As the digital economy demands a measured and low-risk approach to IT transformation, many are turning to modernisation as their preferred and reliable strategy. What’s the secret? Pragmatism, writes Derek Britton, Software Product Leader, Application Modernization and Connectivity, Micro Focus.
The statistics around the risks of poor corporate and IT performance are astonishing: a staggering 88 percent of companies which were in the Fortune 500 fifty years ago have now dropped off the list. At the same time, and perhaps not entirely coincidentally, the fortunes of major IT projects make for equally grim reading – as an industry, project success rates sit at about 29 percent, whereas partial or total failure rates stand at 71 percent.
Derek Britton, Software Product Leader, Micro Focus.
These eye-watering figures explain why large-scale, seismic IT projects are now falling out of favour. IDC recently explained that businesses with deep investment in mission-critical IT systems must ‘leverage these investments and de-silo their mainframe, Windows, or Unix systems by opening them up and connecting and integrating them with the rest of the world in a pragmatic way’.
The most critical IT systems are often written in the COBOL language, typically running on mainframes, and powering the most fundamental processes in modern business.
From tax and pension systems, payment processing, through logistics monitoring, government bureaux and insurance quotations, these core systems represent comprise long-standing intellectual property and business value. Faced with this, businesses will rightly conclude that a potential 71 percent failure rate is unacceptable. But what is this pragmatic IT modernization approach, and how does it differ from riskier methods? Here are some key considerations:
IT Modernization: Think Strategically, not just Technically
The first question is always: what is the business trying to do, and what are the main operational considerations? The usual suspects line up, of course. Time to market. Risk management. Cost management. Competitiveness.
To use a tangible example, one client looked purely and simply at these four issues and chose to modernise its incumbent, home-grown system because it would be quick to deliver, low risk, cheap, and most importantly the business would retain its competitive advantage by reusing the current (successful) IT system. The alternative large scale replacement systems – which are risky, expensive, and of only questionable competitive value – were quickly discounted.
Content from our partners
Look Through all the Lenses
Modernisation ultimately means IT change. But change can be defined across a number of lenses as it impacts both the IT operations and the business it serves. A sensible modernisation strategy must ask what needs to be achieved across three key technical domains. First, the what – what application, what new capabilities, what integrations, and what security and operational updates are required. Second, the process – how is the application built and delivered, what internal methods such as Waterfall, Agile, DevOps, and CI/CD does the company currently use, and whether these need to be changed.
Finally, IT teams need to consider the infrastructure – where does the application currently execute, who accesses it from where, and whether that will that need to be modified. A modernisation strategy that is tightly coupled to one domain only without considering the other two is likely to overlook key operational dependencies.
Preparation is Everything
Whatever you may need to change, you need to make that decision based on fact, not fiction. As such, a genuine inventory of the current state of the business is a pre-requisite. Missing this part is going to guarantee that any plan for the future is not much more than an educated guess.
A range of seriously insightful assessment technology can undertake hitherto impossible drains-up reviews of incumbent core business systems. This enables an understanding of where the value lies, which systems hold that value, what the interdependencies are, and where the risks and impacts of change are, right down to the level of code. The first rule of modernisation is don’t attempt to modernise something you don’t yet understand.
New and Shiny? Don’t Believe the Hype
A view not often heard in the tech industry is that new doesn’t always mean better and, more importantly, old doesn’t always mean redundant. Blending innovation with trusted IT value is key. What makes the most practical sense is to build a bridge between the old and the new. If an IT system is 40 years old, then that means it contains 40 years of value and uniqueness – the task is to determine how to nurture and reuse it. In nearly every case, an incumbent system can be easily adapted, integrated or enhanced to support a new, digital interface or capability.
As the motor car or telephone will attest, good ideas from some time ago remain useful today, and have kept up with the times. No-one drives a Ford Model T any more. The average child is aghast that phones used to need wires. The 2019 incarnation of the most successful business technology of them all, COBOL, is a very far cry from its predecessor – but it remains as viable, contemporary and prevalent as ever within the world’s largest companies.
Culture eats Everything
One of the most common mistakes is to overlook the impact on corporate culture as the IT organisation attempts to transform. Roles change, operations change, and as a result, attitudes need to change.
As new working methods, collaborations and levels of expectation evolve, people need to shift their mind-sets. Effective leadership is necessary to support that cultural transformation. A customer recently summed this up by testifying, ‘it took us a few weeks to modernise the code, but a couple of years to fix the culture’.
Sharpen Your Pencil
Methodological, scientific approaches are employed in engineering tasks the world over: so why not use them in software change programmes? Over the course of a few decades and thousands of modernisation projects, we have seen what constitutes a successful planning and management discipline for modernisation, and much of it boils down to a checklist of the same core elements.
While no two projects are exactly the same, many possess the same characteristics, and the following are always worthy questions regardless:
- How will we undertake our ‘current state’ portfolio assessment and analysis?
- Will we need to partially or fully transition to Agile/DevOps?
- What is the future of this application – and how does it need to change?
- Do we need to remove existing platform dependencies?
- Do we need to decouple application dependencies?
- Do we need to modernise our operational processes?
- What are our operational & architecture requirements?
- What about data? What modernisation is needed?
- Did we forget about people & culture?
Pulling it all Together
Most risks associated with major IT projects involve a failure to manage the unknown. Between an appreciation of where you are today (considering your strategy against cost, risk and timeliness factors), and awareness of the major lenses through which a modernisation journey can be plotted, pragmatic steps can be mapped out to mitigate against the risks of change to deliver genuine transformational value.
This enables the IT team to plot accurately where they are today in terms of the modernisation maturity of their incumbent systems, and draw up a viable and practical plan towards their desired destination. It’s worth considering.
