As companies plan modernization projects, the question inevitably arises: what is the best way to modernize a codebase? To ensure that the business is not negatively impacted when modernizing, it is necessary to understand, document, and import all business rules to the new system. As the changes made are meant to improve the business and increase efficiency, the rules themselves must not be altered. The continued success of the business depends on this.
Unfortunately, too many people see a modernization effort as a chance to rewrite everything from scratch and make it better. This might work if business rules were visible as distinct chunks of code; they could then be analyzed, as with every other code function, to create a better-functioning application. Instead, business rules are strewn in snippets throughout the code, rarely documented, and extremely hard to find. And yet, without extracting this logic, the odds of creating a system that accurately reflects business needs are very low.
Understanding this makes it clear that the first step of any modernization project has to be business rule extraction. Then the problem becomes how to go about it. It is first necessary to understand what a business rule is. Business requirements are define the needs of the company, and the business rules define how to meet those needs. The business logic is the code, and defines how the business rules are enforced. The logic is often tightly bound up in the architecture and the process. Teasing out the rule/logic relationship is difficult because the original business requirements document (if it exists), has likely changed over time, and changes are often poorly documented or undocumented altogether.
Some projects have attempted to manually scan the code and assemble the rules. Not only is this time-consuming due to its difficulty; it is also fraught with risk. The process relies on the knowledge and experience of the analyst, and since the original developers are probably long gone and never documented the system, the odds of failure are quite high. Even if documentation was written originally, subsequent changes to the application probably weren’t included.
To make things even more challenging, the business itself may not be able to help. Communication between IT departments and the rest of the business has only improved slightly over the years and there is often a huge disconnect between the the two groups.
Having ruled out a manual approach, the only logical alternative is automation. CM evolveIT offers a way to analyze code automatically, linking up the code snippets that underlie the business logic and displaying the paths it traverses. Better yet, the analysis is ‘self-documenting,’ which results in clear, documentations of the business rules, perhaps for the first time. This process is quick and accurate, expediting the next phase of any modernization project.
Check out CM evolveIT here. Making this solution the first step on the modernization journey will ensure the success of the project.
