Traceability means different things to different people, even within the reasonably narrow confines of business rules.  At a broad level, traceability means the ability to link disparate pieces of information, leading to coherent knowledge.  The purpose of this article is to shed some light on some of the traceability aspects, in the context of business rules, and show how traceability can be gradually built in over a period of time.

In traditional systems development we have data and programs.  Business rules falls in the twilight zone between data and program code and, as such, inherits characteristics of both.  But there are some subtle differences.  Business rules are discrete and atomic.  Pure business rule systems are non-deterministic.  Programming is procedural.  Data is the input and byproduct of programming systems.  Business rules act on data and produce action.  Yet when a large and complex business application is decomposed into a system of rules, the rules component in itself represents tangible knowledge about the application.

Another consideration is that business rules represent discrete non-deterministic statements about the problem domain and, as such, need to be viewed and assimilated in the context of the business process.  This brings us to the subject of traceability of business rules.  Business rules are at the core of an enterprise's operation and bring together different players within the organization.  These different players tend to look at business rules from different viewpoints or angles.  For example, members of the executive committee of the organization would like to know how business rules implement the high-level business policies they have put forth.  Sales would like to know which of the business rules effectively improve their Sales metrics — and which do not.  Customer Service would like to know how automated business rules decrease their customer call volume, thereby alleviating the pressure on their overworked Customer Service representatives.  Information Technology would like to know how business rules trace to the different sub-systems that they maintain and to determine how the externalization of business rules is aiding in the overall ease of maintenance of the system.  As you can see there are different people and communities within the organization that have diverse traceable informational goals out of the business rules.

A typical roadmap for an organization going down the path of business rules starts with a pilot project.  If the project team and the scope are sized correctly the methodology and technology has the propensity to yield excellent results in a very short period, which can cut down conventional systems development time by a magnitude.  With a positive result new projects spring up, and soon we have a magnitude of enterprise knowledge invested in business rules.  This is why traceability is paramount to the success of any business rules venture.  Traceability from a tooling perspective is achieved through incisive reporting.  As the business rules approach gains acceptance in an organization, the number of business functions that business rules address increases.  The number of rules to manage increases.  Traceability-oriented reporting from the Business Rules Management (BRM) application soon becomes a very important tool for the Business Rules Governance function.

In this article I present a number of key traceability aspects.  I also specify how we have implemented these traceability aspects into BRIDE, which is our Business Rules Management application.  BRIDE is an acronym for Business Rules Interactive Development Environment.

Vocabulary Traceability

The key component of business rules is business vocabulary (terms and facts).  To that end, when faced with a pile of a few thousand rules, it is very useful to have the ability to search by vocabulary and to report rules usage for the vocabulary.  Vocabulary Traceability can be achieved by building search screens within the BRM application that is vocabulary aware.

This was one of the first kinds of traceability we implemented within our rules application, BRIDE.  Vocabulary Traceability allows the user to query for rules with a combination of vocabulary and furthermore report on it.  This functionality is turning out to be a must have functionality amongst our Business Rules Analysts.

Core Terms Traceability

Depending on the rule functionality or realization, there are always one or more terms that are very commonly used in the rules of that realization.  For example, in our Health Insurance Claims adjudication-related realization 'procedure' is a core term.  A large number of rules reference specific procedure codes.  Furthermore there might be very specific functional requirements around these terms that would mandate a specialized treatment from the other vocabulary.  This kind of traceability traces a core term to all the pieces of vocabulary that address it.  You can then trace back to all the rules that use that term.

Core Terms Traceability is very similar to Vocabulary Traceability, with the following distinctions.  You could have different pieces of vocabulary referencing the same term — for example, the terms 'input procedure' and 'history procedure' each reference the term 'procedure', but are two different vocabulary entries.  Also we might want to have some specialized handling of certain core terms.  For example, the user might want to know which rules reference procedures from a specific version of the Current Dental Terminology.  (This is something we have not yet implemented but foresee doing in the future.)

Rule Reuse Traceability

Business rules are like Lego blocks and can be put together to enforce the policies for diverse business requirements.  As such the same business rules can be reused in different rule-sets.  With reuse we need the ability to trace forward to all the rule-sets using a specific rule or a given combination of rules.  Rule reuse traceability should work:

• Top-down — from the rule-sets to the rules that constitute the rule-set.
• Bottom-up — from the rules to the rules sets that use the rules.

This was again one of the initial traceability aspects we incorporated into BRIDE.  Rule Reuse Traceability allows us the ability to search for rule-sets (we call them 'Rule Packages' in BRIDE) with specific configurations.  This is a powerful traceability aspect as this allows us to take stock of our inventory of business rules and shows us the reuse of the rules between rule-sets.

Temporal Traceability

At the broadest level Temporal Traceability is the ability to trace business rules to the date/time they take (or lose) effect.  That said, the implementation of temporal traceability could vary from application to application.  For example, we might want to have effective dates on the rule-sets instead of on the individual rules.

Temporal Traceability can be one-dimensional or two-dimensional.  One-dimensional Temporal Traceability is the ability to trace back to a rule or a set of rules based on an effective date.  Two-dimensional Temporal Traceability is the ability to trace back to a rule or a set of rules based on an effective date and the query date (the date you pose the question).

We have approached Temporal Traceability in a different manner.  We have kept our rules and rule-sets agnostic of effective dates.  Instead, integration points to rule-sets in the domain have the effective dates.  We have kept our rules and rule-sets as Lego blocks that can be used and reused by different clients for different effective dates.  But the ability to trace back to what is (or was) effective is still there.  Rule-sets for assorted functionality are decorated into a rule component with effective dates.  In this way the rule-sets themselves are reusable, agnostic of effective date.

Business Policy Traceability

Business policies are high-level objectives of a business that influence the rules of the business.  As such it is very important to know where a rule comes from and what business policy it enforces.  It is important to be able to search for and report on business rules applying a certain business policy.

This traceability can be achieved by having vocabulary targeted at specifying the policy that is being applied, which can then be incorporated into each rule.  This technique best works for Production Rules.  Business Policy Traceability can alternatively be achieved by capturing this information as meta-data, with the BRMS tooling having functionality to associate the rules and related policies.  Either approach works, depending on how explicit or implicit we need that association to be.  In either approach a policy cataloging -system should be in place for categorizing and capturing elements of Business Policy.

We have incorporated this traceability into our BRM in a fairly seamless manner.  Our infrastructure for holding policy data is pretty sophisticated.  These policies derive from various sources, — contractual, processing policies, statutes, mandates, etc. — and are targeted to different interfaces like IVR (Interactive Voice Response), EOB (Explanation of Benefit), Contracts, Help manuals, etc.

Services (SOA) Traceability

The business rules technology base is a collaborative technology base that best works in collaboration with a Services Oriented Architecture (SOA).  A 'service' can be thought of as a higher-level, coarse-grained component, which is reusable across the Enterprise.  A service could encapsulate (or wrap) the invocation of one or more disparate rule-sets, to achieve a higher, discrete business function.  These services in themselves are like individual Lego blocks that can be reused to build other pieces of the enterprise.  Several services could use a given rule-set.

Services Traceability is the ability to trace the use of a given set of rules to the different services that use it.  As SOA gains wider adoption, this is getting to be a very important aspect of traceability and this is a kind of traceability we foresee helping us tremendously in the future.

We are using Service Oriented Architecture for our Enterprise Technology Solution.  The services we are deploying execute different rule-sets behind the scenes.  By changing rules we can now assess the far-reaching changes by tracing back to the services that are involved.  This is a capability we do not currently have — we started our pilot with a set of core traceabilities.  But we plan to incorporate this in future releases of our solution.

Work List Traceability

Another collaborative technology that works extremely well with business rules technology is Business Process Management (BPM) or workflow-based technology.  In workflow-based technology, computer software automation is interwoven with manual functions in a nearly seamless manner.  Business rules collaborate, orchestrating the decision-making processing in a workflow-based architecture.

There are certain aspects of a business that are inherently hard to automate.  For example, in a Medical Claims Processing system the adjudication of a certain expensive medical procedure is based on the study of the relevant x-rays by an expert physician.  But the ability to decide on the fact that the x-ray for the procedure needs to be examined could be done through a business rule.  The integration point with a manual activity (such as the above) in a workflow is called a Work List.  A Work List is a task accumulation point that is manned by a human actor.  Based on the volume of work or data being processed by the system, the decision to move the document in the workflow to a Work List needs to be a judicious and scientific one.  To do that we need the ability to trace the specific rules that route decisions to a Work List.

For example, in our Claims Processing system we have built this traceability into our Business Rules Management application.  It helps us closely monitor our "drop to pay" ratio, which determines the percentage of claims that get adjudicated automatically.  The other usage for this kind of traceability is the ability to throttle the claims volume that is directed to specific Work Lists or departments.  This is really crucial for agility and adaptability.  When a department's employee strength is affected for some reason due to unforeseen circumstances, Work List Traceability allows identification of the rules that would route claims to Work Lists in that department and then re-routing or automating them, as the case may demand.

Test Case Traceability

With the advent of Agile Development methodologies for software development, Test Driven Development (TDD) is starting to gain in popularity.  Test Driven Development requires that an automated unit test, which defines requirements of the code, is written before each aspect of the code itself.  A business rules architecture should employ a strong testing framework that allows the business users to test business rules in a standalone fashion. 

Over a period of time the number of rules and rule-sets increase, necessitating a strong scaffolding of regression test cases.  The execution results from these test cases should be able to be compared with the captured expectations for the test cases.  Such a mechanism offers a quick way of assessing impacts.  With Test Case Traceability we are able to measure the coverage provided by the test cases.  This is becoming an increasingly important traceability aspect as the need for strong auditing and accountability grows.

We have integrated a powerful test harness into BRIDE to provide regression testing capabilities and also powerful search and reporting capabilities.  For example, we can search for test cases that satisfy certain test data criteria, execute them, and report on the results of the regression run.  These reports also provide performance metrics.  Furthermore, we can capture positive and negative test case expectations.  The Testing Console is capable finding test cases by the rules they exercise.

Processing Traceability

This is one of the most important traceability aspects.  In Processing Traceability, we trace the execution path of the different business rules that fired during the processing of a given business scenario.  For example, when adjudicating a given claim we can determine the rules that were violated during the process.  In a traditional procedural system this kind of tracing was not readily available since the system itself was pretty much a black box.

There are two ways to implement Processing Traceability.  I like to call these:

• Proactive Processing Traceability:  In this form of Processing Traceability, we provide hook points in the application architecture to capture the actual rules being fired when the application is running; this information is stored in a database for reporting and Business Intelligence use.
  
  
• Reactive Processing Traceability:  In this form of Processing Traceability, we reach into the business application and reverse engineer a test case for a processing scenario.  These test cases can be stored and rerun later.

 Both these forms of Processing Traceability can be collaboratively used.

Again, this is one of the first traceability aspects we integrated into our architecture.  For example, we can capture the rules that fired during the adjudication of a claim.  This helps our Claim Specialists narrow down an issue with considerable ease.  We have incorporated both these forms of Traceability within BRIDE.

Deployment Traceability

When dealing with Production Rules that need to be deployed to an application running in production, we need the ability to trace to the specific deployments for a given rule-set.  This helps the Business Rules Analyst keep on top of changes.

This aspect of traceability was one of the later ones to be implemented, but nevertheless it is an important one.  This, in conjunction with Processing Traceability, helps us narrow down problematic rules to specific execution milestones (points in time).

Compliance Traceability

This is a collaborative traceability aspect.  This is a process that needs to evolve under Business Rules Governance, wherein we collaboratively start using all the different traceability aspects in an orchestrated fashion towards a common goal — compliance.  So this is really a kind of traceability that is achieved through a set of processes/procedures established by the Governance body.  Figure 1 depicts it.

Figure 1.  Compliance Traceability is collaborative.

In Conclusion

I have presented some of the traceability aspects we have encountered so far.  I have also presented a few more that I foresee we will encounter in the near future.  In our day-to-day business rules analysis and maintenance our Business Rules Analysts use these different aspects in collaboration with each other.  Having the Business Rule Analysts involved in the overall evolution and revolution of BRIDE has worked well for us; it has produced a deep and positive shift in the way we think of enterprise software development.

Traceability has been achieved through tooling in the Business Rules Management Application and by introducing appropriate hook-points in the overall Application Architecture.  The information captured for traceability enhances our Business Intelligence about our rules and processes.  It is important, however, to remember that building traceability into your Business Rules and Enterprise Architecture is an evolutionary process and needs to be built in over time.  Features of vendor products out of the box come only half way.

The landscape for business rules is changing rapidly.  Standardization of business rules is starting to take center stage.  This would be a good time to start incorporating some of these traceability aspects into standards and specifications.  In conclusion, traceability harnesses the true power of business rules and the knowledge behind it all.

# # #