A Data-Driven Approach to Application Modernization

Whenever tech companies change their business focus, they face significant technology challenges linked to agility, compliance, maintainability, scalability, and additional software quality issues. These problems are only amplified when a company experiences hypergrowth.

The good news is that application modernization can serve as a countermeasure to these challenges while preventing a major rewrite of the system (or at least parts of the system) by improving the architecture and keeping architectural and design technical debt in check. For these reasons, the use of application modernization is quickly growing in popularity. Konveyor's May 2022 report revealed around 54% of businesses have plans to adopt the process within a year. 

Missing deadlines, longer cycle times to add new features, inability to scale, and higher defect slippage – often lead to discussions around the need for application modernization. Legacy technologies, badly designed modules, poor architecture choices, and poor code quality are typically the reasons for these challenges. Re-architecture, rewriting modules, and application modernization are the recommended solutions. 

But an application modernization initiative should not be made without serious consideration. In some cases, a focused effort on tech debt reduction for 3-4 months can solve pressing challenges or rewriting a few modules over 6-9 months might be all that's necessary. However, application modernization is the only approach that will work in other cases. 

How do you determine whether application modernization is the best route? A solid business case will ensure you spend resources on the right move. But what data points do you need to prepare such a business case? 

Most of the frameworks for application modernization have two common steps:

1. Tech Due Diligence: This involves evaluating the application's architecture, technology stack, and business value. The goal is to determine whether the application can be modernized or whether it should be replaced entirely.

2. Modernization Roadmap: This involves creating a detailed plan that outlines the approach, timelines, and resources required for modernization.

Based on my experience creating these artifacts, below are the key details that should be considered for both.

Essentials for Technical Due Diligence 

To get a fresh perspective, avoid including reviewers from the original team and speak to stakeholders involved in decision-making earlier to understand the past business objectives and constraints (both short-term and long-term), challenges in the current architecture, the current organizational structure, and the development processes. 

Your tech due diligence must cover the following:

High-Level Architecture 

For a 360-degree view of the system, collect information about the following: 

• Key Architecture Principles: You can get key architecture principles and decisions easily as Confluence pages or ADRs if your team follows a practice to document it (Architecture Decision Records). 
• Tools, Technologies, and Frameworks: Along with the cloud platforms, rule engines, and web servers used, get a detailed understanding of the frameworks and libraries used in the system. 
• Standards and Guidelines: Collate standards and guidelines followed for technologies like frontend, API, database, etc. 
• Non-functional Aspects: Gather information on non-functional aspects like performance, security, and compliance.

Component Design

Most of the time, system components' designs are not documented. However, a code walkthrough for a use case can help you understand the design.

• Design Principals: Find out whether good design principles like SOLID, Domain Driven Design, and appropriate design patterns were used. 
• Data Stores: List all the different data stores like RDBMS, key-value stores, and document stores used in the product, along with their purpose. 
• Data Modelling: Each type of data store has different modeling techniques. Review them to check if the right techniques are used or not. 
• Data Privacy: Closely observe the techniques used for data privacy and vulnerabilities. 

Dev Processes

This step is to understand the processes followed along with execution challenges and product quality, including functional and non-functional. 

• Processes: Clearly understand new feature development, change management, problem management, release management, etc. 
• Execution Challenges: Teams typically know the problems they face during development, deployment, planning, delivery, decision-making, team balance, and team motivation. You should review these aspects to unearth problems in any of them. 
• Bug Reports: The bug reports cover trends, analysis, Root Cause Analysis (RCA), and the first-time-right. 

Team Capability 

Technical leads are often unaware of an individual's technical strengths and weaknesses. To counter this challenge, you must find out which developers are highly productive, write good quality code consistently and strive to get the first time right (build user stories with minimum bugs). 

Infrastructure

Gather data around current cost and the cost trends for the past one year along with other key metrics that the team collects like MTTR, MTTF, Uptime, Release Frequency, Rollback frequency, etc.

To summarize, the Tech Due Diligence Report lists the problems/challenges the current system has by considering all aspects like high-level architecture, component design, dev processes followed, team capability, and infrastructure.

Essentials for a Modernization Roadmap

The roadmap helps you to de-risk the modernization. Here are the key inputs necessary to create the roadmap: 

• Tech due diligence report.
• Future business objectives and constraints.
• Planned product roadmap (new features that need to be added to the application). 
• Non-functional requirements that the system needs to support in the near future and beyond.

Based on these inputs, develop a target architecture that meets most of your requirements. The target architecture needs to meet business goals, and you can divide the goal into two broader categories:

1. Business Sustenance: Ability of the system to:

• Add new features quickly at a scale where the development team size is more than 100. With the growing development team, coordination efforts required between different teams will also grow manifold. As a consequence, the cycle time will also increase. 
• Detect and fix bugs quickly within committed SLAs.

2. Business Growth: Ability of the system to:

• Scale linearly with business growth. 
• Be compliant with laws and regulations. 
• Be always available with high reliability. 
• Be secure

Apart from these, the system must also support software quality attributes like portability, accessibility, localization, etc. The proposed technology roadmap must cover not only the technical/architectural changes but also the cultural and process changes while staying aligned with the following:

• Development Processes: For planning, execution, code quality, product quality, deployment, documentation, and release with a feedback loop and continuous improvement baked in. 
• Tech Debt Management: Processes to be followed to ensure tech debt is controlled and cleared off at regular intervals.
• Team Structure: To support development with increased productivity and high morale.

Advantages of a Data-Driven Decision

By gathering and considering all these data points, you guarantee the following:

• Well-defined, measurable goals for modernization.
• Scores on key architectural areas with explanations. 
• Gaps and risks in the current architecture/design/code. 
• Target architecture along with Key Architecture Principles and reasons for the choices recommended.

You can also create a Tech Due Diligence report to have a 360-degree view of the technology of your product on all dimensions at regular intervals. Doing this can extend your product's life and preempt scrapping the product in the long run.