中台反思：技术中台设计架构

“技术中台长什么样子？”对于没接触过的同学而言这可能会是最需要解答的疑问，但对有技术中台经验的同学而言他多半会告诉你：技术中台是构建在业务中台、数据中台之下，为后者提供通用技术能力支撑的平台。如下图所示：

但是，真的仅仅是这样吗？我们知道“服务”是中台对外提供能力的核心载体，业务中台会向前台应用、后台系统露出操作型、事务型的服务，数据中台也需要将数据模型转成并露出分析型的服务。那么这些服务谁来管理？自然而然的这会落到技术中台。如下图所示：

技术中台除了其显而易见的提供开发框架、运行环境、监控预警等能力外，还需要提供服务管控能力，实现服务注册、发布、检索、订阅、编排等核心功能，进而实现中台能力的统一管控。

既然提到了服务，那么一些共性基础服务谁来管呢？技术中台必定当仁不让。因此我们会进一步演化成如下图所示：

所有的公共服务会沉淀在技术中台，一般而言，一个标准的技术中台需要提供如下服务：

除了这些常见的还有数据同步、多维监控、统一日志等各类更基础的服务。

到目前我们看到了最常见的技术中台架构：技术中台提供研发能力及公共服务以支撑业务中台、数据中台的服务建设。从云架构分层视角看实质是提供了iPaaS及SaaS层的支撑。那么这样有没有问题呢？

对于一般的企业而言，这样的技术中台足以支撑需求，但是随着需求广度、深度的扩展、下探我们会面临如下问题：

笔者被问过很多这样的问题，究其本质是：想要的更多。对于领导、业务开发的同事而言，大家把中台想得太过“强大”了，觉得中台是解决IT问题的“万金油”，所以在你告诉他们我可以这样时总是被问及能不能那样。我们可以去科普中台的界限，但是我们为什么不进一步思考中台到底能不能给到更多呢？

业界也看到了目前技术中台的局限，也出现了一些解决的方向。比如阿里尚在研发中的MSC（Middle-Platform Service Components）就是其中典型的代表，它以四编排（模型、服务、流程、界面）引擎为核心实现可视化的应用构建。于是我们的架构会如下图所示：

在服务管控之上加入了能力编排，可用于开发简单的小应用。当然这种在原架构之上“硬生生”地添加一层必然存在缺陷，我们想做的本质是什么？我们希望的是加入低代码能力（LCDP)以支持应用级的交付而非服务级的支撑。因此我们需要强化研发能力，在架构上需要明确地划分出研发态与运行态。如下图所示：

可以看到几个明显的变化：

基于上述架构，技术中台有能力实现端到端的交付，为其提供了全面的IT研发支撑。对应的形成了中台对业务的四个支撑象限。如下图所示：

如何设计低代码构建平台会在后续文章中介绍。

组织架构是中台建设成败的关键之一，这点笔者也是反复强调，下文将聚焦到技术中台内部的团队建设，聊一下架构上的变迁。

一开始，一般的技术中台会按面向技术及服务划分两个组：

但随着支撑的深入后上述组织划分会受到如下挑战：

为应对上述问题，我们优化了组织架构。如下图所示：

能力交付组用于解决业务支撑不力及能力沉淀不足的问题，由产品经理、中台开发及前台应用开发组成，产品经理划归到此组以获取一手的业务需求。该组衔接公共服务、基础技术组与需求方，避免未经验证的或是突发的需求打乱整体的产品研发节奏，对于边界模糊的需求可由该组开发，验证可产品化后再转入公共服务或是基础技术组完善。另外该组成员可动态增减前台应用开发，以解决中台资源不足导致的支撑问题。

质量管控及架构管控一同解决了内控缺位的问题。

解决方案组一方面通过低代码构建平台的研发，整合公共服务及基础技术产品；另一方面面向大客户编制定制化的解决方案以提升技术中台的产品力。

通过上述组织优化分别实现了横纵双向的组织贯通，提升了协作的效率。