Redefining Modernization: Application Transformation
Anyone that works with a mainframe today understands that the mainframe is, indeed, already a modern machine. Just look at the new features with the z16. The key today is how do we optimize the mainframe to include the latest advancements and features of the mainframe. Optimizing allows the user to implement best practices based on the new features. Now when we get to the applications running on the mainframe, that is a completely different story. This article will cover how to implement an application modernization strategy for your mainframe environment.
I like to approach this concept as application transformation, as that is really what we are doing. The work involves transforming older software solutions with upgraded compilers, translating, refactoring or replatforming for efficiency either with the existing language or to a new one. Many times, the process can focus on behemoth monolithic applications that are on-premises and prime candidates to be targeted for microservices via DevOps methodologies.
Several things need to be looked at when targeting a particular application. Budget is usually one of the mitigating factors along with the complexity of the application. Additionally, how critical is the business that it is supporting and what about the resources needed to do the work?
So, how do you develop the strategy for application transformation?
How to Craft an Application Transformation Strategy
First and foremost, you need to follow a solid DevOps strategy that aligns your goals to your business objectives. The DevOps strategy supports application transformation. A structure of good communication and collaboration must be supported by the staff, leading to faster development and deployment. Automation is a must for things like pushing code out. DevOps relies on “continuous everything,” i.e., improvement, feedback, monitoring, integration, testing and delivery. Focus on the people and the processes.
Understanding the need for change is one of the most important pieces of understanding before you begin. Answer these questions, for starters:
- What are the goals you want to accomplish?
- What is wrong with the current application that you want to transform?
- Is the application hard to maintain?
- Do you have the needed resources to make the changes?
- Is it a performance nightmare, eating MIPS? What about security?
Now take a good, hard look at the current condition of the application that you want to transform. Assess what is good about it and what is bad about it. Are there inherent risks associated with the transformation—and what about the cost that will need to be incurred?
Once you fully understand the goals and the current condition of the application, you can develop a transformation plan. A solid transformation plan includes a timeline for completion, the resources that will be needed to do the work as well as the specific steps that will need to be accomplished to complete the transformation. The steps needed for transformation will need to include solid DevOps principles and methodologies as I have previously stated. The specific steps will need to include successor and predecessor activity.
Application Transformation Best Practices
You will need to get commitments and buy-in from the stakeholders that are funding the transformation, as they will be the beneficiaries. It’s important to take into consideration all the stakeholders to include application owners, IT staff and most importantly, the business users. The stakeholders need to have a good understanding of the value that will be delivered as part of the transformation effort. Communication is paramount, and all stakeholders need to be informed from start to finish. Additionally, the stakeholders need to be informed of progress—and that means positives and negatives. Bad stuff happens with transformations and that needs to be communicated as well.
Part of the DevOps process includes continuous testing. Take the time needed to test the transformation application to ensure that it’s working correctly. Closely review the output and functionality. Review database activity and get your users involved in sanity check as needed, as well. When I was a developer, some of the best testing was directly with my users. They will tell the story, as they know what the application looked like before and now after the transformation has occurred.
It is very important to monitor the performance of the transformed application using test data and if possible, within your DevOps process, use a form of synthetic transactions when appropriate. Once in production, monitor the performance to validate that it is meeting all the expected requirements—including functional and non-functional requirements. Make sure the service-level agreements are being maintained and the users are happy. Sometimes, just sitting with a user to see the actual end-user performance is one of the best tests. Call your partner or friend and have them perform a real live test if you can (for instance, a website that can be visited). As a formal Candle employee, I used OMEGAMON extensively.
There are several common strategies for application transformation that can be pursued. Before pursuing any of these approaches, make sure you fully understand the goals and the current state of the application. Ensure the time, money and resource commitment are validated before you proceed. This is very important because bad decisions can be costly in a number of ways.
Application Transformation Approaches
Let’s explore some of the most common methods for transforming applications.
Rehosting
One of the ways and one of the more popular approaches is “lift and shift,” perhaps better known as rehosting. Very simply, lift and shift involves moving the application to a new environment or platform, like the cloud. No changes are made to any of the application code, similar to moving to a new house. This is where many of the hyperscalers get involved to move the application to one of their cloud-based environments. As a mainframer, I believe some applications belong on a mainframe and shouldn’t be moved, as the mainframe has the power, security, scaling, etc. to support the application in the best way. Conversely, some applications can do very well in a hyperscaler environment and may be better off there. The right platform for the right workload.
Refactoring
Refactoring applications is another way to transform; it involves making changes to the application code. This may be done to improve the structure or its performance. As you can imagine, this can take time, but it can also be very beneficial as it can lead to solid improvements. This is a very complex and time-consuming approach that can be costly to undertake. Care should be given to understand the investment using this approach and ensure that it is warranted. Refactoring can be completed in versions or waves.
Rearchitecting
As a mainframe architect, I like the approach of rearchitecting the application, which involves designing the transformed application to take full advantage of new technologies with the system. It’s also more focused on using best practices. In the case of the IBM z16 system, running COBOL 6.4 simplifies programming in COBOL to interoperate with Java 8 and 11 programs. This can be a game-changer for the developer. Rearchitecting is by far the most complex and disruptive approach to transformation but will most definitely deliver very significant improvements in the application. I would like to call this coding for the future, because the code is not only brought up to current standards, but the new features of the system it is running on are utilized.
Rebuilding
The final approach to application transformation is rebuilding. This approach means to pitch what you have in the trash and start rewriting the code completely from the beginning. As you can guess, this is the most time-consuming approach to transformation, as all facets of code development are required. Depending on age and functionality, this may be the best approach for some applications. Just realize the time, cost and resources that will be consumed can be staggering—but the outcome may be exactly what is desired of the application.
The right approach for your application transformation strategy is determined by several of the factors that I have outlined. Whichever approach is right for you, a well-defined plan and buy-in from your stakeholders will lead you to success with your application transformation strategy.
After writing this article, I don’t think I will ever use the word modernization again…long live application transformation!