本文来自twt企业IT社区，作者/汪照辉。
《哈佛商业评论》中文版推出《数字化运营——新思路应对新周期》提到，企业的数字化升级是一整套体系的进化，从底层架构到业务模型、人才、组织架构，再到制度，乃至于文化等多个层面的升级。
为什么是一整套体系的进化？首先从数字化转型的本质来说，它是使用科技手段来对数据要素的深度分析和应用而带来的业务、流程、模式等的创新和变革，这是生产力的创新和变革，从而也就需要组织架构、企业文化等生产关系方面的创新和变革，以适应生产力的要求。信息化是单点信息技术采用带来的局部效率提升，数字化则要求以数据为驱动、对全局数据的深度洞察和分析，以发现数据之间潜在的联系和关系，从而开发、创新新的业务或业务模式。因此数据在数字化阶段成为基本的生产要素。
数据成为基本的生产要素，单体系统的数据量无法满足数字化海量分析的需求，无法洞察到不同系统间数据的潜在联系和关系，所以需要将这些系统数据进行集成，或者采集到数据仓库、数据湖、大数据平台等地方，再对数据进行处理和分析等。这是通用的习惯方法，不过这种方式没有从根本上解决数据的融合问题，带来了大量的中间数据处理环节和工作量。前些年推行的主数据管理系统（MDM）试图整合企业内系统间共享的高价值数据，实现数据一致性、标准化等，从而在各个系统之间提供唯一可信数据源。以主数据管理的思想，以主数据为骨架，重构企业数据架构，在新建应用系统或者替换改造存量应用系统时，按照新的数据架构来构建系统，旧系统旧方法、新系统新方法，逐步实现企业级的数据融合。
数据和应用通常是一体两面，数据融合势必要求应用架构的调整，比如从单体竖井架构进化为分布式微服务架构。微服务架构和ESB架构虽然都是服务化架构，但两者解决的问题是不一样的。微服务解决的是单体竖井系统的分解问题，ESB解决的是系统集成问题。所以可以说ESB重在集成，微服务意在重构。ESB架构是一种系统集成的过渡方案，没有从根本上解决数据融合问题，所以要实现数据融合，服务化架构选择微服务架构是合适的，要从数据层进行重构，消除不必要的集成补丁环节。应用的微服务化也便利实现服务级组件的复用和共享，从而为中台架构构建中台服务提供了可行方案。应用部署运行在基础设施之上，基础设施产生的数据也往往和应用的运行状况密切相关，是实现应用运行可见性、可观测性的必备要素。分布式的应用架构需要分布式的基础设施架构来支撑，比如微服务运行在容器上，容器基于kubernetes实现调度管理，运行在虚拟化或云平台上，从而实现业务层和基础设施资源层自动弹性伸缩能力。从而实现了应用融合和基础设施资源的融合。
应用是业务信息化、数字化的一种表示，数据是业务执行和交互的基础要素。数据和应用的融合，也意味着业务的融合。通过对业务数据的分析和洞察，发现并找到数据之间的关系和联系，从而也就找到了业务之间的关系和联系，从而可以开发、创新新的业务或优化已有的业务，这就是数据驱动业务创新优化。
数据、应用、基础设施以及业务的融合都是需要技术的支撑，比如说云原生技术体系的支撑，以微服务分布式架构替换单体竖井架构，部署在容器化PaaS云平台，从而使企业内从基础设施资源到数据、应用和业务看起来是一个整体，每个应用类似于一个组件，消除了应用之间的集成补丁，可以类比于中国传统建筑的榫卯结构，无需额外的铆钉，简单、坚固并且高效。
业务的融合势必需要调整组织架构。其实，从基础设施资源融合，应用的分布式开发和部署，就需要考虑研发的组织架构调整，以适应新的生产力发展要求。不过业务的融合更容易让企业看到组织架构调整的必要性，只是这需要一个过程，可能会有阵痛。什么样的组织架构更合适？这个问题比较难回答，不同企业实际情况不一样，数字化转型路径也会有不同，所以组织架构如何调整和融合，如何能更适应自身的实际，可能也需要尝试和按需调整。可能也是摸着石头过河的过程，所以自身对数字化和数字化转型的认知和把握非常重要。别人的经验不见得适合自己，削足适履只会自己承受痛苦，所以笔者特别不建议动不动就搬什么最佳实践。一定要基于自身的实际来考虑、来规划和执行。
系统融合其实还是遵循着企业架构的方法，只不过从原来简单的单体系统扩展为企业级分布式的复杂系统。这也是中台架构之所以有需求的一个原因。可以看到系统融合包括基础设施（包括基础设施资源、工具组件、安全等）的融合、数据融合、应用融合、业务融合、组织流程融合等几个方面。系统融合是一种企业架构发展的要求和趋势，是数字化和数字化转型整合各项资源、统筹各方面能力、以数据为驱动、统一认知、理顺协调好关系、从而按照规划的路线图实现企业的目标和目的的要求。
