在中台概念甚嚣尘上的时候，无论大中小型企业都在加速建设自家的中台系统。不过随着这股热潮冷静下来后，有的企业开始发现：做中台，没有那么简单！
《邯郸学步》：战国时期，有个燕国少年听说赵国邯郸人走路的姿势特别美，于是不顾路途遥远，到邯郸当地学人家走路。结果他不但没学会人家走路的姿势，还把自己原来走路的姿势也忘记了，最后只好爬着回去。
这个例子同样适用于某些盲目做中台的企业们。
接下来，我就简单跟大家聊聊我被问到的一些与中台有关的问题：
第一次被问到中台：
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未来应该达到的状态，并实施一系列的计划，使项目团队通过交付达成。
以用户为中心（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在技术概念上的准确定义，一旦概念被定义出来，它就可以被理解或不理解的人传播了，因为无法通过“为每个服务定义一个唯一名称变量，然后在调用时通过从数据库查询这个唯一名称字段找到服务地址”这样的描述来向不懂的业务领导介绍服务命名。
同时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架构转变。
更个性化、更快地响应最终用户的请求，尤其是外部用户的请求，应该是中台构建的业务价值目标。如果中台仅仅是优化内部业务，由于业务价值不明确，或难于衡量，将可能导致不及预期、难于协调一致多个部门，所以由外部用户感知的业务价值驱动，更能有效地落地业务资源与流程的整合。
比如说，利用用户旅程分析工具，将过去用户需要面对多个业务人员的流程优化为一项自助式服务，并支持在移动端、PC端和终端多处完成。定义用户服务请求的监控指标改进，包括业务处理时间、业务流量、交易量，等，即决定了此项优化的业务价值。
3.2 团队自治：构建你的高效面向业务服务的基层文化
如果你的团队并不能真正理解服务化/中台的好处，如此庞大的工程不可能真正落地。因为中心化的系统建设涉及的范围太广了，一条规范不能被正确执行，都会留下后期调用的隐患。
让过去涉及到多个业务协作的系统团队进行合作，设计出新的解决方案，让他们直接面向业务部门收集的反馈，或用户使用的行为指标、报告作出响应。
如果发现在这个团队中，他们依然还需要依赖第三方的人、系统来解决问题，那么自治式还不够好，需要进一步解除依赖。虽然这在许多金融机构听起来不太可能，但如果这些问题都解决不了，谁又能真正承诺最终交付的中台服务能够高效响应呢？
3.3 服务管理：一步步加强你的中心团队治理能力
随着服务越来越多，需要有专门的服务管理团队，接手服务基础设施、目录，并完善高可用、监控和运营治理。
可以为服务管理团队设立服务规划部门，一步一步为企业的服务化/中台战略进行未来状态的导引。
总结
中台不是一个新事物，也并不神秘。重视中台，说明中国的企业开始意识到IT的重要性，以及企业架构带来的巨大能效优势。不应因“茅台中台事件”因噎废食，前车之鉴，供我们制定更加合理的转型提速节奏。
