Many companies want to move away from having their own data center and utilize cloud-based infrastructures and software environments instead. But their core business depends on long-running mainframe applications, and it becomes too complex to leave the centralized control and security of their on-site data center.
Here’s the problem: Because the mainframe application ecosystem is not a platform for innovation, mainframes have become a source of crippling technical debt. What are your options? We recently sat down with Gary Crook, CEO of Heirloom Computing, to break down your alternatives.
Q1: Heirloom Computing is a very valuable Azul customer and key partner. Gary – I understand that your company is the only cloud-native mainframe replatforming & refactoring solution in the market – tell me more about that.
GC: Thank you, Anne. Heirloom® is an award-winning software platform that has been proven to be the fastest, lowest-risk approach for migrating mainframe workloads as cloud-native Java applications on any cloud. Unlike any other solution in the market, Heirloom delivers on replatforming and refactoring outcomes simultaneously, but let’s frame this properly by first being clear about the terminology. Replatforming typically means you have decided to continue developing your applications in the original language, most commonly that will be COBOL or PL/I. Refactoring typically means that you are seeking to change your legacy language ecosystem for something more modern – this is almost always Java.
We achieve this via something we refer to as “language coherence” and it gets quite technical quite quickly, so I will resist the strong urge that all engineers have, even inactive ones such as myself, to deep dive and explain it from that perspective, but for our clients it essentially means they are in complete control of their modernization journey. They can turn the dial between replatforming and refactoring at a granular level, which enables them to retain their existing code base and the application SMEs, alongside the Java source-code that is produced by our compilers. Cost savings from this approach are pretty dramatic with our clients typically seeing a reduction of 65-85% running workloads on the cloud compared to the mainframe, but perhaps more importantly, these applications are now executing on a modern agile Java platform that puts them in a great position to quickly deliver on whatever comes next.
Q2: What is technical debt – and how does it impact the balance sheet?
GC: I think the easiest way to grasp technical debt is to first understand that infrastructure and processes of any type in any industry are living things that need constant work – primarily due to competitive pressures. In that context, technical debt is something that accrues over time when we prioritize speed of delivery for that work over the best implementation. That isn’t necessarily a bad thing – delivering faster than your competition in the short-term can increase your market share and secure new business, but if it goes unchecked over extended periods of time, it will clog up your gears and significantly compromise your ability to compete. That lack of agility will directly erode your bottom line and at its worst it can become systemic and ultimately, fatal.
When we look at the mainframe, it has been an incredible computing platform. Consistent, reliable – a venerable workhorse for transacting business. That said, the application architecture today is fundamentally exactly the same as it was when first conceived in 1964 with the release of IBM’s System 360. The technical debt within that ecosystem today is suffocating, amplified over several decades by monopolistic chokeholds enforced by IBM, BMC, and Broadcom. And I think this is why the cloud has now become the mainstream strategy within large enterprise – it’s an opportunity to modernize the transactional engine so it can scale on demand with multi region availability at a utility price point – to liberate the data in the systems of record so it can be leveraged by systems of engagement – to transition from overnight batch processing to real time processing – to refactor monoliths into macro and micro services so new capabilities can be delivered much, much faster – and so on and so on and so on – essentially, the cloud is a not-to-be-missed opportunity to become more agile.
You must innovate in order to thrive.
Q3: What are some of the ways to mitigate technical debt and overcome the challenges?
CG: The simple answer is the obvious one – you must innovate in order to thrive. To minimize the risk of such work, you must affect revolutionary changes through evolutionary actions, and commit to do so consistently and iteratively.
The mainframe presents a number of unique technical challenges in this regard – an archaic proprietary application model with proprietary datasets, a constrained application development ecosystem, intertwined operational processes and tools with dependencies on upstream and downstream processing – to name just a few. There are also some cultural challenges, including institutionalized adherence to the “IBM way” regardless of advances outside of the mainframe ecosystem. This has created intransigent organizations that will need strong leadership to transform them so they are better aligned with the business.
Sometimes an analogy works – here’s mine – today the internal combustion engine dominates 97% of the transportation market. It’s also a dead technology – electric vehicles have won. Same thing with the mainframe – it may still dominate enterprise IT today, but the cloud has won. This shift is happening now – across all industry verticals – and that’s why having complete control over your transformation journey on a modern agile platform is so critical. For us, Java is the substrate of that platform – it provides a high-performance scalable execution layer that is processor-independent and cloud-agnostic.
The system was up and running test transactions within 3 months and the production system delivered 152% better performance than the mainframe, an 85% reduction in cost per transaction, and a system that enables Arek to instantly scale as required.
Q4: Great – but let’s get real…. how do you measure your success here? What are some real examples?
GC: I’m going to respond again with the somewhat obvious – for us, success means customers who are running their migrated mainframe workloads in production, many of whom have been doing so for several years now. Some examples are Venerable, an insurance company, that realized savings of over $1M per month, cutting their OPEX by more than 80% – ACI Worldwide, who provide an electronic payments platform to 19 of the world’s top 20 banks, processing trillions of dollars every day – The Avon Company, a cosmetics retailer, that shutdown their mainframe to deliver on their strategic goal of exiting the datacenter business.
These examples are all great projects that delivered compelling value and endorsed by the clients with testimonials, but there is one project that stands out for me, which is the one we did for Arek who provide pension services to all of Finland’s pension providers. Why? Well, because it’s a great example of how we took a very large monolithic mainframe application, built from 22 million lines of COBOL and PL/I code, and refactored it as a Java Spring Boot service running on an infinitely scalable Kubernetes cluster on Google Cloud. The system was up and running test transactions within 3 months and the production system delivered 152% better performance than the mainframe, an 85% reduction in cost per transaction, and a system that enables Arek to instantly scale as required – this was their primary objective as they are projecting a 10X increase in requests as the pension providers open up their systems to their customers.
Q5: Together our Azul Platform Prime and Heirloom have really driven a lot of value in the market. From your perspective, what is the impact to the balance sheet?
GC: Well, looking again at Arek and what we did for their balance sheet – when you deliver 152% better performance – that means you don’t need to rent as much compute from Google Cloud, not to mention the productivity gains in your operating model. With an 85% reduction in cost per transaction, that means more scale in delivering pension services and improving customer experience. All of this means more elasticity in faster cash flow while removing technical debt of running large monolithic mainframe applications.
By using Azul Platform prime, Heirloom automatically re-platforms and re-factors mainframe applications to run as cloud-native Java applications on Azul Platform Prime. Heirloom’s compilation process preserves business logic and data integrity, seamlessly mapping all application subsystems to Java and open-systems equivalents.The resulting application is guaranteed to exactly match the business logic and functionality of the original application.
Again, the impact to the balance sheet is that you get greater application elasticity, higher availability, and dynamic, pay-for-use right-sizing of capacity for efficient resource utilization. And with Azul Platform Prime, they’re assured of the best Java security, reliability, and support in the industry.
Need more help?
Check out how Heirloom Computing’s replatforming service works with Azul Platform Prime. Interested in learning more about how Heirloom Computing can help you attack your technical debt? Get started with Heirloom Computing here.
Azul offers an optimized JVM to improve performance for your business-critical applications. Take Azul Platform Prime for a test run here.