传统IT架构的问题

1 详细介绍共享服务理念给企业业务发展带来的业务价值

2 阿里巴巴在建设共享服务体系时如何进行技术框架的选择，哪些重要的技术平台支撑起了共享服务体系

3 阿里巴巴内部的一些经验和实践，入组织的架构和体制如何更好的支持共享服务体系的持续发展

4 最后结合两个典型案例来介绍如何在实际工作中应用共享服务体系

从supercell模式说起：

这家游戏公司经过6年的时间将游戏开发过程中公共，通用的游戏开发素材，算法做了很好的沉淀，企业的文化充分鼓励员工进行创新，甚至进行试错，才使得他们在开发的众多游戏中以最快时间找到哪些用户真正喜爱的游戏，这种强大的试错能力是

supercell相比于其他游戏公司最大的差别，也是核心的竞争力。其他的游戏公司难道没有想到学习这样的模式么？答案一定是肯定的。为什么其他的游戏公司不具备supercell这样的能力呢？我觉得很多人忽略了supercell所构建的中台能力。抛开个人水平高低的影响，supercell公司在多年的游戏研发中积累了非常科学的研发方法和体系，使得今天公司可以支持几个人的小团队在几周时间就能研发出一款游戏，并进行公测

2013年电商对传统零售商的分销模式产生了巨大的冲击，这些品牌商就着急要获取到最终用户的消费行为，爱好等信息。从而为用户的精准营销做有力的数据支持，但发现用户的会员信息，消费行为信息等都被烟囱式的系统建设方式拆分到不同的系统中，因此不得不开始打通这些烟囱，从而获得品牌商所需的全局会员以及消费数据。面对这样的业务需求和系统处境，业界早在十几年前就提出了SOA,ESB理念。很多企业通过ESB系统很好的实现了多个独立系统间的打通，不可否认ESB的架构很好的屏蔽了服务接口变化给服务消费者带来的影响，是解决不同系统间实现互联互通的很好的架构，但这样的项目在企业中落地后，后面的发展就让SOA价值的体现出现了本末倒置的现象。

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

产生这种现象的根本原因就要追溯到企业实施SOA的方式，典型的项目实施模式，在确定了贯穿多个系统的主业务流程后，就要求各个相关的系统进行服务的封装改造，这中模式是典型的自顶向下的建设模式，而这个时候，各个需要提供服务和改造的系统无不均属于各自的运维期，所以对于服务开发相关的工作，运维人员的心态往往协同和配合，没有太多的积极性。

所以有个很严重的问题：当SOA成功实施结束后，后续有新的业务系统希望接入这些服务，而新的业务系统又发现现有的服务不能很好的满足他们的要求，希望提供更多功能或更好体验的服务要求时，在现实中就会出现下面两种情况：

1 服务提供团队不管是从KPI考核的角度，还是从认知上认为服务封装的任务已经完成，所以当他们收到新的服务需求时，心里上拒绝的，最终的结果是新业务系统认为该服务不可用，逼着他们在自己的系统中重新有实现了一套跟这个服务差不多的功能模块，也就是产生了一个新的烟囱。

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

这也就是很多年中，在很多企业经常上演的一幕：一个系统上线运行5~8年后，企业的信息中心会向领导人提出随着业务的快速发展，现有系统不管是技术架构还是业务模型都不能满足现有业务发展的需求，需要整体系统升级。而这样的升级往往意味着对原有系统推倒重建。这对于企业来说是可能是最大的资产流失。

传统的IT系统建设模式下，上线的系统就进入了系统维护期，这个时间段实际上是系统对业务需求响应非常不敏感的阶段。如果说过去，业务需求的增长态势还算比较平滑，没有体现出系统的响应能力有多大的差距，那么今天，互联网时代业务需求的增长越来越迅猛，原有系统对业务响应的能力就显得更加捉襟见肘。

对于技术人员来说：

我们看到能力较强的员工能体现自己价值的地方在于负责的项目更大，甚至同时负责多个项目，而这里终归是增加了项目经验，并不能在某以专业领域得到知识和经验的沉淀，相信随着时间的流逝，越来越多的人会慢慢失去最初的工作积极性和创造性，这样最终的结果是IT信息中心的员工很少能在一个业务领域做足够的深入的了解和业务沉淀，更多的是对业务知其然，不知其所以然，也谈不上成为业务领域专家，更不能对业务发展提出创新想法和独到见解。