对数字化转型，整体来看大部分人相对关心问题主要还是集中在以下两个方面。

企业传统的IT架构如何如何微服务改造，演进发展

企业传统IT如何全面上云和实施云原生

以上两点实际都包括一个关键点，即企业当前内部已经存在一个遗留的IT应用和架构环境，而不是一片空白，当前的IT能够支撑业务运作，但是用的是传统IT建设和架构模式。需要考虑如何对IT架构进行改造优化，包括如何形成能够逐步迁移上云服务的能力。

其次，以上两个事情本身又不是单纯的技术驱动的，而是围绕企业整体业务和IT战略，数字化转型目标驱动的。正如我们常说到的：

企业业务战略和数字化转型推动了IT本身的改造和演进

在其一数字化转型过程中，IT需要更加敏捷，更加快速地响应最终的业务需求，特别是toC的行业更是如此，同时整个IT在支撑业务过程中，对整个高可用性，高性能，高弹性扩展，高安全性等的要求也是越来越高。

而这些才是推广传统IT架构改造优化，IT上云的一些关键点。

数字化转型能力框架

可以看到，数字化转型核心仍然是围绕连接，数据，智能三要素的业务价值链构建。对于连接解决基本的业务链协同问题，通过连接下的业务协同形成数据沉淀，通过数据的存储处理，管控治理形成数据服务能力反哺业务。同时数据持续积累又进一步为机器学习，深度学习等智能化分析应用提供服务。

我在前面也给出过一个完整的数字化转型能力框架如下：

在整个框架中实际上包括了组织支撑，技术支撑，核心业务价值链和运营支撑四部分关键内容。如果企业不去思考其核心业务价值链的改造和优化，而是马上去考虑技术支撑平台建设，那么显然就是舍本逐末了。

对于这四个部分内容，具体展开主要包括了：

1.组织支撑

1.1 组织和业务重构

1.2 团队和人员管理

1.3 敏捷和数据驱动文化

2.技术支撑

2.1 底层技术支撑(物联网，云原生）

2.2 数据中台建设

2.3 平台能力开放

3.核心业务价值链

3.1 连接-数据-智能

3.2 从消费互联到产业互联

3.3 产品价值和客户体验

4 运营支撑

4.1 数据驱动运营

4.2 自动化到智能化

IT反向推动业务

最早谈得最多的是市场驱动研发，业务驱动IT。但是你会看到在数字化时代往往变化为了IT反向推动业务流程改进，业务战略目标达成等。

当前类似人工智能，物联网，智能制造，数字化，人工智能，消费互联和产业互联各种新的概念和技术不断发展。这些概念本身的发展就对传统企业传统的生产制造，市场营销等造成了巨大的影响。比如传统市场营销方法往往已经跟不上节奏，现在谈的多是数字化影响，谈的企业自媒体和品牌打造，谈的公域流量如何引流为你自己的私域流量等。

而这些内容由于涉及到新技术和IT等，传统的业务部门和业务人员往往难以深入去思考如何去优化改进业务，如何去应用。

相反，企业的CIO往往具备这种引导能力，特别是那些有IT和技术背景，同时又熟悉企业内部业务和核心价值链的CIO，往往不再是单纯的建设IT支撑业务，而变化为了如何构建IT来推动业务发展。这个趋势发展下，IT往往也不再是单纯的成本单位，而可能变化为利润单位。

企业CIO要意识到，虽然新技术很重要，但是新技术下产生的新的业务和商业逻辑更加重要，只要对新的业务模式清楚了解后，往往才能够更加清晰的认识新技术和架构。

比如，CIO给公司的CEO汇报，明年准备立项一个项目进行当前IT系统的微服务化改造，这就是典型的技术思维和技术词语，这种汇报估计很难有企业老总能够批准。其次，可能CIO自己也没有想明白为何要做架构改造，为何要上云？

消费互联和产业互联

在我前面文章谈到过，企业数字化转型实际首先需要解决从信息化到数字化的过程，这个数字化首先要打通企业内部价值链的横向集成和纵向集成。

• 横向集成往往围绕供应链，财务的核心端到端业务
• 纵向集成围绕研发，生产，制造业务

在整个内部IT构建和集成过程中，往往还涉及到物联网技术，人工智能，自动化，机器人等技术的应用。重点是要实现通过各种技术，减少人工的输入输出，导入导出，通过人录入来产生信息并进行信息流转，而应该是通过人和物连接，物和物的连接来实现信息的自动产生和流转。

对于前面谈到的这两点，至少会涉及到企业内部类似ERP(横向核心），MES（纵向核心）两个核心系统的建设，当然围绕着两个核心还有大量的业务系统构建。简单来说就是业务流程和运作完全能够通过IT来自动化支撑。即使如此，大部分企业连上面这两点都无法做到，内部的IT能力成熟度完全不够。

而数字化转型当前实际上有两个方向。其一是围绕消费互联网和数字化影响的方向，其二是围绕产业互联网的方向。

在消费互联层，很多toC的企业都在考虑如何更好地进行数字化营销，流量经营，如何构建自己的自媒体平台，或者自己的电商能力整合平台，如何通过运营特别是数据运营来推动整个业务的发展。而在产业互联网层面，更多的是则是考虑如何突破企业内部边界，通过能力开放的方式，实现产业上下游链路的整合。

不论是哪种方式都可以看到，实际重点在于如何突破企业传统边界，以能力开放和协同的方式来实现和外部的协同和交互，实现资源的进一步整合，实现对用户的直接触达能力等。

但是当你突破企业边界，朝外拓展的时候，最关键的还是你内部能力足够成熟或者至少有了完整的积累才可以。入境讲内圣外王，先修身齐家，最后才是平天下。内部能力不足够，迫切地去快速朝外拓展，往往对很多企业又是灾难。

也就是说，一个企业你连基本的内部信息化，横向和纵向业务集成都没有做好，就去追热点，搞什么数字化转型，搞数字化营销，那么绝对是舍本逐末。

当前很多做数字化转型的咨询服务商，中台咨询和建设的厂商，给客户画的饼太多，忽悠的东西太多，发现最终自己规划的东西都无法在企业落地，建设的中台无法真正用起来，或者说建设完后业务敏捷性能力反而比原来还糟糕，系统也更加难以运维和管控。

以上都是典型的问题，并不是说SOA不好，云原生不好，或者中台思想不好，而是你的企业没有在最适当的阶段，去做最适合企业业务目标和发展该做的事情。

比如对企业的业务和IT当前现状分析后，本身应该是构建一个SOA共享服务平台来解决业务协同问题并提供对外能力开放接口就可以的，你却理想的去大搞智慧中台建设。

企业IT建设从来都不容易，本身也是一个循序渐进的过程。

企业CIO重点从来都不是技术先进性和热点，而是对企业本身业务架构模型的理解，并且根据企业的业务发展目标匹配当前最合适的技术能力。

当一个企业的内部IT真正能够从成本单元转变为利润单元的时候，那么整个IT对企业将带来的巨大的发展价值。从最早流程和IT部门的合并，到当前很多企业也在推动的业务战略+IT部门的合并，都能够看到整个IT融入企业整体业务，推动业务发展的大趋势。

企业传统IT架构转型的关键诉求

微服务架构这个概念出来已经有5年以上的时间，从最开始在互联网企业的广泛应用，到现在越来越多的企业开始关注和希望尝试使用微服务架构。对于企业从传统IT架构到微服务架构的转型，绝对不是盲目地跟风互联网企业，而是企业的业务规范，企业的信息化水平和IT成熟度发展到一定阶段后的实际需求驱动。

那么这些关键的诉求究竟有哪些？

从系统规划建设期到IT管控治理和运维期

首先可以看到当企业的信息化和IT系统建设发展到一定阶段后，自然会从IT系统的规划和建设期发展到后期的IT系统管控治理和运维期。到了后期不会再有大量的新系统规划建设，而更多的都是为了业务流程优化进行的IT系统需求变更，优化和功能改造。那么关键的问题就变成了如何快速地响应业务需求变化并发布系统，同时如何又以最小的代价和影响来发布系统？

传统的IT架构模式可以看到很难解决这个问题，每次需求或功能变更的发布周期相当长，同时由于是一个大单体应用全部发布，往往增加了一个新功能反而导致多个老功能出问题。这些都是我们经常遇到的问题，其核心的原因就是原来我们管理的业务系统本身的颗粒度太大了，其次就是从需求到开发到测试到发布整个过程如何自动化衔接。第一点涉及到微服务架构，第二点涉及到PaaS和DevOps方面的内容。

在微服务架构下，我们管理的单位从原来的大单体应用变化为了细粒度的微服务模块，自然在变更和发布的时候影响单位也相应变小到各个业务模块粒度。这将有效的解决子在后期运维变更功能发布的影响。

从业务组织和IT系统紧耦合到解耦需求

其次，在传统IT系统规划和建设中，在企业架构规划设计中，我们经常谈业务和流程驱动IT，强调端到端流程的贯通。但是系统规划设计和实现的过程中，最普遍的现象就是不是业务驱动IT，而是业务部门驱动IT，导致我们的IT系统和业务部门是紧耦合的。

举例来说，一个企业只有供应链部，那么建设的系统就是供应链系统；但是如果一个企业有采购部，有物流部，那么建设完成的系统就是采购系统和物流系统。

在这种情况下，带来的最大问题就是企业的业务组织架构一调整，往往带来IT系统巨大的调整工作量，在我原来的企业也经常遇到IT系统经常配合业务组织架构调整的事情。这类工作已经不是简单的HR系统组织结构调整，还包括了本身的业务系统中业务功能点的调整，已有的业务数据的调整，这些都需要进行动态切换和割接。当企业建设的业务系统越多，和业务部门关系绑定得越紧密，这种调整带来的复杂度和工作量也就越大。

而真正的解决思路就是要将业务部门和业务系统解耦。

如何解耦？仍然是从业务流程驱动的角度去考虑和拆分具体的业务单元，这些业务单元形成独立的业务组件（微服务架构中的微服务模块），由于这些业务组件粒度已经足够细，因此更加容易灵活的组装或组合去满足实际业务部门的日常业务需求。

举例来说：如果是大的供应链部门，就配置供应商管理，物料管理，采购订单，招投标，库存管理，物流配送管理等多个微服务模块。如果是拆分为采购部门和物流部门，那么采购部门配置供应商管理，物料管理，采购订单，招投标管理，物流部门配置库存管理，物流配送管理等微服务模块。

在规划和拆分微服务模块的时候更多是业务和流程角度出发，只要划分得足够合理，就能够最小化的减小业务组织架构调整对IT系统本身造成的影响。

从单打独斗信息孤岛到共享思路下的平台战略

企业信息化发展到一定阶段，自己都会意识到按照传统的一个个孤立的业务系统建设模式越来越行不通，这不仅仅是业务系统很多功能重复建设的问题，同时还导致了业务系统中数据不一致性，集成困难，后续的运维和变更处理困难等一系列问题。即典型的钱花得更多，但是系统却越来越复杂和难用。

而解决这个问题的的关键就是平台战略，对于平台战略本身又有两个重要的核心，即不是简单的遗留系统能力直接服务化共享，而是首先要集中，其次才是共享。集中化是云的思路，而共享才是SOA的思路，两个关键点都解决了才是云计算+SOA的关键思路融合。

为啥要把这个问题在微服务架构里面谈，因为平台+应用构建模式本身也是微服务架构实施的一个基础条件，微服务模块更多都应该是独立承担某个业务域的业务组件模块，而不应该包括类似流程引擎，系统管理等共性底层组件，否则微服务模块又变成很重的单体应用，没有了任何价值。

要做好微服务架构，我们就必须做好底层基础共性平台的建设，只是微服务架构里面会谈为共性的技术服务能力提供，都是一个道理，就是共性的东西或能力要下沉，然后再以标准的服务接口方式暴露或共享出来给上层的业务系统使用。

资源池的有效利用和资源动态调度

这是微服务架构结合PaaS容器化技术和动态调度技术后带来的一个新的亮点，即可以真正实现按照业务需求和业务并发量动态的申请和分配资源，以满足业务并发访问的需求。在整个过程中不需要人为去干预，而只需要设置好相应的调度规则和资源动态扩展规则即可。

对于这个点实际当前并不是当前很多企业的必备诉求，只是后续成熟度发展到一定阶段后带来的亮点功能，真正解决了IT系统的灵活资源分配，扩展和动态调度问题。

IT架构转型前的准备工作

回到这篇文章题目提到的两个点，即企业数字化转型过程中往往会遇到两个问题，特别是在已有遗留系统和IT架构已经存在的情况下，即：

已有的遗留IT架构如何改造？

当前的内部IT基础架构和应用如何迁移上云？

这两个实际上是大部分企业都希望去解决的问题。

在前面的文章中我也谈到过如何通过服务代理方式来构建一个中台能力中心为上层业务应用服务，或者当前遗留IT架构如何逐步进行微服务架构优化和迁移工作等。

微服务架构不是简单的微服务开发框架的使用，更不是简单的Restful接口的使用，而是大量的SOA，持续集成，组件化和服务化，云平台和容器，DevOps等思想的融合应用。

因此在考虑转型到微服务架构的时候可以首先进行相应的准备，而这些准备基本都是可以独立完成并实施的，具体如下：

持续集成实践：在很早就有持续集成的思想和最佳实践，里面涉及到配置管理，自动编译部署，环境迁移，自动化的单元测试，每日构建和冒烟测试等方法和实践的使用。这些即使没有实施微服务架构，对单个业务系统也可以进行持续集成的实践。持续集成和自动化的构建是后续微服务架构和DevOps的一个重要内容。

领域建模思想：对于领域驱动架构是面向对象分析和设计中的一个重要内容，通过领域服务层的构建可以很好的解决业务高内聚和粗粒度的服务接口提供的问题，而不是简单的将对数据库表的CRUD操作发布为服务接口，同时领域建模也很好的解决了原有的贫血业务逻辑层的问题，真正在业务建模和架构设计阶段，从对数据对象的关注转移到对业务领域对象的关注。粗粒度的服务接口即使在实施微服务架构后也是必须关注的内容，否则会出现微服务模块间大量的接口交互的场景，这种接口越多越导致了微服务模块之间越紧耦合。

SOA思想的深入理解，对于微服务架构实际上是SOA参考架构思想在原有的单体应用内部的实践和落地，因此SOA思想是基础，而SOA思想本质就是业务能力组件化，组件能力服务化，将业务流程或业务的实现转变为多个松耦合的业务组件（微服务模块），同时通过微服务模块暴露的API服务接口实现组件之间业务功能的组合和编排，以完成完整的业务流程。

微服务开发框架的学习：比如对当前主流的Spring Cloud微服务框架的学习和理解，其中包括了服务目录和服务注册，微服务网关，服务的发布，服务后续的管控治理，服务运行监控等诸多内容。这些都需要去学习和理解。通过微服务开发框架，真正实现了各个微服务模块的开发完全独立自治，可以独立进行设计，开发和最终的部署。而微服务模块暴露的服务在注册到微服务网关后又实现了多个微服务模块之间的联动。

关键技术的学习：这里面主要包括了Web Service，消息中间件，事件引擎，Restful接口和面向资源的概念，CXF开发框架，Spring Boot和Spring Cloud，Maven构建，DevOps，云和容器技术，前端技术等。这些都是在微服务架构实现和微服务模块开发中会用到的内容，需要学习和掌握。

基础平台和技术组件和服务的学习：这里面包括了常用的工作流引擎，4A和权限管理，日志管理，缓存，文件服务，ETL数据集成，消息和通知等，这些也都是在实施微服务架构的时候可能会下沉到基础平台层统一规划和实现的内容。

软件过程改进方面的内容：企业遵循什么样的软件开发过程和软件生命周期模型？是传统方法还是敏捷方法论？需求，架构，设计，开发，测试，发布完整的流程是如何的？对于配置，变更，评审和Review等过程又是如何的？这些都需要有一定程度的定义和标准。即使实施了微服务架构，也需要遵循传统或敏捷的软件工程方法论。而在微服务架构中，很重要的一个就是微服务模块的划分，微服务API接口的识别和定义，我们可以在传统方法论中进一步补充这方面的内容。

IT架构转型-具体演进路线

对于传统IT架构转型具体的实施路线和步骤可以总结为如下几个关键步骤。其核心的思路还是企业在已有遗留IT环境的情况下如何平滑过渡和逐步演进。

步骤1:4A和流程平台的下沉和能力开放

这个是我谈得最多的问题，即在实施微服务架构转型的时候必须将4A（也可先狭义理解为原业务系统的系统管理模块）和流程引擎下沉到平台层共性建设，或者说优先要将这两个模块做为微服务模块剥离出来，同时给上层的业务组件模块提供API服务接口能力。

对于4A模块剥离后，我们希望的是涉及到人员，组织，用户，权限等能力的获取都是通过服务接口实时查询获取，这些基础主数据信息也不要落地。在进行这样实施的时候确实会增加上层业务系统的改造工作量。对于流程平台的签出相对来说比较容易，最主要的还是给业务模块提供流程启动，暂停，获取待办已办列表等关系服务接口信息为主。

进行4A和流程平台的剥离核心目的仍然是是的后续需要进行拆分的业务模块只包含业务功能，而不再包含共性的技术能力功能。

步骤2：基础主数据模块能力独立建设

这是我们谈的第二个重点，即希望将提供共享基础主数据的功能单独剥离出来进行独立建设，比如建设独立的主数据平台或叫提供基础主数据的各个数据中心模块。然后数据能力以数据服务的方式暴露出去供上层业务系统使用，同样我们希望上层业务模块在使用这些基础主数据的时候最好主数据不落地，实时用实时查。

在传统PaaS平台建设中会涉及到MDM主数据平台的建设，到了彻底的微服务架构可能并不存在主数据平台的概念，而是各个类似产品中心，供应商中心，客户中心的各个微主数据中心模块，这些微服务模块也是我们常说的中台的核心数据能力提供中心。

要规划和建设中台，首先要考虑的就是这种基础数据中心，其次才是提供业务支撑和业务逻辑处理的中心。

步骤3：业务模块的拆分到微服务模块或逐步剥离出来

我们一直在讲，传统企业的微服务架构转型是一个渐进的过程，是一个老的IT架构逐渐被新架构替换，老架构逐步消亡的过程。在步骤1和步骤2这种共性的基础技术和数据能力下沉后，剩余的业务系统迁移和微服务模块拆分就可以开始逐步进行，逐步迁出。

对于一个业务系统的业务模块逐步剥离出来，一个关键的策略就是优先剥离耦合性最低的业务功能模块，在这个思路下最可能的实施策略就是先将业务系统支持流程的两端（最前端流程或最后端流程）逐步剥离出来。因为两端的流程往往是耦合性最小的流程。

拿采购系统来举例，前端的招投标模块是最容易剥离出来的，后端的采购过程跟踪，采购评估等模块往往也是最容易剥离出来的。

这里拿招投标模块来举例。

注意招投标模块在剥离出来后，横向的交互接口往往并不多，最多也就是招投标执行过程的结果信息或配额信息需要传递到采购管理模块。而对于招投标本身的一些结果数据已经可以下沉到平台层的主数据模块中，而设计到流程处理部分也已经下沉到平台层的流程引擎模块，因此可以看到只要步骤1和2迁移到平台层后，再迁移出招投标模块基本就很容易了。

步骤4：及早地进行统一门户的建设

要注意，在各个微服务模块建设完成后，单个微服务模块本身是不能提供支撑完整业务流程的能力。对于用户来说并不关心是否进行了微服务架构化，而是关心涉及到业务流程处理的功能和操作是否能够很方便的在一个业务应用里面操作和完成。

而这些业务模块基于业务流程，基于业务场景和使用部门的组装和展现，就需要在门户层完成。对于统一门户不仅仅是提供统一认证和单点登录，也还包括了统一的待办集成和任务处理，统一的消息通知等共性功能能力。也就是说，只要是各个微服务模块共性的一些需要展现的能力，都可以集中化到统一门户层去集中处理和展现。

门户层还有一个重要的功能就是进行微服务模块的组装，这些模块组装后可以为业务用户提供完整的端到端业务流程功能支持，让最终用户的感觉就是在使用一个系统，没有系统不停切换的感觉。因此实际上在门户层不仅仅是简单的模块选择，也还可以做一些展现层的编排和组合工作。

对于微服务模块的灵活组装也是相当困难的，因为很多模块组装最终都是体现到模块提供的南北向接口的自动对接，这往往是比对服务组合和服务编排进行定制更加困难。

本文转载自：「今日头条」，原文：https://www.toutiao.com/a6920037920254738955/