EA企业架构、4A架构，业务架构、IT 架构之间是什么关系？

图片

大家好，我是人月聊IT。今天继续聊企业架构方面的话题。即对于EA企业架构、4A架构，业务架构、IT 架构之间是什么关系？这些架构之间又有哪些区别和联系？

首先整体回答下问题再展开详细回答。

企业架构一般谈4A架构，即业务架构，数据架构，应用架构和技术架构

。如果只谈业务架构和IT架构。那么IT架构包括了数据架构，应用架构和技术架构。但是在当下数字化转型下，为了更好体现数据驱动，实际数据架构工作应该提前，不应该将数据架构作为IT架构的一部分，数据架构同时支撑业务架构和应用架构。

如果谈TOGAF里面的业务架构，其实没太强调业务建模，但是BABOK业务架构指南里面实际有完整的业务对象和业务对象建模的描述。有了业务建模实际业务架构更好的承接应用架构和数据架构。

我原来有一篇文章专门谈企业架构中的4A架构的关系和集成，可以参考我公众号的历史文章文章。新企业架构更加强调集成架构的作用，原来集成架构是属于应用架构的一部分，实际集成架构应该从应用架构中拿出来单独规划和设计。

企业架构4A架构的基本概念和关系

企业架构（Enterprise Architecture EA）是从企业全局的角度审视与信息化相关的业务、信息、技术和应用间的相互作用关系以及这种关系对企业业务流程和功能的影响。从这个定义至少可以看到重要的两点，其一是业务、信息、技术和应用的融合；其二是EA包括了业务和IT两个重要的方面，是从全局考虑业务和IT的集成。企业架构是一个多视图的体系结构，它由企业的业务架构、信息架构、应用架构和技术基础架构共同构成。

我们常说的4A架构就是业务架构、数据架构、应用架构和技术架构，其实去理解4A架构的集成核心，你仍然要去参考企业架构这本书里面谈到的企业架构元模型。大家看我今天这张图的时候也能够感觉到我其实这张图也是依托在企业架构元模型的基础上，只是做了一些调整和优化。

首先我们还是来看业务架构业务域，大家都知道在业务架构里面其实有三个核心的内容，一个是价值流，一个是业务能力，一个是业务流程。价值流往往就是顶端的流程，业务能力的分解往往是2~4级，对于详细的业务流程的分解往往就到了5~7级，只是原来在业务架构里面，我们没有太强调流程架构，实际上从架构的Y模型里面可以看到，在业务架构里面是有两个视角，一个就是业务能力的视角，一个是业务流程的视角。

所以说我在这个地方专门补充了端到端流程，也就是说2~4级的业务能力，它往往都会有一个端到端流程进行对应，而更细化的5~7级的业务流程往往到了实际的业务活动和操作层面。对于5~7级的流程，我们详细的去做流程建模和梳理的时候，里面就是有三个关键的元素，一个是业务对象，接接着就是业务活动，业务规则和业务角色，而这4个东西刚好是我们在业务架构里面做详细的业务建模的关键的内容，在业务建模的时候识别出了关键的业务对象，这个业务对象就会导入到我们数据架构里面去了。

业务架构和数据架构集成方面，业务对象映射到数据架构以后，一般就会映射到我们讲的数据实体或者是概念模型，这个概念模型进行详细的数据建模，会形成逻辑模型和物理模型，这个是业务域和数据域之间关键的集成和映射关系，它核心是业务建模和业务对象驱动的。

业务架构到应用架构集成方面，我们刚才讲到了，在业务建模里面会拆分出业务对象、业务活动、业务规则、业务角色这4个核心的要素。这4个核心的要素我们去详细考虑it实现的时候，一定会映射到它相关的应用功能。这个应用功能不是单独的和业务活动业务规则做映射，而是和完整的4个要素去做映射。有了应用功能以后，再上层我们做聚合会形成应用组件，包括当前你做微服务拆分，可能会涉及到微服务的组件，应用组件再朝上走会形成相关的应用系统。

数字化转型下数据架构的新定位和价值

在数字化转型的背景下，数据架构的角色和定位发生了重大变化。原来我们只划分为业务架构和IT架构的时候，大家看到数据架构一般会把它划分到IT架构的范畴，但是对于数据架构，实际上它是业务架构和IT架构两者之间的一个关键的衔接点，对于数据架构里面的数据主题域的分析，数据的业务对象梳理和分析，这个实际是你业务建模阶段要做的事情，而对于数据架构里面详细的数据的逻辑模型，数据的物理模型和数据库设计，这些内容自然而然就过渡到了IT应用架构规范设计。

数据架构是业务和IT架构的关键衔接点。从企业业务战略到业务目标，从业务目标梳理业务场景，基于业务场景我们要去考虑应该有哪一些关键的能力来支撑这些业务场景，这个粗粒度的能力你要去做进一步的分解，基于端到端流程梳理和分解，分解出一级流程、二级流程、三级流程、详细的业务功能点和业务操作，然后形成的业务架构；同时，在业务架构形成以后，我们要去做关键的CRUD分析，这个是我前面讲过那个内容。

对于数据驱动一定要理解为两个方面的内容，一个是数据驱动决策，这个是传统BI做的事情。一个是数据实时反哺业务，数据驱动业务，这个是数字化转型下更加强调数据价值挖掘的重点。所以我今天谈的数据驱动，更多的是在谈数据如何更好的驱动业务。要明白数据驱动决策，往往是形成了企业全局或业务域的KPI指标，并提供各种维度分析工具，方便管理层发现问题，并基于问题去改进已有的业务流程。而数据驱动业务，是通过数据加工处理建模后，形成的数据服务能力，需要在每一笔，每一次业务交易中都要用到。

虽然数据驱动决策和数据驱动业务，都存在底层数据存储汇总，数据的统一建模，或者数据分析模型建设等。但是最大的区别就是数据服务要在业务协同中，实时的使用，来作为业务协同中的关键卡点，或关键分析后数据的提供。了解清楚这个后，我们再来看一些数据驱动业务的实际场景。

在数字化时代我们很强调数据驱动，但是怎么样更好地理解数据驱动。我们可以简单理解一下，在你原来信息化时代的时候，往往很多时候都首先是我们制定相应的流程规范和标准，把它固化到相应的信息系统里面，然后是人执行相应的流程规范，执行完以后将相应的数据录入到系统，形成信息流，最后信息流执行完了以后再沉淀相应的数据，最后才是通过数据去做相应的辅助的决策分析。

所以说原来的线条往往是先有流程标准制度，再有人的执行，人的执行再形成信息流，信息流最后再落地到数据，这个是原来我们通常的一个做法。但是在数字化时代这个做法就会发生很大的一个变化。这个变化主要会体现在哪些地方呢？在数字化时代你会发现它整个的流向它是反着的。也就是说首先是在数字世界里面形成了相应的信息的规范和相应的数据，通过数据和相应的调度规则，它自动的去产生信息流，然后通过信息流反向的推动人去执行。

业务架构的演进：从TOGAF到BABOK的业务建模

要注意业务架构是一个完整的概念，是有多个架构文档，形式化的图形建模共同完成的。只要是企业内涉及到业务的方方面面，人，事，物，时间，环境等都可以在业务架构描述中找到详细的内容或者其它内容。

业务架构不等同于流程架构，流程架构是业务架构的一个部分；业务架构不等同于业务建模，业务建模仅仅是形成业务架构的一种方法；采用形式化的方法清晰的描述清楚企业业务即业务架构要完成的事情。

业务架构的形式可以以价值链或端到端的流程分析为切入点，组织结构和岗位角色建模是业务架构的一个基础内容，在此基础上围绕流程和数据两条线相互交互融合而展开，流程涉及到子流程，业务活动和业务操作；数据涉及到数据域，数据主题和分类，具体数据的概念模型和逻辑模型等。或者可以简单地说为刚开始是基于价值链分析，端到端流程的高端流程建模；在流程分解到一定程度后进入到业务用例分析和建模，业务对象分析和建模。

在流程建模过程中，特别是到分解后的下级流程，仍然是推荐采用EPC事件流程链的方法进行建模。EPC流程图包含了流程活动，事件，岗位角色，业务对象等多个内容并形成一个整体。更加方面对企业内业务流程中的各个关联事物进行全面的理解。所以整个流程建模的思路可以是高端价值链-》传统的流程图-》EPC流程图。

在前面这些过程或活动中，可以形成大量的输出文档和目录清单，包括了流程清单，每个流程的详细活动描述清单（活动，输入，输出，业务对象，岗位角色），业务功能或活动清单，组织信息清单，岗位和角色信息清单，业务对象详细描述清单等。如果仅仅是端到端流程分析来输出，那么这个清单不完整，因为有些业务功能或活动不在端到端流程上面，比如一些业务部门的日常例行管理工作，监控工作，统计分析工作等。这也是业务架构不能单纯的从顶向下完成的原因，为了弥补这个问题，还需要的就是对于企业内的各个业务部门进行业务调研和访谈，了解各个业务部门的业务目标，各个业务岗位的业务职责和工作内容，进一步识别出不在端到端流程和流程分解节点上的内容。由顶向下+由底向上才可能形成一个完整的业务架构需要的内容。

如果仅仅是上述这些内容，那还不是一个完整的业务架构，在ARIS流程建模或TOGAF中都没有专门提到CBM组件化业务模型，这实际是基于SOA的思路做业务架构的一个很关键的内容。业务能力组件化和组件能力服务化。业务组件是企业内部一个高内聚的能够完成核心的一个业务价值的业务能力单元，这个业务组件将以业务服务的方式朝外部提供服务能力。因此各个业务组件之间本身就应该是高内聚，松耦合的。

业务架构到应用架构的转换逻辑

在业务架构梳理完成以后，我们自然而然就会过渡到应用架构的梳理。很多时候大家看到业务的功能架构和应用的功能架构觉得两者之间长得很类似，那么，他们之间有哪一些关键的区别，我们来看一下。第一个关键区别：增加了上下红色内容。从业务架构过渡到应用架构以后可以看到在应用架构里面，上下红色部分往往都是多出来内容。

比如在应用架构的整体架构图里面，我们就会有底层的IAAS整个云数据中心资源池的规划，IAAS上面的是PAAS技术平台的规划，比如说我们有我们的4A平台，流程平台，集成平台，大数据平台，这些往往都是跟业务完全不相关的内容，但是我们在应用架构规划的时候，我们需要去梳理。同时在应用架构规划里面，往往还会增加上层的应用门户的内容，或者是BI决策层的一些内容，这些往往是在业务架构的梳理规划里面是没有的内容，这是第一个关键的区别点。

第二个关键的区别点，当业务架构映射到对应的应用架构里面的业务系统的时候，主要有两个区别点，第一个区别点是它的颗粒度有可能不一样，比如说在业务架构里面，我们都叫供应链管理，但是到了应用架构，已经拆成合同管理系统，采购管理系统，物流管理系统。当然，也有可能是在业务架构梳理的时候，你梳理的是采购管理，物流管理，合同管理，但是到了应用架构以后，我把多个业务域的一些功能合并成一个大的供应链系统，就是从业务到应用系统之间映射颗粒度出现了变化。

第二个区别点，同一个业务架构里面的业务组件可以同时映射到应用架构中的多个应用系统或应用组件。任何一个企业在做信息化IT建设时候，往往都会首先建一个基础的ERP系统，而ERP系统往往是一个大而全的系统，它包括了计划、采购、研发、生产、人力资源管理、市场营销很多的业务功能模块，但是随着整个企业业务的发展，你会发现它会在ERP系统外围衍生出很多其他的业务系统，比如说我们的APS系统、财务共享类的系统、MES系统，这些系统往往他仅仅是ERP系统的外延。这时你会发现我要实现业务架构里面一个核心财务的能力，你会看到这个财务的能力既包括了ERP系统的财务管理应收、应付、总账模块，也包括了我在应用架构里面外挂的财务费控系统、财务预算系统、财务资金系统，这个也是导致了我们实际看到的业务架构和应用架构之间它的匹配和映射，出现了一个比较大的变化点。

应用架构还包括了集成架构规划设计。在业务架构过渡到应用架构以后，应用架构本身既包括了应用功能架构，又包括了应用集成架构，那应用集成架构怎么来的呢？还是在前面，我们经过场景梳理能力，基于能力梳理流程，基于流程的梳理，我们形成了业务架构和核心的业务功能模块、业务组件以后我们就要去考虑端到端的流程，在各个大的业务组件是怎么样去协同和交互的。

数据架构在业务与应用架构间的承上启下作用

数据架构是业务和IT架构的关键衔接点。首先从企业业务战略到业务目标，从业务目标梳理业务场景，基于业务场景我们要去考虑应该有哪一些关键的能力来支撑这些业务场景，这个粗粒度的能力你要去做进一步的分解，基于端到端流程梳理和分解，分解出一级流程、二级流程、三级流程、详细的业务功能点和业务操作，然后形成的业务架构；同时，在业务架构形成以后，我们要去做关键的CRUD分析，这个是我前面讲过那个内容；那么对于数据架构，是企业架构里面另外一个很关键的线条，在原来我们只划分为业务架构和IT架构的时候，大家看到数据架构一般会把它划分到IT架构的范畴，但是对于数据架构，实际上它是业务架构和IT架构两者之间的一个关键的衔接点，对于数据架构里面的数据主题域的分析，数据的业务对象梳理和分析，这个实际是你业务建模阶段要做的事情，而对于数据架构里面详细的数据的逻辑模型，数据的物理模型和数据库设计，这些内容自然而然就过渡到了IT应用架构规范设计。

所以当你去看数据架构的时候，一般你会发现一个关键的主线就是数据架构最顶层就叫数据的主题域分析，从数据主题域的分析到数据的概念模型，从概念模型到逻辑模型，从逻辑模型到物理模型。数据的主题域的分析，这个主题域可以理解成业务价值链的业务域，比如说任何一个企业，会分人力资源、市场营销、研发，供应链，每一个业务域里面，我就会去分析他核心的业务对象或者叫数据对象，比如说在人力资源里面有人员、组织，在市场营销里面有客户、订单，在研发里面有bom、有物料，在供应链里面有订单、合同，这样就完成一个简单的数据主题域的分析。

在数据的主题域分析完了以后，我们就会过渡到核心概念模型，概念模型类似于传统在IT软件开发里面的业务对象建模，相当于ER的实体关系图，因为在概念模型阶段，我只要识别出核心的业务对象和业务对象之间的关系就足够了，比如说对于供应链域我们会识别出关键的有项目对象、合同对象、订单对象、供应商对象，项目跟合同之间可能是一对多的关系，合同跟订单可能又是一对多的关系，到了这个粒度，我们的概念模型就已经建完了。

从概念模型到逻辑模型，我们一般要拆分到具体的数据表的粒度，比如说对于采购订单，在概念模型的时候就是一个对象，但是到了逻辑模型的时候，我要拆分出采购订单实际包括了采购订单头、采购订单联系行、采购订单分配行、采购订单发运行，这样形成一个完整的采购订单的四层表结构。

在逻辑模型做完以后，我们还要过渡到在软件开发里面的物理模型，物理模型阶段，那就需要去对每一个数据库表，每一个字段类型字段约束进行详细的设计，到了物理模型设计出来以后，他已经完完全全可以支持我们IT系统的开发和建设，这个是我们常说的数据架构里面最核心的一条主线。

那么第二条主线是什么呢，就是我刚才讲的，通过流程分析，通过CRUD矩阵分析，我们会去看每一个数据对象和业务功能之间的耦合关系，把这个耦合关系梳理完了以后，我们就会去结合应用架构，应用架构有合同系统、采购系统、物流系统，这些更多的是叫应用功能架构，它解决了业务功能的聚合，但是它没有解决数据的聚合。

在应用功能架构分析完以后，我们结合CRUD矩阵分析，还要去分析哪一些数据会聚合到一个大的数据库里面，比如哪一些数据会聚合到采购系统的数据库里面，每一个数据对象必须要找到他实际的owner究竟是哪一个IT系统或者是应用系统，这个是我们在去做数据架构梳理以后必须要完成的另外一个重要的工作。

通过以上分析我们可以看到，企业架构中的4A架构是一个有机整体，业务架构、数据架构、应用架构和技术架构之间存在着紧密的互动关系。在数字化转型背景下，数据架构的地位和作用更加凸显，它不再是单纯IT架构的一部分，而是连接业务和IT的关键桥梁。业务建模作为业务架构的核心，通过详细的业务对象识别和分析，为数据架构和应用架构提供了坚实的基础支撑，确保了企业架构各层次之间的有效衔接和协同工作。