《企业IT架构转型之道》读书笔记（部分1）
出发点：企业IT系统建设普遍面临的问题和处境
很多企业面临的问题和处境：
- 『烟囱式』系统建设模式。
当业务部门提出业务需求，信息中心部门进行系统集成商的招投标，再进入到需求收集、需求分析、开发、测试、上线的项目周期中。某种程度上，每个新系统的上线都预示着一座新的烟囱矗立而成。这种完全基于业务需求建设系统的方式，已经成为过去20多年企业建设IT系统的标准流程，导致IT系统建设早的企业内部系统烟囱林立。这正是今天很多企业面临互联网转型难的根结所在。
它带来三大弊端：
- 重复功能建设和维护带来的重复投资。因为大量的功能和业务在多个系统中同时存在，单单从开发和运维两个方面成本投入的角度，对于企业来说就是一种很显性的成本和资源浪费。
- 打通『烟囱式』系统间的集成和协作成本高昂。业界早前就提出了SOA的理念，多家厂商推出了ESB产品及解决方案，重点就是来解决此类异构系统之间的交互问题。
- 不利于业务的沉淀和持续发展。在传统IT系统建设模式下，上线的系统就进入了系统维护期，这个时间段实际上是系统对业务需求响应非常不敏感的阶段，一般半年或一年才会进行一次系统的升级。也就是说，系统业务需求响应的能力和企业本身业务发展对系统建设的要求不成比例。如果说过去，业务需求的增长态势还算比较平滑，没有体现出系统的响应能力有多大差距，那么在今天，互联网时代业务需求的增长越来越迅猛，原有系统对业务响应的能力就显得更加捉襟见肘了。
- 企业信息中心的组织职能只停留在『业务支持』上
各个企业都认可信息技术部门对于企业发展的重要地位，但是，该部门往往不具有与核心部门同等的部门话语权。该问题的核心是，IT信息部门在现有模式下已经被更高的领导层定位成了业务支持部门，是一个花钱的成本中心。
作者认为，造成这种困境的原因是因为IT信息部门的人员不懂业务。作者所说的『懂业务』是指能对业务的下一步发展有着自己的理解和看法，对业务流程如何进一步优化能更好地提升业务，甚至对企业现有的业务提出创新的想法，为企业带来新的业务增长点。
而其根本原因，是因为很多大型企业的IT信息化部门已经存在了20多年，一成不变的就是项目制的系统建设模式，这样建设项目的模式除了带来『烟囱式』建设的一系列弊端，同时使得IT信息化部门一直处于『业务支持』的职能位置，即只为了满足业务部门需求而进行IT系统建设的实施和运维部门。这种模式下， 很多企业的IT信息化部门的员工大多数的工作内容都是项目管理。当一个项目顺利上线验收后，这些员工开始投入到下一个项目的工作中。因此，其结果是，员工增长了项目经验，但并不能在某一专业领域得到了知识和经验的沉淀，其最终结果是IT信息中心的员工很多少能在一个业务领域做足够深入的了解和业务沉淀。
这些问题是如今大多数企业都遇到的问题，阿里巴巴在2008年业务系统的建设模式、组织架构以及遇到的问题，都和大多数企业是一样的。
解决之道：共享式业务中台
阿里巴巴电商系统的架构经历了烟囱式架构，到分布式架构，再到共享式架构的转变。
当前的阿里巴巴『厚平台，薄应用』架构形态如下图所示。目前阿里巴巴集团前端超过了25个业务单元，比如淘宝天猫聚划算等，均不是独立地构建在阿里云的云平台之上。在后端阿里云技术平台和前端业务之间有了一个『共享业务事业部』，将阿里巴巴集团前端业务中公共、通用的业务沉淀到了这个事业部，包含额用户中心、商品中心、交易中心、评价等十几个中心。共享业务事业部正是『厚平台』的真实体现，为阿里巴巴各种前端业务提供着相应服务中心领域内最为专业、稳定的业务服务。
价值：摆脱『烟囱式』系统建设带来的各种困境
共享服务架构的建设，使得阿里巴巴摆脱了因为『烟囱式』系统建设方式带来的各种问题，最终成为阿里巴巴业务中台战略的核心组成。
1. 回归 SOA 的本质 - 服务重用
作者非常认可SOA的理念，但是SOA在落地时候变了味。具体表现在：
- SOA 在企业落地时，无一例外都是通过ESB（企业服务总线），使各个系统以服务封装或服务调用方式实现了不同系统见的业务交互。其本质上，仅仅是采用了服务的形态，以技术的视角选择了一个科学的方式实现了系统互联。
- 这对于企业中业务服务的持续发展和沉淀没有任何帮助，根本就没有实现SOA理念最核心的架构：松耦合的服务带来业务的复用，通过服务的编排助力业务的快速响应和创新。
- SOA 理念的提出，原本是真正为企业的IT系统建设指出一条光明大道，真正提现SOA核心价值的正是这些服务，只有这些服务在业务发展过程中得到持续的演进、功能逐步完善和增强，最终变为企业在该领域最为专业的IT资产时，才能真正打到SOA中所描述的业务的快速响应，更好地支持业务创新。但实际上，SOA的项目都沦为了实现多个系统之间的集成。
而阿里巴巴已经将集团20多个核心业务中的公共的、通用的业务以服务的形式沉淀到了共享业务事业部。整个集团的核心业务能力均建立在这样一套共享服务体系之上，使得SOA架构的核心价值 - 服务用重用 得以实现和发挥。
2. 服务被业务不断滋养
要解决的问题：『烟囱式』系统方式以及SOA『项目制』的建设方式，导致了业务得不到沉淀和持续发展，从而造成服务不能真正成为可重用的组件，为业务的快速响应、支持业务快速创新带来业务价值。
原因：SOA项目是一种集成项目建设的方式，就很容易造成服务提供者面对业务提出更多要求时，考核指标、工作回报都不能得到很好提现，服务提供者主观上没有太大的积极性来满足新的业务需求；再加上如果当初服务设计的功能扩展性和业务前瞻性不足，导致有心无力满足新的需求，结果是这些服务无法再进行功能扩展，成为企业『业务稳定』运行的『服务』。
结果：如果一个服务一味追求功能的不变，一定程度上就是固步自封，这样的做法是在逼着其它系统去建设同样的轮子。当越来越多的系统都建设自己轮子的时候，之前的服务就慢慢少有人问津，它就会逐步退出历史舞台了。
解决之道：服务不需要『业务稳定』，而是需要不停的滋养。只有在滋养中才能从最初仅提供单薄业务功能的服务，逐步成长为企业最宝贵的IT资产，而服务所需的滋养正式来自新的业务不断进行服务的接入。
做法：阿里巴巴共享事业部的『服务』『滋养』『稳定』这三大价值定位，定义了共享服务的真谛。服务能力的沉淀和体现的业务价值是完全成正比的，需要一个长期、持续的过程。企业不能再走入『项目制』实施SOA项目的误区，而是需要更多一些耐心，在接下来的业务发展过程中打造这些服务。这就要求新的业务必须接入这些已经产生的服务，为这些服务能够变得更加专业和稳定带来急需的需求养分。
3 共享服务体系是创新的土壤，业务中台赋予业务快速创新和试错能力
需求：今天所有的企业，应该在互联网时代具备一种跟互联网公司一样的业务快速创新，甚至是试错的能力。
问题：传统企业中，一定是需要申报预算和立项来落实业务创新的想法，传统『烟囱式』的系统建设方式对项目投入的资金和资源自然不会少。在申请大量资金而且项目还有失败的可能性的情况下，有业务创新想法的人在考虑到失败带来的影响时，一定会权衡其中的利弊，大多数人会选择退缩。
解决之道：利用业务中台为业务创新提供一个坚实的中台。通过中台资源的优势，支撑业务的快速创新和业务试错。有了业务中台后，利用原本就建设好了的专业服务，使得企业在投入少的情况，快速收获了更多的结果。
4 为真正发挥大数据威力做好储备
需求：大数据会是展现企业核心竞争力并发掘新的商业模式的推动器。
问题：很多企业的大数据项目并未带来期望的成效，因为有以下两个主要问题：
- 数据分布广、格式不统一、不标准。这还得归咎于『烟囱式』系统建设方式，使得相关业务领域的数据分布在不同的系统中。这位大数据平台项目初期数据的抽取和同步带来了很多的复杂工作。
- 缺少具有能基于数据进行业务建模的专家。大数据平台的威力，要有人知道怎么利用它来发挥出真正的业务价值，这是很多大数据平台难于落地或真正让企业感受到器价值的最大障碍。
解决之道：共享服务体系是解决这两大问题的不二法门。
- 一方面，通过业务中台，在各相关领域在业务和数据层做了很好的融合。
- 另一方面，共享服务体系能帮助企业信息部门培育出懂业务的专家，这些人有技术功底，随着业务能力提升，他们能成为能发挥大数据平台价值的『数据科学家』。
5 改变组织阵型会带来组织效能的提升
问题：大多数企业的信息中心部门的职能还停留在『业务支持』的程度，是为企业的业务部门提供IT系统支持的组织。
解决之道：有了业务中台，整个共享服务体系中的这些服务中心进行持续的『运营』的职能势必会落在企业信息中心这个部门。这时，可以将信息中心部门的员工按照服务中心的方式进行人员组织的重新编排，让员工在各自擅长和感兴趣的业务领域持续发展。
结果：让信息中心部门从之前在企业中『业务支持』的组织职能，转变为基于企业核心业务和数据进行运营的团队，逐步培养出企业最稀缺的『既精通业务，又熟悉技术』的复合型人才。
