企业架构有四大支柱，分别是业务架构、数据架构、应用架构和技术架构，上次我写了一篇业务架构的文章《把业务架构搞搞懂，才算敲开了理解业务的大门！》，谈了对业务架构的粗浅理解，这次来讲讲应用架构。

网上关于应用架构的资料非常碎，因此我找了企业架构开发方法的权威TOGAF作为参考，把应用架构的交付物和端到端流程全部走了一遍，图文并茂，希望尽量用浅显易懂的方法把应用架构讲讲清楚。

一、企业架构全景图

TOGAF（The Open Group Architecture Framework）是一个工具集、术语集和流程集，提供了一个全面的方法来开发企业架构。TOGAF的中心是一个被称为"架构开发方法"（Architecture Development Method，简称ADM）的流程，如下图所示：

我们最关注的是业务架构、数据架构、应用架构及技术架构，这些架构层次的描述体现了从高层策略到低层实施的逐渐细化的逻辑。

1、业务架构

主要关注业务策略、治理、组织和关键业务流程。

描述业务功能、业务流程、事件、组织单位、角色、业务服务以及其他业务行为。

2、数据架构

描述组织的物理和逻辑数据资产以及数据管理资源。

关注企业的信息资产，如何在应用和业务流程中结构和使用它们。

3、应用架构

描述应用系统的总体结构和应用组件的相互关系。

关注系统解决方案和服务以支持业务架构的需求。

4、技术架构

描述硬件、软件、网络和其他技术资源的策略和标准。

定义支持应用架构运行所需的基础技术结构。

应用架构与其他三个架构有紧密联系：

1、业务架构定义了为什么要进行某项业务，并提供了业务需要什么样的信息支持（即数据架构）。

2、数据架构和应用架构合作，确保业务流程能够通过正确的信息系统得到所需的支持。应用架构定义了什么系统需要进行交互，以及这些系统如何与数据交互。

3、技术架构再进一步定义了如何实施应用架构，它描述了支持数据、应用和业务功能所需的基础技术。

这四个层次构成了企业架构的综合视图，它们共同工作，确保从高层的业务策略和要求到实际的技术实施都是对齐的。

二、应用架构的定义

应用架构在TOGAF中处于阶段C，专注于定义支持业务和数据处理所需的应用系统，它描述了应用系统之间、应用与用户之间的交互和行为。

不同于应用程序或软件的内部架构，应用架构不涉及单个应用的具体架构和实现技术。其核心是确定企业需要哪些类型的应用以及这些应用如何管理数据和为企业人员提供信息。在应用架构中，应用被视为负责支持数据对象管理的逻辑功能组或支持业务功能的组件，而不是具体的计算机系统。总之，应用架构关注如何整合多个应用系统以满足业务需求，而不是单个系统的技术细节。

那么，应用架构具体长啥样呢？

TOGAF 提供了一个详细的架构工具模型，如下所示：

在阶段C，TOGAF定义了应用架构的主要交付物，共分目录、矩阵、图三类类型，总计14个制品：

1、目录：应用组合目录、接口目录

2、矩阵：系统/组织矩阵、角色/系统矩阵、系统/功能矩阵、应用互动矩阵

3、图：应用通信图、应用和用户位置图、系统用例图、企业可管理性图、流程/系统实现图、软件工程图、应用迁移图、软件分布图等

下面以案例的形式逐个说明这14个制品的具体内容，应用架构的最终交付物往往是这14个制品的编排组合：

1、应用组合目录

假设我们有一个中型企业，该企业涉及以下几个核心业务领域：

（1）销售：负责产品的销售。

（2）人力资源：负责员工的招聘、培训和福利。

（3）财务：负责公司的财务管理，如支付、收款、预算和报表。

基于这三个业务领域，我们可以列出以下的应用组合目录：

在这个简化的应用组合目录中，我们可以清晰地看到每个应用支持哪个业务领域，它们的主要功能是什么，它们运行在哪些技术平台上，以及它们当前的生命周期状态。这有助于企业更好地管理其应用组合，理解各应用之间的关系和依赖性，并决定在哪里投资以支持未来的业务需求。请注意，实际的应用组合目录可能会包含更多的细节和其他信息，例如应用的拥有者、应用的使用频率、应用的维护成本等。

2、接口目录

接口目录（Interface Catalog）在TOGAF中是一个结构化的文档或表格，用于描述、定义和记录组织内外的应用接口。这个目录通常列出了组织中所有已知的应用接口，并为每个接口提供了相关的详细信息。这有助于在整个组织中确保接口的一致性和互操作性。

接口目录通常包括以下内容：

接口名称：一个简短、描述性的名称。

接口描述：接口的简短描述。

来源应用：发起或产生数据的应用名称。

目标应用：接收或消费数据的应用名称。

接口协议：如 HTTP、FTP、SOAP、REST等。

数据格式：如 XML、JSON、CSV等。

数据内容：传输的数据的简短描述或摘要。

接口状态：如激活、待激活、已弃用等。

3、系统/组织矩阵

系统/组织矩阵（System/Organization Matrix）是一个工具，用于显示各个组织部门或角色与系统之间的关系。该矩阵有助于理解哪些部门或角色使用或拥有哪些系统，从而可以更好地协调和规划业务和IT资源。

一个简单的系统/组织矩阵可能像这样：

在此示例中，我们可以看到：

销售部门使用销售管理系统和销售分析工具。

人力资源部门使用人力资源信息系统。

财务部门使用财务管理系统。

管理团队可以查看所有系统的信息，但可能没有完全的使用权限。

这种矩阵形式的表示方法为组织提供了一个清晰、简洁的视图，展示了各部门或角色与各系统之间的关系。这有助于确保系统的正确分配、减少重复投资、优化许可证成本，并确保适当的培训和支持。

4、角色/系统矩阵

角色/系统矩阵（Role/System Matrix）是一个工具，用于显示组织内各个角色与他们与系统的关系。这个矩阵有助于了解哪些角色需要访问哪些系统，以及他们对这些系统的具体使用模式（例如，查看、编辑、创建等）。

一个简单的角色/系统矩阵可能如下所示：

在此示例中，我们可以观察到：

销售代表需要在订单处理系统中创建和编辑数据，在人力资源管理系统中查看数据，并在客户关系管理系统中进行各种操作。

人力资源经理在人力资源管理系统中有广泛的权限，在财务系统中可以查看数据，并且可以在客户关系管理系统中查看数据。

财务分析师在订单处理系统中可以查看数据，在财务系统中有创建和编辑的权限，并且可以在客户关系管理系统中查看数据。

客户服务代表可以在订单处理系统和客户关系管理系统中查看和编辑数据。

这个矩阵为组织提供了一个简明扼要的方式，来展示不同角色如何与各种系统互动。这对于理解和管理权限、培训需求和审计跟踪都非常有帮助。

5、系统/功能矩阵

在TOGAF中，系统/功能矩阵（System/Function Matrix）是一个工具，用于表示特定的系统提供了哪些功能。它帮助架构师和其他利益相关者理解系统的功能覆盖范围，并确保满足了所有预期的功能需求。

一个简单的系统/功能矩阵可能如下所示：

在此示例中：

电子商务系统提供了订单处理、库存管理和付款处理功能。

仓储管理系统专注于库存管理并提供报告生成功能。

财务系统处理付款并能够生成报告。

销售分析系统处理订单数据并提供报告功能。

通过这样的矩阵，组织可以清晰地看到各系统之间的功能交集或功能缺失，从而进行优化或整合。此外，当需要对某一功能进行更改或升级时，矩阵可以迅速提供哪些系统可能受到影响的信息。

6、应用互动矩阵

应用互动矩阵（Application Interaction Matrix）主要用于描述不同应用之间的交互和依赖关系。这种矩阵提供了一个结构化的方法来捕获和描述如何通过各种接口和服务在应用之间传递数据。

这种矩阵特别有助于：

（1）明确哪些应用需要与其他应用通信。

（2）确定数据流的方向和性质。

（3）提供有关应用如何协同工作以支持特定的业务流程的视图。

以下是一个简化的应用互动矩阵例子，假设一个制造企业有以下应用：

（1）销售系统

（2）生产计划系统

（3）仓储系统

（4）财务系统

矩阵可以如下：

解释：

（1）销售系统:

与生产计划系统交互：请求产品信息以确保产品可用性。

与仓储系统交互：查询库存确保产品库存量。

与财务系统交互：创建发票和管理付款。

（2）生产计划系统:

与销售系统交互：接受并处理销售订单。

与仓储系统交互：基于需求和库存发出生产订单。

与财务系统交互：查询产品的制造成本。

（3）仓储系统:

与销售系统交互：提供库存信息。

与生产计划系统交互：接受并执行生产订单。

与财务系统交互：提供库存产品的成本信息。

（4）财务系统:

与销售系统、生产计划系统 和 仓储系统都有交互，处理与财务相关的各种事务。

通过此应用互动矩阵，企业可以明确理解其不同应用之间的交互和依赖关系，从而更好地进行集成和优化工作。

7、应用通信图

应用通信图（Application Communication Diagram）描述了应用组件之间的通信关系。这些关系可以是调用、数据流或其他形式的连接。这种图有助于展示系统和应用之间的交互模式，以及它们是如何支持业务功能和进程的。

应用通信图通常包含以下元素：

（1）应用组件：如系统、模块或其他应用单位。

（2）通信关系：如数据流、调用或消息传递。

（3）可选地，外部用户或系统和其他接口。

案例描述：

假设一个简化的电商平台包含以下应用组件：

（1）客户前端（Customer Frontend）

（2）订单管理系统（Order Management System）

（3）仓库管理系统（Warehouse Management System）

（4）付款网关（Payment Gateway）

在应用通信图上，它们的交互可以描述如下：

（1）客户前端

用户在这里浏览产品、添加到购物车并下单。

当用户下单时，前端与订单管理系统通信，提交订单详情。

前端还与付款网关通信，处理支付。

（2）订单管理系统

接收来自客户前端的订单数据。

与仓库管理系统通信，通知出货。

一旦支付确认，通知付款网关。

（3）仓库管理系统

接收来自订单管理系统的出货请求。

更新库存信息。

（4）付款网关

接收和处理来自客户前端的支付请求。

一旦支付成功，通知订单管理系统。

这只是一个非常简化的示例，实际的应用通信图可能包括更多的细节、更复杂的应用和更多的交互模式。这种图为企业提供了一个可视化的工具，以理解应用如何互相关联，以及它们是如何支持特定的业务需求和流程的。

8、应用和用户位置图

应用和用户位置图（Application and User Location Diagram）是用来展示应用系统与用户的物理位置关系的。这种图的目的是确保应用的部署位置满足用户的性能需求，并可以实现应用之间的互动。它还有助于确定网络带宽需求。

例如，考虑一个大型企业，它的总部位于纽约，但在全球各地都有办公室。它使用一个集中的CRM系统、ERP系统和一个分布式的报告工具。一个简化的应用和用户位置图案例描述：

（1）物理位置

纽约 (总部)

伦敦

北京

孟买

（2）应用系统

CRM系统 (部署于纽约)

ERP系统 (部署于纽约)

报告工具 (分布式部署于各个办公室)

（3）用户

销售团队 (在所有办公室)

财务团队 (主要在纽约和伦敦)

人力资源 (主要在纽约)

这个图展示：

（1）CRM和ERP系统在纽约的数据中心有实体。

（2）报告工具在每个办公室都有实体或本地访问点。

（3）销售团队在各个地方都需要访问CRM。

（4）财务团队在纽约和伦敦需要访问ERP系统。

（5）人力资源在纽约访问ERP系统的HR模块。

这样的图有助于决策者理解网络带宽的需求，以及如果某个地方的系统出现问题，哪些用户将受到影响。这还有助于计划备份和灾难恢复策略。

9、企业可管理性图

企业可管理性图（Enterprise Manageability Diagram）主要描述了架构管理和控制要点，以确保系统的稳定性、性能、安全性和其他可管理性方面的要求得到满足。这些图表提供了对管理控制点（例如性能监控、安全性、日志记录、异常管理等）的高级视图，以及管理数据如何流动到企业中的各种支持系统（例如性能监控工具、安全工具、事件管理工具等）。

具体案例：

假设一个大型在线电商公司有以下几个主要的系统模块：

（1）用户服务

（2）商品浏览服务

（3）订单处理服务

（4）付款服务

（5）物流服务

以及以下管理工具：

A. 安全监控工具B. 性能监控工具C. 错误日志系统D. 用户行为分析工具

一个简化的企业可管理性图可能如下：

以上描述提供了一个概念性的视图，描述了这些服务与企业的管理工具之间的互动。在实际的企业可管理性图中，这些关系会被更加直观地表示出来，通常使用箭头来指示数据流的方向。

10、软件工程图

软件工程图（Software Engineering Diagram）是用来展示应用结构的。这些结构包括应用的软件组件、接口和与其他软件组件的连接。它为软件工程师和系统开发人员提供了一个视角，帮助他们理解和构建系统的软件部分。这种图的核心是展示软件组件之间的关系、依赖和流程。其目的是为了确保软件设计的完整性和一致性。

案例：在线图书商店

假设我们要为一个在线图书商店开发软件。以下是与此相关的软件工程图的简化描述：

软件组件：

（1）用户界面组件：处理用户交互、显示图书目录、购物车管理等。

（2）订单处理组件：处理用户的订单，包括支付、库存检查和订单状态更新。

（3）支付网关接口组件：与外部支付服务提供商进行交互，处理支付事务。

（4）库存管理组件：负责图书的库存检查和更新。

（5）推荐系统组件：基于用户的浏览和购买历史为其提供图书推荐。

关系和依赖：

（1）用户界面组件依赖于推荐系统组件来为用户提供图书推荐。

（2）用户界面组件将订单数据发送到订单处理组件。

（3）订单处理组件与支付网关接口组件交互，以处理支付。

（4）订单处理组件查询库存管理组件来检查图书的可用性。

在实际的软件工程图中，这些组件、接口和关系将被更详细地展现，还可能包括具体的方法、属性或操作。

11、系统用例图

系统用例图通常是一个高层次的图，描述了系统与其外部实体（例如用户、其他系统或外部组织）之间的交互。用例图能够描述系统的主要功能，并表明谁可以执行或受益于这些功能。

用例图包括以下元素：

（1）参与者：与系统交互的外部实体，可能是用户、其他系统或硬件设备。

（2）用例：系统的功能或动作，用椭圆表示。

（3）关系：表示参与者与用例之间的交互关系。

案例：假设我们要为一个图书馆信息系统创建一个系统用例图。

（1）参与者

读者

图书管理员

（2）用例

借书

还书

查找图书

登记新图书

注销图书

（3）关系

读者可以“查找图书”，“借书”和“还书”。

图书管理员可以执行所有的用例。

这个简单的用例图为我们提供了一个清晰的视图，描述了图书馆信息系统的主要功能及其与参与者的交互方式。

12、流程/系统实现图

流程/系统实现图（Process/System Realization Diagram）主要目的是确保某个业务流程或业务用例可以通过现有的系统和应用得到实现和支持。这种图的目标是描述系统的物理实现和系统如何支持某一流程或多个流程。

这种图通常显示：

业务流程或用例的一部分或全部

支持该流程的系统或应用组件

系统或应用组件之间的流动或交互

以HR招聘流程为例：

（1）发布职位

业务活动：HR部门确定了一个新的职位或空缺，需要在公开市场上进行招聘。

IT系统支持：HR管理系统中，HR人员可以创建和发布新的职位描述、职位要求等。

（2）筛选简历

业务活动：收到应聘者的简历后，HR人员对简历进行筛选，将符合条件的简历筛选出来。

IT系统支持：HR管理系统允许HR人员记录每个候选人的信息，简历筛选工具可以帮助快速筛选合适的简历。

（3）安排面试

业务活动：对于筛选出来的候选人，HR或相关部门人员会安排面试。

IT系统支持：电子邮件系统用于发送面试邀请给候选人；日历系统用于安排和通知面试时间。

（4）面试反馈

业务活动：面试官在面试后提供对候选人的反馈。

IT系统支持：面试评价系统允许面试官输入和保存他们对候选人的评价。HR管理系统会更新应聘者的状态。

（5）发放Offer

业务活动：对于成功的候选人，公司会发放正式的工作邀请或Offer。

IT系统支持：HR管理系统可以生成、记录和发送Offer。

（6）入职安排

业务活动：一旦候选人接受Offer，HR部门会为其入职做准备。

IT系统支持：HR管理系统可以安排入职培训、生成员工编号等。

流程/系统实现图将明确这些业务活动如何与各个IT系统相关联。它可以清晰地展示每个活动是如何由不同的IT系统支持的，以及这些系统之间如何交互来支持整个业务流程。

13、应用迁移图

应用迁移图（Application Migration Diagram）主要描述了从当前架构状态到目标架构状态的迁移路径。这个图为架构师、项目管理、IT策略决策者等提供了一个明确、可视化的工具，用以显示如何在多个项目或阶段中进行迁移以达到最终的目标状态。

具体来说，应用迁移图主要包括：

（1）现有的应用、组件或系统。

（2）预期的未来或目标应用、组件或系统。

（3）迁移路径，这可能涉及到某个应用的升级、合并、退役或替换。

（4）时间轴或项目阶段，以展示迁移的进展和时间表。

让我们考虑一个场景：

一个大型企业决定将其所有应用迁移到云环境以减少基础设施成本和提高可伸缩性。此外，由于某次收购，他们还需要整合新公司的一些应用程序。原始环境中有CRM, ERP, 和一个旧的财务系统。收购带来了一个新的BI系统和ERP系统。他们的目标是：

（1）迁移CRM到云并升级到最新版本。

（2）合并两个ERP系统，并在云中运行一个统一版本。

（3）废弃旧的财务系统，并在云中使用收购公司的BI系统。

（4）CRM集成新的BI系统

在此图中，我们可以看到各种迁移活动，以及由于整合和依赖关系带来的复杂性。这样的图形提供了关于项目计划和资源分配的见解，以确保迁移的成功。

14、软件分布图

软件分布图（Software Distribution Diagram）在TOGAF中主要是描述软件的物理部署以及如何在多种环境中进行分布。这种图的目标是确保所有的软件组件都被适当地部署到其所需的硬件环境中。这包括显示软件组件、关系、以及它们如何映射到硬件上。这有助于明确哪些软件组件部署在哪些服务器、设备或平台上。

假设有一个电子商务应用，它包括前端服务器、后端应用服务器、数据库服务器、以及一个CDN（内容分发网络）来服务其静态内容。以下是此案例的软件分布图：

在这个例子中：

数据中心内有前端Web服务器、应用服务器和数据库服务器。

CDN用于分发静态内容。

移动用户设备上的移动应用通过API与前端Web服务器通信。

前端Web服务器与应用服务器以及数据库服务器之间存在通信。

前端Web服务器从CDN的静态内容分发节点请求静态内容。

那么，应用架构定义这么多输出物的目的是什么？

1、全面性：应用架构需要涵盖许多方面，从高层策略到详细的实施细节。多个输出物确保了各个方面都得到了恰当的关注。

2、分层的设计：不同的输出物对应不同的关注点。例如，系统/功能矩阵关注功能的分配，而应用通信图关注应用之间的互动。这样的分层设计有助于简化复杂性。

3、有效沟通：不同的利益相关者需要不同的信息。例如，业务人员可能更关心应用组合目录，而技术团队可能更关心应用互动矩阵或软件工程图。为每个群体提供专门的输出物可以确保他们得到所需的信息。

4、灵活性和模块化：分解成多个输出物意味着当组织的某个部分发生变化时，只需更新或修改特定的输出物，而不是整个架构。

总的来说，应用架构的多个输出物提供了一个全面、详细和模块化的方法来描述和管理组织的应用景观。这确保了有效的沟通、明确的决策路径、和更好的架构治理。

大家平时看到的很多应用架构图表现形式千变万化，但无论怎么变化，核心内容大都逃不掉TOGAF定义的14种制品的内容范围，下面举例说明：

1、某WeB中间件功能架构图，其实就是系统/功能矩阵的视图版本。

2、某支付系统架构图，看起来挺复杂的，其实就是系统/功能矩阵、应用通信图、应用互动矩阵、角色/系统矩阵的组合。

3、“4+1”视图模型是Philippe Kruchten提出的，它为软件架构定义了五种主要视图：逻辑、实现、过程、部署和用例视图，其与应用架构交付物其实也有很好的对应关系，如下所示：

（1）逻辑视图

应用通信图：展示了应用组件间的通信和关系，这与逻辑视图的关注点相似。

系统/功能矩阵：展示了系统与其支持的功能之间的关系，这与逻辑视图的关注系统功能有关的部分相似。

应用互动矩阵：展示了应用间的互动，这也是逻辑视图的一部分。

（2）实现视图

软件工程图：这个图描述了系统的软件结构，包括软件组件、它们的依赖关系以及与之相关的构建和发布流程。这与实现视图的核心概念非常相似。

软件分布图：此图描述了软件如何分布于物理硬件之上，但它还涉及软件组件及其依赖关系，这也与实现视图的部分关注点相似。

（3）过程视图

应用通信图：展示了应用组件之间的通信路径和方法，这涉及到动态的信息交换，与过程视图关注的运行时交互相似。

（4）部署视图

应用和用户位置图：这个图描述了应用的物理部署以及用户的物理位置。它提供了有关哪些应用部署在哪里，以及用户如何与它们互动的信息。这与部署视图的主题非常相似。

软件分布图：此图描述了软件如何分布于物理硬件之上。它直接关注于软件组件与硬件资源之间的映射，这与部署视图完全一致。

三、应用架构的构建

TOGAF给出了ADM的架构开发方法，这种方法同样适用于独立的应用架构开发，企业可以基于自身实际对ADM进行裁剪后进行。这里以供应链管理系统升级为例，演示如何使用TOGAF的ADM来创建一个应用架构的交付物，即系统/功能矩阵：

1. 准备阶段 (Preliminary Phase):

输出物:

架构原则: “采购管理集中化、标准化、一体化”，“流程高效”。

架构框架：采用TOGAF架构方法、ArchiMate建模工具和相关系统、流程文档模板。

关键利益相关者列表：上级管理层、供应链经理/主管、采购团队、库存和仓库管理者、外部合作伙伴、财务团队、IT团队等。

2. 架构愿景 (Phase A: Architecture Vision):

与公司领导、采购部门、物流部门等相关部门协作，明确他们希望系统达到的目标和功能。

预期输出：“集成性”、“统一性”、“智能化”。

3. 业务架构 (Phase B: Business Architecture):

通过与各部门沟通，绘制业务流程图

识别和记录核心业务功能，如“采购寻源”、“需求预测”、“物流配送”等。

输出：业务流程图、核心功能列表。

4. 应用架构 (Phase C: Application Architecture):

现有架构评估：发现现有的功能分散在“供应链管理系统“、”MIS系统”、“供应商门户系统”、“合同管理系统”等。

定义目标应用架构:

根据业务架构输出，未来的供应链管理系统需要支持的功能：“库存管理”、“订单生成”、“需求提报”等。

识别和定义系统组件：例如“供应链管理系统”、“MIS系统”、“决策支持系统”。

创建系统/功能矩阵。在其中，所有系统都被列出，并对每个功能进行标记，以指示该系统是否支持该功能。

5. 机会与解决方案 (Phase E: Opportunities & Solutions):

发现“需求提报”和“订单生成”落在了MIS系统，“采购合同”和“供应商注册”分别落在了合同管理系统和供应商门户系统，“采购分析”落在了供应链管理系统，这些功能与原有系统的定位不符，供应链功能割裂，导致流转不畅，考虑重新归位。

输出：一系列建议和机会，以优化系统功能。

6. 迁移规划 (Phase F: Migration Planning):

基于系统/功能矩阵和机会列表，根据系统间功能模块的业务关联程度选择业务依赖较高的功能模块作为优先建设的目标，制定迁移策略

第一步：整合现有供应商门户、合同管理系统相关功能到新供应链系统

第二步：迁移并升级需求提报、库存管理等功能到新供应链系统，与MIS系统做好集成

第三步：决策支持系统新增采购分析等能力