Retooling entrenched business processes requires retooling one’s information systems. This may involve replacing systems or, in other cases, significantly reworking those systems. In either case, knowledge of the underlying rules that govern those systems is essential to understanding how the business works as well as how replacement systems can better support your business.
This article uses a real-life scenario to outline how business process redesign, top-down data and systems redesign and bottom-up analysis of an existing system were combined to create a specification for a replacement system.
Numerous users, across multiple service areas of a large organization, had been doing business in a highly customized fashion for the better part of three decades. The users defined their processes in terms of the existing accounting system. One team set out to document these processes and how they could be streamlined or improved. A second team set about defining a new systems architecture, including a new data and process model.
The third element of the project involved understanding how the current applications worked. This included identifying all system artifacts, the applications to be replaced (versus interfacing systems that must remain intact), the data used by the current system and essential to the target system, and the rules embedded in the existing application.
While there were many aspects to this project, the focus of this article is on the extraction of business functionality from the existing system for purposes of validating top-down design models and ensuring that the replacement system fulfilled essential business requirements. The first phase of this effort involved understanding the business data used by the system, while the second phase involved business logic extraction and analysis.
The project’s first phase involved understanding business data. The second was business logic extraction and analysis.
Prime Data Definition Extraction and Analysis
Once an accounting of existing application artifacts was in place, the team set about identifying prime data structures within the existing application that could be used to inform the creation of the new data model and provide a basis for business logic extraction. This involved:
- Identifying all data entering and leaving the existing system
- Using an analysis tool to capture record definitions used within the system
- Employing record group analysis to identify essential business data
- Extracting persistent data definitions owned by the system being replaced
- Providing data usage information to business and data analysts
A combination of manual and tool-assisted analysis identified all data interfacing with the accounting system. Extraction and identification of prime data structures used within the system, however, was significantly more automated. The analysis found that the system had hundreds of record definitions that decomposed into a subset of common groups. The team analyzed each group to identify data that was essential to the business.
For example, the analysis found three unique, yet overlapping, Address Masters. A composite view of these three Address Masters was incorporated into the new data model. The team then used data elements from the prime record structures as input to business logic extractions.
Business Logic Capture, Filtering, Packaging and Analysis
In preparation for rule extraction, analysts conducted interviews, reviewed system inputs and outputs, and examined documentation to map business processes to various program clusters. This high-level functional decomposition, coupled with more granular business logic extractions, ensured that automated logic extraction was augmented by human knowledge about the system and business.
Business logic is a bounded set of conditional and imperative statements, contained within a software artifact that relies on and directly or indirectly impacts business data. A rule on the other hand is a description of how a business works. Obtaining business rules from existing systems involves an extraction, filtering, packaging and analysis process that follows several steps, as described below.
- Leverage high-level functional decomposition, typically performed as a precursor to logic extraction, as a guide to identifying major functions and sub-functions across an application.
- Use prime record definitions, as discussed previously, to identify data elements of interest that could help identify related business logic.
- Narrow the scope of the logic extraction process to modules and programs related to functional topics of interest.
- Filter operational logic from the logic extraction process. This involves the process of ignoring any logic that is not directly impacting prime business data or otherwise defining a business rule.
- Agree on a delimitating factor to define logic blocks with a defined start and stop point. For example, extracted logic may be related to a given data element and bounded by a conditional statement.
- Use automated analysis tools to feed data element requests into the logic analysis engine.
- Review each rule for validity to ensure that it represents useful logic from a business perspective.
- Capture, categorize and store the business logic along with the relevant information about the source of the rule.
- Package business logic into a form that can be viewed by subject matter experts and used to create or validate business rules or otherwise understand system functionality.
Figure one shows the extracted, filtered and packaged business logic that was taken from the accounting system in this example and illustrates the format used to deliver extracted functionality to a top-down design team. The business logic extraction tool used in this project was told to find every logic block that contains the element “REGION-CODE” and is bounded by a conditional statement. Synonyms were automatically identified by this particular tool.
To ensure that only business logic was captured, industry accepted guidelines for filtering certain logic from the analysis process were employed. These guidelines include filtering out logic that is not related to business functionality, but is rather tied to the physical implementation of a system. For example, most application logic is used to change file names, sort files, merge files, test status conditions and so on. The replacement system would typically supplant this functionality and, therefore, any program logic related to these processes should be ignored.
Once captured, business logic analysis may be performed by subject matter experts and other individuals who are performing the top-down analysis. For example, figure two shows how captured business logic was analyzed and decomposed further into a business rule.
Business rules, once in this format, can be used for many purposes. In this project they were used to validate a target systems data and process model that was initially based on business process analysis efforts gleaned from business analysts. Without the system interface analysis, bottom-up data analysis and business rule extraction, the top-down team would have omitted essential functionality from new system design models.
In summary, when complex applications are being replaced, it is important to understand system data and functional requirements that need to be retained and reused within the new system. As a result, organization will increasingly need to couple bottom-up analysis of existing systems with business process retooling efforts.
