In an IT world where a single bad decision can cost the business its reputation or market share, digital transformation requires care and pragmatism. The Modernization Maturity Model is a technology platform providing rapid, low-risk IT evolution. The Micro Focus (now OpenText)-developed best practice approach to modernisation projects has been refined over the course of more than a thousand successful customer engagements, offering a practical, proven change framework for business-critical systems.
Is modernisation that important?
A staggering 88% of Fortune 500 companies have dropped off that list since the 1950s. And in an era where the pace and breadth of change is unprecedented, there remains a worryingly high number of failed IT projects littering the best intentions of digital transformation. It’s no wonder many are turning to application modernisation as a more pragmatic approach.
Modernisation seeks to deliver business value at low risk by protecting core application and data investments already made — effectively building upon what already works successfully.
The application modernisation marketplace is reportedly growing at nearly 20% each year.
How to manage modernisation
Yet modernisation can mean so many things, and plotting the journey and the before and after state is a vital element of any successful change programme. The Modernization Maturity Model helps our organisations plan and implement their own unique journey.
It outlines best practices for enterprise modernisation projects based on three decades of experience, across thousands of projects. The combination of implementation expertise and technical capability provides a powerful, proven modernisation solution.
Real-world guidelines for successful modernisation
The Modernization Maturity Model aims to map the journey from initial business drivers behind the change requirements, through a technical strategy, towards appropriate tactical options. The start point is to understand the requirements for change from operational and business perspectives.
Then follows a review of the technical drivers for change, which may include elements such as application complexity, technical and supplier strategy, platform and architectural considerations, and resourcing. Only then can the discussions regarding potential application strategy take place, which of course would include options not only to modernise, but also potentially under certain circumstances to evolve in different ways such as replacement or retirement.
A critical aspect of the model invites customers to look at their proposed modernisation initiatives, one by one, through all related lenses, enabling them to consider and plot their own modernisation landscape and associated journey for each initiative. It is very important to ensure each requirement is treated separately, based on its characteristics in terms of business goals, time frames and technical considerations. For example, smaller, isolated departmental application updates may be adequately planned using current processes and technology, while larger-scale applications with major cross-team dependencies may need to explore process, technology and cultural changes to support their modernisation objectives.
Plotting the modernisation journey
The columns in the table above are a convenient way of plotting the modernisation journey for a given application set. Many customers have used this model to recognise the separation of elements, plotting them at different maturity phases depending on the lens they are looking through. For example, some major mainframe clients have adopted a DevOps-style approach to application delivery, while continuing to use the mainframe as their core platform.
Conversely, some Cobol application teams are building cloud-ready applications but have retained close control of the applications in a largely siloed culture/operation. Other teams have looked at whether cloud-native is their ultimate goal or whether a more flexible cloud-ready approach is more supportive of their business goals, at least initially.
Importantly, this model ensures no important details are overlooked by the customer during the initial assessment of their current situation, and offers sensible guidance in terms of required destination for each of their modernisation initiatives.
Critical success factors
Large-scale infrastructure modernisation programmes would typically concentrate on considerations of portfolio assessment, and then removing platform (and application) dependencies, data modernisation, application rejuvenation, as well some management and people changes. But often the application’s modernisation journey will then need further changes to functionality in its new environment. Suddenly, considerations around application and process modernisation could become important, such as API enablement, transition to Agile, and operational process modernisation.
Importantly, each application’s modernisation journey will comprise a combination of considerations at various stages. Across the countless modernisation projects that we have supported, the “portfolio assessment and analysis” consideration — namely a drains-up review of the application estate to be modernised — has proved imperative and invaluable.
What are the real benefits?
You can expect some key, measurable results:
- Efficiency: We can help streamline development and delivery activities by 40%, using contemporary technology, DevOps agility and unrivalled flexibility.
- Reduce and improve: Customers can expect 50-90% reduction in IT operations costs and a performance improvement of up to 50% for batch and online transactions.
The model gives organisations the ability to keep what works: deploy Cobol and PL/I applications across all major supported platforms unchanged. It works for all core applications and major data stores. Take your database variants into both mainframe and distributed worlds. It also allows you to stay current: innovate with confidence thanks to certificated virtual and cloud environments including AWS and Azure, and containerisation, including Docker.
- This promoted content was paid for by the party concerned