《中台产品经理宝典》选讲：带你系统认知企业架构（EA）
在之前的中台文章中，我曾多次提到企业架构这个概念，但是企业架构到底是什么呢？本篇文章我将为你带来解读。
一、企业架构初识
首先我认为解决复杂系统搭建的核心方法论就是企业架构（EA），这里的企业架构其实是一个面向整个企业去设计软件的一个思路。
这里我先给出企业架构的标准定义：
企业架构（Enterprise Architecture），简称EA。是指对企业日常事物管理系统中具有体系的、普遍性的问题而提供的通用解决方案。企业架构是指基于业务导向和驱动的架构来理解、分析、设计、构建、集成、扩展、运行和管理信息系统。
二、企业架构详解
刚才说的是定义，下面我来简单为大家介绍下企业架构的起源。
1987年，John Zachman就提出：“为了避免企业分崩离析，信息系统架构已经不再是一个可有可无的选择，而是企业的必需”。
事实上在John Zachman当时提出这个口号的时候，他就发现随着企业业务不断的扩大，企业内部信息化建设的复杂度也随之提升。
此时设计一个系统，如果只考虑单业务方诉求，而不考虑别的部门协作，就会导致整个企业的系统群变得越来越难用。
因此他建议企业信息化必须从企业顶层入手，也就是整个企业视角，可以说这是为企业架构的诞生铺垫了核心思想。
从那时起，Zachman的企业架构理论就开始逐渐发展起来， 它现已成为许多大公司用来理解、表述企业信息基础设施的一个直观模型。
为企业现在的以及未来的信息基础设施建设提供了蓝图和架构。
随后在TOGAF（the open group）定义提出并被广泛采纳后，企业架构（EA）被清晰的划分为两大部分：业务架构和IT架构。
1. 业务架构
从组成上看业务架构，包括运营模式、流程体系、组织结构、考核体系几个部分。
而简单来说，用最简单的几个字总结一下就是一家企业是怎么运行起来的。
企业是由哪些部门组成，然后这些部门做了什么事情把这个业务运作起来的，这叫做业务架构。
2. IT架构
IT架构包括公司内部现有系统组成，系统间的数据体系是什么样子的？主数据体系是什么？
整个技术架构是通过什么实现的，例如微服务、SOA等。
总结就是如何去设计一套IT系统去支撑整个企业的业务，注意此处不是单个产品线的，是去支撑所有的企业业务。
完整的企业架构组成如下图所示：
至此我们如果用通俗的语言来解读企业架构概念的话，可以总结为：将企业的业务以一个全局视角来看，从而统筹规划信息系统。
也就是说在使用企业架构时，我们要跳出传统的在某个产品线里去设计软件的这种狭隘视角。
这里需要强调下两种截然不同的研发模式：
- 产品线研发流程：业务线提出的任意需求将其线上化，例如要求订单中能跳过登录环节；
- 企业业务研发流程：以企业视角考虑多个业务线的诉求，从企业全局思考是否能跳过登录环节。
可以看到企业架构就是企业业务研发流程。
而企业架构落地最好的路径就是在我在《中台产品经理宝典》一书中提出的MSS模型。
这里由于是概念解读，我就不做过多展开了，感兴趣的朋友可以去看我的这本书。
三、企业架构应用
在之前的文章中我曾提出一个观点，当下的企业多数处在信息化转折点的关键时期。
在这个时期中，企业的系统群存在各种各样的问题，急需一次彻头彻尾的重构来改善整个企业的信息化运行效率。
那这个时候其实在任何单一系统上去进行单点的发力改造，是根本没办法去解决这个问题的，我们必须要站在一个全局视角，去联动所有系统去做一个改造。
所以此时我们对于企业的设计，就是进入企业架构设计的范畴之中了。
为什么说企业架构适合这个阶段呢？就是因为企业架构是从整个企业的业务视角去入手。
通过分析整个企业的战略是由哪些部门来去承载，各部门承载了之后，这些部门又通过怎么样的运作方式去实现。
可以看到这里的建设者始终是站在企业主的角度去考虑问题的，因此设计出的系统肯定也是以全局最优的方式去进行的，所以这是解决转折点问题的核心。
让我们举个实际拆解企业架构的例子来看，如下图。
比如此处该企业的目标是要占领某细分市场，为此他的组织架构会开始设计需要由哪些业务部门和团队组成。
有了团队后，具体要怎么去占领呢？
下一步的核心就是要去设计一个交易流程，比如要面向这些客户如何获取订单，接下来继续定义运营流程，例如如何运营这些客户，如何运营交易标的物。
拿电商来说，此处需要去设计商品的管理、商品上下架、新品的研发等运营工作，这样就完成了业务架构的梳理。
面对这个业务架构，我们下一步就要设计IT架构，也就是你要用哪些系统来承载整个企业的业务。
比如你的交易流程它是由哪个系统承载？可能有OMS，有商城，那么运营流程里头又包含什么系统？
你获取到用户订单怎么去交付，使用哪些系统承载。
定义完系统后，接下来之后还需要考虑你的整个数据体系、数据实体有哪些？
比如有商品、订单、会员，然后你的整个数据管理流程是什么样的？是集中化管理还是分散化管理？
以及最终你的技术架构是什么样的？
可以看到这就是站在一个全局去思考整个企业业务的信息化，这就是企业架构。
那么在我们的日常工作中，根据这个企业架构的这个思想，当我们在面对大型企业级系统建设，如中台建设，我们一定要面向领域工程，而不是在像以前的点对点需求研发。
怎么理解呢？就是说我们需要考虑相似或者相近的一个场景，并且建立起一套通用的能力去一次性解决一整个领域里的问题。
而不是像以前出现一个订单需求，开发一个订单服务，那别的业务线又出现订单需求，再开发一个订单服务这样的模式。
而像现在的互联网大环境中，企业已经进入到了一个存量时代，或者说已经进入到一个零和博弈的阶段。
那这个时候我们必须要能以一次建设去提供多次服务的这种方式来进行研发迭代，那么这就叫领域服务。
领域服务就是我们建设的通用能力，我们在其基础上，做一些稍微的配置，就能为具体的某个场景去提供应用解决方案，这样的话企业内部研发效率就会变得非常的高。
这其实就是中台的最本质的思想。
四、最后
既然IT架构它是业务架构了一个承载物。所以我们必须要去规范整个企业的业务架构，规范我们的业务。
如果业务本身不能被很好的结构化和模块化，那么再好的技术团队也没办法去承载这个业务。
注：本文内容摘录于本人出版图书《中台产品经理宝典》。
#作者#
三爷，微信公众号：三爷茶馆，2019年年度作者。《中台产品经理宝典》作者，原万达高级产品、MBA特约讲师、独立创业者，现叮咚买菜B端产品线负责人，拥有多款集团项目从零到一经验并带领实现商业化布局。
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
