application现代化： 当重写比重构更好时

数字化转型的最大影响之一是对应用开发的颠覆。 从历史上看，将新架构引入应用程序开发通常需要几年时间才能进入高速发展阶段并得到主流采用。 席卷整个行业的应用架构最终会成为事实上的标准。 我们看到这发生在 20 世纪 90 年代中后期，当时 J2EE 缓慢但坚定地成为开发三层 Web应用的“企业标准”。

如今，似乎注定要“坚持”并成为新标准的架构是云原生。 这些基于容器的微服务架构正在迅速发展并主导各行各业的新开发项目。 Kubernetes 的成功发展表明，大量此类应用在其之上部署和运行，这种最新的应用程序架构将会继续存在。 我们的研究表明，至少有一半的组织正在因数字化转型而探索“新架构”。 

现在，这通常被解释为组织正在进行“现代化”之旅。 而我们（业界）倾向于用非常笼统（且松散）的术语谈论现代化。 就好像组织只需挥动一根魔杖，所有的应用就会建立在这个新模型之上。 

实际情况是，组织有很多方法来实现应用的现代化。 只有一部分 (37%) 正在采用重构方法。 重构方法有很多，其中最流行的方法之一是红绿重构。 但还有其他的，包括准备重构和基于抽象的选项可供选择。 大多数都是基于简化代码。 换句话说，他们很大程度上依赖于一种破坏性较小的重写应用的形式。

但有时彻底重写才是实现现代化的最佳策略。 一般来说，完全重写现有遗留应用所需的工作量足以让最坚定的数字化转型倡导者望而却步。 但在某些情况下，它可以节省大量成本。

考虑联邦机构为实现其应用组合的现代化而采取的方法。 根据转向敏捷方法的要求，该机构需要获得特殊许可才能以传统的瀑布方式开发应用。 现在，瀑布式方法在我编码时是主要的方法，所以是的，它已经过时了。 该机构认为，最好的起点是了解自己的投资组合，并合理化每个应用的需求。

在那次审计中，他们发现在约 6000 个应用中，有近 200 个执行相同的基本资产管理任务。 想象一下，需要对基本业务功能进行一项变更，而这项变更需要修改所有 200 个应用。

开发人员和运营商需要投入大量的时间和精力来开发、测试和部署相同的业务功能。

该机构决定实现现代化，用一个微服务取代所有 200 个应用，现在该微服务可供整个机构用于跟踪资产。 它使用敏捷方法开发并在现代环境中运行，可以扩展以满足依赖于其个人私有应用的每个功能的需求。

并非所有的现代化努力都集中在重构上。 战略性地探索现代化对整个应用程序组合的意义可以带来显著的业务优势。 许多组织，特别是那些已经运营几十年的组织，可能会遇到同样的投资组合问题：重复。 重组、收购、合并和管理变动很容易导致应用重复。

作为现代化战略的一部分，进行应用审计和合理化将对每个组织都有好处。 您可能会发现您有数百个应用，但只需要其中的一些。 这种策略使领导者能够证明在新的架构中开发的全新应用的合理性，从而消除应用程序冗余以及由此产生的成本。