TOGAF架构开发方法（ADM）-- 架构愿景阶段

1.2 架构愿景（Architecture Vision）

                                     

企业架构开发方法各阶段——架构愿景

1.2.1 目标

• 确保架构开发循环的进展被企业管理层认知和支持，并取得必要的管理线的支持和承认。
• 在预备阶段中明确的架构框架的整体背景之下定义和组织架构开发循环。
• 验证业务原则、业务目标、组织的战略业务驱动力，以及企业架构的主要性能指标（KPIs）。
• 定义基线架构的范围，明确其所包含的组件以及组件的优先级。
• 定义相关干系人以及他们的关注点和目标
• 定义架构工作所要解决的关键业务需求，以及必须应对的各项约束
• 阐明架构愿景，并定制价值主张。这些价值主张被用来阐述对于那些需求和约束的回应
• 创建一个综合性计划，用来表明规划进度、资源、财务、沟通、风险、约束、假设和依赖关系，并应与企业中的项目管理框架相适合（PRINCE2或PMBOK等）
• 确保正式批准得以执行
• 理解与其他并行的企业架构开发循环之间的相互影响

1.2.2 方法

      架构愿景阶段是从架构组织收到来自于架构赞助组织的架构工作要求书时开始的。在这个阶段中，组织需要基于针对当前资源及其可用性所做的评估来界定架构工作的范围，以及需要应对的种种约束。这些约束通常来源于在准备阶段中制定的各项业务原则和架构原则，而在架构愿景阶段中，组织需要确定这些原则是存在并清晰的，如果不是这样，则需在此阶段对这些原则进行明确的定义。除此之外，在此阶段所涉及到的方法还包括：

创建架构愿景

      架构愿景是架构赞助者向各干系人以及决策者推广其所提出的能力的绝佳工具，它描述了新的能力如何满足组织的战略和业务目标，以及当这些能力实现时，相关干系人所关注的问题又是如何获得解决的。因而针对架构愿景的创建实际上就是对架构的目标进行明确，并对如何通过架构开发来达成这些目标进行阐明。架构愿景在一个很高的层面上为基线和目标架构做了有关第一印象的描述，并且这一描述应该涵盖业务、数据、应用和技术这四个层面（这只是概要性描述，这些层面的具体内容将在后续的相应阶段被逐步细化）。

      一旦架构愿景被定义并被记录到架构工作说明书中，接下来在各个干系人中对这份架构愿景形成共识将会成为重中之重，因为如果没有这份共识，那么最终的架构是否能够被组织所接受就无从谈起了。这份共识的获得是通过赞助组织签署架构工作说明书来实现的。

业务情景

      业务情景方法用于识别和阐明隐含的架构需求和隐藏在新业务能力（用于满足关键业务驱动力的需求）中的业务需求。此技术通过一种循环迭代的方式进行，并针对业务架构的各层次化分解部件采用不同等级的详细度进行描述。

1.2.3 输入与输出

      在当前阶段所需的输入材料以及此阶段输出的各种交付物归纳如下：

输 入	参考资料	架构参考资料
	非架构性输入	架构工作要求书
		业务目标、原则和驱动力
	架构性输入	企业架构组织模型，包括： 受影响的组织范围 成熟度评测、差距及解决方法 架构团队所担当的角色和职责 架构工作约束 重用的需求 预算需求 变更请求 治理和支持策略
		定制的架构框架，包括： 定制的架构方法 定制的架构内容（交付物和制品） 架构原则，包括业务原则（如果事先存在） 配置和部署工具
		已经具有内容的架构资源库
输 出	经过批准的架构工作说明书，包括： 范围和约束 架构工作计划 角色和职责 风险与缓解措施 工作产品效能评测 业务案例与KPI指标
	改善的业务目标、原则和驱动力说明
	架构原则
	能力评估
	定制的架构框架，包括： 定制的架构方法 定制的架构内容（交付物和制品） 配置和部署工具
	架构愿景，包括： 经过改善的关键高层次干系人的需求 基线业务架构0.1版 基线技术架构0.1版 基线数据架构0.1版 基线应用架构0.1版 目标业务架构0.1版 目标技术架构0.1版 目标数据架构0.1版 目标应用架构0.1版
	沟通计划
	纳入到架构资源库中的新增内容

1.2.4 步骤

      在当前阶段中所要执行的各个步骤归纳如下：

• 建立架构项目
• 识别干系人、关注点和业务需求
• 确认并阐述业务目标、驱动力和约束
• 评估业务能力
• 评估业务转型准备情况
• 定义范围
• 确认并阐述架构原则，包括业务原则
• 开发架构愿景
• 定义目标架构价值主张和主要性能指标
• 明确业务转型风险和缓解措施
• 开发企业架构计划和架构工作说明书，并确保被批准