参加了今年的云栖大会。作为中泰的从业者，我也比较关注中泰架构实施的行业现状，学习其他公司中泰的思路和经验。图片来自Pexels云栖大会。和做中台实践的同学，还有在阿里做中台的小伙伴们进行了深入的交流和探讨。总结。在讨论中台让人纠结和困扰的是什么之前，我们还是要先说说我们为什么要做中台（注：本文中的中台仅限于企业IT架构的中台，不是企业IT架构的中台）广义的中台），做中台会给我带来什么好处？想不通再去深究中台的细节是没有意义的。中台的概念近年来非常流行。就像90年代，不做ERP就是等死。现在，做不做中台似乎决定了一个企业的生死存亡，以至于大家都在搞中台。但是，并不是所有的公司都适合做中台。只有满足以下条件的公司才有必要实施中台。不要乱来。企业适合中台条件。因此，如果你是创业团队或者业务线单一，建议不要盲目尝试中台架构，否则会拖慢你的业务发展速度。此外，我们还必须清楚地了解实施中泰的目的以及中泰将给企业带来的价值。没有实际利益，中台就很难推广，或者有形无形。中台的价值明确了中台的应用场景和价值体现，我们开始着手实施中台架构。从今年上半年开始宣传中国和台湾，到现在已经快几个月了，过程中也是摸着石头过河。虽然中台有很多理论知识可以学习，但是在实际过程中发现中台的实施难度很大。它没有标准，认识也不统一，在一些关键环节存在很多差异。恰好这次在云栖大会上，和几位在中国大陆和台湾修行的朋友进行了深入的讨论，总结了讨论的内容。希望中台建设少一些纠缠，多一些自信。中台的定义：理念VS工具什么是中台？可能每个人的理解不一样，业界也没有严格的定义，但是我很认同其中一种说法：中台是一个企业级能力复用的平台。这句话怎么解释？由于中台定义的核心是能力的复用，商学院认为中台其实是一套思想。措施和所有可重用的能力都属于中台的范畴，所以中台是一种组织方法。技校的人认为，既然是能力复用的平台，就必须有支持复用的工具，必须定义一套技术规范来支持复用。中台要有基础平台支撑。中台首先要统一思想，围绕能力的复用进行组织管理，将能力组件化，如下图底部。同时，在中台上，我们需要搭建一个可以快速实现的技术平台（图中OECP部分），通过低代码平台能力，实现组件的组装和流程设计，并快速构建应用程序。技术平台与业务无关，但业务平台必须与业务相关。只要把业务和技术有机结合起来，把企业的能力积累起来，再利用起来，这就有了平台的基础。中台以上集成开发能力复用粒度：粗粒度VS细粒度复用是中台建设的核心，是一切的基础。没有复用意识，中台就变成了自娱自乐的游戏。可能很多人会说，在没有中间平台之前，复用无处不在。我们编写程序重用代码并做解决方案重用案例。为什么要搭建中台？首先重申，中台的复用范围是“企业级”，既不局限于技术同学内部的程序复用，也不局限于团队内部的复用，而是站在企业的最高视角作用于整个企业的IT架构；其次是“能力复用”，能力的范围更广。跟阿里巴巴的朋友讲复用的时候，我们也提到了复用的层次。比如阿里云，其实是基础设施层面的复用。我自己将复用的层次抽象为如下图5层：复用层次越低，粒度越小，复用范围越广，但价值越低；层级越高，粒度越大，复用价值越高，但复用范围越有限。因此，从业务和价值的角度，首先要从最高层进行复用。只有当上层无法实现复用时，我们才会逐步寻找下层。但是有时候从技术角度来说，我们习惯于在低层复用，因为这是最贴近我们自己的工作，粒度越小，技术越可控。但不管怎样，只要能把这些能力组织好、管理好，实现复用，就是中泰的思路。具体到中台的IT架构，微服务基础架构是目前最流行的方式，因为纯程序代码的复用价值有限，传统单体应用的复用极其不灵活，而基于微服务架构的复用业务组件数量处于中等水平，灵活性和复用性比较平衡。组件复用的核心思想是领域驱动设计（DDD），而我认为DDD最大的难点在于粒度的控制。粒度太粗则不够灵活，复用性差。维护成本高。Gartner的服务粒度划分Gartner在研究报告中提出了宏服务、小服务和微服务的粒度划分：宏服务：一种传统的Web服务，支持在单个应用程序中封装功能。宏服务不支持独立部署或扩展，它们只能作为整体应用程序的一部分进行部署，并且不需要微服务基础设施。小服务：从服务粒度上来说，小服务是一个粗粒度的、松耦合的、支持独立部署的应用组件。小型服务需要微服务基础设施。微服务：在粒度范围的远端，微服务是可独立部署的组件，支持实现单个应用程序功能。微服务可以直接部署到微服务运行时环境中，并且通常有专用的数据存储。微服务需要微服务基础设施。我个人非常喜欢Gartner的除法。基于这三个服务的粒度，我也会说说我对粒度的一些思考。如果我们想复用现有系统的能力，可以使用宏服务模型，适合系统集成和治理。对于新的业务和项目，我们最初建议以小服务的形式拆分业务域。不建议分割得太细。这个小服务可以满足需求的基本抽象。从适度的粒度开始，服务的粒度必须在业务推进的过程中不断演进。创新业务促进服务粒度向细粒度方向裂变，业务成熟稳定后，促进服务向粗粒度方向聚合。流程支撑：ServiceOrchestrationVSSOP实践证明，业务能??力的输出主要是核心业务数据和业务流程。在我上面定义的复用级别上，业务流程的复用是在LV4，也是比较高级别的复用能力。在云栖大会的朋友聚会上，我一个在中台实践过的同学谈到了中台服务如何更灵活的支持前台，并谈到了服务安排。他们的做法是给前端同事提供一套服务编排工具，然后发布一系列原子服务，每个前端团队根据自己的流程安排适合自己的逻辑流程。我并不反对服务编排，在SOA和微服务的架构下，服务编排是必不可少的能力。但是我不同意前台提供编排工具，而中台只提供原子服务。因为在中台建设中，我们一直提到中台一定要和业务相关。中台的输出不仅仅是工具，还需要深入具体的业务场景，提供优秀的业务流程实践。阿里的朋友在讨论这个问题的时候提到了SOP（StandardOperationProcedure）的概念。他认为最好的方式是提供一套标准化的流程+预留可以动态注入前台的扩展点。比如淘宝和天猫在业务上可以共享一套SOP，在这套SOP的扩展点中注入自己不同的规则来满足自己的需求。从中台复用的范围来看，我特别认同这种方式，因为中台只提供SOP，才是真正实现业务流程的高层复用（就像国外ERP提倡的，你买的不只是一个系统，还有企业管理要好的做法）。当然，如果要实现SOP的定义，中台团队必须要有业务和技术都精通的人。我们俗称“业务架构师”，但水平高的人难求。从这点来说，我也理解工具是开放给前台自己做服务安排的同学的。虽然我一直在强调中台要深入业务，细化SOP，但是中台不能过度介入业务，业务的敏捷性不能被中台拖累。中台提供的能力必须是灵活可定制的，让业务方能够按照规范自主完成，降低沟通成本，提高效率。因此，服务编排还是需要作为一种工具来提供。前期利用工具快速尝试探索合适的业务流程，后期通过优秀的业务实践形成SOP。服务编排快速创新，SOP稳定复用顺序：业务中台优先VS数据中台优先虽然中台种类繁多，但真正与业务保持紧密配合的是业务中台和数据中台，阿里巴巴的中台platform核心也是由这两个中间平台驱动的。这里体现的核心是一切业务数据，一切数据业务，业务产生数据，数据赋能业务。业务中台和数据中台的双重驱动在与一位Gartner分析师交流时，他的观点是先有业务中台，再有数据中台。虽然我们也是从商务中心出发，但是我个人不是特别认同这个观点。我比较认同的是先有业务后有数据，但先启动哪个中台完全取决于每个企业的个体情况。如果企业最迫切的需求是避免重新发明轮子，提高IT生产力，数据基础相对较好或者数据水平不够，建议业务中心优先。如果企业最迫切的需求是系统多但孤岛严重，急需打通，企业已经有大量数据急需在业务中发挥价值，建议数据中心放在第一位。具有自主技术研发团队特点的科技公司更适合业务中心优先，而自主开发能力较弱、更多依赖第三方外包应用系统的传统企业可能更适合数据中心优先。中台团队：委员会VS许愿池中台的建设是一流的工程。没有自上而下的推广，中端很难落地。因此，中台转型的第一步是组织架构的调整。要成立中台团队，负责组织、协调和建设。如何建立中台组织也是摆在中台团队面前的一道难题。在我见过和经历过的中期组织中，往往有两种形式：第一种是委员会。中台团队是一个虚拟的组织，由各个业务条线选派的同事组成，其中大部分是领导，更多的是承担组织协调的角色。具体执行工作分散在原部门。这可以称为委员会。看起来像中泰。由于各部门的领导组成，相互之间加强了信息共享，重用的意识也逐渐有了。但在企业IT建设环节，由于没有专门的执行团队专门负责共享业务，协作成本会增加。输出可能更务实，看起来很生动，但实际上很难体现复用的价值。二是许愿池。中台只是一个普通的共享研发部门。前台直接把需求丢到这个心愿池里，然后期待中台提供一个现成的组件和服务。中台变成了前台的兼职。不用说，累并不讨人喜欢。阿里早期的共享事业部大概就处于这种窘境，在商业上没有话语权。中台团队既不应该是一个委员会，也不应该是一个愿望池。中台团队不仅能组织带头，更要有实际输出。中台需要前台的滋养，前台需要中台的赋能。只有中台团队成为拥有核心话语权的实体团队，才能最大限度地复用企业能力。所以阿里巴巴才会让CTO行健张建峰负责推进中台战略，所以才有今天阿里巴巴中台的影响力。中台和前台要相互赋能。其实中台建设遇到的问题远不止这些。我们需要在实践中摸索出正确的解题方法。中泰成功的行为准则和行动计划最后引用本书的内容《中台战略》结束本文。希望修行中台的同仁，能立马成功。参考文献：《中台战略：中台建设及数字商业》陈新宇等机械工业出版社《MASA 架构》Gartner分析报告作者：谭明明简介：在技术、产品、运营等领域拥有丰富经验，现负责百洋智能科技产品研发。喜欢并擅长IT架构和产品架构。微信公众号：CaigenChaosTan，欢迎关注，聊聊产品和技术。
