钟华@编著 机械工业出版社 2019年5月第1版
第1章 阿里巴巴集团中台战略引发的思考 (cause)
烟囱式 系统建设模式弊端(P8)
- 重复功能建设和维护带来的重复投资
- 打通“烟囱式”系统间交互的集成和协作成本高昂
- 不利于业务的沉淀和持续发展
第2章 构建业务中台的基础–共享服务体系 (why)
2.1 回归SOA的本质-服务重用 (P15)
- SOA是目前业界被验证的真正赋予企业业务快速响应和创新的科学架构,包括微服务也是SOA演变后的一种呈现方式。
- 设想以下,如果企业的业务架构也是基于共享服务体系构建的,相关业务领域的业务功能和数据模型原生的就在业务层汇聚到了一起,此时烟囱式系统的第一个弊端就可以有效避免。
2.2 服务需要不断的业务滋养(P17)
- 服务提供者在主观上没有太大的积极性满足新的业务需求,再加上如果当初服务设计的功能扩展性和业务前瞻性不足,导致有心无力满足新的需求,结果就是这些服务无法再进行功能扩展,成为企业 “业务稳定” 运行的 “服务”。
- 而我想说的是,服务最不需要“业务稳定”! 一个服务如果一味追求功能的不变,一定程度上就是固步自封,这样的做法是逼着其他系统取建同样的“轮子”,当越来越多的系统都采用自建轮子的方式取满足需求时,之前的这个服务就少有人问津,当有更好的服务出现或者该服务完全满足不了当前业务需求时,也就是这个服务离开历史舞台的时刻。
- 服务不需要 业务稳定,而需要不停的滋养,只有在滋养中才能从最初仅提供单薄业务功能的服务逐渐成长为企业最为宝贵的IT资产,而服务所需要的滋养正是来自新业务不断的接入。
2.3 共享服务体系是培育业务创新的土壤 (P19)
- 企业真需要的创新一定是来自于企业内部,而不会由外面所谓的专家告诉你如何创新
- 专家的形成:掌握各种基础的知识点;有意识的将知识点串在一起,形成知识线;知识线的汇聚构建了知识面(认知领域)
- BCP(Business Check Platform, 业务校验保障平台) 的建立,就是在“点”上感知不到的问题,在“线”和“面”的平台上,通过专业的技能解决,这就是很好的创新!
2.4 赋予业务快速创新和试错能力 (P21)
- 企业要想在互联网时代拥有绝对的竞争力,我觉得业务试错是一个非常重要的能力,先人一步,唯快不破,才能帮助企业抢占商业先机的制高点。
- 互联网时代的竞争只有第一,没有第二,这是我认为互联网公司的IT架构能力和传统企业的最大差别。
- 如果打造了很好的业务中台,可能以前20个人,4个月的项目现在就让3个人2周内建好并推向市场。
- “大中台,小前台”战略思想中,小前台具备以下特征
1. 团队协同效率最高
科学证明,人数是7个人的团队协同效率是最高的
2. 对战机(商机)的把握更加敏锐
小团队具有创业意识,具有生死忧患,对战机(商机)的感知会更加敏锐
3. 调整方向更加快捷
俗话说,船大掉头难。小团队的方式进行业务的试错,一旦发现方向性错误,不管时调整方向还是放弃,对于企业的投入都是在可控范围内
4. 一旦发现正确目标,全力投入扩大战果
战团队找到了正确的攻击目标,一个远程呼唤,后端的中台炮火群会瞬间摧毁目标,这就是中台阵型发挥威力的最佳体现
2.5 为真正发挥大数据威力做好准备 (P25)
- 服务共享体系可以很好的解决大数据方面的两大问题:
1. 数据分布广、格式不统一、不标准
2. 缺少能基于数据有业务建模能力的专家
2.6 改变组织阵型会带来组织效能的提升 (P28)
- 传统应用开发模式下各技术人员(架构师,UI,开发人员,运维,DBA) 的组合可以堪称一个精密的流水生产线有一个弊端:个人技能的提升会遇到瓶颈,大部分工作都是重复的,最终会丧失积极性或者跳槽。
- 各服务中心的需求都输入到流水线中,各岗位的人员每天都面临不同业务的需求,对各服务中心现有的能力很难有清晰和深入的理解,不容易提供专业的支撑,自然会对最后提供业务的专业度和稳定性带来很大隐患。
- 应该针对每一个建设的服务中心,有一个完整固定的组织,对服务提供持续的服务和运营。
- 阿里服务体系中,每一个服务都是由则100人,多则4, 500人的团队进行专业的运营,每个团队对自己的服务逐步完善,稳定负责的过程中,由足够的时间和机会对该服务相关的业务领域有更深入的理解,从而为团队培养出既懂技术,也懂业务的复合型人才创建了良好的生长土壤。
- 最核心的角色就是业务架构师,既懂技术,又对负责的业务领域有相当的理解。这些人一般都是技术出身,在多年业务领域的需求浸染中,不断形成了对该业务全面的知识体系以及自身的理解,对该业务在集团内的职能定位、市场发展趋势有一定的全局认识,能从业务的视角带领团队朝着服务中心的核心能力打造并不断成熟的方向前进。
- 业务架构师既作为整个服务中心业务发展的领路者,又是保障服务中心核心业务具备通用性和公共性的最重要的捍卫者。在对接前端业务需求时,一定要进行过滤和判断,不能损害服务中心的通用性。
- 当然,以上组织形态也不是金科玉律,在实际发展过程中也会针对业务发展的需求进行适当的调整。比如UED采用资源池的方式,为不同的服务中心甚至前端应用可供专业的UED支持。