第一部分 引子

第1章 阿里巴巴集团中台战略引发的思考

本章从阿里巴巴为何启动中台战略说起，谈到阿里巴巴共享业务事业部从建立、摸索及系列演变，到最终成为阿里巴巴业务中台战略中核心组成部分的过程。深入分析阿里巴巴共享业务事业部发展历程中所遇到的一系列问题和困境，而这些问题也恰恰是当今很多传统企业信息系统建设过程中所遇到的问题，找出这些问题的症结是根治这些问题的必修课。

2015年年底，当大多数企业忙着进行年度工作总结和下一年规划时，阿里巴巴集团对外宣布全面启动阿里巴巴集团2018年中台战略，构建符合DT时代的更具创新性、灵活性的“大中台、小前台”组织机制和业务机制，即作为前台的一线业务会更敏捷、更快速适应瞬息万变的市场，而中台将集合整个集团的运营数据能力、产品技术能力，对各前台业务形成强力支撑。

与任何公司一样，阿里巴巴组织架构的战略调整势必对公司现有组织架构、部门间的协作等各方面都将带来深远影响。战略执行到位、3年内达到战略调整所设定目标，对业务的创新和支持将带来巨大的影响，假若没能很好地控制战略执行过程中带来的风险，对组织架构的动荡过大，都会给现有业务带来不小的影响。

阿里巴巴为什么会在这样一个时间点做出如此重大的决定呢？这还要从一次商务拜访说起。在2015年年中，马云带领阿里巴巴集团的高管，拜访了位于芬兰赫尔辛基的移动游戏公司Supercell，这家号称是世界上最成功的移动游戏公司，以《部落战争》《海岛奇兵》《卡通农场》等游戏知名。Supercell是一家典型的以小团队模式进行游戏开发的公司，一般来说两个员工，或者5个员工，最多不超过7个员工组成独立的开发团队，称之为Cell（细胞），这也是公司名字Supercell（超级细胞）的由来。团队自己决定做什么样的产品，然后最快的时间推出产品的公测版，看看游戏是否受用户欢迎。如果用户不欢迎，迅速放弃这个产品，再进行新的尝试，期间几乎没有管理角色的介入。团队研发的产品失败后，不但不会受到惩罚，甚至会举办庆祝仪式，以庆祝他们从失败中学到了东西。使用这样的模式使得Supercell公司成为了年税前利润15亿美元的游戏公司，2015年App畅销排行榜上Top 10的游戏中，Supercell公司开发的游戏占据了榜单的大半江山。在笔者撰写此书时，2016年6月，中国腾讯公司以86亿美元收购了员工数不超过200人的Supercell公司84.3%的股权，每一名员工人均贡献的估值超过3.54亿人民币。

笔者对Supercell模式的理解是这家游戏公司经过6年的时间将游戏开发过程中公共、通用的游戏开发素材、算法做了很好的沉淀，企业的文化充分鼓励员工进行创新，甚至进行试错，才使得他们在开发的众多游戏中以最快时间找到那些用户真正喜爱的游戏。这种强大的业务试错能力是Supercell相比于其他游戏公司最大的差别，也是最核心的竞争力。其他的游戏公司难道没有想到学习这样的模式吗？答案一定是肯定的。为什么其他游戏公司不具备Supercell这样的能力呢，我觉得很多人忽略了Supercell所构建的“中台”能力，抛开个人水平高低的影响，Supercell公司在多年的游戏研发中积累了非常科学的研发方法和体系，使得今天公司可以支持几个人的小团队在几周时间就能研发出一款新游戏，并进行公测。

Supercell的模式给参加此次拜访的阿里高管们很大的震撼，在大家反复的心得交流和讨论中，一个非常重要的问题引起了很多人的反思：信息时代的公司架构到底应该是怎样的？正是有了这次拜访才真正让阿里巴巴的领导层有了足够的决心要将组织架构进行调整，在此次拜访的半年后，集团正式启动2018年中台战略。

所谓的“中台”，并不是阿里巴巴首先提出的词语，从字面意思上理解，中台是居于前台和后台之间。其实在阿里巴巴集团启动中台战略之前，有另一个被很多外界所熟知的“厚平台，薄应用”架构，说起这个架构则不得不说其中最为重要的一个部门——共享业务事业部，这个部门的产生、演变和发展在笔者看来都极具代表性和参考价值。

1.1 阿里巴巴共享业务事业部的发展史

在阿里巴巴内部论坛中有两篇暴走漫画形象生动地描述了共享业务事业部的产生、发展以及最终奠定部门在集团内重要地位的演变过程，如图1-1所示。

第一幅漫画中，描述了阿里巴巴在2003年时成立了淘宝事业部（图1-1左一）；随着集团领导层意识到B2C模式的业务将来也会是电商领域重要的组成部分，在2008年时集团成立了天猫（最初期叫淘宝商城），只不过当时是从淘宝团队中抽调出一拨人，作为淘宝事业部中的一个部门进行运营（图1-1右一）。

随着天猫业务的蓬勃发展，没过多久就单独成立了天猫事业部，成为跟淘宝并驾齐驱的两大电商事业部，此时淘宝的技术团队同时支持着淘宝和天猫的业务（图1-1左二），这样的组织架构阵型决定了技术团队对于来自淘宝的业务需求满足的优先级一定优先于天猫（屁股决定脑袋，大家都懂的），使得天猫的业务团队怨声载道，严重影响了天猫的业务发展。另一个问题是业务架构层面的问题，当时淘宝和天猫的电商系统是完全独立的两套体系，两套电商平台都包含了商品、交易、评价、支付、物流等功能。

正是因为以上两大问题，在2009年，共享业务事业部应运而生，主要成员来自于之前的淘宝技术团队，在组织架构上单独成为一个跟淘宝、天猫同样级别的事业部（图1-1右二），集团希望以这样的方式更好地让技术团队同时支持淘宝和天猫的业务，同时也将两套电商的业务做了梳理和沉淀，将两个平台中公共的、通用的业务功能沉淀到了共享业务事业部，避免有些功能的重复建设和维护，更合理地利用技术资源。

但接下来的发展却事与愿违。虽然组织架构上共享业务事业部和淘宝、天猫平级，但从对业务的理解和业务贡献的体现来说，淘宝和天猫相对共享业务事业部拥有着更多的话语权，结果就是共享业务事业部在两大业务部门的业务需求下艰难生存着（图1-1左三）。到此，共享业务事业部的产生和发展确实与大多数人的期望有着很大的偏差。

看看接下来又发生了什么故事，如图1-2所示。

共享业务事业部同时满足着淘宝和天猫高压态势的业务支持，在资源固定的情况下，就算团队成员再怎么加班加点，也很难及时、周到地满足两大业务部门业务需求，结果就是业务部门对共享业务事业部的满意度不高，而共享业务事业部的员工则是有苦说不出，只能默默流泪（图1-2上左）。

真正带来转折的是2010年，作为阿里电商业务的团购入口——聚划算的出现。聚划算平台刚一上线，就展现它强大的流量吸引的威力，据不完全统计，不管是淘宝还是天猫的商品，一旦进入聚划算平台，销售额会在短时间内至少增长25倍，聚划算对于淘宝和天猫的运营人员来说，无疑是一个增加流水的有效途径，所以一时间大家趋之若鹜，纷纷对接聚划算平台（图1-2上中）。

面对这一快速提升商品交易量的利器，继淘宝、天猫之后，1688也参与其中，三大电商运营人员各展所长争占聚划算平台上的有利资源。来自三大电商平台如洪流般的业务对接需求让当时成立不久的聚划算团队应接不暇（图1-2上右）。

这时就出现了对于共享业务事业部历史转折点的一个举措，集团要求三大电商平台如果要与聚划算平台进行业务对接，必须通过共享业务事业部！正是有了这“点睛之指”，使得共享业务事业部有了一个极强的业务抓手，将原本与三大电商的业务对话权不平衡的天平拉到一个相对公平的水平（图1-2下左）。从而最终奠定了今天大家所看到的共享业务事业部成了阿里巴巴集团业务的核心业务平台，如图1-3所示。

图1-3中清晰地描述了阿里巴巴“厚平台、薄应用”架构形态，目前阿里巴巴集团前端超过25个业务单元（如淘宝、天猫、聚划算、去啊等大家熟知的业务）均不是独立地构建在阿里云的云平台之上，在后端阿里云技术平台和前端业务间有了一个“共享业务事业部”，将阿里巴巴集团前端业务中公共、通用的业务沉淀到了这个事业部，包含了用户中心、商品中心、交易中心、评价等十几个中心，而共享业务事业部正是“厚平台”的真实体现，为阿里巴巴各种前端业务提供着相应服务中心领域内最为专业、稳定的业务服务。

当阿里巴巴在2015年启动中台战略后，也看到有些专业评论对阿里巴巴此次中台转型的担忧，转型中带来的改变是否会对现在阿里巴巴集团组织架构产生巨大冲击，是否对前端的淘宝、天猫等业务带来较大影响，转型之后的效果是否能达到领导层的预期。但从笔者的视角，阿里巴巴做出中台战略转型的决定并非空中楼阁。阿里巴巴从2009年就开始建设共享业务事业部，已经为中台战略在转型过程中将会面临的组织间业务协作、业务核心能力的沉淀、组织KPI考核等方面都做了很好的实践和经验沉淀，加上阿里巴巴强大的执行力，笔者完全相信阿里巴巴能成功实现中台战略的转型，为下一轮的业务腾飞打下更为坚实的业务中台。

1.2 企业信息中心发展的症结

笔者初次了解到阿里巴巴共享业务事业部的发展史时，就有很大触动，一部分原因是我亲眼见证了阿里巴巴为了更好地满足集团业务快速发展的需要对组织架构的多次调整，这个过程充满了集团领导的思考和智慧，也经历了艰辛的尝试，才使得阿里巴巴集团在今天充满残酷竞争的中国互联网时代屹立于强者之列；另一个原因则是我发现阿里巴巴在2008年面临的问题跟现在很多企业面临的困境非常相似，而经过阿里巴巴多年打磨和验证过的这套共享服务体系可能是让非互联网行业的企业摆脱困境的最好出路。

我为什么会产生这样的想法呢？让我把前面漫画中的一些问题和现象与现在企业中的问题和面临的处境做一下映射。

1．“烟囱式”系统建设模式

在图1-2上左中，大家看到了2008年时淘宝的技术团队同时支持着淘宝和天猫两大电商平台。1999年成立的B2B电商平台1688一直拥有自己的技术支持团队。阿里巴巴集团三大电商体系的技术支持架构如图1-4所示。

正如之前所述，三套电商体系的架构完全独立，各自应用独立开发和运维。在电商平台上有过购物经历的读者都能想到，一个标准的电商平台至少提供了会员服务、商品的信息、交易支付，不管是B2B、C2C或者B2C的电商平台都需要提供，为什么阿里巴巴的三大电商平台会独立建设和维护，这其中没有任何公共和通用的功能吗？

我想导致这种建设模式的因素有很多，个人认为其中主要原因是开发团队考虑到电商模式的不同，所以需要独立建设；或者是新的业务团队认为在之前的电商平台基础上改造成支持新模式的电商平台会有太多的技术和业务的历史包袱，还不如重新构建。不管原因如何，最终促成了当时我们看到的三座“烟囱”分别矗立支撑着当时阿里巴巴集团最为核心的电商业务。

而这样的故事实际上在中国企业IT建设20多年的历程中几乎天天都在上演，今天企业IT系统建设的模式是：当业务部门提出业务需求，信息中心部门进行系统集成商的招投标（如自身有开发团队的企业则无需此流程），再进入到需求收集、需求分析、开发、测试、上线的项目周期中，某种程度上每个新系统的上线都预示着一座新的烟囱矗立而成，这种完全基于业务需求建设系统的方式已经成为过去20多年企业建设IT系统的标准流程，导致IT系统建设早的企业内部系统烟囱林立。这正是今天很多企业面临互联网转型难的根节所在。

其实对于“烟囱式”系统建设带来的弊端在十年前就已经有人提出，以这样的方式建设系统对企业的“伤害”有三大弊端：

1）重复功能建设和维护带来的重复投资。大家都不用太仔细去梳理这些“烟囱式”建设起来的系统，就能发现大量的功能和业务在多个系统中同时存在，单单从开发和运维两方面成本投入的角度，对于企业来说就是一种很显性的成本和资源浪费。但这一点对企业带来的伤害却是最小的，只是成本的损失。

2）打通“烟囱式”系统间交互的集成和协作成本高昂。随着很多企业业务的发展，要打通这些“烟囱式”系统之间的连接，以提高或优化企业运营效率，这样的场景在2005年后（是因为在这个时间点上很多大型企业已经进行了多年的IT建设，有了不少的烟囱）逐步涌现，特别在如今的互联网时代，如何更好地整合内部资源、更好地提升用户体验，实现各个系统间的交互成为必然发生的事情。

最为典型的例子发生在零售快消行业，很多的品牌商在2008年天猫出现后，立马上线了一个系统用于对接天猫平台，与自己企业的商品、库存、物流打通；随着后期京东、微商的出现，相继建设了相关系统；同时企业还有几千家门店以及分销商需要管理，所以都要建立对应的PoS、CRM等系统。2013年电商对传统零售商的分销模式产生了巨大冲击，这些品牌商就着急要获取到最终用户的消费行为、爱好等信息，从而为用户的精准营销做有力的数据支持，但发现用户的会员信息、商品信息、订单信息、消费行为信息等都被之前“烟囱式”的系统建设方式拆分到了不同的系统中，因此不得不开始打通这些“烟囱”，从而获得品牌商所需的全局会员以及消费数据。

面对这样的业务需求和系统处境，业界早在十几年前就提出了SOA的理念，出现了各大厂商纷纷推出了各自的ESB产品及解决方案，重点就是来解决此类异构系统之间交互的问题。一时间，各大企业纷纷上马SOA项目，构建企业服务总线，基于服务的方式实现了这些“烟囱”间交互的问题。

纵观各个SOA项目的实施，平均来说企业为了系统的打通所花费的成本是比较高昂的，这其中牵涉大量的协同和开发成本。

3）不利于业务的沉淀和持续发展。从传统IT系统建设的生命周期来看，一旦系统上线以后，就进入了运维阶段。在运维阶段，也会有对系统功能完善和新业务需求的升级；因此我们看到了平均周期均在几个月，甚至半年进行一次功能的升级。而事实上业务的需求是与日俱增的，特别在现今的互联网时代，来自客户、市场的反馈和信息都要求系统进行快速的响应，而传统项目的迭代周期对业务的响应和支持越来越吃力。

上面提到很多企业通过ESB系统很好地实现了多个独立系统间的打通，不可否认ESB的架构很好地屏蔽了服务接口变化给服务消费者带来的影响，是解决不同系统间实现互联互通的很好的架构，但这样的项目在企业中落地后，后面的发展就让SOA价值的体现出现本末倒置的现象！

企业实施SOA集成项目上线后，各个系统按照标准封装的这些“服务”就进入一个“稳定”状态。这里的“稳定”当然不是指服务运行的稳定，而是这些服务对外提供的功能变得“稳定”，也就是说，很多服务在初次上线后，在接下来几年的时间里就几乎没有新的服务功能的增加或提升。

产生这种现象的根本原因就要追溯到企业实施SOA的方式，典型的项目实施模式，在确定了贯穿多个系统的主业务流程后，就要求各个相关的系统进行服务的封装和改造，这种模式就是典型的“自顶向下”的建设模式，而这个时候，各个需要提供服务封装和改造的系统无不均属于各自的运维期，对于服务开发相关的工作，运维人员的心态往往是协助和配合，并且多数情况下这些服务封装的工作跟运维人员自身的KPI考核是没有多大关系的。正是基于这样的背景，我们很少看到在功能性和扩展性方面做得足够好的服务。另一个更严重的问题则是当此期SOA成功实施结束后，后续有新的业务系统希望接入这些服务，而新的业务系统又发现现有的服务不能很好地满足他们的要求，希望提供更多功能或更好体验的服务要求时，在现实中就会出现下面两种情况：

1）服务提供者团队不管是从KPI考核的角度，还是从认知上认为服务封装的任务已经完成，所以当他们收到新的服务需求时，心理上是拒绝的，会出于多一事不如少一事的心态，告诉新业务系统的需求方：“我们目前仅能提供这样的服务”，导致最终的结果是新业务系统认为该服务不可用，逼着他们在自己的系统中重新又实现了一套跟这个服务差不多的功能模块，也就是产生了一个新的烟囱。

2）服务提供者团队拥有不错做事的态度，也愿意改造服务以满足新业务的需求，但受限于之前服务设计时的通用性和业务前瞻性的不足，造成如果要满足新业务的需求，就要对现有服务的数据模型、业务逻辑做较大的改造，在改造带来的风险和满足新业务需求的选择中，更多的团队选择了放弃对新业务需求的支持，而保持现有服务提供的稳定，其结果跟第一种情况完全一样。

不管是传统项目建设方式带来业务迭代能力的不足，还是现有企业内SOA“项目制”建设的效果最终导致三个弊端，而其中第三个弊端“IT系统建设中实现的业务得不到沉淀和持续发展”是对企业伤害最大的。

前面两个弊端是基于成本和效率的角度，第三个弊端则是基于发展的角度。采用“烟囱式”方式建设的系统体系，企业中一个业务领域的数据和业务往往就被打散在不同的系统中，采用系统打通的方式解决了眼前相关业务间的交互问题，但这样的方式治标不治本。随着业务的发展，这样的方式最终无法满足业务快速响应和业务模式创新的需求。这也就是过去很多年中，在很多企业经常上演的一幕：一个系统上线运行5～8年后，企业的信息中心会向企业更高领导人提出随着业务的快速发展，现有系统不管是技术架构还是业务模型都不能满足现在业务发展的需求，需要整体系统升级，而这样的升级往往意味着对原有系统推倒重建。且不论这样推倒式重建对于现有业务带来影响的大小，多少基础功能的重复建设和资源投入，更重要的是对于之前多年业务的沉淀能保留多少，这对于企业来说可能是最大的资产流失。

这个问题本质上是由于系统所提供的服务能力没有随着企业业务的发展做到与时俱进。在任何一个企业中，业务需求是一直存在的，传统IT系统建设模式下，上线的系统就进入了系统维护期，这个时间段实际上是系统对业务需求响应非常不敏感的阶段，一般半年或一年才会进行一次系统的升级。也就是说，系统业务需求响应的能力和企业本身业务发展对系统建设的要求不成比例。如果说过去，业务需求的增长态势还算比较平滑，没有体现出系统的响应能力有多大差距，那么在今天，互联网时代业务需求的增长越来越迅猛，原有系统对业务响应的能力就显得更加捉襟见肘，如图1-5所示。到了一个时间点，量变产生质变，就会出现企业核心业务系统运行多年后被推倒重来的现象。

2．业务支持一直是企业信息中心的组织职能

如图1-2上中，阿里巴巴集团将原来淘宝的技术团队从淘宝事业部划分出来成立了单独的共享业务事业部，成为一个中立的、同时支持淘宝、天猫两大业务单独的部门。集团的这种举措与今天的企业一样，无一不认可信息技术部门对于企业发展的重要地位，每家企业中信息中心部门的行政级别均和核心业务部门的级别相当。但实际上，行政级别的平等并不代表着具有同样平等的部门话语权！

正如图1-2上右，共享业务事业部在两个业务部门间处境悲惨。试想一下，在董事会的桌子上，企业高层领导者希望各部门的领导能提出对业务发展各抒己见的时候，一定是业务部门的领导们基于对业务发展的理解高谈阔论之时，此时有几位CIO或IT信息部门的领导能在业务上提出独到的见地？结果相信大家都能猜到，业务部门的领导因为自己的想法被领导采纳，争取到好的建功立业的机会，也自然获取到公司高层的不少好感，这些好感也无形中为部门的话语权增加了不少筹码。而IT信息中心则获取的工作任务是配合该业务部门完成该业务目标中IT系统的建设。

我听说过一个真实的故事，一个大型国企的信息中心主任在3个月间都没有给董事长做过一次工作汇报，不是信息中心主任不想做汇报，而是这位董事长总推辞没有时间，而分管销售的部门经理（与信息中心主任管理级别平级）则几乎每周给董事长做一次当面的汇报。相信这样的事情在很多企业中都有，我认为这个问题的核心就是我们IT信息部门在现有的模式下已经被更高的领导层定位成了业务支持的部门，是一个花钱的成本中心。

造成这样处境的原因是什么？我认为是因为IT信息部门的人员不懂业务！我说出这个观点，可能会引来很多IT信息中心人员的反驳和不认同，“我对系统的核心业务流程最熟悉，甚至比那些业务部门的人更懂”、“系统的数据模型都是我们设计的，怎么说我们不懂业务？”……

我承认在对业务系统的具体流程、操作、数据模型方面IT人员比业务部门更懂，因为这些系统是IT人员负责建设的，但我所说的懂业务是指，能对业务的下一步发展有着自己的理解和看法，对业务流程如何进一步优化能更好地提升业务，甚至对企业现有的业务提出创新的想法，为企业带来新的业务增长点。

而造成IT信息中心不懂业务的根本原因又是什么呢？很多大型企业的IT信息化部门已经存在了超过20多年，一成不变的就是项目制的系统建设模式，这样建设项目的模式除了带来前面所提到的“烟囱式”建设的一系列弊端，同时使得IT信息化部门一直处于“业务支持”的职能位置，即只是为了满足业务部门需求而进行IT系统建设的实施和运维部门。这样模式下造成我们今天看到的很多企业IT信息化部门的员工大多数的工作内容就是进行项目管理，负责开发商招投标、开发商与业务团队间的协作沟通、紧盯项目进度。当一个项目顺利上线验收后，这些员工开始投入到下一个项目的工作中。这样的工作确实也非常锻炼人的组织、协调能力，但这样能力的提升与工作时间的长短并不是呈线性增长的，更多的时候，我们看到能力较强的员工能体现自己价值的地方在于负责的项目更大，甚至同时负责多个项目，而这在我看来终归是增加了项目经验，并不能在某一专业领域得到知识和经验的沉淀，我相信随着时间的流逝，越来越多的人会慢慢失去最初的工作积极性和创造性。这样的最终结果是IT信息中心的员工很少有能在一个业务领域做足够的深入了解和业务沉淀，更多的是对业务知其然，而不知其所以然，也谈不上成为业务领域专家，更不可能对业务发展有创新想法和独到见解。

上面讲的故事说明，在2008年阿里巴巴业务系统的建设模式、组织架构包括遇到的问题都与如今企业并无二致，而如何摆脱这样的困境，选择什么样的IT业务架构以及基于哪些技术原则为企业真正打造一个在互联网时代满足业务发展的IT基础架构，将是接下来几个章节详细阐述的重点。