To modernize or not to modernize? That is the question many organizations running critical mainframe workloads find themselves having to face.
It’s clear that most CIOs and IT leaders are well-aware of the existential threat of slow transformation, and the real-life horror stories about legacy mainframe catastrophes are no secret either. But digital transformation, like anything, has its challenges. The move from waterfall and siloed development operations to a DevOps-centric land of continuous integration is a difficult task, but escaping the confines and ancient hieroglyphs of the mainframe world is an entirely different hurdle altogether.
It doesn’t have to be a Catch-22. The facts make it clear that retiring big iron as soon as possible is the right move, but this doesn’t mean that organizations should be hasty about it. Transparency is everything, so if you are finding yourself skeptical about whether to migrate or not, here are three truths and a lie about migrating your mission-critical workloads to the Cloud:
Truth #1: Not all workloads need to be migrated to cloud-native microservices
Cloud-native might be a logical design goal of newly developed cloud workloads. However, there are good reasons not to distill your complete legacy functionality down to an independent set of loosely coupled microservices. The good news is that you probably won’t need to.
Certain functionality might be better off staying as a monolith, due to the complexities involved in architecting, managing, scaling and monitoring highly transactional atomic-based workloads, but also because of their steady state (e.g. updated less frequently). Workloads with these characteristics don’t need a continuous delivery model supported by their own team. Disposition strategies for monolithic workloads will depend on business requirements, and may include re-hosting “as-is” with little-to-no change, or refactoring to Java or C# and further optimizing to leverage specific cloud capabilities such as increased elasticity and availability.
It’s critical not to hurry down one modernization path right out of the gate. The best outcome will be achieved by taking a tailored approach, and by developing a strategic modernization roadmap with specific goals for different applications based on individual requirements. Identify a few high value capabilities that you want to decouple, and then progress towards a cloud-native microservices architecture.
Truth #2: You can significantly reduce risk by completing a thorough assessment that combines a top down and bottom up analysis
Lines of business and other stakeholders should not be kept in silos. As such, members of the business teams need to be brought into any modernization conversations from the beginning. This is required in order to proactively address cultural change issues associated with reorganizing teams to support any new development and deployment model, as well as ensure they see the value in this future application state.
A top down and bottom up analysis should be executed in tandem. A top down analysis, driven via workshops using proven approaches and techniques such event storming and domain driven design (DDD) allow the future to be shaped by describing the business and how events flow through the system. Legacy functionality usage has most likely evolved over the years, so incorporating user experience in order to build specific service use cases is also critical.
The purpose of a bottom up analysis is to provide a comprehensive picture of the contents and interrelationships between application components. The cost and complexity of any future modernization effort can be dramatically reduced by isolating unused components, anticipating potential roadblocks and proactively focusing on areas in need of particular concentration. Using our own analysis tools here at Advanced, we’ve seen scope reduction results of approximately 40 to 70 percent. A bottom up analysis also helps you expose the legacy application design and understand the anatomy of the source code which is critical for ensuring that the future state architecture doesn’t inherit the very design weaknesses that potentially cause you the greatest amount of pain.
To be able to successfully plan for the different disposition strategies requires a form of structured code analysis to find the tightly coupled dependencies in your code. As such, it’s important to use specialized modernization tooling that can address the outcomes of the top down analysis coupled with a bottom up analysis.
Truth #3: Moving to the cloud is best approached as an incremental journey
A byproduct of any good assessment should be a strategic modernization roadmap containing a multi-phased approach to achieving a ROI at each step of the migration. There are different levels of maturity to consider when moving through this incremental journey: Cloud ready, cloud optimized and cloud native.
While cloud native is the ideal destination for “born in the cloud” greenfield development projects, a logical first phase option for monolithic applications is to automatically convert code into cloud native languages such as Java or C#. In this situation, by removing the dependency on the mainframe, you can target a cloud ready containerized environment optimized to take advantage of many of the benefits that the cloud has to offer. In a cloud optimized environment, workloads are optimized further to provide scalability at the container level, while replacing a few high-value capabilities with new microservices functionality. Further optimization efforts can continue at your own pace in order to incrementally move towards a cloud native environment, realizing that you might never replace the entire monolith.
Lie #1: You don’t need to worry about operations and infrastructure
In a typical modernization project, around 40 percent of the effort is focused on application source code and data conversion, with 40 to 50 percent expended on testing, and the remaining 10 to 20 percent spent on designing, implementing and managing the target operations and hardware infrastructure. The target platform should never be an afterthought. This is especially true when deploying to a cloud environment. The reality is that a legacy environment comes with well-established operational and infrastructure standards and processes. A major challenge you’ll face as you embrace a cloud-native microservices approach is the required level of operational readiness and skilled resources needed to support the new, continuous delivery processes. Building out the target environment as part of the incremental journey will give your team tasked with managing it time to adjust before any microservices-driven projects even begin.
Being able to get to the cloud in general is a good thing, to help you gain quick access to new services, platforms and toolsets. Once you have a cloud native infrastructure in place, you will be operating your business with a modern application foundation which will support vastly improved innovation, continuous improvement, faster development cycles, agility and flexibility – just like the Department for Work and Pensions recently experienced. If you want to learn more about their modernization journey – the largest of its kind in Europe – be sure to sign up for our live discussion with Oracle on Tuesday October 12, 2021 (which will also be available on-demand globally after the event).
FURTHER RESOURCES
- Case Study: UK Department for Work and Pensions (DWP)
- How Cloud Migration Can Help Your Organization to Go Green
- Struggling to Adopt DevOps? Maybe It’s Because of Your Aging Mainframe
- 78% of organizations have started at least one modernisation programme because of the pandemic, new report from Advanced reveals
