人怕出名猪怕壮，阿里一出手，对手抖三抖…
言归正传，自从阿里提出“小前台，大中台”，逐渐演变成“中台战略”“中台思维”…
从字面上看，它应该是介于前台和后台之间的一层，称之为“中台”。我们通常理解的前台是业务系统，包括电商平台，客户服务系统之类的，后台是IT支撑，包括云计算平台，数据库，运维系统等等。
前台的业务系统完成业务功能服务客户，这些应用运行在后台上。
那么，阿里巴巴为什么需要一个中台？中台产生的原因又是什么？
一是随着电商业务的发展，应用越来越庞大，几百号人维护一个应用，而且需要经常更新，做过应用开发和运维的童鞋对这种痛苦可想而知。
二是阿里巴巴从淘宝开始，到天猫，在发展中形成了两套独立的体系，商品、支付、物流都是独立的。但从运营角度来说，这些都是公共的部分，从运营角度就需要统一。
于是，为了解决这些问题，阿里巴巴从2009年就成立了“共享业务事业部”，将两个平台上公共的、通用的部分划归共享业务事业部。
这就是中台的前生。
后续的发展中，共享事业部的工作越来越重要，共享业务单元也越来越多，包括用户，商品，交易，店铺，营销等等。
阿里巴巴的几十个业务均通过共享业务中心来完成自身的业务功能。
中台就这样产生了，中台就是“共享业务”的今世。
阿里巴巴中台架构的概况
中台某种程度上是为前台而生的！
为了业务的敏捷，创新！
业务需求变化快，变更以天甚至更短的频率计算，一个单体大型应用，庞大的开发团队对单一应用的变更变得越来越困难。将大应用变为多个小的应用组合，才能适应外部的快速变化，实现业务的敏捷。
随着业务的发展，业务系统之间的交互通常会变得越来越复杂。一个功能的修改可能会影响很多方面。只有将需要大量交互的功能独立，从应用中拆解出来，这样可以使得应用之间耦合度大幅下降。
一些公共的能力通过复用，大大提高了开发效率，避免了重复建设。同时使得数据和流程可以集中得以管理和优化。
这不就是多年前提出的SOA思想吗？
没错，这就是中台的本质。
中台通常可以分为三个层面： 业务层面，数据层面和技术底层。
将业务的公共需求组合成服务，比如电商公司，客户，商品，物流，支付就是公共需要，比如汽车制造商，用户，车辆，订单，交付都是公共需求。将这些公共业务组合成统一的业务服务，供各个业务单元使用。
这些业务公共服务，通常合称为“业务中台“。
数据时代，业务中越来越依赖于数据，包含：数据的收集，数据处理，数据算法和分析，报表，以及数据的治理。
数据相关的服务合称“数据中台“。
基础服务通常是底层的服务，面向技术。这些底层技术包括：安全认证，权限管理，流程引擎，门户，消息，通知等等。这些组件通常与业务关联度不大，属于每个应用都需要使用的功能。
这些技术服务合称“集成中台“。
中台的建设不是那么件轻松的事情。
首先要建立“中台“配套的相关管理机制，其次是建立应用架构，从相对容易的基础共享服务开始，到定制与业务贴合的业务中台。在建立中台的过程中，需要配套中台运行的后台基础架构。
中台的建设可以总结为五步走。
中台的建立，切忌做成项目制，中台需要使用产品管理的方式来对待。
这是因为中台对外提供的服务需要不停的迭代，适应业务的需求，否则经过一段时间，前台因为中台提供的服务固化，只好自己新建一个服务来满足业务需求，逐渐不使用中台提供的公共服务。
因此，中台应该有一个独立部门或团队来持续服务和运营，而不是项目制那样完成就解散。
另外，中台本身就是一个为前台提供创新的平台，要允许试错。
企业和阿里巴巴不同，阿里巴巴基本上都是C端应用，电商、文娱、消费，业务系统都是自己开发。企业历史包袱重，自主开发能力不强，既有购买的商品化软件，又有自行开发的系统。
比如，制造企业既有后端的SAP ERP，PLM，MES，WMS等系统，这些年又产生了面向外部的电商，客户服务，营销服务等前端系统。
前端系统由于市场需要变化快，要求系统迭代速度以周甚至天计算，而后台的传统应用，变更和迭代通常以月甚至年来计算。
Gartner将企业的两种IT称为双模IT，传统IT是模式1，互联网IT是模式2。
既不能抛弃传统IT应用，又要发展快速的互联网IT，需要建立两种IT的桥梁。
同时，为了前台互联网IT的敏捷，解耦，复用，我们又需要建立中台，这三者的应用架构可以参照如下的架构：
前台应用和中台之间采用API网关架构，中台和后台应用之间采用ESB服务总线架构。
基础共享服务是面向技术层面的基础公共共享服务，因为大部分服务就是集成功能，因此也可以称为“集成中台”。大致有如下的共享公共服务：
进入到数据时代（DT），数据的重要性越来越被企业认知。对数据的收集，分析计算，深度学习，并转让为企业的核心竞争力。
在这样的背景下，数据中台的概念也随之诞生。
通常数据中台包括如下方面：
业务中台每一个企业都是不同的，它是高度个性化的，无法通过直接购买获得，因为它与业务密切相关。
例如，下图是一个金融公司的业务中台：
但是，汽车制造相关的业务中台，它必须包含金融业不具备的产品设计，车辆，生产计划等业务服务。
业务中台需要长期的沉淀，抽象和归纳。打造一个业务中台绝不是一朝一夕的事情。
中台不是空中楼阁，中台需要底层的基础设施支撑。那么中台需要什么样的基础架构呢？ 中台既要要实现敏捷，低耦合，复用，又要实现高扩展，高性能，弹性，以下就是中台需要的基础架构：
这些基础架构包括：
上图概况了中台的软件架构、云、容器编排、DevOps都是中台必要的基础。
孙福杰
SAP天天事
近年来，诸多科技公司提出了「小前端，大中台」或「前中后台」的架构，市场上的声量也逐渐扩大，SAP 的很多客户也正在逐渐接受这种概念。
姑且不去评论这个热议的架构是否适合所有业务类型的企业、是否适合不同的信息化发展阶段，至少它给我们公用事业行业带来一个无法回避的问题：越来越多的
公用事业
客户开始考虑，SAP 传统的应用系统，是否适应「小前端，大中台」的架构？或者说，「前中后台」的架构下，该如何对 SAP 进行定位？
三个月前，我们去拜访一个公用事业行业客户的新任 CIO。这个客户无论在管理理念、业务流程、经营业绩和信息化建设等方面，都是中国领先的公用事业企业，和 SAP 有长期的合作关系，十几年前就采用了 SAP 诸多解决方案，包括 ERP、CRM等，是中国公用事业行业采用 SAP 方案最全的客户之一。目前，这个客户正在进行企业业务战略升级和管理重构，并面向全集团
开展
数字化转型。
在我们首次与 CIO 的交流中，我们刚介绍完第一页 PPT，即 Gartner 双模架构和 SAP 的智慧企业总体框架图，CIO 就抛出了一个问题，并进行了40多分钟的讨论，这个问题是：SAP 的双模架构或者智慧企业架构，与「前中后台」架构是什么关系？作为 CIO，他要考虑该企业未来较长一段时间的总体架构以及与 SAP 架构的匹配。客观地说，我们当时并没有很好地回答出这个问题，但是很明确地意识到：要切入该客户的数字化转型项目，这是一个无法回避的重要问题。
通过 SAP 内部各领域咨询专家团队反复讨论，并和包括客户首席架构师在内的技术人员沟通，我们基本明确了 SAP 产品体系与客户心目中「前中后台」架构的关系，并得到了客户的认可。
SAP 主要产品体系与客户
心目中「前中后台」的关系
针对该客户的业务情况，我们将 SAP 的主要产品体系与客户心目中的「前中后台」进行了匹配，如下图。
在与客户首席架构师和核心技术人员的沟通中，大家对「前中后台」架构的适应性达成了比较一致的看法：电商企业的业务逻辑相对较清晰，能相对容易地切分业务组件；另外，电商对 IT 的依赖度极高，一般来说，电商公司的内部 IT 力量很强；即便这样，他们从竖井式系统走向「小前端、大中台」也是经过一个渐进过程。但是，不是所有的企业都像电商公司那样适合构建理想的「小前端、大中台」架构，在实际操作层面上，要考虑到业务的复杂性、稳态常规业务与敏态变化业务的比例、企业内部 IT 开发和支撑能力、IT 投入和时间成本、IT 建设的发展阶段、业务与 IT 的依赖强度等因素。
因此，需要综合考虑以上各种因素，根据企业的实际情况，做出比较理性的架构选择，总体思路是：核心稳定业务交给成熟套装软件来完成，少部分需要敏捷、变化的业务创新，交给中台来完成，这也符合双模 IT 概念，与 SAP 智慧企业架构也是吻合的。
