Exploring the Benefits of an Agile Application Modernization Approach

Suppose you are a leader at a company that developed an important application over an extended timeframe: 10, 20, or even 30+ years. Maybe this system is used internally as a critical part of operating your business. Perhaps it is sold to other companies. Unless you have been constantly refactoring and modernizing this asset over its history, problems begin to emerge:

• On-premises infrastructure costs are not competitive.
• It has become a rat’s nest of dependencies.
• You spend more time fixing it than adding new features.
• Customers are unhappy because you are missing commitments.
• Vendors are dropping support of key technologies used by your application.
• Staffing for legacy technologies is increasingly expensive and difficult to find.
• Customers want features, like Machine Learning and AI, that it won’t support.
• You have multiple versions, releases, and code bases, creating a support nightmare.
• It is increasingly difficult to meet regulatory and compliance demands.
• You are at risk of a data breach.

A Dull, Sinking Feeling

You know what good looks like—a modern, cloud-native, microservice architecture using SOLID principles, built and maintained with sound DevSecOps practices like TDD, CI, CD, and Infrastructure as Code. Containerized, scalable, future-proof, nimble, compliant, secure, cost-effective, and ready for the rapidly emerging technology trends that customers want. But time pressures, expediency, and tightening budgets make you opt for band-aids.

Ignoring this problem, however, can have serious consequences. Once you start losing customers, are threatened with lawsuits, there’s a breach, or you are about to lose a vital compliance certification, the risk to your company becomes existential. It is better to address the situation before that happens.

There is a temptation to do a moonshot project and attempt to rewrite and re-platform the entire solution in a short period of time. Sometimes this works. I’ve been part of one of those that was successful. I’ve seen many more that weren’t. Outright failures. Unfinished journeys that just made things worse.

Large initiatives, like modernizing a legacy solution, are risky and fraught with peril. The thought that you can quickly recreate something built over a couple of decades is generally unrealistic. Plus, the business will want all those new features they could not get before at the same time. Fortunately, there is a better way to approach this.

Breaking Up the Work

Recognize, upfront, that this is going to be an adaptive journey. You must break the problem into smaller problems and solve them incrementally. This allows us to deliver value quickly. As each capability is freed from the rat’s nest, working tested product is placed into the hands of the user or customer. They will experience the progress being made. This constantly creates options about which capability to tackle next. The steps become:

• Develop an understanding of the capabilities the solution provides.
• Assess each capability’s Business Value, Performance in Role, and Risk.
• Quantify the economic benefit of improving each capability (performance, market fit, availability, quality, etc.)
• Decide the transformation approach for each capability.
• Transform capabilities incrementally, in priority order.
• Establish an Agile System of Governance to guide this (and other) efforts.

Capabilities

A capability is the combination of people, business processes, and assets (e.g., technology, information, materials) that delivers some quantifiable unit of value for the company. Notice this is a larger perspective than simply an application. Your products and user journeys leverage those capabilities to deliver value. Sales and Finance are examples of capabilities. Capabilities are enabled by technology. When building an application modernization roadmap, the first step is to understand your capabilities in general and, specifically, those supported by the problematic application.

The next step is to assess those capabilities. How relevant is a capability to your current strategy? How well is it performing its role? How often, or how quickly, does your market require the capability to be changed? Is the architecture of the capability suitable to be changed at that speed? With this information, you can begin to make investment decisions.

Transformation Approaches

Not all capabilities have to be delivered in the same way. A strategically relevant, differentiating capability that requires frequent changes to satisfy a market should probably be implemented as a bespoke, cloud-native application. Your digital storefront, where customers discover your products, which supports the Sales capability, might fall into this category.

A supporting capability that does not need to be changed frequently but needs to perform well may be best served by a COTS or SaaS product. Your General Ledger, which contributes to the Finance capability, must be right. But for most companies, it is not what differentiates you in the marketplace.

Some capabilities may no longer be essential and can be left in place while you manage risk. Others may no longer be needed and can be eliminated, freeing up funding and capacity for more important things.

Now, with your capabilities assessed, you can tackle each capability in priority order based on the amount of capacity and capital you are willing to invest. The important thing is that you are implementing the capability and not simply trying to reproduce exactly what the legacy application used to do.

Adaptive Governance

This is an adaptive and dynamic process best served by agile governance. It requires a team of people, which we at LeadingAgile call an Investment Team, to manage strategy articulation, prioritize the capabilities backlog, align resources, and manage the funding. This team monitors, adapts, and responds to challenges during the journey. An Investment Team typically oversees several objectives and initiatives.

A Brighter Future

Regardless of how the situation came to be, addressing a large, legacy solution becomes unavoidable at some point. By avoiding the temptation to fix it all at once, taking a capability-based approach, transforming in increments, and establishing an agile and adaptive system of governance, you can create a solution that serves the needs of the business.

Once this is done, you have a structure in place to steward the solution over its life and avoid getting back in the same situation ten years from now. All those startups that look nimble and fast now will likely make the same mistakes everyone else does. But because you’ve done the work of developing a robust modernization plan, you’ve created a long-term competitive advantage over those companies that will inevitably slow down over time.