企业4A架构：业务、应用、数据、技术的完美融合

Posted 2024-06-7 Updated recently

By Eric

20~26 min read

见字如面，与大家分享实践中的经验与思考。

企业4A架构是一种综合性的企业架构模型，主要包括四个核心要素：业务架构（Business Architecture, BA）、数据架构（Data Architecture, DA）、应用架构（Application Architecture, AA）和技术架构（Technology Architecture, TA）。这种架构模型旨在帮助企业更好地理解和管理其业务、数据、应用和技术方面的复杂性，从而提高整体运营效率和竞争力。

BA、TL或架构师在对一个系统进行架构设计时，可以按照4A架构模型进行设计。本人在阅读完《华为数字化转型之道》后，书中也提到了4A架构，接下来一起看下不同公司或组织是如何理解这些概念的，以及如何在我们实际工作中去使用。

4A架构

从架构专业角度，通过业务架构、信息架构（数据架构）、应用架构和技术架构4个方面入手，对架构蓝图进行细化设计。

架构的定义：

一个架构是系统的基本结构，它由多个组件以及它们彼此间的关系而组成，并且在一定环境和原则下进行设计和演变。

问题：如果不做企业架构规划会带来什么？

系统烟囱式建设，系统边界模糊互相扯皮，系统重复建设，企业内多套标准或者标准不统一，IT系统之间集成困难，难以更上市场需求以及功能的快速迭代。

TOGAF

目前业内最广泛、最流行的企业架构（Enterprise Architecture）就是 TOGAF (The Open Group Architecture Framework)。下面是 TOGAF 10.0 Metamodel 概览图：

TOGAF 的核心就是大家熟知的四大架构：业务架构、数据架构、应用架构和技术架构。

华为“一体四面”企业架构

“一体”指的是瞄准业务目标实现或业务问题解决，由架构师团队协同进行框架设计；“四面”指业务架构、信息架构、应用架构、信息架构、技术架构4个关键要素。

业务架构（Business Architecture，BA）

业务架构是对业务的结构化表达，描述组织如何运用业务的关键要素来实现其战略意图和目标。业务架构由价值流、业务能力和业务流程等几大要素组成。在规划阶段，规划团队可以从价值流出发，识别每一个价值流所需的关键业务能力，进而识别哪些能力可以重点引入数字技术进行业务模式重构，提升业务能力水平。

要点：项目战略/愿景、AS-IS流程图（若有）、TO-BE流程图、服务蓝图、产品功能全景等

信息架构（数据架构）（Information Architecture，IA）

信息架构是以结构化的方式描述在业务运作和管理决策中所需要的各类信息，以及这些信息之间互相关系的一套整体组件规范。业务对象是信息架构的核心，在规划阶段，可以重点分析“产品、客户、合同、订单、员工”等关键业务对象以及分布，分析这些业务对象是否已经在IT系统中进行了管理，了解这些业务对象在系统间的传递是否顺畅，以及是否在数字世界中创建了数字镜像。

要点：数据模型设计、数据治理、数据组件、数据服务、数据平台、数据湖等。

应用架构（Application Architecture，AA）

应用架构识别和定义了支撑业务目标达成所需的IT系统，以及这些IT系统的定位和周边IT系统的集成关系。在规划阶段，应用架构重点关注用什么样的联接平台来构建来构建客户和用户体验，以及采用什么样的IT系统承载数字化转型所需的关键业务能力。

要点：业务到IT的转换，识别支持各业务功能所需要的应用程序、组件、外围IT系统等。

技术架构（Technology Architecture，TA）

技术架构定义了一系列技术组件，代表了各种可以从市场或企业内部获得的IT平台和基础设施资源。在规划阶段，技术架构首先需要关注企业应该引入哪些数字技术，同时需要关注各种业务场景对IT平台和基础设施的需求。

要点：根据应用架构，进行技术支撑分析，例如技术选型、代码分层架构、PaaS平台、云原生技术、DevOps实践、微服务设计、部署架构等。

这里华为的信息架构与我们常见的理解有些差异，一般叫数据架构。而在TOGAF中数据架构和应用架构合并为信息架构。

4A架构与DDD

我们经常使用4A架构理念去做架构设计，那么是否结合 DDD 进行关联设计呢？

这里通过一些具体的例子来了解它们之间的关联：

业务架构（Business Architecture）：
- DDD强调通过领域专家和开发团队的合作来定义业务需求。业务架构中的关键流程、功能、角色和能力可以通过DDD的领域模型来描述。
- 例如，在银行业中，可以有“客户服务”、“贷款审批”和“账户管理”等领域，这些领域可以通过DDD的边界上下文（Bounded Context）来划分。业务架构中的流程图、业务能力模型等可以映射到DDD的领域模型中。
应用架构（Application Architecture）：
- DDD中强调的边界上下文和聚合（Aggregate）概念与应用架构中的模块化设计相契合。应用架构中，系统之间的接口和服务划分可以通过DDD的边界上下文进行管理。
- 例如，电商系统中的“订单处理”和“库存管理”可以是两个边界上下文，每个上下文中都有相关的聚合和服务，这与应用架构中应用系统的划分相符。
数据架构（Data Architecture）：
- DDD中的领域模型和实体通常代表业务中的关键概念，这与数据架构中的数据模型、实体关系模型相对应。通过DDD的领域模型来设计数据结构，可以确保数据架构与业务需求一致。
- 例如，在客户关系管理系统中，客户实体可以有多个属性，如姓名、地址、订单历史等。数据架构可以从领域模型中提取这些实体，构建数据库表结构。
技术架构（Technology Architecture）：
- DDD的分层架构与技术架构有很强的对应关系。DDD中的应用层、领域层、基础设施层等与技术架构中的软件架构、开发框架、通信技术等相关。
- 例如，在一个微服务架构的项目中，应用层可以与REST API相对应，领域层可以包含业务逻辑和领域模型，基础设施层可以包含数据库和消息中间件。这种分层架构可以反映在技术架构的设计中。