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. (more…)