中台按消费者（Consumer）调用的SLA来评价。比如一个模块，在做之前，如何通过价值评价来决策做或者不做？

　　1、中台本质：企业架构治理

　　尽管如今已经步入了Microservices与Cloud Native阶段了，但如果不是一家游戏类、照片类、音视频类纯数字化公司（据我观察，这类公司是早采用云计算技术的），我推崇还是搞清楚早期Microsoft的一篇架构文档中说明的三种架构层次。为什么？就像早期熟悉云计算架构必须看Amazon的技术白皮书一样，作为企业服务领域的一哥，Microsoft的总结有极强的参考价值：

　　应用架构（Application Architecture），即系统技术架构，通常表现为带有数据库的三层/多层技术架构体系。

　　产品/项目架构（Product/Project Architecture），后期又称之为解决方案架构（Solution Architecture），解决方案层与应用层的区别在于，它是业务导向的，致力于提升应用系统的业务质量。

　　企业架构（Enterprise Architechture），它其实是一个规划过程，识别企业IT未来应该达到的状态，并实施一系列的计划，使项目团队通过交付达成。

　　中台如何应对来自以用户为中心的业务挑战

　　以用户为中心（Customer-centric）意味着向消费驱动的转变。企业产品与服务的推出不再内部可控，而是需要快速捕获外部用户的变化并响应用户的需求。曾经有客户问：业务部门一年复一年人员都没有增长，提需求的就是这些人，为啥我们的技术部门人员年年增长还不能完成需求？原因就在于：提需求的人是没有增长，但提需求的节奏、频率、变化都大大提升了。

　　2007年时还没有Micoroservice架构，后来由Netflix在整合移动多屏及个性化时被实现。

　　中台成功核心在于业务治理

　　Morgan在一篇文章《Adoption, rather than Architechure, is the high order bit for Architects》中指出，企业架构重要的是组织对齐。“对齐”是国内某家企业跨部门沟通爱用的词，也充分体现了该企业强大的组织能力。

　　中台与ESB的核心差异是什么？在于业务服务能力（Capability）的下沉。ESB是消息总线，解决系统异构信息交换问题，而中台集成的是各种服务提供方，解决业务能力共享的问题。中台服务面向的颗粒度更细，更强调的是封装完整的业务资源、逻辑和流程，每个服务有更强的自治性，而ESB的出现更单纯地是为了解决系统层面的协作。比如说，早年企业针对销售部门有一个订单管理系统，后来针对售后部门又开发了一个服务管理系统，后发现，售后需要回溯销售合同的条款，一开始通过批量同步，还行；后面量大了，批量处理已经延后了，就需要两个系统更及时地同步。如果作为中台架构师，在业务资源识别时，彻底的就是面向客户建立全生命周期的产品管理服务体系。早期的共享信息数据（SID）模型就是这样的架构。

　　建设中台或任何企业级中心化的系统，需要权衡的就是如何协调不同使用部门之间的利益点。比如说，某些部门不希望花费过多精力在系统建设上，那么组织提供的共享资源就很有用处；而某些部门希望能够快速响应经常变化、个性化的需求，那么组织级平台就可能拖累他们的节奏；而还有一些部门根本就不想与其它系统有依赖，那这样的共享服务对他们而言就没有存在的必要。

　　中台并不神秘，当企业想建设中台时，先应当考虑的是，业务部门的需求究竟是什么，他们希望改进什么方面？他们及涉及的利益相关者愿意为这个改进作出多大业务上的对齐？谁能够承担企业架构师的角色？很多架构师其实只是一个高级程序员，并不具备权衡（Tradeoffs）的能力和魄力。否则，这不应该成为中台项目，更好的处理模式是在解决方案或应用层面寻找优化措施。

　　早期的Connected Services Framework，在许多国外大型机构中演进成为Shared Services架构。

　　2、为什么你无法复制中台？

　　阿里巴巴业务本身就是平台型、开放型，但仅仅因为业务形态，也不足说明非平台型公司不能建中台，毕竟建成后效率更高啊。但企业需要意识到，阿里巴巴成功建设中台，原因有两点：，是对现有资源的整合而不是新建；第二，由内部团队驱动而不是外部公司承接。

　　可重用的资源

　　中台普遍采用服务、API来集成提供业务能力，许多企业步就是欠缺的，没有这些服务和API；通常我们说的“服务化”，意思是把现有的组件封装为Web Service，以提供更强的复用能力，比如说，一个Java的组件，只有Java的程序能调用，但封装为服务之后，PHP/Node.js/iOS/Android全都可以支持了，就极大地提升了后端程序的复用性。

　　但事实上去到企业一看，很多系统连组件边界都不清晰，这个服务化，其实在帮助企业进行应用架构（Application Architecture）层面的模块化梳理。许多企业连模块化都不想做，就要一步上中台，怎么办，请外部公司空降PPT画大饼、做培训、仓促上马半成品，结果可想而知。

　　运行维护和保障：你有工程能力来建设中台吗？

　　比如简单的一个问题，中台上一个服务有多个消费者，如何进行版本升级？内部组件如何做到灰度部署？如何回滚？事实是，关于服务要不要有版本编号，版本编号到底是不是一个值得采纳的工程实践，业界都还在踩坑、争论。运转中的中台，复杂度超过一般的系统运行维护，没有规范、没有自动化、没有云平台管理能力的企业，很难玩转中台。即使空降一个中台系统，落后的管理方式也只能将高铁按照大巴时刻发车。

　　3、如何稳步走向服务化战略

　　茅台这张PPT问题在哪里？在于没有给出路径。

　　与“中台”这个名词相比，我们还是更喜欢使用面向服务的战略来表述以用户为中心的未来IT架构转变。

　　用户驱动显性化中台业务价值

　　更个性化、更快地响应终用户的请求，尤其是外部用户的请求，应该是中台构建的业务价值目标。如果中台仅仅是优化内部业务，由于业务价值不明确，或难于衡量，将可能导致不及预期、难于协调一致多个部门，所以由外部用户感知的业务价值驱动，更能有效地落地业务资源与流程的整合。

　　比如说，利用用户旅程分析工具，将过去用户需要面对多个业务人员的流程优化为一项自助式服务，并支持在移动端、PC端和终端多处完成。定义用户服务请求的监控指标改进，包括业务处理时间、业务流量、交易量，等，即决定了此项优化的业务价值。

　　团队自治构建高效面向业务服务的基层文化

　　如果你的团队并不能真正理解服务化/中台的好处，如此庞大的工程不可能真正落地。因为中心化的系统建设涉及的范围太广了，一条规范不能被正确执行，都会留下后期调用的隐患。

　　让过去涉及到多个业务协作的系统团队进行合作，设计出新的解决方案，让他们直接面向业务部门收集的反馈，或用户使用的行为指标、报告作出响应。

　　如果发现在这个团队中，他们依然还需要依赖第三方的人、系统来解决问题，那么自治式还不够好，需要进一步解除依赖。虽然这在许多金融机构听起来不太可能，但如果这些问题都解决不了，谁又能真正承诺终交付的中台服务能够高效响应呢？

　　服务管理一步步加强中心团队治理能力

　　随着服务越来越多，需要有专门的服务管理团队，接手服务基础设施、目录，并完善监控和运营治理。可以为服务管理团队设立服务规划部门，一步一步为企业的服务化/中台战略进行未来状态的导引。

　　总结

　　中台不是一个新事物，也并不神秘。重视中台，说明中国的企业开始意识到企业架构带来的巨大能效优势，供我们制定更加合理的转型提速节奏。