数字化转型的最大影响之一便是颠覆了应用开发。从历史上看，应用开发领域引入的新架构通常历经数年后才能进入加快速度进行发展期并获得大规模采用。而且，有望席卷整个行业的应用架构最终会成为事实标准。J2EE 就可以证明这一点，20 世纪 90 年代中后期，J2EE 以缓慢但坚定的步伐成为了三层 Web 应用开发的“企业标准”。
从当前发展的新趋势来看，云原生架构注定会胜出，成为新的行业标准。这些基于容器的微服务架构将很快主导各行各业的新开发项目。如今，Kubernetes 上部署并运行着许多这样的应用，Kubernetes 的强劲增长预示着这一最新应用架构将成为主流。我们的研究表明，至少一半的组织出于数字化转型原因开始探索“新架构”。
现在，人们通常将这种情形称为组织“现代化”。我们（业内）倾向于用非常笼统且含糊的词语谈论现代化。好像组织只需挥舞下魔杖，就可以基于这个新模型构建所有应用。
事实上，组织可通过诸多方式来进行应用现代化。只有部分组织 (37%) 采用重构方法。在众多重构方法中，Red Green Refactor 最受欢迎。除此之外，还有预备重构和许多不错的基于抽象的重构方法可供选择。大多数重构方法都以简化代码为基础。换句话说，它们主要依赖于破坏性较小的应用重写形式。
但有时，完全重写才是实现现代化的最佳策略。通常，完全重写现有的传统应用可能涉及大量的工作，即使是最坚定的数字化转型倡导者也会望而却步。但在某些情况下，这样做可以省去大量工作。
我们不妨看一下一家联邦机构为实现其应用组合现代化而采用的方法。接到转向敏捷方法的指示后，该机构需要获得特殊许可才能以传统的瀑布式方法开发应用。在我做程序员的那个时代，瀑布式开发是主要的应用开发方法。没错，这种方法现在已经过时了。该机构最终决定首先了解下自己的产品组合并确定每个应用的存在是否合理。
在审核过程中，他们发现近 200 个应用（总共约 6000 个）在执行相同的基本资产管理任务。试想一下，如要更改这项基本业务功能，就需要修改 200 个应用。
这意味着研发人员和运营人需要投入大量时间和精力来开发、测试和部署相同的业务功能。
最终，该机构决定进行现代化改造，将这 200 个应用全部替换成单个微服务。现在，整个机构都能够正常的使用该微服务来跟踪资产。微服务使用敏捷方法开发而成，并在现代环境中运行，可灵活扩展以支持各项依赖于各自专有应用的不同功能。
重构并不是现代化工作的全部，从战略上探索现代化对整个应用组合的意义能带来巨大的业务优势。许多组织，尤其是已经运营了几十年的组织，可能都存在产品组合冗余问题。重组、收购、合并和管理变更都非常容易导致应用冗余。
将应用审核和合理化确定作为现代化战略的一部分对每个组织来说都大有裨益。您可能拥有成百上千个应用，但实际上只需要其中的一部分。借助这种策略，领导者能确定采用新架构开发的全新应用是不是合理，从而消除应用冗余以及其带来的成本。
