Nobody really cares about standards… until suddenly they do. When a standard reaches some threshold of adoption, a tipping point is reached. Then, if you’re not on the standard you’re proprietary....

Understanding Business Data: The Key to Business Rule Extraction

Large-scale information systems are impacted in a variety of ways as organizations retool business processes and undergo related transformations. Whether migrating, redesigning, consolidating or replacing existing systems, analysts need to gain a better understanding of underlying systems functionality.

Understanding existing systems, however, is a major challenge, especially if analysts do not understand the business data used by these systems. This article discusses the justification and approaches to understanding business data from the perspective of a business rule extraction initiative.

Why is Business Data Important to Business Rule Extraction

Every substantive information system contains business data and operational data. An example of business data would be an Account Code or Customer Address. An example of operational data, on the other hand, would be EIB Status Code, which is a status code used to test results of an online CICS transaction. Business data is essential to the underlying viability of an organization and, therefore, the focus of business rule extraction efforts.

Consider an effort to consolidate and streamline two insurance systems with similar functionality. The data and business functionality within those systems must be reconciled and rationalized into a common subset. Extracting customer and claims data from those systems, identifying data redundancies or inconsistencies, and consolidating this data into a common subset are critical steps in a consolidation project. This business data then serves as the foundation for business rule extraction and consolidation.

Even if a system’s functionality is being redesigned from scratch, existing business data must still be incorporated into a target data model. For example, a government billing system was being redesigned and the new data model had to incorporate key billing data from various service areas. This was accomplished by extracting business data from the existing system and using it to validate the top-down model.

Business Data Extraction

Extracting meaningful business data from systems is manageable primarily because it is a tool-supported process. Consider a project that had to extract accounting data from an aging system where most subject matter experts had retired. The following steps were used to extract meaningful data from this system.

• Obtain all relevant system artifacts, including source code, data definition language, batch and online control table, scripts and job control structures, and other artifacts that makeup the system.
• Use an analysis tool to capture and organize all data definitions into common data groups (e.g. record, table or segment). The grouping criterion includes linkage to external data structures, transference relationships (e.g. CALL, MOVE, etc.) and group length.
• Streamline data groups by filtering out data not directly or indirectly tied to a physical file, database, user interface or other external structure.
• Review and filter out data groups that do not represent business data. For example, a table used to control batch job flow would be omitted.
• Select a subset of data groups of interest, based on project-specific goals, by working with system subject matter experts.

This approach provides analyst teams with a foundational set of business data that can be used to perform business rule extraction. This analysis also provides analysts with the basis for validating top-down data models or creating, bottom-up normalized data models from existing business data.

Using Extracted Data in Business Rule Extraction

Business logic within existing systems references business data. Business data is typically tested to determine a specific condition that triggers a specific action or modifies related business data.

For example, assume analysts found a data group called SALES-REVENUE-INPUT. This group represents data that is relevant to furthering the sales processes within a business. Detailed data elements can then be reviewed by examining a layout of this data group along with related data layouts.

“SALES-REGION” was one such element identified in our example by reviewing the SALES-REVENUE-INPUT data group layout. Analysts fed this data element into a business rule analysis tool to obtain the following logic extraction result.

IF SALES-REGION = “8”, “9” OR “11”

ADD SALES-AMOUNT TO REGION-TOTAL

ELSE

MOVE “INVALID REGION” TO USER-MESSAGE.

This and other rules tell analysts how a system currently performs. Because systems have a wealth of logic that can qualify as business rules, a rule categorization scheme is useful. A data oriented approach to business rule extraction provides a natural means of rule categorization. In the above example, all business logic related to SALES REVENUE can be grouped together for top-down design analysts or other knowledge workers requiring this information.

As one can see, using business data as the foundation for business rule extraction is a natural and effective means of ensuring that business rule analysis meets project objectives. This approach provides a way to streamline and categorize business rules in a way that makes them useful for a variety of purposes.

William Ulrich is President of Tactical Strategy Group, Inc., Co-chair of the OMG Architecture-Driven Modernization Task Force and author of “Legacy Systems: Transformation Strategies”. He may be reached through his web site at www.systemtransformation.com.

William Ulrich's Training Course

Back to Articles, including BPM, SOA, BDM, BA & OP