Business Rules in Code

Capture and Leverage COBOL Business Rules for Better Modernization

As any IBM mainframe enterprise IT shop is aware, meeting the challenges of modernization is a critical effort in order to keep up with competitors who may be investing in API microservices, big data, and advanced technology like blockchain implementations.

Beware the Migration Time-Suck

Since business rules are essentially how you define your business, to begin moving forward, the first step is to identify hard-coded business rules in the millions of lines of COBOL code – a job that used to take weeks, if not months. The challenge: when you’re dealing with a mass of millions of lines of mostly untested, undocumented COBOL code built up over decades, it takes an enormous amount of effort and money to tame them. For most, it’s harder to read code than to write it.

However, by using CM evolveIT jobs like that can be completed in a few days.

How CM evolveIT Solves It

CM evolveIT is the single most efficient, effective system of its kind on the market today for analyzing and documenting mainframe systems. Where CM First’s CM evolveIT really sets itself apart is in its unique technology and methodology for capturing the business rules from existing legacy applications.

CM evolveIT’s rules capture identifies specific source code paths that are relevant to the ‘business rules’ while filtering out the non-essential information found in the many millions of lines of code. It accomplishes this by performing interactive backwards slicing on program results that is specifically designed to weed out the noise of the application. It then generates convenient diagrams of the resulting logic. It aligns the application logic with business process documentation and generates system diagrams that visualize the information so it can be effectively shared, improving communication between IT and the business.

For the many companies who see the value of keeping their mainframes, CM evolveIT is a go-to solution for understanding, maintaining and improving legacy code bases. It’s time to stop fantasizing about moving off the mainframe and start modernizing, or at least fix, your COBOL programs instead using new tools and processes.

Read the Excerpt of White Paper “Capturing Business Rules in COBOL Systems”

What are Business Rules?

In a very real sense, an organization’s Business Rules are its business – they determine how it responds to external and internal stimuli, and what outcomes it strives to achieve. The combination of suitably chosen Business Rules (there is probably no such thing as a “right” or “wrong” Business Rule) together with appropriate enforcement policies, result in a successful business. Business Processes define the steps that have to be taken to apply the Business Rules.

Business Rules and Source Code

A business rule is not typically just a small set of code that resides in a single program. A business rule is most often implemented through a series of code snippets that are spread out across the multiple components and millions of lines of code that make up your mainframe application. Furthermore, Rules and Logic are often confused. Business Rules– affect a business outcome. Business Logic– enforces a business rule.

The Rule Tells you what the business must do
The Logic Tells you how the rule is enforced

Why is the distinction necessary? Rules are free of process and architecture. They are implicit in code. Logic is tied to process and architecture. On-line systems will typically apply all the rules to each customer in turn. Batch systems will typically apply part of a rule to all customers, and then apply another part of a rule at a later time before an outcome can be determined. Mixed systems often have duplicate logic, share logic and even have logic that adjusts the results of badly shared logic! The actual logic enforcing a business rule can thus be overly complex, distributed amongst many paragraphs, sections, programs and time. The rule/logic relationship is rarely documented, so changes over time adds to the complexity and confusion.

  1. Only IT systems know what actually happens.
  2. Other sources provide an easy ‘heads up’ on what to look for.
  3. Ultimately, you need to mine code to find or verify rules, look for exceptions and check that
    your IT systems do what the business expects them to do.

To read the full White Paper, click here.