解构 TOGAF-6-如何对齐企业的架构愿景？

介绍企业架构的历史已经好多次了，在《企业架构设计的本质》中介绍过三个重要的框架：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 映射矩阵（步骤二）
• 价值链图（步骤八）
• 解决方案概念图（步骤八）