Once the applications being modernized have all been upgraded to a consistent language release level, the task of removing programming anomalies, or the results of bad programming habits, is easier. When resolving the confusion of deeply nested decision logic, for example, a standard verb approach can be used across all programs without having a different approach for each program’s language release level. After all, we are looking for consistency, and, wherever possible, greater simplicity. And, as with the release level update step, there are application tools that can automate this step.
The consequences of not removing coding anomalies are:
- Difficulty in rationalizing existing logic to newly reusable code because of “noise” caused by dead code, or code that is not even being executed
- Difficulty, or even impossibility of, restructuring program code for ease of understanding. For example, if performed paragraphs overlap, or include branches out and back to a paragraph, it is not possible to recognize candidate reusable logic. Reusable logic must be complete and have a single entry point for it to be consistently reusable.
STAGE TWO: RESTRUCTURING EXISTING CODE
ISOLATING BUSINESS LOGIC
For most accurate reusable business logic identification, any programming logic that is used for managing file or database access, screen management, or for general system management, such as CICS or IMS interaction, should be filtered.
The consequence of not filtering non-business logic is increased difficulty in identifying common logic that should become component services, if for no other reason than the amount of code that would have to be manually excluded. It is a much more productive use of the analyst’s time to review only true candidate business logic.
RATIONALIZING COMMON LOGIC
Once a project’s program code is clean, any programming anomalies have been removed, and non-business logic has been filtered, it is possible to apply pattern-matching techniques across all of the project’s programs to identify candidate common logic. This can be done either based on common data access for component or business rule services, or purely on common logic for reusable algorithms that could execute as component or business rule services.
The consequence of not performing this rationalization step to identify what is likely redundant, hard-coded logic within the same program, or across programs, would be:
- Added difficulty in simplifying future modernization efforts
- The inability to protect the organization from incorrect variances in system responses
- A reduction in reuse with an increase in complexity and cost of maintenance.
EXTRACTING BUSINESS LOGIC AS REUSABLE SERVICES