David S. Read

For years the phrase “system of record” was used by the IT team to connote the master database for a set of data (e.g. HR, Orders, Finance, etc.).  Different databases might be the “system of record” for a subset of the company’s data.  The key was to know which one housed the master information for each type of data.  These days the concept needs to be expanded.  The “system of record” must include business rules since business rules give our data its meaning.

As enterprises have moved toward service oriented architectures, one of the main advantages is to allow rapid access to data.  New applications, including those from external stakeholders (vendors, partners, customers), allow for further streamlining and automation of business processes.  These integrations allow our systems to be accessed by an arbitrary collection of applications.  The rules around our business operations must be automatically enforced regardless of the path by which the information arrives within our infrastructure.

In order to provide for the consistent application of rules when interacting with our data, it is the business rules which must filter the access to data.  Rules such as credit checks, minimum order quantities, user validation and so forth must be consistently applied whether the information is being manually entered into an application of our own creation, arriving via a web service call or read from a batch file.  This consistency is provided by the business rules, not the database.

Beyond these simple examples, consider that many organizations change their interpretation of data based on shifting regulations or updated business strategies.  In many cases the data needs to be interpreted as of a specific date (for instance a date of service in the health care space).  That changing interpretation, which might include situations such as why a claim was denied or the requirement for a certain minimum coverage, is something that is best managed in a business rules environment.

Since the business rules provide the context for the interpretation of data, enterprise IT environments must strive to integrate systems at the business rule level rather than at the database level.  As the products around web services have matured we can now more easily achieve this goal.  By presenting business rule environments as services, rather than tightly integrated point solutions, the ability to allow multiple applications, our own and those of partners, vendors and customers, to share the same rules is simplified.

Competition these days is more about streamlining processes and data transparency, both of which require integration of systems.   It is therefore critical that businesses make such integrations quick and painless.  Integrations at the data level lead to inconsistent results, since the interpretation of the data is left to separate applications.  Integration at the business rule level prevents such issues, ensuring that flaws and misinterpretations of rules in external systems do not lead to inconsistencies in our data.

A further advantage of driving all data access through the business rule layer is that the complexities of the database environment are hidden.  Even though we may have multiple databases, redundant data or denormalized designs, the work to unify that is done once, behind the rule environment, and all integrated applications are isolated from that.  Obviously if the data structure is refactored, only the integration with the business rule tier needs to be updated.

In addition, companies concerned about compliance with laws such as Gramm-Leach-Bliley (GLB) and Sarbanes-Oxley (SOX) also win with this approach since the business rules are consistently enforced when they sit between all applications and our corporate data.  From a compliance reporting and auditing perspective this is vital.

Having carried out integrations in both ways (data-centric and rules-centric) I can guarantee that the effort to create the standards around rule-based data access will payoff handsomely as you benefit from the consistency of data interpretation and business rule enforcement.

Tags: business rules, system integration, web services

This entry was posted on Friday, February 20th, 2009 at 23:36 and is filed under Architecture. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.