介绍企业架构的历史已经好多次了，在《企业架构设计的本质》中介绍过三个重要的框架：Zechman，DoDAF 和 TOGAF。除此以外市面上还有各种各样的书讲架构设计方法和实践，所以我再想是不是可以为架构设计圈做一点有意义的小事，就是把这些架构框架，架构书籍，甚至架构工具都解读一遍。现在使用最多，影响力最大的就是 TOGAF 了，所以我打算就从这个有点重的块头开始，和庖丁解牛一样一点点拆解，所以这个小事有个标签：和坚解构。
之前在《解构 TOGAF-4-如何建设架构能力？》一文中介绍了 ADM 的预备阶段，经过预备阶段战争动员已经做完了，现在正式进入 ADM 的循环，第一个阶段是架构愿景。
1 架构愿景阶段的目的
为什么要做架构愿景？不做行不行？在我看来，ADM 里面其他阶段都可以剪裁，唯独架构愿景是不能剪裁的，因为这个阶段决定了企业架构设计项目的边界和范围，不明确这个边界，我们无法确定架构项目要怎么做才算成功。架构愿景是对目标架构的简介描述，描述了业务价值以及成功部署对企业产生的变化。它即是理想的愿景，也是详细架构开发的边界。所以架构愿景有这样三类重要的目的：业务价值，工作边界和对齐
- 明确架构工作的业务价值
- 制定能力和业务价值愿景
- 验证组织的业务原则，业务目标，战略业务动机和企业架构 KPI
- 确定架构的工作边界
- 建立架构框架上下文，定义架构开发周期
- 定义基线架构构建范围
- 与 stakeholder 对齐
- 定义 stakeholder 极其关注和目标
- 获得管理层对架构工作说明书的批准
2 架构愿景阶段的步骤
2.1 步骤一，建立架构项目
企业架构是一个业务能力，业务能力需要通过有边界的项目来获得，所以建立架构愿景的第一步是立项，通过立项获得企业对项目的认可，管理层的背书，以及部门管理者的支持和承诺。
2.2 步骤二，识别 stakeholder，关注点和业务需求
既然企业架构是一个公司投资的项目，那这个项目的成败就取决于手握筹码的 stakeholder。所以第二步需要识别 stakeholder 并对他们进行管理。所以这个阶段有一个重要的制品是干系人地图矩阵，通过矩阵表的方式说明每一个 stakeholder 的关注视角，沟通类别（保持满意，保持告知，加强告知等等），以及可以帮助他们理解架构工作的制品应该有什么。
2.3 步骤三，确认业务目标，业务驱动者和约束
这一步主要是设定企业架构项目的边界，一个是这个项目的最终业务目标是什么，比如全面降低成本，开发一个新产品，或者扩大市场规模。另一个是这个项目的边界在哪，什么是企业层面的边界，比如没有银行牌照不能不能做金融业务；什么是项目的边界，比如多久时间，多少人，多少预算等等。
2.4 步骤四，能力评估
能力评估是一个架构交付物。
实现业务目标是需要企业能力支撑的，所以这一步需要评估实现目标需要的目标能力有哪些，目前的基线能力有哪些，然后目标和基线之间的 GAP 就是需要开发的能力了。这里的能力既包含在动员阶段发现的架构能力，也包含实现业务目标需要的其他能力。
比如说业务目标是新开发一款手机，那就需要手机的设计能力，生产制造能力，供应链管理能力，以及保证这些能力顺利运转的 IT 系统支撑能力。
最后的结果会被记录到一个架构交付物能力评估中：
- 业务能力评估
- IT 能力评估
- 业务成熟度评估
2.5 步骤五，定量评价业务转型准备度
业务转型准备度，是理解组织接受变化，发现问题以及在实施和迁移规划中处理这些问题的准备就绪程度，是阶段 E 和 F 架构成功转型的关键。这一步使用业务准备度评价因子来定量评价转型准备状态。
这一步的结果也会加入到架构交付物能力评估中：
- 业务转型准备度评估
2.6 步骤六，定义架构工作范围
通过几个方面确定哪些是架构的工作，哪些不是：
- 架构工作的层级深度，比如说架构工作只要得 L4 就够了
- 架构工作的领域宽度，比如说只需要业务架构和应用架构，不需要技术架构
- 架构工作的时间范围，比如说工作 3 个月，其中 2 周一个迭代
2.7 步骤七，确认和阐述架构原则，包括业务原则
这一步需要审视在预备阶段开发的架构原则，如果某个原则定义不清晰，就需要要求架构治理机构重新清晰定义，然后最重要的是获得公司级管理层的认同。
2.8 步骤八，开发架构愿景
架构愿景是一个架构交付物。这一步是阶段 A 最关键的工作，前面七步都是为了这一步在做准备，可以认为如果阶段 A 没有做这一步就等于没做。所谓架构愿景，是两个给管理层的高层级架构视图，一个是基线架构视图，一个是目标架构视图。架构愿景的内容包含：
- 问题描述，
- stakeholder 及其关注点 ( 输入信息来自步骤二 )
- 对应的问题和场景列表（输入信息来自步骤三）
- 架构工作说明书的目的
- 架构工作要求书的概要视图
- 价值链图（制品，价值链需要能力支持，输入信息能力来自步骤四和步骤五）
- 解决方案概念图（制品，解决方案涉及架构工作范围，输入信息来自步骤六）
- 映射的需求 ( 输入信息来自步骤二)
- 架构定义文件草案的参考资料（架构定义文件来自预备阶段）
2.8.1 价值链图
2.8.2 解决方案概念图
2.9 步骤九，定义目标架构价值主张和 KPI
这一步是为每个 stakeholder 组定义价值主张，评估和定义采购需求，并获得 stakeholder 的认同，定义用于满足业务需要的架构 KPI，还要评估风险。
我在解读到这一步的时候其实是有一个疑惑的，如果是为每个 stakeholder 定义价值主张，为啥不在步骤二就定义清楚价值主张呢？思考了一下发现了 TOGAF 在这里的严谨：因为步骤二梳理的信息是 stakeholder 的问题域，而价值主张是基于对问题域的分析给出的解决方案。所以只能基于步骤八的架构愿景才能定义价值主张。
2.9.1 什么是价值主张？
价值主张描述了 stakeholder 从架构工作中所期望得到的收益。通常价值主张会包含三个部分，工作产出清单，收益创造方案（如何为 stakeholder 创造收益），痛点缓释方案（如何减少 stakeholder 的痛点）。
2.10 步骤十，识别业务转型风险和规避措施
架构愿景阶段的最后一步是识别与架构愿景有关的风险，并评估最初的风险等级。关于风险登记 TOGAF 是这么定义的：
- 风险的初始等级：实施风险缓释行动前的等级（例如灾难性，关键性，不重要的）
- 风险的残余等级：实施风险缓释行动后的等级
2.11 步骤十一，开发架构工作说明书；确保批准
架构工作说明书是一个架构交付品。定义了架构工作的开发周期和实施路径，是测量架构项目成功执行所依据的文件。这一步除了要交付架构工作说明书以外，更重要的是要确保架构工作说明书获得批准。
架构工作说明书典型的内容有：
- 架构项目要求和背景
- 架构项目描述和范围
- 架构愿景的概述
- 角色，职责和交付物
- 验收准则和程序
- 架构项目计划和进度表
- 批准记录
3 架构愿景阶段的交付物
- 架构工作说明书（步骤十一）
- 业务原则，业务目标和业务驱动因素（步骤三和步骤七）
- 架构愿景（步骤八）
- 能力评估（步骤四和步骤五）
4 架构愿景阶段的制品
- stakeholder 映射矩阵（步骤二）
- 价值链图（步骤八）
- 解决方案概念图（步骤八）
