Business Rule Management Systems (BRMS) coupled with commercial off-the-shelf (COTS) applications are prevalent today. Together and separately, they provide rapid and satisfactory solutions to particular problems in specific business areas. In fact, the most common use of BRMS today is for self-contained point solutions in a functional area of a business. “Not that there is anything wrong with that” – as Jerry Seinfeld would add. However, the impact on an enterprise vision of introducing another “technology silo” must not be underestimated. This paper explores this impact and a solution.
Reality Check
Despite the promise of Service-oriented architecture (SOA) and other enterprise approaches, the use of self-contained applications will be with us for many years. The highly specific needs of particular functional areas of any business will continue to demand vertical solutions and (well-meaning) vendors will continue to deliver them. So much the better if the solutions are business rules based. Such solutions will deliver on the promise of greater flexibility and lower maintenance costs over time. But there is a challenge lurking. Without proper planning and stewardship, they are likely to do so only within a narrow business domain. At some point, proliferation of business rules for narrow business domains will become a business liability.
How History Repeats Itself
Therefore an organization seeking a cohesive enterprise vision, must get serious about evaluating the short-term versus long-term cost of such applications – whether developed in house on modern BRMS systems, or implemented from COTS vendors. Without due diligence, such solutions are likely to become the new, disconnected islands in the already vast tangled web of legacy applications. How will this happen?
The classic scenario is that a specific business problem is addressed with a set of competing commercial solutions. The organization evaluates each, selects one, and perhaps does a pilot. Then, a real project begins and often, the vendor leads the application implementation in a specific business area with a very narrow focus. Whether managed internally or externally, too often the result is a data model, an object model, a business glossary, and set of business rules that conform to the needs of that business area. However, these are not likely to align with those of the rest of the enterprise. The meanings of narrow terms, the stability of narrow models, and the usefulness of the narrow business rules do not transcend the business area because they are not designed to do so. In the past, we have dug ourselves out of such situations.
Why We Can’t Dig Our Way Out with Business Rules
Historically and ultimately the data issues can – and usually are – solved by complex mapping logic, extract and transform and load software, frequent data transformations, and a thorough labyrinth and hierarchy of data marts and data warehouses. These solutions are expensive but acceptable because they work. Yet, parallel issues in business rules are not so easily conquered, not even with money and technology. Business rules are less malleable, and give rise several areas of concern.
(1) Business rules don’t lend themselves to the solution of mapping and warehousing. That is, data, is simply stored for subsequent access, and can be transformed to other formats over and over again. But, business rules actually execute. In fact, business rules are not only core business logic, but are active components that cannot be transformed into something else.
(2) Business rules harvested for use in self-contained applications, are typically expressed by the subject matter experts (SMEs) in narrative form, often imbedded (hence, lost) in requirements and use cases.
(3) Such business rules do not emerge as a cohesive set of logic amenable to analysis and testing for conformance with business policy. The opportunity for early and more complete (less expensive) testing is not there.
(4) As soon as buried business rules are handed over to the programmers, the business rules become ‘lost’ to the business. Their documentation is not maintained. The new (but unacceptable) source for the business’s rules becomes the program code!
(5) Such business rules are not likely to reflect the needs of stakeholders beyond the boundaries of the functional area in which the application is being developed and from whom the business rules are harvested.
(6) Invariably, each vendor operates according to their own business rule methodology and standards. These will vary among vendors and are not likely to comply with those used in other areas of the enterprise. This leads to future difficulties in the sharing and/or reuse of the business rules.
Do Business Rules Really Matter?
While many organizations have operated in this manner for decades, the business implications today can be staggering.
One of the largest Telecom companies in the world, experienced the difficulty of introducing several self-contained applications with serious negative business implications. Customers were receiving conflicting prices, conditions and offers for the very same services from different business units of the company, sometimes within days of each other. The source of the problem lay in self-contained disparate systems developed by different groups within the organization, each having its ‘own’ business rules and yet, each using the same data sources!
The solution for this company lay in the time, cost, and full investment of major re-work. It involved re-harvesting the business rules from within those disparate systems, building a corporate repository of those business rules, identifying the discrepancies, endorsing a common enterprise customer vision, and driving consistency through a governance council. Over time, the organization regained control of the business rules and continued to maintain business alignment among the business units. But, not until there were losses of money and customers.
Because they were playing catch up – some damage had been done – the solution process was difficult, and expensive. Nevertheless, the recognized stewardship of enterprise-valued business rules resulted in improved customer satisfaction, significant savings for the company, and a healthy ROI in customer communications.
Lesson Learned
The lesson learned is one we have (or should have) learned before. Maybe we saw it with different technologies, perhaps different vendors, maybe even different programmers. But the lesson is this – don’t settle for a compromise in the enterprise vision by complicating the technology web with too narrow a focus. Instead, evaluate the impact on the longer-term enterprise integrity of the shorter-term disconnected string of orphaned, banished applications.
Another lesson learned is that the threat of new silos on the enterprise vision is not always obvious. In fact, all too often, the threat does not seem significant at early points in time. For a long time, the organization may appear to function without visible serious repercussions. However, one by one proliferation of point solutions (e.g., COTS) slowly erodes the enterprise’s integrity. And, like a cancer without early detection and controls, the conflicts eventually become noticeable, the organization fails to function seamlessly, and the problem becomes significant.
The good news is that an enterprise approach to business rules can accommodate COTS point solutions, as well as standalone BRMS implementations. But this accommodation does not happen by itself and it does not happen by keeping the focus narrow. It happens when the organization aims to detect and prevent such unhealthy situations, rather than permit them to disintegrate the enterprise slowly. It happens when the organization makes investments in that prevention through proper staffing, methods, training, standards, and technology for the longer-term healthy vision. Such an organization evaluates up-front, even in the absence of serious business problems, the full impact of new silos: the cost of leaving them as silos, the costs of fixing the silos later, and the true ROI to the enterprise and its customers over time. How can we prevent unnecessary silos?
An Organization is Born
A recommended practice is the establishment of an enterprise group to provide the methodology and training for the harvesting of business rules; to maintain a central repository of the business rules along with the appropriate governance mechanisms to ensure alignment of business rules regardless of where they are implemented; to work closely with all business rule projects. Keep in mind that:- Unconnected technology islands are predictable (and run rampant) in organizations that do not have an enterprise mindset- Unconnected technology islands are predictable where there isn’t an enterprise business rules group in place- Where an organization establishes such a group, there is an expensive loss of ROI if projects are allowed to work around the group- Unpleasant business repercussions are possible when a vendor or internal resource does not appreciate the value of such a group to the company as a whole.
Is the Enterprise Business Rule Group Similar to Existing Groups?
Business rules are not the only asset worth leveraging. A typical organization “has other assets that are valuable, shareable, and levarageable, too, such as its employees, its money, its customers, and its legal obligations.” (von Halle, Barbara, John Wiley & Sons: Business Rules Applied, 2002). Because such assets are precious and critical to an organization’s success, most organizations create centralized functions dedicated to leveraging them. These include human resource functions, finance departments, legal departments, and customer service or relationship management functions. But, are business rules substantial enough to merit such a function?
The Business Rule Difference
Assets such as people, money, and customers are tangible. But, business rules, especially buried in systems, seem less tangible. However, business rules are only less tangible until they hurt the organization or until the competition offers better ones.
Fortunately, unlike money and people, business rules are a resource that is not consumable. As a non-consumable resource, a business rule is not used up when it executes in a system or is carried out by a human. To the contrary, there is an extra cost each time a business rule is copied or implemented more than once unnecessarily, delivered with a narrow focus that prohibits reuse, is resistant to change, or is inconsistent with other rules or goals. Non-consumable resources are vulnerable to misuse and business rules are no exception. The cost of misuse is significant because the business rules are driving the business, regardless of their quality.
An enterprise business rule group leverages the business rule asset by:o Reducing unnecessary redundancy in business ruleso Encouraging deliberate redundancy in business rules, where appropriateo Advocating that business rules be automated in technology appropriate for multiple usageso Minimizing unhealthy competition for and “ownership of” business ruleso Protecting, secures, and controls access to the most proprietary of business rules, ando Providing a single point of contact for the enterprise’s business rules, as a source of organizational knowledge.
Inevitably, some people will propose that an enterprise approach to business rules (or, perhaps, to anything) adds to the cost of individual projects. And, perhaps they are right, for the first few projects. However, an enterprise approach to business rules will in fact reduce the immediate maintenance cost and increase the overall business ROI time and time again. A valid question to ask is not how many BR-oriented solutions do business areas want, but how many does the enterprise really need? It may be a case of less is more.
The organization with an enterprise approach to business rule management makes consistent decisions, runs its business optimally, and has a strong competitive advantage.
