【Day 01】中台架构浪潮与启示

前言

近几年中国掀起一股『中台架构』热潮，大型企业纷纷导入此一概念，重整战略资讯架构，建构业务、数据、AI、技术、移动、通讯、安控、...等中台，接着这股热潮也吹进国内金融产业，前阵子某金控就办了一个大型的研讨会，主轴就放在中台架构规划、DDD与微服务实践上，究竟它有何魔力? 我们就来好好的研究一下。

记得之前在电信业服务时，公司还未开台就已经备妥近百个应用系统，以备营运之用，当时资讯部门马上面临一些问题，所有系统可否单一帐号登录? 客户/商品资讯可否共享? 客户资讯开放共享後，如何保密不让非相关的人士查阅? 这些事情看似简单，问题是近百个应用系统有的是外购、委外开发、自行开发，也使用不同的资料库、程序语言、开发框架，如何整合是一个大问题，这个现象几乎是所有企业长久经营下来，必会面临的问题，因此，阿里巴巴提出中台架构，马上掀起千堆雪，大家一股脑的想要一探究竟。

图片来源：阿里巴巴集团的「大中台、小前台」组织战略。

起源与进展

中台架构是阿里巴巴在2015年提出的概念，喊出『大中台、小前台』，将13个业务中心进行整合，在2018年再提出『业务-数据双中台』，将13个业务中心整合成业务、数据两个中台，之後，再衍生出『技术中台』、『AI中台』、『技术中台』、『移动中台』、『通讯中台』、『安控中台』...。

在阿里巴巴提出中台架构，并且大肆宣扬後，其他大型企业也随之跟进，包括腾讯、百度等也提出各种中台，希望能破除企业内的资料孤岛，建立统一的架构平台。相关报导可参阅『你还不懂「数据中台」？』一文介绍。

到了2021年阿里执行长张勇又宣称要把中台架构拆了，变成碎片化(Fragmentation)，其实，张勇并不是要把中台架构拆掉，而是要把2018年提出的『业务-数据双中台』变成更多的中台，包括知识中台、AI中台、移动中台、研发中台、...等等，并将『微服务』(Microservices)导入中台，使系统开发与交付(Delivery)更迅速，以迎接业务型态与销售管道不断创新的挑战。微服务是要拆分业务，而中台架构是要整合相关业务、资料与技术，看似相反，他们如何并用，是一个很有趣的思维。

中台是甚麽?

事实上，学术上并没有中台这个名词，只有前台(Front End)与後台(Back End)，Gartner中国还特别为它翻译为『Middle Platform』，它重要的不是分为多少种中台，而是强调企业复用的能力，复用就是重复使用(Reuse)，也就是企业如何建立一个共享平台，提升企业水平整合能力，让各业务能在共通架构下，对新业务、新产品、新通路、新服务型态的需求，可以更快速的反应，包括系统的开发与调整。

以产物保险为例，公司通常会依业务型态切分为多个事业群，各自开发系统，如下：

但每个业务都有高度重叠的功能，例如车险、火险、水险业务功能都包含以下功能，膝盖式的反应就是把各业务进行水平整合，这样我们就能快速开发出新的险别/险种，例如健康险：

再进一步的思考，每个企业都有些共通的特性，例如每个企业都会有客户、产品、订单、使用者等，这些又可以独立出来，提供跨企业的共通平台，这就是几年前提出的概念『Master Data Management』(MDM)。

所以，严格讲中台并不是一种技术架构，而是一种思维，它的企图心很大，从战略资讯系统架构、个别系统分析、详细设计(Design Pattern)至开发架构(微服务)无所不包，既要『统合』共通架构，建构共享平台，又要能『切分』成各种微服务，分层设计，以利後续的维护与扩充，初次接触，感觉有点在画大饼，深入研读後，整个思维确实可以帮助中大型企业，进行资讯系统改造。

怎麽进行?

中台架构这麽好，那要如何搞定它呢? 目前的作法是以领域驱动设计(Domain-Driven Design, DDD)进行业务领域的切分与规划，找出核心能力、通用领域、支撑(Support)平台，之後就在此中台架构之上，进行个别系统的分析/设计/开发，最终以微服务的形式发布，希望能解构(Decoupling)过往庞大的前後台单体(Monolithic)架构。

因此，要建构一个中台架构，必须要了解下列事项：

1. 订定战略资讯架构(Strategy Information System)：规划企业整体资讯系统架构。
2. 掌握领域驱动设计(DDD)方法论：订定领域模型、聚合(Aggregate)相关领域，推出企业服务。
3. 熟悉微服务(Microservices)技术：如何切分微服务，考量与後端的整合。

以上每一项都是大哉问，之後，我们就来仔细地品尝相关的技术吧。