https://blog.csdn.net/watermelonbig/article/details/77620847
1、ADM的架构开发阶段
ADM方法是由一组按照架构领域的架构开发顺序而排列成一个环的多个阶段所构成。通过这些开发阶段的工作,设计师可以确认是否已经对复杂的业务需求进行了足够全面的讨论。TOGAF中最为著名的一个ADM基础结构图如下所示:
![](https://i-blog.csdnimg.cn/blog_migrate/8cf0607a93b34226bbb27235f7a4d94f.jpeg)
ADM方法被迭代式的应用在架构开发的整个过程中、阶段之间和每个阶段内部。在ADM的全生命周期中,每个阶段都需要根据原始业务需求对设计结果进行确认,这也包括业务流程中特有的一些阶段。确认工作需要对企业的覆盖范围、时间范围、详细程度、计划和里程碑进行重新审议。每个阶段都应该考虑到架构资产的重用(以往ADM迭代成果、其它框架、系统模型、行业模型等)。
因此,ADM便形成了3个级别的迭代概念:
- 基于ADM整体的迭代,用一种环形的方式来应用ADM方法,表明了在一个架构开发工作阶段完成后会直接进入随后的下一个阶段。
- 多个开发阶段间的迭代,例如在完成了技术架构阶段的开发工作后又重新回到业务架构开发阶段。
- 在一个阶段内部的迭代,TOGAF支持基于一个阶段内部的多个开发活动,对复杂的架构内容进行迭代开发。
2、ADM方法各阶段中的活动
ADM阶段 | ADM阶段内的活动 |
准备阶段 | 为实施成功的企业架构项目做好准备,包括定义组织机构特定的架构框架、架构原则和工具。 |
需求管理 | 完成需求的识别、保管和交付,相关联的ADM阶段则按优先级顺序对需求进行处理。 TOGAF项目的每个阶段,都是建立在业务需求之上并且需要对需求进行确认。 |
阶段A:架构愿景 | 设置TOGAF项目的范围、约束和期望; 创建架构愿景; 定义利益相关者; 确认业务上下文环境; 创建架构工作说明书; 取得上层批准。 |
阶段B:业务架构 阶段C:信息系统架构(应用&数据) 阶段D:技术架构 | 从业务、信息系统和技术三个层面进行架构开发,在每一个层面分别完成以下活动:
|
阶段E:机会和解决方案 | 进行初步实施规划,并确认在前面阶段中确定的各种构建块的交付物形式; 确定主要实施项目; 对项目分组并纳入过渡架构; 决定途径(制造/购买/重用、外包、商用、开源); 评估优先顺序; 识别相依性。 |
阶段F:迁移规划 | 对阶段E确定的项目进行绩效分析和风险评估; 制订一个详细的实施和迁移计划。 |
阶段G:实施治理 | 定义实施项目的架构限制; 提供实施项目的架构监督; 发布实施项目的架构合同; 监测实施项目以确保符合架构要求。 |
阶段H:架构变更管理 | 提供持续监测和变更管理的流程,以确保架构可以响应企业的需求并且将架构对于业务的价值最大化。 |
3、ADM方法的详细说明
在以下的表格中从目标、步骤、输入和输出几个方面对ADM环中的每个阶段进行了分析和描述。
3.1 准备阶段
目标 | 步骤 |
|
|
输入 | 输出 |
|
|
3.2 阶段A——架构愿景
在架构愿景阶段,将启动一次架构开发过程的迭代,设置迭代工作的范围、约束和期望,创建架构愿景、验证业务上下文,创建架构工作说明书并取得大家的一致认可。
愿景表达了我们对架构的期望结果,阐明重要涉众关注的问题和目标,可帮助团队关注架构的核心领域。
目标 | 步骤 |
|
|
输入 | 输出 |
|
|
3.3 阶段B——业务架构
在业务架构阶段,将开发一个支持架构愿景的业务架构。架构愿景中概括的基线和目标业务架构将在此被细化,从而使它们可以作为技术分析的有用输入。业务过程建模、业务目标建模和用例建模是用于生成业务架构的一些技术,这又包含了所期望状态的差距分析。
本阶段的核心内容包括组织如何满足业务目标;企业静态特征(业务目标、业务组织结构、业务角色);企业动态特征(流程、功能、服务)。
目标 | 步骤 |
|
|
输入 | 输出 |
|
|
3.4 阶段C——信息系统架构
在信息系统架构设计阶段,确定主要的信息类型和处理这些信息的应用系统。在本阶段有两个主要的步骤,数据架构设计和应用架构设计,二者既可以依次开发,也可以并行开发。核心内容为:IT系统如何满足企业的业务目标;信息以及信息之间的关系;应用以及应用之间的关系。
3.4.1 数据架构
目标 | 步骤 |
定义业务运行所需的数据源和数据类型。 |
|
输入 | 输出 |
|
|
3.4.2 应用架构
目标 | 步骤 |
定义处理数据并支撑业务运行所需的各种应用系统。 |
|
输入 | 输出 |
|
|
3.5 阶段D——技术架构
在技术架构阶段,完成对IT系统基础服务设施的设计,定义了架构解决方案的物理实现,包括硬件、软件和通信技术。
目标 | 步骤 |
开发一个目标技术架构,并以此作为后续的实施和迁移计划的基础。 将应用架构中定义的各种应用组件映射为相应的技术组件, 这些技术组件代表了各种可以从市场或组织内部获得的软件和硬件组件。 |
|
输入 | 输出 |
|
|
3.6 机会及解决方案
这是第一个直接关注实施的阶段,该阶段主要描述确定目标架构交付物(项目、程序或文件)的过程。
目标 | 步骤 |
|
|
输入 | 输出 |
|
|
3.7 阶段F——迁移规划
该阶段通过制订一个详细的实现和迁移计划完成从基线架构向目标架构的转变。
目标 | 步骤 |
|
|
输入 | 输出 |
|
|
3.8 阶段G——实施治理
该阶段定义了实施项目的架构约束,提供项目构建的架构监督,产生一个架构契约。
目标 | 步骤 |
|
|
输入 | 输出 |
|
|
3.9 阶段H——架构变更管理
该阶段确保能够以一种可控制的方式对架构的改变进行管理。
目标 | 步骤 |
|
|
输入 | 输出 |
|
|
3.10 需求管理
架构需求管理适用于ADM的所有阶段,这是一个动态的过程,完成对企业需求的识别、存储并把它们插入或取出相应的ADM阶段。需求管理是ADM流程的中心。处理需求变化的能力对于ADM过程是非常重要的,架构通过其天然处理不确定性和变化的能力在涉众诉求之间架起桥梁并交付一个可实践的解决方案。
目标 | 步骤 |
|
|
输入 | 输出 |
|
|
3.11 建立架构活动的范围
ADM方法不能够确定架构活动的范围,这必须由企业自己确定。需要限定架构活动范围的原因与以下因素有关:
- 创建架构的团队所具备的组织权力;
- 需要在架构中实现的目标和干系人的诉求;
- 可利用的人、资金以及其它资源。
选定的架构活动范围理论上应该地支持企业中的架构师高效地完成治理和整合工作。这需要一套一致的“架构分区”,确保架构师不会从事重复劳动或冲突的活动。这同样需要定义重用和多个架构分区间的服从关系。下表从四个维度对架构活动范围的限定进行了说明。
维度 | 考察 |
企业范围或焦点 | 企业最大的业务范围是什么?其中又有多少是需要架构工作聚焦的? 许多企业的规模非常大,实际上形成了一个组织单位成员的联盟,每个成员都有自己独立的企业权利。 现代企业越来越突破它的传统界线,包括了一个由供应商、客户和合作伙伴形成的模糊的传统行业企业联盟。 |
架构领域 | 一个全面的企业架构描述应该包括全部四个架构领域(业务、数据、应用、技术),但是实际的资源和时间约束经常意味着没有充分的时间、资金或其它资源去设计一个自顶而下的、包含全部四个架构领域的架构描述。即使在选定的架构活动范围小于企业整体业务范围时也是这样。 |
详述垂直范围或级别 | 架构工作应该细化到第几层?怎么样的架构工作才算充分的? 架构工作和其它相关工作(系统设计、系统工程以及系统开发)的界线是什么? |
时间周期 | 架构愿景的准确时间周期是什么?它是否意味着要在这个时间期间内用详细的架构描述填充满?如果不是,那么需要定义多少个中间级别的目标架构,并且它们的时间周期是多少? |