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