架构是关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。听起来是一个很抽象的概念，大家可能希望有一些指导可以参考。这个就是架构方法论。架构方法论有很多，有 TOGAF、Zachman 等，其实本质上都大同小异。架构方法论，提供架构师架构设计的参考流程、常规的动作、标准的产出物，但是不会保证架构设计的交付质量。也就是说，架构方法论决定架构的下限，但不决定架构方案的上限。

Zachman

Zachman 更像一个架构方案的模版，指导架构师需要考虑的方面。

TOGAF

ADM

TOGAF 的核心是 Architecture Development Method（ADM），指导架构师架构设计的流程。

预备阶段

做架构之前，要先了解现状。

了解组织架构、了解在使用的架构框架/methodology、了解已有的架构资产。

Architecture Vision

定义 stakeholders、了解愿景、定义范围。

找准 stakeholders 很重要，架构需要有人买单（buying）。

架构要提现老板们的愿景。

架构要有问题范围，无限的就不是架构了。

问题要具体，比如 3+3、比如 0 配置、比如降低成本 XXbp。

业务架构

这个部分我们一直强调的很少。

业务也是需要架构师的。

组织架构（Organization structure）、功能（Functions）、服务（Services）、流程（Processes）、角色（Roles）、规则（Rules）、Use case，这些都是业务架构的产物。Maybe 这部分是 PD 要完成的范畴。

信息系统架构

这块可能是我们最熟悉的，但是这里又分成两部分：

• 数据架构（Data Architecture）

• 应用架构（Application Architeture）

数据架构描述实现业务架构需要的数据模型。数据模型分成概念模型、逻辑模型和物理模型。

数据架构还需要考虑数据安全和数据迁移。

应用架构我们很熟悉了。但是需要注意，应用架构不是单纯的模块图，需要提现应用之间的交互（应用间依赖关系，在业界有统一的 System Context 来定义）。

技术架构

信息系统架构的技术实现，在 18 摸，叫 Operational Model。

包括关系数据库、非关系数据库、缓存选型、软件采购；

还包括云/容器/物理机，网络、存储等。

管控

剩下的就比较虚了。

几点可以关注一下：

• 需要有从老架构到新架构的迁移方案；

• 需要对实现的管控；

• 需要有架构变更管理；

• 需要有需求管理。

Architecture Repository

TOGAF 里面特意定义了 Building Blocks、Artifacts，就是要有架构需要有 Repositoy 和传承。

对于 ADM，有如下的 metamodel 与之对应可供参考：

同时定义了 ADM 交付件中包括的 Artifacts，这里不详述。

Enterprise Continuum

取长补短，不断完善 Architecture Repository。