Day31-46｜12.3.1 ADM 架构开发方法：以迭代治理形成企业架构与项目落地路线

一、教材定位

本节进入《系统架构设计师教程（第2版）》第12.3节“信息系统架构设计方法”，主题是 ADM（Architecture Development Method，架构开发方法）。前面学习了信息系统总体框架、架构风格、架构分类和一般原则，本节开始讨论如何系统地开展架构开发：从准备和愿景开始，逐步形成业务、数据、应用和技术架构，再推进机会、迁移、实施治理和变更管理。

ADM 的价值在于把“架构设计”从一次性的画图活动，转化为有阶段、有输入输出、有利益相关者参与、有决策记录和有治理闭环的过程。软考高级案例和论文常考架构开发流程、基线与目标架构、差距分析、迁移规划、架构治理和变更管理。答题时不能只背阶段名称，要说明每个阶段解决什么问题、产出什么、如何与项目和组织决策衔接。

二、ADM 的基本思想

ADM 是一种面向企业架构开发的迭代方法。它通常以架构愿景为牵引，围绕业务架构、信息系统架构和技术架构逐步细化，并通过机会与解决方案、迁移规划、实施治理和架构变更形成闭环。

ADM 的核心思想包括：

1. 从业务战略和利益相关者目标出发，而不是先选技术。
2. 先形成架构愿景和范围，再逐步深化各架构域。
3. 现状架构与目标架构并重，通过差距分析识别改造任务。
4. 架构开发与项目管理、风险管理、需求管理和变更管理协同。
5. 架构不是一次交付物，而是在实施和变化中持续更新。

三、ADM 的典型阶段

ADM 常以预备阶段、架构愿景阶段、业务架构阶段、信息系统架构阶段、技术架构阶段、机会与解决方案阶段、迁移规划阶段、实施治理阶段和架构变更管理阶段组成，并由需求管理贯穿全过程。不同资料对名称或编号可能略有差异，考试时应结合题干使用，但阶段逻辑基本一致。

四、预备阶段

1. 建立架构能力

企业需要明确架构组织、角色、职责、评审机制、工具、建模语言、文档模板和参考架构。架构委员会负责重大原则、标准、例外和投资决策；领域架构师负责业务、数据、应用和技术域；项目架构师负责将企业原则落实到项目。

2. 制定架构原则

原则包括业务优先、数据权威、标准接口、安全内建、复用优先、可演进和合规等。每条原则要说明目的、适用范围、例外流程和验证方式，不能只有口号。

3. 识别现有资产

盘点业务能力、应用、数据、技术、接口、合同、人员和债务，建立资产目录和基线。没有现状基线，目标架构和迁移路线就缺乏依据。

五、架构愿景阶段

1. 明确范围和目标

确定组织范围、业务域、时间范围、预算、关键约束和预期收益。范围过大可能无法在周期内形成结果，范围过小又可能解决不了跨域问题。

2. 识别利益相关者

包括高层、业务负责人、用户、项目经理、架构师、运维、安全、数据负责人、供应商和监管方。不同角色关注价值、成本、体验、风险、可维护性和合规，架构愿景要协调冲突。

3. 形成架构愿景

愿景用较高层次描述目标能力、主要变化、质量目标、原则和价值，不需要一开始就确定所有组件。可以使用能力地图、上下文图、目标场景和初步蓝图表达。

4. 取得批准

应明确决策人、验收指标、资源和下一阶段授权。没有利益相关者承诺，架构研究很容易停留在文档，无法进入项目和预算。

六、业务架构阶段

1. 描述业务基线

分析当前组织、能力、流程、角色、产品、规则和外部协作，识别痛点、重复、人工环节和风险。既要了解正式流程，也要发现实际运行中的“影子流程”和人工补偿。

2. 设计目标业务架构

根据战略目标设计目标能力、流程、组织协同、规则和服务。目标架构不能只画理想流程，要考虑法规、人员技能、分支差异、系统能力和实施成本。

3. 差距分析

比较基线与目标，识别新增、修改、合并、替换和退出的能力。将差距转化为候选项目、数据治理任务、组织变革和技术改造，并评估依赖和风险。

七、信息系统架构阶段

信息系统架构通常包含数据架构和应用架构。

1. 数据架构

确定数据实体、主数据、信息生命周期、数据流、数据权威、存储和共享。数据架构要回应业务目标，例如统一客户、打通订单、提高质量或支持分析。要区分现状数据重复、质量问题和目标数据治理。

2. 应用架构

确定应用、服务、功能、接口、交互、复用和部署边界。应用划分要以业务能力、数据所有权、变化频率和团队责任为依据，不应只按现有部门或代码包切分。

3. 应用和数据协同

应用架构与数据架构必须互相验证。一个业务能力需要哪些数据？数据由哪个系统产生？应用之间通过什么契约共享？数据迁移、同步和分析如何实现？如果只画应用框图，不说明数据流和权威，架构仍不完整。

八、技术架构阶段

1. 技术基线

盘点现有服务器、网络、数据库、中间件、操作系统、云资源、安全设备、监控和研发平台，识别版本、容量、单点、漏洞和供应商依赖。

2. 目标技术架构

根据数据和应用需求选择部署、计算、网络、存储、消息、缓存、容器、云边协同和安全方案。技术选型要说明质量属性、组织能力、成本、兼容和退出策略。

3. 技术标准

建立推荐技术、禁止技术、版本、接口、开发、测试、安全和运维标准。标准要支持例外，例外应有期限和风险控制，避免阻碍合理创新。

九、机会与解决方案阶段

1. 识别实施机会

将架构差距转化为项目、平台、数据治理、组织变革和基础设施建设机会。可按业务价值、风险、紧迫性、依赖和实施难度排序。

2. 形成方案组合

候选方案可能包括继续维护、改造、替换、整合、购买、云化、外包、试点或新建。要比较成本、收益、风险、时间、资源和供应商锁定，不要只比较功能。

3. 定义架构构建块

将稳定共性能力抽象为可复用构建块，如身份、主数据、消息、流程、文件、审计、监控和数据平台；将业务差异留在领域应用中，避免过度平台化。

十、迁移规划阶段

1. 建立迁移路线图

确定阶段、里程碑、依赖、预算、资源、试点和退出条件。路线图要包括数据迁移、接口过渡、用户培训、组织变更和运行切换，不能只列技术项目。

2. 迁移策略

常见策略包括直接替换、并行运行、旁路建设、逐步剥离、数据同步、双读、双写、适配层和区域灰度。高风险核心系统通常采用渐进路线，低风险外围功能可以快速替换。

3. 风险和回退

每一阶段要明确数据回退、业务回退、接口回退、用户回退和版本回退。迁移前要进行演练、备份、对账和容量验证；上线后要监控业务指标和技术指标。

十一、实施治理阶段

实施治理保证项目交付与已批准的架构一致。架构团队要参与需求、设计、技术选型、接口、数据、测试、上线和变更评审，检查关键原则和质量属性是否落实。

如果项目因工期、供应商或现场条件需要偏离架构，应提交例外申请，说明原因、影响、补偿措施和期限。治理不是阻止变化，而是让变化被看见、被决策和可追踪。

十二、架构变更管理阶段

业务战略、法规、技术、市场、组织和风险都会变化。变更管理要收集触发因素，评估对业务、数据、应用、技术、安全、成本和路线图的影响，决定局部调整、重新规划或启动新一轮 ADM。

1. 变更分类

可以分为微小配置变化、项目级变化、跨域架构变化和企业战略变化。不同等级需要不同评审、授权和文档。

2. 持续架构

总体架构应有版本、基线、目标、过渡和已退役状态。每次重大变化都更新架构仓库、标准、资产和项目约束，避免文档与实际系统脱节。

十三、需求管理的贯穿作用

需求管理连接所有 ADM 阶段：收集和分类需求，识别影响的架构域，追踪到目标、构建块、项目和测试；新需求或变更出现时，评估是否修改业务、数据、应用、技术和迁移计划。

需求要包括功能、质量、约束、法规、数据、接口和迁移需求。需求之间可能冲突，例如强一致、低时延、低成本和高可用不能无限同时满足。架构师要记录优先级、假设、权衡和确认人。

十四、ADM 的交付物与追踪

交付物要保持需求、目标、项目和测试的追踪关系。文档越多不代表架构越成熟，关键是能够支持决策和实施。

十五、案例分析：集团客户平台的 ADM 实施

某集团准备建设统一客户平台，目标是整合客户主数据、营销、服务和渠道。现有各事业部系统独立，客户编码不一致，项目组希望直接购买一个新 CRM 全量替换旧系统。

问题一：如何按 ADM 推进？

参考答案：预备阶段建立集团架构治理、数据标准、项目角色和评审机制；愿景阶段明确统一客户、提升服务和营销协同目标，识别事业部、客服、销售、数据和合规利益相关者；业务阶段梳理客户服务、营销和组织流程，设计统一能力和差异配置；数据架构明确客户主数据权威、编码、质量和迁移；应用架构设计 CRM、渠道、营销、服务和旧系统接口；技术架构确定云、API、消息、身份、数据平台和安全；机会阶段比较全量替换、渐进改造和平台整合；迁移阶段按事业部灰度、数据清洗、对账和回退；实施阶段进行架构合规和例外治理；变更阶段持续评估新业务和法规。

问题二：为什么不建议直接全量替换？

参考答案：旧系统承载隐含业务规则、历史客户和事业部差异，全量替换存在数据丢失、流程遗漏、用户适应、接口中断和业务连续性风险；客户主数据问题还没有治理，直接迁移会把错误带入新系统。应先建立数据标准和适配层，选择低风险事业部试点，逐步迁移和验证。

问题三：如何判断某阶段可以进入下一阶段？

参考答案：愿景阶段要有目标和资源承诺；业务阶段要确认流程和差异；数据阶段要通过质量、编码和对账验证；应用阶段要完成接口契约和关键场景原型；技术阶段要通过性能、安全和可用性验证；迁移阶段要完成演练、培训、回退和上线条件检查。每个阶段都应有明确验收指标和责任人。

十六、综合知识练习

题1

ADM 与一次性架构设计有什么区别？

参考答案：ADM 是有阶段、有输入输出、有利益相关者、有治理和变更闭环的迭代过程，架构在实施和变化中持续更新；一次性设计通常只形成静态方案，难以应对需求、组织和技术变化。

题2

为什么业务架构应先于技术架构？

参考答案：技术选择应服务业务能力、流程、质量和约束。先确定业务目标和边界，才能判断数据、应用、部署和技术需求；先选技术容易把业务问题强行适配到技术框架中。

题3

机会与解决方案阶段主要解决什么问题？

参考答案：将架构差距转化为可实施的项目、平台和变革方案，比较替换、改造、整合、购买和云化等选项，形成构建块、项目组合和实施优先级。

题4

架构治理为什么需要例外管理？

参考答案：现实项目受工期、供应商、遗留系统和现场条件影响，完全禁止偏离不现实；例外管理可以让偏离被说明、评估、批准、补偿并设置期限，避免临时方案永久化和架构失控。

十七、论文写作素材

论文可以围绕“基于 ADM 的企业信息系统架构建设”展开。按预备、愿景、业务、数据/应用、技术、机会、迁移、实施治理和变更管理组织正文，重点说明每个阶段的输入、决策和输出，以及如何把架构蓝图转化为项目。

可使用如下段落：

“在项目中，我采用迭代式 ADM 方法推进架构。预备阶段建立架构治理、标准和资产基线；愿景阶段明确业务目标、范围、利益相关者和验收指标；业务阶段梳理能力与流程，信息系统阶段确定主数据、应用边界和集成方式，技术阶段评估云、数据库、消息和安全平台；随后通过差距分析形成项目组合和迁移路线，采用试点、并行、灰度、对账和回退控制实施风险。上线后通过架构合规评审、运行指标和变更管理维护持续架构，确保目标方案没有停留在设计文档中。”

十八、今日复盘

1. ADM 将企业架构开发组织为准备、愿景、业务、信息系统、技术、机会、迁移、治理和变更等阶段。
2. 每个阶段都要有明确目标、输入、输出、利益相关者和决策依据。
3. 业务、数据、应用和技术架构应逐步深化，并通过差距分析连接到项目和路线图。
4. 实施治理和变更管理保证架构能够落地并持续适应组织和技术变化。
5. 需求管理贯穿全过程，负责追踪、冲突处理、优先级和架构影响分析。
6. 案例和论文要写出阶段逻辑、交付物、治理、迁移和验证，而不是只背 ADM 名称。

本节的核心结论是：ADM 的价值不在于增加流程，而在于把架构决策放到正确的时间、由正确的角色作出，并通过基线、目标、差距、路线图和治理把战略逐步转化为可运行的系统。