Written By: Sudhanshu Dubey, Open Mainframe Project Summer Mentee
Let’s do a quick recap before we start with this blog. In the introductory blog I briefly described my project “COBOL Modernization” for the Open Mainframe Project Mentorship 2020. The Modernization process I used for this demo of a monolithic COBOL banking application has 4 steps:
- Analyzing the COBOL Application.
- Identifying services candidates.
- Isolating and exposing them as services.
- Connecting them to a new, modern UI.
Then in the next blog I talked about the first step of analyzing the COBOL application. So today, as the title of this blog implies, I will explain the details of identifying the service candidates. I am calling them the blueprint of the modernized application because they decide what your modernized application will do and what it will not. This is the final planning step as after this there is only implementation of the plan that you create here. So you better get the managers involved in this one. In fact get all of your team involved. I will explain why and how.
Service Candidates?
So when I say service candidates, I am talking about the parts of the legacy application that you are planning to isolate and expose as individual services. Now one thing that I would like to emphasize here is that the goal is to only isolate parts of the code. We are not planning to rewrite them or make big changes. The COBOL will remain COBOL just in smaller, individual, more manageable components. Clear? Good.
The candidates are identified based on:
- High business value
- Low degree of required code change
See, we are trying to maximize the gains while keeping the disruption as low as possible. Each candidate after extraction and isolation should result in:
- Increased speed
- Minimal required testing
- Lower risk
This is why this planning is very essential and should have the whole team onboard. Now let’s explore the different perspectives of this important decision.
The Analyst’s Perspective
The analyst is the one to start the conversation. This person has done the analysis of the application in the last step and so they know the application’s architecture very well. Quite obviously having the detailed understanding of the monolithic application is a pre-requisite to identifying service candidates. So the analyst should start by explaining the application’s current architecture to the team and then suggesting the parts that they think are tightly coupled and are somewhat independent from the other parts.
The Manager’s Perspective
The product manager has the best understanding of the business. They know exactly what the company is expecting from this modernized application. They know the business requirement. And so their goal is to maximize the business value of each service and accordingly they will pick the candidates.
One thing to note here is that there is something called the “business rules”. Business rules are an advanced way of documenting the code with additional information like the overall action that a set of lines perform. Basically, if you add to the current documentation what these specific lines mean for the overall business goal of the application then you are creating a business rule. These business rules are very helpful for the manager in picking service candidates if they already exist. If not, they should be created by the analyst during the first step.
The Developer’s Perspective
The developer is the person who has to actually implement this plan and it might sound lazy on their part but they should pick candidates that require minimal code changes. The simple reason is that we want to retain as much of the efficiently working code and logic as possible. It really doesn’t makes sense to disrupt something that has been performing consistently well for ages.
Now I have been emphasizing on minimal code changes because I know that “no code change” is impossible. You do need to adapt these services to the new UIs. But even that should be done in the least destructive way possible. For example you can make additional driver programs that act as an intermediate between the new UI and the service. The goal of modernization is to improve upon what’s already there without unnecessarily destroying what’s already there.
The Tester’s Perspective
Yes, they also have a say in this. After all you are changing a perfectly validated and approved application. So a tester, somewhat similar to a developer, should look for minimal testing while assuring the changes still work the same as the old application. Why? Because testing represents risk and we’re looking to minimize risk. If a large test effort is required, that is a measure of how risky the project is. But another way to look is that minimal testing means that the unit test cases already built for the monolithic are applicable to the services too. So yeah, for a tester the ideal service candidate would be one requiring minimal testing for itself.
Now the final candidates that should be picked are those that satisfy the need of all the team members to the maximum extent.
Our Case
So in our case, I was the team. I was the manager, the analyst, the developer and the tester. But it was a pretty inexperienced team and we had no business goals to achieve by modernizing our demo application. So I had a free reign. I tried to follow all of the principles and rules that I have stated above but it wasn’t perfect and in one case my curiosity got the best of me.
But anyway, I picked 4 candidates for modernization and our target architecture looked like this:
Target architecture
For more details on what these services do, check out the documentation in the repo. And if you want even more details, well, read the detailed design.
So while you’re waiting for my next blog, why don’t you check the COBOL Mentorship Session from the recently concluded Open Mainframe Summit whose session recordings are now publicly available on YouTube. In this session, my fellow mentees and I talk in brief about our respective mentorship projects.
Stay tuned.
