數位化轉型的最大影響之一便是顛覆了應用開發。從歷史上看，應用開發領域引入的新架構通常歷經數年後才能進入快速發展期並獲得大規模採用。而且，有望席捲整個行業的應用架構最終會成為行業標準。J2EE 就可以證明這一點，20 世紀 90 年代中後期，J2EE 以緩慢但堅定的步伐成為了三層 Web 應用開發的「企業標準」。
從當前發展趨勢來看，雲原生架構註定會勝出，成為新的行業標準。這些基於容器的微服務架構將很快主導各行各業的新開發項目。如今，Kubernetes 上部署並運行著許多這樣的應用，Kubernetes 的強勁增長預告我們，這一最新應用架構將成為主流。我們的研究發現，至少一半的企業出於數位化轉型原因開始探索「新架構」。
現在，人們通常將這種情形稱為企業「現代化」。我們傾向於用非常籠統且含糊的詞語談論現代化。好像企業只需揮舞下魔杖，就可以基於這個新模型構建所有應用。
事實上，企業可通過諸多方式進行應用現代化。只有部分企業 (37%) 採用重構方法。在眾多重構方法中，Red Green Refactor 最受歡迎。除此之外，還有預備重構和許多不錯的基於抽象的重構方法可供選擇。大多數重構方法都以簡化代碼為基礎。換句話說，它們主要依賴於破壞性較小的應用重寫形式。
但有時，完全重寫才是實現現代化的最佳策略。通常，完全重寫現有的傳統應用可能涉及大量的工作，即使是最堅定的數位化轉型倡導者也會望而卻步。但在某些情況下，這樣做可以省去大量工作。
我們不妨看一下一家聯邦機構為實現其現代化應用組合而採用的方法。該機構的任務是轉向敏捷方法，因此需要獲得特殊許可才能以傳統的瀑布式方法開發應用程式。瀑布式開發已經是過時的應用開發方法，該機構認為最好的起點是首先瞭解自己的產品組合並確定每個應用程式的存在是否必需的。
在審核過程中，他們發現近總共約 6000 個應用程式中有200 個應用（總共約 6000 個）在執行相同的基本資產管理任務。試想一下，如要更改這項基本業務功能，就需要修改 200 個應用。
這意味著開發人員和營運人員需要投入大量時間和精力來開發、測試和部署相同的業務功能。
最終，該機構決定進行現代化改造，將這 200 個應用全部替換成單個微服務。現在，整個機構都可以使用該微服務來跟蹤資產。微服務使用敏捷方法開發而成，並在現代環境中運作，可靈活擴展以支援各項依賴於各自專有應用的不同功能。
重構並不是現代化工作的全部，從戰略上探索現代化對整個應用組合的意義可以帶來巨大的業務優勢。許多企業，尤其是已經運轉了幾十年的企業，可能都存在產品組合重複的問題。重組、收購、合併和管理變更都很容易造成應用程式的重複。
作為現代化戰略的一部分，進行應用程序審核和合理化對每個企業都是有益的。您可能會發現您有數百個應用程式，但只需要其中一些。藉助這種策略，營運者可以證明採用新架構開發的全新應用程式的合理性，從而消除應用冗餘以及其帶來的成本。