There are ways to cut your costs by up to 50% while also improving performance.
Yes, there are still some mainframes operating in Australia and New Zealand! And those that are still operating are playing important roles and supporting business critical applications. How can we transform them to be fit for the future?
More often than not, cloud transformation projects are becoming harder and more complex. Any ‘easy’ transformation projects have already been done, and the ones that are left are a bit more complex. In fact, on average 80% of enterprise applications have already transformed to the cloud.
In this remaining 20%, organisations are trying to tackle the business critical applications hidden in the dusty corners… the era of mainframe transformation is upon us. In fact, you’ll remember Andy Jassy called out mainframe transformation as a key theme in his Re:Invent key note in December. Microsoft is equally keen for these workloads to move to Azure.
Over the last few months, I’ve spent time talking to customers in ANZ as well as with Microsoft and AWS about the mainframe modernisation challenge. This topic is often one that is too hard and difficult for the initial move to cloud and often gets perpetually relegated to the bottom of the backlog, something left to tackle in next year’s plans.
But let’s entertain the idea that this is the year for modernisation, why would you want to take on this challenge? Transforming away from the mainframe presents challenges for even the most tenacious CIOs, yet there is a long list of compelling reasons to accelerate your transformation plans. These include:
- Technical debt
- Old niche skills
- Poor user experience
- Massive expense
- Being wedded to physical locations e.g. a DC to run it in
- Being tied to CAPEX investments
- Being unable to fully move & exploit the benefits of cloud solutions
- And don’t even get me started on the challenge of trying to exploit new business models with data-driven, AI-powered architectures which can be achieved in the cloud.
Yes, you could solve the latter with an API wrapper, but that is putting off a problem for later, papering over the cracks of the past without stable foundations for the future.
Globally, there is still a tonne of COBOL code in use by organisations in the IT landscape today, with an estimation of over 200 billion lines of code still in existence. This problem isn’t going to go away without some effort, so what are our options?
Emulation
Now solving this problem is nuanced, you can emulate the mainframe on a new cloud platform, which allows the existing application to run, thinking that it is still on a mainframe. This is a great option for organisations who need to move quickly, if timelines are tight, giving you a way to get to a new platform without a large transformation.
Although emulation is viable, it does not provide an answer to many of the mainframe problems which I listed earlier… you still need old skills to maintain the code, you are tied into licensing models and the overall cost burden remains high. On the skills front, emulation lets you keep the same skills in the organisation, although this can be a blessing and a curse. Who will be able to recruit COBOL programmers in 2025?
Code Transformation
The alternative is code transformation, which means converting your COBOL, RPG or other language into one that is understood by more than a handful of aging, dedicated loyalists.
Moving your code base to Java or .Net is well worth the short-term transformation effort, as it frees you up to a new world of features, staff, skills, ideas and methodologies.
Taking this approach can truly revolutionise your application model. You can move your mainframe into your DevOps shop. You can have your source code in GIT. You can leverage Azure DevOps or AWS CodePipeline. You can release new features as fast as possible for your e-commerce site. The options to revolutionise your model are endless!
The Fujitsu Approach
Fujitsu has a fully automated code conversion solution called Progression. The solution leverages AI to parse your application code, decouple the monolithic application into a functional component architecture, and ultimately provide you with clean Java or .Net.
I say clean code deliberately, as some solutions provide you with a nasty mash-up of COBOL with Java, or JOBOL, or CONET if you go down the .Net route – no one wants this! You need to ensure that you have code which is readable, maintainable and does not trip you up in Day 2 operations.
We’ve completed a number of these transformation projects for the likes of New Brunswick and the Washington State Department of Licensing. Fujitsu Progression is continuing to assist organisations to solve this aging mainframe problem, and we are working closely with AWS & Microsoft to ensure that the resulting solution is cloud native and aligns with DevOps best practises.
And it gets better, most organisations see a 50% cost saving after this transformation. They also see performance improvements for processes that used to take hours, now being delivered in minutes!
How?
The best approach is split into 2 phases; first transform to cloud with the same functionality and then modernise using the strangler pattern in phase 2.
Phase 1:
- Code is converted with Progression into your .Net or Java
- Your initial testing & go live focusses on proving that the new application functions in the same way as the previous application. This ensures that your testing & go-live is clean & clear.
- No retraining the transformed application will act exactly like the original so you do not need to retrain your end user staff. From the user’s perspective, the change is invisible.
Phase 2:
- During this phase, user productivity is a key focus. Most users on mainframe systems, especially in data entry are familiar and productive with their current system. Often users don’t use the mouse and you don’t want to slow down the productivity of your staff. Instead you need a system that can keep up with the lightning speed of your users and only transform the user interfaces if and when it adds value.
- That being said, once you have transformed, you are now able to improve the application, extend the functionality and enhance the user experience and move to a data-driven, AI-powered cloud architecture to drive better business insight & performance.
How long?
We can move very quickly on the code conversion, converting 10 million lines of COBOL code in just a few hours! But don’t be sold by that headline, the real work comes in the planning, scheduling, testing & release of the transformed solution. You should be planning to take approximately 6 months for most transformation projects, but the timeframe really depends on how many screens and processes need to be tested.
In 2018, there were approximately 60 mainframes still in operation in Australia and New Zealand, and we don’t believe this has changed much since then. However, the same solution can be used to transform mid-range systems, iSeries, RPG, Transact, COBOL and more… which brings this transformation opportunity to the mainstream.
Don’t delay and get in touch with the Fujitsu application & cloud transformation team today!
