架构推进方法论-开发方法

架构推进方法论-开发方法

一、架构开发方法概述

ADM方法是一种开发和管理复杂组织体架构生命周期的典型方法，它综合集成了复杂组织体架构的所有元素及可用的架构资产，以满足组织的业务和IT需要，现已在国际上被广泛采用。本文重点介绍ADM方法。

二、架构开发方法阶段

ADM方法为开发架构中涉及的不同阶段和步骤定义了一个推荐的顺序，ADM的基本结构见图1。

图1 ADM架构开发周期

ADM方法在使用过程中通常需要在ADM整个周期、ADM周期的各阶段之间以及ADM周期的各阶段内部进行迭代。对于ADM的每轮迭代，必须按照以下因素采取新的决策：

待定义的复杂组织体覆盖范围的广度

待定义的细节层级

目标时间区间范围，包括任何中间时间区间的数量和范围

更大程度利用架构资产，包括：

        复杂组织体内以往的ADM周期迭代所创建的资产

        在行业其他地方可用的资产（其他的框架、系统模型等）

这些决策均应基于对资源和能力可用性的实际评估以及实际期望从选定的架构工作范围内增加到复杂组织体的价值中。

三、架构开发方法详述

本部分重点介绍ADM周期中各阶段的目标、输入、步骤与输出。

3.1 预备阶段

预备阶段为复杂组织体实现成功的架构项目做好准备，包括定义组织特定的架构框架和架构原则。预备阶段的目标、输入、步骤与输出见图2。

图2 预备阶段的目标、输入、步骤与输出

3.2 阶段A：架构愿景

阶段A：架构愿景用于明确EA愿景，确定项目范围、约束和期望，定义利益攸关者，生成架构工作描述，获得利益攸关者的普遍认同。阶段A的目标、输入、步骤与输出见图3。

图3 阶段A的目标、输入、步骤与输出

3.3 阶段B：业务架构

阶段B：业务架构选取参考模型、视图和工具进行基线业务架构及目标业务架构的描述与定义。阶段B的目标、输入、步骤与输出见图4。

图4阶段B的目标、输入、步骤与输出

3.4 阶段C：信息系统架构

阶段C：信息系统架构选取参考模型、视图和工具进行基线数据架构和应用架构及目标数据架构和应用架构的描述与定义。本阶段分为两个部分，这两个部分可顺序开展或同时开展：

数据架构

应用架构

阶段C中数据架构的目标、输入、步骤与输出见图5。

图5 阶段C-数据架构的目标、输入、步骤与输出

阶段C中应用架构的目标、输入、步骤与输出见图6。

图6 阶段C-应用架构的目标、输入、步骤与输出

3.5 阶段D：技术架构

阶段D：技术架构选取参考模型、视图和工具进行基线技术架构及目标技术架构的描述与定义。阶段D的目标、输入、步骤与输出见图7。

图7 阶段D的目标、输入、步骤与输出

3.6 阶段E：机会和解决方案

阶段E：机会和解决方案描述识别各种交付载体（项目、项目群或项目谱系）的流程，以有效地交付此前各阶段识别的目标架构。阶段E的目标、输入、步骤与输出见图8。

图8 阶段E的目标、输入、步骤与输出

3.7 阶段F：迁移规划 

阶段F：迁移规划描述如何通过最终确定一个详细的实施和迁移计划将基线架构迁移至目标架构。阶段F的目标、输入、步骤与输出见图9。

图9 阶段F的目标、输入、步骤与输出

3.8 阶段G：实施治理

阶段G：实施治理定义对实施项目的架构化监督，指导构建过程并创建架构合同。阶段G的目标、输入、步骤与输出见图10。

图10 阶段G的目标、输入、步骤与输出

3.9 阶段H：架构变更管理

阶段H：架构变更管理确保对架构的变更以可控的方式进行管理。阶段H的目标、输入、步骤与输出见图11。

图11 阶段H的目标、输入、步骤与输出

3.10 需求管理 

如图1所示，需求管理位于ADM周期的中心，ADM由需求管理流程持续驱动。需求管理是一个动态流程，通过该流程可识别、存储复杂组织体的需求及其后续变更，并在相关的ADM阶段和ADM周期之间进行输入和输出。

处理需求变更的能力是至关重要的。架构在本质上是处理不确定性和变革的一项活动——是介于利益攸关者所渴望的因素与可规定和设计为解决方案的因素之间的桥梁。

需求管理的目标、输入、步骤与输出见图12。

图12 需求管理的目标、输入、步骤与输出

四、界定架构的范围

ADM架构开发方法定义了在组织内部开发复杂组织体架构涉及的各种阶段和步骤，但ADM无法确定复杂组织体架构需要开发的范围，范围需要结合组织自身的情况进行确定。

有多个原因约束（或限制）待执行架构活动的范围，大部分原因与下面的限制有关：

架构创建团队的组织权限

在该架构内所涉及的目的和利益攸关者关注点

人员、财务和其他资源的可用性

在理想情况下，架构活动选用的范围应允许对所有架构师在该复杂组织体范围内的工作进行有效治理和综合。这就需要一系列协调一致的“架构划分”，确保架构师不会从事重复的或冲突的活动。这也需要定义各架构划分之间的复用和合规性关系。

典型情况下，使用四个维度来定义并界定架构范围：

广度：复杂组织体的完整扩展广度是什么，本架构工作会涉及该扩展广度的哪一部分？许多复杂组织体非常庞大，实际上包括一个由若干组织单元构成的联盟，这些组织单元在其自身范围内就可以被视为复杂组织体。现代复杂组织体日益延伸到传统边界以外，包括一种由传统业务复杂组织体与供应商、客户和合作伙伴结合在一起的模糊组合。

深度：架构工作应该进行到什么样的细节层级？多少个架构是“足够”的？架构工作和其他相关活动（系统设计、系统工程、系统开发）之间的适当界限是什么？

时间区间：什么是描绘架构愿景所需的时间区间？在详细架构描述中涵盖同一时区间是否有意义（就现实性和资源而言）？如果没有意义，将定义多少个过渡架构？它们各自的时间区间是什么？

架构域：一个完整的复杂组织体架构描述应当包括全部四个架构域（业务、数据、应用、技术），但是资源和时间约束的现实情况往往意味着没有足够的时间、资金或资源来建立一个涵盖所有四个架构域的自顶向下的全面架构描述，即便是选定的复杂组织体范围比整个复杂组织体的总体范围要小得多。

通常，首先在广度、深度和时间方面表达架构的范围。一旦理解了这些维度，可选定适于正在应对的问题的适当架构域组合。