1.2 企业信息中心发展的症结
笔者初次了解到阿里巴巴共享业务事业部的发展史时，就有很大触动，一部分原因是我亲眼见证了阿里巴巴为了更好地满足集团业务快速发展的需要对组织架构的多次调整，这个过程充满了集团领导的思考和智慧，也经历了艰辛的尝试，才使得阿里巴巴集团在今天充满残酷竞争的中国互联网时代屹立于强者之列；另一个原因则是我发现阿里巴巴在2008年面临的问题跟现在很多企业面临的困境非常相似，而经过阿里巴巴多年打磨和验证过的这套共享服务体系可能是让非互联网行业的企业摆脱困境的最好出路。
我为什么会产生这样的想法呢？让我把前面漫画中的一些问题和现象与现在企业中的问题和面临的处境做一下映射。
1.?“烟囱式”系统建设模式
在图1-2上左中，大家看到了2008年时淘宝的技术团队同时支持着淘宝和天猫两大电商平台。1999年成立的B2B电商平台1688一直拥有自己的技术支持团队。阿里巴巴集团三大电商体系的技术支持架构如图1-4所示。
图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所示。到了一个时间点，量变产生质变，就会出现企业核心业务系统运行多年后被推倒重来的现象。
图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基础架构，将是接下来几个章节详细阐述的重点。