本期书目

• 书名：《TOGAF9.2口袋书》

• 作者：The Open Group

• 简要介绍：这是TOGAF 9.2官方的工具书，本篇内容主要是对B站《TOGAF9.2企业架构框架教程》学习及口袋书的对照整理而成。距离公众号发表的第一篇关于TOGAF 9.2学习笔记（一）已经过去了2年，在这里说声抱歉。    由于本人才疏学浅，整理的内容中如有不对的地方，还望批评指正。

阅读笔记

1

TOGAF全景概览

TOGAF 的定义

TOGAF 是the open group architecture framework的简称，意思是开放群组架构框架，这个名称可以拆成2部分来看：1. 怎么做架构？（使用）架构框架；2. 什么样的组织在推行这个框架？开放群组。总体来说，TOGAF是一种标准的、开放的、具有业界共识的企业架构框架（The TOGAF Standard, Version 9.2 A Pocket Guide, Chapter 1, Introduction），它提供了方法和工具，来帮助企业或组织来设计、规划、实施和治理其架构。

TOGAF的发展历史

TOFAG的发展历程可总结为以下几个阶段：

一：起源

1980年代中期：企业架构的概念开始形成，IBM和其他公司及大学开始探索构建企业架构的方法。

1986年：美国国防信息系统局 (DISA) 开始开发 TAFIM (Technical Architecture Framework for Information Management)，这是TOGAF早期版本的基础。

二：诞生

1991年：TAFIM的第一版草稿完成。

1995年：TOGAF的第一个版本发布，它是基于TAFIM并由The Open Group开发。

三：成熟和迭代

1995年至2009年：TOGAF经历了多个版本的迭代和发展，逐步完善其架构开发方法（Architecture Development Method, ADM）和相关指南。

2009年：TOGAF 9.0发布，这是一个重要的里程碑，引入了内容框架，更加关注架构内容的描述和指导，而不仅仅是架构开发过程和方法。

2011年：TOGAF 9.1发布，进一步增强了框架的实用性和灵活性。

2018年：TOGAF 9.2发布，这个版本包含了更多的最佳实践和改进，以适应不断变化的技术环境。

2019年：TOGAF继续被广泛采用，成为企业架构领域最主流的方法之一，据报告，有超过80%的《福布斯》全球50强企业在使用TOGAF。

四：当前状态

截至2024年，TOGAF依然是业界广泛认可的企业架构框架之一，持续被用于帮助组织设计、规划和实施其IT架构策略。

TOGAF包括哪些内容

TOGAF一共包括了6个部分，分别是：

第一部分：对企业架构的关键概念，特别是TOGAF方法进行了概念性的阐述。

第二部分：ADM（架构开发方法），这是TOGAF的核心部分，这是一个以业务能力为中心，架构开发的过程，是一种逐步开发企业架构的方法。

第三部分：ADM指南和技术，这一部分包含了一系列最佳实践技术，来帮助我们专业化开展架构开发，这里包含了32种技术，4个向导。

第四部分：架构内容框架，这部分描述了TOGAF内容框架，包括用于架构制品的结构化元模型，可复用的架构构建块（ABB）的使用以及典型的架构结构可交付物的概述。也就是讲到的概念、画出来的图、产出物的分类命名等，要做到统一。这是一种行为上的约束。

第五部分：企业连续性和工具，指连续系列，本部分讨论了在企业中分类和存储架构活动输出的适当分类和工具，强调整个企业架构设计出来从水平划分可以分为四个等级，同时我们在做架构设计的时候，要充分参考以往成熟的架构资产。

第六部分：架构能力框架，本部分讨论在企业中建立和运行架构功能所需的组织、流程、技能、角色和责任。也就是企业架构的真正需要的三种工作能力：设计能力——架构师，治理能力——管理部，决策能力——委员会。

总结下来，就是郭老师讲述的八字口诀：

念、法、技、导、行、连、考、能。

接下来，我们逐个展开看看。

2

 

第一部分：概念

 

    TOGAF作为一种架构框架，用于协助接受（即做到领导层达成共识、平级部门支持、下级部门宣贯）、生产（创建）、使用和维护（治理）企业架构。

接受、创建、使用、维护（Acceptance， Production，use，maintenance）。

注意这里的四个顺序，接受为先，文化做接受，说的是方向。我们要构建新的架构原则、架构文化，来引领我们向前走，就要通过文化的方式、原则的手段，让大家去接受，这种接受的塑造是自上而下的，要先抓领导层的共识，再抓业务层的共识，再抓下属单位的共识。接着才是创建，也就是方法。

除了这四大行为，还有两种文化：

迭代：TOGAF基于迭代过程模型做好总体架构设计。能力不能一蹴而就，眉毛胡子一把抓，要做选型，如果我们在企业架构的范围上过度扩散的话，一定要做范围裁剪，淘汰一批当前并不是很紧要的能力建设问题。以能力组合，迭代的进行塑造为导向，去推进，一部分一部分的进行规划设计。

重用：TOGAF注重最佳实践和重用已有架构。企业架构是一个知识工程，在这个过程中一些典型的模式，我们要封装，要沉淀，要重用。把一系列的典型设计单元封装为构建块（building block），不断的去重用。

TOGAF认为，做企业架构可以帮企业推动以下能力的提升：

– 从异构到同构：讲的是数据资产。用企业架构养出来的数据，能纵横贯通的数据，叫数据资产。原来我们是用系统做存储，由于不同的系统拥有不同的架构、接口、存储等，造成了集成难度高、维护复杂等问题，有了企业架构之后，通过统一架构、接口和标准，我们实现了架构集成，于是可以通过企业架构来养资产。

– 从事后到事前：从事后关注IT治理到事前关注IT信息化建设顶层设计。企业架构作为顶层设计，是引领企业的信息化建设的。

– 从离散到统一：从离散的以功能为中心的系统建设，到以能力为中心的统一建设。也就是从散着建功能，到统着建能力。

– 从无序到有序：以往的信息化建设，实际上是按照时间交付，实现几个系统验收；有序指按照能力达成，来建里程碑。

TOGAF中涉及以下几个核心架构域：业务架构 BA、应用架构 AA、数据架构 DA、技术架构 TA，也就是EA 企业架构 = BA + DA + TA + AA，其中：

业务架构，看流程：这个流程按照标准是L2级别的，跨职能、跨层级。涉及到整个企业业务战略，及其整个业务治理，面向整个组织级跨越的关键业务流程，这个流程，又名能力主线。能力主线，横向跨阶段，纵向跨角色

应用架构，看集成：应用之间是集成的关系，单体软件的时代已经过去，怎么集成，走总线式还是微服务式：传统企业总线式，互联网络微服务。稳态的业务，用总线，敏态的业务，走微服务

数据架构，看共享：资产、资源、资本是数据的三种状态，散着是资源，统着叫资产，赋能叫资本。通过数据架构引领数据资产形成数据资本，这是数据架构的价值

技术架构，看平台：技术架构实质上是平台规划，要识别未来的信息化的公共技术平台体系。以往是用技术路线形成标准化的集成化环境，现在是用技术平台形成标准化技术环境，行话叫建平台、定标准、上应用、通数据。规划平台体系，让它成为我们标准化的信息技术环境，上面部署应用，而且支撑数据的共享贯通，这是我们平台体系。

另外在TOGAF9.2中，新增了2个扩展架构，分别是服务架构、安全架构，其中服务架构作为转型的方向，安全架构作为整体的环境，未来的所有企业信息化环境必须是安全可控的，所有的信息化的方向，应逐渐从以内部职能为中心专项面向客户市场为中心。

TOFAG框架概览如图所示：

到了版本10这个图已经几乎完全不一样了，但本文是基于9.2的材料整理，因此这个图就不做分析，如果后面有机会找到10的资料，再跟大家一起学习下。

图片来自open group 官网

3

 

ADM 架构开发方法

ADM架构开发方法，要满足四大行为的要求（接受、创建、使用、维护），作为TOFAG的核心部分，ADM是从四大行为的角度，以业务能力为中心给出的一个总体的工作框架。

ADM给出了一种可靠的、经过验证的开发和使用企业架构的方式。说白了就是怎么做出企业架构，这种架构又怎么去用？另外，在这个过程中，它尽力围绕四大核心架构域开展架构开发，不管企业提出什么样的业务能力需求，它认为都可以用四大核心做一个相对完整的能力规划。因此就有了下面这个所谓的“葫芦图”，这也是ADM的基本结构图，叫做架构开发周期。

这个图使用口诀可以总结为：一备一中心，八步一法。

一备，是预备阶段

一中心，是需求管理

八步一法，包含的是ABCDEFGH，一共是8个环，分别为：

A：架构愿景

B：业务架构

C：信息系统架构

D：技术架构

E：机会和解决方案

F：迁移规划

G：实施治理

H：架构变更管理

其中，从A到D，解决能力规划的创建问题。

从葫芦图整体来看，方向盘在预备阶段，发动机在需求阶段。一备是方向盘，需求管理是发动机，中间的轮子就能健康的往前走。

因此，企业架构的成功与否就看预备阶段能不能达成能力范围的接受，这里提供一个基本原则，也就是：能力导向、业务驱动、统一架构、分工协同，遵循：接受（预备阶段）、创建（ABCD）、使用（EF）、维护（GH）。

下面对各阶段做一下详细说明。

预备阶段

为组织成功地开展架构项目做好准备，解决的是接受问题，该阶段的目的是：

1. 了解业务环境

2. 获得管理层承诺

3. 对架构范围达成共识

4. 定义架构原则和标准

5. 建立治理结构

6. 对TOGAF进行裁剪和定制

这个阶段的事情是交给管理层的，前面说过，要构建新的架构原则和架构文化，需要以领导层的共识为前提，如果高层针对未来能力规划达不成关于能力的明确方向性的共识，企业架构就无法顺利开展下去，此时作为企业架构师可以再继续游说高层，直到达成共识，这是一个迭代型的努力。

这个阶段可以总结为：一个导向、三个要素、一个位置。

一个导向：共识–管理层承诺

三个要素：范围、原则与裁剪。范围——能力组合范围，原则——要倡导的文化，裁剪一般是方法、交付物、元模型

一个位置：治理（要认可通过信息职能建立架构管控）

需求管理

需求管理的目的是收集和记录业务需求，做能力需求的定义，并确保在每个阶段执行时，相关的架构需求都是可用的。这是一个需求识别和管理的过程，涉及确定业务需求的来源，并将其与业务能力紧密联系起来。

需求来源：业务需求可以从管理部门、业务部门或下属单位等多个渠道获得，是一种面向调研过程中的引导性梳理，这类似于传统的调研过程，它帮助我们确定能力的具体含义，即这个能力解决了什么样的业务场景问题。调研分为：

部门调研：了解内部各部门的需求。

下属单位调研：了解下属单位的需求。

外部调研：收集客户的反馈，特别是那些通过信息化实现数据协同的企业客户的意见。

需求管理有两个核心要求：

以业务能力为中心：做业务流程梳理，梳理完成后，流程优化作为需求的一部分。这意味着我们要围绕业务能力进行需求识别。

以统一愿景为中心：在领导层已经确定的统一愿景基础上，聚合各种需求。聚合需求是根据特定目标来看是否能够将这些需求统一关联在一起。如果能够聚合，说明这些需求是一致的；如果不能聚合，则可能存在冲突或不在原定的能力范围内，这时可能需要重新获取需求或暂时搁置。

简而言之，需求管理以业务能力为中心梳理和引导需求，然后进行愿景关联分析，自上而下地塑造能力愿景（接受），进而推动企业架构的创建、使用和维护。

需求管理确保TOGAF的每个阶段都建立在业务需求的基础上，并对其进行验证。需求管理是一个动态的过程，关注的是如何识别、存储以及将这些需求输入到相应的ADM阶段输出。

阶段A：架构愿景

又称为能力愿景，这个阶段的目的是：

1. 启动架构流程第一次迭代，为TOGAF项目设定目标、范围和约束条件

2. 建立架构愿景

3. 确定利益相关者的需求

4. 创建架构工作说明书

用领导层共识去确定愿景，确保所有参与者都对项目有一个共同的理解。

架构愿景需要基于业务需求来定义，从业务场景中挖掘出要建的能力，架构愿景应该深入挖掘这些能力的本质，确保它们能够满足业务需求。需求管理所支撑下的业务场景描述实际上是问题导向的（围绕着需要解决的具体问题展开），领导层关注如何通过架构设计来实现组织的战略目标，是设计导向的，当问题导向（即业务需求）和设计导向相结合时，就能达到最佳效果，这意味着设计不仅要符合业务需求，还要能够支持企业的长期发展目标。

阶段B：业务架构

核心是定义业务场景，描述业务流程，理解业务是如何运作的。传统的业务流程是以职能为中心的，新时期业务流程是以客户为中心的。

组织结构必须保障业务架构能够分解、能够分配、能够分责。说白了，各部门在按照业务流程分配下去之后，能够认责，这才能落地。但业务架构决定着组织架构。

业务架构，1要有基线，2要有目标，3有差距分析。梳理业务流程，要纵横贯通、跨阶段跨角色。业务架构四个步骤：1业务梳理，2流程展现（由主责部门负责），3问题发现（用系统支撑、数据贯通来分析），4目标优化（目标业务架构）。整个过程要坚持业务驱动。

阶段C：信息系统架构

信息系统架构体现出面向业务架构的双轮驱动：

信息对应数据架构，走DT路线

系统对应应用架构，走IT路线

双轮驱动实现了业务能力的支撑和赋能，确保数据和应用能够满足业务需求。在这里支撑讲究端到端覆盖，赋能讲究数据驱动融合创新，二者是协同关系。数据架构定义了要共享的内容，应用架构确定了要集成的管道，管道中流转的是共享的内容，二者之间的定位，前者叫数据流贯通，后者叫端到端覆盖。

所以，数据流贯通是数据架构的事情。强调内容（贯通的内容），端到端覆盖是应用架构的事情。强调贯通（贯通的管道）。

内容在管道中共享贯通，管道支撑数据流转，最终共同反哺业务。

那实际工作中我们应该先确定应用架构还是先确定数据架构呢？如果我们业务类型属于稳态业务（如传统企业），应用架构为先，先进行塑造，如果我们业务类型属于敏态，数据架构为先。最终数据和应用需要同步保持与业务架构一致。

保持一致体现在三个方面：

1.业务划分决定两者划分

2.业务构成决定两者构成

3.业务交互决定两者交互

也就是：业务划分决定二者划分和分类、业务交互决定二者交互。

如何理解呢？数据，应用，业务是不是要分类，业务怎么分类，分几大能力类型，数据就怎么划分，应用就怎么归类。这个数据是谁的责任，就看这个数据是从哪个业务源头生产的，从生产的关系，判定数据的责任划分。

那什么是业务交互决定数据应用交互？数据是一个共享交互关系，业务上交互的方向是数据共享的方向， 业务上交互的方向是应用集成的方向。

应用架构模型：

一步找划分：识别应用，描述应用的整体布局，包括应用的边界和它们之间的关系

二步找构成：识别模块内部构成，展示应用系统内部的模块划分和每个模块提供的功能和服务

三步找交互：识别交互方式，确定模块间或应用之间的交互方式

数据架构模型：

一步找划分：确定数据领域和主题域

二步找构成：识别主题域内的数据实体和业务过程

三步找共享：定义数据的共享方式

共享关系必须与业务之间交互关系保持严格的遵从，不允许有偏差和违背。

下面是关系视图，也是数据概念视图，E-R视图。

图片来自亿信华辰

这些数据的关联箭头、关系必须跟业务交互保持一致。这个交互来讲，一个能力主线、一个共享视图，如果完全揉在一起，会造成数据关联关系复杂性难以呈现的问题。一般项目当中，每个能力主线来独立规划它的应用架构和数据架构，应用集成和数据共享，按照能力主线，一个能力主线一组，分别进行规划。

阶段D：技术架构

技术架构是IT系统的基础组织形式，技术架构阶段主要确保技术层面上能够支撑应用架构，保证系统的可靠性和安全性，未来我们应用集成和数据共享，都需要技术架构的支撑。这里技术架构赋能应用架构、数据共享。

下面是一个常见的技术架构视图：

从架构图可以看到，对于企业架构来说，一般由这几部分组成：左开发、右安全、上门户、下云化。左侧放置统一开发平台，右侧为统一安全平台，上面建门户平台，下面建云化平台。通过这些走向信息化平台保障机制。

阶段E：机会及解决方案

A – D之后，我们的创建行动就完成了。

这一阶段的重点是寻找差距，并确定哪些技术方案可以帮助实现架构愿景。机会主要是找差距，（根据架构愿景）识别改进的机会，确定哪些技术和方案可以帮助实现架构愿景；解决方案研究是说，有方案的才能立项，没有方案可供选择，则该机会可能会被搁置。总结来说就是，机会分析找差距、方案优选立项。

当通过差距分析识别到机会（主要实施项目）之后，我们需要进行以下步骤：

1. 工作包分组：将识别出的机会分成不同的工作包，以便于管理和优先级排序；

2. 确定实施方案：这里可以探索多种实施方案的可能性，比如：直接购买现成的产品、外包开发、利用开源解决方案、购买商业套件等。通过对比分析，选择最优的实施方案。能够进行方案优选说明这个项目是可行的。

3. 优先级与依赖划分：在确定了实施方案之后，需要项目划分优先级和依赖关系，这一步骤体现了项目组合管理的特点，即明确项目之间的优先顺序和依赖关系。优先看价值（根据项目的潜在价值来确定优先级，价值越大，优先级越高），依赖看规律（识别项目之间的依赖性，即一个项目必须先于另一个项目完成的情况）。

阶段F：迁移规划

对上一阶段确定的工作包和项目，分析成本、利益和风险，制定详细的实施和迁移计划，确保顺利过渡到新的架构。

F阶段是在E阶段所识别出的项目组合基础之上，来进行的一个划分、四个细化。

一个划分：叫阶段划分，阶段指的是过渡架构，每个阶段叫做一个过渡架构，交付一个能力增量，阶段划分下来会形成一系列的过渡架构。

四个细化：时间、预算、价值和风险（TCVR），分别体现为规划过程中的进度规划、预算规划、目标规划和风险保障四个章节。

阶段G：实施治理

对实施过程进行架构监管，防止跑偏，并解决出现的问题，关注的是确保迁移计划的成功执行。

这个阶段的关键任务包括：

1. 架构契约的创建和管理：架构契约是一种契约精神，指每一个实施类的项目（行动单元），都要遵从全体架构，相应的，遵从性的条款合起来就叫做架构契约，这是由架构管理职能面向项目管理小组所签署的一个正式的文档，用于描述项目的目标、范围、责任和其他重要细节。

2. 监控合规性：确保项目按照架构契约的规定执行，保持与目标架构的一致性。

3. 变更管理：管理实施过程中出现的任何变更，确保变更不会偏离架构愿景。

4. 性能监控：持续监测项目进度和成果，确保它们符合预期的目标。

5. 风险管理：识别和管理实施过程中的风险。

6. 利益相关者沟通：与利益相关者保持沟通，确保他们了解项目的进展和任何重要的变更。

阶段H：架构变更管理

H阶段专注于架构变更管理，旨在持续监控并提供需求变更管理流程，确保以一致和结构化的方式管理架构变更。这样做的目的是确保架构具有灵活性，能够快速演进，并及时响应技术或业务环境的变化。

H阶段的重点在于通过变更来确保架构持续支持业务价值的最大化。当原有的业务能力发生变化后，通过架构的调整来促进整体业务能力的整体提升，确保架构的整体脉络与业务发展相匹配，从而最有利于业务的发展。

在实际工作中，如果源自业务能力的需求发生变化，或者实施项目与整体架构产生偏差，这时就需要推动架构变更管理。具体来说，有两种情况会触发架构变更管理：

A. 业务能力需求变化：当业务需求发生变化时，需要相应地调整架构以支持新的需求。

B. 架构合规评估偏差：如果发现实施项目与架构指导原则不一致，也需要进行变更以确保一致性。

进行架构变更管理的目的并不是简单地哪里有偏差就修正哪里，而是要确保有一种一致的方式来进行处理。这样既能保证架构的灵活性，又能持续及时地响应各种问题。这也告诉我们，一个好的企业架构是通过不断的变更和完善逐步形成的。

总结：

ADM架构开发周期这个过程是一个周期性的，每一次能力的规划，都要走一个完整的周期。能力规划，项目组合，变成发展规划去搞建设，到实施治理，然后再变更，再来一轮，再变更再来一轮，这是周期型的能力。此外，开发周期包含阶段的划分，从某种层面来讲，每个阶段都要进行独立的验证，要去确保我们做出来的能力规划，能力落地等都满足原定需求的需要。最后，我们日常工作过程中，我们每一个阶段内部的活动，都离不开利益相关者    （干系人）的参与。

4

 

ADM 指南和技术

最开头我们讲到，ADM提供了32种最佳实践，来帮助我们开展架构开发，这32个技术在企业架构中，各阶段都有所涉及。

1. 裁剪，裁剪就是一个选的过程，一般是5选：

选原则（原则就是口号）

选方法

选工具（用什么工具，如archi或者Visio等等）

选交付（看看交付物会有哪些）

选参考（看看参考资料可以选哪些）

裁剪最重要的是原则和方法，其他都是辅助性的，原则就是有什么理念让大家接受。

2. 企业架构组织模型，所有企业开展企业架构都需要（组建）专业的企业架构团队，一般来讲，叫“一总、四分、两管“这样的角色：

一总：是企业架构总师，或者叫企业架构师

四分：为业务架构、应用架构、数据架构、技术架构，四个维度的架构师，其中：流程建模——业务架构师，集成规划——应用架构师，数据治理——数据架构师，对新技术、大数（据）、（移动互联）网、云（计算）、端（计算）、安（全）、（人工）智（能）、（区块）链、图（论）熟悉的人适合做技术架构师

两管：项目管理（主要做沟通管理，帮助企业架构师，约时间，做领导访谈），文档管理（整个架构工作过程中会形成很多文档）

这些角色中，重点在于业务架构师，往往需要在企业架构团队过程中让一部分业务部门的人参与进来，担当起业务架构的角色，这样的话，把业务梳理的能力，业务架构设计的能力，传递到业务部门，对长远来讲是有益的。

3.架构原则，原则就是口号。根据组织的不同，原则可以在不同领域和层次上确立，有2个关键领域为架构的开发和利用提供了信息：

架构原则要考虑4个类型、4个标准、5个质量。

4个类型是业务类、应用类、数据类、技术类，对应四个架构子域。

业务上要推动战略契合、流程重构，在保证业务连续、业务合规条件下推动开展流程重构。这是能力建设之所需，企业发展战略之所需。

应用架构要注重统一设计、重用，保证柔性互联，使用应用安全。

数据架构，面向数据资产化，推动数据共享和重用，另外在数据治理方面，要从源头上实现数据治理的分工，按照生产者认责制的原则，谁生产、谁管理、谁负责的原则，来推动对数据治理的工作，这就是数据认责。此外，还要推动数据标准化和数据安全。数据架构是引领数据治理很重要的一个前置行为，先定数据架构， 我要什么样的数据共享效果，你就通过数据治理给我塑造出来。

技术架构，要保证形成标准化的信息技术环境，保证平台与应用及其数据共享呈现出的集成交互的可操作性，再有保证呈现出信息化的性能（今后的性能要通过平台化建设来保障），解决建的出、撑的住的问题。再有，异地多活，服务管理等一些要建立起来。所以在这里面蕴含的一些原则，让我们去思考，假如我们要引领企业，去发展业务能力，去开展应用及技术的架构塑造，去推动平台规划，我们有什么概念可以引领。

在原则梳理的时候，要多想一想，要规避企业文化的冲突。

4个标准指，架构出来时，每条原则要满足四个标准：名称上、声明上、依据上、相关的影响上：名称应积极——宣扬积极的术语，积极的观念；声明无二义——声明有解释说明，无二义性；依据有价值（推的原则，对业务能力建设有帮助，有利于业务能力建设整个达成）；相关保一致（他跟其他原则很明显有相关性，你必须得保持一致）。

5个质量：要易懂、健壮、完整、一致、稳定。

易懂看个人，架构原则应该易于整个组织中的个人理解，该原则的表述应该清晰明了，使得每个人都能快速把握其意图

健壮看复杂，无论业务需求多么复杂，原则都应能够提供明确的指导

完整看覆盖，这个原则的作用范围应该是全面的，覆盖所有相关领域

一致看冲突，原则之间不应存在冲突

稳定看变化，原则应具备足够的稳定性，即使面对业务能力的变化也能保持有效，这意味着，即使业务能力发生变化，原则仍然能够使用，而不必频繁更改。

4.业务原则、业务目标和业务驱动力

业务原则、目标和驱动通常在架构活动之前，在企业的其他地方定义，作为预备阶段的输出。

原则要保证，能力导向、业务驱动、分工协同、统一架构、统一管控。这就是一个好的原则。所以企业架构师一定要用理念取胜，用沟通取胜。

抓业务原则，抓业务目标，抓业务驱动力，其实就是能力导向，业务驱动这两个要素，一定要落到实处。

5.架构库

架构库（Architecture Repository）是一个集中存储和管理架构资产的地方。架构库包含了组织的所有架构信息和相关文档，旨在为架构师和相关利益相关者提供一个统一的信息来源。架构库中包含以下内容：

架构框架存方法

标准库中存标准

架构景观存设计（设计出来的东西叫架构景观）

参考架构存案例

治理日志存偏差 

6.架构工具

选工具，当前主要的工具有Visio、Archi等，Archi是开源的，是推荐的标准企业架构建模工具。

7.架构工作请求

架构工作请求，是由赞助组织发给架构组织的文档，来触发架构开发周期的开始。它是在架构组织的协助下，作为预备阶段的输出而被创建的。架构工作请求也可作为被批准的架构变更请求的结果而被创建，或是根据来源于迁移规划的架构工作的参考条目而被创建。

它是我们在企业中谁来发起企业架构项目的一个方式和方法，总结为双高原则：

1 高层发起：任何业务部门/信息部门都不能以部门名义来发起，来推动企业架构的立项，能力发展规划必须是高层发起。业务部门/信息部门是配合高层发起的协同部门。

2 高层赞助：这个能力建设所需要的拉动企业各方面的投资，流程梳理、系统建设、数据治理，平台建设，迁移等，要出钱出力

这份文档的建议内容如下：

– 组织赞助商

 

– 组织使命的声明

– 业务目标（和变化）

– 业务的战略计划

– 时间限制

– 业务环境的变化

– 组织约束

– 预算信息和财务约束

– 外部约束和业务约束

– 对现有的业务系统的描述

– 对现有架构/IT系统的描述

– 对开发组织的描述

– 对开发组织可用资源的描述

8.架构工作说明书

架构工作说明书是作为阶段A的可交付成果被创建的，它通常是在架构工作请求被接受之后，由架构团队创建的一个详细的计划文档，旨在确保架构工作的顺利执行并达成既定目标。

一般包含如下内容：

– 项目概述

– 企业架构项目请求和背景

– 项目描述和范围

– 架构愿景概述

– 管理的方法

– 范围变更的流程

– 角色、职责和交付物

– 接受标准和程序

– 项目计划和时间表

– 签署的正式批准

b背景，g目标，i输入，c成本，t时间，o输出。

一般架构工作说明书，至少是4个调研、2个文档（调研报告、分析报告）、4个架构、1个规划、1个治理。

9.架构愿景

架构愿景在A阶段创建，它起到了高层授权、部门支撑和向下宣贯的作用。

– 高层的授权：确保高层管理者对架构活动的支持和认可。

– 部门的支撑：确保组织内部各相关部门对架构工作的支持和参与。

– 向下的宣贯：确保架构愿景在整个组织中得到传播和理解。

在架构愿景阶段，经常使用的一种辅助技术是业务场景技术，用于描述每种能力的业务需求及其应用场景。业务场景由业务流和数据流两部分组成，帮助我们明确业务活动的流程以及数据的流动方式。

业务流：描述业务活动的顺序和流程，包括业务活动之间的逻辑关系。

数据流：描述数据在业务活动中的流动方式，包括数据的来源、处理过程和目的地

业务场景 = 业务流 + 数据流

10.利益相关者

利益相关者（干系人）是架构项目成功的关键因素，它们是哪些能够影响项目或受项目影响的人。架构师需要识别和管理这些利益相关者，以确保项目的成功。这项技术主要在阶段A种被使用，用来对架构项目的关键参与者进行识别，但也贯穿整个架构开发过程。

利益相关者（干系人）管理可以分为四个步骤：

– 识别：找出所有的利益相关者

– 分析：使用“双力原则”来识别关键的利益相关者，即哪些拥有较大权利和影响力的人员

– 定义：以利益相关者的视角来定义架构交付物，确保这些交付物满足他们的需求

– （判）评估：引导利益相关者参与评估过程，获取他们的反馈，以确保项目能够得到他们的支持

1识，2分，3定，4判。

双力原则：权力者（组织中有决策权或能够对项目产生重大影响的人）、魅力者（可能没有直接的权利，但在组织中有影响力的人物）

11.沟通计划

企业架构师或项目经理需要制定有效沟通的计划，这种计划通常可以总结为：三向、四定。

向上沟通求授权（高层）：与高层管理者沟通，寻求项目授权和支持

对等沟通求支持（同级）：与同级别的同事沟通，寻求合作与支持

向下沟通求落实（下级）：与团队成员沟通，确保项目计划得到执行。向下沟通的目的是确保项目计划得到落实，站在落实的角度进行宣贯。

四定包括：

一定相关干系人：识别出所有与项目有关的利益相关者

二定相关关注点：了解每个人利益相关者（干系人）关心的问题和期望

三定时机与频率：确定沟通的最佳时机和频率，比如每周会议或每月报告

四定手段与方法：选择合适的沟通手段和方法，比如面对面会议、电子邮件或电话会议

12.业务转换的准备就绪评估

业务转换准备就绪评估用于识别和评估能力建设的可行性，通常在A阶段使用。这项评估旨在量化一个组织对接受变更的准备程度。

目的：企业架构是面向能力的规划，但是在规划能力时，需要确保这些能力的建设是可行的。例如，一个组织可能具备生产能力、管理能力、服务能力、运营能力等多种能力，但这些能力的承受度各不相同。

评估的必要性：就像跳高比赛，不同的人有不同的跳跃高度。同样，在规划能力时，目标架构所蕴含的能力增量应当是可行的，否则就存在业务转换风险。

评估的核心要点：

立足转换找风险：评估组织在实施能力转换过程中可能遇到的风险。

立足增量看可行：评估拟议的能力增量是否切实可行。

当高层管理者对项目的可行性有所顾虑时，可以通过业务转换准备就绪评估来讨论以下几点：

能力增量：明确本次能力建设将实现的能力增量。

可行性分析：分析这些能力增量在企业中是否可行。

风险评估：评估项目实施过程中可能遇到的风险，并提出相应的缓解措施。

13.能力评估

能力评估是指评估组织当前的能力水平以及识别改进机会的过程，强调面向能力的提升可行性。

能力评估有两个核心作用：

识别可行能力：确定哪些能力适合进行优化。

评估优化潜力：分析优化后的潜力，即能力能够提升的程度。

能力评估的维度：

宽度：评估有多少能力适合进行优化。

高度：评估能力优化的潜力，即能够达到的提升程度。

宽度看多少，高度看增量。

企业能力与能力提升的关系

能力基础：企业的能力基础越强，面向能力提升的潜力也越大。

弹跳力：强大的能力基础能够提供更强的“弹跳力”，使得能力提升更为可行。

14.风险管理

风险管理是一种在实施架构项目时用于降低风险的技术。风险管理可以概括为“5步1环”的过程：

识别（Identify）：识别可能影响项目的潜在风险因素（把风险找出来）。

度量（Measure）：评估识别出的风险，确定哪些风险最为严重（把严重的风险挑出来）。

量化（Quantify）：量化严重风险的影响程度，包括其发生的可能性和后果。（把严重风险的影响识别出来）

权衡（Weigh）：评估风险的积极和消极影响，确定哪些风险需要重点关注。

应对（Respond）：制定应对策略，包括规避、减轻、转移或接受风险。

循环开展（Cycle）：风险管理是一个持续的过程，需要定期回顾和更新。

1 识、2 度、3 量、4 称、5 术、6 循环

风险管理包括这些活动：风险分类、风险识别、初始风险评估、风险缓解和剩余风险评估、风险监控。

企业架构师必须通过风险管理使自己能够运筹帷幄决胜千里。

15.架构定义文件

架构在梳理过程中需要形成正式的交付物，因此，从文档的角度，架构定义文件是必须要输出的，它是架构开发过程中形成的一个重要交付物。它通常需要在企业的领导层会议上进行正式介绍，并向全系统的业务部门及下属单位进行宣贯说明。

架构定义文件通常包括原则、架构、指南三个核心要素，其中：

原则：又叫做总体策略，指导架构决策和方向

架构：即业务架构、数据架构、应用架构和技术架构四个架构，业务架构描述了业务能力、流程和组织结构，它是以能力为导向，由业务驱动的；数据架构描述了数据的组织结构、数据流和数据存储等内容；应用架构：定义了应用程序和服务的集成和交互方式；技术架构：描述了硬件、软件、网络和通信设施等技术基础设施。

指南：提供遵从性规则和治理管控的应用指导。

16.架构需求规格

架构需求规格是一组量化的声明，它概要地说明了实施项目必须做到什么样的效果以符合架构要求。它是架构定义文件的补充，为架构定义文件提供了定量的视图，有助于确保实施项目与架构保持一致。

架构需求规格与架构定义文件的区别：

架构定义文件：架构定义文件侧重于描述业务能力（能力规划）。

架构需求规格：侧重于平台层面的设计，相对更加具体，更容易遵从和实现。

17.架构路线图

架构路线图是面向架构迁移的，它描述了一个能力达成的过程，通常体现为阶段性的路线图。

架构路线图的核心内容包括1个主线2个要素：1个主线–阶段划分，2个要素–过渡架构、项目组合。

阶段划分，将整个迁移过程划分为若干个阶段。

过渡架构：每个阶段内部的过渡架构，即在每个阶段末期应达成的架构状态，过渡架构其实就是我们规划当中建设的能力；

项目组合：为了实现过渡架构，每个阶段中需要执行的项目组合，比如针对规划中的能力实现，我们在业务上做什么项目，在数据上、应用系统建设上、平台上做什么项目，这个就是项目组合，项目组合有利于能力的达成。

例如，在一个为期五年的135规划中，架构路线图会明确每年需要达成的业务能力，以及为了实现这些能力所需要执行的项目。

架构路线图列出了从基线架构向目标架构演进的各个增量，并将这些增量放在一条时间轴上，展示了整个演进过程。它是过渡架构的关键组成部分，并在TOGAF ADM的阶段B至F过程中，以增量的方式被开发。

架构路线图通常包含：项目列表、面向时间的迁移计划、实施建议

18.业务场景技术

业务场景是一种重要的技术，用于识别和理解企业中的业务需求。它帮助架构师和利益相关者理解新业务功能中隐含的业务需求，以解决关键的业务驱动因素，并揭示隐含的架构需求。

业务场景用于：

识别业务需求：帮助识别新业务功能中的业务需求。

解决问题背景：提供业务问题的描述，使得需求在整个问题的背景下相互关联。

业务场景通常由以下两个主要部分组成：

业务流：描述业务活动的顺序和流程，包括业务活动之间的逻辑关系。

数据流：描述数据在业务活动中的流动方式，包括数据的来源、处理过程和目的地。

通过结合业务流和数据流，可以更全面地理解业务需求和业务流程中的数据处理方式。这种双流合一的方法有助于确保业务需求和架构需求之间的一致性和完整性。

19.差距分析

差距分析是识别工作包的一个过程，关注于识别当前状态（基线架构）与未来状态（目标架构）之间的差异，并通过这些分析来定义工作包，最终形成项目。这个过程帮助架构师确定需要采取哪些行动来弥补这些差异，以确保架构愿景得以实现。

差距分析通常包括以下几个步骤：

1. 定义基线架构：确定当前的状态，即现有的业务、数据、应用和技术架构。

2. 定义目标架构：根据架构愿景和业务需求，定义未来的状态，即期望的业务、数据、应用和技术架构。

3. 识别差异：通过比较基线架构和目标架构，识别两者之间的差异。这些差异可以是缺失的功能、不兼容的技术、需要改进的过程等。

4. 评估影响：评估这些差异对业务的影响，包括成本、时间和资源等方面。

5. 确定优先级：根据差异的影响和紧急程度，确定解决差异的优先级。

通常会绘制一个差距分析矩阵，把现状中有什么，目标中有什么，对应的架构构建块进行对比，具体措施为：

缺：代表需要新建的构建块。

弱：代表需要升级的构建块。

重：代表需要重新构建或消除冗余的构建块。

20.架构视点

架构师从阶段A到D，使用视图和视点来开发每个架构领域（业务、数据、应用、技术）的架构。一个视图就是你看到的东西，而视点是从哪儿看，即决定你所看到的角度或观点。

视图是通用的，可以存储在视点库中重复使用，视图总是特定于它所创建的架构。每个视图都有一个相关的视点来描述它，哪怕该视点是隐含的。

21、架构视图

指按照架构视点所完成的架构设计，架构视图的目的是为了更好地沟通和理解架构的不同方面，并且要能够协调不同利益相关者的关注点。

在创建架构视图时，需要考虑不同利益相关者的需求和关注，当利益相关者之间存在冲突时，架构师需要通过协商和沟通来协调这些冲突，以确保架构视图能够被广泛接受。

架构视图有三种形式：目录（列表形式）、矩阵（展示不同架构元素之间的关系）、图表（用图表来表达架构元素极其关系）。

22.架构构建块

架构构建块（ABB）是架构的文档描述和模型，来自于按照架构连续系列进行分类的企业架构存储库，主要在ABCD阶段被定义或选择。

架构构建块能形成企业架构资产库，有利于重用

23.解决方案构建块

解决方案构建块是指作为技术提供商，在产品规划时可以利用特定的思维来封装解决方案。这种封装将解决方案与甲方（即客户或业务方）的利益相关者关注点相结合，形成解决方案构建块。

ABB和SBB的区别：

架构构建块 (Architecture Building Block, ABB)：是更通用的构建块，可以被多个架构重用。一般来讲，一个视点加相关方案叫SBB，一个视点加相关视图叫做ABB。

解决方案构建块 (Solution Building Block, SBB)：是特定于某个架构或业务需求的构建块，通常是在架构构建块的基础上进行定制和细化。

解决方案构建块首次出现在阶段E（机会和解决方案），在这个阶段定义了什么样的产品和组件能够实现所需的功能，从而定义了实现方式。这些构建块与具体的产品或供应商相关，满足业务需求。

24.基于能力的规划

Phases E 和 F 提供了一种基于能力规划的原则，用于确定和规划企业转换的具体方法。这是一种专注于业务成果的业务规划技术，是业务驱动和业务导向的，它结合了所有业务领域所需的必要努力，以实现所期望的能力。它适用于大多数公司的业务模式，尤其适用于那些需要具备潜在响应能力（例如，应急准备部门）的组织，或相同的资源被投入到多种能力的组织。通常，这些能力的需求是通过业务场景发现并精炼的。

基于能力的规划、企业架构和项目组合/项目管理三者之间的关系如下图：

25.迁移规划技术（TCVR技术）

迁移规划在企业架构领域中通常被称为TCVR技术，它涉及到四个关键参数的细化：

Time (时间进度规划)：定义项目的实施时间表，包括各个阶段的起止时间。

Cost (预算与投入规划)：估计项目的总成本和资源投入。

Value (价值目标规划)：确定项目的价值目标，即项目的预期收益。

Risk (风险保障规划)：评估和管理项目的风险，包括风险预防和缓解策略。

迁移规划技术的实施

在前期阶段划分的基础上，对于每个项目，我们都需要细化这四个参数。我们需要考虑如何安排进度、衡量价值、识别预算和分析风险。

迁移规划技术包括以下技术：

1. 实施因素推论矩阵

在阶段E中使用创建实施因素评估推论矩阵的技术来记录影响架构实施和迁移计划的各种因素，典型的因素包括风险、问题、假设、依赖性、行动和影响。

2. 整合差距、解决方案和依赖性矩阵

整合差距：在细化了每个项目的四个参数之后，需要进行整合，分析项目的依赖关系。

依赖分析：通过分析依赖关系，我们可以确定项目的先后顺序，识别哪些项目需要先实施，哪些项目可以并行进行。

3. 架构定义增量表

架构定义增量表：用于记录每个过渡架构中需要完成的项目组合，以及这些项目如何支持过渡架构的实现。

26.实施和迁移计划

实施和迁移计划在阶段E、F中被指定，目标是定义一个有序的项目列表，这些项目将按计划实施，以实现目标架构。它还涉及评估和管理与实施相关的风险，并确保项目与业务目标保持一致。

实施和迁移计划通常包括以下内容：

项目列表：列出为了实现目标架构所需的项目。

项目优先级：根据项目的紧迫性和重要性对项目进行排序。

时间表：为每个项目定义预计的开始日期、结束日期和里程碑。

资源分配：确定每个项目所需的资源，包括人力、资金和其他物理资源。

依赖关系：识别项目之间的依赖关系，包括前置条件和后续步骤。

风险评估：评估实施过程中可能遇到的风险，并制定风险缓解策略。

成本估算：提供每个项目的成本估算。

价值评估：评估每个项目对业务目标的价值贡献。

变更管理计划：定义如何管理架构变更，包括变更请求流程和审批机制。

沟通计划：定义如何与利益相关者沟通项目进度和变更。

治理结构：确定监督实施过程的治理结构，包括角色和职责。

度量指标：定义用于衡量项目成功和进度的关键性能指标（KPIs）。

实施和迁移计划的过程：

项目组合分析：基于TCVR技术（时间、成本、价值、风险），分析项目组合，确定项目的优先级和顺序。

整合差距分析：基于前期的差距分析结果，整合各个项目的需求和依赖关系。

制定项目计划：为每个项目制定详细的实施计划，包括时间表、资源分配和风险管理。

制定沟通计划：确定如何与利益相关者沟通项目进度和变更。

制定变更管理计划：定义变更请求流程和审批机制，以确保架构的一致性和可控性。

制定度量计划：定义关键绩效指标（KPIs），以监测项目的进度和成功。

实施监控和控制：定期审查项目进度，确保项目按计划进行，并及时调整计划以应对变化

27.过渡架构（里程碑）

过渡架构是用来描述从当前架构状态（即基线架构）到目标架构状态之间的一系列中间架构状态。每个中间状态（过渡架构状态）都包含了业务、数据、应用和技术四个主要领域的架构描述。

过渡架构通常包括以下内容：

过渡架构描述：

定义每个过渡阶段的架构状态：这指的是在从当前架构到目标架构的过程中，每一步的具体架构状态。每个状态都是一个清晰定义的架构配置，它代表了一个具体的过渡点或阶段。

每个过渡状态的业务架构：

描述了业务流程、组织结构、策略、目标和关键绩效指标等要素在每个过渡状态下的具体安排。这有助于确保业务需求得到满足，并且整个转型过程对业务目标有所贡献。

每个过渡状态的数据架构：

包括数据模型、数据存储、数据质量和数据安全等方面的设计。它描述了如何管理和利用数据资产来支持业务需求，并确保数据治理和合规性在整个转型过程中得到维护。

每个过渡状态的应用架构：

涉及应用系统的布局、集成和服务接口的设计。它描述了应用系统如何支持业务流程，并确保应用组件能够有效地协作以提供所需的服务。

每个过渡状态的技术架构：

包括硬件、网络、操作系统和其他基础设施组件的选择和配置。技术架构还关注安全性、性能和可用性等方面，确保技术基础架构能够支持应用和数据架构的需求。

综上，过渡架构的构建需要从业务、数据、应用和技术等多个维度进行考虑。每个维度都有其特定的架构描述，这些描述共同构成了一个完整的过渡架构状态。

28.实施治理模型

实施治理模型是一个组织保障机制，确保企业架构的有效实施。这里要求一个企业的信息部门必须做三件事情：

1. 定政策：定义架构治理政策和指导原则。

2. 建组织：建立专门的架构治理组织和管理职能。

3. 明流程：明确架构治理流程，包括变更管理和合规性评估。

4. 做考核：制定考核指标，以评估架构治理的效果。

实施治理模型的作用：确保过渡架构的实施活动符合架构定义文件，并平滑过渡到适当的架构治理阶段（G阶段）。

29.架构契约

企业架构时代，每个企业架构实施项目，都需要一个遵从性的章程，叫做架构契约。它意味着，我们的流程建设，不能违背整体能力发展的规划，不能违背业务架构；系统软件开发，不能违背应用架构；数据库的设计及其数据的共享流转，不能违背数据架构；技术路线的选取，不能违背技术架构。

架构契约，就是以契约精神去推动我们企业架构对实施项目的管理问题。它在阶段G生成，是用于管理架构实现过程的正式文档，定义了项目参与者之间的协议，确保实施活动与架构定义保持一致。

30. 变更请求（H阶段）

变更请求包含2种来源、3种类型：

来源：

需求变化：由于业务需求的变化引发的变更。

治理偏差：由于与架构定义文件不一致导致的变更。

类型：

整体变更：看战略。当企业的战略调整导致能力组合发生变化时，可能需要整体变更。

增量变更：加能力。追加一个能力的规划，重新打造某一个全新的能力。

简单变更：看IT。单纯是IT架构的调整，如应用架构的调整，从总线型架构解耦为微服务模式。

31. 合规性评估

合规性评估是评估实施活动是否符合架构定义文件（战略和架构目标）的过程。

32. 需求影响评估

需求影响评估是识别业务需求与架构关注点之间关联性的过程，即在调研过程中，识别业务需求与业务架构、数据架构、应用架构和技术架构之间的关联性。

4

 

调整ADM的指导

ADM是一个通用型的架构开发框架，旨在满足大多数系统和组织的要求，由于每个项目和组织的情况都有所不同，因此需要调整ADM以适应特定场景和组织的需求，这体现了ADM的灵活性。

ADM支持向导就是用来对ADM进行调整或扩展以适应特定场景和业务需求的技术，使用ADM支持向导的目的是审查ADM的过程和输出看其是否适用，然后对它们进行裁剪以适应具体的企业环境，帮助企业架构师根据具体情况适当的调整架构开发方法。

上一部分讲的32个技术是做法（细节应该怎么做），而这里的向导是用法（ADM怎么用）。

有四个向导：裁剪、迭代、层次、指导，两种风格：基线架构、目标架构。

1）裁剪的对象是原则、方法、交付物。原则是说根据原则模板体系来选择适用的原则；方法是说，根据ADM框架，来增补或裁剪步骤；交付是确定最终需要产生的视图和文档。

2）迭代的目标是通过迭代来达成共识，它是共识导向的。

裁剪是个多少问题，迭代是个先后问题。

分为四种迭代：

架构能力迭代：建立和维护组织的架构能力。

架构开发迭代：定义架构愿景，创建业务架构、信息系统架构和技术架构。

过渡规划迭代：规划从当前架构到目标架构的过渡。

架构治理迭代：确保架构定义文件得到有效实施，并持续监控和控制架构实施过程。

3）层次：指当面对一个企业架构的时候，我们要学会做好工作分解，首先把企业总体战略分割为业务战略，接着业务战略再分割为能力规划，归根到底，企业架构是从能力规划出发，构建业务架构、应用架构、数据架构和技术架构。

层次指企业架构在完成空间上有三大维度，三个层次。

三个维度：

主题：指业务种类或业态

时间：企业架构的规划设计时间跨度，要识别出几年要能够撑得起的发展路径和阶段

细节：细化的层次问题，细节粒度

三个层次为企业战略、业务战略、能力规划。

4）指导：目标是指导如何构建非核心架构，如安全架构、服务架构，具体的做法是：从四大核心架构中寻找关注点，并确保架构的完整性。

以安全架构为例，安全架构在架构设计过程中是经常需要考虑的，并且安全在未来企业是一个整体环境的问题，那如何找安全关注点呢？要从业务安全、应用安全、数据安全、技术安全去考虑，当安全设计完成之后，再从业务视角、应用视角、数据视角、平台视角是否安全来进行衡量和判定是否存在不完备之处。

安全架构师普遍关注的领域包括：7A一个R

Authentication、Authorization、Audit、Assurance、Availability、Asset Protection、Administration、Risk Management。

简单说下服务架构，在ADM中，我们可以使用服务导向的思维方式来定义和实现服务架构。例如，在业务架构阶段定义服务的功能需求，在应用架构阶段设计服务的接口和交互，在技术架构阶段选择合适的技术栈。这里区分一下传统服务和现代服务：

传统服务侧重于分割，将现有的业务应用、数据和技术要素分割为服务单元，便于共享和隔离变化

现代服务侧重于转型，面向客户和市场的信息和资源聚合，加强企业对外的能力，实现服务的敏捷性和灵活性

最后，除了四个向导，还TOGAF定义了两种风格的架构定义：

基线优先：从当前的状态出发（基线架构 Baseline），通过对现有架构的分析和理解，逐步推进到目标架构；当组织可能还没有一个清晰的战略方向或愿景，但已经积累了大量的现有系统、流程和技术资产，采用基线优先可以帮助组织从当前状态出发，逐步理解和优化现有架构，进而向目标状态过渡，说白了基线就是适用于战略方向不够明确且资产较多的情况，侧重于解决现有问题，自下而上

目标优先：从目标架构出发，先定义期望达到的目标状态，然后逐步规划如何从当前过渡到目标，适用于战略方向明确但资产较少的情况，侧重于实现长期愿景（愿景驱动），自上而下

5

 

架构内容框架

架构内容框架模型主要解决在内容上的三统一：统一概念、统一视图、统一分类，它提供了一种标准化的方式来组织和管理架构内容，包括架构元模型、架构视图、架构视图模板、架构制品和架构存储库等元素。这些元素共同构成了一个全面的架构管理框架，旨在帮助架构师以一种一致和结构化的方式创建和管理架构模型。

统一概念：业务域画出来的流程，叫能力主线，主线分职能，职能内部有流程，流程内部是活动。这样的层次化的划分有助于明确业务职责和流程，确保所有相关方对目标有一致的理解。

统一视图：业务能力视图，与组织结构和职能结合，确保业务流程能够有效落地实施，数据域和业务域保持一致，确保数据治理与业务需求保持同步，应用域遵循业务域的划分，有助于确保应用程序和服务与业务需求紧密相连，技术视图侧重支撑应用集成和数据共享，确保技术层面满足业务需求。

统一分类是指，架构工作产出的分类。包括构建块、制品和交付物。

1. 交付物 (Deliverables)：指在架构开发过程中产生的可交付成果，通常是一些文档或模型，如愿景文档、架构定义文档、架构合同等。

2. 制品 (Artifacts)：是架构内容的具体表现形式，可以是文档、图表、模型或其他形式的信息。

3. 构建块 (Building Blocks)：是架构内容的基本单元，用于构建架构模型。构建块包括业务构建块、信息系统构建块和技术构建块。业务构建块：描述业务能力、流程、规则等；信息系统构建块：描述应用组件、数据实体等；技术构建块：描述技术平台、基础设施等。

日常产出构建块、阶段产出为制品、最终产出交付物

白话版：平时架构师做出来的，一个个的设计单元叫构建块，构建块不断的涌现不断的完成，达到了某一种阶段性之后，叫做制品（阶段性成果）。当各阶段产出逐渐完善并获得干系人认可之后，就可以叫做交付物了。最终是用架构合同来衡量的。

下图展示了交付物、制品和构建块的关系：

6

 

企业连续系列

企业连续系列提供了一种方法来管理和分类架构资产，以便于重用和演进。它可以帮助组织理解、管理和控制其架构资产的发展历程。

图：企业连续系列

图：TOGAF 架构存储库的结构：

连续系列，有下面的4个等级：特定组织级、行业级、通用级、基础架构，它们的差异是这样界定的：

特定级别看企业：专注于特定组织的的特定需求和环境，反映组织的具体情况

行业级别看产业：关注特定行业的共同需求和最佳实践

通用级别看跨越：跨行业的通用架构构建块，适用于多个行业

基础级别看标准：最通用的一类，包含了最基础的架构构建块，通常是符合国际标准或行业标准的，需要大师级的企业架构师才能完成

7

 

参考模型

参考模型的概念在于鼓励架构师们在进行架构设计时，尽可能地利用现有的架构资产，而不是从头开始进行原始创新。这有助于提高效率和确保一致性。

TOGAF提供了两种典型参考模型（按照连续系列进行分类）：

技术参考模型 (TRM): TRM为技术架构的设计提供了指导，帮助确定技术组件的位置和分类，它位于连续系列的基础级别，是高度标准化的，适用于广泛的组织和技术环境。

集成信息设施参考模型 (IIIRM – Integrated Information Infrastructure Reference Model): IIIRM主要用于指导应用架构的设计，特别是关注于应用集成方面。

起到的作用:

– 开放互联用标准: IIIRM提倡使用标准协议和技术来实现不同系统的开放互联。

– 协同访问用代理: 通过代理机制（例如应用集成器）来实现不同系统的协同访问。

– 打造无边界信息流: IIIRM的最终目标是创建一个无边界的信息流，使数据能够在各个系统之间自由流动。

– 权限与身份管理: 强代理（如企业服务总线ESB）用于管理权限，而弱代理（如目录管理）则用于身份管理。这种模式在现代的分布式服务架构和微服务架构中很常见。

8

 

架构能力框架

架构能力的主要有三：

设计能力-架构师：由架构师团队负责，他们负责架构的设计和开发。

治理能力-管理部：通常由一个专门的组织或部门（如架构治理委员会或架构管理办公室）负责，确保架构的实施符合既定的标准和政策。

决策能力-委员会：通常由架构评审委员会或类似的高级管理层组成的小组来行使，负责审批重大架构决策，确保架构的一致性和合规性。

决策过程中主要包括以下几个方面：

架构之间的冲突问题：解决不同架构之间的矛盾和不兼容性。

数据流和业务流的方向不一致：确保数据流和业务流程的一致性和顺畅性。

确定哪些能力作为共性积累：识别哪些架构构建块可以被广泛重用。

哪些应重点关注技术赋能：确定哪些技术领域需要特别的关注和支持。

灵活性与稳定性之间的平衡：决定哪些部分需要灵活性，以适应变化，哪些部分需要稳定性，以确保可靠性。

架构三大能力如何沉淀：

1 培训（入门）：通过培训项目帮助新成员了解架构的基本概念和方法论，这是入门阶段。

2 实践（成长）：通过参与实际的架构项目来积累经验，这是成长阶段。

3 知识管理：包括知识管理活动，如文档编制、案例研究和最佳实践分享，这些都是能力沉淀的重要组成部分。

建立架构不仅仅是指设计架构的能力，还包括实施和管理架构的能力。因此，除了设计之外，还需要考虑架构的实施、维护和治理等方面。

图片来自互联网

9

 

总结

最后，祝您逢考必过。

阅读分享只为记录自己的阅读历程，如果有写得不好的地方，还请批评指正，也欢迎书友一起交流观点。感谢！

引用：

[1] The TOGAF Standard, Version 9.2 A Pocket Guide

[2] https://pubs.opengroup.org/architecture/togaf9-doc/arch/

[3] https://pubs.opengroup.org/pocket-guides/togaf-pocket-guide/main/introduction.html

[4] https://www.bilibili.com/video/BV1AL4y1L72s

《完》