谈到设计中台绕不过去的一个概念就是企业架构，为什么这么说呢？
是因为设计中台就不能像以往设计传统的单一产品线的产品那样，仅仅是面向特定的人群进行思考，而是需要站在公司的视角，面向于整个公司业务对象与公司内部生产关系进行设计。实现对内提升企业运作效率，对外提升产品交付效率。
记得在本系列的第一篇文章里我已经给大家阐明了中台实际上就是一个餐厅中配菜的小工，职责就是负责向前台的各位大厨配菜，但是在梳理中台需求的时候，我们必须要清楚的知道前台到底有多少位厨师？各个厨师的偏好是什么样子的？我们怎么样的工作才能配合上每位厨师的炒菜节奏？也就是完成一次新的企业架构定义。
再用更白的话说一下就是，我们搭个工棚可能不需要设计，拿着砖就干了，但是如果我们要建个迪拜塔就必须要好好设计了，整个建筑的上下水，电怎么接等都需要思考，而这就是企业架构的活。
1
我们先来看看企业架构到底是个什么东西？
企业架构(Enterprise Architecture)这一概念最早是由IBM的咨询顾问John Zachman，于1987年提出的。
也就是在随着企业管理精细化，企业内部引入了多套不同领域的管理软件之后，绝大多数企业出现了相类似的信息化企业病，我称之为“人肉接口”与“为系统工作”的两种病症。
具体来说这两者的根本症结就是存在当公司内部采购了多个软件后，由于各个软件之间数据无法互相传递，事件状态无法相互推进，导致不得不由员工将上一个系统产生的结果手动输入到另一个系统进行下一步流转。
此外由于系统间天然的隔离性，导致在上一个系统做过的审批以及操作，在下一个系统中很有可能还需要进行。
举个例子来看，某公司的信息系统体系如下：
HRM：italent
OA：企业微信+邮件
邮箱：内部搭建
产品研发管理：JIRA
财务系统：财务
销售管理：某CRM
以员工离职这个场景来看，当我们要为某员工做个退工操作时：
第一步：需要进入HRM系统进行退工封档；
第二步：需要进入OA系统里关闭权限；
第三步：关闭邮箱权限；
第四步：关闭JIRA项目权限；
......
这正是由于数据无法互通，导致我们不得不在多个系统之间进行操作，尤其注意的是这其中任何一个系统的权限遗漏都有可能会造成不可挽回的损失。
可以说上述的场景在现在的很多企业中都是非常常见的，那么现在企业中是怎么解决这个问题的呢？
由于无法实现系统间的互联，因此往往是由公司人事部门整理了一份离职list，在每个人员离职的时候，按照list进行逐个手动关闭系统权限。
大家回想下自己离职的时候，是不是也会收到这样一份list要你按照上面的流程去找不同的人关闭权限并签字确认。可以说这大大加大企业内部的风险与对应人员工作流被打断次数。
其实这个问题并不是这几年才暴露出来的，早在1987年这位咨询师就已经发现了这样的问题，并给出了自己的解决方案这就是企业架构：他认为在企业信息化建设之初就应该考虑到多个部门之间的协作，并且在系统上体现出来，也就是A部门的协作结果很有可能成为B部门的信息来源，所以在系统之间必须有。对应的数据接口进行数据传递，此外还必须要为系统的后续迭代保留可拓展的部分。
让我们具体来看看企业架构到底是由什么组成的，如果绕过那些特别繁琐的实施方法，仅从产出物上来看，我引用一张在我书中的图来概括企业架构是什么东西：
业务架构：如何将企业抽象的商业理论变为具体的执行层面，例如马云提出的让天下没有难做的生意落实到具体的执行层面，就是建立一个由支付体系（支付宝）+全球交易平台（泛淘宝平台）+物流体系（菜鸟驿站）组成的业务架构；
IT架构：如何管理企业内部在运作中产生的数据，不同的应用软件，以及底层的实现技术。
当然完整的企业架构构造不会这么简单，按照John Zachman的理论，企业架构具体分为这6类角色：
企业拥有者
业务管理者
系统分析者
系统设计者
系统建设者
系统本身
而这6类角色各自关注的问题也是有所不同的，具体关注的问题如下表所示（可点击放大哈）：
既然聊企业架构，我就再展开点引用一位明白人谈谈目前发展的现状：
工业和信息化部副部长杨学山在一次内部座谈时提到：与西方发达国家比，国内的信息化建设在硬件方面已经不相上下，在软件方面有5年的差距，在信息化管理方面有大概10年的差距，在企业架构方面则有20年的差距。
2
了解了企业架构后的中台建设
了解完了企业架构的概念后，我们再回到中台建设思考上，中台本质也是一个业务系统。
所以当我们研制中台的时候我们就需要考虑企业原有的企业架构（业务+现有IT系统），在中台加入后的新企业架构会是什么样的？
如何既符合原有业务架构又能封装整个IT架构，为产品交付提供便利。
当然我们不需要像传统的软件咨询行业一样去规划企业蓝图，中台建设中更多关注的是企业的业务现有流程，以及现有各系统之间的关系，在中台层面需要如何进行支撑与服务。
举个例子我们作为一个外卖APP，我们内部有商城系统，商户管理系统，物流调度系统，客服系统，当我们新拓展出的外卖派送、同城派送与超市派送等业务时，虽然应用场景各不相同，但这背后的业务核心流程是完全相同的：都是为用户提供周边5公里的派送服务。
对此我们可以将这派送机制抽离并整合进中台中，由中台提供一个全公司业务的派送调度服务，而由不同的前台业务线来根据具体场景设计对于的用户交互流程与订单的下单与进度显示。
这其中本质上就是要梳理企业各业务线中原有的调度系统关联关系，以及原来的派单业务的运营模式、流程体系、业务人员的组织结构。
让我们再来看中台的完整建设流程（也就是在我的书中介绍过的MSS建设模型）：
该流程的前三步其实就是在进行业务架构的梳理（当然本系列中台实战文章的写作路径也就是在按照企业架构的梳理方法进行一步步展开的）。
例如在上一篇文章《中台实战（6）：业务边界的划定》里，我们其实谈的就是企业架构里业务架构的梳理，我们结合前面学习过的商业模式识别与已经标准化的企业流程，对我们各业务线的SOP进行评估以及最终产出了一个业务标准建模：
Part1：生鲜电商商业模式（业务架构）
Part2：业务架构承载方：业务线定义（业务标准建模步骤1）
Part3：业务线SOP梳理（业务标准建模步骤2）
经过这些的梳理我们得出的是一家公司中的完整业务架构，并在此基础上去进行中台系统的定义。
中台在IT架构中起到的作用用一个词概括就是封装底层。
具体来说建设完成后的业务中台与前台的交互模式，由业务中台负责去定义需求的范围与内容，并将具体的业务数据与处理结果返回给前台，由前台业务线负责具体展示形式。
如果用我们经常听到的产品设计五层模型来对应的话，加入中台后的企业IT架构就如下图所示：
可以清楚的看出业务中台是五层模型里的结构层，而框架层与表现层由前台业务团队进行定义。
3
最后
中台建设本质上就是对企业业务架构了一次升级，所以如果我们想要建设一个好的中台，就必须对企业架构特别是业务架构进行充分的梳理与归整，只有这样中台才能发挥起自己的作用。
