Since I got started in this business, one of the most critical success factors has always been business-IT alignment. Yet in all these years, it seems that we still struggle to communicate clearly with our business partners. This results in customer dissatisfaction (both our company’s customers and our business partner’s customers), frequent and urgent code modifications and often, more technical debt. It doesn’t matter whether you’re simply making requested code changes or building a new business system; on the journey to deliver quality systems, if you don’t know exactly where you‘re going, you’re much less likely to get there.
The main problem is finding a common language. Mainframe coding languages are never a direct, line-by-line interpretation of what the business wants as an outcome. We have to layer in things like I/O management to make it all come together into something the processor can interpret. Data structures and business logic may be found across the code base, and we know how little documentation exists to explain the choices past developers have made. We think in terms of coding logic, but the business thinks in terms of business rules.
Business rules are, according to the Business Rules Group,
“a statement of structure or constraint that the business places upon itself or has placed upon it. Each business rule statement may be related to one or more other business rule statements. A business rule is a statement that defines or constrains some aspect of the business, but (in contrast to a business rule statement) it cannot be broken down or decomposed further into more detailed business rules. If reduced any further, there would be loss of important information about the business. Each business rule may be based on one or more business rule statements.”
While these definitions may be a little unclear, what you need to know is that when these rules are put into code, the logic defining them may be hard to trace through the program or programs where they reside.
Business rules are how companies make money. They represent value, but like caches of diamonds, they can be very hard to find. When challenged to web- or mobile-enable your code, you will often find that the lack of knowledge of what the code is really doing will hold you back. When you can’t modernize the code, management begins to consider other, non-mainframe options, so you need a way to analyze your code from a business perspective.
With millions of lines of code to examine, no time for this careful work and a high risk of missing something critical, automation is the only way to find business rules and document them. The right automated tool will not only connect the code points to define a rule—it should also clearly display the connections in a way that gives both IT and businesses the power to discuss necessary changes. The tool will use code slice path analysis, data mapping and more to deliver a clear picture of the business without the hard work of manual mining. Even better, the best of these tools may point to technical debt issues so you can readily resolve these as well.
But we’re also optimistic that we will get the chance to create new applications once we show how well the mainframe can continue to deliver on business expectations. You want to look for an automated code analysis tool that will help you do this analysis even during the development of new applications, automatically creating the documentation you need to ensure successful results.
Check out the world of automated code analysis as part of your journey to keep the mainframe alive and thriving. Expect to be surprised and delighted as you see your code in a new way—the way a business sees it. A world of opportunity awaits the better informed developer.
Denise P. Kalm is chief innovator of Kalm Kreative Inc.