经高人推荐，所以买了一本学习下，争取两周读完，这一周读了一半左右。不过我读书慢，写读书笔记更慢，不知道要花多少时间能写完。
这本书是讲阿里巴巴中台战略和架构的书，看起来似乎和敏捷转型关系不太紧密，其实不然。之前读《大规模敏捷开发实践》这本书，感觉书中讲的关键的一点也是架构。对于复杂产品的大规模敏捷，一个良好设计的架构其实还是必须的，不然应对变化时很难快起来。不过公司里部分同事对敏捷宣称的“演进式架构”是有疑问的，认为产品的架构还是需要先深思熟虑的设计好，打好地基之后才能向大厦中添砖加瓦。想起《代码大全2》中对软件开发的多种隐喻，生长的隐喻主要是针对敏捷开发方法说的，建筑的隐喻主要是面向大型软件的，但是最后的总结部分也提到，其实多种隐喻之间并不是矛盾的，可以同时应用多种隐喻。

序言

本书讲述了阿里巴巴的技术发展史，同时也是一部互联网技术架构的实践与发展史。

序言中的第一句其实也已经说明了，架构不是预先设计出来的，而是根据实际情况不断演化出来的。

不同于搜索、社交之类的应用系统，电子商务、支付的业务特性决定了其必须有很高的稳定性与可靠性。用户在使用搜索引擎的时候，哪怕丢失了一半的搜索结果，用户可能都没有觉察。但在电子商务应用中，每一笔订单、每一个状态、每一次支付都不能有丝毫查错。与此同时，像双十一这种业务高峰时刻，每秒钟就需要处理十万笔以上的订单。高可用、海量、复杂的业务逻辑交织在一起，是阿里巴巴系统的主要挑战。

其实我们的电信运营支撑系统也是涉及到钱的，一旦出现费用计算类的错误就是大故障。我们的业务逻辑也足够复杂，TW的技术教练在帮我们重构业务代码时认为系统的业务逻辑比他之前接触过的系统要复杂很多，积累的历史遗留代码量也很大，重构的难度和工作量都要大。读到这段时心里不禁在想，我们系统的业务逻辑有没有可能比阿里的还要复杂？

架构解决的是创新效率的问题，举个例子，要做个新业务，如果需要100人年的成本，可能投资人会犹豫；如果是100人月的成本，就果断决定投了。从这个角度说，一个优秀的架构已经超出了效率本身的范畴，而是决定企业成败的关键因素。所以说卓越的IT绩效已经成为企业的竞争优势，将来可能所有的企业都会变成软件企业。

最大的浪费不是重复建设，而是不断重复建设。

公司的新产品版本不停的迭代演进，经常在做颠覆性的架构变化，也是遵循从单体应用到分布式，最后到云化的微服务架构的路线。上层的业务特性确实是在不断重复研发，存在这样的浪费。不过记得之前肖大师说过，V9基于云的微服务架构将是终极架构，不会再推倒重来了（Serverless会有影响吗？）。感觉这本书中说到最后，讲的就是阿里如何把自己的架构演进到微服务模式的，而亚马逊是从2002年就开始了这个演进，贝佐斯其实是个天才的架构师，不过他对架构的要求把工程师们折磨得半死，十年的磨炼成就了AWS。到现在微服务基本上成为事实上的架构标准了（5G已经把微服务架构作为标准），DDD也随之流行起来。
软件研发方法、范式的演进，其实一直都在考虑和解决的就是重用的问题，宏、函数/方法、类、包；面向过程、面向对象、面向切面、泛型、函数式。现在到架构，就是重用程度越来越高，粒度越来越大的过程。
谈到最大的浪费，不记得这几天在哪里看到的，认为精益思想中提到的最大的浪费其实是未能人尽其才，把公司中每个人的潜能都发挥出来。其实消除这种浪费也是公司推行敏捷转型的主要原因之一，即便每个人的潜能只是多发挥10%，公司也会变得很不一样。有点跑题了，还是说这本书。

第1章 阿里巴巴集团中台战略引发的思考

阿里的中台战略是2015年底开启的，开篇先讲为什么，看来做什么事情都要遵循黄金圆环理论，从why开始。
2015年年中，马云带着阿里高管拜访了芬兰的游戏公司Supercell，被震惊了。这个公司是典型的小团队运作方式，每个独立团队不超过7人（典型的Scrum团队规模），称之为Cell（细胞）。团队自己决定做什么样的产品（自组织的团队），以最快的速度开发出公测版，获取用户反馈（精益创业的模式），如果用户不欢迎，迅速放弃这个产品（fail fast, fail cheap）。团队失败时没有惩罚和悲伤，反而会庆祝从失败中学到了东西（容忍失败的文化很重要）。这个模式使得Supercell成为年税前利润15亿美元的游戏公司（游戏产业真的好大）。这个公司有多少人呢？不超过200人。这个公司开发过哪些游戏？有《部落战争》《海岛奇兵》《卡通农场》等（前两个游戏我见过广告，不过已经过了玩游戏的年纪，没有玩过）

这种强大的业务试错能力是Supercell相比于其他游戏公司最大的差别，也是最核心的竞争力。

为什么Supercell能按这种模式运作？是因为它构建的“中台”能力，包括多年积累的非常科学的研发方法和体系（研发流程和方法也是核心竞争力之一）。所以阿里后续确定了“厚平台，薄应用”的中台战略。
其实大家都是在向美军学习吧，通过加强后端支撑平台的能力，向前方战斗团队赋能，让前方团队自行决策，以提高应对复杂状况的能力。看到樊登今年推荐的第一本书就是美军一位四星上将写的《赋能 打造应对不确定性的敏捷团队》，后面也要读读这本书。

想到个小问题，游戏和阿里的业务都是2C的，快速获取用户反馈相对容易，而2B的难度就大很多，涉及到客户关系等复杂问题（参考《Lean B2B》），所以是不是也不完全适用？公司里推行敏捷时也有类似的声音：“客户并不需要我们持续交付，只要能按计划交付就可以了”。对这个问题，我自己的想法是修屋顶应该在晴天，等到雨天就来不及了。不过，阴天的时候是修还是不修呢？

1.1 阿里巴巴共享业务事业部的发展史

这部分讲述了共享业务事业部的发展历程。刚开始成立这个部门时淘宝和天猫都不买账，业务单位显然话语权更大，下面这幅图很形象：

然后聚划算业务爆发，阿里集团出台强制规定：

这时就出现了对于共享业务事业部历史转折点的一个举措，集团要求三大电商平台如果要与聚划算平台进行业务对接，必须通过共享业务事业部！
这个规则出现之后才真正把前端业务中公共、通用的业务沉淀到了事业部，真正形成“厚平台”，如下图：

image.png

架构明细如下图：

image.png

我猜测这个过程肯定不是一帆风顺的，会有很多博弈和扯皮的过程，因为多了一层间接，共享业务事业部的人员并不是最贴近一线最了解业务的，那么一线的淘宝和天猫这样的业务单位开展新业务的速度应该会比之前略慢，肯定会有不少抱怨的声音。但是如果不是强制出台规则做这个事情，各个业务单位的人力一定会不断膨胀，重复开发的浪费会越来越大。集团高层考虑的是整体优化，各个业务单位考虑的是局部优化，两者之间必然存在冲突。并且作为共享支撑单位，不可避免会面临产能无法满足所有业务单位要求的问题，会不断面临质疑，需要集团领导有足够坚决的意志力坚持这个决策才能推行下去。即便现在共享业务事业部已经形成规模，应该也还是会有这个问题。所有的变更都需要自上而下的强力支持和推动才能成功。

1.2 企业信息中心发展的症结

经过阿里巴巴多年打磨和验证过的这套共享服务体系可能是让非互联网行业的企业摆脱困境的最好出路。
我想这句话隐含的意思是阿里要把自己的这种能力对外输出，确实如我所料，书中第三部分就是阿里的能力输出与案例，有点类似IBM以前向华为输出IPD的感觉，区别在于IPD是纯方法论，中台是有实际的软件产品的。