之一：传统企业信息系统建设的弊端

阿里中台战略：厚中台，薄应用。
传统企业信息系统建设：“烟囱式”系统建设。主要有以下三大弊病：
1 重复功能建设和维护带来的重复投资；
2 打通“烟囱式”系统间交互的集成 和协作成本高昂；
3 不利于业务沉淀与持续发展。
传统企业打通各系统之间壁垒，一般在系统中采用SOA架构，但主要偏重于搭建企业ESB(企业服务总线)，使各个系统以服务封装或服务调用的方式实现不同系统间业务交互。但这只是利用了企业服务总线搭建了一个企业内部的服务路由枢纽和渠道，受项目制建设的影响，对企业中业务持续发展和沉淀没有任何帮助。
项目制的系统建设模式，技术人员最终增加的可能只是项目经验，并不能在某一专业领域得到知识和经验的沉淀，很难有对业务理解的持续积累，信息部门无法对企业业务发展往往最终沦为支撑部门。
企业架构调整首先要调整的是组织结构，屁股决定脑袋。

心得：从传统企业角度来讲，通过流程的规范建立以及架构上的高度抽象和封装，弱化个人的独特性和重要性，一定程度上是必要的，对公司来说，没有人是必须的，每个人都是流水线上的一个螺丝钉。但是在信息化和智能化快速发展的今天，传统的模式是否能满足快速响应，敏捷交付的要求？
对个人来讲，在公司框架下，满足工作要求，通过集体努力，达成公司整体的业务成功，对得起得到的报酬，这是起码的职业素养。但是，每个人也要积极考虑个人职业发展，公司的发展是否能满足个人的发展？每个人要自己对自己负责。积极思考，快速适应变化，不断提升个人能力，是唯一出路。

---

之二：构建业务中台的基础---共享服务体系

SOA的本质-服务重用：

SOA理念最核心的价值：松耦合的服务带来业务复用，通过服务的编排助力业务的快速响应和创新。
真正体现SOA价值的正是这些服务，只有这些服务在业务发展的过程中得到持续的演进、功能逐步完善和增强，最终变为企业在该领域最为专业的IT资产时，才能真正达到SOA中所描述的快速响应，更好的支持业务创新。而不仅仅只是为了实现多个系统间的集成。

图2-1 共享服务支持前端业务示意图.jpg

服务需要不断的业务滋养

前面提到的传统企业系统建设的弊病之三：“业务得不到沉淀和次序发展”。根因就在于SOA项目基于一种集成项目建设方式，就很容易造成服务提供者面对业务提出的更多要求时，考核指标、工作回报不能得到很好的体现，服务提供者在主观上没有太大的积极性满足新的业务需求。再加上如果初期服务设计的功能扩展性和业务前瞻性不足，导致有心也无力满足新需求，导致这些服务无法再进行功能扩展，成为“业务稳定”运行的“服务”。
然而，服务恰恰最不需要的就是“业务稳定”，需要的是不断的业务滋养，只有这样服务才能不断发展创新，最终成为企业最宝贵的IT资产。服务所需要的滋养正是来于业务不断的进行服务的接入。

图2-2 阿里共享业务事业部的5大价值定位.jpg

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

知识形成：点=>线=>面。对于个人也是一样，只有构建完成对某一领域的完整的知识体系，才能说是这一领域的专家。另一种模型也很贴切，T字形知识架构，T的一横是知识的广度，T的一竖是知识的深度。需要持续不断努力，并且找到大致准确的方向和方法。

服务业务快速创新和试错的能力

阿里的“大中台，小前端”战略和美军现在的战斗阵型完全一致，小的前端团队(One-Pizza team)具有以下特点：
1 团队系统效率最高；
2 对战机(商机)的把握更加敏锐；
3 调整方向更加快捷；
4 一旦发现正确目标，全力投入扩大战果。

为真正发挥大数据威力做好储备

实施大数据项目的问题：
1 数据分布广、格式不统一、不标准：传统烟囱式系统建设的后果；
2 缺少能基于数据有业务建模能力的专家：能真正发挥出大数据平台威力的重点还是要围绕着业务场景，也就是要有人知道怎么利用大数据平台发挥出真正的业务价值。共享服务体系可以帮助企业培养自身的业务专家。

改变组织阵型会带来组织效能的提升

从按照技术分团队到全栈工程师，全功能团队，团队建设。
业务架构师既要懂技术，也对服务的业务领域有相当的了解。
业务架构师即作为整个服务中心业务发展的领路者，也是保障服务中心核心业务保持通用性和公共性的最重要的捍卫者。

心得：技术架构和组织结构都是为了实现业务成功，技术架构或者架构师不能脱离业务只专注于技术，组织结构不是固定或不可变的，要根据业务场景来调整最佳战斗阵型。个人知识积累也要基于实际应用和场景。由点到线再到面，既有广度也要有深度。