广义中台和狭义中台发展趋势解读.docx

广义中台和狭义中台发展趋势解读 【导读】为什么中台的落地出现了龙生九子九子各不同的状况？希望本文能帮助读者厘清相关的内容，从而对中台落地有更好的理解。中台的本质是一种架构方式，其目的是为了共享和重用。但自从中台的概念提出来之后，各种理解都有，直到现在依然有很多人不知道该如何落地。一方面由于其概念比较大，提出者也没有讲清楚其本质和路径，只是提了概念和理念，每家企业每个人都是按照自己的理解去做中台，所以也就有了龙生九子九子各不同的状况；另一方面，中台被提升到了企业架构的层次，不仅限于技术层面，所以像组织中台、共享平台等中台架构概念中难以清晰定位和落地实施的内容，从而导致概念就混淆不清，落地更是千差万别。最初从技术落地层面，笔者将可落地的中台定义为服务（微服务）中台，以微服务粒度来实现共享和复用，也尝试解释了中台和平台的区别，并强调平台是从技术层面来定义，中台是从架构层面来定义，这是两个完全不同的概念。但技术之外的中台概念没有包括，所以也使 “ 服务中台 ” 的思路不够完善。服务中台可以被称之为技术层面的、可落地的、狭义的中台。而广义的中台架构则是指企业内企业级的可共享和复用的能力，包括组织、工具平台等。广义的中台往往从业务角度，可包含一切可复用的能力、资源、组织人员等，但这部分往往比较虚，往往难以有效落地，难以用技术手段或流程来实现或评估。比如说，营业部是前台、产品合规风险 IT 是中台、人力财务行政是后台。这其实和中台架构的本意（技术角度）已经偏离了。中台要落地，就需要考虑落地的粒度，是工具平台级的共享复用？还是更细粒度可复用的服务级的共享复用？甚至服务的粒度是 ESB 服务还是微服务或者其他粒度的服务？等等。厘清了这些内容，才能更好的划分前、中、后台的内容，才能正确区分应用的前中后、架构的前中后台、中台架构的内容、以及中台中的平台或后台中的平台（大厂提出的中台没有后台的概念， PaaS 及以下都是中台）等。所以很多人把数据库、数仓、大数据平台等都放在中台，从而带来很多混沌不明的问题。如果考虑一个应用系统的前、中、后台或分层架构，可能会容易理解应用系统的复用。所以中台从架构角度来说，并不是一个新概念，只是将它从应用系统的层面提高到了企业架构的层面，把一个系统的前中后台扩展为一个企业或一个生态的前中后台，复用的粒度和角度发生了变化，区别是从一个应用系统的复用（单体系统）和一家企业内所有应用系统级别的复用（融合架构复杂系统）。其实和 ESB 企业服务总线的思想有些类似，变简单系统为复杂系统，只不过不是通过简单集成而是重构+集成的方式来实现。复用的粒度不同，所带来的效率也不一样，代码层面的复用、函数或方法级别的复用、类包和服务级别的复用以及工具组件和平台级别的复用等所带来的研发和运维的效率和成本是不一样的，响应的能力是不一样。云计算和云原生（容器、微服务、 DevOps ）等技术为中台架构的落地提供了助力，使微服务粒度的服务复用共享和敏捷响应成为可能。所以，这些可复用的微服务构成了服务中台。这些微服务来自于经过抽象、提取、沉淀的数据服务、技术服务、业务服务等。数据服务来自于数据库、数仓、大数据平台或其他数据工具或平台；技术服务来自于和数据、业务无关的纯技术平台和工具，比如 kafka 消息服务、认证服务、权限服务、日志服务、 AI 服务、告警服务、短信服务、加解密等安全服务等等；业务服务则是业务流程中业务交叉功能点的沉淀。很多人也提了很多其他中台的概念，比如 AI 中台、财务中台等，但其都不外乎数据中台、技术中台和业务中台的范围。将复用和共享提升到企业层级（单体系统到企业所有系统），其复杂度可能提升了很多个数量级。因此中台架构是一个需要顶层规划的复杂系统工程。不是建一个或几个平台工具就可以的，它是一个持续的工作，随业务变化而调整，所以这几年上中台项目的几乎没有成功的也很正常。不成功大家也就不怎么谈它了，反正不缺新概念。不过靠概念变现始终是无本之木、无源之水，难以久长，我们可能更需要沉下心以价值变现，去做实实在在有价值有意义的事情。企业级中台架构其实落地也简单，至少技术中台是相对很容易实现的，然后是基于企业主数据来构建可复用的数据中台服务，搭建数据中台；当然，重构数据架构并不是一件容易的事，但关键是要认识到这一点，把企业内所有系统融合为一个系统来看，中台所要实现的就是系统中间层次的服务。中台架构在落地部署时，往往采用分布式微服务架构，而不是集中式。有人觉得：中台意味着集中，集中意味着运维量的大大增大，如果不是一定体量和信息化运维水平，做中台等于给自己挖坑。这样的理解是不对的。中台跟集中没有必然关系。中台是为了复用。逻辑上中台把可复用的能力提取出来，但并不是为集中，不是把所有可复用能力集中起来管理。可复用的服务可以在不同的团队不同的部门，而且实际部署时是分布式的，只是逻辑上把这些可复用的能力划分在了中台层。复用越多，效率越高，响应才能越快。微服务分布式会带来运维量的增加，但往往可以通过云原生自动化的运维来提升效率，可能人工运维工作量和运维人员需求大大降低。因此中台并不要求集中。无论企业大小，只要复用都是有需要的，中台架构都是可以采用的。将中台架构划分为广义中台和狭义中台，能够更好地理解和落地。其实笔者以前也说过，中台的目的就是为了复用和共享，不管理不理解中台的概念和本质，去做复用和共享就行了。做的多了，也就可以量变到质变，从而可以真正实现中台架构。-全文完-