今天准备分享下业务中台规划建设方法论对传统企业架构规划方法的改进。对于中台建设方法论简单来说应该结合如下几个方面的核心思想，具体包括：

SOA思想：重点体现纵向到横向，服务识别和基于服务编排和组合

微服务思想：体现构建的时候传统单体进行微服务化，大拆小

中台思想：体现在构建业务和应用架构的时候，共性业务能力下沉

云思想：重点体现由传统的接口服务集成，转变为集中化建设和能力服务开放

对于传统企业架构思想可以看到基于业务驱动IT思路，从端到端流程分析出发进行企业核心的业务流程活动，业务对象识别，然后再规划业务架构，数据架构，应用架构和技术架构，在应用架构中又包括了我们常说的集成架构规划。

传统企业架构方法核心说明

从顶朝下和从底朝上结合

在企业架构规划中，架构分析的入口点，我们认为合理的方式是从整体的端到端流程分析入手，细化到各业务域的端到端，经过不断的流程分解到3-4级流程，最终细化到最底层流程（如EPC流程，它是流程，本身也是业务功能）。另外的一个方式是直接从业务活动信息收集入手，如根据组织架构和岗位职责直接收集业务功能点。

第一种方式既看到面又看到点，从上到下层层推进；而第二种方法则是容易只看到点，但无法贯彻整个企业端到端流程。

当然，流程分析并不一定能够涵盖所有的业务功能点，因为有些业务功能本身便是最底层的EPC流程，往往并不是从高端的端到端流程分解而来，如用章管理是一个业务功能和EPC流程，但并不一定能够挂接到高端流程上面。

这也是端到端流程分析要注意点，即从顶朝下和从底朝上要相互结合。高端流程分析和分解是建立全局思维，但是仍然要借助第二种方法收集完整的业务和活动。

从业务活动分析中发现业务对象

流程到子流程，再到业务活动，业务活动中承载的是业务单据和业务实体。需要对业务实体进行抽离，进行数据层面的数据建模和分析。分析在流程各个阶段和活动中产生的业务实体之间的关联和依赖关系。业务域对应到数据域和数据分类，进一步可以分析到具体的概念模型或逻辑模型。

流程分析偏业务操作和事件，而数据正是业务操作的对象。SOA中强调操作和数据解耦，则正好是分析的两个维度。

业务组件划分-微服务的雏形

业务架构中的业务组件划分强调的是业务本身的高内聚和松耦合原则。

对于任何一个业务域基本有两种类型，一种是数据驱动型，一种是工单任务型。如资源、资产等核心数据对象，业务操作层面重点是对数据对象实现全生命周期管理。因此业务组件划分基本遵循底层为基础数据支撑层，上层为生命周期管理层，覆盖该数据对象的核心生命周期阶段。这是业务组件划分的一个基本思路。

对于业务架构的构建，特别是我们对某个业务域并没有深入的理解前，最好的方式就是流程驱动分析，抽离数据进行数据建模，然后进行CRUD矩阵分析，分析数据和业务功能的关系。对底层的业务功能进行组合满足高内聚松耦合的原则，然后从底向上的对细粒度的业务功能进行组合，形成高内聚的业务组件。当然在整个过程中往往我们会参考业界标准的业务架构参考模型，如供应链的scor模型，电信行业的etom模型等。

业务架构完成后，将会过渡到应用架构，业务架构和应用架构基本是对应的。

其中较大的差别点在于业务架构只关注业务，业务本身分为功能性需求，非功能性需求。非功能性需求中包括了平台层面的支撑需求，即应用的集成支撑和数据的集成支撑，公共平台层功能等。另外还包括了纯技术层面的非功能性需求。对于前者需要体现到应用架构中我们往往会分为技术支撑平台和应用支撑平台。

技术支撑平台包括了安全，管控等；而应用支撑包含了数据平台，集成平台和流程平台等。应用架构一般会分为支撑层，应用层和决策层。

服务架构需要考虑业务系统间的集成点。这个集成点的分析我们期望可以将端到端流程结合应用架构中的业务系统，CRUD矩阵分析形成跨业务系统的跨系统交互流程图。这种流程图已不是纯粹业务层面的流程图，而是做系统交互分析的跨系统交互流程图。所有的跨系统交互点则为流程驱动下的业务集成点。而CRUD矩阵分析则帮助我们分析出数据驱动的数据集成点。前者为业务服务为主，而后者即以数据服务为主。两者在分析完备后最终都体现到应用集成架构中。

业务中的平台级和非功能性需求转化到应用架构中的底层支撑层，对底层支撑层中的核心技术进行抽取，最终转化到一个完整的技术架构。技术架构和业务无关，它所提供的是底层技术支撑层能力。

技术架构逐步转化到公共的平台层，提供核心的资源池能力。业务组件本身转化为能力单元，业务组件由平台资源承载，提供业务服务能力。业务服务最终又可以通过灵活的配置形成完整的业务应用。因此我们所说的解耦不仅仅是业务组件间的横向解耦，还包括了业务组件到底层平台，业务组件到上层应用间的纵向解耦。

对传统企业架构规划方法的优化

从上面我们对传统企业架构规划方法的核心逻辑说明来看，传统EA企业架构规划方法仍然相当完整，但是我们也需要看到在整个SOA和云架构思想下，在中台和微服务思想逐步演进的过程中，传统的企业架构规划也需要进行优化和调整。

传统企业架构规划方法仍然是按照传统遗留大单体应用垂直纵向建设的模式来进行的规划，同时很少考虑到了集中化的云平台建设模式。然后在当前企业的信息化规划建设，平台+应用构建模式已经逐步成为主流。

同时在平台+应用分层构建的模式下，进一步将传统应用大单体拆分为多个独立自治的微服务进行独立建设和管控，而对于平台层则进一步融入云平台建设思路，包括最近1到2年我们谈的最多的面向云原生的解决方案。

这个云原生已经从传统的IaaS云平台过渡到了完整的PaaS云平台和技术服务能力提供。

基于以上分析，可以看到传统企业架构优化点主要体现在：

从纵向到横向：架构规划分析需要从纵向过渡到横向分层规划设计

数据库拆分：业务架构和数据架构结合分析，在规划阶段形成数据库拆分

业务和应用架构融合：在剥离了平台后，进一步融合业务和应用架构

基于业务组件规划设计微服务

技术架构规划新增加PaaS和技术中台服务内容

以上即是我们考虑需要进行优化的一些关键点。基于上面的思路，我们可以看到中台规划和建设的方法论可以进一步简化为下图。

从上面图可以看到，对于流程分析和数据架构分析仍然无大变化，核心都是为了划分业务组件和微服务模块。但是对原来的业务架构和应用架构可以合并，原因就是传统应用架构的平台层已经将其移到技术架构规划中。其次就是技术架构不再是单纯的IT基础设施架构，而且需要包括我们当前说的PaaS云平台和面向云原生的整体解决方案。

在整个中台建设规划中可以看到业务中台规划简单的重点仍然体现在两方面：

其一是业务中台中的微服务如何拆分

其二就是微服务究竟应该暴露哪些独立的可复用API接口

而对于技术中台可以看到，实际上包括了多个方面的内容，这个在我们前面的文章也有提到，即微服务开发框架和环境，DevOps支撑平台，容器云平台，共性技术服务能力，API网关和能力开放平台，运维监控平台。这些才构成一个完整的技术中台，如下图：

中台构建思路-横向分层和纵向拆分

大家都比较清楚，中台架构咨询和建设来源于互联网企业，然后逐步转入到传统企业内部，对于互联网企业基本也给出了中台建设的初步思路和方法论，但是如果简单的照搬这些思路到传统企业内部，往往行不通。那么我就需要首先分析互联网企业和传统制造类企业在业务和IT建设中的一些差异。

初步比较关键点如下：

IT系统受众：互联网后台管理用户少，而外部用户多；而传统企业大部分为内部用户。

前台应用的敏捷性：互联网对前台敏捷度要求高，而传统企业前台应用敏捷度要求并不高。

业务逻辑复杂度和强事务要求：互联网相对低，而对于传统企业IT系统业务逻辑更复杂。

当我把上面几点想清楚后，实际上对于传统企业中台构建的差异点或思路基本就想清楚。对于第1和2两点刚好对应到我们在进行横向分层构建上的差异，第3点对应到纵向拆分上的差异。具体为：

横向分层上：不是所有传统IT都要转为中台+前台模式，而是需要考虑受众和敏捷性要求

纵向上：不是微服务拆分的越细越好，而是要考虑业务逻辑和事务处理需求

如果企业内部中台构建不考虑上面两点，而是完全照搬互联网企业的中台多个中心+前台应用的构建模式，那么就是走极端，为了中台而中台。因此在企业中台构建时候一个关键点即：企业中台的构建不能脱离实际业务需求和场景，所有技术选择一定要追溯业务需求和目标。

横向分层：中台和前台分层构建思路上的思考

首先我们来看下横向分层上面的思考，即中台+前台构建思路上的差异思考。

前面已经谈到过了企业内的IT系统建设更多的是面向企业内部员工或业务部门，其受众相对来说比互联网应用小很多。那么在这种情况下如何来构建中台，或者说中台+前台分层构建的思路从哪里入手呢？

企业业务需求从内朝外扩展和延申的时候

第一个思考点就是企业内部业务从内到外延申的时候，比如企业需要自建电商平台直接服务于外部的C端客户，比如企业需要和外部的上下游，合作伙伴对接的时候。当出现这种延申的时候，我们就可以理解为可以参考中台+前台构建思路来进行。

其核心原因就是，延申业务本身业务敏捷性述求高，而且延申业务不会产生企业需要的核心业务对象和数据，仅仅是产生中间过程对象。在这种场景下最合适进行中台+前台模式进行构建。

即当企业构建自建电商平台的时候，你完全可以参考互联网电商平台中台+前台的构建方式来构建。其次企业内部的围绕ERP为核心的IT系统需要开放能力给业务系统用，而这个时候你可以将企业内部的业务能力整合后形成一个能力中台再开放给电商平台使用。

这个能力中台可以理解为企业内部IT系统能力服务的代理和整合。

对应企业内部面向全体员工的业务系统建设

企业内部有很多IT系统，其中类似采购，财务等核心系统往往只面向供应链，财务部门。而对于人力资源，办公，报账平台等业务系统往往则是面对全体员工。正是由于人力资源管理，报销平台这些系统受众广，我们才看到企业内部业务架构和IT架构优化转型的时候会提出共享的概念。即经常看到的企业财务共享中心，企业人力服务共享中心。

面向全员的系统受众广，往往导致了业务敏捷诉求高，再业务敏捷述求高的情况下我们就可以考虑优先采用中台+前台的建设模式进行构建。提升前台应用的敏捷响应度。

企业新构建的核心业务系统的外围系统，本身无核心业务对象数据产生

最后一种常见就是企业新构建的核心业务系统的外围系统，这类系统的特点就是本身无核心业务对象数据产生，更多是产生输入到企业内部核心业务系统的正式数据。

比如我们常见的企业招投标管理系统，这个系统存在的价值就在于产生招标评审通过的供应商信息导入到供应商或采购系统中，其他都是招投标过程业务数据。还有类似的就是我们常见的员工报销系统，员工报销系统同样不产生核心数据，更多是生成中间过程的报销单据，形成最终的应付凭证信息导入到企业内部的财务系统。这类系统本身往往就适合采用中台+前台模式构建。

纵向切分：从单体应用到微服务化的思考

首先我想说明下，在中台和微服务的概念还没有提出的时候，我在企业私有云PaaS平台构建中就在谈企业内部信息系统建设的组件化拆分，提出了平台+应用构建，业务能力组件化，组件能力服务化。

在拆分后不再强调业务系统的概念，因为业务系统的概念和边界已经模糊了，业务系统已经被打散为多个微服务模块。对于这种思路我们再来回顾下更多的是纵向的思路。即：原有业务系统拆分为多个业务组件，每个业务组件从数据库+中间件+业务逻辑和前台完全独立并松耦合。

也就是说原来的一个采购系统可能拆分为了招投标，供应商物料管理，采购订单，采购执行监控，配额管理6个微服务组件。这6个组件都对应独立拆分后的数据库。这个和我们现在的微服务架构完全纵向拆分独立的思路完全是一致的。

但是我们仍然发现了一些问题，即业务组件间耦合性很强，导致后续应用开发，团队协同困难。其次，拆微服务必须是横向和纵向两个维度结合共同来拆，而不是监控的模块划分，这个我在后面几篇文章还要详细谈。

那么对应纵向拆分，从单体应用到微服务化，我们实际需要考虑的关键点有哪些？

以是否拆分数据库的粒度来考虑业务组件粒度

在这里我提出以是否拆分数据库的粒度来考虑业务组件的粒度。比如供应商和物料两个核心对象的管理，我们发现两者耦合性相当强，因此我划分为一个大的业务组件为采购基础数据中心组件。

对应采购基础数据中心组件里面，我们的思考如下：

只存在一个独立数据库，不再根据对象继续拆分

只存在一个中台逻辑层提供服务，不再拆分

可以构建多个前端或前台应用，这个粒度可以灵活拆分

即我们打破原来我们经常谈到的前端前台，中台，数据库必须1对1的模式。这样既兼顾了底层的数据库逻辑处理和事务管理要求。同时又满足了前端的细粒度构建。

对外服务提供和上层应用支持逻辑层组件拆分

这个也是我这次提出的一个观点，即在构建中台的时候，我们将对外服务能力提供作为中台层的核心模式，而对应上层应用支持的逻辑层不再纳入到中台层，这个逻辑层可以和上层应用紧绑定，可以走类似RPC或直接的jdbc模式进行数据库访问协同。

这种拆分的好处是我们真正将应用功能的逻辑层，和中台服务逻辑层关系和边界划分清楚。在这样划分后我们更加清楚后续中台的范围，包括在性能出现瓶颈后组件的弹性扩展范围。

中台构建方法论整体说明

在前面我们已经给出了中台建设方法论对传统企业架构规划方法的优化和改进关键点，在这里我们进一步做详细的描述说明。

业务流程分析，通过业务流程分析识别业务功能和业务对象

这个点和传统企业架构规划思路基本一致，从业务流程分析入手，从最顶层的业务流程和业务价值链模型，逐层分解到三到四级流程，找到关键的业务活动单元和业务对象，然后从下朝上构建业务架构。

在整个流程建模和分解过程中，我们找到两个关键内容：

其一：业务活动或业务功能点

其二：业务对象或数据对象

注意，在传统业务架构建模方法上，我们务必要分析到最底层，最底层的意思可以理解到了最下面的一个业务功能点的业务操作过程说明。为什么要分析业务操作说明？因为通过业务操作分析，实际上你会发现关联或依赖的数据对象才能够识别出来。只有这样业务对象或数据对象才能够识别完整。

基于高内聚，松耦合原则来拆分业务域或业务模块

在业务功能和业务对象都识别出来后，接着重要的一个步骤就是业务域的划分，你也可以理解为中台规划中的一个关键，就是业务组件或微服务模块的划分。划分的原则是高内聚和松耦合，但是核心的方法仍然业务和数据各种交互矩阵分析。其中包括：

业务组件交互矩阵：横向和竖向都是业务组件，内容单元格里是具体的业务交互接口点，通过此矩阵可以看出业务组件的划分是否会导致大量的业务接口存在，分析每个业务接口产生的原因，以进行组件的合并、业务功能转移等。

业务对象和业务交互矩阵：横向是业务组件和业务功能，纵向是具体的业务对象，内容单元格是具体的CRUD信息（即传统的CRUD矩阵分析）。对于同一个业务对象，CUD操作尽量减少分离，而读操作则可以共享，以减少业务对象的多头管理和维护，将业务表单和数据的维护尽量控制在同一个业务大组件中完成，减少数据间的交互和传递。

流程交互分析矩阵：横向是具体的流程信息，纵向是具体的流程活动信息，在这个矩阵图上可以看到同一个流程活动或流程片段往往存在于多个不同的流程。该分析的重要作用是对流程建模中可复用的流程片段或流程活动进行抽象和分析。

功能业务组件分析矩阵：横向是具体的业务组件，纵向是业务功能，在该交互分析上重点是分析具体的可复用的业务功能，以对可复用的业务功能进一步进行抽取，形成可复用的服务。

当我今天重新回顾这个矩阵分析方法的时候，我发现了一些变化点。

比如我们原来谈到的CUD操作尽量减少分离，而读操作则可以共享，这个并不绝对。即我们的矩阵分析方法优先要解决的不是业务功能模块然后拆分的问题，而是要优先思考数据库拆分问题，即哪些数据对象应该聚合在一起。

简单来说在业务对象和业务功能的矩阵分析图中，我们需要进行一些特殊标志。

对应业务功能需要同时操作多个数据对象并同时入库的进行红色标注。

对于业务功能需要同时查询多个数据对象并返回结果的进行绿色标注。

这个分析的核心目的就是通过业务功能的分析来评估业务和数据对象之间本身的耦合性。对于耦合性高的实际上在进行数据库拆分的时候并不建议拆分开。

在前面一篇文章我就谈到拆库是基础，以拆分完的数据库粒度来作为实际的业务组件或模块的粒度。但是单个业务组件本身仍然还可以在前台或前端构建多个微服务模块。这个也是我近期思考提出的一个重要观点。

因此我们看到业务数据的交互矩阵分析重点是数据拆分，而不是哪些业务功能要聚在一起。

上层的业务功能，比如有10个业务功能，你可以打包为5个微服务，也可以打包为10个，这个不是关键。在这个思考清楚后，我们再来看上层的业务模块如何划分，即哪些业务功能点应该打包在一个也业务模块里面。那么这里的分析方法又该是如何的呢？

在讲解这个前，我们首先将CUD操作拆分为四个操作，即增加一个Import操作，变化为ICUD操作。对于Import操作理解为业务功能在完成后形成正式的业务对象，作为流程末端的输出写入，即Import操作。比如招投标管理里面有一个功能供应商认证，该功能在认证和审批通过后会形成一个合格供应商数据，写入到供应商管理模块。那么这个供应商认证功能对于供应商对象即是Import操作。

因此，我们可以将对数据对象的CRUD操作全部打包在一起形成一个完整的业务模块。对于R我们理解为基础查询功能，而非其他业务功能实现中的类似Reference的引用查询功能。

数据架构分析-逐步弱化并和业务分析融合

对于数据架构分析，我们可以看到进一步和业务流程和业务架构分析方法融合。即数据架构的作用首先是找到所有的业务对象和数据对象。而对于数据域的划分本身意义不大，因为我们在前面业务模块分析中已经看到通过业务交互分析本身就已经在做数据库拆分和拆库的事情。

数据架构一个重点变成识别出所有的数据对象和业务对象，然后补充进矩阵交互分析中。因为我们常规的业务流程分析可能会持续识别遗漏的情况。

要注意到对于业务架构我们只分析到业务对象模型，没有进入到逻辑模型和物理模型阶段，因此在后续数据库拆分清楚后具体的数据模型设计，仍然是传统的数据架构分析方法进行。

在数据对象分析里面有一个重点就是主数据识别和分析。

这个仍然保留，因为前面业务分析方法有可能出现主数据或基础数据识别不全的情况。其次将所有的数据对象仍然纳入到业务数据交互矩阵分析中。对于基本上大部分跨域业务功能都需要使用到的数据纳入到主数据或共享数据的范畴，并将这部分数据拿出来单独拆库进行处理。企业内部信息化建设模式，主数据就一个大数据库，而新的架构模式下我们可以看到主数据也可以拆分为多个基础数据库。

注：今天讲的分析方法里面我们可以核心是业务流程驱动，通过业务流程分析业务功能和业务数据，因此在整个分析和规划过程是弱化了数据架构的。

应用架构规划

应用架构规划会出现大变化，基于前面分析完成后构建的应用架构重点需要体现两点，第一是横向分层，第二是纵向的微服务划分。

我们可以参考下当前企业中台架构图可以看到，实际上前面分析的业务模块基本都属于中台的概念，虽然这些业务模块本身也带了前台功能界面操作。而实际上互联网中台架构里面谈到的前台更多是面向C端用户的，对于企业中台可以理解为三个方面的可能，这个我前面也解释过。

面向对外的C端用户的，比如企业自建电商平台或APP应用。

面向企业内部所有员工自服务的，例如自服务报账应用。

面向产业互联和上下游协同的，类似和供应商，合作伙伴的一个协同平台等。

因此当前的应用架构规划需要体现出横向分层。前台和中台之间通过能力开放平台进行协同，实现前台和中台能力的进一步松耦合。

对于应用架构中的中台各个业务模块，需要进一步拆分，包括体现出中台微服务的三种不同呈现方式，这个我原来讲到过。需要区别出一个中台模块是否有前端，是否对应有自己Owner的数据库等。

a. 只有业务逻辑层并暴露服务接口

b. 业务逻辑层+Owner数据库+服务接口暴露

c. 业务逻辑层+Owner数据库+前端

d. 业务逻辑层+Owner数据库+前端+服务接口暴露

在前面谈到过，对应d这种模式是否拆分为b和c两种模式需要进一步考虑。

同时我们谈到，在新的中台架构规划中，我们完全可以将业务架构规划和应用架构规划进一步融合为一个规划，要明白在融合统一后，业务架构规划中的业务组件规划即是中台架构中的微服务模块。唯一的差异点，即在于应用架构规划中有前端应用层的概念。

（以上内容摘录自互联网，如有侵权请联系删除）

今天准备分享下业务中台规划建设方法论对传统企业架构规划方法的改进。对于中台建设方法论简单来说应该结合如下几个方面的核心思想，具体包括：

SOA思想：重点体现纵向到横向，服务识别和基于服务编排和组合

微服务思想：体现构建的时候传统单体进行微服务化，大拆小

中台思想：体现在构建业务和应用架构的时候，共性业务能力下沉

云思想：重点体现由传统的接口服务集成，转变为集中化建设和能力服务开放

对于传统企业架构思想可以看到基于业务驱动IT思路，从端到端流程分析出发进行企业核心的业务流程活动，业务对象识别，然后再规划业务架构，数据架构，应用架构和技术架构，在应用架构中又包括了我们常说的集成架构规划。

传统企业架构方法核心说明

从顶朝下和从底朝上结合

在企业架构规划中，架构分析的入口点，我们认为合理的方式是从整体的端到端流程分析入手，细化到各业务域的端到端，经过不断的流程分解到3-4级流程，最终细化到最底层流程（如EPC流程，它是流程，本身也是业务功能）。另外的一个方式是直接从业务活动信息收集入手，如根据组织架构和岗位职责直接收集业务功能点。

第一种方式既看到面又看到点，从上到下层层推进；而第二种方法则是容易只看到点，但无法贯彻整个企业端到端流程。

当然，流程分析并不一定能够涵盖所有的业务功能点，因为有些业务功能本身便是最底层的EPC流程，往往并不是从高端的端到端流程分解而来，如用章管理是一个业务功能和EPC流程，但并不一定能够挂接到高端流程上面。

这也是端到端流程分析要注意点，即从顶朝下和从底朝上要相互结合。高端流程分析和分解是建立全局思维，但是仍然要借助第二种方法收集完整的业务和活动。

从业务活动分析中发现业务对象

流程到子流程，再到业务活动，业务活动中承载的是业务单据和业务实体。需要对业务实体进行抽离，进行数据层面的数据建模和分析。分析在流程各个阶段和活动中产生的业务实体之间的关联和依赖关系。业务域对应到数据域和数据分类，进一步可以分析到具体的概念模型或逻辑模型。

流程分析偏业务操作和事件，而数据正是业务操作的对象。SOA中强调操作和数据解耦，则正好是分析的两个维度。

业务组件划分-微服务的雏形

业务架构中的业务组件划分强调的是业务本身的高内聚和松耦合原则。

对于任何一个业务域基本有两种类型，一种是数据驱动型，一种是工单任务型。如资源、资产等核心数据对象，业务操作层面重点是对数据对象实现全生命周期管理。因此业务组件划分基本遵循底层为基础数据支撑层，上层为生命周期管理层，覆盖该数据对象的核心生命周期阶段。这是业务组件划分的一个基本思路。

对于业务架构的构建，特别是我们对某个业务域并没有深入的理解前，最好的方式就是流程驱动分析，抽离数据进行数据建模，然后进行CRUD矩阵分析，分析数据和业务功能的关系。对底层的业务功能进行组合满足高内聚松耦合的原则，然后从底向上的对细粒度的业务功能进行组合，形成高内聚的业务组件。当然在整个过程中往往我们会参考业界标准的业务架构参考模型，如供应链的scor模型，电信行业的etom模型等。

业务架构完成后，将会过渡到应用架构，业务架构和应用架构基本是对应的。

其中较大的差别点在于业务架构只关注业务，业务本身分为功能性需求，非功能性需求。非功能性需求中包括了平台层面的支撑需求，即应用的集成支撑和数据的集成支撑，公共平台层功能等。另外还包括了纯技术层面的非功能性需求。对于前者需要体现到应用架构中我们往往会分为技术支撑平台和应用支撑平台。

技术支撑平台包括了安全，管控等；而应用支撑包含了数据平台，集成平台和流程平台等。应用架构一般会分为支撑层，应用层和决策层。

服务架构需要考虑业务系统间的集成点。这个集成点的分析我们期望可以将端到端流程结合应用架构中的业务系统，CRUD矩阵分析形成跨业务系统的跨系统交互流程图。这种流程图已不是纯粹业务层面的流程图，而是做系统交互分析的跨系统交互流程图。所有的跨系统交互点则为流程驱动下的业务集成点。而CRUD矩阵分析则帮助我们分析出数据驱动的数据集成点。前者为业务服务为主，而后者即以数据服务为主。两者在分析完备后最终都体现到应用集成架构中。

业务中的平台级和非功能性需求转化到应用架构中的底层支撑层，对底层支撑层中的核心技术进行抽取，最终转化到一个完整的技术架构。技术架构和业务无关，它所提供的是底层技术支撑层能力。

技术架构逐步转化到公共的平台层，提供核心的资源池能力。业务组件本身转化为能力单元，业务组件由平台资源承载，提供业务服务能力。业务服务最终又可以通过灵活的配置形成完整的业务应用。因此我们所说的解耦不仅仅是业务组件间的横向解耦，还包括了业务组件到底层平台，业务组件到上层应用间的纵向解耦。

对传统企业架构规划方法的优化

从上面我们对传统企业架构规划方法的核心逻辑说明来看，传统EA企业架构规划方法仍然相当完整，但是我们也需要看到在整个SOA和云架构思想下，在中台和微服务思想逐步演进的过程中，传统的企业架构规划也需要进行优化和调整。

传统企业架构规划方法仍然是按照传统遗留大单体应用垂直纵向建设的模式来进行的规划，同时很少考虑到了集中化的云平台建设模式。然后在当前企业的信息化规划建设，平台+应用构建模式已经逐步成为主流。

同时在平台+应用分层构建的模式下，进一步将传统应用大单体拆分为多个独立自治的微服务进行独立建设和管控，而对于平台层则进一步融入云平台建设思路，包括最近1到2年我们谈的最多的面向云原生的解决方案。

这个云原生已经从传统的IaaS云平台过渡到了完整的PaaS云平台和技术服务能力提供。

基于以上分析，可以看到传统企业架构优化点主要体现在：

从纵向到横向：架构规划分析需要从纵向过渡到横向分层规划设计

数据库拆分：业务架构和数据架构结合分析，在规划阶段形成数据库拆分

业务和应用架构融合：在剥离了平台后，进一步融合业务和应用架构

基于业务组件规划设计微服务

技术架构规划新增加PaaS和技术中台服务内容

以上即是我们考虑需要进行优化的一些关键点。基于上面的思路，我们可以看到中台规划和建设的方法论可以进一步简化为下图。

从上面图可以看到，对于流程分析和数据架构分析仍然无大变化，核心都是为了划分业务组件和微服务模块。但是对原来的业务架构和应用架构可以合并，原因就是传统应用架构的平台层已经将其移到技术架构规划中。其次就是技术架构不再是单纯的IT基础设施架构，而且需要包括我们当前说的PaaS云平台和面向云原生的整体解决方案。

在整个中台建设规划中可以看到业务中台规划简单的重点仍然体现在两方面：

其一是业务中台中的微服务如何拆分

其二就是微服务究竟应该暴露哪些独立的可复用API接口

而对于技术中台可以看到，实际上包括了多个方面的内容，这个在我们前面的文章也有提到，即微服务开发框架和环境，DevOps支撑平台，容器云平台，共性技术服务能力，API网关和能力开放平台，运维监控平台。这些才构成一个完整的技术中台，如下图：

中台构建思路-横向分层和纵向拆分

大家都比较清楚，中台架构咨询和建设来源于互联网企业，然后逐步转入到传统企业内部，对于互联网企业基本也给出了中台建设的初步思路和方法论，但是如果简单的照搬这些思路到传统企业内部，往往行不通。那么我就需要首先分析互联网企业和传统制造类企业在业务和IT建设中的一些差异。

初步比较关键点如下：

IT系统受众：互联网后台管理用户少，而外部用户多；而传统企业大部分为内部用户。

前台应用的敏捷性：互联网对前台敏捷度要求高，而传统企业前台应用敏捷度要求并不高。

业务逻辑复杂度和强事务要求：互联网相对低，而对于传统企业IT系统业务逻辑更复杂。

当我把上面几点想清楚后，实际上对于传统企业中台构建的差异点或思路基本就想清楚。对于第1和2两点刚好对应到我们在进行横向分层构建上的差异，第3点对应到纵向拆分上的差异。具体为：

横向分层上：不是所有传统IT都要转为中台+前台模式，而是需要考虑受众和敏捷性要求

纵向上：不是微服务拆分的越细越好，而是要考虑业务逻辑和事务处理需求

如果企业内部中台构建不考虑上面两点，而是完全照搬互联网企业的中台多个中心+前台应用的构建模式，那么就是走极端，为了中台而中台。因此在企业中台构建时候一个关键点即：企业中台的构建不能脱离实际业务需求和场景，所有技术选择一定要追溯业务需求和目标。

横向分层：中台和前台分层构建思路上的思考

首先我们来看下横向分层上面的思考，即中台+前台构建思路上的差异思考。

前面已经谈到过了企业内的IT系统建设更多的是面向企业内部员工或业务部门，其受众相对来说比互联网应用小很多。那么在这种情况下如何来构建中台，或者说中台+前台分层构建的思路从哪里入手呢？

企业业务需求从内朝外扩展和延申的时候

第一个思考点就是企业内部业务从内到外延申的时候，比如企业需要自建电商平台直接服务于外部的C端客户，比如企业需要和外部的上下游，合作伙伴对接的时候。当出现这种延申的时候，我们就可以理解为可以参考中台+前台构建思路来进行。

其核心原因就是，延申业务本身业务敏捷性述求高，而且延申业务不会产生企业需要的核心业务对象和数据，仅仅是产生中间过程对象。在这种场景下最合适进行中台+前台模式进行构建。

即当企业构建自建电商平台的时候，你完全可以参考互联网电商平台中台+前台的构建方式来构建。其次企业内部的围绕ERP为核心的IT系统需要开放能力给业务系统用，而这个时候你可以将企业内部的业务能力整合后形成一个能力中台再开放给电商平台使用。

这个能力中台可以理解为企业内部IT系统能力服务的代理和整合。

对应企业内部面向全体员工的业务系统建设

企业内部有很多IT系统，其中类似采购，财务等核心系统往往只面向供应链，财务部门。而对于人力资源，办公，报账平台等业务系统往往则是面对全体员工。正是由于人力资源管理，报销平台这些系统受众广，我们才看到企业内部业务架构和IT架构优化转型的时候会提出共享的概念。即经常看到的企业财务共享中心，企业人力服务共享中心。

面向全员的系统受众广，往往导致了业务敏捷诉求高，再业务敏捷述求高的情况下我们就可以考虑优先采用中台+前台的建设模式进行构建。提升前台应用的敏捷响应度。

企业新构建的核心业务系统的外围系统，本身无核心业务对象数据产生

最后一种常见就是企业新构建的核心业务系统的外围系统，这类系统的特点就是本身无核心业务对象数据产生，更多是产生输入到企业内部核心业务系统的正式数据。

比如我们常见的企业招投标管理系统，这个系统存在的价值就在于产生招标评审通过的供应商信息导入到供应商或采购系统中，其他都是招投标过程业务数据。还有类似的就是我们常见的员工报销系统，员工报销系统同样不产生核心数据，更多是生成中间过程的报销单据，形成最终的应付凭证信息导入到企业内部的财务系统。这类系统本身往往就适合采用中台+前台模式构建。

纵向切分：从单体应用到微服务化的思考

首先我想说明下，在中台和微服务的概念还没有提出的时候，我在企业私有云PaaS平台构建中就在谈企业内部信息系统建设的组件化拆分，提出了平台+应用构建，业务能力组件化，组件能力服务化。

在拆分后不再强调业务系统的概念，因为业务系统的概念和边界已经模糊了，业务系统已经被打散为多个微服务模块。对于这种思路我们再来回顾下更多的是纵向的思路。即：原有业务系统拆分为多个业务组件，每个业务组件从数据库+中间件+业务逻辑和前台完全独立并松耦合。

也就是说原来的一个采购系统可能拆分为了招投标，供应商物料管理，采购订单，采购执行监控，配额管理6个微服务组件。这6个组件都对应独立拆分后的数据库。这个和我们现在的微服务架构完全纵向拆分独立的思路完全是一致的。

但是我们仍然发现了一些问题，即业务组件间耦合性很强，导致后续应用开发，团队协同困难。其次，拆微服务必须是横向和纵向两个维度结合共同来拆，而不是监控的模块划分，这个我在后面几篇文章还要详细谈。

那么对应纵向拆分，从单体应用到微服务化，我们实际需要考虑的关键点有哪些？

以是否拆分数据库的粒度来考虑业务组件粒度

在这里我提出以是否拆分数据库的粒度来考虑业务组件的粒度。比如供应商和物料两个核心对象的管理，我们发现两者耦合性相当强，因此我划分为一个大的业务组件为采购基础数据中心组件。

对应采购基础数据中心组件里面，我们的思考如下：

只存在一个独立数据库，不再根据对象继续拆分

只存在一个中台逻辑层提供服务，不再拆分

可以构建多个前端或前台应用，这个粒度可以灵活拆分

即我们打破原来我们经常谈到的前端前台，中台，数据库必须1对1的模式。这样既兼顾了底层的数据库逻辑处理和事务管理要求。同时又满足了前端的细粒度构建。

对外服务提供和上层应用支持逻辑层组件拆分

这个也是我这次提出的一个观点，即在构建中台的时候，我们将对外服务能力提供作为中台层的核心模式，而对应上层应用支持的逻辑层不再纳入到中台层，这个逻辑层可以和上层应用紧绑定，可以走类似RPC或直接的jdbc模式进行数据库访问协同。

这种拆分的好处是我们真正将应用功能的逻辑层，和中台服务逻辑层关系和边界划分清楚。在这样划分后我们更加清楚后续中台的范围，包括在性能出现瓶颈后组件的弹性扩展范围。

中台构建方法论整体说明

在前面我们已经给出了中台建设方法论对传统企业架构规划方法的优化和改进关键点，在这里我们进一步做详细的描述说明。

业务流程分析，通过业务流程分析识别业务功能和业务对象

这个点和传统企业架构规划思路基本一致，从业务流程分析入手，从最顶层的业务流程和业务价值链模型，逐层分解到三到四级流程，找到关键的业务活动单元和业务对象，然后从下朝上构建业务架构。

在整个流程建模和分解过程中，我们找到两个关键内容：

其一：业务活动或业务功能点

其二：业务对象或数据对象

注意，在传统业务架构建模方法上，我们务必要分析到最底层，最底层的意思可以理解到了最下面的一个业务功能点的业务操作过程说明。为什么要分析业务操作说明？因为通过业务操作分析，实际上你会发现关联或依赖的数据对象才能够识别出来。只有这样业务对象或数据对象才能够识别完整。

基于高内聚，松耦合原则来拆分业务域或业务模块

在业务功能和业务对象都识别出来后，接着重要的一个步骤就是业务域的划分，你也可以理解为中台规划中的一个关键，就是业务组件或微服务模块的划分。划分的原则是高内聚和松耦合，但是核心的方法仍然业务和数据各种交互矩阵分析。其中包括：

业务组件交互矩阵：横向和竖向都是业务组件，内容单元格里是具体的业务交互接口点，通过此矩阵可以看出业务组件的划分是否会导致大量的业务接口存在，分析每个业务接口产生的原因，以进行组件的合并、业务功能转移等。

业务对象和业务交互矩阵：横向是业务组件和业务功能，纵向是具体的业务对象，内容单元格是具体的CRUD信息（即传统的CRUD矩阵分析）。对于同一个业务对象，CUD操作尽量减少分离，而读操作则可以共享，以减少业务对象的多头管理和维护，将业务表单和数据的维护尽量控制在同一个业务大组件中完成，减少数据间的交互和传递。

流程交互分析矩阵：横向是具体的流程信息，纵向是具体的流程活动信息，在这个矩阵图上可以看到同一个流程活动或流程片段往往存在于多个不同的流程。该分析的重要作用是对流程建模中可复用的流程片段或流程活动进行抽象和分析。

功能业务组件分析矩阵：横向是具体的业务组件，纵向是业务功能，在该交互分析上重点是分析具体的可复用的业务功能，以对可复用的业务功能进一步进行抽取，形成可复用的服务。

当我今天重新回顾这个矩阵分析方法的时候，我发现了一些变化点。

比如我们原来谈到的CUD操作尽量减少分离，而读操作则可以共享，这个并不绝对。即我们的矩阵分析方法优先要解决的不是业务功能模块然后拆分的问题，而是要优先思考数据库拆分问题，即哪些数据对象应该聚合在一起。

简单来说在业务对象和业务功能的矩阵分析图中，我们需要进行一些特殊标志。

对应业务功能需要同时操作多个数据对象并同时入库的进行红色标注。

对于业务功能需要同时查询多个数据对象并返回结果的进行绿色标注。

这个分析的核心目的就是通过业务功能的分析来评估业务和数据对象之间本身的耦合性。对于耦合性高的实际上在进行数据库拆分的时候并不建议拆分开。

在前面一篇文章我就谈到拆库是基础，以拆分完的数据库粒度来作为实际的业务组件或模块的粒度。但是单个业务组件本身仍然还可以在前台或前端构建多个微服务模块。这个也是我近期思考提出的一个重要观点。

因此我们看到业务数据的交互矩阵分析重点是数据拆分，而不是哪些业务功能要聚在一起。

上层的业务功能，比如有10个业务功能，你可以打包为5个微服务，也可以打包为10个，这个不是关键。在这个思考清楚后，我们再来看上层的业务模块如何划分，即哪些业务功能点应该打包在一个也业务模块里面。那么这里的分析方法又该是如何的呢？

在讲解这个前，我们首先将CUD操作拆分为四个操作，即增加一个Import操作，变化为ICUD操作。对于Import操作理解为业务功能在完成后形成正式的业务对象，作为流程末端的输出写入，即Import操作。比如招投标管理里面有一个功能供应商认证，该功能在认证和审批通过后会形成一个合格供应商数据，写入到供应商管理模块。那么这个供应商认证功能对于供应商对象即是Import操作。

因此，我们可以将对数据对象的CRUD操作全部打包在一起形成一个完整的业务模块。对于R我们理解为基础查询功能，而非其他业务功能实现中的类似Reference的引用查询功能。

数据架构分析-逐步弱化并和业务分析融合

对于数据架构分析，我们可以看到进一步和业务流程和业务架构分析方法融合。即数据架构的作用首先是找到所有的业务对象和数据对象。而对于数据域的划分本身意义不大，因为我们在前面业务模块分析中已经看到通过业务交互分析本身就已经在做数据库拆分和拆库的事情。

数据架构一个重点变成识别出所有的数据对象和业务对象，然后补充进矩阵交互分析中。因为我们常规的业务流程分析可能会持续识别遗漏的情况。

要注意到对于业务架构我们只分析到业务对象模型，没有进入到逻辑模型和物理模型阶段，因此在后续数据库拆分清楚后具体的数据模型设计，仍然是传统的数据架构分析方法进行。

在数据对象分析里面有一个重点就是主数据识别和分析。

这个仍然保留，因为前面业务分析方法有可能出现主数据或基础数据识别不全的情况。其次将所有的数据对象仍然纳入到业务数据交互矩阵分析中。对于基本上大部分跨域业务功能都需要使用到的数据纳入到主数据或共享数据的范畴，并将这部分数据拿出来单独拆库进行处理。企业内部信息化建设模式，主数据就一个大数据库，而新的架构模式下我们可以看到主数据也可以拆分为多个基础数据库。

注：今天讲的分析方法里面我们可以核心是业务流程驱动，通过业务流程分析业务功能和业务数据，因此在整个分析和规划过程是弱化了数据架构的。

应用架构规划

应用架构规划会出现大变化，基于前面分析完成后构建的应用架构重点需要体现两点，第一是横向分层，第二是纵向的微服务划分。

我们可以参考下当前企业中台架构图可以看到，实际上前面分析的业务模块基本都属于中台的概念，虽然这些业务模块本身也带了前台功能界面操作。而实际上互联网中台架构里面谈到的前台更多是面向C端用户的，对于企业中台可以理解为三个方面的可能，这个我前面也解释过。

面向对外的C端用户的，比如企业自建电商平台或APP应用。

面向企业内部所有员工自服务的，例如自服务报账应用。

面向产业互联和上下游协同的，类似和供应商，合作伙伴的一个协同平台等。

因此当前的应用架构规划需要体现出横向分层。前台和中台之间通过能力开放平台进行协同，实现前台和中台能力的进一步松耦合。

对于应用架构中的中台各个业务模块，需要进一步拆分，包括体现出中台微服务的三种不同呈现方式，这个我原来讲到过。需要区别出一个中台模块是否有前端，是否对应有自己Owner的数据库等。

a. 只有业务逻辑层并暴露服务接口

b. 业务逻辑层+Owner数据库+服务接口暴露

c. 业务逻辑层+Owner数据库+前端

d. 业务逻辑层+Owner数据库+前端+服务接口暴露

在前面谈到过，对应d这种模式是否拆分为b和c两种模式需要进一步考虑。

同时我们谈到，在新的中台架构规划中，我们完全可以将业务架构规划和应用架构规划进一步融合为一个规划，要明白在融合统一后，业务架构规划中的业务组件规划即是中台架构中的微服务模块。唯一的差异点，即在于应用架构规划中有前端应用层的概念。

（以上内容摘录自互联网，如有侵权请联系删除）