传统企业数字化转型-从能力框架到方法论
今天对数字化转型方法论做了初步的思考。在前面我谈过多篇数字化转型方面的文章，其中提出了几个重点内容，在这里重新做下总结。
前期数字化转型内容总结
第一点就是数字化转型的三大核心内容，即连接，数据，智能。实际上后续很多数字化转型详细内容展开都是基于以上三个核心要素。
第二点给出了数字化转型发展的三个关键阶段，即从企业内部传统的信息化，到企业内部横向应用和纵向应用建设和集成；到围绕消费者触达能力的消费互联；再到以生态能力构建和整合为目标的产业互联网。
第三点就是数字化转型是一个涉及到整个企业战略，组织，业务，IT和技术，合作伙伴，数据，管控等多方面的一个全面转型和能力重构。数字化转型绝非传统IT部门能够单独推动的事情，基于这个思路给出了数字化转型能力框架。
为何要谈数字化转型方法论？
在我前面谈数字化转型的时候，更多是基于远行科技和团队大集团信息化规划，SOA和云技术平台建设等实践过程的一些总结和思考。这些总结偏核心要素和能力框架层面，也就是说偏数字化转型的静态架构内容。
但是一个企业基于企业战略和业务目标，包括如何结合当前遗留的IT基础架构和应用系统，在遵循一种科学的方法步骤的情况下来完成快速的转型的迭代，即这种动态方法论层面的思考没有系统化。
方法论的核心是流程，即你需要遵循哪几个大阶段，每个阶段又有哪些大步骤一步步地来做这个事情。同时又基于每个阶段，步骤给出具体的组织和团队支撑，方法，工具，知识包，业界最佳实践等作为重要参考。
对于数字化转型的大框架，大方法论，我自己本身也还在不断学习和整理阶段。
因此今年的重点是对已有知识和实践积累，结合业界大的咨询公司，大集团企业等案例等进一步抽象和整理为方法论，形成完整的知识体系。
方法论是否一定指导落地？
就数字化转型这件事情来说极其复杂，涉及到企业组织，业务，技术方方面面的内容。对于传统企业和互联网企业本身差别就很大。同时传统企业里面不同的行业类型，比如制造类企业，电信电网重资产运营类企业，面向C端消费者的快消类企业，金融行业等本身又差别很大。即使同样都是制造行业，可能各个企业本身的IT建设和信息化基础不同，导致数字化转型方法和行动路线上也存在很大的差异。
这也是我在前面没去思考方法论的原因。
即方法论要做到一种普遍使用性，那么就牺牲了针对性，越是抽象你会发现越对你实际遇到的问题没有多少用。但是思考方法论有一个很重要的好处就是真正将一件事情从道理，原理，内部机制和关系等都想明白，形成一个完整的整体。
你可以基于这个方法论去具体应用落地，在落地的过程中不断完善和补充，形成面向不同行业，不同IT成熟度企业的最佳实践。
从华为数字化转型方法论说起
如果你用数字化转型方法论搜索，很容易搜索到一个材料，即华为在2019年发布的行业数字化转型方法论白皮书。
这个白皮书华为官方网站有下载，不再给出地址。
首先我们看下白皮书前面部分内容，关键还是在谈数字化转型必须是企业核心战略驱动，是一把手工程，需要的是组织和文化的变革，需要业务和技术的高度协同和融合，
从企业整体数字化转型战略出发，给出了业务+技术融合，平台赋能，生态落地三大关键内容。后续方法论基本也是基于这个内容展开。
实际上整体体现动态方法论的内容仍然是在数字化转型顶层设计这块的描述。对于顶层设计本身又为了价值发现，蓝图设计，路径规划三个阶段。
这个内容大家看到就会比较熟悉，即和我们传统的企业架构，信息化规划有很多类似之处。特别是蓝图设计本身就用的是企业架构的标准图。而对于业务价值发现本身更多又是对当前业务现状的梳理，差距的分析，和业务目标和匹配等。
同时平台赋能部分给出了企业数字化转型需要有一个支撑平台，这个支撑平台不仅仅是技术支撑，也包括了共性业务能力支撑。通过支撑平台来为上层应用开发和交付赋能。该平台需要体现六大关键特征，如下：
应用场景化：根据不同的业务场景提供个性化的应用功能，满足不同角色对象在组织经营/运营活动中所需的、随时随地接入使用数字化系统的需要，丰富业务场景，提升用户体验。
能力服务化：业务能力共性提取，形成数字化服务接口；业务流程灵活编排，支持业务敏捷与创新。
数据融合化：全量数据采集汇聚、全域数据融合、全维数据智能分析，洞察业务内在规律，提供决策支持。
技术组件化：以组件化框架承载，按需引入大数据、物联网、视频智能分析和AR/VR等新技术，技术架构易扩展、技术元素易集成、技术能力易调用。
资源共享化：智能终端、网络连接和计算/存储资源的云化，使之共享复用，实现资源的弹性、高效管理。同时给出一个关键点平台化参考架构如下：
这部分内容实际上有两个关键点，即垂直业务场景启动快速实现业务价值，其次是基于平台+应有，能力服务化方式构建应用。这两个点实际上在前面我自己谈数字化转型关键点和发展趋势的时候都提及到了。
但是本白皮书并没有对其顶层的方法论进一步展开，也就是说价值发现，蓝图设计，架构规划这些事情究竟应该如何展开去做。是不是还是传统的企业架构规划那套内容？或者你可以说是不是还是以企业架构规划思想来指导当前的数字化转型规划和设计？
个人认为如果你还是按这个思路来思考数字化转型方法论，那么一定是错误的。包括我自己，我在前面也在谈在新的数字化转型，新的微服务下，对传统的企业架构方法的优化和改进等内容。
但是数字化转型需要的方法论不是对传统方法论的改进和优化，而是更大的变革。
为何会带来这个大变革？
传统的企业架构规划更多考虑的是业务驱动IT这个思路，即IT始终是一个配合的角色；其次就是强调数据建模和产生是晚于业务的，即数据只能处于后期配合而非数据驱动。其次，传统的企业架构思想，实际对平台化+服务化体现得相当弱，包括我很早就基于SOA+云的思想对这部分进行了优化，但是不完整。
再次，传统的企业架构一个大问题就是大而全，这和当前大多企业需要的敏捷性，快速找到业务价值项目并持续迭代的核心思路也出现了冲突。
所有这些都让我们得重新思考对传统架构规划方法进行变革而非简单优化。
数字化转型方法论框架
对于数字化转型方法论框架，需要更多地体现动态方面的内容，因此对前面我给出的数字化转型能力框架进行调整，给出如下框架图：
这个图可以高度总结为以下四点方便记忆。
1个技术平台：围绕云原生，5G，数字孪生，物联网的核心技术支撑平台
2大中心：业务能力共享中心和数据能力开放中心
3大阶段：包括内部信息化阶段，消费互联阶段，产业互联阶段
4大场景：传统业务价值链整合，智能制造，数字化影响，数据驱动运营简单来讲整体的方法论框架重点仍然是平台化，服务化，场景化三个核心要点。而要实现这三点，仍然是基于连接，数据，赋能三大核心目标和要求展开。
为何这样说？
比如我们要构建一个新应用或驱动一个新的业务模式，新的架构你需要考虑的是平台层能力如何支撑，基于平台快速的构建你需要的应用满足场景。这个思维模式和传统构建新应用，从需求，设计，开发测试，上线思路是有巨大区别的。
再比如你在做内部信息化阶段，在解决横向供应链和纵向生产制造集成阶段，你也需要考虑如何解决连接问题，解决数据为业务赋能问题，解决当前数据的采集处理和大数据分析问题。所以连接，数据，智能三大要素，无论你在哪个阶段你都需要随时去考虑回答这三个方面的问题。
没有解决连接问题，就谈不上数据，没有数据就更谈不上智能。场景驱动下业务目标，业务问题的解决，你可以看到本质还是解决这三个方面的问题。
数字化转型方法论
德勤数字化转型五阶段
对于数字化转型方法论，实际我在前面文章谈数字化转型能力框架的时候分析过类似德勤，埃森哲，毕马威等各个大的咨询公司的数字化转型方法论。
但是整体来说，仍然是偏宏观和静态，而确实动态呈现，确实具体落地实现步骤。其核心一个原因我在前面也提到，如果方法论实操性太强，那么其抽象和通用性就更弱，这里面有一个如化均衡的问题需要解决。
但是即使这样，方法论层面也需要将核心的原理和步骤讲明白。只有核心原理和步骤讲明白后，你才能够在后续落地实践过程中逐步去调整和优化，持续改进你的方法论。
我们举一个简单的例子来说。
方法论层面不能只谈要进行微服务化，而是需要给出如何微服务化，即基于当前业务需求，业务应用的构建，你如何去拆分微服务，定义微服务API接口，并实现API能力组合满足业务，这个过程你必须要讲明白和透彻。
今天只谈数字化转型方法论的核心思路，后续在进一步细化和整理。因为整个形成完整方法论框架体系的过程也是不断学生思考的过程，需要实践来验证。
1.企业战略和愿景
实际上你会看到很多企业根本就提不出明确的战略和愿景，这就导致了看着别人做信息化你也要做信息化，看别人做数字化转型你也要转型的情况。
如果提不出战略愿景，那就说明无法跳出盒子，打破传统边界，站在一个旁观者的角度重新来看待和审视企业的业务，企业的核心价值。
如果提不出来，实际应该是走出去，多去看别人怎么做的，多去下一线客户和下沉市场调研下情况，多思考下国家宏观战略和政策发展趋势等。
比如类似国家的数字经济，数字化转型大指导思想等都是必须了解内容。
战略愿景=》关键垂直可落地场景
这个分解才是关键，战略要快速落地，必须找到关键可落地的垂直场景。如果你的战略是啥都想做，往往是啥都做不好。
这个场景可以是实现对客户的全触达能力可以是敏捷交付效率提升多少，也可以是类似内部横向业务和纵向业务的全打通，基于能力平台构建产业生态等。
所有场景都必须要垂直，要可落地。
当前大部分企业实际上都是有了业务和技术IT方面的基础积累，因此不再是做从0到1的大而全规划和建设，而是要考虑基于场景驱动如何快速构建应用满足新的商业模式。
2.现状调研和差距分析
如果你是找咨询公司来帮你做数字化转型，一定会涉及到大而全的业务和IT的现状调研。但是如果是企业自己主导的数字化转型，那么企业自身人员完全是清楚自身的业务和IT现状的，也没有必要再去做大而全的业务和IT调研。
那么这个时候的调研实际是回答当前的业务链是否能够支撑新垂直场景业务需求。如果不能支撑，那么差距在哪里，哪些能力可复用，哪些要完善和新增。
其次是需要思考你当前的内部技术和IT能力是否支持你的业务场景或业务链，在这个支撑过程中哪些能力可复用，还存在哪些差距需要完善。
简单来说：
这步的重点是差距分析，而差距分析不是完全抛弃已有的业务和IT能力，而是基于场景驱动的思路来分析你当前的业务和IT能力成熟度或满足度。
3.目标架构规划
在构建目标架构前，希望强调下，不是对原有能力全部推翻，而是进行重构。在面对消费互联和产业互联的时候，原有能力应该下沉为后台支撑能力。并根据关键业务场景梳理和新的模式来构建前台应用和能力。
每一个独立的场景都可以是一个独立的前端应用，但是共享底层平台层能力。
这个平台层能力既包括了基于云原生为核心的技术平台能力，也包括了围绕业务能力中心和数据能力中心的业务平台能力。
基于SOA思路进行目标架构规划
在这里又回到了SOA的思路，即前面分析了关键垂直业务场景，那么这里就需要进一步分析这个场景如何去构建？
在构建这个能力的时候哪些应该放在前台层面，哪些应该复用平台层已有的共性服务能力来进行组合和组装。通过这个分析，核心是梳理清楚底层平台组件+微服务业务中心+前端场景化应用的三层架构模式。
在这个规划中重点就是思考清楚如何满足业务场景。
先将你希望构建的应用当做一个黑盒进行思考，考虑和外围客户，合作伙伴间的交互关系，理清黑盒应该北向暴露提供的接口。这黑盒的这些北向接口实际是内部后台支撑平台提供的。
第二层梳理的是后台支撑层如何提供这些能力？ 需要如何识别和定义这些API接口。
简单总结下就是构建一个新应用满足新垂直场景架构规划重点：
这个应用本书提供哪些核心Feature
应用如何和外围交互协同，满足核心业务场景
这个应用需要后台支撑提供哪些可复用API能力
4.详细方案设计
在前面整体目标架构梳理清楚后，就过渡到详细方案设计阶段，在这个阶段你需要回答一个关键问题，就是如何去构建这个应用。
你需要做详细的业务功能架构和应用架构设计，同时应用架构本身也是微服务化的，因此应用本身也按业务场景-》如何基于服务能力组合提供。
这个服务能力既包括接入的后台能力，也包括在应用中你需要新构建的服务能力。
在核心流程贯通后再进行详细的需求和关键业务规则逻辑的梳理。
数据架构和数据模型仍然是必须的，在这里实际上有两个关键思路。
1.基于运营类场景实际是数据驱动的，先数据后业务
2.基于传统业务流程实现的场景，是基于流程识别数据
另外要利用好数据这条线。数据驱动业务变革，数据可以驱动新的商业模式。传统规划和建设数据都处于后期成果，那么在当前新的架构思想下能否形成：垂直业务场景和目标=》需要哪些数据-》业务如何去形成这些数据。这个分析思路，是一个需要思考的问题。
包括技术驱动也是同样的道理，原来谈的都是业务驱动IT，但是新的数字化时代IT本身是可以驱动业务发展的，即很多新的业务模式本身80%就是围绕一个IT应用展开的，是新的技术产生了某种新模式。比如前段时间谈到的RPA机器人，你完全就可以从技术层面思考RPA能够引入哪些新的有价值的商业模式和业务场景实现等。
5.落地实施计划
基于垂直场景驱动核心就是可落地，能够快速地制定落地实施计划。
这里面就包括了团队组建，对于大型业务场景的实现可能还涉及到大的组织变革和调整等。在团队组建后做好人员角色分配，制定敏捷过程管理机制等。
其次就是技术框架的选择，详细的研发进度和迭代计划等。
计划的一个核心就是可迭代，能够快速地进行短周期迭代，并在迭代的过程中不断地自我调整和优化。而不是一开始就去搞大而全。
对于大部分企业来说数字化转型这个事业界都没有标准答案，只有指导思想和方法原则，因此需要的是你自己去快速的实践，去试错，并不断的纠正自己的过程方法。
数字化转型方法论整体框架回顾
在前面我给出了数字化转型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.建设实施
基于垂直场景驱动核心就是可落地，能够快速地制定落地实施计划。因此从大应用的产品规划，还需要根据需求优先级分解为多个项目迭代版本计划，采用敏捷开发的思路进行迭代开发和版本演进。
这里面还包括了团队组建，对于大型业务场景的实现可能还涉及到大的组织变革和调整等。在团队组建后做好人员角色分配，制定敏捷过程管理机制等。
其次就是技术框架的选择，详细的研发进度和迭代计划等。
计划的一个核心就是可迭代，能够快速地进行短周期迭代，并在迭代的过程中不断地自我调整和优化。而不是一开始就去搞大而全。
文章被以下专栏收录
