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