TOGAF系列【5】原创万字长文，一篇读懂TOGAF 10 ADM架构开发方法：从4A架构设计到实施治理的完整方法

企业架构究竟应该怎么做？

很多人想到企业架构，首先想到的是业务架构、数据架构、应用架构和技术架构，也就是通常所说的4A。于是，大量工作集中在现状调研、架构建模、目标设计和差距分析上。

这些工作当然重要，但架构设计完成以后呢？

目标架构如何转化为具体建设项目？项目实施过程中，如何保证建设内容符合架构要求？如果项目为了赶进度改变了原来的设计，应该如何处理？系统上线以后，业务和技术环境发生变化，架构又如何持续调整？

这些问题如果没有解决，前面做得再好的架构设计，也可能停留在文档和图纸上。

TOGAF提供的架构开发方法（Architecture Development Method，ADM），恰恰考虑了这些问题。它覆盖了架构工作的准备、设计、实施规划、实施治理和持续变更管理。

结合TOGAF 10的体系，韩老师将架构开发方法归纳为五个方面：认识ADM、架构设计、实施规划、治理与演进、综合应用。

一、认识ADM：理解架构开发方法的整体框架

ADM是TOGAF的核心方法，用于指导企业架构的开发和生命周期管理。

它并不是一套单纯的架构设计步骤，而是覆盖架构工作全过程的方法体系。

从整体上看，ADM由准备阶段、A到H八个阶段，以及贯穿全过程的需求管理组成。

各阶段承担不同的职责：

• 准备阶段：建立企业架构能力、组织、原则和治理基础。
• A阶段：架构愿景，明确架构工作的目标、范围和方向。
• B阶段：业务架构，描述企业的业务能力和业务运行方式。
• C阶段：信息系统架构，包括数据架构和应用架构。
• D阶段：技术架构，明确支撑信息系统运行的技术基础。
• E阶段：机会与解决方案，识别实施机会，组织解决方案和工作包。
• F阶段：迁移规划，确定项目优先级、资源安排和实施路径。
• G阶段：实施治理，监督项目实施，确保建设成果符合架构要求。
• H阶段：架构变更管理，持续识别和管理架构变化。
• 需求管理：贯穿整个过程，负责架构需求的持续管理和衔接。

这里需要特别注意两个地方。

第一，准备阶段并不属于A到H八个正式阶段。它主要解决企业是否具备开展架构工作的基础条件，包括组织、原则、治理机制和架构能力建设。

第二，需求管理不是ADM最后增加的一个阶段，而是贯穿全过程的管理机制。随着架构设计和实施不断深入，需求可能持续增加、调整或发生变化，需要统一管理。

ADM也不是必须严格按照顺序执行的线性流程。企业可以根据架构工作的范围、目标和实际条件进行裁剪与迭代。

理解ADM，关键是理解它所覆盖的完整工作过程：从为什么开展架构工作，到设计什么样的架构，再到如何建设、如何治理，以及如何持续调整。

二、架构设计：从架构愿景走向4A目标架构

架构设计是ADM的核心工作。

从A阶段开始，架构团队需要明确架构工作的目标、范围、利益相关者和预期成果，形成架构愿景。

在此基础上，进入B、C、D三个阶段，开展业务架构、数据架构、应用架构和技术架构设计。

这四个架构领域通常被归纳为4A。

需要说明的是，4A是对四个架构领域的归纳，并不是TOGAF将B、C、D重新划分为四个正式阶段。TOGAF的正式划分是：B阶段业务架构、C阶段信息系统架构、D阶段技术架构。其中C阶段包含数据架构和应用架构。

1. 业务架构：企业要做什么，具备什么能力？

业务架构关注企业如何创造价值、具备哪些业务能力，以及业务活动如何组织和运行。

它是连接企业战略与信息技术建设的重要环节。

企业战略通常描述发展方向和经营目标，但这些目标如何落实到实际经营活动中，需要通过业务架构进行分解和表达。

业务架构主要关注四类内容。

业务能力

业务能力描述企业为了实现业务目标需要具备什么能力，例如客户管理、产品研发、供应链管理、营销管理和财务管理等。

业务能力相对稳定，可以作为企业分析业务现状、识别能力差距和规划数字化建设的重要基础。

价值流

价值流从客户或其他利益相关者的价值需求出发，描述企业如何通过一系列价值阶段创造和交付价值。

它关注价值如何产生、如何传递，以及不同阶段如何共同形成最终成果。

价值流帮助企业从端到端的视角理解价值创造过程。

业务流程

业务流程描述企业为了完成特定业务目标而开展的一系列活动、任务和决策。

它回答具体业务如何运行、由谁执行、按照什么规则完成。

业务能力说明企业需要具备什么能力，业务流程说明企业如何通过具体活动实现业务目标，两者相互关联，但不能混为一谈。

组织与业务信息

组织架构描述企业的组织单元、角色及其职责关系；业务信息描述业务活动涉及的信息对象及其关系。

这两类内容分别从组织责任和业务信息的角度补充业务架构。

因此，业务架构不能简单等同于组织架构，也不能只用业务流程图来表达。

在TOGAF的B阶段，架构师需要建立基线业务架构、设计目标业务架构，开展差距分析，并形成相应的架构成果。

2. 数据架构：业务需要什么信息，数据如何组织？

数据架构属于C阶段的信息系统架构。

它关注企业需要管理什么数据、数据之间存在什么关系、数据如何组织和流转，以及数据管理需要遵循哪些要求。

主要包括：

• 数据实体与数据概念：识别客户、产品、合同、订单、供应商、员工等核心业务对象。
• 逻辑数据模型：描述数据实体、属性以及实体之间的关联关系。
• 数据分布与数据流转：分析数据由哪些业务活动产生，在哪些系统中使用，以及如何在不同应用之间传递。
• 数据管理与治理要求：包括数据质量、数据标准、数据安全、数据管理责任和数据生命周期等。

数据架构不能只关注数据模型，还需要考虑数据在企业范围内的管理和使用。

在C阶段，架构师需要建立基线数据架构、设计目标数据架构，并通过差距分析识别需要解决的问题。

3. 应用架构：由哪些系统支撑业务运行？

应用架构同样属于C阶段的信息系统架构。

它关注企业需要哪些应用系统、应用系统提供什么服务、如何支撑业务能力，以及不同应用之间如何协同。

主要包括：

• 应用系统与应用组件：识别企业现有和目标应用系统，分析系统职责、功能边界及相互关系。
• 应用功能与应用服务：分析应用系统提供哪些业务功能和服务，明确其对业务活动的支撑关系。
• 应用交互与集成关系：分析应用系统之间的数据交换、服务调用和业务协作关系。
• 应用组合与优化：分析应用重复、系统依赖和建设规划，为应用整合、系统替换和平台建设提供依据。

应用架构不能简单按照现有系统菜单进行分类，应当结合业务需求和应用职责进行识别。

在C阶段，架构师需要建立基线应用架构、设计目标应用架构，并通过差距分析识别需要新增、调整、整合或退出的应用。

4. 技术架构：应用和数据依靠什么技术运行？

技术架构对应D阶段。

它关注支撑数据架构和应用架构运行的技术基础，包括计算、存储、网络、平台、基础软件和技术标准等。

主要包括：

• 计算与基础设施：服务器、计算资源、存储设备、网络设备和云基础设施。
• 平台与基础软件：操作系统、数据库、中间件、容器平台、云平台和集成平台。
• 技术标准与技术约束：统一技术标准、技术参考架构和技术选型要求。
• 技术部署与运行环境：分析应用系统的部署环境、资源组织和运行协同关系。

在D阶段，架构师需要建立基线技术架构、设计目标技术架构，并通过差距分析确定技术升级、替换和建设需求。

5. 4A之间如何形成整体？

4A不是四套相互独立的架构，它们共同描述企业从业务价值创造到信息系统支撑，再到技术运行环境的完整关系。

可以用四个问题来理解：

• 业务架构：企业要做什么，需要具备什么能力？
• 数据架构：业务需要什么信息，数据如何组织和管理？
• 应用架构：由哪些应用系统提供业务功能和信息服务？
• 技术架构：应用和数据依靠什么技术环境运行？

例如，企业希望提升客户服务能力：

业务架构需要明确客户服务涉及哪些业务能力和流程；数据架构需要定义客户、产品、订单等核心数据；应用架构需要明确客户管理、订单管理和服务管理系统如何协同；技术架构则需要提供相应的计算、存储、网络和平台支撑。

由此形成从业务目标到技术实现的完整架构链条。

需要强调的是，4A之间不是简单的单向层级关系。数据、应用和技术领域的设计结果也可能反过来影响业务方案，架构工作需要在不同领域之间反复验证和迭代。

完成4A设计后，企业需要形成基线架构、目标架构、差距分析和相应的架构定义成果，为后续实施规划提供依据。

三、实施规划：把架构设计转化为真正的建设任务

4A设计完成以后，企业得到的是一套目标架构，以及从现状到目标状态之间需要解决的问题。

但这些问题不会因为形成了架构图和设计文档就自动解决。它们需要转化为建设任务，需要明确由谁实施、投入多少资源、先做什么、后做什么，以及不同项目之间如何协同。

这就是ADM中E、F两个阶段的主要工作。

E阶段：识别实施机会，组织解决方案

E阶段需要整合业务、数据、应用和技术架构的差距分析结果，识别实施机会，分析解决方案，组织工作包，并考虑过渡架构。

重点回答：

• 哪些架构差距需要优先解决？
• 哪些建设任务可以整合？
• 哪些能力可以通过共享平台实现？
• 不同工作包之间存在什么依赖关系？
• 如何划分不同阶段的目标状态？

例如，多个业务领域都提出了数据共享需求。如果分别建设独立的数据共享平台，可能产生新的重复建设。

这时就需要从企业整体架构出发，分析共性需求、共享能力和实施机会，形成更加合理的解决方案。

F阶段：制定可执行的迁移计划

E阶段形成了初步实施方案，F阶段需要进一步评估工作包的业务价值、成本、风险、资源需求和实施优先级。

重点回答：

• 哪些项目应该优先实施？
• 哪些项目可以并行开展？
• 哪些项目存在前后依赖？
• 如何安排过渡架构？
• 需要投入多少资源？
• 如何安排项目里程碑？

最终形成实施与迁移计划，明确从当前架构走向目标架构的具体路径。

这里需要特别强调：E、F阶段不是简单地把架构差距整理成项目清单，而是要建立架构目标、建设任务、投资安排和项目实施之间的联系。

架构设计解决目标问题，实施规划解决实现路径问题。

如果缺少这一环节，架构就很难进入企业的投资决策和项目建设过程。

四、治理与演进：企业架构落地的关键核心保障

在企业架构实践中，很多工作集中在4A设计，实施规划也往往能够形成一定成果，但到了真正的项目建设和后续运行阶段，架构治理经常被弱化。

这也是很多企业架构项目面临的现实问题：

架构设计时要求统一技术标准，项目建设时却各自选择技术；架构规划时明确了系统整合方向，实际项目仍然按照部门需求独立建设；架构评审时提出了问题，项目上线以后却没有持续跟踪。

时间一长，目标架构与实际建设逐渐脱节，架构成果也就失去了应有的指导作用。

因此，实施和治理并不是4A设计之后可有可无的附加工作。它们是企业架构从设计走向落地的关键核心保障。

TOGAF通过G阶段和H阶段，分别处理架构实施治理和架构变更管理。

1. G阶段：实施治理，确保项目按照架构要求建设

G阶段的核心任务，是确保实施项目符合批准的企业架构。

这需要架构团队真正进入项目建设过程，而不是等项目结束以后再检查架构文档。

主要工作包括：

明确实施范围和优先级

与项目管理团队共同确认项目范围、实施优先级和架构要求，明确项目需要交付什么。

落实实施资源和技能

确认项目是否具备所需的人员、技术能力、开发方法和工具，确保架构方案具备实际交付条件。

指导解决方案部署

将企业架构要求传递到项目设计和开发过程中，指导解决方案设计，确保项目与目标架构保持一致。

建立架构合同

通过架构合同明确架构要求、实施责任、交付目标和遵从约束，建立架构治理方与项目实施方之间的正式约定。

开展架构遵从性审查

对照架构标准、架构原则和项目约定，检查实施成果是否符合架构要求。

发现偏差后，需要分析影响，采取整改、例外许可或变更处理等措施。

完成实施后评审

项目交付以后，检查实际成果是否达到预期目标，业务和IT服务是否正常运行，并形成评审记录。

这里需要特别强调架构遵从性审查。

企业架构如果不能进入项目建设过程，就很难对实际建设活动形成有效约束。架构治理的目的也不是增加审批环节，而是让架构要求在项目设计、开发、部署和交付过程中得到落实。

2. H阶段：架构变更管理，保证架构持续适应企业发展

项目上线并不意味着架构工作结束。

企业战略、业务模式、组织结构和技术环境都可能发生变化，原有架构可能逐渐无法满足新的业务需求。

H阶段关注架构变化的识别、分析、决策和实施。

主要工作包括：

• 建立价值实现流程，跟踪架构投入所带来的业务价值。
• 部署监控工具，持续监控业务环境、技术环境和架构运行表现。
• 管理架构风险，识别可能影响架构持续运行的因素。
• 开展架构变更分析，判断当前架构是否仍然满足业务和绩效要求。
• 制定变更需求，明确需要调整的架构内容和预期目标。
• 管理架构治理流程，对变化请求和例外事项进行审议。
• 启动变更实施流程，将批准的变化纳入架构维护和实施工作。

H阶段还需要区分维护性变化和重大架构变化。

对于现有架构范围内的维护性变化，可以按照既定治理机制进行更新；如果变化涉及重大架构方向调整，就可能需要提出新的架构工作请求，启动新一轮ADM。

G阶段和H阶段解决的是两个不同的问题：

G阶段关注项目实施是否符合架构；H阶段关注企业架构是否需要随着环境变化而调整。

两者共同保障架构从设计、实施到运行的持续有效。

如果说4A设计决定了企业架构应该建设成什么样，那么实施规划决定了如何建设，实施治理决定了建设结果是否符合架构，变更管理则决定了架构能否持续适应企业发展。

这也是为什么企业架构不能只重视设计，而忽视实施和治理。

五、华为实践：企业架构如何从规划走向治理？

前面介绍了TOGAF ADM的整体方法。可能有人会问：这些方法在真实企业中是如何运作的？

华为的企业架构实践提供了一个值得研究的案例。

1. 从4A架构设计走向统一的企业架构

在2023年The Open Group架构师交流大会上，华为企业架构演进实践。

提到，企业架构通常包括业务架构、信息架构、应用架构和技术架构四个方面。

在早期实践中，这四个领域存在一定程度的割裂：业务架构独立于信息架构，应用架构与技术架构也没有充分协同。

这会带来一个实际问题：不同专业都在开展架构工作，但没有围绕同一个业务目标形成整体方案。

为解决这一问题，华为推动架构能力的组合和协同，并通过工具管理相关架构能力。支持围绕业务场景组织能力、流程、数据和应用，使不同业务场景能够复用已有能力，并根据自身特点进行差异化扩展。

2. 建立架构管控机制：避免项目各自建设

架构设计和实施规划形成之后，还需要解决一个问题：如何保证各个项目真正按照企业整体架构开展建设？

在上述华为从业者的实践回顾中，介绍了其企业架构管控机制。

公司层面设有企业架构委员会（EAC），负责对跨领域业务变革需求和解决方案进行架构评审，为变革决策团队提供专业意见。

EAC之下设有四个资深架构专家组（SAG），分别对应：

• 业务架构专家组（BA-SAG）。
• 信息架构专家组（IA-SAG）。
• 应用架构专家组（AA-SAG）。
• 技术架构专家组（TA-SAG）。

这些专家组参与专业领域的架构原则、标准和方案评审。

在业务领域层面，还设有变革需求及架构管理团队（RAMT），负责推动领域内架构管理和变革需求的衔接。

这一机制体现出几个值得关注的特点：

第一，公司层面负责整体架构原则和跨领域架构协同，避免各领域各自建设。

第二，专业架构专家组负责领域级专业评审，保证架构方案具有专业性。

第三，领域级架构管理团队负责把公司级要求与实际业务需求联系起来。

这与ADM强调的架构治理思想相通：架构需要有明确的责任主体、专业评审机制和正式决策机制，不能只依靠架构师个人推动。

六、注意事项：

理解了ADM各阶段，并不意味着企业就能直接照搬这套流程。

TOGAF提供的是通用架构开发方法，企业还需要结合自身组织、业务、治理和项目管理机制进行裁剪。

实际应用中，需要重点关注四个方面。

1. 需求管理贯穿全过程

需求管理不是ADM的第九个阶段，而是贯穿各阶段的持续管理机制。

它负责需求识别、记录、基线管理、变更监控和影响评估，保证需求在不同架构阶段之间持续流转。

2. 架构成果需要前后衔接

架构愿景、架构定义文档、架构路线图、实施与迁移计划、架构合同等成果不是孤立存在的。

前一阶段形成的成果，会成为后一阶段开展工作的依据，并在后续过程中不断完善。

3. 架构设计必须进入项目实施

架构成果需要转化为项目范围、建设任务和实施要求，并通过架构治理机制进行持续检查。

架构师也需要与业务部门、项目管理团队和技术团队建立协同关系，让架构真正进入企业建设过程。

4. 建立企业架构运行机制

企业需要明确架构组织、职责分工、工作流程、架构标准和资产管理机制。

通过组织、流程、资产和项目运行机制的协同，让ADM融入企业日常管理和项目建设。

最终，企业架构不再只是某个项目中的设计工作，而是能够持续支撑企业战略、业务发展、数字化建设和组织变革的一项管理能力。

企业架构的成果不应止步于一套设计方案，而应落实到企业的项目建设、业务运行和持续变革之中。

七、原创100页PDF培训参考资料：