Enterprise applications have grown over the years, with cumulative enhancements causing them to become complex monoliths that are slow to respond to change and difficult to maintain. Market expectations have also evolved during that time, demanding that applications be more responsive and have greater agility. Realizing that these dynamics are at odds, enterprises have broadly begun migrating applications to the cloud and re-evaluating the current state of their applications to make the best use of the cloud. This has compelled many enterprises to modernize their existing applications. Modernizing a monolith is not a trivial change, but a journey on which enterprises must consider a number of factors and make multiple decisions.
The modernization approach is not a single, common path for all cases. Companies’ journeys often vary depending on three key factors: the enterprise’s objective for the modernization, the current state of the application, and the application archetype.
Whiteboarding the Modernization Objectives
The objectives for modernization may be grounded in business or technical reasons. Some of the most-common business objectives include:
- Faster Time to Market: The company may need more agility and faster release for specific functionality, and/or the ability for business stakeholders to make changes to the business process/product/rule without depending on IT and the development cycle.
- Cost Reduction: Enterprises may seek to replace high-cost infrastructure and/or software to reduce the overall cost of ownership and maintenance.
- Improving Business Operations Efficiency: Executives may demand greater insights into the business operations and relevant KPIs, hence improving their ability to make suitable data-driven business decisions.
- Improving Customer Experience: In a world where customers increasingly select brands based on the experience with them, companies recognize the need to provide new services and experiences to customers across all touchpoints, typically with the systems of engagement.
- Support Business Growth: With increased business comes a need to enable systems and modules to handle the expected growth in business volume.
- Innovative Differentiated Offering: The business may need to leverage newer technology to enable differentiation through innovative functionality.
Application modernization can also be a technology-driven initiative, but such initiatives need to be traced back to the appropriate business objectives to justify the investment. Technology-driven modernizations are primarily initiated to reduce technical debt, which makes applications hard to enhance, maintain and manage. Some technical reasons modernization may be needed are:
- Reducing Technical Complexity: In a word, this is about simplification, making the application more maintainable by modularizing complex modules into simpler components.
- Improving Resilience: Market complexities have forced enterprises to refocus on how to make their applications more resilient and fault tolerant to withstand failure.
- Overcoming Technical Obsolescence: Among the most basic technical motivations, companies frequently desire to replace obsolete, end-of-life software components with newer technology that offers more capabilities and can be supported with commonly available skillsets.
Together, these business and technical objectives help enterprises arrive at the target architecture of the application to be modernized.
Current State of the Application
The architecture, design, technology stack, and code quality of the existing application all influence the modernization approach. A detailed understanding of the application’s current state helps to baseline the current/as-is architecture, which can be compared to the “to-be” architecture in order to identify the gaps and required changes to succeed in the application modernization. A simple analysis could include:
While the type of modernization depends on the objective and application’s current state, the path taken for the modernization depends on several application archetypes.
Application Archetypes
An application archetype is a representative form or pattern that serves as a model for many others of same characteristics.
Modernization Decision Options
Since there could be multiple objectives for the modernization, enterprises may use a combination of approaches, as shown in this decision tree of key objectives and corresponding treatments. Decision options can be applied to any archetype, though archetype-specific decisions require more detail.
Modernization of UI Application Archetype
To explore a more-detailed option, consider the modernization objective to be improving the company’s time to market and its user experience for the UI application archetype. The customer journey analysis must first be completed to determine the optimal user experience, and a detailed application analysis must be performed to identify any hotspots inhibiting the application’s agility. Once these are determined, the impact assessment, estimation and cost-benefit analysis can be undertaken. The matrix below represents the different ways in which the UI application could be modernized based on key decision points.
Depending on the current state of the application and the objectives, the modernized application may end up in any of the five target states:
- A) Micro-Frontends: Micro-frontends, or MicroApps, is an approach to split the front-end into a set of independently deployable, loosely coupled applications and assembled together to create a consistent user experience.
- B) Modernized UI on top of Microservices: In this state, the user interface (UI) is decoupled from the microservices, but not functionally split into smaller Micro-Frontends. The UI is modernized as a whole and can be deployed separately from the microservices.
- C) Modernized UI on Top of Service Layer: Here, the UI is decoupled from the services layer, but neither is further split into smaller parts. The UI is modernized as a whole and can be deployed separately from the service layer.
- D) Modernized UI Embedded in Microservice: This state sees the UI and corresponding microservice split into independently deployable units based on the bounded context. The UI is modernized and deployed along with the respective microservice, which may be composed together if required.
- E) Modernized UI Locally Decoupled from Service Layer: In this scenario, the UI is logically decoupled from the service layer, but neither is further split into smaller parts. The UI is modernized as a whole and deployed together with the service layer.
Modernization Implementation Considerations
Incremental, iterative modernization is generally better than the “big bang” approach, which is very risky. Incremental modernization takes the architecture closer to the target state during each step, with an interim solution that can be utilized by end users, thereby leveraging the investment more quickly without waiting for the entire application to be modernized. Companies should consider several elements during such modernization implementations.
Enterprises have a large number of existing applications that need to be modernized, perhaps for an equally large number of reasons. Application modernization is a journey, not a one-time event, and companies must consider various factors when deciding which approach to take based on the application archetype. This article explored several of those key factors, and the different paths to modernization for UI application archetypes. We will explore a more-detailed modernization approach for other key application archetypes in a future article, but please contact us in the meantime if you wish to discuss this further.
