How to build an effective application modernization roadmap

All software modernization endeavors are not created equal. They differ in scope, industry, and details. One thing unites them, though: they’re prone to fail without proper preparation. Data presented in the 2021 Mainframe Modernization Business Barometer Report supports this claim. According to the survey by Advanced, 77% of mature organizations have started but failed to complete at least one modernization program last year (as compared to 74% in 2020), and almost 40% blame it on the lack of planning.

If that’s the case, embarking on a journey towards revamped software seems to be reasonable only with a viable application modernization roadmap at hand. In this guide, we’ll explain why exactly you need it, what it should encompass, and how to build it from scratch.

Click on the question to find the answer:

• What is an application modernization roadmap?
• Why do you need a roadmap for a software revamp?
• How to prepare for building an effective application modernization roadmap?
• What to remember when creating a roadmap?
• What to do with an app modernization roadmap once you’ve built it?

What is an application modernization roadmap?

First things first. Before we dig into the nitty-gritty of composing a practical application roadmap, it’s essential to understand what a project roadmap is and what it’s not.

An application modernization roadmap is a high-level overview of key stages of your software revamp project.

Typically, it features information about the schedule, timeframe, milestones, epics, dependencies, significant business events, and resources. While it sounds like a lot, the key thing about a project roadmap is that it should be intelligible and highly visual, like an easily digestible snapshot of your modernization endeavor.

An example of a project roadmap. Source: GanttPRO

An application modernization roadmap is supposed to provide a bird’s-eye view of the project. Therefore, beware of confusing it with:

• a product roadmap, which is much more detailed and includes information about requirements and tactical steps,
• a project plan, which is also more explicit in giving task-level details and representing the project’s progress,
• a backlog, which lists the features to be developed without placing them in a larger context of a timeline or high-level deliverables.

If you fail to do so, you risk focusing on short-term achievements and producing an incomprehensibly dense document.

Why do you need an application modernization roadmap?

Since you’re reading this article, you must feel in your bones that the above-mentioned report by Advanced was right, and launching a modernization project with a  roadmap at hand offers real benefits. What are they, exactly?

• Clear and unified product vision

An application modernization roadmap is created at the initial stage of the software revamp project. This means that the team building it gets to work on the coherent product vision, including objectives and the development path, from day one. Thus, a modernization roadmap gives a sense of stability and predictability. Once established, it also prevents the IT experts from getting side-tracked at the execution stage. 

A coherent vision doesn’t equal a fixed concept, though. As the project progresses, the application modernization roadmap should be revisited and adjusted to the current conditions, which we’ll elaborate on later. 

• Explicit goals and priorities 

Although it doesn’t go into details of specific tasks, an application modernization roadmap gives you the sense of where you are and where you’re heading. As a highly visual document that defines, among others, deliverables, it acts as a signpost for the entire team and reminds them of the overarching goals. On top of that, when in doubt regarding the next steps, you can refer to the application modernization roadmap to double-check the project’s priorities. 

• Effective communication

Misunderstandings lead to conflicts or even spectacular failures. Kicking off the modernization project with a roadmap at hand prevents that from happening. When the objectives, schedule, and milestones are clearly defined, stakeholders find it easier to understand the transformation process and know what to expect of the team. At the end of the day, it’s easier to get their buy-in, which is essential for the success of any software moderation endeavor.

An application modernization roadmap facilitates communication with the tech team as well. Because it describes not only epics and dependencies between them but also technology enablers, the roadmap gives every team member a clear idea of what guides their actions and how they contribute to software revamp’s success.

How to prepare for building an effective application modernization roadmap?

As is the case with other decision-informing documents, an application modernization roadmap can’t be created without solid preparation. To prove our point, let us quote a federal CIO interviewed by Deloitte and Appian:

If you don’t get a handle on what you have, it could be nearly impossible to define a roadmap, identify duplication of applications draining resources, or make a business case for new IT investments and projects.

That being said, let us show you what steps lead to the birth of a modernization roadmap. And if you’re curious about how this process looks like in real life, take a look at this video and see how we prepared for transforming an outdated e-learning platform. 

Step 1: Business-oriented project discovery

The first phase is project discovery, which is particularly important when you use the tech partner’s support during the digital upgrade. At this stage, the IT experts gain in-depth knowledge about your company, processes, and stakeholders to inform the subsequent steps of a software revamp. In short, they’re trying to answer the question: What kind of problem is this application supposed to solve? 

To find the answers, the modernization team needs to gain insight into business processes, goals, and stakeholders involved in the transformation of your business. One way to achieve this goal is to have the Domain Experts and the tech team work hand in hand to create a Business Model Canvas, which documents the activities performed to deliver the value proposition, customer segments, distribution channels, cost structure, and revenue streams. Other helpful tools and techniques are exploration-level Event Storming, Service Blueprint, and competition analysis.

Step 2: Current state analysis

Having a firm grip on the product, process, and business needs, you can move on to analyzing the system’s current state from the user and the tech perspective.

The user-oriented investigation into the current version of your system typically involves a product performance and usability analysis based on both quantitative and qualitative UX research methods. Once this assessment is complete, software specialists should provide you with specific areas for improvement and suggest relevant metrics (e.g., user engagement or conversion rate) that would measure the success of these enhancements. 

The other step to be taken at this stage is the technological assessment. It aims to examine your system from the technical side, including architecture, solution-critical areas, and implementation. While the scope of this analysis is relative to an individual case (both your representatives and external developers usually attend such a discussion if you hire external help), it will typically include:

• architecture review,
• development and QA processes review,
• integrations review,
• deployment review,
• technological audit (with its constitutive parts).

Step 3: Future vision definition

Once you determine the as-is state of the system, the modeling phase may begin. At this point, you’re aiming to gain in-depth knowledge about the domains within a system, create a domain model, and provide a visual representation of the architecture. Among the tools that increase your chances of success are the modeling-phase Event Storming and Domain-Driven Design. 

When developing the future vision, don’t forget about the users, though, as disregarding the expectations of individuals who use your system while proposing a new model may, sooner or later, result in mounting complaints and malfunction-related reviews. 

Step 4: Recommendations and roadmap creation

Finally, the time has come to build an application modernization roadmap. The insights gathered so far will help you and the team define priorities, estimate costs, and plan the next steps for the first phase of your software’s transformation. 

Best practices for creating a successful application modernization roadmap

Now that you know how to prepare for creating a modernization roadmap, we’d like to share a couple of pro tips for making it as effective as possible.

Make it a collaborative effort

Teamwork makes the dream work, also in software modernization. To build a sensible transformation roadmap, you need decision-makers, domain experts, and technologists to collaborate. 

Imagine you’re working with a tech partner. Your knowledge will be invaluable for understanding how your organization operates and what its objectives are. The expertise of an external software architect, developers, and designers will enable identifying legacy-related issues and suggesting top-notch solutions. Only when working together, can you define the business value and estimate the cost of the modernization.

A collaborative effort is vital for creating a feasible application modernization roadmap

Take your time to prioritize initiatives

Software modernization doesn’t happen overnight. As a long-term effort aiming to transform entire systems, it should be divided into phases – which, unfortunately, is easier said than done. According to Jim Semick, ProductPlan’s co-founder, 

even large, well-known companies struggle with decisions not being tied to the strategic goal, stakeholders questioning prioritization, and priorities being driven by the loudest executives or the latest sales prospects.

Suppose you don’t want to fall into that kind of trouble. In that case, your application modernization roadmap should be prioritized in such a way to get stakeholder buy-in on the one hand and make a real difference for the users on the other. Here’s our selection of tools that will help you achieve this goal:

• Eisenhower matrix

First comes a decision-making tool that differentiates between urgent and important tasks. The former, as the name suggests, are time-sensitive and put you in the responsive, narrowly-focused mindset. The latter are about values and goals, which induce a more rational and open-minded attitude. Thinking about your modernization efforts in these two dimensions will help you place them on a timeline.

If a given task is both important and urgent, e.g., it’s a critical issue costing you business revenue and customers, tackle it first. If it’s important but not urgent, schedule it for later but beware of procrastination. If it’s urgent but not too important, automation may be a good option. And if it’s neither urgent nor important… it doesn’t add much value, does it?

• Impact vs. effort matrix

A similar tool is the impact vs. effort matrix. The main difference between this model and the Eisenhower matrix are the criteria according to which you evaluate the initiatives. Impact defines how much business value performing a specific action drives. This can translate to the increase in revenue, traffic, users’ satisfaction, or the system’s performance and reliability. Effort, on the other hand, represents the difficulty of the initiative and indicates how many resources you’ll need to make it work.

If an initiative is placed in the high impact and low effort quadrant, it’s a low-hanging fruit that you should consider pursuing in the first place. At the same time, be careful not to neglect the higher effort initiatives of the same impact. They’re both more challenging and rewarding, which means they should be prioritized strategically. Low impact and low effort mark a small quick win that doesn’t provide gobsmacking value. Finally, the low impact and high effort items should be carefully considered and possibly deprioritized.

📙  Prioritizing an application modernization roadmap in practice

The matrixes mentioned above are only two examples of how to evaluate initiatives taking into accounts two criteria. When building a modernization roadmap for one of our clients, we drafted a similar matrix but placed the business importance and the implementation difficulty on the axes. 

Marrying the business and tech perspectives, we wrote down key modules, epics, and initiatives and placed them on the matrix. Next, we used a utility function, which helped us rate and prioritize the items. In this case, we assumed that business impact is twice as significant as the implementation difficulty and cost. This means that a module with great potential but very challenging to develop comes lower on the priority list.

Prioritizing initiatives using relative importance vs. relative difficulty matrix and a utility function allowed us to create an ambitious yet feasible application modernization roadmap that we continue to follow.

• MoSCow

Another prioritization tool worth mentioning is the MoSCoW, which serves to identify the obligatory and secondary-importance elements on the modernization schedule. Within this practice, there are four prioritization categories: must-haves, should-haves, could-haves, and won’t-haves. To quote Jennifer Stapleton, a system’s minimal usable subset is created as a result of completing project must-haves. Won’t-haves, in turn, represent the redundant assignments on the current to-do list.

Keep it real 

Opinions and gut feelings can’t inform your modernization efforts. Data can – but only if it’s high quality and up to date. Suppose you rush through the preparatory stage. In this case, you risk overlooking some modules or underestimating their business impact, and that’s enough to produce an erroneous roadmap. Not to mention that as the project progresses, conditions and requirements may change, which also makes the first version of your modernization roadmap irrelevant. 

Finally, there’s also the issue of having eyes bigger than your stomach. There’s nothing wrong with being ambitious. However, being too optimistic about the timeline and your team’s capacity leads to extended deadlines, disappointment, or even friction between the stakeholders.

We’ve created an application modernization roadmap… what next?

Now that you’re holding a high-level overview of the software revamp project in your hands, you’re almost good to go on a modernization journey. Before that happens, though, take a moment to remember that a roadmap is like a living creature: over time, it should evolve.

The roadmap that you create at the pre-development stage is a starting point. With the project progress, it’s only natural for new issues to enter the picture, previously significant tasks to turn out less important, deadlines to extend, etc. An application modernization roadmap should be regularly updated to reflect these changes for a couple of reasons:

• to provide a valid point of reference for the entire team,
• to accurately reflect dependencies between tasks and, if need be, cause a shift in priorities,
• to give the modernization team the room for learning from their experience, including mistakes such as under or overestimating the schedule.

Adopting an Agile approach helps keep the roadmap up-to-date. Following this project management methodology, you hold periodic meetings (e.g., biweekly or monthly) to learn from sprints and their outcomes. The result is regularly revising your path to revamped software.

Conclusion

With so many businesses failing to complete modernization programs, kicking off the software revamp project with a reasonable roadmap at hand is a must. Not to mention that finding a tech partner experienced in helping mature organizations handle the growing demand further increases your chances of success.

Do you think seriously about software modernization? See how we helped businesses like yours streamline their software towards business growth!