今天来整理关于数字化转型方法论层面的第二篇，这篇文章重点思考基于垂直场景驱动下的规划建设方法论，也就是说把宏观的方法论进一步基于场景驱动，业务价值驱动进行聚焦，给出一些可以去实践和落地的方法逻辑思考。

数字化转型方法论整体框架回顾

在上篇文章我给出了数字化转型1234整体方法论框架，即1大技术平台，2大业务能力中心，3大阶段，4大业务场景。具体展开如下：

1个技术平台：围绕云原生，5G，数字孪生，物联网的核心技术支撑平台
2大中心：业务能力共享中心和数据能力开放中心
3大阶段：包括内部信息化阶段，消费互联阶段，产业互联阶段
4大场景：传统业务价值链整合，智能制造，数字化影响，数据驱动运营

简单来讲整体的方法论框架重点仍然是平台化，服务化，场景化三个核心要点。而要实现这三点，仍然是基于连接，数据，赋能三大核心目标和要求展开。

在这个方法论框架里面我提到了内部信息化，消费互联，产业互联三个阶段。但是这个是一个企业数字化转型的发展阶段和成熟度演进过程，并不是指企业数字化转型具体的规划建设阶段和方法步骤。

简单来说，如何谈到基于数字化转型中的业务重构和IT建设来说，仍然会遵循传统的目标确定，需求和差距分析，架构设计，落地实施等关键的阶段和步骤。

同时在新的数字化转型过程中，平台化，服务化，平台+应用构建模式已经成为一个大的发展趋势，这个对传统IT规划建设相关方法论导致了大的变革，这些都需要在新的规划建设方法论中进行重新思考。

指导思想：SOA+云计算

在我上篇文章中实际谈了一个关键的一点，即基于垂直场景驱动和切入，基于企业当前业务和IT已有能力，基于迭代化的思路来快速的交付新的应用满足新场景，实现业务价值。

因此指导数字化转型的方法论，SOA和云的思想又重新回到一个关键点。

云的思想是集中化，但是SOA的思想是如何找到遗留业务和IT资产并高效复用，两者充分结合来构建一个共性平台层，才可能实现平台化+服务化。

对于SOA和云的思想，平台+应用的思想，实际早在2012年远行科技做联通集团私有云PaaS平台大项目的时候就在使用，远行是做为ESB企业服务总线集成商和整体产品集成负责人参与了该项目。该大项目超过10个以上的软件服务商参与，集中办公人员就上1000人，现在差不多10年过去了，但是当时谈到的大业务系统彻底的组件化和服务化，去IOE，构建应用托管+共性技术服务能力+共享业务服务能力的厚PaaS平台，这些思想即使到现在也具备足够的参考价值。

去年我初步的《SOA与大数据实战：企业私有云平台规划和建设》这本书，写作背景就是基于当时大项目建设实践，书的参考简介如下：

本书主要结合作者多年对企业信息化规划、SOA、大数据以及云计算等方面的技术研究以及平台建设实践，以“平台+应用”和SOA服务化核心理念为指导思想，围绕如何降低企业IT建设成本、提升IT资源利用率、打破企业烟囱式系统建设模式、提升系统建设规范等核心诉求，主要阐述了企业私有云平台建设的总体框架、平台规划、架构设计、平台治理管控等核心内容。同时基于国内大型企业一线项目实践，总结提炼了企业私有云平台建设的核心方法论、标准规范和建设流程，为企业进行私有云平台建设提供可借鉴、可参考的一整套指导方法与思路。

感兴趣的可以自己前往当当或京东购买。

指导思想：企业架构

SOA的核心思想是横向分层和解耦，在首先满足解耦的要求下实现共享，协同和复用。一个完整的业务系统被拆分了应用，服务和资源层能力三个方面的内容。资源层的能力最终以粗粒度的服务方式暴露出来，应用层的构建需要大部分的借助于共享服务层抽取和接入的各种服务能力。

企业架构核心仍然是业务和IT的融合，业务驱动IT，即以端到端流程驱动入手，通过逐层的流程分解最终确定各种业务活动单元，各个业务活动单元按照高内聚松耦合的指导原则来确定大的业务域和业务组件。

业务能力的微服务化和组件化，组件能力API接口化是一个核心，那么初步的业务架构和业务组件规划完成后，后续重要的事情就是组件向外暴露的能力服务如何识别？同时需要在业务架构层面增加一个跨业务域或业务组件的组件交互协同分析，既需要分析完成一个端到端流程的时候这些业务组件应该如何交付，这些具体的交互点将成为潜在的服务识别点。

在业务架构完成后进行数据架构规划和设计，数据架构规划的一个重点即是SID共享数据，包括了主数据和共享动态数据，可通过各种功能和数据的矩阵分析方法来找到相应的SID共享数据。在业务流程建模和分析中，可以看到有两类数据，一种是衔接某个业务活动输入和输出的数据，一种是该业务活动需要依托的底层数据，往往业务活动依托的底层数据很多都可以纳入到SID共享数据中。数据架构规划和分析最终是识别和形成各种数据服务能力的提供。

传统企业架构规划并没有考虑太多云计算和平台层规划内容，当思考企业架构和云计算的融合思路时，在进行应用架构和技术架构分析的时候，需要考虑平台层云化能力的抽取，包括了IaaS平台和PaaS平台。其中对于PaaS平台层则需要考虑各种共性的技术组件和组件化服务能力的抽取，形成各种技术服务。

以上几个部分完成后，结合在应用架构规划中的应用集成架构规划可以进一步分析和识别服务，形成完整的服务架构和服务目录。服务架构是在企业架构规划中必须增加的一个内容，这也将直接影响到我们应用架构构建可转化为“资源+服务+应用”的模式。

服务层在里面起到关键的解耦作用。

基础的服务架构规划和服务目录库出来后，业务架构中的业务域可能已经转化为我们应用架构规划中的技术组件，数据组件和业务组件。这些已经是技术层面的概念，当然业务流程也进一步映射到系统层面需要实现的系统流程，那么还得再做一次流程分析，分析在流程执行过程中需要调用到哪些业务组件或技术组件的服务能力，是否存在服务识别遗漏和缺失。这步完成后，基本能够保证前期分析和识别的服务是能够满足服务组装和流程编排所需。

垂直场景驱动的应用规划和建设

在前面谈到过，这里不谈大方法论，而谈偏落地实践层面的小方法论。这个方法论有个前提就是企业在传统业务和传统IT架构下，如何更好地去做数字化转型，如何基于垂直业务场景快速的构建业务和IT应用，来满足场景需求，实现业务目标。

企业的数字化转型不应该是全部推倒重来，而是应该更加清楚地认识自己的能力，并基于能力进行重构和整合。

如果是全新的公司，全新的业务和IT建设，那么还是需求走完整的数字化规划，IT建设规划和整体架构设计。但是对于已有IT基础公司，需要考虑的是组织级别业务和IT资产的复用，考虑的是如何敏捷地去相应业务场景的述求。

因此，基于以上思考，垂直场景驱动下的应用规划建设方法论如下：

该图还有诸多不成熟的地方，后续会进一步完善。

即整个构图核心还是要遵循SOA，平台+应用的思想，同时借鉴传统企业架构规划方法，以垂直业务场景驱动的思路来快速的完成应用的规划，迭代建设和交付过程。

传统企业数字化转型方法论不应该是彻底对已有业务和IT推倒从来，不是从0到1，而是应该充分对已有业务和IT能力进行评估，将已有能力下沉为平台层能力，同时重新规划和建设上层应用能力。

基于上图的五个阶段，在这里先做一个初步说明如下：

1.启动计划

在这里有相当多的准备工作，其中包括了对企业已有的业务和IT资产的初步梳理，即你首先要搞清楚你当前已经具备了哪些能力。这个梳理本身又不是传统企业架构和信息化规划中的全面业务和IT调研，这个过程太重，周期太长。这个梳理核心个人认为重点仍然是粗粒度的业务单元和业务能力。

同时企业要进行数字化转型，在前期先开展数字经济，数字化转型基础框架，消费和产业互联，国家十四五规划，工业互联和智能制造，云计算和5G，数字孪生技术等新知识和技术的学习是必要的。当前其中也包括了对业界，对同类已经完成数字化转型企业的最佳实践和案例的学习等。

其次，我们希望在启动阶段搞清楚企业数字化转型的战略愿景，但是这个战略愿景不能太虚，必须要可落地。

如何落地？

即将战略愿景分解为诸多个关键垂直业务场景，每个业务场景之间松耦合，可以独立实现和交付。当然如果从大的产品规划角度来谈，这里面还是涉及到类似IPD集成产品研发里面的组合管理等方法使用，在此略过。

简单来讲计划启动阶段先确定可落地的垂直业务场景。

2.场景分析

场景分析简单来说包括了三个关键活动。

其一是基于关键场景来分析，这个场景具体实现的业务流程，即分析清楚经过什么样的业务流程，哪些关键业务活动或操作能够实现这个场景。其二是在第一步的基础上来思考分解出来的关键业务活动哪些是已有的业务能够支撑的，哪些是需要补充的。其三是对于支撑的业务，哪些是IT和技术层面已经支撑的，哪些是欠缺的需要补充的。

三者是从场景和流程驱动，逐步分解，从业务到技术的一个过程。

核心仍然是搞清楚当前能力和目标场景实现的差距。而差距分析不是完全抛弃已有的业务和IT能力，而是基于场景驱动的思路来分析你当前的业务和IT能力成熟度或满足度。

3.业务建模

注意在这里的业务建模核心是基于SOA架构思想的，是接口驱动的。

简单来说一个核心的业务场景和流程的实现，通过流程或业务建模已经分解为了关键的业务活动或操作，那么这里思考的就是这些业务功能点的实现需要哪些API接口能力来支撑。

API能力通过组合或组装完成了整个场景。

其次在能力识别完成后，还需要进行详细的能力梳理，这个能力梳理实际上包括了两个关键内容，其一是对于接口能力进行初步的定义，这个定义既包括了功能操作，也包括了详细的业务对象模型。其二是需要梳理构建场景需要的这些API能力，哪些是当前业务和技术能够提供的，即可以复用的能力；哪些是需要新增的能力。

业务建模阶段重点是搞清整个业务场景实现和外部的关系，即业务内部的一些逻辑可能并没有做到完全梳理和细化，但是业务场景和外部业务和技术的交互必须思考清楚。

这个类似我们在SOA架构规划，需求建模中谈的边界分析。

4.技术建模

技术建模一个是参考SOA的思路，一个是参考领域建模的思路，但是不能完全照搬领域建模的思路，否则太重。技术建模的时候重点已经会将我们需要实现的业务场景或流程规划一个新应用，来思考这个应用如何构建。

即这个应用本身就实现了一个端到端的流程和场景。

这个应用你可以理解为前台的能力，同时这个应用的构建本身也是微服务化的，可以拆分为多个不同的微服务进行构建，各个微服务本身提供API接口能力去组合和协同，完成一个关键垂直业务场景。

即这里的重点是基于领域建模，微服务设计思路来进行应用架构的设计。这个设计不仅仅是应用实现的业务功能设计，更加重要的两点是：

其一应用本身涉及到的私有数据库，数据对象和模型的设计。

其二是应用本身需要复用的底层业务平台和技术平台接口设计。这些接口有些可能是已经存在和发布的可复用API接口，也可能是本次新场景实现，需要进一步让后端业务系统新开发的API接口。简单来说就是新应用构建要搞清楚你自己要实现哪些功能，你需要委托后端的业务平台实现哪些功能。

当然在应用实现过程中还涉及到底层共性技术支撑，即应用构建需要使用底层技术平台共性能力来构建，比如当前主流谈到的云原生技术平台。

5.建设实施

基于垂直场景驱动核心就是可落地，能够快速地制定落地实施计划。因此从大应用的产品规划，还需要根据需求优先级分解为多个项目迭代版本计划，采用敏捷开发的思路进行迭代开发和版本演进。

这里面还包括了团队组建，对于大型业务场景的实现可能还涉及到大的组织变革和调整等。在团队组建后做好人员角色分配，制定敏捷过程管理机制等。

其次就是技术框架的选择，详细的研发进度和迭代计划等。

计划的一个核心就是可迭代，能够快速地进行短周期迭代，并在迭代的过程中不断地自我调整和优化。而不是一开始就去搞大而全。