Why Johnny Still Can’t Write Rules

Business rules administration constitutes the core value proposition of any advanced business rules management system (BRMS) solution and, quite often, represents the holy grail of enterprise BRMS implementations. With the promise of propelling IT into an agile, flexible, and faster policy deployment environment, business rules administration capabilities often serve as key drivers for many cost benefit cases. However, less than 60% of these implementations actually leverage the full promise of BRMS offerings, ending up by managing business rules projects much like any other conventional software project. More importantly, business rules are too often not managed by those who should be empowered to manage them – i.e., business owners and stewards. Why does this happen? AAG’s experience shows that solutions with a full-scale, end-user facing rules administration capability may overwhelm the software change management infrastructure or, alternatively, they do not adequately address key aspects of business rule change management. This continues to happen despite increasingly sophisticated and advanced software platforms.

The result is that, as the software gets better, the ROI gets worse – at least in terms of agility and business user enablement gets worse. This observation leads to several basic questions:

1. What role does IT play? What role should IT play? Are business, IT, and BRMS platforms on the same page?
2. BRMS market offerings for rules administration and the emerging demands of business users demand – are they converging on the same page?
3. Has adoption of management technologies been hampered by the inadequacy of available tools and techniques for harvesting, capturing, and analyzing business rules?

Let’s begin with the question of the roles played by business, IT and how they interact with current BRMS platforms. A robust BRMS has a fairly well defined set of capabilities for managing rules[1], to include:

• A rule repository
• Technical and non-technical rule management tools
• Verification and validations tools
• Testing tools
• Deployment tools
• Data management capabilities
• Impact analysis tools

The majority of the market leaders in this space provide platforms with most of these capabilities, if not many more. With them, the ability to realize “zero time to market” or “total agility” is there for the taking. It is possible to make an immediate change to a production environment, thus allowing an enterprise to react instantaneously to environmental, market, or regulatory changes. It can happen, but typically doesn’t.

There is reason to believe that many business users haven’t acquired the skills, confidence, or authority to take advantage of the non-technical rule management tools available to them. However, the real problem here is more likely to be the SDLC (software development life cycle) that has been created in most organizations. In many instances, they may not have been established to handle situations where this kind of rapid change was anticipated, or even considered. Lacking any other alternatives, BRMS projects are far too often lumped together with many other types of software implementations and are then subjected to a long, overly controlled, and a non-responsive change management process. The result is often a marked lack of agility and yet another IT-driven solution.

This doesn’t have to be the case. We all seem to have the tools we need – what we need is a better way to use them. This means modifying the overriding change management process to provide an agile framework that satisfies corporate needs for safe and controlled system deployment. This kind of framework should present trade-offs for various levels of maturity throughout the process, while also offering key control-gates for customizing rule administration implementations. Salient points for a framework of this type should include:

• The need for an incremental maturity level approach, e.g., starting with a read-only, development-centric approach for rules administration – moving toward a full-scale, end-user facing, hot-deployment type approach;
• Describing what types of business should be subjected to each of these maturity levels and the corresponding investments required. Are certain kinds of rules less-risky to change (i.e., changing a numerical limit from 70 to 75)? Do certain situations necessitate an immediate change (e.g., a sudden unanticipated stock market plunge over some threshold)?
• Identifying needs from project inception that will facilitate later adoption of management capabilities.
• Delineating control points to tailor the right balance between the benefits, investments, and realizable value for the organization, i.e., do all projects really need or use a rules administration capability?

Putting a framework like this in place can effectively balance the needs between agility and safety and allow the tools that have been provided to truly be put into the hands of the business user.

You will notice at this point that we have only addressed the first question (and perhaps part of the second) in this discussion. What has been proposed here has the potential for enabling functionality and an operational mode that seldom exists.  However, this just gets the proverbial horse to water. It doesn’t make him drink. This is because we are talking about rules management. Essentially, rules operate more or less like a programming language. And, as much as we’d like to believe it is completely business user friendly, experience suggests otherwise. That’s because we should be discussing decision management, a topic teed up for discussion in another issue.