分享程序员开发的那些事...
更新时间：2022-08-22 13:50:28
马老师参观一个著名的游戏公司Supercell之后提出了中台思想，简言之就是“小前台、大中台”。 Supercell从表象看有200多名员工，一个游戏通常4-5个人研发，截止到2016年3月，Supercell面向全球市场推出了《部落冲突》、《卡通农场》、《海岛奇兵》和《皇室战争》四款游戏。大致可以分析Supercell采用的策略：
Supercell由于其游戏业务的特点，或与其它业务的研发模式不同。但有一个共同性思考，就是一个良好的中台首要的支持前台业务的快速创新。几个人干1-2个月，业务可以close，不用心疼。但如果百人月的产品，试错成本太高，时间方向也不满足高速变化的市场需要。
类比美军作战模式，就可进一步感受中台的作用。美军在二战时期，以军为单位作战；越战时变成以营为单位作战；中东战争时期进化为7人或11人的极小班排作战。之所以美军的“小前端”如此灵活，因为有强大的中台能力，给前端军队提供各种资源支持以及中台炮火群支持打击。
From：陈华编著《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》图2-4 战场中的中台阵型
我理解，中台不是凭空而来，亦不是平台化架构换个名字。中台化架构是平台化架构的自然演进。一定规模的互联网IT公司都可能有一个叫共享平台或者平台技术这样的部门，就是把业务基础设施和技术基础设施下沉，然后由对应的研发和产品部门去负责。但久而久之，共享平台就成了资源中心，前端业务找你就是要人干活，平台做的也是接客干活。如前文所述，各平台接客模式协同负责度高，周期长。一个商业系统不仅仅是组织几个component，而是需要解决方案。中台提供的能力可以是service、可以是由service组合的组合能力、亦可以是解决方案(solution)的直接输出。
前面提个平台化目标是高内聚、低耦合；职责边界清晰；易于集成等。那么中台化架构进一步可总结为：高内聚、低耦合；数据完整性原则；业务可运营原则。当然，从架构方法来讲，宜采用渐进式架构的演进原则。如果一个中台把若干平台聚拢起来，对业务支持的SLA没有变化、也没有在业务运营上有所改变，一定是失败的。
以上图为例，业务在发展过程中，会有若干业务系统。平台化的架构是按项目模式，把公共平台和业务系统的架构师，开发，测试，产品搞在一起协同、排期、研发、上线。中台化架构可以在进一步把平台能力按能力、服务、实体进行管理。把平台划分为系统运行、业务运营2部分。实现80% 甚至更多的业务需求由业务团队自助进入。这反映到前端业务上支持效能提升了，中台的代码基本不用研发，沟通成本也急剧下降。其2，中台的架构师和研发队伍可以把精力放到中台能力提升，从运营视角发掘类似业务全息查询、数据产品这样的创新。
电商中台的负责人玄难提到：我们讲整个淘宝最早是一个系统搞定，后来不行，必须分拆，用分布式架构，后来每个系统又很复杂了。阿里的生态太大了之后，其实每个人进来已经不知道阿里有什么了，所以必须通过中台把我们有什么能力要呈现出来，让业务方根据自己的需要去选择去使用。同时，我们在架构上能让业务方在这些能力上可以自己去定制，组装成自己的业务。当前的问题通过中台的思路去解决，慢慢这个矛盾就会变低，但必然会产生新的矛盾，就需要用新的思想去解决。
同时，电商业务中台，有四件事情肯定要去做：
第一，保证阿里的业务跑得更快，更稳定。比如保障双十一稳定，同时不断提升前台业务的开发效率。
第二，产生创新。有三种形式，一种是我们看到了某个业务模式比较好，我们会把它变成一种基础能力，提供给更多业务方用；第二种是打通业务之间的连接，例如把阿里生态中A业务和B业务连接，提供给客户新的价值；第三种是通过自己的思考形成新的产品能力，就像前面提到的「地动仪」。
第三，根据集团的需要进行新业务孵化。孵化到一定阶段，觉得可以独立发展的，我们分拆出去，就像我们现在重点投入的海外市场。
第四，人才的培养。在中台，我们能看到集团所有的业务，同时也支撑所有的前台业务，相对来说系统性思考，全局性思考会更好一些。所以，我们也会根据需要给前台业务培养和输出人才。
实现中台有不同的方法和实施路径，但可以总结出类似的目标和价值。
有人讲，是否是足够庞大的组织才需要中台思想呢？我觉得不尽然。先说庞大的，曾经淘宝使用近百人、几个月的浴血奋战搞了一个统一的CRM平台。但是大部分商家并不买账，最后这个系统下线了。因为淘宝的几百万商家划分不同行业，规模也有很大差异，不可能靠一套系统解决。后面淘宝通过开放生态建设，把消费者服务、商家IT服务、商家运营服务做了分类，依托15万家ISV来搞定几百万家商家不同需求。按我的理解，这就是中台化实践，通过开放赋予不同业务，不同商家业务创新的机会。同时通过一系列运营服务比如数据分析工具促进了商家业务量的变化，是运营赋能业务的体现。
第2个case，来自转瞬之夏《一次交易失败引发的血案和思考》。故事大概是这样的：
任何一个合格的产品负责人，都会具有一个特点，就是喜欢使用、捣腾自己的产品以及同行的产品。就拿今天来说，抱着思考产品特性和探究异常处理逻辑的想法，我故意在收银台签约并支付时，输错3次短信验证码，果不其然，在点击支付时，系统报交易存在风险，交易失败。
一切都和预期一致，于是我想，简单测试完了，估计是触发了风控规则，，找客服帮我解锁吧。但想了想，正好可以验证下这种输错验证码被拦截的常见场景，客服处理起来效率怎么样。
于是我找了在线客服，然后角色扮演一位不小心输错验证码而被锁的可怜顾客，并只提供少量信息。我本以为是很简单就能定位的事，所以也估计客服也能很快就能解决。但实际情况是，客服给了我一个完全错误的解决方案，而且把出现异常的原因认定为我输错了银行预留手机号导致的。
......
作者提出的关注客户，关注客服，关注体验的观点，我很认同。但这个问题具备普遍性，想站在中台的角度多说几句。站在平台化思考问题，对于你的服务对象，可能是割裂的。
平台化的协作可能是这样的，YY一张图：
从上图可以看到，用户可能在做某项业务比如购买的时候到收银台；他没有正确完成签约；触发了风控规则。那么一般而言，如果客服是人肉服务模式的话，通过知识库查询对应问题的答案告知客户，或者找产品，产品找开发，开发找安全团队的开发或产品，进行一系列讨论，最终给出答案。
回顾一下，我前面提出的平台化思路的不足，平台职责明晰，但如果站在用户（商户）服务和支持的视角，就全然不是那么回事了，用户对了解内部职责的划分没有兴趣。他们只想快速，准确的给我解释，告诉我怎么做。
那么，我们把接触客户的部分当作客户服务中台，把共享服务当作共享业务中台，前端Bu业务作为xx业务中台。这些中台之间需要按照服务对象来梳理能力，并互相协同。
如上图所示，业务共享中台和业务中台的业务产品上下线、对客可见的规则变更类需要联动到服务中台的知识库、help页面。而服务中台运营对产品分析，产品改进提出反馈。业务共享中台拥有全部的基础数据和系统链路资产，可以提供用户画像数据、业务全息查询等工具给服务中台。有此可见，多个中台互为消费关系，虽然各中台职责分明，但如何更好的服务业务，服务用户，提升企业运营能力甚至支持产品创新都是最基础的原则。
总结：平台化相比于烟囱型架构基于提升效能，消除重复，职责聚焦的视角而来；而中台化是平台化的自然演进，以进一步通过改变组织阵型提升效能、数据化运营、更好支持业务发展和创新。任何应用架构、组织架构都没有终点，只有“合适”。当非关键冲突变成关键冲突的时候，又是新一代架构要持续升级的时候了！
QA：
Q：银行的组织架构也划分了前台、中台、后台。 前台通常是以客户为中心，和客户直接打交道的岗位；中台一般不直接接触客户，但要负责制定业务策略、风险控制等；后台主要是业务的处理和支持。 前中后台分离后，通过流程银行来支持业务运营，建立呼叫中心、单证中心、集中作业中心等，提高效率降低成本、降低人员要求，让专业的人做专业的事情。 IT架构为适应业务架构，通常也是划分了前台、中台、后台系统。 而基础的技术支撑平台则是共享的，如开发工具、开发框架、运行平台、基础设施（云服务、中间件）、基础组件（认证、安全、通讯、加密、审计等）。 等）。那么这里的中台化是不是就是银行组织结构的中台？
A：
我觉得不尽然。不同平台无论在业务的组织形态还是上下游关系上有”前台”、“中台”、“后台”的分野，但如果是分离提供服务支持业务的模式，那么就没进化到中台模式。中台模式可以构建解决方案能力，快速支持业务，消除平台之间的gap、通过组织变革配套促进创新。传统的前台业务比如to C的客户接触、受理也可以升级中台思维。能不能做全渠道打通？能不能提升用户体验、精准服务用户？等等，跳出柜台受理、网银受理的界限和框框，全渠道全业务，或有更好的用户黏性也未可知。
附录：面向全球化的业务中台
From：http://blog.csdn.net/mini_monster/article/details/51175903
参考材料：
简书：转瞬之夏的日记本（http://www.jianshu.com/p/5207680ea08c）
阿里研究员玄难：如何做电商中台
淘宝和天猫背后，阿里系还有一个不为人知的神秘组织
陈华编著《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》
云栖社区：平台化三部曲之一微核心可扩展架构 - 从Eclipse平台看交易平台化