Yuraku
阿里自2015年起执行“数据中台战略”走在前面，除此之外，腾讯、华为、用友、京东等都结合自身优势开启数据中台的探索，并提供对外服务。
9月30日，腾讯发布的战略与架构升级中，提到了成立技术委员会和“技术中台”的概念。
- 再说华为，华为提出了构建数字化转型的“共同平台”，打造支撑业务增长的“黑土地”。
- 用友网络今年同样提出了【中台战略】，副总裁兼CTO程操红先生首先发布了用友云平台重磅产品——技术中台、业务中台、数据中台。
- 看看京东的玩法：2017年末，京东商城技术团队拆分为前台与中台，前台研发职能对接商城各事业部，中台研发则聚焦于解决共性需求
（原创）文 | 刘成军，工业互联网研习社发起人，造奇智能新媒体创始人兼主编
造奇智能新媒体发现，【中台】思想充分体现了阿里关于“业务数据化，数据业务化”的思考与实践。这是今年演讲的一张图片，非常清晰简单明了，高度抽象化表达，容易理解。这是当前的一种状态，正如石红生总所讲，此框架不是一下子就演变成这个样子的，也许后面还会变得更简单。
如果我们按照历史事件和业务逻辑来梳理的话，可以有几句话值得讲一下：
- 1、外部：响应速度慢，服务能力跟不上客户的节奏；
- 2、内部：组织和部门的组织壁垒，垂直IT系统柜形成的数据壁垒；
多种IT系统之间的层层壁垒使得公司内外部的各种信息无法有效流通，众多高价值数据也只能在自身系统的小圈子里转，无法在更大的格局与链条上发挥价值。同时，内部创新力不足。
这无论对于有着数十年阉割的传统制造企业来说，还是对于新兴的互联网公司来讲，都面临着冗余、包袱，而缺乏效率和及时响应，这意味着用户体验极差，在互联网公司和商界竞争力，这是不被允许的。
阿里敏锐的发现了自己的困境，并寻求解决方案。这里有一个故事，在《中台》那本书里有详细的介绍。
从2009年开始建设的“共享事业部”为阿里巴巴的架构转型奠定了基础。这是一个转折点。但由于组织架构、事业部之间的博弈，刚开始的“共享事业部”并没有按照预期发展。这时，阿里集团要求三大电商平台如果要与聚划算平台进行业务对接，必须通过共享事业部！正是有了这“点睛之笔”，共享事业部便有了一个极强的抓手，将原本与三大电商平台对话权不平等的情况拉平，这使得“共享事业部”成为了阿里巴巴集团的核心业务平台。
这个架构的形成和刚才发的2018年的架构在整体部署上没有明显差异。
这个转折之后的共享事业部和新架构从09年开始磨合运行，直到2015年底，当大多数企业忙着进行年度总结和规划时，阿里巴巴集团宣布全面启动“中台战略”，构建符合DT时代的“大中台、小前台”组织机制和业务机制。
阿里巴巴中间件首席架构师、《阿里巴巴中台战略思想与架构实践》作者钟华表示，在用阿里技术推动企业数字化转型、建立数字中台的过程中，第一大挑战是业务、其次才是技术。所谓业务挑战，就是从业务视角，把共性的业务模块沉淀到共享业务中台，把个性化的业务剥离出去后形成前台，形成“大中台，小前台”新格局。（这是业务部门（人员）与IT部门（人员）深度融合的典型）总结阿里发展数字中台的核心经验：
原有的共享IT部门必须要找到极强的互联网业务作为抓手，把自己变成核心业务部门，才能够真正转型成为企业的共享业务事业部，而不是某种变形的、换汤不换药的共享IT部门，这也就是阿里共享业务事业部经常讲的“业务滋养”的概念。
在共享业务抽象与沉淀的过程中，还需要一个开放的技术平台来承载不断沉淀下来的共享业务单元，这就是阿里云中间件Aliware平台（“厚平台、薄应用”）
阿里发展数字中台还有一个关键经验，这就是共享中心的技术团队组织构成，不再是之前与业务相匹配的流水线模式：之前是UED用户体验设计师对于前端交互界面、架构师和开发人员对应业务逻辑、运维工程师和DBA对应数据库等；
深度思考、认知升维、跨界连接，欢迎加入#工业互联网研习社#社群
（欲加入研习社，欢迎私信咨询）
—笔者在知识付费领域的探索，2018年1月1日，造奇智能产业新媒体独家推出、业界首份聚焦工业互联网领域的高质量实名付费社群——[工业互联网研习社]，依托[知识星球]而建。致力于打通工业互联网从资讯→信息→知识→认知→见识→服务的链式通路，助力您的职业发展和机遇把握。这是在工业媒体与知识分享领域的知识付费尝试！
—近300位付费研习社社友遍布上海、北京、深圳苏州、杭州、武汉、芜湖等工业重镇，初步构建起覆盖工业互联网平台、工业软件、底层数据采集、工业数据分析、系统集成商、大学及产业资金在内的全国价值网络。
工业互联网研习社
有幸读过《企业IT架构转型知道：阿里巴巴中台战略思量与架构实战》，从书中也吸取了阿里数据中台建设的一些思想。（这本书很不错，建议大家阅读以下）
阿里最早的时候，是只有淘宝的，后来有的天猫，我们就那这两个举例，如果没有数据中台的话，淘宝是一个系统，天猫是一个系统。这就是"烟囱式"的架构, 也就是每个业务线虽然类似但都各自搞一套。
这样"烟囱式"的架构，会有什么弊端呢？
重复建设和维护带来的重复投资：这个好理解；如果除了淘宝、天猫之外，想再建一个类似的系统，里面包括会员、商品、商家、物流、支付等等功能，一定很浪费资源。
打通烟囱式系统间交互的集成和协作成本高昂：一个客户在淘宝买了一件商品，又在天猫买了一件商品，那么客户应在在淘宝或者天猫任何一个客户端上，看到这两个商品；现在如果是两个独立的系统，那么很多类似的功能，做起来会非常费时费力。
不利于业务的沉淀和继续发展：例如某个业务流程需要优化，那么就要在每个系统里面改一遍。
“大中台，小前台”说白了可以看成：淘宝和天猫都有很多类似的功能，那么把这些功能单独的抽出来，作为一个一个独立的系统，比如会员系统、商品系统、物流系统、支付系统等等。一个完整的系统，就是一个前段+各个流程所需系统组成。
那“大中台，小前台”的共享服务体系到底有什么优点呢？
服务可重用：例如淘宝和天猫都要有支付，那么就单独做一个支付服务；不必为不同的前端业务，开发相同或者类似的服务。
服务被滋养：书中提出了一个观点：服务最不需要“稳定”。服务需要被不停的滋养，促使服务不断的自我成长，这样服务才能最终成为IT资源，而服务所需的滋养正是来自新的业务不断的接入。
服务助创新：共享服务平台中的诸多服务是经过清晰的沉淀，可以通过重新编排、组合，快速的响应市场，达成创新，说白了就是一个字儿——快。
服务敢试错：共享服务平台由于具备快速编排、组合服务的能力，可以以较小的成本投入来构建出一个新的前端业务，即使失败了，公司损失也很小。
希望我的回答，能够帮助到你！
我会持续分享Java程序开发、架构设计、职业发展等方面的知识和见解，希望能得到你的关注【会点代码的大叔】。
