中台战略作为近期大厂和品牌商竞相追逐的方向，背后反映出企业对于业绩增长进入相对瓶颈期的焦虑。
我们的观点：
（1）中台从来不单是技术的游戏，是企业战略、组织、方法论与技术的结合产物。
“中台是组织的外化，最终服务于商业模式”，脱离战略与组织维度的企业数字化转型往往事倍功半。
中台概念之所以被争相传播，与企业所面临的成长瓶颈期以及企业技术架构的发展阶段强相关。我们通过阿里中台转型的故事看到：自顶向下、切入正确的场景、产品化思维是中台战略不可或缺的要素。
（2）各互联网大厂的中台战略尽管围绕主营业务各有侧重，但无一例外希望：
- 尽可能实现数据打通
- 业务共性得到充分的抽象沉淀
- 前台业务创新迭代周期得到压缩以充分享受中台红利。
然而目前看除阿里中台相对成熟外，其余大厂中台布局道阻且长；长期视角下的互联网大厂更希望自家中台的逐步社会化，这也侧面推动了云服务市场的繁荣。而具备危机意识的品牌商也已拉开中台化的进程，但在组织变革层面的进展相较于互联网大厂要更难。
（3）我们对中台的前景坚信不疑。ERP在早期实施阶段与中台当前面临的问题如出一辙，但毫无疑问ERP的实施强力推动了企业信息化进程。
特别是在全渠道零售/服务领域，中台将在线上线下的数据、业务与供应链融合过程中大展拳脚。
对于企业，找到当前发展阶段最适合自己的组织与技术架构乃当务之急，克服盲目对中台追随的心态有助企业保持理性与健康发展，毕竟在高速行驶中更换发动机谈何容易。
开篇说：
我们认为中台之所以不能被正确和理性看待的原因尽管复杂，但并不难理解：脱离企业组织文化单独看中台，将把中台归类为技术系统的优化、归纳与升级，这将会对中台的功能定义以及落地实施的期望值造成较大的偏差。
我们认为中台≈战略与组织的外化形式，企业组织的健壮性与柔性、业务的成熟度、数据沉淀的规模以及看待中台的视角将很大程度决定企业中台建设的必要性及推进难度。
一、我们为什么关注中台：企业战略与组织的抽象与凝练
中台战略作为近期大厂和品牌商竞相追逐的方向，背后反映出企业对于业绩增长进入相对瓶颈期的焦虑。我们认为，中台不仅仅是技术架构的变革，而是一套“战略、组织、方法论、技术架构”多者协同的结果。
中台思想在早期更多以技术层面展现和解读，往往是因为技术层面是企业战略、组织、文化外化的最终结果，从中台实施的最终结果看毫无疑问要以技术架构作为落地手段。
因此，本文通过不同主线反映企业中台的成长与进化历程，以中台为切入口探讨中台与战略和组织之间的关联，并尝试归纳与总结中台未来的发展方向。
我们看到，中台的诞生并未偶然或无迹象，我们认为这与企业业务发展与人员规模的扩大密切相关，中台的诞生也或多或少反映管理层的意志（当然也承载了他们对企业的美好愿景）。
基于对中台的历史研究我们初步认为，阿里中台的发展轨迹已在业内具备代表性：阿里最初的业务以1688和淘宝为主，各自为政，面向客户以及业务对象均有较大差异。
淘宝初期主要面向C2C电商领域，全套系统围绕淘宝垂直的技术框架落地。随着业务的不断扩张，阿里成立天猫事业部主抓B2C电商，又形成了一套并列垂直的技术框架。
这种垂直式的、相互不连通的架构体系类似烟囱林立带来了诸多不足，如成本的重复投入和维护、数据之间打通复用的难度、几年之后推倒重建的风险等。
为了解决这些问题，阿里于2009年就已成立了共享业务事业部（Shared Service Center）与数据平台部，通过构建共享服务来沉淀和复用业务能力。
但由于成立初期业务话语权不强，共享服务体系的建设并不顺利。随着“聚划算”团购项目的启动，公司统一要求各系统的流量都需要通过聚划算，共享服务中心依托聚划算业务才得以大展手脚，逐步将集团核心的业务能力沉淀成为用户中心、商品中心、交易中心、评价中心、店铺中心等数十个共享服务。
共享业务事业部：地位曾尴尬到聚划算救场
二、中台的成长路径：自顶向下的战略与组织变革承接者
基于阿里中台的建设案例我们认为，企业中台的成长路径就是在企业战略与组织博弈的同时开辟的：通过战略与组织的相互博弈与妥协(战略也需要在组织调整的反馈中动态调整），最终达成一致，使得中台的形态随之逐渐迭代，形成承接战略与组织的成熟形态，进而推动业务在未来商业模式的不断（小幅）迭代。
也即：战略通过组织体现，组织效能通过中台反映，业务逐渐通过中台（而不是原有体系）进行商业模式的更新。
中台的典型架构：业务是骨架，数据是血液，双中台相辅相成
三、如无必要，勿增实体：技术架构演变催生中台方法论与落地
基于上述分析，中台需要考虑组织、方法论与技术三个维度的事项。从技术架构的演变，可以看出除了组织外，技术成熟度的提升也侧面催生了中台方法论（以及背后思想）的诞生。
从SOA到ESB理念转型为微服务架构，最早可以追溯到从亚马逊早期提出的核心管理原则的转变——我们能够从贝佐斯铁腕管理方式对中台诞生的萌芽初窥门径。
2002年，Bezos突然向全公司发布了指令，核心内容表达为：全公司数据不得成为孤岛，IT项目组之间必须以接口（API）的形式进行合作。
这使得从2002年开始直到2006年API工程迁移完成之后， 亚马逊内部技术体系逐渐调整为SOA (service-oriented architecture，面向服务)架构，每个技术组和产品组之间都是service形式，都可进行互相调用。
之后Amazon不仅在技术架构上逐渐变成业内俗称的“微服务架构”，并且使得整个组织都变得API化，不断强化对外接口的能力，AWS也间接受益于此：亚马逊早期的系统能力是按照高峰期的需求配置的，美国人购物集中在圣诞节前，圣诞节后系统的利用率仅有30%左右，其余算力都进入闲置状态，内部建议将闲置的系统计算能力和存储空间出租。
这也是最早的云的概念，亚马逊通过早期管理思想的积淀与电商业务的不断打磨，也一步步摸到了云的入口。
众多国内企业早期的发展的技术架构更多采用ESB架构完成——ESB（Enterprise Service Bus）讲究企业技术架构的联通，其基于SOA，应用场景是在对已有应用的打通，比如企业ERP+CRM软件以及定制开发的软件，这些软件价格不菲，需要长期使用，轻易无法改动。
所以要尽量保留，通过SOA进行架构串联，是一种企业集中式服务治理的架构；久而久之，企业形成了“烟囱式”的技术服务基础设施，“烟囱式”的技术服务设施尽管对单一业务的逻辑闭环与系统支撑形成了良好的支持。
但对于企业整体系统而言并不利于延展和内部业务相互协同，原因有如下几个：
（1）功能重复开发和维护成本带来的浪费：原有业务的系统支撑模块无法复用到新的业务系统架构中，只能重新开发极其类似的系统支撑模块；
（2）打通企业“烟囱”间交互花费企业更大成本：ESB架构的大部分/彻底推翻，新的企业架构的建立所需花费的时间；
（3）ESB模式下数据流典型系统特征：仅支持数据的单向流动和单场景使用，业务与系统单线联动，业务优化仅限于局部改善，无法做彻底性改动（如果彻底改动，可能对企业业务整体带来重大影响如业务停摆等）；
ESB架构下不同环节系统林立，使得业务链无法模块化拆分
四、互联网大厂的中台战略：平台企业中台化，垂直企业平台化
阿里是互联网大厂中台战略的坚定推行者之一。我们基于上述分析认为，阿里中台的前身是2009年成立的“共享业务事业部”和“数据平台部”。
具体到《企业IT架构转型之道》中，作者钟华的表述采用“共享服务中心”（shared service center），并且“从原有传统应用架构转变为今天共享服务体系的架构，本质上是微服务架构建设的过程”——中台架构大概率会选型微服务架构，微服务架构既是一种有形架构，也是一套管理复杂系统的服务治理思路。
阿里自2015年提出“大中台小前台”战略（提出此战略的目的是在共享服务基础上进一步之后，组织架构和业务机制两个层面进一步将关系梳理清晰，拆掉部门之间隔墙）经过3年多的改造，中台已经实现公共业务和技术组件横向打穿，为阿里前台业务提供高效运转和迭代的支撑。
阿里大中台示意：业务数据化+数据业务化，前台灵活+双中台支撑
五、品牌商的中台：早期萌芽、初露锋芒，但刚需大潮难以阻挡
品牌做中台的逻辑即为零售全渠道（Omni-channel）背景下的举措。消费零售行业渠道品牌的前台一直有个更通俗的说法，叫“全渠道系统”——在门店、APP、电商平台、微信小程序、to B分销的全渠道销售时，共享一套会员、商品、订单、库存、营销、支付体系（我们认为这也是近年来所谓新零售模式想要去实现的目的）——共享这一套体系的基础是什么？
是线上线下业务逻辑的解耦（拆分核心能力并标准化）和资源（流量/渠道）的不断货币化（在满足内部的终端渠道需求基础上开放给外部中小客户）过程，本质即为中台建设。
渠道能力解耦与抽象：多场景保持一种体验，全零售流程对应一种中台方案
六、中台的未来：效率为本，价值为先
中台的未来是什么？
结合上文的分析，我们看到了中台在不断被各行业的各类组织所接纳并采用，对中台的认知与理解在业内也逐步开始从单一技术视角深化到高层认识+组织文化+实施方法论+技术等多视角并行。
以史为鉴，我们仍然从重温贝佐斯2002年向亚马逊内部发布的指令开始：
- All teams will henceforth expose their data and functionality through service interfaces.
- Teams must communicate with each other through these interfaces.
- All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
- Anyone who doesn’t do this will be fired.
这四道指令如破墙的铁锤打破了亚马逊内部组织与数据体系的隔阂，并强迫企业养成了API化的企业内部技术架构，极大提升了企业的透明度。中台的建设就是在打破公司组织与组织之间、系统与系统之间、数据与数据之间的藩篱。中台建设也侧面促进组织透明化程度与合作协同的深度。
赋能、适度透明、强调/考评价值观的企业组织文化可能是中台建设的先决条件
在市场红利逐步放缓的前提下，中台将最终成为企业苦练内功过程中的抓手。
进入稳定期的企业往往到了拼精细运营的时候了：大家都寄希望于中台来帮企业最大化内部能力复用，从而实现降本增效，在技术上的表现就是企业架构在从单层的应用拼接到两层甚至多层的平台化架构（平衡经济性和灵活性）的过程。
但是，未必所有的企业拼精细运营都需要经历中台建设的步骤，中台也并不适用于公司的每个阶段，中台是为前端业务创新的不确定性服务的，企业前端场景鲜少发生变化或应用相对固定，可能就不需要中台。
因此适合自己的业务架构和组织架构，以及随之构建的技术架构，就是最适合的伴随企业成长的架构。进化组织尽管大势所趋，但并非所有企业都要在中台火热的时点（盲目）追风。
在此文结尾之时，我们仍然相信让企业产生平滑稳健运营和业绩效率的、具备敏捷/灵活的组织与架构，就是（当前时点）最适宜的组织与系统架构。
证明自身价值的历程往往是漫长且艰苦的，而价值得到证明的一刻，就是企业中台战略拨云见日之时。
这一切，当然都是命运石之门的选择。
作者：怪盗团郑达、高博文、焦杉，公众号：互联网与娱乐怪盗团（ID：TMTphantom）
来源：https://mp.weixin.qq.com/s/fj7PtwGAzXjxcl8cWuzRWQ
本文由 @互联网与娱乐怪盗团 授权发布于人人都是产品经理，未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议