For a number of years, I have been struck by the way in which the topic of meta data is approached by IT professionals. It often seems that there is an assumption that every specialty in IT has its own set of meta data that can be known in advance, and there is no effort needed to discover what meta data might be necessary in any given situation. Indeed, people often talk about "the meta data" that is required for a project, as if no discussion is required about what this meta data consists of. There is no doubt that meta data exists for every project, but just because it exists does not mean that it is useful and needs to be managed. It is not the fact that meta data happens to exist that should drive meta data management. Rather, it is business requirements that should dictate what meta data needs to be managed.
A second disturbing trend is the "Roach Motel" approach to meta data management. Roach motels were (and maybe still are) roach traps that were advertised with the slogan "The roaches check in but never check out" - or something like that. Many projects concerned with meta data seem to collect meta data and place it in a repository that is difficult to access, or which nobody wants to access. The meta data is trapped, but no value is obtained from it.
These problems with approaches to meta data have contributed to an increased wariness by user management when it comes to meta data projects. The worry is that these kinds of projects do not have a great return on investment. Yet business rules are nothing if not meta data, and so it is reasonable to ask how to approach "business rule meta data" if a business rules project is to be successful.
What is Meta Data?
Meta data is usually described as "data about data," which is rather an unsatisfying definition. In reality, "data" is often used to identify data that end users update in physically implemented databases, and meta data is other information that is somehow related to this data. From this perspective, meta data often boils down to being mainly data that is important to IT professionals but which is not updated by end users. The problem is that rather than there being a finite, knowable set of meta data in any given situation (as many IT professionals seem to suppose), there is in fact a potentially infinite amount of meta data. A database design may include meta data about the definitions of entities and attributes. The sources of these definitions are also meta data, as are the names of the people that compiled them, the points in time when these definitions were compiled, the versions that the definitions went through and the reasons why any definitions were changed. Similarly, there can be extensive meta data related to security, authority, ownership, stewardship and so on. Furthermore, if a given set of data is reused in a new context, it may spawn even more dimensions of meta data. For instance, bank account data is routinely maintained by the bank's back-office systems, but it may be reused by systems that attempt to detect money laundering. Money laundering detection systems have their own perspective on meta data, including a lot of business rules to detect questionable sets of transactions. It is simply impossible to put boundaries or limits on meta data.
What about Business Rules?
Understanding that meta data can be infinite in any situation means that attempting to manage all meta data that can possibly exist for business rules can be a journey with no end. Just because meta data exists does not mean that we have an obligation to capture it or manage it. Rather, in a business rules project we need to be driven by requirements. Yet, with the increasing awareness of the business rules movement, many organizations are thinking about sponsoring business rules projects because business rules are "the right thing to do." In these situations, the requirements definition phase seems to be bypassed and, of course, gathering requirements is not necessarily simple. In particular, defining a requirement often forces the question of why the sponsoring organization would want such a requirement met and if the cost to meet it is justifiable. However, only if requirements can be defined can we begin to identify the meta data that really has to be managed to successfully implement a business rules project.
Common Business Rules Meta Data
While meta data about business rules can be potentially without limit, it is often the case that there is a basic set of meta data that is required to define business rules. This basic set of meta data may vary, depending on requirements, but it typically includes entity and attribute definitions for the data upon which the rules operate. It also usually includes reference data values, that is code values used to segregate different records within a database table. For instance, individual customers may have different rules compared to corporate customers, and a code value for Customer Type in the Customer table is used to differentiate these two kinds of customers and so is used in the rules. Figuring out a basic set of meta data that is needed for rule definition should not be difficult after project requirements are gathered. Where care is needed is in determining which additional meta data is required. Only meta data needed to meet project requirements should be managed. It is critical not to succumb to the temptation to capture business rule meta data for no other reason than it exists, and whatever meta data is captured must provide value.