读书笔记: <企业IT架构转型之道(阿里巴巴中台战略思想与
身边有两个人读了这本书并且反馈说值得推荐, 索性接着假期读完了.
企业IT架构转型之道(阿里巴巴中台战略思想与架构实战)
中台的起源
Supercell 的模式给参加此次拜访的阿里高管们很大的震撼, 在大家反复的心得交流和讨论中, 一个非常重要的问题引起了很多人的反思: 信息时代的公司架构到底应该是怎样的? 正式有了这次拜访才真正让阿里巴巴的领导层有了足够的决心要将组织架构进行调整, 在此次拜访的半年后, 集团启动2018年中台战略.
Supercell 也许只是一个引子, 阿里高层不会因为看到一家公司怎么怎么样就折腾自己的架构吧.
中台初期, 夹缝中生存
但接下来发生的事情事与愿违. 虽然组织架构上共享业务事业部和淘宝天猫平级, 但从对业务的理解和业务贡献的体现来说, 淘宝和天猫相对共享事业部拥有这更多的话语权, 结果就是共享业务事业部在两大业务部门的业务需求下艰难的生存着, 到此, 共享业务事业部的产生和发展确实与大多数人的期望有着很大的偏差
高层的架构设计是好的, 只不过不给"实权"的共享业务事业部还是不如业务大, 因此共享业务事业部(或者说中台)也搞不起来, 我猜会沦落成一个"垃圾桶": 别人来的做的功能扔给中台.....
契机
这时候出现了对于共享业务事业部历史转折的一个举措, 集团要求三大电商平台如果要与聚划算平台进行业务对接, 必须通过共享业务事业部! 正式有了这"点睛之指", 使得共享业务事业部有了一个极强的业务抓手, 将原本与三大电商业务的对话权不平衡的天平拉到一个相对公平的水平, 从而奠定了今天大家所看到的共享业务事业部成了阿里巴巴业务核心平台.
所以顶层设计再好, 也要给一个支点才能撬动现有的组织: 如果没有高层的一个决断, 想必中台也就泡汤了, 靠自然演进估计就是痴人说梦.
中台架构的最终形式
中台今天的架构
参照上面的架构图, 如果切换到自己的公司, 思路也很简单了:
- 最底层阿里云的部分, 大家各自换成自己的 Cloud Provider, 或者使用自己的基础架构替换即可
- 中间的
共享业务事业部也就是中台, 就是各自业务的核心抽象以及沉淀 - 最上面就是各自的垂直业务线.
如果不搞中台
如果不搞中台, 那么就是"烟囱式"的架构, 也就是每个业务线虽然类似但都各自搞一套, 而且多半出现的原因是业务最大, 想尽快搞定业务不就是不管三七二十一重新写一套.
"烟囱式"弊端
- 重复建设和维护带来的重复投资
- 打通烟囱式系统间交互的集成和协作成本高昂
- 不利于业务的沉淀和继续发展
关于"烟囱式"架构的弊端, 直觉想到的是重复建设和维护. 可我觉得另外两个才是更值得关注的. 随着业务的演进, 需要打通烟囱式系统的成本和扯皮成本才是让人心累的. 更进一步, 业务的沉淀以及背后带来的相关研发人员实力的提升是更大的收益.
"中台"
"中台"前的组织架构:
中台前组织架构
"中台"后的组织架构:
中台后的组织架构
在这样的组织中, 最为核心的角色就是业务架构师, 在阿里巴巴共享服务各服务中心的业务负责人就是此角色, 业务架构师的能力模型正式那种典型的即懂技术, 也对负责的业务领域有想当的理解的. 这些架构师一般都是从技术出身, 在多年业务领域的需求浸染中, 不断形成对该业务全面的知识体系以及自身的理解, 对该业务在集团中的定位 市场发展趋势都有一定的全局认识, 能从业务的视角带领团队朝着服务中心的核心能力打造专业成熟的方向前进.
按照业务划分团队, 而不是按照职能划分, 并且由业务架构师负责整个团队, 沉淀业务和技术.
共享服务中心的架构目的是通过业务拆分来降低系统的复杂性; 通过服务共享来提供重用性; 通过服务化来达到业务支持的敏捷性; 通过统一的数据架构来消除数据交互的屏障.
所以如果也实施"中台"架构, 如果达不到上述的目的, 就是失败的.
共享服务中心的一些原则:
- 高内聚低耦合
- 数据完整性原则
- 业务可运营原则
- 渐进性建设原则
不过前面也讲到, 阿里巴巴的共享服务中心也是借着领导层的"点睛之笔"强制业务接入共享服务中心才干成的, 这个渐进性原则渐进到什么时候让领导层点一把呢?
总结
搞中台, 个人理解更多的是组织上的变革, 组织上变了, 系统架构自然也就跟着变了.
这本书的价值在于前几章: 为啥要搞中台, 以及如何把中台这件事做成; 至于后面一些技术的"细节", 等遇到实际问题了再翻也不迟.
对了, 开了一个微信公众号: haitaoyao , 欢迎关注
欢迎扫描关注微信公众号
