【读书笔记一】《企业 IT 架构转型之道 - 阿里巴巴中台战略思想与架构实战》

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



一、思考



Supercell这家游戏公司真的是“神奇”的公司，在不到200人的规模上却创造了税前利润15亿美金，且2015年APP畅销排行榜上top10中占据大壁江山；另外在2016年中平均人均贡献为3.5亿人民币。根据对它的理解，这家公司的优胜地方在于把6年过程中公共、通用的游戏开发素材、算法做了很好的沉淀，且鼓励创新甚至试错。



二、共享事业部发展史



       2003年淘宝事业部成立，2008年天猫作为淘宝事业部下辖的一个业务部门的地位诞生，技术团队从原淘宝事业部拨一部分人进行支撑；后来因为阿里战略问题，天猫事业部分离出来变成跟淘宝同等级别的事业部，技术支持还是靠着原淘宝的那波人在支撑。这样的组织架构带来的问题是，所有的IT资源肯定是向淘宝倾斜的。因为上述问题，在2009年成立了共享业务事业部，在组织架构层面跟淘宝和天猫平起平坐。但是，事情却事与愿违，因为共享业务事业部需要满足两个部门的业务需求，最终结果肯定是两边不讨好，共享业务事业部却觉得有苦说不出。

       这一时刻，聚划算作为巨大流量入口诞生，且集团命令要求：接入聚划算的一个前提是必须通过共享业务事业部。就是这样的一个命令使得共享业务事业部变得尽可能的与天猫淘宝平起平坐，为后来大家所见到的共享业务事业部变成阿里巴巴核心业务平台奠定了基础。



三、企业信息中心发展的症结



从阿里巴巴共享业务事业部的发展史，可以折射企业一系列的问题。



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

• 开发团队考虑到电商模式的不同，所以需要独立建设；

• 新的业务团队认为在之前的电商平台基础上改造成支持新模式的电商平台会有太多的技术和业务的历史包袱，还不如重构；



在今天，这种建设模式几乎还在天天上演，究其原因还是因为这种完全基于业务需求建设系统的方式已经成为过去企业建设IT系统的标准流程，然后就导致“烟囱”林立。这种模式带来什么的弊端：

• 重复功能建设和维护带来的重复投资；

• 打通“烟囱式”系统间交互的集成和协作成本高昂；

• 不利于业务的沉淀和持续发展。



前两个弊端最多是成本与效率的问题，但是第三个弊端则是长期发展的问题。采用“烟囱”式的建设模式，即使后期通过某种手段打通系统间的数据交互，但是随着系统的复杂度不断增大，也还是解决不了问题。一般会最后发生的情况是：当系统建设了5-8年后，在原有系统上堆二次功能的速度已经满足不了业务部门互联网般的速度，IT部门会跟公司高层需要推倒重建。假若这样，在整个5-8年内根本就没什么所谓的沉淀，说白了就是IT资产的流失。



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

在过去的几十年，虽然在很多公司IT部门也变成了跟业务部门同一个级别，但是行政级别相同不代表部门话语权相同，你看当初刚独立的在没有傍上“聚划算”这个大款前的共享业务事业部是多么的悲催就知道啦。究其原因就是IT部门在原来的模式下已经被定位为支持业务的成本中心，而不是盈利中心。当然造成这个原因也有IT自身的原因。



• 因为很多的IT人员根本就不懂业务，所谓的“不懂业务”不是指现有的业务流程逻辑之类的，而是指对业务的发展有没有自己的理解和看法，甚至对企业现有的业务模式有没有思考过如何通过创新想法为企业带来新的业务增长点。如果不改变IT人员的这种问题，IT部门永远只是业务支持型的成本中心，因为IT部门不懂如何驱动业务。

• 另外，“项目制”这种系统建设方式带来的一种后果。为什么？如果采用“项目制”的话，那IT部门只是负责或聚焦于梳理需求、招标、监控等项目管理类工作。如果是这样，IT人员增长的更多是项目经验，而不是业务知识和经验的沉淀，这样又反过来加剧了这种模式。



第二章、构建业务中台的基础-共享服务体系



一、服务需要重用和业务滋养



ESB理念最核心的价值就在于服务间的松耦合，通过服务聚合层的业务编排快速响应业务和孵化创新。但是过往大部分企业的IT治理项目中，受限于项目制建设模式，ESB核心的理念没有真正发挥出来，我们只是利用了这类企业服务总线构建了一个企业内部的服务路由而已。



“烟囱式”系统建设的三大弊端：

1、重复功能建设和维护带来的成本浪费；

2、需要打通不同系统来实现业务交互；

3、业务得不到沉淀和持续发展；



ESB本身是没错的，错就错在SOA项目是基于一种集成项目建设的方式。这个什么意思呢？这个ESB是项目制，项目制代表着有开始和结束，这样就导致：

• 服务提供者没有太大的积极性满足新的业务需求，再加上当初设计的功能扩展性和业务前瞻性不足就导致无法轻易快速的响应业务需求；

• 服务需要“稳定”，稳定代表着不能随意改动。

问题来了，不随意改动的话，意味着会倒逼更多的业务系统会自建相同的“轮子”。随着自建“轮子”越多，代表着ESB的某个服务就越少人问津，当有某个更好的服务面世的时候就意味做这个原本的服务要退出历史舞台了。



二、共享服务体系是培育业务创新的土壤



企业真正需要的创新一定是来自于企业内部，而不会由外面所谓的专家告诉你如何创新。因为好的创新一定是基于企业的现状因地制宜，因此提出创新的人一定是对行业有过人的认知。



好了，这种专业人士在哪里找？可以到外面挖，但是可能存在水土不服等问题。那就培养吧。我们以前学习的套路是怎样的？一开始学习基础知识点，并随着掌握的业务知识点（此乃“点”）越来越多，会有意识的把知识点串起来（此乃“线”）解决问题，接着随着越来越多的“线”交叉在一起慢慢形成了“面“，即对这领域有个全面的理解并能解决问题。同理，业务专家也是这样形成的。



当我们建立了共享服务体系以后，每个人就会在某个领域（如共享服务体系里面的订单中心、支付中心等不同中心）内不断的掌握知识“点”，编织问题“线”，最后结成业务“面”。共享业务体系能很好的培养出特定领域的专家，然后这些专家一定可以大概率的为企业带来想要的业务创新能力。



三、共享服务体系赋予业务快速创新和试错能力



在互联网时代，想要跟同业产生差异化竞争力，业务试错是一个重要能力，毕竟天下武功唯快不破。就如书中的supercell公司一样，除了在体制上要有所改变外，最重要的是要为业务的创新打造一个坚实的中台。



在中台的支撑下，小前端团队具备以下特征：

• 团队协同效率最高；

• 对战机（商机）的把握更加敏锐；

• 调整方向更加快捷；

• 一旦发现正确目标，全力投入扩大战果。



最具代表性的一个事例要属阿里的团购业务。在2010年团购业务蓬勃发展，阿里也决定自建平台，当时在市场早就有美团、高朋等网购网站。当时阿里投入产品、运营、开发等10+名员工进行基于淘宝和天猫商品的平台建设，就是之前已经存在着用户中心、商品中心、交易中心等共享业务服务，该平台在1个半月后就成功（即聚划算的前身）。



四、组织矩阵改变会带来组织效能的提升



传统应用开发模式下的组织矩阵由架构师、开发人员、运维工程师、DBA、UED工程师等不同的职能部门或科室组成。整个团队组成精密的流水生产线，通过流水线方式流经每个专业人员的环节，通过“专人做专事”的方式最终输出整体交付。但是这种方式的弊端是对于不同角色人员的技能持续提升是会出现发展瓶颈的。



正是出于上面因素的考虑，对于技术团队的组织架构也做了一定的调整。针对每个服务中心建立一个全功能团队，由架构师、开发人员、UED工程师等不同角色组成，对某一服务中心的业务能力进行“运营”。

在这样的一个组织中，核心角色为业务架构师(即该服务的团队技术leader)。该架构师一般是技术开发出身，既懂技术又对业务领域有相当理解。他作为整个服务中心业务发展的领路者，又是保障服务中心核心业务具备通用性和公共性的最重要的捍卫者。



同样的，通过共享服务体系的建设以及组织阵型的调整，在有效提升员工积极性和创新意识的同时，能够在生产力和业务响应效率得到极大的提升，随着团队逐渐掌握最核心的业务和数据，能够逐渐培养出企业最稀缺的“既精通业务又熟悉技术”的复合型人才。随着把这种能力对外开放，这种组织也将成为企业最宝贵的资产。