存储在线
| 作者：陈新宇 – 云徙首席架构师
数智化，可以概括为通过连接产生数据，基于数据发现规律产生智能，基于智能帮助决策指导行动，赋能商业，周而复始，生生不息，从而推动企业业务新的增长。
连接、数据、智能，是其中的三个关键词语。
连接表现在企业品牌、市场、营销、交易、服务、设计、研发、生产等各环节。比如，连接企业客户，连接企业上下游的合作伙伴，连接企业内部员工等。除了人与人的连接，还有物与物的连接，人与物（设备）的连接。
有些连接是数字化之前即已存在的，但没有被数字化；有些连接是基于数字化视角所产生的新的连接。
那么，数据从哪来呢？与应用场景结合产生数据，与业务的结合，是数据生命周期的起点。我们的目的是，在海量的数据上，通过一整套让数据用起来的机制，将企业沉睡的数据变成数据资产。让数据为业务服务，活用数据。
同时，呈指数级增长的数据为人工智能的应用提供了基础支撑，让数据帮助我们做出决策，从而改造产品设计、升级运营手段等，赋能商业。
中台是企业数字商业的新基建
数字化转型是指企业利用大数据、人工智能、IoT、5G等技术，通过改善客户体验、改进产品及提高运营效能等来赢得客户，降低成本，形成和保持企业核心竞争力，推动企业业务的增长。
左边是技术，右边是业务目标，中间需要建设一座桥梁，这座桥梁是什么呢？
去年4月国家发改委和中央网信办联合印发《关于推进“上云用数赋智”行动 培育新经济发展实施方案》。采取云服务普惠推动企业“上云”，更深层次促进大数据的融合运用即“用数”, 加大企业智能化改造为企业“赋智”。通过“上云”、“用数”、“赋智”，用很简洁的语言为企业的数字化转型指明了关键路径。
更进一步，2020年8月， 国务院国资委颁布的《关于加快推进国有企业数字化转型工作的通知》更明确地提出需要探索和构建适应企业业务特点和发展需求的数据中台、业务中台等新型IT架构模式，建设敏捷高效可复用的新一代数字技术基础设施。
我们来看，企业内部的信息化系统。
传统的台式机上，我们构建部门的办公软件；随着网络的兴起，又构建了局域网络拓扑系统；云计算时代，提供了计算，存储网络的基础设施，以及PaaS的基础服务，比如数据库服务等，都是偏向技术。上层的应用则是B2C商城、BBC商城、企业管理系统、协同办公软件。
这中间还是缺了一层，这一层是什么呢？我们认为，是一个结合业务的，面向上层应用建设的、平台化的数字中台。
从这个概念可以看到，中台已经不仅仅是前台/中台/后台的中台，而是企业中枢的中台，上层的应用系统都建设在这套平台化的基础上，所以中台是企业数字商业的新基建。
我们给中台一个定义就是：数字中台是基于云计算、大数据、人工智能等新一代技术架构打造的持续演进的企业级业务能力和数据共享服务平台 。
阿里所推出的，并被大家所广泛接受的是业务中台和数据中台。
业务中台是以业务领域划分边界，形成高内聚低耦合的面向业务领域的能力中心。诸如商品中心、交易中心、营销中心等。
数据中台则是数据整合和智能应用平台，首先构建数据的模型，包括人货场(会员、商家、经销商、商品、店铺)等的主题模型，浏览、下单、支付、评价等事件模型，进行统计分析，并运用机器学习、深度学习等技术搭建标签、推荐、预测等算法模型。
业务中台与数据中台一起来支撑企业客户端、生态端和员工端应用，来服务上层的消费者。
中台如何建设？
那中台究竟如何去建设呢？
中台是一个共享服务平台，其中的一个关键原则就是，开发以重用。
中台建设的技术本质：分析相似性和差异性，管理通用性和可变性：按需组装、按需部署、按需配置、按需编排、按需扩展。
这里面包含三个机制：拆分机制、组装机制、变化机制。
拆分机制： 一定是从大到小拆，大家比较熟悉的理论，就是面向领域的驱动的设计，DDD（Domain-Driven Design）。
组装机制：在领域拆分的基础上，我们通过在一个基础功能包之上叠加多个功能包形成不同的执行单元。
将不同的功能拆分为不同的功能包，优点是可以根据实际需要进行组装叠加。
比如，一个企业内部有不同的业态，有做文旅的，有做地产的，有做汽车的，他们对交易是有个性的需求。云徙自身也在服务不同的行业，包含地产的、汽车的、渠道的、快消的等等。这样，通过功能包拆分可以自由组装出各业务板块或各行业所需要的执行单元。
变化机制：可以从可配置、可编排、可替换、可扩展四个方面来考虑。
可配置
通过组装的方式，我们可以变换出想要的执行单元。但那些参数在不同的执行单元，不可能跳到每一个执行单元去配置，所以各个执行单元的可配置性要上报到统一的管控中心。
配置项是相对独立的，需要从业务角度进行编排，形成可视化的配置。配置的结果，再下发到原来独立的执行单元，执行单元按需装载配置，就达到了我们最开始说的中台的柔性的执行。
可编排
配置数据的统一控制、下发和隔离、装载机制会让中台随需而变，除此之外，支持动态执行业务规则和业务流程的引擎也是实现中台柔性执行的另一大支撑点，比如交易引擎、促销引擎、流程中心等等。
此处以交易引擎为例。各个领域提供的能力，经由可视化编排，即可做到先付款后发货，也可以先发货后付款。对于大额订单，还可实现支付环节的自定义，比如上传支付凭证。通过编排能力满足具体业务情况。
可视化的编排可以使中台更具像化，并大大降低中台管控和运营的门槛。
可替换
不同的企业，同一企业的一个中台系统，以及一个中台系统的阶段，比如开发、测试、生产等，它们的运行环境都可能不是完全一致的。比如开发时使用本地的开源环境，生产使用某公有云厂商的服务等等。因此，中台需要实现环境隔离，做到不同环境间的无缝迁移，而无需更改业务代码。
可扩展
功能包之间不是像垒砖一样的简单的堆叠关系，而是设计了一种扩展点和扩展之间的互相连接，类似插座与插头。每个功能包可以预埋一些可插拔的扩展点，而其之上的功能包即可提供一些扩展实现，嵌入到下层功能包的执行过程，以此来改变原先系统行为，达到了不用修改已有代码，即可实现个性化需求的目的。另外，此功能包也可继续预留扩展点，从而就象乐高积木式的堆叠起系统。
中台能力经由多个前台应用使用，才有共享的价值。但各个前台应用一般是由一个特定的业务驱动的，比如品牌企业直接构筑面向2C的官方商城，为经销商赋能BBC的云商，以及社区团购等，这些业务一般是由不同的运营团队负责的，在业务发展上需要相对隔离的。
那么，实现可变性所需的标识体系，首先要将系统的运行空间分成不同的层级：
系统可支持不同的租户。在同一个租户下，可运营不同的业务空间，比如前面提到的官方商城B2C、BBC云商、F2B等。
在业务空间下，我们根据实际需要再定义了一层叫业务身份，用于更细粒度地管控中台。比如，同一个商城下，某些商品需要预约才能下单，有些商品可以直接购买。
有了运行空间分层后，根据实际管控的要求，在不同的层级设定合适的配置值，然后在运行时识别当前业务活动所属的运行空间层级，并根据层级装载相应的配置值即可实现不同层级的管控。
这里需要提醒一下。
第一，可变性不是越大越好。大的可变性将导致组件不易理解，从而不能有效地进行使用，或者当可变性互相冲突时，导致无法预见的错误。
第二，看似共性业务被广泛使用，实际上是放大了业务的差异性，不但加重了业务配置的负担，同时增加了业务维护的难度。
第三，劣质的组件不利于工作，且让使用者对组件喪失信心
第四，不合适的可变性机制，也满足不了业务的需要。
因此，云徙结合我们服务众多各行业头部客户的实战经验，提出”软件定义中台”的方式来建设中台。
软件定义中台
软件定义中台的核心思想包括两部分：
其一是：明确提出由技术平台来支撑业务中台和数据中台的构建。技术平台强调的是一个平台体系，包含了完整的能够支撑业务中台、数据中台以及上层业务系统和应用开发、运行等的工具及环境等。
通过技术平台才是更好的支撑业务中台和数据中台发展的工具平台体系，因此，我们将其定义为数字中台的一部分。
其二是将中台分为运营层、控制层和执行层，统一运营、集中管控，柔性执行。
以上就是云徙整体的“软件定义中台”的概念。