阿里的“大中台，小前台”战略从2016年到现在，渐为人知，也随着阿里在多个业务领域站住脚而被认为是一种成功的模式。2016年的几乎同一时刻，我在凡普也提出了“大平台，小前台”的战略，并有效支撑了凡普之后在业务规模和种类上的快速扩张。国内为阿里马首是瞻。很多人，包括在凡普内部，认为平台战略就是复制中台战略。虽然我在凡普的时候多次解释，还是有必要在离开以后以文字再说明一下。
首先由于竞争激烈和外在不稳定因素，传统的职能型组织很难适应这样的发展，因为国内的业务发展是非常强调“快”的。简单的说，由于职能割裂，技术部门就好像一个外包团队，以排期来接活，不理解业务需要，也很难为结果负责。大项目中的协调合作是一个令所有人头疼的事情。业务部门也对项目排期不满意：别说把你排到靠后，即使是排到第二个，你也肯定是不满意的。这样业务需求就会尽可能的占用技术的“资源”，因为对他们来说这是免费的，需不需要趁着排期排上了，“做了再说”。
中台战略和平台战略都是说，打造扁平的小团队，符合敏捷精益的方法论，即业务团队也会包括技术职能实现业务线的需求。中台团队打造对内服务的公共模块。业务团队基本上不会受制于中台团队的排期，但是要对自己的成本负责。
然而这样的中台，会和前台有很多矛盾，而且既然是中台，那还有后台了，比如更靠后的类似财务这样职能线，也会和中台产生矛盾。最常见的问题包括：
1. 一个似乎公共的模块，中台没有这样的服务怎么办？
2. 业务线提出不合理的需求怎么办？
3. 责任和利益怎么分，比如生产事故的处理和业务激励的分配？
另外一种是完全扁平化团队，即阿米巴。其好处是减少大公司内的沟通协商成本，以最大的灵活性开展业务。
来看看阿米巴的问题：
1. 重复造轮子，每条业务线都要重复相同的基础建设，软硬件资源都浪费严重；
2. 跨业务线的战略协同开展困难。
重复造轮子有一点浪费，在粗放型发展的阶段还能够忍受，但是后一条，协同困难会造成数据孤岛，在需要深度使用和分析整合数据，甚至提升到人工智能层面的后互联网时代，成为巨大的瓶颈，制约包括不点名几个巨头级大公司的进一步发展。
这些就是平台战略所要解决问题的一些出发点。
平台战略以产品的形态来服务各业务线。这是在阿米巴的基础上解决中台问题的关键。理解这个问题，我们要后退一步理解技术工作的本质。其实技术的产出，本身也是一种业务，最极端的就是软件外包，然后是基于工具的各种定制化，比如在美国，Salesforce、Oracle、IBM都是这样的解决方案提供商，换句话说，就是现在开始谈起的To B业务。
也就是说，哪怕还没有对外提供服务，公共服务团队也应该拿一个2B业务的标准来要求自己：产品标准化、提供售前售后解决方案、产品运营和客户渠道关系维护等等，甚至要核算成本以及通过定价机制形成营收。
从自身发展来说，这有利于平台团队以市场化的需要规划自己的标准公共服务产品，而不被业务线牵着鼻子走，避免成为“免费”服务，尤其是其中的一些业务需求是不合理的。
对集团发展来看，平台产品通过业务线的打磨，逐渐成熟。各业务线通过使用平台，自然起到数据规范和整合的作用，比行政命令式的治理效果要好得多。成熟的平台产品也为技术赋能转型提供可能，在内部服务基本满足的时候，向行业输出技术能力和解决方案。
事实上，阿里有大量的技术人员和残酷的团队内部竞争来支撑这样的中台战略。这些对于一般的公司来说，太奢侈了，而阿里云就是事实上业务化的平台技术团队。
总之，平台战略忠于敏捷精益端到端，全职能，目标一致的方法论，以市场化产品的要求规划技术团队的工作，激发团队的自驱性，提升对业务的敏感度，对工作的结果真正负起责任，并获得收益和认可。“前中后”与其说是分层，实则造成断层，谁能说阿里云不是在“前线”做业务而只是中台呢？
方亮
2019年元旦于加州圣荷西
P.S. 台湾有个中台禅寺，是已经圆寂的惟觉老和尚一手创建的。我有幸在美国湾区阳谷县的分院学习过禅修，以此也纪念一下。阿弥陀佛！
