中台启示录：为什么你无法复制中台？

　　在中台概念甚嚣尘上的时候，无论大中小型企业都在加速建设自家的中台系统。不过随着这股热潮冷静下来后，有的企业开始发现：做中台，没有那么简单！
　　《邯郸学步》：战国时期，有个燕国少年听说赵国邯郸人走路的姿势特别美，于是不顾路途遥远，到邯郸当地学人家走路。结果他不但没学会人家走路的姿势，还把自己原来走路的姿势也忘记了，最后只好爬着回去。
　　这个例子同样适用于某些盲目做中台的企业们。
　　接下来，我就简单跟大家聊聊我被问到的一些与中台有关的问题：
　　第一次被问到中台：
　　2017年，来自物流行业某科技公司：你对中台怎么看？
　　我说：阿里巴巴快速发展期间建了很多重复的业务系统，后来的系统整合吗？
　　对方正在负责中台建设业务，作为顾问，这个回答未免太实在。
　　第二次：
　　2018年协助一家保险行业的客户提升组织效能，逐步沉淀出清晰的前中后台协同流程。
　　客户认为，这些要做，但是不够大，还要更大、更高屋建瓴的方案；于是又提议了客户聚焦（CustomerFucus）的整体方案，重点优化线上营销端到端流程，面向高价值客户快速上市产品组。
　　结果最后客户提出，你能不能给我们培训一下中台。
　　最后一次：
　　2019年在某大会上遇到了某银行的顾问同仁，问我：中台团队如何评价绩效和价值？
　　我说：中台当然按消费者（Consumer）调用的SLA来评价呀。
　　对方说：比如一个模块，在做之前，如何通过价值评价来决策做或者不做？
　　我说这不是架构师的职责吗？中台没有架构师吗？那这个中台是怎么做出来的？
　　对方：现在就是没有人能评估这个事儿，所以做出来争议很大，中台团队也感觉不到自己的存在感
　　常言道B端决策缓慢又理性，为什么中台却如此迅速地席卷大江南北，从不断升温到碎片一地，中台究竟给我们什么样的启示？企业在面临新的技术概念时，如何更有条理地看待和采纳？
　　1。中台本质：企业架构治理
　　尽管如今已经步入了Microservices与CloudNative阶段了，但如果不是一家游戏类、照片类、音视频类纯数字化公司（据我观察，这类公司是最早采用云计算技术的），我推崇还是搞清楚早期Microsoft的一篇架构文档中说明的三种架构层次。
　　为什么？
　　就像早期熟悉云计算架构必须看Amazon的技术白皮书一样，作为企业服务领域的一哥，Microsoft的总结有极强的参考价值：
　　应用架构（ApplicationArchitecture），即系统技术架构，通常表现为带有数据库的三层多层技术架构体系。
　　产品项目架构（ProductProjectArchitecture），后期又称之为解决方案架构（SolutionArchitecture），解决方案层与应用层的区别在于，它是业务导向的，致力于提升应用系统的业务质量。
　　企业架构（EnterpriseArchitechture），它其实是一个规划过程，识别企业IT未来应该达到的状态，并实施一系列的计划，使项目团队通过交付达成。
　　1。1中台如何应对来自以用户为中心的业务挑战
　　以用户为中心（Customercentric）意味着向消费驱动的转变。企业产品与服务的推出不再内部可控，而是需要快速捕获外部用户的变化并响应用户的需求。
　　曾经有客户问：业务部门一年复一年人员都没有增长，提需求的就是这些人，为啥我们的技术部门人员年年增长还不能完成需求？
　　原因就在于：提需求的人是没有增长，但提需求的节奏、频率、变化都大大提升了。
　　中台大火，正是作为“包治百病”的神药诞生。而对中台一词最不感冒的是电信业的小伙伴，“这些玩意不是电信业务软件中早就实现过的？凭空造些概念出来。”
　　没错，中台的很多概念，您都可以从GabrielMorgan（前微软企业战略规划部、现星巴克企业架构部主管）在2007的这篇文章《ServiceDeliveryPlatform（SDP）fortheEnterprise》中找到答案，其借鉴的正是电信业SDP（ServiceDeliveryPlatform）快速交付业务服务的思路。文中Morgan提出：
　　WeallknowthatSOAisapowerfultooltoenableanagilebusinessbutWell，itturnsoutthatthetelecomindustryhaslargelysolvedthisandareworkingonthechallengesofwhatcomesnext。
　　SOAThroughcontinuousimprovementandchangeinthebusiness，wewillcontinuallymodifyourarchitecturetoadvanceourbusinessandbemorecompetitive。
　　Forexample，basedontheneedsoffasterdeliveryofservices，ServiceManagementwithfeatureslikeServiceNaming，RegistryandLocationServices，ServicePolicyManagement，ServiceQualityManagement，ServiceConfigurationManagement，andServiceRatingandDiscountingManagement。
　　Anotherexample，isthesophisticationsinhowanenterprisewillhandlesupportingsharedservices。EnterpriseArchitectureswillneedtosupportsharedservicesandwillrequiresophisticationsinDevandTestenvironments，Governanceprocessandteammodels，SDLCmodifications，CustomerSupportandServiceConsultationOnboarding。
　　Andfinally，therearelevelsofsophisticationhowtheenterprisearchitecturewilllookinSSscenariossuchasprocess，informationandsystemintegrationwithcloudservices。Or，resolvehowthearchitecturewillhandlepartnercollaborationandcustomercentricchallengesthebusinessstrivefor。
　　2007年时还没有Micoroservice架构，后来由Netflix在整合移动多屏及个性化时被实现。
　　所以，粗体字充分展示了Morgan在技术概念上的准确定义，一旦概念被定义出来，它就可以被理解或不理解的人传播了，因为无法通过“为每个服务定义一个唯一名称变量，然后在调用时通过从数据库查询这个唯一名称字段找到服务地址”这样的描述来向不懂的业务领导介绍服务命名。
　　1。2中台成功核心在于业务治理
　　同时Morgan在另一篇文章《Adoption，ratherthanArchitecture，isthehighorderbitforArchitects》中指出，企业架构最重要的是组织对齐。“对齐”是国内某家企业跨部门沟通最爱用的词，也充分体现了该企业强大的组织能力。
　　中台与ESB的核心差异是什么？
　　在于业务服务能力（Capability）的下沉。
　　ESB是消息总线，解决系统异构信息交换问题，而中台集成的是各种服务提供方，解决业务能力共享的问题。
　　中台服务面向的颗粒度更细，更强调的是封装完整的业务资源、逻辑和流程，每个服务有更强的自治性，而ESB的出现更单纯地是为了解决系统层面的协作。
　　比如说，早年企业针对销售部门有一个订单管理系统，后来针对售后部门又开发了一个服务管理系统，最后发现，售后需要回溯销售合同的条款，一开始通过批量同步，还行；后面量大了，批量处理已经延后了，就需要两个系统更及时地同步。
　　如果作为中台架构师，在业务资源识别时，最彻底的就是面向客户建立全生命周期的产品管理服务体系。
　　早期的共享信息数据（SID）模型就是这样的架构。
　　建设中台或任何企业级中心化的系统，需要权衡的就是如何协调不同使用部门之间的利益点。
　　比如说，某些部门不希望花费过多精力在系统建设上，那么组织提供的共享资源就很有用处；而某些部门希望能够快速响应经常变化、个性化的需求，那么组织级平台就可能拖累他们的节奏；而还有一些部门根本就不想与其它系统有依赖，那这样的共享服务对他们而言就没有存在的必要。
　　中台并不神秘，当企业想建设中台时，首先应当考虑的是，业务部门的需求究竟是什么，他们希望改进什么方面？他们及涉及的利益相关者愿意为这个改进作出多大业务上的对齐？谁能够承担企业架构师的角色？
　　很多架构师其实只是一个高级程序员，并不具备权衡（Tradeoffs）的能力和魄力。否则，这不应该成为中台项目，更好的处理模式是在解决方案或应用层面寻找优化措施。
　　早期的ConnectedServicesFramework，在许多国外大型机构中演进成为SharedServices架构。
　　2。为什么你无法复制中台？
　　阿里巴巴业务本身就是平台型、开放型，但仅仅因为业务形态，也不足说明非平台型公司不能建中台，毕竟建成后效率更高啊。但企业需要意识到，阿里巴巴成功建设中台，原因有两点：
　　是对现有资源的整合而不是新建
　　由内部团队驱动而不是外部公司承接
　　2。1可重用的资源：你有服务资产来建设中台吗？
　　中台普遍采用服务、API来集成提供业务能力，许多企业第一步就是欠缺的，没有这些服务和API；通常我们说的“服务化”，意思是把现有的组件封装为WebService，以提供更强的复用能力，比如说，一个Java的组件，只有Java的程序能调用，但封装为服务之后，PHPNode。jsiOSAndroid全都可以支持了，就极大地提升了后端程序的复用性。
　　但事实上去到企业一看，很多系统连组件边界都不清晰，这个服务化，其实在帮助企业进行应用架构（ApplicationArchitecture）层面的模块化梳理。许多企业连模块化都不想做，就要一步上中台，怎么办，请外部公司空降PPT画大饼、做培训、仓促上马半成品，结果可想而知。
　　2。2运行维护和保障：你有工程能力来建设中台吗？
　　比如最简单的一个问题，中台上一个服务有多个消费者，如何进行版本升级？内部组件如何做到灰度部署？如何回滚？
　　事实是，关于服务要不要有版本编号，版本编号到底是不是一个值得采纳的工程实践，业界都还在踩坑、争论。
　　运转中的中台，复杂度超过一般的系统运行维护，没有规范、没有自动化、没有云平台管理能力的企业，很难玩转中台。即使空降一个中台系统，落后的管理方式也只能将高铁按照大巴时刻发车。
　　3。如何稳步走向服务化战略
　　茅台这张PPT问题在哪里？
　　在于没有给出路径。
　　与“中台”这个名词相比，我还是更喜欢使用面向服务的战略来表述以用户为中心的未来IT架构转变。
　　3。1用户驱动：显性化你的中台业务价值
　　更个性化、更快地响应最终用户的请求，尤其是外部用户的请求，应该是中台构建的业务价值目标。如果中台仅仅是优化内部业务，由于业务价值不明确，或难于衡量，将可能导致不及预期、难于协调一致多个部门，所以由外部用户感知的业务价值驱动，更能有效地落地业务资源与流程的整合。
　　比如说，利用用户旅程分析工具，将过去用户需要面对多个业务人员的流程优化为一项自助式服务，并支持在移动端、PC端和终端多处完成。定义用户服务请求的监控指标改进，包括业务处理时间、业务流量、交易量，等，即决定了此项优化的业务价值。
　　3。2团队自治：构建你的高效面向业务服务的基层文化
　　如果你的团队并不能真正理解服务化中台的好处，如此庞大的工程不可能真正落地。因为中心化的系统建设涉及的范围太广了，一条规范不能被正确执行，都会留下后期调用的隐患。
　　让过去涉及到多个业务协作的系统团队进行合作，设计出新的解决方案，让他们直接面向业务部门收集的反馈，或用户使用的行为指标、报告作出响应。
　　如果发现在这个团队中，他们依然还需要依赖第三方的人、系统来解决问题，那么自治式还不够好，需要进一步解除依赖。虽然这在许多金融机构听起来不太可能，但如果这些问题都解决不了，谁又能真正承诺最终交付的中台服务能够高效响应呢？
　　3。3服务管理：一步步加强你的中心团队治理能力
　　随着服务越来越多，需要有专门的服务管理团队，接手服务基础设施、目录，并完善高可用、监控和运营治理。
　　可以为服务管理团队设立服务规划部门，一步一步为企业的服务化中台战略进行未来状态的导引。
　　总结
　　中台不是一个新事物，也并不神秘。重视中台，说明中国的企业开始意识到IT的重要性，以及企业架构带来的巨大能效优势。不应因“茅台中台事件”因噎废食，前车之鉴，供我们制定更加合理的转型提速节奏。