IT2.0：中台构建还应从企业业务实际出发

通过这个系列，让大家对中台的价值、针对的问题痛点、中台规划的方法思路和技巧、一些中台业务实践有个基本的认识，让客户清楚的意识到企业中台的业务价值，进而通过企业中台规划牵引客户 IT 基础设施投资。

今年“中台”一词异常火爆，百度搜索指数已经远超“数字化转型”。中台的产生并非完全自上而下的战略设计，也并非是为了追风，而是随着企业业务的高速发展、组织架构不断膨胀的过程中暴露出的各种问题急需解决。此时，中台的概念恰有其声，大家在经过不断实践论证后欣然接受了中台。

企业中台作为现在的市场热点，几乎每一个客户都会在建设的过程中遇到一系列的问题。借此，希望通过这个系列，让大家对中台的价值、针对的业务问题痛点、中台规划设计的方法思路和技巧、一些中台业务模式实践有个基本的认识，让客户清楚的意识到企业中台的业务价值，尤其是通过中台帮助传统行业的各家企业构建差异化业务服务竞争优势，提升客户满意度，进而创造更多的经济效益，基于企业中台的实际业务价值有效引导 IT 投资。

（一）：前中后台基本定义

前台：由各类前台系统组成的前端平台。每个前台系统就是一个用户触点，即企业的最终用户直接使用或交互的系统，是企业与最终用户的交点。例如用户直接使用的网站，手机 App，微信公众号等都属于前台范畴。

后台：由后台系统组成的后端平台。每个后台系统一般管理了企业的一类核心资源（数据+计算），例如财务系统，产品系统，客户管理系统，仓库物流管理系统等，这类系统构成了企业的后台。基础设施和计算平台作为企业的核心计算资源，也属于后台的一部分。

中台：套用经济学中对于服务的定义，中台就是要协调/调度资源，满足前台与用户互动的需求。业务中台（SOD-System of Differentiation）本质上就是要解决“业务供需矛盾”，即解决创新驱动快速变化的前台（SOI-System of Innovation）和稳定可靠驱动变化周期相对较慢后台（SOR-System of Record）之间的矛盾。（相关概念转自 Gartner Pace-Layered）

业务中台建设的根本目的是要满足前台与用户的互动，中台的模式取决于互动的模式（Interoperability Mode），包括：中台和后台（服务组织）支配的高效互动模式；前台支配的人性化互动模式；用户支配的个性化互动模式。相对于互联网行业而言，传统行业的商业模式、业务模式较稳定，决策链、价值流、业务流很长，高效协同的迫切性往往会高于个性化和人性化，这也是华为一直在追求的服务化转型要兼顾“做生意更简单高效”和“ROADS 体验驱动、客户满意”。

（二）：中台的价值

现有的软件系统不符合客户的业务应用场景。ISV 关注的是自己的软件产品应用场景，并非客户实际的业务应用场景。

客户的实际业务应用场景应该是“端到端高效协同的”、“可以根据新商业模式定制的”、“可以根据作战场景 DIY 的”，ISV 的软件产品迭代总是跟不上客户的业务应用场景变化，因为 ISV 只是软件产品的 Owner，而非客户业务场景的 Owner。

中台规划的核心理念可以总结为：客户业务场景驱动的服务化 IT 架构规划（含前中后台规划）。

我们帮助客户规划设计业务中台的根本目的是要撬动 IT 基础设施转型升级的机会。

我们帮助客户基于客户自身业务场景规划设计的业务中台，某种意义上可以说是“独一无二”的、只适合于客户的，因此业务中台是买不来的，只能整合各个 ISV 的软件功能进行“筛选”、“拼装”和“组合”，尤其要打破各个 ISV 软件包之间的“墙”。

（三）：业务场景驱动的服务化IT架构规划

基本套路：1）快速地将客户知道的业务场景变成顾问自己的；2）基于业务场景推导出服务化 IT 架构（前中后台规划）。

快速地将客户知道的业务场景变成顾问自己的本质上就是要做好场景剖析的工作，而场景剖析的关键在于快速地利用一些有效的工具将客户对业务场景的非结构化表述变成结构化的咨询交付件。对于场景剖析而言，推荐采用 3PM 模型来做结构化描述（Purpose、Principle、Process、Method），我们可以将客户描述的场景转换成 3PM。

将客户描述的场景转换成 3PM 结构化表述，按照高效、人性化、个性化三种互动模式，通过 4A 集成方法系统性地考虑服务化 IT 架构对客户业务场景的有效支撑。

（四）：业务场景驱动的前中后台架构规划

“中台和后台（服务组织）支配的高效互动模式”下的业务场景驱动的服务化 IT 架构规划。

“信息化投入能够帮助客户提升人员单位产出”，因为信息化可以避免“人拉肩扛”式的业务运作，避免业务人员从事低价值的工作，能够让业务尽可能自动化、自运营、免人工干预。CIO 应该聚焦 IT 架构和以业务场景为中心的解决方案能力的提升，打造横向端到端业务高效协同、纵向前中后用户体验驱动的一体化 IT 应用服务平台，IT 团队的新阵型、新打法、新导向都应对准业务场景的 IT 解决方案所创造的价值。

IT 使能高效协同的业务场景：1）业务端到端协同场景驱动的中台规划，服务组织需要协调好环境、设施/设备、数据资源等，以满足前台和用户的交互；2）在中台构建的高效协同场景下，抽象出面向用户的交互场景，以用户体验驱动前台规划；3）单业务域场景可以看成是单个业务部门或单个系统的场景，由其驱动的后台规划作为资源和能力的来源供中台调用。

（五）：整体规划方法和业务场景驱动的端到端架构规划

在中台和后台（服务组织）支配的高效互动模式下，中台承担了更多的业务集成拉通的任务，中台也承载了端到端协同的业务模式，例如对于传统制造业来说，研发、交易和交付、生产供应、计划、采购、财务等业务集成的模式直接决定了前台的交互模式。换句话说，在这种情况下是由中台来决定前台的不同用户之间能够做些什么，由中台来决定如何调度资源、如何组织这些资源以及如何使用资源，前台用户更多地是围着中台构建的业务模式来进行互动。

整体规划方法：1）对客户业务场景的了解和分析；2）对客户业务场景的剖析；3）基于客户业务场景规划前台交互模式、中台协同模式和后台资源。

对客户业务场景的了解和分析可以通过调研和访谈等方式，充分获取客户对业务价值流、业务模式、业务场景的非结构化描述（自然语言），并辅助一些结构化分析手段进行总结和记录。对客户业务场景的剖析则是站在 IT 架构师的角度对业务场景所包含的关键要素进行进一步的细分和定义，可以通过信息链、EBIM 和应用集成关系对业务场景进行结构化剖析，识别业务活动之间的数据演进关系和应用之间的数据集成关系，以支撑业务端到端协同场景下的用户交互设计。

（六）：从端到端架构规划到领域级架构规划

端到端是业务运作视角，领域划分是业务管理视角，两者缺一不可。业务运作关注的是把事情做好，而业务管理关注的是把资源准备好、把能力建好以满足端到端业务运作的需求。

领域级架构规划的目的是要系统性地管理业务能力所包含的关键要素，包括：

1) BPA 中的流程要素：以流程目录的方式管理好各业务管理域中的标准流程、活动和任务；

2) IA 中的数据要素：以数据资产目录的方式管理好各业务管理域中的标准业务对象、数据实体和属性；

3) AA 中的应用要素：以应用功能目录的方式管理好各业务管理域中的标准应用和模块；

业务场景的剖析有两种方式，分别为端到端架构规划和领域级架构规划，其中，端到端架构规划是基于业务端到端协同场景的中台规划和基于用户交互场景的前台规划的重要输入，领域级架构规划是业务管理支配的后台资源、能力服务化的重要输入。

1） 对于业务场景驱动的架构规划来说，可以“自上而下”，先有业务集成场景来驱动端到端架构规划，进而按照业务领域划分分解为领域级架构规划；

2） 对于软件包驱动的架构规划来说，可以“自下而上”，先梳理单个业务领域对应的软件包的架构资产，进而将软件包架构资产集成起来并与业务场景相适配，形成端到端架构规划。

（七）：Design Thinking使能用户体验驱动的前台规划

中台和后台（服务组织）支配的高效互动模式，“优先考虑协同的效率，并满足用户一站式接入的期望”，其前台规划可分解为 4 个过程：

1） 运用 Design Thinking 方法，基于业务端到端高效协同场景，完成面向用户的交互场景设计；

2） 运用用户体验之旅（Journey Map）工具，对面向用户的交互场景进行剖析，识别并定义用户交互触点（Touch Point），参考用户体验标准（如 ROADS）识别用户交互体验的痛点和改进机会；

3） 按照一定的原则，识别用户交互触点需要调用的业务应用服务和数据服务，并作为对中台应用服务市场的需求；

4） 基于用户交互触点、需要调用的业务应用服务和数据服务组合成一站式 APP（轻应用），完成面向用户一站式服务的前台应用规划。

参考华为公司服务化 IT 架构的元模型 – V 模型，用户服务触点/业务活动和业务应用服务均应围绕业务对象来定义，均可视为针对业务对象的在不同上下文中（业务上下文、IT 上下文）的一系列动作/操作。

前台为了满足面向用户的交互需求（人机交互），需要中台调度资源并提供应用服务供前台调用，这就是“大中台，小前端”的理念，即前台是没有资源的，需要中台平衡前台交互需求与后台资源供给之间的关系。服务对象、前台、中台和后台的边界：

1）外部互动线用以划分服务对象行为和与服务对象互动的服务前台行为的边界。

2）服务可视线用于划分与服务对象互动的服务前台行为和调度资源以满足前台服务需求的服务中台行为的边界，一旦跨过服务可视线，服务对象就无感了。

3）内部互动线用于划分调度资源以满足前台服务需求的服务中台行为和后台资源准备行为的边界。

（八）：业务对象的内涵和建模方法

业务对象是业务领域重要的人、事、物，用来统一业务领域的重要业务概念，是业务人员之间以及业务人员与系统人员之间沟通的桥梁，是识别变革项目涉及的信息范围和关键信息的依据，明确信息定义和关联关系的基础。

对象属于物理数据设计的范畴，概念属于逻辑数据设计的范畴，我们通常所说的人事物，都有其物理性的一面，还有其逻辑性的一面。

物理数据设计针对的是对象，每一个对象都有其状态，而对象所属的类决定了对象可能存在的状态。对象可以抽象为变量，一组变量也称为实体，每个变量都会有其赋值，变量或实体所属的类型指定了赋值所要表达意思的集合，逻辑数据设计针对的是变量或实体。

从物理数据设计到逻辑数据设计，本质上是从对象的客观状态变化到逻辑变量或实体的主观意识变化，这种转变需要基于主体对客体到本体转变的约定。某种意义上，这个约定也是元数据的来由，即基于业务状态改变对相关变量的数据取值规则进行约定，以实现主体对客体对应本体的一致性认知。

概念模型、逻辑模型和物理模型是承接逻辑数据设计的，且其语境从 Outside the computer 转变为 Inside the computer。

1） 物理数据设计：以客体为中心，描述对象的状态变化，对象所属的类决定了对象可能存在的状态。

2） 逻辑数据设计：以本体为中心，对象可以抽象为变量，一组变量也称为实体，每个变量都会有其赋值，变量或实体所属的类型指定了赋值所要表达意思的集合。

从 Physical 和 Logical、Outside the computer 和 Inside the computer 两个方面 &四个象限明确业务对象的完整上下文定义。

（九）：识别业务对象的流程、方法和原则

识别业务对象可以大体上分成 5 个阶段：分析和识别业务对象、整理业务对象初稿、业务对象开发和验证、更新业务对象定义和描述、刷新业务对象。

在分析和识别业务对象阶段，可以有 4 种主要的工作模式：架构驱动模式、参考架构驱动模式、软件包驱动模式、业务需求驱动模式。自上而下和自下而上的业务对象分析和识别更多体现在组织方式的不同以及侧重点的不同，前者更加注重支撑业务战略目标的业务对象完整程度，后者则侧重于业务场景与业务对象的匹配度。

在整理业务对象初稿阶段，重点是梳理候选的业务对象，并对候选的业务对象进行初步的合并和抽象，以初步输出业务对象清单。人工完成这个过程的方式和机器学习一样，包括“分类”和“聚类”，或者也可称之为“有监督学习”和“无监督学习”。

在业务对象开发验证阶段，主要针对前一阶段输出的业务对象初稿，按照合规性、完整性、合理性、集成性等原则进行审核、验证、优化。

在更新业务对象定义和描述、刷新业务对象阶段，重点是要明确业务对象的业务责任人（Owner），由业务责任人来负责业务对象的演进、管理和发布，而这也与第七节中提到的基于业务对象定义的业务应用服务管理有着密切联系。

（十）：基于DDD的业务对象颗粒度定义

在实际识别和定义业务对象过程中，业务对象的颗粒度却是最难以确定“好”和“坏”标准，而这又会影响到以业务对象为宿主的业务应用服务的拆分颗粒度。拆分业务应用服务的目的都是为了实现业务对象的“高聚合、松耦合”，其本质是“业务对象的处理逻辑能更加集中”与“业务对象本身能更加分散”之间的矛盾，从业务视角来看，前者代表着集中管控类的诉求，后者代表着快速发展、构建、演进类的诉求。

对于集中管控来说，希望管辖范围内的每一个个体都是符合管控逻辑的，也即是对业务对象有很强的一致性要求，要求业务对象内部遵循统一的一致性原则。对于快速发展、构建、演进来说，则是希望可复用、去中心化和分布式，要求业务对象对外提供的服务尽可能单一、简单，彼此之间有很清晰的边界。这个本质上可以说是强一致性和柔性一致的矛盾，对于任何业务对象来说，都需要考虑到这两方面的诉求，相关要求可以参考数据库技术中的 ACID 和 BASE 策略。

对于 DDD 领域驱动设计（Domain-driven design）来说，最核心的就是要建立一个领域模型，通过定义对象之间清晰的所属关系和边界来实现领域模型的内聚，聚合定义了一组具有内聚关系的相关对象的集合。这种聚合间的边界本质上就是一致性边界，即聚合不可再分，否则就很难保证其业务强一致性要求；聚合也不可再合并，否则对聚合之间的弱一致性业务规则要求也会造成损害。如果将聚合作为领域模型中一个个较为独立的“高聚合”和“松耦合”业务对象的话，恰好能够在“业务集中管控”和“业务高可复用”之间取得平衡，将其作为对业务对象颗粒度定义的基本要求是非常合适的。

（十一）：协同、共享、自助、感知模式下的中台规划

华为全场景驱动的 4 种中台规划模式，包括“协同、共享、自助、感知”。

协同模式：服务组织支配的高效互动场景。对于传统行业而言，业务中台更加强调基于标准化流程的端到端高效协同，在此基础上通过前台给用户带来标准一致的服务体验。

共享模式：前台支配的人性化互动场景。对于共享经济而言，业务中台是一个个整合资源后形成的能力共享中心，前台通过对能力的组合、编排，快速重构并搭建一个个新的业务模式。

自助模式：用户支配的个性化互动场景。用户可以自助调取中台的能力来构建自己想要的前台，某种意义上是基于前台支配的人性化互动模式的更进一步发展。

感知模式：IoT 驱动环境感知场景。任何人都可以借助各种传感器、IoT 感知外部环境，获得环境反馈并作出相应改变，加快与现实世界间的信息流动。

（十二）：协同模式下的中台规划

协同模式下的中台规划，其最大的价值是要面向前台和用户提供业务协同服务，让数据多跑腿，让人少跑腿。

首先需要考虑的是协同业务流的设计。在前面的章节中介绍过端到端业务场景梳理和剖析的方法，协同业务流的设计则是要将业务场景集成起来，并进行适当的划分。

端到端的业务流视角看的是业务事件的演进，端到端数据流视角看的是各类数据的集成拉通。将业务流转换为数据流的过程中，重点需遵循的原则是“高聚合、松耦合”，业务流可以是发散的，但数据流一定得按照数据的定义进行收敛，不同的业务流对同一类数据的处理和传递应尽可能归一化，有益于数据的同源管控，避免数据不一致和 IT 重复建设。

基于“高聚合、松耦合”原则对业务流的数据流进行重构，支撑集成业务场景以及前台用户的交互场景。数据流的定义确定了中台的业务协同服务的颗粒度，通过对业务协同服务的灵活组合，可以支撑不同业务协同模式下的业务流。

业务协同服务可以包括 3 个部分的内容：

1、 提供数据流横向、纵向集成服务。数据流横向集成服务指的是单个数据流的不同业务对象之间的集成服务，数据流的纵向集成服务指的是不同数据流之间的集成服务。

2、 满足前台构建面向用户一站式 Portal 的业务应用服务需求。包括数据流横向、纵向集成服务，以及针对业务对象的各种处理和访问逻辑，可以将这些功能封装成业务应用服务，在统一的服务市场中注册、发布，并供前台用户订阅和调用。

3、 基于数据流的业务协同服务还需要调用共享模式下的中台提供的业务应用服务，这也可以作为业务协同服务的一个关键组成部分。

协同模式下的中台规划，本质上是由协同业务流驱动的数据流重构，以及基于数据流的业务应用服务规划，以满足业务集成拉通、前台用户一站式交互、对共享中心的调用等诉求。

（十三）：共享模式下的中台规划

共享模式下的业务中台是一个个整合资源后形成的能力共享中心，前台通过对能力的组合、编排，快速重构并搭建一个个新的业务模式。业务能力共享中心的重点在于业务能力、业务活动、业务数据的“被集成”。

共享模式下的业务中台提供的业务应用服务的复用性非常高，基本上任何一个前台的构建都不可避免的会用到中台提供的服务，这样也能有效避免公共服务的重复建设。

共享模式下的业务前台的自主性非常的高，前台通过集成中台提供的共享服务，可以快速构建面向用户的 APP，以支撑新商业模式的快速搭建和推广。不同的前台之间的交互是非常少的，前台业务之间并没有太多的协同诉求，前台更多地通过共享的中台服务来实现统一和畅通。

互联网企业将核心业务中公共的、通用的业务以服务的方式沉淀到共享业务事业部，整个集团的核心业务能力均建立在这样一套共享服务体系之上，这样就能发挥服务化架构的核心价值，即“服务重用”。对于传统企业来说，将现有的业务平台中可以统一共享的业务能力剥离出来，构建共享的业务中台，确实有利于传统企业新业务的快速构建和发展。

共享业务服务中台因其统一、共享、高复用性等特点，决定了共享服务的成熟是需要经过海量业务洗礼的，互联网企业的业务中台支撑的业务流量是非常巨大的，这也是为什么互联网企业普遍抛弃了传统的集中式或联邦式 SOA 架构，转而发展分布式微服务架构的根本原因。

共享服务的业务对象的特点基本上就是跨领域统一、共享和复用，包括基础数据、主数据、关键事务数据、原子指标数据、公共的非结构化数据、统一元数据。

在构建共享的业务中台时，除了考虑到基于跨领域统一、共享和复用的业务数据对象外，还包括相应的业务处理能力，因此可以说是数据+业务处理能力共同构成了业务应用服务核心要素，包括基于主数据、基础数据和关键事务数据等的公共业务服务和基础服务；基于公共办公数据（非结构化数据）的公共办公服务；基于统一元数据的公共数据服务。

共享模式的业务中台相对于协同模式的业务中台（平台）具有更好的业务灵活性和服务复用性，两者并非是“非此即彼”的关系，可以是不同业务阶段的选择，可以平滑演进，也可以同时存在互为补充。

（十四）：自助模式下的中台规划

在用户支配的个性化互动模式下，用户可以自助调取中台的能力来构建自己想要的前台，某种意义上是基于前台支配的人性化互动模式的更进一步发展。用户的体验用户自己说了算，就像自助分析厂商 Tableau 说的那样“自己做的报表才是体验最好的报表”。用户支配的个性化互动模式较常用于业务数据中台的规划和搭建，基于数据中台的自助数据分析和洞察是其典型应用。

业务中台支撑的是更好的业务运作，而数据中台则聚焦于通过数据洞察驱动业务变革，即在“掌握数据或信息”的基础上“获取洞察”，进而采取“行动”，优化决策策划以提升业务绩效。除此之外，还需要不断地“学习”，从每一次业务结果中获得反馈，改善基于信息的决策流程，从而实现“数字化转型”。

数据中台的内涵：数据产品的自动化生产线、供应链。

数据中台的外延：与传统“物”的供应链类似，数据供应链包含“原始数据产生->数据获取（采购）->数据存储（仓储）->数据增值加工->数据应用（消费）”全过程。数据中台基于数据供应链的相关能力，协调好环境、设施/设备、数据资源，给服务对象提供“可使用、可感知”的服务，与服务对象全程互动，满足不同服务对象差异化的探索数据并创造价值的需求。

（十五）：感知模式下的中台规划

在我们实际的服务化架构中，除了用户、前台、中台、后台之外，还应考虑到对服务环境的改造，使其更加有利于服务交互的过程。通过 IoT 使能的环境感知场景可以驱动“感知”模式的中台规划和构建，任何人都可以借助各种传感器、IoT 感知外部环境，获得环境反馈并作出相应改变，加快与现实世界间的信息流动。“感知”模式的中台可以面向用户或“协同、共享、自助”模式的中台提供“环境感知服务”。

环境感知服务的价值不外乎是线上线下或 AB 世界（Atomic & Bit World）的融合、让数据流动更快、更实时的决策以及分析能力前移到一线等，并最终消除 IT 和 OT 之间的数字鸿沟。

感知模式的中台，就是要消除 IT 和 OT 之间的数字鸿沟，需要具备以下 4 种能力并提供“环境感知服务”：

1、工业大数据的融合：工业大数据的融合服务是个业务服务而非技术服务，这需要大量的不同专业领域的业务知识作为输入，通过数据分析方法与工业机理知识的结合，打破“知识黑盒”的限制，对工业数据进行深度挖掘，方能提供更有价值的数据服务以满足工业大数据需求。

2、云计算和边缘计算的融合：站在用户的角度，用户的计算需求是完整的，面向用户的计算服务也应该是统一的，需要感知模式的中台整合云计算和边缘计算服务，面向用户需求提供统一的计算服务。

3、IT 和 OT 连接协议的融合：工业自动化市场上“一网到底的革命”就是将上层成熟度很高的商业以太网系统，直接接入到厂房设备的底层，但是距离实现统一的通讯协议与标准架构，还差得很远，因为这里面涉及大量的 IT 和 OT 连接协议的融合工作。

4、统一应用软件使能平台：工业互联网应用的使能平台 AEP（Application enable Platform）将 L1 到 L5 不同的软件功能模块统一到一个平台之上，并且轻松完成编译、封装和分发。

（十六）：中台的独特技术要求

构建 SaaS 层的前中后台特别需要关注的技术能力或服务包括：

1、 前台应用需要统一 UI 组件。

2、 中台需要统一服务管理，满足服务市场和服务编排的应用需求。

3、 SaaS 层协同、共享、自助、感知的业务中台和数据中台需要调用 PaaS 层技术中台的统一、通用技术服务。

Contract First Design，CFD 是一个很朴素的设计理念和方法，既然中台是以服务为中心满足业务协同、共享、自助、感知的需求，那么中台业务应用服务的管理模式就应该与通用的业务服务管理模式一致（与 GST 的管理模式很类似），即基于契约的服务设计与运营管理。各类业务应用服务的技术实现，本质上是利用通信技术，把计算机里面承载的 Bit 资源，完整地共享出去，给应用系统瘦身，减少重复投资。这里的 Bit 资源，包括用于记录业务状态的 Data 和用于描述业务处理逻辑的 Code，需要将 Data 和 Code 封装成消息 Message 再传输。服务供给和消费方要有明确的服务责任边界，并以契约化的方式约定好消息的标准格式，按照服务设计时和服务运营时的管理要求来协同。

我们在服务化技术架构和方案中经常提到的 RESTful、SOAP、RPC 等都可以视为按照 CFD 理念和方法形成的不同的服务风格，而 SOA、微服务则更多地属于不同的服务化软件架构。

“业务协同、共享、自助、感知的中台规划和建设，需要华为云平台的技术方案支撑”。

（十七）：中台实施路径规划

中台实施路径规划目的在于对准业务价值和发展方向，规划客户 IT2.0 架构驱动的业务前台、中台自主知识产权的 IT 产品路标及项目。

1、 首先需要站在 IT 视角，对准业务发展目标的业务场景中的 IT 使能的标准化业务场景，即可以通过 IT 支撑自运营的确定性业务场景，其执行流程和规则是标准化、规范化、结构化的，不需要太多的人工干预。

2、 IT 举措源自于业务痛点的 IT 变革需求，我们需要认识到，要解决一个业务痛点问题，单单只是 IT 变革是不够的，必须结合业务变革以形成完整的业务解决方案。

3、 IT 项目封装是业务痛点的 IT 变革需求以及 IT2.0 架构落地举措交叉汇聚的结果，一方面要对准业务发展目标的业务场景中的 IT 使能的标准化业务场景，解决具体的业务痛点问题，另一方面需要按照 IT2.0 服务化 IT 架构的要求，按照前中后台来设计并建设 IT 系统。

4、 最后，封装并定义好的中台实施项目，需要按照战略匹配度、问题紧急程度、依赖因素的成熟度、能及时感知的收益等角度评估其优先级，综合考虑并规划项目的实施路标，以及项目的投资匡算。

按照 SaaS、PaaS、IaaS 三层，加上运维和运营以及安全两个公共能力，划分整个架构落地举措，明确 IT2.0 架构落地需要做的事情有哪些。

1、 对于 SaaS 层来说，这是服务化 IT 架构落地的重点，包括了从传统的 IT1.0 时代的基于软件包的单体应用，向公司级前中后台演进的相关举措。

2、 对于 PaaS 层来说，重要的是支持 SaaS 层前中后台应用的实施，包括应用的开发时和运行时，尤其是要满足中台实施的特定技术要求。除此之外，通过对技术平台的服务化改造构建技术中台，支撑应用从“开发”走向“制作”，降低用户有效利用 IT 专业技术的门槛。

3、 对于 IaaS 层来说，主要是基础设施全面云化建设和管理，目的是为了实现更好的 IT 资源共享。

4、 对于两个公共能力来说，运维和运营、安全的落地举措更多的依赖于云化、服务化平台的整体方案，与中台的实施是松耦合的关系。

IT 项目封装是业务痛点的 IT 变革需求以及 IT2.0 架构落地举措交叉汇聚的结果，通过对 IT 使能业务场景的洞察，对齐 IT2.0 架构落地的举措，可以明确具体的阶段任务，进而明确各阶段性项目要达成的目标。最后按照多维度评估项目的优先级，综合考虑并规划项目的实施路标，以及项目的投资匡算，完成整个中台及中台相关的实施路径规划。

对于传统行业来说，企业中台的建设一定是业务自己的事情，没有哪家企业的中台是长得一摸一样的，因为中台建设的出发点就是帮助企业构建业务服务竞争优势，这一定是一个结合各家企业的业务实际特点，持续构建，持续优化，持续提升的过程。知易行难，行胜于言，只要对准业务价值，动起来了，持续优化，未来可期，一切皆有可能。

本文分享自华为云社区《IT2.0 业务中台规划牵引客户 IT 基础设施投资随想 （十八）：收尾篇》，原文作者：APTX-486977 。

点击关注，第一时间了解华为云新鲜技术~