一、ADM的架构开发阶段网络
ADM方法是由一组按照架构领域的架构开发顺序而排列成一个环的多个阶段所构成。经过这些开发阶段的工做,设计师能够确认是否已经对复杂的业务需求进行了足够全面的讨论。TOGAF中最为著名的一个ADM基础结构图以下所示:架构
ADM方法被迭代式的应用在架构开发的整个过程当中、阶段之间和每一个阶段内部。在ADM的全生命周期中,每一个阶段都须要根据原始业务需求对设计结果进行确认,这也包括业务流程中特有的一些阶段。确认工做须要对企业的覆盖范围、时间范围、详细程度、计划和里程碑进行从新审议。每一个阶段都应该考虑到架构资产的重用(以往ADM迭代成果、其它框架、系统模型、行业模型等)。框架
所以,ADM便造成了3个级别的迭代概念:工具
二、ADM方法各阶段中的活动性能
ADM阶段 | ADM阶段内的活动 |
准备阶段 | 为实施成功的企业架构项目作好准备,包括定义组织机构特定的架构框架、架构原则和工具。 |
需求管理 | 完成需求的识别、保管和交付,相关联的ADM阶段则按优先级顺序对需求进行处理。 TOGAF项目的每一个阶段,都是创建在业务需求之上而且须要对需求进行确认。 |
阶段A:架构愿景 | 设置TOGAF项目的范围、约束和指望; 建立架构愿景; 定义利益相关者; 确认业务上下文环境; 建立架构工做说明书; 取得上层批准。 |
阶段B:业务架构 阶段C:信息系统架构(应用&数据) 阶段D:技术架构 |
从业务、信息系统和技术三个层面进行架构开发,在每个层面分别完成如下活动:
|
阶段E:机会和解决方案 | 进行初步实施规划,并确认在前面阶段中肯定的各类构建块的交付物形式; 肯定主要实施项目; 对项目分组并归入过渡架构; 决定途径(制造/购买/重用、外包、商用、开源); 评估优先顺序; 识别相依性。 |
阶段F:迁移规划 | 对阶段E肯定的项目进行绩效分析和风险评估; 制订一个详细的实施和迁移计划。 |
阶段G:实施治理 | 定义实施项目的架构限制; 提供实施项目的架构监督; 发布实施项目的架构合同; 监测实施项目以确保符合架构要求。 |
阶段H:架构变动管理 | 提供持续监测和变动管理的流程,以确保架构能够响应企业的需求而且将架构对于业务的价值最大化。 |
三、ADM方法的详细说明spa
在如下的表格中从目标、步骤、输入和输出几个方面对ADM环中的每一个阶段进行了分析和描述。架构设计
3.1 准备阶段设计
目标 | 步骤 |
|
|
输入 | 输出 |
|
|
3.2 阶段A——架构愿景orm
在架构愿景阶段,将启动一次架构开发过程的迭代,设置迭代工做的范围、约束和指望,建立架构愿景、验证业务上下文,建立架构工做说明书并取得你们的一致承认。blog
愿景表达了咱们对架构的指望结果,阐明重要涉众关注的问题和目标,可帮助团队关注架构的核心领域。
目标 | 步骤 |
|
|
输入 | 输出 |
|
|
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方法不可以肯定架构活动的范围,这必须由企业本身肯定。须要限定架构活动范围的缘由与如下因素有关:
选定的架构活动范围理论上应该地支持企业中的架构师高效地完成治理和整合工做。这须要一套一致的“架构分区”,确保架构师不会从事重复劳动或冲突的活动。这一样须要定义重用和多个架构分区间的服从关系。下表从四个维度对架构活动范围的限定进行了说明。
维度 | 考察 |
企业范围或焦点 | 企业最大的业务范围是什么?其中又有多少是须要架构工做聚焦的? 许多企业的规模很是大,实际上造成了一个组织单位成员的联盟,每一个成员都有本身独立的企业权利。 现代企业愈来愈突破它的传统界线,包括了一个由供应商、客户和合做伙伴造成的模糊的传统行业企业联盟。 |
架构领域 | 一个全面的企业架构描述应该包括所有四个架构领域(业务、数据、应用、技术),可是实际的资源和时间约束常常意味着没有充分的时间、资金或其它资源去设计一个自顶而下的、包含所有四个架构领域的架构描述。即便在选定的架构活动范围小于企业总体业务范围时也是这样。 |
详述垂直范围或级别 | 架构工做应该细化到第几层?怎么样的架构工做才算充分的? 架构工做和其它相关工做(系统设计、系统工程以及系统开发)的界线是什么? |
时间周期 | 架构愿景的准确时间周期是什么?它是否意味着要在这个时间期间内用详细的架构描述填充满?若是不是,那么须要定义多少个中间级别的目标架构,而且它们的时间周期是多少? |