For many organizations, business rules represent their core differentiating offerings. This is particularly true in industries where the product offering is actually a service that is implemented by complex software systems. The financial services industry, such as banking, insurance, finance, loan processing and credit cards, is a prime example of a domain (or many domains) where business rules take center stage and are the MVPs of differentiation.
Since business rules are the manifestation of core business domain knowledge, it’s unfortunate that in most organizations such rules are embedded in the IT infrastructure, making it difficult if not impossible for business domain experts to define, model and maintain the rules. Not only does the situation impede the business domain expert’s ability to make changes, it also undercuts confidence in how the rules are functioning since IT staff must translate these rules into a form that only they can understand and the computer can execute. And once this is done, the ability for domain experts to validate that those same rules actually perform as they should is greatly diminished.
Though companies rarely detect this phenomenon, dys-synchronization of business rules—the business user’s expectations of what is to be implemented versus the developer’s understanding of what will be built—is a major source of loss for most businesses. Loss can take a myriad of forms: fines for failure to meet regulatory compliance criteria (important in the insurance, telecommunications and telemarketing industries, to name a few); lost business efficiency due to the failure to follow known best practices; and loss due to dropping the ball on exploiting market opportunities. Rapid response to changes in the business driven by shifting market influences or competition is often essential to capitalizing on the short window of opportunity in the marketplace. This short window is where the attractive and most profitable arc of the pricing power curve resides.
Loss can also be expressed in terms of how your IT infrastructure can hobble your ability to react quickly. Loss is realized due to the inevitable business latency introduced by the inability to know how or if your existing IT systems will be able to respond to requests to changes. Where is the opportunity cost of this flexibility? In the loss of increased margins to competitors who are able to respond more quickly.
Conceptually, the problem here is relatively simple: translating qualitative business knowledge into procedural IT algorithms effectively hamstrings both domain experts and business analysts. Neither has the training or experience to know that the numerous linked data tables or labyrinthine procedural code they are reviewing implement exactly the rules as were conceived by the experts who know the business: product managers, operations supervisors, marketing researchers, et al. To eliminate this inexact science—the science that makes the gap insurmountable—the translation business has to be eliminated. Simply put, rules should be preserved in the language of the business domain expert. This is a key element for moving towards concepts such as business process management, where the IT architecture provides a framework around a set of tools that allow the business domain experts to model and ultimately implement business process workflow and rules themselves.
Achieving the goal involves some significant organizational change, but the payoff is worth the effort. Ultimately, it places the power of defining, modeling and maintaining business rules squarely with the subject matter expert: the domain user. Further, it liberates the IT staff from the laborious chore of maintaining information for which they have limited or no expertise, thereby making them more productive in IT-intensive areas.
