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

1.2 架构愿景（Architecture Vision）

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

1.2.1 目标

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

1.2.2 方法

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

创建架构愿景

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

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

业务情景

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

1.2.3 输入与输出

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

1.2.4 步骤

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

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