Our LzLabs teams have helped many organisations in their modernisation projects, from the initial consultation and planning stages all the way through implementation, testing and go-live. This end-to-end expertise is unique and has allowed LzLabs to experience how the very philosophy behind modernisation has changed over the years. In so doing, we’ve identified four key success factors to legacy application modernisation.
1. Make small but continuous progress
An all-in-one-go approach, known as ‘big bang,’ is often seen as a necessary evil due to the complex interdependent nature of mainframe environments. The issue with this often lies within the limitations of individual modernisation technologies or methodologies and the urgency to get to a new state in a single step.
However, experience tells us that picking apart the project into smaller and quicker deliverables dramatically increases the rate of project success and thus accelerates the speed of delivery of value to the business. Splitting items into a few steps may overall take a little longer but is likely to deliver a better overall result.
At the heart of this methodology lies a fundamentally different management philosophy: one of incremental migration and modernisation of legacy workloads. As modernisation becomes imperative to many businesses, the incremental approach, which reduces project risk by minimising the number of moving parts at any given point, allows companies to forego of the big bang approach (which is proven to have spectacular failure rates). Alas, many companies are still sold on big bang projects with unrealistic timelines because businesses need agility from their systems. What the incremental approach has demonstrated is that it is still possible to advance business and do so quickly, it just requires a different strategy and for items to be broken up and/or delivered in incremental steps of value.
Experience tells us that smaller projects as part of an overall strategy allow for change. Change happens so often that no Gantt chart stays relevant after a few quarters. And while a rock-solid project plan provides a high-level overview, it never wins when it encounters reality. Better pick the most important small steps, execute them and then look at the strategy, and build the next steps based on reality at that point. A good strategy allows for the flexibility that organisations and their vendors need to deal with the unexpected. And simply factoring in time buffers won’t remove the stress of stretching or constantly slipping timelines.
2. Minimise the number of moving parts
Whilst technologies can help accelerate a modernisation programme, a realistic approach will always be grounded in the understanding that moving 30+ years of development forward will not be a quick or simple process. Promises such as “in the cloud in 12 months” or “Automated COBOL to Java in minutes” are just that—the kind of promises known as magic bullets. Such claims seem worth pursuing because they fulfil the need to see clearly from afar a desired end state. They seem exciting because they are risky.
However, when it comes to application modernisation, the lowest-risk approach is the one people ought to get excited about because it offers the highest chance of success. The incremental approach follows a simple principle: modernisation is a journey, and one should always move on with the lowest number of moving parts at each step of the way. It’s a methodology that studiously avoids any framework, predetermined architecture or technology tools. Rather, it runs an evidence-based analysis of the value that application modernisation generates for the business.
This analysis informs the modernisation roadmap, which prioritises in successive migration waves the workloads according to their criticality and complexity, ensuring interoperability and getting organisations step by step closer to their desired modernisation outcomes.
The incremental approach rests upon the premise that the business logic embedded in legacy assets is unique. Therefore, the methodology preserves what must be preserved so that organisations take back control of their applications. There is no need for a big bang project. Organisations that run their legacy applications on the cloud or their preferred platform of innovation are able to test more and earlier, speed up time-to-market and reap the benefits of their modernisation investment sooner.
If big bang modernisation projects continue to be popular is because interdependencies between workloads are deemed too complex to unravel. Whatever the cause or causes for big bang modernisations, their inherent risk is too big to ignore from business, technical and human points of view. How long does it take for the business to see the value and return of their investment? How does the development deal with changing requirements as the rewrite moves forward? No one likes to talk about staff change but experience shows that people often move on part way through a project—how does this affect the project?
3. Engage end-to-end guidance
A large modernisation effort is like planning an excursion across the rainforest. Sounds exciting and maybe strenuous, but endurance and resourcefulness should suffice. Well, not quite. You have some choices to make.
Do you learn advanced navigation, field medicine, high-frequency communications, local wildlife, plant life and other geographic factors, carry multiple days of food, equipment and supplies on your own back, and many more things? Or perhaps you take an organised trip with a guide, someone who knows the landscape inside out and gets you from A to B safely, steering clear of pitfalls.
Many vendors, large and small, have built their skill sets around specific modernisation tasks. Assembling a group of vendors, each specialised in a particular domain, to plan and implement the project, is unlikely to end up well. Therefore, what makes the difference is having all the skills and expertise necessary under one roof.
It makes perfect sense that organisations do not have all the required skills in-house. Due to the specific nature of legacy application modernisation, many of these skills are highly specialised and will only be useful on limited occasions. It’s important for companies to build in areas that are repeatable and gain experience, but they shouldn’t invest to build one-off skills.
4. Align legacy modernisation with business priorities
When you only have a hammer, everything starts to look like a nail. It’s convenient and often feels easier to focus on one tool to solve all modernisation issues. If there’s only one standalone application to deal with, this is a perfectly valid approach. The problem occurs when there are many applications written over decades by different experts with a huge number (often thousands) of interdependencies.
Considering different applications at different stages of their lifecycle means looking factually at each application’s value and possible journey. This will mean evaluating each application for modernisation (everything from transcoding to rewriting), retirement or replacement. Database interdependencies and future state, third-party migration or replacement, scheduling and several hundred other factors. The approach needs to be sympathetic, pragmatic and looking to a future state aligning business and technology needs. Each choice has to work for the needs of that application and overall in the strategy to reduce time to value and minimise business continuity risks.
We know that it is difficult to grasp the full nature of a legacy modernisation effort. But you are not alone. Contact us for a free consultation.
