《邯郸学步》：战国期间，有个燕国少年听说赵国邯郸人走路的姿势特殊美，于是不顾路途迢遥，到邯郸当地学人家走路。结果他不但没学会人家走路的姿势，还把自己原来走路的姿势也忘却了，末了只好爬着回去。
这个例子同样适用于某些盲目做中台的企业们。
接下来，我就大略跟大家聊聊我被问到的一些与中台有关的问题：
第一次被问到中台：
2017年，来自物盛行业某科技公司：你对中台怎么看？
我说：阿里巴巴快速发展期间建了很多重复的业务系统，后来的系统整合吗？
对方正在卖力中台培植业务，作为顾问，这个回答难免不免太实在。
第二次：
2018年帮忙一家保险行业的客户提升组织效能，逐步沉淀出清晰的前中后台协同流程。
客户认为，这些要做，但是不足大，还要更大、更居高临下的方案；于是又发起了客户聚焦（Customer Fucus）的整体方案，重点优化线上营销端到端流程，面向高代价客户快速上市产品组。
结果末了客户提出，你能不能给我们培训一下中台。
末了一次：
2019年在某大会上碰着了某银行的顾问同仁，问我：中台团队如何评价绩效和代价？
我说：中台当然按消费者（Consumer）调用的SLA来评价呀。
对方说：比如一个模块，在做之前，如何通过代价评价来决策做或者不做？
我说这不是架构师的职责吗？中台没有架构师吗？那这个中台是怎么做出来的？
对方：现在便是没有人能评估这个事儿，以是做出来争议很大，中台团队也觉得不到自己的存在感……
常言道B端决策缓慢又理性，为什么中台却如此迅速地席卷大江南北，从不断升温到碎片一地，中台究竟给我们什么样的启迪？企业在面临新的技能观点时，如何更有条理地看待和采纳？
1. 中台实质：企业架构管理
只管如今已经步入了Microservices与Cloud Native阶段了，但如果不是一家游戏类、照片类、音视频类纯数字化公司（据我不雅观察，这类公司是最早采取云打算技能的），我推崇还是搞清楚早期Microsoft的一篇架构文档中解释的三种架构层次。
为什么？
就像早期熟习云打算架构必须看Amazon的技能白皮书一样，作为企业做事领域的一哥，Microsoft的总结有极强的参考代价：
运用架构（Application Architecture），即系统技能架构，常日表现为带有数据库的三层/多层技能架构体系。产品/项目架构（Product/Project Architecture），后期又称之为办理方案架构（Solution Architecture），办理方案层与运用层的差异在于，它是业务导向的，致力于提升运用系统的业务质量。企业架构（Enterprise Architechture），它实在是一个方案过程，识别企业IT未来该当达到的状态，并履行一系列的操持，使项目团队通过交付达成。1.1 中台如何应对来自以用户为中央的业务寻衅以用户为中央（Customer-centric）意味着向消费驱动的转变。企业产品与做事的推出不再内部可控，而是须要快速捕获外部用户的变革并响运用户的需求。
曾经有客户问：业务部门一年复一年职员都没有增长，提需求的便是这些人，为啥我们的技能部门职员年年增长还不能完成需求？
缘故原由就在于：提需求的人是没有增长，但提需求的节奏、频率、变革都大大提升了。
中台大火，正是作为“包治百病”的神药出身。而对中台一词最不感冒的是电信业的小伙伴，“这些玩意不是电信业务软件中早就实现过的？凭空造些观点出来。”
没错，中台的很多观点，您都可以从Gabriel Morgan（前微软企业计策方案部、现星巴克企业架构部主管）在2007的这篇文章《Service Delivery Platform (SDP) for the Enterprise》中找到答案，其借鉴的正是电信业SDP（Service Delivery Platform）快速交付业务做事的思路。文中Morgan提出：
We all know that SOA is a powerful tool to enable an agile business but … Well, it turns out that the telecom industry has largely solved this and are working on the challenges of what comes next.
…SOA…Through continuous improvement and change in the business, we will continually modify our architecture to advance our business and be more competitive.
For example, based on the needs of faster delivery of services, there are higher levels of sophistication in how to do Service Management with features like Service Naming, Registry and Location Services, Service Policy Management, Service Quality Management, Service Configuration Management, and Service Rating and Discounting Management.
Another example, is the sophistications in how an enterprise will handle supporting shared services. Enterprise Architectures will need to support shared services and will require sophistications in Dev and Test environments, Governance process and team models, SDLC modifications, Customer Support and Service Consultation/On-boarding.
And finally, there are levels of sophistication how the enterprise architecture will look in S+S scenarios such as process, information and system integration with cloud services. Or, resolve how the architecture will handle partner collaboration and customer-centric challenges the business strive for.
2007年时还没有Micoroservice架构，后来由Netflix在整合移动多屏及个性化时被实现。
以是，粗体字充分展示了Morgan在技能观点上的准确定义，一旦观点被定义出来，它就可以被理解或不理解的人传播了，由于无法通过“为每个做事定义一个唯一名称变量，然后在调用时通过从数据库查询这个唯一名称字段找到做事地址”这样的描述来向不懂的业务领导先容做事命名。
1.2 中台成功核心在于业务管理
同时Morgan在另一篇文章《Adoption, rather than Architecture, is the high order bit for Architects》中指出，企业架构最主要的是组织对齐。“对齐”是海内某家企业跨部门沟通最爱用的词，也充分表示了该企业强大的组织能力。
中台与ESB的核心差异是什么？
在于业务做事能力（Capability）的下沉。
ESB是总线，办理系统异构信息交流问题，而中台集成的是各种做事供应方，办理业务能力共享的问题。
中台做事面向的颗粒度更细，更强调的是封装完全的业务资源、逻辑和流程，每个做事有更强的自治性，而ESB的涌现更纯挚地是为理解决系统层面的协作。
比如说，从前企业针对发卖部门有一个订单管理系统，后来针对售后部门又开拓了一个做事管理系统，末了创造，售后须要回溯发卖条约的条款，一开始通过批量同步，还行；后面量大了，批量处理已经延后了，就须要两个别系更及时地同步。
如果作为中台架构师，在业务资源识别时，最彻底的便是面向客户建立全生命周期的产品管理做事体系。
早期的共享信息数据（SID）模型便是这样的架构。
培植中台或任何企业级中央化的系统，须要权衡的便是如何折衷不同利用部门之间的利益点。
比如说，某些部门不肯望花费过多精力在系统培植上，那么组织供应的共享资源就很有用处；而某些部门希望能够快速相应常常变革、个性化的需求，那么组织级平台就可能拖累他们的节奏；而还有一些部门根本就不想与其它系统有依赖，那这样的共享做事对他们而言就没有存在的必要。
中台并不神秘，当企业想培植中台时，首先应该考虑的是，业务部门的需求究竟是什么，他们希望改进什么方面？他们及涉及的利益干系者乐意为这个改进作出多大业务上的对齐？谁能够承担企业架构师的角色？
很多架构师实在只是一个高等程序员，并不具备权衡（Tradeoffs）的能力和蔼魄。否则，这不应该成为中台项目，更好的处理模式是在办理方案或运用层面探求优化方法。
早期的Connected Services Framework，在许多国外大型机构中演进成为Shared Services架构。
2. 为什么你无法复制中台？
阿里巴巴业务本身便是平台型、开放型，但仅仅由于业务形态，也不敷解释非平台型公司不能建中台，毕竟建成后效率更高啊。但企业须要意识到，阿里巴巴成功培植中台，缘故原由有两点：
是对现有资源的整合而不是新建由内部团队驱动而不是外部公司承接2.1 可重用的资源：你有做事资产来培植中台吗？中台普遍采取做事、API来集成供应业务能力，许多企业第一步便是欠缺的，没有这些做事和API；常日我们说的“做事化”，意思是把现有的组件封装为Web Service，以供应更强的复用能力，比如说，一个Java的组件，只有Java的程序能调用，但封装为做事之后，PHP/Node.js/iOS/Android全都可以支持了，就极大地提升了后端程序的复用性。
但事实上去到企业一看，很多系统连组件边界都不清晰，这个做事化，其实在帮助企业进行运用架构（Application Architecture）层面的模块化梳理。许多企业连模块化都不想做，就要一步上中台，怎么办，请外部公司空降PPT画大饼、做培训、仓促上马半成品，结果可想而知。
2.2 运行掩护和保障：你有工程能力来培植中台吗？
比如最大略的一个问题，中台上一个做事有多个消费者，如何进行版本升级？内部组件如何做到灰度支配？如何回滚？
事实是，关于做事要不要有版本编号，版本编号到底是不是一个值得采纳的工程实践，业界都还在踩坑、辩论。
运转中的中台，繁芜度超过一样平常的系统运行掩护，没有规范、没有自动化、没有云平台管理能力的企业，很难玩转中台。纵然空降一个中台系统，掉队的管理办法也只能将高铁按照大巴时候发车。
3. 如何稳步走向做事化计策
茅台这张PPT问题在哪里？
在于没有给出路径。
与“中台”这个名词比较，我还是更喜好利用面向做事的计策来表述以用户为中央的未来IT架构转变。
3.1 用户驱动：显性化你的中台业务代价
更个性化、更快地相应终极用户的要求，尤其是外部用户的要求，该当是中台构建的业务代价目标。如果中台仅仅是优化内部业务，由于业务代价不明确，或难于衡量，将可能导致不及预期、难于折衷同等多个部门，以是由外部用户感知的业务代价驱动，更能有效地落地业务资源与流程的整合。
比如说，利用用户旅程剖析工具，将过去用户须要面对多个业务职员的流程优化为一项自助式做事，并支持在移动端、PC端和终端多处完成。定义用户做事要求的监控指标改进，包括业务处理韶光、业务流量、交易量，等，即决定了此项优化的业务代价。
3.2 团队自治：构建你的高效面向业务做事的基层文化
如果你的团队并不能真正理解做事化/中台的好处，如此弘大的工程不可能真正落地。由于中央化的系统培植涉及的范围太广了，一条规范不能被精确实行，都会留下后期调用的隐患。
让过去涉及到多个业务协作的系统团队进行互助，设计出新的办理方案，让他们直接面向业务部门网络的反馈，或用户利用的行为指标、报告作出相应。
如果创造在这个团队中，他们依然还须要依赖第三方的人、系统来办理问题，那么自治式还不足好，须要进一步解除依赖。虽然这在许多金融机构听起来不太可能，但如果这些问题都办理不了，谁又能真正承诺终极交付的中台做事能够高效相应呢？
3.3 做事管理：一步步加强你的中央团队管理能力
随着做事越来越多，须要有专门的做事管理团队，接手做事根本举动步伐、目录，并完善高可用、监控和运营管理。
可以为做事管理团队设立做事方案部门，一步一步为企业的做事化/中台计策进行未来状态的导引。
总结
中台不是一个新事物，也并不神秘。重视中台，解释中国的企业开始意识到IT的主要性，以及企业架构带来的巨大能效上风。不应因“茅台中台事宜”因噎废食，前车之鉴，供我们制订更加合理的转型提速节奏。
本文由 @陈加兴 原创发布于大家都是产品经理。未经容许，禁止转载
题图来自Unsplash，基于CC0协议
