架构设计TOGAF标准
2024-04-01 09:55:16 5 举报AI智能生成
架构设计TOGAF标准
作者其他创作
大纲/内容
念--概念阐述
法--开发方法
技--32个最佳实践技术
导--4种向导
行--内容框架
连--连续系列
考--参考成熟架构资产
能--架构工作能力
念、法、技、导、行、能、连、考
TOGAF 8个基础内容
The Open Group Architecture Framework 是一个广泛使用的企业架构开发方法论，它提供了一套结构化的方法和工具，用于设计、规划、实施和管理企业架构。
有30年的历史
有专门的论坛
超10万人进行维护
开放群组架构框架
文化的方式
原则的手段
构建新的架构原则架构文化引领我们往前去走
先接受再创建
领导知道我在想什么
懂我
领导知道我怎么做
爱我
领导支持
牵手
谈恋爱原则
引导领导接受
让大家接受
除非愿意亏本，接受损失
搞不了接受千万别干
规划的能力需要和企业客观的能力匹配
十三五规划
文化做引领(接受)
架构做创建
落地做应用
治理做维护
迭代筛选，一部分一部分的能力去进行规划设计。
TOGAF基于选代过程模型做好总体架构设计。
在过程中一些典型的模式要封装要沉淀，推动重用工作的开展
不断的重用
将一系列的典型单元封装成构建块(building block)
TOGAF注重最佳实践和注重重用已有架构。
4个行为2种文化
TOGAF已经成为企业架构的国际标准
TOGAF由国际标准权威组织TheOpenGroup制定。
概述
形成数据资产(企业架构下养出来的数据，能纵横贯通的数据)
基于企业架构养出资产
数据资产从异构到同构
从异构到同构（塑造同构IT）
事后关注IT治理，事前关注信息化顶层设计
大哥病人入口前调理病人(药膳)
二哥江湖郎中及早发现病症
小卡拉米在病入膏肓时候处理
扁家兄弟有三为何汝之名声最盛
扁鹊和魏王的故事
突出事先顶层设计的重要
企业架构作为顶层设计引领信息化建设
从事后到事先（塑造规划IT）
提需求抓需求变更
功能
做业务梳理、是做系统集成
能力
从散的建功能到统的建能力
系统不能重塑，架构越来越难调整
如果转不过来会导致系统功能越来越多，用户使用越来越复杂
以功能为中心转为以能力为中心
从离散到统一（塑造统一IT）
保证业务能力和传统IT能力一致
以能力来引领信息化建设
从无序到有序（塑造有序IT）
TOGAF能干什么
作为目前最主流的企业架构框架，TOGAF在国除上已被验证，可以灵活、高效地构建企业IT架构，帮助企业节约成本，増加业模式的灵活性，使之更加的个性化、随需应变，并提高信息系統应用水平。
已得到IBM、HP、SUN、SAP、NEC等国除主流厂商的积极推动。 已得到国家电网、人民銀行、中国核电、中国鉄路公司等特大型央企的青眛。
认可度
关键业务流程(能力主线)
横向跨阶段纵向看角色
业务架构看流程
定义业务战略、治理、组织和关键业务流程
业务架构(BA)
散的叫资源
捧着叫资产
赋能叫资本
数据架构看共享
基于数据资产数据流模式
\"共享\"是指多个系统或组织之间共同使用和访问数据的能力。共享数据可以促进信息的流动和共享，提高数据的可用性和可靠性，以及减少数据冗余和重复。
组织的各类逻辑和物理数据资产以及数据管理资源的结构。
数据架构(DA)
强集成，传统态，契约化，规范化
总线(稳态)
弱集成，能够适应变化
微服务(敏态)
应用架构看集成
两种方式集成
应用架构(AA)
建平台、上应用、通数据
技术架构看平台
对于支持业务、数据和应用服务的部署来说必需的逻辑软、硬件能力。包括IT基础设施、中间件、网络、通信、部署处理和一些标准等。
技术架构(TA)
企业架构
有了企业架构，不会再按照产品进行选型，是根据企业架构进行选型，可以根据企业架构去外包或者选型，主动权始终掌握在自己企业手里，减少对供应商的依赖，要求供应商按照企业架构开发做定制，不依赖供应商的产品。
因为供应商的产品定型了，改不动，很难改
业务出需求-邀约-中标-然后企业被中标单位绑死(供应商产品平台好坏直接决定了我们信息化平台的好坏，他能弹性扩展，我们的需求就能变更落地，如果供应商固步自封，我们的信息化就举步维艰)
老的模式
可以选择多家供应商作为合格供应商同时参与的中标模式，每次中标三家以上的供应商，按照信息架构做信息系统开发，如果那家不听话就踢掉
企业架构掌控
依托业务驱动，打造信息化条件下的新型业务能力，构筑新管理能力，新业态能力，新经济能力。
创造面向业务的能力成效
内部的部门想到的新型能力
内生愿景
例如我需要被迫使用大数据能力去解决当前的需求
我想改进什么样的业务能力，我被迫需求适应什么业务能力的需求
外生驱动
能力愿景产出
TOGAF包含的内容
TOGAF概述
一种可靠的、经过验证的开发和使用企业架构的方式
一种从四个核心维度(业务、应用、数据、技术)上开发架构的方法，使架构师能够确保各种复杂的需求都能被充分考虑到，对架构开发工具的一些普适指导策略。
ADM（Architecture Development Method）
一备一中心八步一法(葫芦图)
解决创建输入的问题，做能力需求的定义
为能力创建找具体需求，确定能力的内涵，到底这个能力的内涵是解决什么样的业务场景
需求管理
一备一中心
一些列业务场景下能力期升作为内涵所支持下一组双向性的能力组合
A架构愿景(能力愿景)
业务流程优化，系统端到端优化覆盖，从离散到连续
数据共享，融合
将能力转为业务架构
帮助业务流程就行优化
B业务架构
应用架构
数据架构
C信息系统架构
D技术架构
解决创建问题
缺某一个系统
缺某一个数据共享
机会就是找差距，从当前变成将来有差距的地方就叫机会
一个工作包能否立项，看有没有可选择方案，项目可信性方案
解决方案
E机会及解决方案(相应的发展规划)
F迁移规划
G实施治理
H架构变更和管理
八步一法
达成共识
一个导向
能力组合范围，到底推动什么能力建设、搞什么能力规划
范围
能力导向
业务驱动
统一架构
分工协同
要倡导的文化
原则
对方法、交付物、原模型进行裁剪
裁剪
三个要素
建立治理架构、治理结构
要认可要通过信息职能建立架构管控
治理
一个位置
一个导向、三个要素、一个位置
了解业务环境
获得管理层承诺
对架构范围达成共识
制定原则
建立治理结构
对TOGAF进行裁剪和定制
案例(准备和启动创建架构能力所需的各项活动)
预备阶段
设定范围、约束和期望
每次架构周期开始时均需进行
启动架构流程的一次迭代
创建架构愿景
验证业务情境
创建架构工作说明
从需求中挖掘出各业务场景下能力的内涵
业务流程及其人员
业务流程、人员之间以及与环境之间的关系
治理业务架构设计和演进的原则
业务架构是业务的基本组织形式，体现在如下方面
业务架构揭示了这种组织形式满足企业业务目标的方式方法
塑造业务流程(纵横贯通)
各部门按照业务流程分配下去后能够认责
保证业务架构能够分解、分配、分责
组织结构
业务目标和目的
业务能力
业务服务
业务流程
业务角色
组织与功能的相关性
业务架构和以下几方面的关系
1.选择参考模型、视点及工具
2.定义基线架构描述
3.定义目标架构描述
4.差距分析
5.定义候选路线图构件
6.正式利益相关者审查
7.形成最终架构
8.创建架构定义文件
业务架构实施步骤
业务架构横向跨阶段纵向跨角色
IT教业务部门做梳理
教
陪着业务部门日常练习如何梳理
练
指导如何进行梳理
导
帮助判断
评
助手作用，只提供人，不认责
助
谁去做什么部分，坚持以业务为驱动
谁的孩子谁抱走、谁的苦恼谁分忧
1.业务梳理
https://wenku.baidu.com/view/41979f514b2fb4daa58da0116c175f0e7dd1196e.html?_wkts_=1696835634192&bdQuery=Aris%E5%B7%A5%E5%85%B7
业务架构建模工具
Aris
架构模型工具
Archi
Visio
流程梳理工具
当各个业务部门都梳理了各自的流程实现，在流程还原过的时候组责部门负责，当业务部门发现流程存在问题的时候，需要IT帮助，可以帮助但是不认责，充当助手作用
2.流程展现
系统支撑
数据贯通
两个思维去发现
3.问题发现
前面的梳理好的是基线业务架构，在优化后就是目标业务架构
4.目标优化
业务架构4个步骤
经营管理域
人资管理域
财务管理域
物资管理域
生产管理域
项目管理域
企业常用6大业务域
应用架构IT
数据架构DT
双轮驱动
端到端覆盖
支撑
数据驱动融合创新(数据流贯通)
赋能
实现业务架构的支撑和赋能
贯通的具体的东西
强调贯通的内容
如何将数据进行贯通
强调贯通的管道
关系
管道支撑数据流转
但情况并不总是如此，这取决于项目范围和约束
通常，应用架构、数据架构据均需开发
理论上应该先开发数据架构
从现实考虑，先开发应用架构或许更有效
开发顺序可任意或并行
业务如果是固态是时候先确定应用架构，业务如果是敏态先开发数据架构
为了确保两者之间的一致性，需要采用迭代开发方式
阶段C主要描述与设计一个组织的信息类型以及处理这些信息的应用系统上
主要的信息类型以及处理这些信息的应用系统
信息与应用系统之间以及环境之间的关系
治理信息系统架构设计和演进的原则
信息系统架构是IT系统的基本组织形式，体现在如下方面
信息系统架构揭示了IT系统满足企业业务目标的方式方法
一步划分
二步构成
三步交互
应用交互视图
基于业务架构看应用架构
数据主题域
数据流
基于业务架构看数据架构
一个能力主线规划一组应用架构和数据架构分别进行规范
规划思路
技术架构的软件、硬件通信技术
软件、硬件、通信技术之间以及他们与环境之间的关系
治理技术架构设计和演进的原则
技术架构是IT系统的基本组织形式，体现在如下方面
赋能数据共享
赋能应用集成
目的
站在应用架构+数据架构去看技术架构
技术架构视图
建得出
撑得住
技术架构满足点
项目之间有项目牵制依赖得关系
找项目组合
做发展规划
发展规划
进行首次实施规划
识别主要实施项目
对项目进行工作包分组
开发、购买或重用
外包
购买商用解决方案
利用开源软件
确定实施方法
优先级是看价值
评估项目优先级
依赖是看规律
识别项目间得依赖关系
机会分析找差距
方案优选立项
重点
发展规划示例
阶段划分
一个划分
时间(进度)
预算
价值
风险
四个细化
一个划分四个细化
成本/收益分析
风险评估
阶段F将对其进行
制定详细得实施与迁移计划
对于节点E确定得工作包和项目
示例
相应遵从性的条款合起来就叫架构契约
每一个实施类的项目或湖这种行动单元，他都需要对全体架构有一定的遵从性
架构管理职能面对项目管理小组所签署的架构契约
推广架构契约精神
监督架构实施
定义实施项目的架构约束
治理和管理架构合同
监控实施工作的合规情况
确保实现业务价值
介绍
架构遵从管控
系统架构管控流程
提供持续监控以及变更管理流程
确保以一致和结构化方式管理架构变更
确保企业架构灵活性，使架构能够快速演进，及时相应及时或业务环境变化
对业务和能力管理进行监控
业务能力的需求发生变化
实施项目与整体架构产生了偏差
起因
架构变更工作流程示例
好的企业架构是不断的需求变化养出来的
业务能力需求变化
架构合规评估偏差
架构变更管理
每个阶段的详细介绍
以业务能力为中心做识别
以统一愿景为中心做聚合
需求管理为中心
获取需求--审核需求--分析需求--审核分析--需求设计--审核设计--形成制品
概述及需求管理流程
部门调研
信息部门调研
项目单位调研
面向调研过程中的引导性梳理
什么是需求管理
以业务能力为中心去梳理和引导需求，再做愿景关联分析
自上而下塑造能力愿景（接受），然后再去推动企业架构的创建，然后推进使用和维护
怎么做需求管理
ADM开发的方法步骤
总览
描述
裁剪就是选择的意思
有什么理念让大家接受，或者信息化发展的规划下一步退出什么样的理念，文化
选原则（口号）
选方法
Visio、Archi、Aris等
选工具
交付物有哪些
选交付
参考资料有哪些
选参考
5种选择
辅助性
解释
裁剪的必要性
希望要懂得项目管理传统方法，只可用来参考，不可用来僵化遵循
有的放矢因地制宜
胜兵之法不可先传
不能
能不能哪一个相似的企业架构做结果裁剪
案例
1.裁剪过的架构框架
核心是业务架构师
组织细分
一总四分两管理，1总--企业架构师/首席架构师、四分--4种架构师、2管理--项目管理、文档管理
2.企业架构的组织模型
推动战略契合、流程重构
业务
谁生产谁管理
数据标准化
数据安全
面向数据资产化，推动数据共享，重用，数据认责
数据
统一设计、重用
应用
形成标准化的信息技术平台
技术
类型
架构的原则
影响架构原则的因素
不同的组织如何构建原则
4个类型
截图
名称应积极、正面
名称
声明无二义
声明
依据有价值（对业务能力建设[效果、效率、效益]有帮助作用）
依据
相关保一致
相关影响
标准
4个模板(标准)
5个标准
建设系统的原则(通过原则去建设我们的信息化系统，不要通过方法去建设)
易懂看用户
易懂
健壮看复杂
健壮
完整看覆盖
完整
一致看冲突
一致
稳定看变化
稳定
5个质量
3.架构原则
能力导向、业务驱动
业务部门调研的时候谈原则讲模式
4.业务原则、业务目标和业务驱动力
架构框架存方法、标准库中存标准、架构景观存设计、参考架构存案例、治理日志存偏差
5.架构存储库
常用桌面工具
商业
sparkea
https://blog.csdn.net/waldensss/article/details/133412171
介绍地址
TOGAF主流推动的
开源
ArchiMate
https://www.archimatetool.com/download/#
下载地址
Enterprise Architect
6.选工具(做企业架构建模的工具)
高层发起--任何业务部门/信息部门都不能以部门名义来发起
高层赞助--拉动企业各方面的投资，流程梳理、系统建设、数据治理等
两高原则
企业架构是面向核心能力做好顶层设计
7.架构工作请求
4个调研、2个文档（调研报告、分析报告）、4个架构、1个规划、1个治理
核心产出
P:背景
P:目标
I:工作输入
C:工作成本
T:工作时间
O:工作输出
PPICTO
架构工作说明书写不出就别玩了
架构说明书案例
8.架构工作说明书(类比于实施方案)
高层授权承诺
面向管理层薅出羊毛，达成架构愿景，明确能力的范围组合
高层授权
各部门去交流，必须支持，每个部门必须出什么能力的需求，围绕能力建设出需求
部门支撑
介绍一下领导层什么意思，各个部门有啥需求
向下就是宣贯，让大家知道要做这个事情
向下宣贯
架构愿景三大作用
架构愿景描述
业务流+数据流
业务场景案例
9.架构愿景
领导层
业务部门
下属单位
代表
干系人有哪些
描述截图
权力者(权力大有哪些人)
魅力者(魅力大有哪些人)
双力
关键
找出来、划分、以利益相关者的关注去定义架构交付物、引领干系人做评估评判获得积极反馈
找出干系人
一施
关键的干系人按照双力原则划分出来，划分为权力大者、魅力大者
二分
做干系人关注的事情，不关注没有效果
以干系人的关注为导向，定义架构交付物
三定
因此需要及时的获得干系人的反馈
早的叫反馈，晚的叫返工
引领干系人做评估评判，获得干系人有意义的反馈
四快
4步
干系人满足的原则(如何管理干系人)
找到关键人，搞定他
做好干系人的管理，早点将问题反应出来
干系人分类示例
10.利益相关者(干系人管理)
向上沟通求授权
对等沟通求支持
就是落实事情
有什么想法
向下沟通求落实
3向(沟通方向)
找准干系人(干系人管理种分出来的一些人)
研究如何跟关系人打交道
一定相关干系人
例如财务部长关心什么，必须定下来
每个干系人关注什么，必须一清二楚
二定相关关注点
什么时间点和干系人沟通合适，上午还是下午，多长时间沟通一次(一次性还是周期性)
三定时机与频率
什么手段、方法和干系人沟通
四定手段与方法
4定(沟通方式)
3向4定
面向领导层先坐着沟通
坐（请坐）
长时间聊，喝个茶
茶（时间）
聊的很久了
饭（一起吃饭）
好的沟通效果（沟通结果的三个等级）
根据时间沟通的长短，能够确定沟通的结果是否有效
11.沟通计划(研究如何与人沟通)
面向能力的规划
识别能力建设的可行性
立足转换找风险
立足增量看可行
两立
12.业务转换的准备就绪评估
宽度找范围，多少能力是适合做优化的
那个能力可行，适合做优化
宽度看多少
具体能力范围，能力单元，我们能增加多少
优化能优化多高多低
优化的能力，能优化多高
高度看增量
两个维度的评估
重点是能力愿景架构愿景的考究
如果能力太大转换不了需要迭代
能力提高的量是否可行呀，贪心不足蛇吞象
架构愿景(高层授权，部门的支持，下属宣贯的能力愿景)
用在做业务架构的时候，做能力愿景架构愿景考究的时候
13.能力评估(强调能力评估可信性)
把风险找出来
识别
把严重的风险挑出来
度量
把严重风险的影响识别出来
量化
看风险是积极的还是消极的，积极的大于消极的别管他，这是好事情，这样能够养风险
权衡
需要有应对之策
应对
5步
上面的5循环的做
循环开展
1环
5步1环
带领、引导其他人往前突破的时候需要有风险管理意识
壮士
烈士
没有风险管理意思的结果
通过风险管理使自己能够运筹帷幄决胜千里
每一步都有一定的风险
风险管理意识要循环的做
企业架构师需要建立风险管理意识
14.风险管理(架构总设计师能力规范过程种建立的风险管理环)
企业架构是根据什么原则做出来的，总体策略
业务驱动输出成果
业务梳理，积极的梳理成果
业务架构
技术架构
4个架构
能力规划的塑造
架构
在当前的条件下如何去做
通过怎样的治理方式让大家用起来
遵从性的规则和治理管控的应用
后期指南
定义输出文件
15.架构定义(输出架构定义文件的交付物)
如果针对一些平台化或专题做总体设计，这种总体设计写出来的是企业架构版的需求规格
不是面向业务能力是面向某种平台，不管是那种平台，基于企业架构写出来的就叫做架构需求规格，有利于招标和推动总体建设之用
面向业务能力叫架构定义，面向某种平台做总体设计叫做架构需求规格
企业架构可以面向能力架构定义
企业架构面向平台做总体设计
面向能力规划出来的比较抽象，面向平台设计出来的比较具体
16.架构需求规格
面向架构迁移描述出来的一个能力达成的阶段路线图
典型包含项目列表、面向时间的迁移计划、实施建议
架构路线图列出了变迁的各个增量，并把它们放在一条时间轴上，展示了从基线架构向目标架构的演进过程；它是过渡架构的关键构件，并在阶段B至F过程中，以增量的方式被开发
1个主线
规矩建设的能力
过渡架构
项目组合
2个要素
一个主线两个要素
17.架构路线图
业务流看逻辑
数据交互一般是交互的对象
数据流看数据
双流合一定义业务交付(目标业务能力对象与相关业务对象的交互问题)
18.业务场景技术
工作包和项目的区别是，工作包通过可行性方案研究解决方案优选才能变为项目
差距分析是识别工作包的一个过程
差距分析案例
直接分析工作包
间接分析选方案
分析工作包
是工作包且有方案的才能立项
往往会绘制一个差距分析矩阵，现状中有什么，目标中有什么
面向对象的一种思想
要素架构中描述的要素叫做构建块
目标与现状直接的比较
差距分析面对的是缺口
现状已有目标认为已经满足说明具有继承那么没有什么可以做的
全新建设
缺
如果现状中没有目标中有这叫做缺，缺少一个构建块
升级改造
弱
如果现状中有目标中认为要升级的
基约化建设
重
现状中有相关多个但目标中基约化统一了
在差距分析中
差距分析中要干的事情
19.差距分析
例如业务存在矛盾，做多套可用的架构，一般会做成统一的架构
在架构设计之前一个共识化管理的问题，干系人在提出很多关注点的时候，企业架构师是按照共识做架构设计还是按照共识+分期做全集架构设计
达成共识，不接受不创建、先接受后创建
针对不同干系人的直接的冲突，需要用同一套原则去引导，看是否能够化解，能化解就是达成了共识，不能化解还是冲突
作用：共识化的干系人关注
20.架构视点
按照架构视点完成的架构设计
目录
应用模块对业务要素的覆盖
例
矩阵
图形
架构视图三种形态
架构师在做的过程中，要去决定到底把哪些做出架构视图哪些不做
架构视图的要点注重点
有冲突的不碰
没冲突的再去做
基本点
要能圆满的协调不同干系人之间存在冲突的关键点，在协调过程中做出的权衡，必须有利于共识化的接受
21.架构视图
架构构建块=一个视点+相关图形的封装
能形成企业架构资产库，有利于重用
构建块比较吻合面向对象的思想，在面向对象这个模式下有利于把架构设计的成果封装为一种设计资产，在类似的架构师工作过程中就可以快速的集成和组用，提高设计效率、效果、质量的一个方式
22.架构构建块
把解决方案跟甲方干系人关注点封装就叫解决方案构建块
解决方案构建块=一个视点+相关方案
解决方案构建块包含的内容
乙方沉淀解决方案构建块
以视点为导向做好封装
引领双方共同推进的事情
解决方案可以作为资产可以按照甲方视点来进行封装
当招标和解决方法优选的时候能够很好的进行结构化的评选
当行业内部解决方案构建块和架构构建块都与视点作为通用的沉淀封装
甲方和乙方是基于视点来衡量解决方案是否可选的思维，有利于去匹配
23.解决方案构建块
在EF角度做发展规划时候是面向能力做交付
每个能力即设计到业务流程改造、数据治理、系统建设、所依赖平台建设问题
完成一系列跨项目的组合
阶段的划分是能力增量的达成
面向能力交付，定好阶段划分，在E/F阶段的一种基于能力规划的原则、确定和规划企业转换的具体方法，是一种聚焦业务成果的业务规划技术；是业务驱动和业务导向，将各具业务线所必需的发行量结合起来，以达到企业期望的能力
24.基于能力的规划
时间进度规划
投入预算规划
价值目标规划
风险保障规划
需要做好4个参数的细化
前面阶段性划分下，每一个项目都需要细化去做这4个规划
通过推论去实施
什么样的流程建设、什么样的系统建设、什么样的数据治理项目、什么平台类的项目
实施因素是我们要干的一系列实施行为
推论完后有利于4个参数细化
推论整个过程中带来什么样的影响
通过实施因素去推论
如何排好进度先后，衡量价值高低，识别预算多少，分析风险状况
架构定义增量表：某种中间过渡能力需要完成什么样项目组合
依赖意味着进度先后、价值高低、风险、投资的倾斜
推论完成后整合分析依赖
25.迁移规划技术(TCVR技术-Time时间 Cost费用 Value价值 Risk风险 )
从基线架构走向目标架构的进度
26.实施和迁移规划
能力过程提升设置中间的的问题
在能力提升努力过程中需要去说明到底有什么价值，要从能力的达成性上去解读
意味着在业务流程上做哪些建设，做了哪些数据的数据梳理，做了哪些系统支撑性的建设，做了哪些平台的提升改造
每一个过度架构需要从业务上、应用上、数据上、技术上进行描绘
27.过度架构(里程牌)
如何把企业架构用起来的组织保障
定政策
建组织
明确流程
明流程
做考核
要求企业信息部门必须做三件事情
28.实施治理模型
流程建设不能违背整体能力发展的规划，不能违背业务架构
系统软件开发不能违背应用架构
数据库设计及其数据的共享流程不能违背数据架构
技术路线的选取不能违背技术架构
架构治理落地到每个实施项目上，需要一个遵从性的章程
架构项目的遵从性章程，建设不能违背整体架构
以契约精神来确保架构实施遵从架构
每个项目最开始就要遵从
契约精神公平、公正、公开的思维
以契约精神推动企业架构对实施项目的一个管理问题
面向治理的契约
治理职能面对实施项目之间契约化的模式
29.架构契约
需求的变化
治理的偏差
2种变更输入
企业的战略调整了，能力组合不一样了，就需要整体的变更
整体变更--看战略
需要追加能力的变化，重新打造一个全新的能力
增量变更--加能力
例如应用架构是总线型的改为微服务架构
战略没有调整、能力没有追加，单纯的IT架构的调整叫做简单变更
简单变更--看IT
3种变更类型
30.变更请求
行为就是确保企业架构有效在实施项目中，有人去检查
时代是我们到了通过让实施项目遵从整体架构去打造新型能力的建设信息化时期
既是行为（检查），又是时代（通过遵从架构去建立能力）
充分发挥了原定治理契约的作用，把检查单有效的用起来，规避合规评估的主观性，回到客观评估上来
31.合格评估
在调研过程中，我们去各部门收集了一些关于能力建设的想法，这些想法是和业务架构有关、还是数据架构有关、还是应用架构有关、还是技术架构有关
什么是需求影响评估
识别业务需求和架构关注点的关联性(业务、需求、应用、技术)
32.需求影响评估
32种关键技术(如何去做)
32种关键技术交付物
架构开发方法ADM周期的关键技术和交付物
立足原则模板体系选哪些
立足A点框架，增补哪些步骤
出哪些视图，典型视图有哪些
对象是--原则、方法、交付物
裁剪是多多少的问题，就是到底裁剪多少
上下文、定义迭代、迁移规划迭代、治理迭代
接受
创建
维护
使用
迭代需要做好
这几点都有迭代，怎么做成共识
迭代是先后问题
按照迭代密度分类：周期型迭代、阶段间迭代、阶段内迭代、团队间迭代
搞定领导层，必须授权达成共同的能力愿景诉求，达不成就去给领导层沟通、洗脑做引导
愿景共识--上下文迭代
构架定义共识--架构定义迭代
迁移规划共识--迁移规划迭代
治理体系共识--架构治理迭代
4种共识4种迭代
迭代是为了共识
战略是未来的目标
战略
资产是前进的路线
资产
2种风格(基础先行、目标先行，取决于战略和资产)
如果既没有目标也没有路线那就问题驱动，用脚趟着走，识别出什么问题就改进什么问题
战略明确、资产丰富---目标先行、自上而下
战略含混、资产匮乏---基线先行，自下而上
2个归类2种分类
2种风格
迭代
把企业架构战略分割为业务战略在分割为能力
将企业架构分割为业务战略
将业务战略分割为能力规划
将能力规划分割为架构设计
分割步骤
按照企业架构、业务战略、能力规划、架构设计的层级顺序进行分割
面对企业架构的时候需要学会做好工作分解
顺着能力规划做提升设计
主题看多少
业务种类、业态
主题
时间看长短
识别出几年的能够撑得起发展路径和阶段
时间
细节看粒度，看粗细
细节
三大维度
战略看全局
业务战略
分段看业态
分段架构
业务看单元
能力架构
三个层次(细节的三个层次)
三大维度三个层次
层次(很重要)
面对安全架构、典型架构、服务架构等典型扩展架构相应得一些能力
用四大架构来找关注、四大架构来看完备设计满足
在构建4大核心之外的架构改怎么做
安全架构师的关注领域：身份认证、授权、审计、保证、可用性等
识别关注
4大视角衡量安全满足
设计满足
两点
7A1R安全平台
4A安全平台
安全架构
服务架构模式
传统服务注重明确共性与隔离变化
把业务、应用、数据、技术有关的要素分割为服务单元，有利于将来服务单元的共享和隔离变化
传统分割
注重数据聚合与资源聚合
现代转型
传统服务为了做分割、现代服务为了做转型
服务架构
指导
ADM调整4大向导
32个技术是做法、向导是用法
ADM调整4大向导和32种关键技术的区别
网络架构
通信架构
部署架构
其他非核心架构
如果是外包需要做到自主可控
调整ADM的指引
统一概念
企业架构化初期就需要裁剪出来的
比较标准的概念+视图的原模型案例
统一视图
概念
架构师做的一个个架构设计单元
日常产出构建块
例如业务架构产出、技术架构产出、安全架构阶段产出、服务架构阶段产出了等
阶段产出为制品
阶段产出后的制品被认可了就可以称之为交付物了
最终产出交付物
架构工作产出的分类
统一分类
解决在内容上的三统一
架构内容框架
反映着我们整个架构设计的总体水平
所作出架构设计水准的划分，他是架构设计资产成果的成熟度划分
一个设计涵盖的普适性越强，说明设计的水平越高
一种抽象性个重用性的等级划分
特定级别看企业
特定组织级（级别最低）
行业级别看产业
行业级（级别倒数第二）
几个产业都能够通用
通用级别看跨越
通用级（级别第二）
设计出来满足了国际标准、国家标准，那就档次很高
基础级别看标准
基础级（级别最高）
4个等级划分
连续序列做基础分类
对架构存储、解决方案面向重用等级的虚拟划分
标准库
作用
一个等级序列
甲方划分架构连续序列
乙方划分方案连续序列
两种用途
形成了虚拟分类的一种依据
一种划分
一个等级序列、两种用途、一种划分
企业连续系列
一定义要沉淀架构资产的参考库
尽量不要原始创新、借鉴他人智慧
基础级别
指导技术架构设计
左开发
右安全
上门户
下文化
有利技术架构明确位置与分类
TRM架构
集成信息基础设施
1.开放互联用标准
2.协同访问用代理
3.打造无边界信息流（数据流）为宗旨
分布式微服务式就是采用这种模式
4.强代理（企业服务组件）、管权限，弱代理（目录管理）、管身份
III-RM架构
参考分类
TOGAF参考模型
架构能力框架
大纲
TOGAF9.2企业架构框架教程
官方介绍
理解
描述组织的逻辑与物理数据资产及数据管理资源的结构
L1:主题域分组
L2:主题域
L3:业务对象
L4:逻辑数据实体
L5:属性
通过分层架构表达对数据进行分类和定义
厘清数据资产
建立数据模型的输入
1.数据资产目录
是业务定义的规范
为数据资产梳理提供标 准的业务含义和规则
2.数据标准
业务数据、数据标准
通过E-R建模实现对数据及其关系的描述
3.数据模型
是数据在业务流程和IT系统上流动的全景视图
识别数据的\"来龙去脉\"
是定位数据问题的导航
4.数据分布
表达数据在业务流的流转
信息链
表达数据在IT系统的流转
定义数据产生的源头
数据源
数据分布组件
4个规范
以结构化的方式描述在业务运作和管理决策中所需要的各类信息及其关系的一套整体组件规范
数据架构的价值
数据架构交付清单
提供包含待部署的独立应用及其之间交互作用和与组织的核心业务流程间的关系的蓝图
为将要部署 的单个应用程序、它们的交互以及它们与组织的核心业务流程的关系提供蓝图
描述了各种用于支持业务架构并对数据架构所定义的各种数据进行处理的应用功能
各种可以从市场或组织内部获得的软件和硬件组件
4A架构案例
http://www.360doc.com/content/12/0121/07/21618889_1076659804.shtml
参考链接
如何去画4A架构
4A架构
架构设计
收藏
0 条评论
回复 删除
下一页
