为深入贯彻落实新发展理念，以供给侧结构性改革为主线，围绕建设现代化烟草经济体系，以更高水平、更深层次的信息化、数字化能力促进资源要素优化配置和合理流动，推动行业高质量发展，国家局提出全国烟草生产经营管理一体化平台建设的总体目标与平台框架（全国烟草生产经营管理一体化平台，从基础支撑到上层应用包含四个层级，分别是：一个云平台、两个中台（业务中台、数据中台）、四大企业应用和两大行业应用，共同形成“1242”总体架构）。其中“数字中台作为行业一体化平台总体框架的重要组成”这一火爆互联网的架构概念提出，吸引了行业大多数IT人员的眼球。“什么是中台？行业要建怎样的中台？怎样设计行业中台？”自然而然地成为了行业IT人员茶余饭后的谈资。出于对信息技术的爱好和偏执，本文以业务中台为例，阐述了笔者对行业业务中台设计的肤浅理解。

什么是中台？可能，每个人都有不同的见解。至少，没有一个权威机构能给出中台的明确定义。百度、知乎上有很多不同的中台定义和理解，但这些定义过于概括和抽象，不适用于项目的独特性，行业体制下的中台建设其独特性尤为明显，实不亚于重大科研创新项目。虽摸着石头过河，但行业一体化项目组全员都凭着赴百仞之谷而不惧的勇气及筚路蓝缕、以启山林的干劲，抓铁有痕、踏石留印地探索着建设之路。

建设中台，首先需要对中台有足够深刻的理解，厘清中台与前台、后台、微服务之间的关系；其次在业务需求梳理和设计层面上将具有共性的业务资源整合，形成行业级的服务复用能力；然后在实现服务能力共享的过程中，不断优化、沉淀更多的业务能力、业务规则配置等要素从而推进运营模式的转变及组织架构调整。

笔者结合行业信息系统项目建设的浅薄经验，按照信息系统架构设计、系统分析理论，根据对中台起源的解读自行定义了中台及业务中台，在厘清中台与前台、后台、微服务之间的关系基础上，梳理了业务中台包含的内容，粗略地阐述了业务中台的设计思路。

1 从起源理解中台

从技术上若将中台算作一种系统架构是新概念，其起源有两种说法，一是中台概念早期是由美军的作战体系演化而来，技术上所说的“中台”主要是指学习这种高效、灵活和强大的指挥作战体系；二是由阿里在2015年提出的“大中台，小前台”战略中延伸出来的概念，灵感源于芬兰的游戏公司Supercell——以小前台的方式组织了若干个开发团队。每个团队包含了开发一款游戏所需的各种角色。而基础设施、游戏引擎、内部开发工具和平台则由类似“部落”的部门提供。用以支持众多的小团队进行游戏研发，团队开发效率高、创新能力非常强，开发出了多款火爆游戏。

图1-1 中台作战体系示意

从管理上若将中台看作一种组织架构，早在我国东汉、唐朝就已历经了几百年的最佳实践。东汉时期,尚书台成为政府的中枢,号称中台。唐朝完善的三省六部制,以门下省为西台,中书省为东台,也将尚书省称为中台。中台作为执行机构，辖吏、户、礼、兵、刑、工六部。

图1-2 三省六部制示意

回溯历史并赋予中台新时代的内涵，中台的组织方式就是在企业内部构建统一的协同平台：一方面可以让各业务部门保持相对的独立和分权,保证对业务的敏感性和创新性;另一方面,用一个强大的平台来对这些部门进行总协调和支持,平衡集权与分权并为创新业务提供生长空间,从而大幅降低组织变革的成本。中台提炼各业务线的共性需求,最大程度减少重复“造轮子”。

从技术层面看,中台是企业级共享服务平台。传统的IT系统或套件没有太多关注系统能力的复用和共享,因此企业在多年的信息化过程中引入和建设了多套具有重复功能的烟囱型系统。而中台则要求对能力进行细粒度分析,识别共享能力,并将共享能力建设成为统一的平台。

综上所述,笔者对中台的理解为：中台是基于企业资源整合的需要，形成的能力枢纽和能力共享中心。中台是在集中的基础上建设分权的业务,进行联通,并为各业务提供统一的服务，将企业各式各样的资源转化为易于前台使用的能力。

2 中台与前台、后台、微服务

早期行业建设的系统有不少是基于单业务领域或企业组织架构来建设的，每个系统都有自己的前端界面和后端业务逻辑，不同系统之间相互独立。用户操作是竖井式，有时一笔业务需要登录多个系统才能完成完整的业务流程（如在处理烟叶调拨业务时需要登录专卖系统完成准运证申办、登录交易系统完成结算）。如下图2-1所示

图2-1 烟囱式系统建设模式

按笔者的理解，在1242总体架构下，行业级会有一套整体解决方案，以实现4大企业应用、2大行业应用与各种不同中台的前端操作、流程和界面的组合、联通和融合。不管在行业级有多少个业务中台，前端用户感受到的始终是一个前台交互界面（如在处理烟叶调拨业务时无需再登录专卖系统完成准运证申办、登录交易系统完成结算，前台应用服务通过中台调用准运证、交易等业务流程提供至前台交互界面，用户操作时始终是在一个应用的前台交互界面）。如下图2-2所示

图2-2 前台应用服务调用业务中台示例

建设中台的过程中，若仅将传统集中式单体应用按业务职责和能力细分为微服务，则会产生越来越多、独立部署的微服务。这种方式虽提升了应用弹性伸缩和高可用能力，但微服务之间物理隔离运行的特性，会导致数据进一步分离。原单体系统内的调用也会变成跨微服务调用，加之前后端的分离设计，会极大增加应用集成难度。

倘若没有合适的设计方法和指导思想，处理不好前台、中台、后台和微服务间的关系，将会加剧前台业务和数据的孤岛化、碎片化。厘清中台与前台、后台、微服务之间的关系与边界势在必行。

2.1前台

由图2-2可看出，前台包含两大部分，前台交互界面和前台应用服务。前台应用服务是指为前台交互界面提供后端服务接口的功能单元集合。业务中台一般不直接面向前台交互界面，而是面向前台应用服务，为其提供共享的服务接口功能单元集合。前台应用服务提供的功能具有应用局限性和特殊性，它一般是完成某一个特定业务场景所需的功能。相对而言，业务中台完成的则是多个业务场景的通用部分，以及挂载和执行面向特定前台业务的扩展功能。通常来说，前台应用服务会根据前台业务场景的特殊需要，将中台能力进行编排、转换后再提供给前台交互界面使用。

2.2后台

后台是指系统的后端平台，终端用户感知不到他的存在。后台的价值是存储和计算企业的核心数据。例如工业企业ERP系统存储商品及库存数据、人力资源系统存储用户及组织机构信息。后台并不直接面向用户，而是面向运营人员的配置管理系统，比如商品管理、物流管理、结算管理。后台为前台提供了一些简单的配置，基础设施和计算平台作为企业的核心计算资源，也属于后台的一部分。

2.3微服务

微服务不是业务中台，但微服务与业务中台并不是截然分开的，“微服务”是当今比较流行的一种技术架构，微服务是在技术层面建设业务中台能力中心的最佳实践。业务中台的内涵不仅仅是技术架构，还是一种组织层面的业务架构。虽然中台作为技术架构体现出来的是微服务的形式，但从广义上讲，它还可以是一种企业组织管理模式和理念。业务中台是在“集中”的基础上建设隔离分权的前台业务，并将这些业务进行联通。业务中台结合了系统论整体规划的思想，将系统按纵、横两个方向进行拆分。它吸收了微服务“按业务领域”的纵向拆分应用方法，形成“高内聚、低耦合”的能力中心；在纵向拆分的基础上，横向将业务中台与业务应用进行隔离，造就了中台的共享理念，使其超脱了微服务的范畴。中台内部纵向拆分服务，降低了领域间的耦合度。中台与上层应用横向隔离，促进了业务和数据在各应用间的交叉共享，大大减少了重复建设和重复投资，由此，也造就了可持续沉淀积累和运行的企业资产，中台因此成为行业数智化转型的新基建。

3 诠释业务中台

在厘清中台与前台、后台、微服务之间的关系后，笔者理解的业务中台是以业务领域划分边界，形成高内聚、低耦合的面向业务领域的能力中心，打造持续演进的行业级业务能力共享服务平台。业务中台的直观呈现就是各能力中心，常见的有交易中心、商品中心、库存中心等。它不仅提供丰富的共享服务，还包含体系化建设企业能力域的方法和机制。业务中台不仅是生产上层应用的开发设计平台，也是配置、编排和扩展业务对象、业务能力、业务规则及业务流程，完成企业资源运营管理的平台。它为上层应用系统的稳定运行提供了高并发、高可用的执行环境。

4 剖析业务中台

通过抽象所形成的通用业务运行机制，解决的是前台业务共性的问题。这种通用的业务运行机制是业务中台的核心内容之一。业务中台专注于通用机制的抽象和实现，所以业务中台才具有通用性和包容性。业务中台再结合可动态修改的配置项，以及可即时扩展的插件，通过业务空间的隔离，解决了业务个性化问题，即以一套通用的机制同时支撑不同业务，从而进一步保证了业务中台的开放性。业务中台主要就是以这两点来支撑不断变化的业务场景，并确保自己不会频繁地被推倒重建。

业务中台专注于通用业务运行机制和系统开放机制的实现。而业务中台通用业务运行机制需要包含四个要素——业务对象、业务能力、业务规则和业务流程，按照微服务设计原则将系统开放机制再拆分为业务配置和业务隔离最小独立应用。由此，业务中台至少包含业务对象、业务能力、业务规则、业务流程、业务配置、业务隔离6项内容。

4.1业务对象

业务对象包括实体对象和过程对象，实体对象是指具体的企业资源、产品与服务，例如商品、用户、客户、组织机构等一切有形或无形的资源。过程对象主要是指企业在经营活动中对业务动作进行的描述。行业级业务中台，笔者理解的业务对象主要为管控对象和业务过程管控。具体指专卖制品的生产、加工、储运、交易等环节涉及的管控实体和业务操作的过程管控，比如“收购”是对交易活动的描述，“工商交接，三方确认”是对多方利益关系在烟叶经营活动中过程的描述，它们都是过程对象。

4.2业务能力

业务能力是同类业务功能的抽象实现，是对业务对象的操作。业务能力可以改变业务对象的状态，并通过结合业务规则来操作相关的业务数据。一个能力可以支持多个功能。能力的基础是结构和算法，能力是系统内生机制的体现。在不同的业务场景下，业务能力可间接表现为不同的应用功能。比如仓库注册能力，既可以对应用户自主注册的功能，又可以对应系统后台主动开通仓库自动注册的功能。

4.3业务规则

业务规则就是业务逻辑，是用来控制或影响业务能力的定义或者约束的描述。中台将业务规则与业务能力独立开来，单独实现。业务规则影响了能力中心所提供的能力和业务数据的聚合、转换、变化。比如，“仓库创建能力”搭配“仓库需要审核”的业务规则，就会产生“仓库创建后，仓库进入待审核状态，需要审核通过后才能发布”的情况。

4.4业务流程

业务流程规定了业务中台系列业务动作执行的顺序，用以完成特定的业务目的。业务中台针对不同业务需要设计不同的业务引擎，比如交易引擎处理交易相关的逻辑，促销引擎负责促销活动相关的自动化，审批流引擎负责统计报表（业务单据）的审批。业务引擎和流程定义决定了能力中心内部以及能力中心之间如何自动化执行。比如通过可自定义的交易流程，业务系统既可实现先付款后发货，又可实现先发货后付款。这种面对实际场景需要多变的业务不是通过修改代码，而是通过调整业务流程来实现的，从而让中台达到随需而变。

4.5业务配置

业务配置是内嵌在业务中台逻辑中的一些控制点和扩展点。通过可视化的配置视图，用户可以动态控制业务中台的执行逻辑，让业务柔性运行。比如烟农身份认证扩展点，可以配置烟农在交售时是否需要进行认证。如果进行认证，是选用滑块认证、人脸认证还是其他认证方式，从而动态控制交售场景中的业务执行逻辑。

4.6业务隔离

业务中台作为共享服务，需支撑多个前台应用。在共享的基础上，需要隔离前台应用，让前台应用既可执行个性化的逻辑，又避免互相干扰，各自独立运营发展。比如，当任何一个前台应用增加功能或者修改执行逻辑时，我们只需对该前台应用进行整体回归测试，而不需要对其他前台应用进行回归测试。

5 业务中台的架构设计

行业业务中台建设是一项极具创新的系统化工程。从系统架构角度看，业务中台也有自己的架构体系。那么中台的主要架构风格是怎样的呢？根据笔者理解的业务中台内容，概括起来就是：纵向分域，横向分层。

5.1 纵向分域

纵向分域是指，业务中台将企业的业务内容，按照不同领域，以及能否独立运营为标准，进行纵向切割。对切割后大小各异、算不上严谨的多个业务领域，业务中台从技术上再进行一系列的分析、抽象、归类、推演，形成在业务上能独立运营、技术上含有多个微服务的系统。切分之后的各个系统，我们一般称为业务中台的能力中心。如常见的用户中心、客户中心、交易中心、库存中心、消息中心、支付中心等。每个能力中心都支撑着不同的业务领域，它内部所有的领域对象均与业务领域有直接的聚合关系。

5.2 横向分层

横向分层需要建立在纵向切分的基础上。对于不同的业务领域，业务中台会根据其管理对象的不同性质，从下向上拆分为业务实体层、业务协作层、业务活动层。这里所说的“横向分层”强调的是在业务中台内部，前面提到的“横向隔离”，指的是整个IT系统层面的横向隔离，也就是将业务中台与前台应用隔离。

·业务实体层：由管理企业静态资源的能力中心构成，居于三层模型的底部，比如商品、仓储、用户等。

·业务协作层：由对企业资源使用策略进行管理的能力中心构成，居于三层模型的中间，起到承上启下的作用，比如营销政策中心、价格政策中心等。

·业务活动层：由管理或实现企业核心业务活动的能力中心构成，居于三层模型的顶部，可实时调用下方两层的业务能力，完成业务活动的执行，比如交易中心、支付中心等。

通过横向分层，中台就确立了不同层次能力中心之间的依赖关系和数据流向关系等。三层模型的顶部，可实时调用下方两层的业务能力，完成业务活动的执行，比如交易中心、支付中心等。

6 业务中台的体系结构

从软件工程角度来讲，完整的业务中台体系结构由设计态、管理态、运行态三个阶段组成。各阶段拥有相应的关键特征，对这些特征的深入了解，有助于指导业务中台的架构设计落地。

6.1设计态

设计态的业务中台提供组件平台和能力平台。组件平台的作用是快速搭建应用，能力平台的作用是统一管理和使用中台能力。

组件平台可完成前后端组件的注册、发布及接入指引。这里的组件包括技术类组件和业务类组件两类。技术类组件封装了通用的技术功能，业务类组件不仅封装了特定的业务逻辑，也封装了对业务中台能力的调用。组件平台为业务应用端到端的建设，从创建应用、描述数据模型到组装页面，提供了组件素材，加快了应用的搭建。

能力平台提供能力的注册、发布及接入指引。通过能力平台，中台系统的使用者（包括中台能力使用方、中台能力提供方和中台机制设计方）不仅可以统一直观地查看中台具备的能力与能力详情，还能汇总统计能力的调用情况等。能力地图即是能力平台的一个体现。

6.2管理态

管理态的中台应包括需求管理、进度管理、质量管理、项目管理、配置管理等多个方面。因为业务中台建设是由多人多角色共同协作完成，所以需要通过统一的管理平台从中协调推进。一般把这些软件生产过程中通用的需求管理、进度管理、质量管理等放在技术平台的研发服务平台上实现。在业务中台建设的推进过程中，建设方还需要加强对各阶段产出物的评审，并通过对评审结果的记录，实现上线内容可追溯。

6.3运行态

运行态的中台包括能力配置、能力编排、能力执行三个方面。可配置和可编排的能力需要统一上报，形成全局的控制中心，即中台管理控制台，以完成对业务能力的管理和配置，然后通过执行平面实现能力的执行，再通过运行监控形成运营监控台，三者共同配合，达到对业务中台运行内容的柔性管理和控制。

7 业务中台构建

根据系统分析理论结合业务中台开发案例分析，业务中台构建主要可分为业务中台构建策略和业务中台构建实施两部分。

7.1业务中台构建策略

业务中台的构建策略（属于项目前期咨询阶段过程或产出物，其方法论和工具网上有很多资料供参考，无需赘述）主要是利用方法论、实践工具等将企业整体业务细分成业务领域和能力中心的过程方法。可归纳为三个层面，即领域驱动、需求结构化和能力可配置。首先，通过领域驱动，从整体上划分业务中台的领域，进而划分出业务中台的具体能力中心；其次，对具体的领域进行细化，使用需求结构化和能力可配置两种策略，最终形成易用、灵活的业务能力中心。

7.2业务中台构建实施

业务中台构建实施通常采用五步法，它是指导建设业务中台的方法论，具体步骤为：业务规划→领域分析→能力中心设计→中台实现→业务运营。其中，领域分析的过程非常关键，是业务中台区别于以往传统IT系统建设的环节；能力中心设计是各平台项目组业务中台方案设计的重点环节。

对行业一体化项目而言，在开展业务中台建设时，一体化项目办和信息中心，首先会结合行业发展战略与业务中长期规划，开展业务需求调研和梳理，形成业务能力蓝图和抽象业务要素；其次会在业务需求调研的基础上，基于对行业业务流程和应用服务的梳理和理解，明确业务共享服务中心的层级结构，形成统一的建设标准和要求，建立业务共享服务中心元模型及清晰的业务中台服务能力构建策略，形成各个业务共享服务中心的详细设计；然后会对业务中台涉及到的微服务架构、应用管理、服务治理、灰度发布等开发、测试和生产环境的技术架构体系进行统一设计，明确业务共享服务中心与云平台工具、业务中台基础框架工具的对应关系，并针对行业应用两级部署的特点，结合两级各中心能力设计，设计出相应的技术架构体系；最终形成纵向分域、横向分层的业务中台顶层架构（0级架构）。业务中台在纵向维度进行领域划分，形成业务中台的能力中心；同时在横向维度，根据业务领域与上层应用的关联性，将业务中台领域进行分层。

根据项目办和信息中心给出的0级架构，在明确了能力中心的层次依赖关系后，各平台项目组就可根据分配好的业务中台建设任务，对不同层次的能力中心，采取不同策略进行能力中心设计及建设。

7.3 能力中心设计

能力中心设计包括组件规划、1级架构设计、能力中心概要设计。组件规划承接0级架构设计，是对能力中心内容的展开，即明确能力中心由哪些业务组件组成。通过对能力中心的功能分析和业务实体的抽象，将具有较强依赖关系的业务实体聚合为一个组件，或者将具有相同主题的业务功能聚合为一个业务组件。最后以结构化的形式聚合这些组件，构成能力中心。业务组件是业务逻辑的封装单位，包含一个或多个能力，一般用于完成一个具体的业务任务，并可被多个业务场景所复用。业务组件按照逻辑关系聚合为能力中心，能力中心又可以根据逻辑关系分为业务实体层、业务协作层、业务活动层三个层。这样就形成了业务中台内“横纵有序、解耦合理”的立体架构。

组件规划设计完成后，需要转化为应用架构。这里的应用架构是指能力中心内部的应用架构，称为1级架构。如果说0级架构是业务中台的骨架，那么1级架构就是业务中台的血液。骨架的作用是稳定和支撑，而血液则需要在身体各部分流动才能维持各项机能的正常运作。1级架构聚焦的是在具体业务场景下，各中心、各应用如何各司其职、承载所属的数据和业务逻辑，即通过具体业务场景，将各中心的能力和领域事件串联起来。在串联的过程中，我们有可能会发现0级架构缺失的能力，甚至需要调整0级架构各能力中心的领域模型分布。1级架构是从0级架构设计到落地开发的关键桥梁，也是能力中心概要设计的指导方针。

能力中心概要设计是从系统设计到开发交付的过渡阶段。通过设计数据库概念模型、功能包结构、核心时序图、接口设计等，为能力中心的详细设计与开发奠定基础。

7.4 开发交付

开发交付是将0级架构及具体场景下的1级架构落实到代码，并实现为可运行系统的过程。开发交付包括能力中心详细设计、测试用例设计等详细内容的设计输出以及代码开发、持续交付等。能力中心详细设计包含数据库物理模型设计、具体能力的时序图、类图等。这里需要注意，数据库模型并不等于领域模型。

开发交付是一项复杂的系统工程，需要依托一套对设计态、管理态、运行态统一进行管理的技术平台才能顺利完成。另外，在使用技术平台的过程中，开发团队也要不断吸收先进内容，如管理思想、开源技术、快捷工具等，这样不仅可以更好地帮助团队快速成长，也可以推动技术平台的沉淀和演进。

整个开发交付过程需在技术自治的思想指导下展开，包括迭代规划、需求反讲、持续集成等，并辅之以日清日结的过程管控。日清，帮助团队发现问题；日结，及时总结经验教训。通过总结回顾，先进有效的措施得以发扬，不足和错误则可被及时制止，保证开发活动有效推进。

7.5 持续运营

业务中台需要持续运营才能不断沉淀和发展，持续运营包含以下4个方面。

(1)业务运营：利用业务中台的管控能力，结合数据中台的各类分析视图、趋势预测，调整原有的业务运营措施或增加新的业务试错方案（如定义新的营销活动，上架合适的商品），驱动业务发展。

(2)内容运营：运营的内容包括产品、销售、服务、企业文化等多个方面。各业务部门可按需准备不同的内容素材，定义不同的内容模板，发布到企业内外部各个渠道。

(3)技术运营：通过中台控制平面，快速调整业务配置，灵活调用编排能力，聚合不同内容，以满足业务运营的需要。对于不能动态调整的场景，则需要扩展已有能力或增加新的能力。中台控制平面与执行平面的交易引擎、营销引擎、链路监控等一系列技术结合，组成管控和执行体系，助力技术运营。

(4)数据运营：业务需要数据的反馈和指导，同样，业务中台的能力建设也需要数据的指引。因此，数据运营不仅会帮助企业进行业务的调整和优化，还可以指导业务中台能力的迭代。

8 双中台联动

传统企业的核心业务大多是基于集中式架构开发的。这种集中式单体系统，一般都存在扩展能力弱、弹性伸缩能力差的问题，无法适应突发高频访问的互联网业务场景。同时，传统企业数据类应用大多通过ETL工具抽取数据以实现数据建模、统计和报表分析功能。这种传统的数据仓库处理模式往往会存在数据时效性问题，再加上传统数据类应用主要面向企业管理和决策分析，并不是为前台而生的，因此难以快速响应前台一线业务的数据服务要求。

在数字化转型时，为同时解决传统的业务和数据应用建设问题，项目办和信息中心高瞻远瞩地采用双中台模式同步建设业务中台和数据中台。业务中台与数据中台各自独立，却又相辅相成。业务中台支撑实时在线业务，并产生业务数据；数据中台则通过汇聚整合、提纯加工、建模处理、算法学习，将数据转为数据资产，并以共享服务的方式提供给业务使用，从而与业务联动，并再次产生新的数据。

从数据角度来看，业务中台通过能力的输出，获取了大量的业务数据。这些实时的业务数据是数据中台非常重要的数据来源之一。而且，因为这些数据是实时的，所以就减少了数据中台模型加工的时间延迟。与此同时，数据中台通过模型加工出来的数据结果，可直接推送给业务中台，丰富业务中台的业务内容。比如，数据中台加工产生的烟农标签，推送给业务中台后，业务中台就可以展现综合的烟农画像，为职业烟农评定提供高效率和高质量的服务。

从业务协作角度来看，业务中台在支撑业务时，需要数据中台提供的数据服务来对业务能力进行调整。数据中台提供的在线数据服务可以帮助业务能力更有针对性和精准度的执行。比如，营销互动场景下，业务中台的交易能力可以结合数据中台的人物画像服务，完成千人千面的差异化推介。

9 项目组织特性

行业一体化平台项目与其他IT项目显著区别有2点，1、行业其他IT项目大多基于单业务领域或某一层级的企业组织架构，而一体化平台项目针对的是行业组织架构下的全业务领域；2、同组织架构类似IT项目，管理维度仅有生产经营或运营一条业务主线，而行业级管理维度涵盖管控和生产经营或运营两条业务主线，其显而易见的项目独特性，更彰显了一体化平台项目科研创新的含金量。

一体化平台项目建设涉及到的技术架构变革、系统架构变革、业务架构变革及引发的运营模式转变和组织架构调整等问题其难度、复杂性不言而喻。作为在行业1242架构下开展设计的平台项目，其每位参与者都已置身于行业数智化转型的风口浪尖。站在“行业一体化”的风口上，除要有 “万折必东不回头”、“赴百仞之谷而不惧”的勇气支撑和“筚路蓝缕，以启山林”的做事干劲外，更需具有乘风而起、顺势而上的自我更新与迭代的学习能力。如在设计阶段，业务人员作为项目组内主攻角色，首先需精通本领域业务，通过业务调研、业务需求、业务分析，细化业务操作过程，对业务进行颗粒度划分，找出每一个功能需求所对应的业务对象或实体；然后需熟练掌握企业供应链上、中、下游各环节业务，从供应链、产业链的角度全盘思考、洞察相关对象或实体在流程流转和业务衔接中存在的痛点、堵点、难点问题；其次需增强全局视野，宽域思考的能力，要站在行业级管理维度（管控、生产经营或运营2个维度）对业务功能需求分析整合，对业务流程优化、重构，企业应用和行业应用的“上下贯通”及行业应用之间的“左右联通”进行前瞻性思考。技术人员作为项目组内主控型辅助角色，除应具备业务人员上述能力要求外，更需强化提升技术水平以解决项目中遇到的技术壁垒，同步辅助好业务人员按系统架构、应用架构、中台架构、数据流向等开展功能、需求设计；并从软件工程和系统分析的层面为项目管理者提供技术方案转化文档（将专业技术文案等转化为通俗易懂的文档）、项目范围管理的边界、进度管理的关键路径节点、过程问题、应用资源情况等辅助。项目管理者作为项目组内的总控师，除具备大型项目管理PMP能力要求外，更需具有对上敢直面问题、打破砂锅问到底，对下能统一步调、齐心协力向前行的——沟通技巧；敢于向积存多年的顽瘴痼疾开刀，冲破行业经营管理障碍——独当一面的魄力；敢于啃硬骨头、涉险滩、勇于探索实践的——责任担当。

结语

“这个世界的现在与未来不会有太多新鲜的东西,大多在历史中都有。”——中台也是如此，它承载业务逻辑、沉淀业务数据、产生业务价值，并随着业务不断发展进化，其核心、根本都是业务。业务中台只是支持业务场景的手段，其特征表现虽是共享和复用，但其目标依然是为了简洁、高效的完成业务运行。   ——本文仅为笔者一孔之见，望能起到抛砖引玉的作用。