Business Analysis with Business Rules: Escape from Change Deployment Hell

By Ronald G. Ross with Gladys S.W. Lam, Principals, Business Rule Solutions, LLC

Excerpted with permission from Building Business Solutions: Business Analysis with Business Rules, by Ronald G. Ross with Gladys S.W. Lam, An IIBA® Sponsored Handbook, Business Rule Solutions, LLC, 2011, 304 pp,

imageA business manager at a very large health care organization recently confided to us that making a change to business rules of even moderate complexity took their organization 400 person-days over a 4-month period. That’s staggering. How could it be sustainable? Their organization, like many today, is living in change deployment hell.
The manager went on to observe that a subtle stagnation had crept into the staff’s very way of thinking about the business. He noted that they often don’t even consider business innovations they know from experience to be difficult for the existing systems to handle. He wondered out loud whether they could even think through any real business innovation effectively any more. The bottom line:  They needed a new approach, not more of the same.
Today’s information systems aren’t agile—even when agile software methods are used to develop them. Companies need business agility and in most cases, IT hasn’t been delivering it.
The solution is to treat business rules as a first-class citizen. We think everybody should.

Business Rules vs. Requirements

Let’s be very clear that business rules and requirements are not the same thing.  When you set out to create a software system, business rules can imply requirements—but that’s a different matter.
Here’s one major difference:  Requirements evolve before deployment of a system; business rules continue to evolve after deployment of a system. That affects everything.
To bring the distinction into perspective, consider data for a moment. Would you consider actual business data—not the data definitions but the actual data itself—to be part of requirements? No!
The life cycle of data and the life cycle of requirements are simply not the same.  The life cycle of requirements, no matter what methodology you use, more or less ends with official software release. For data, in contrast, that’s just the beginning of life. The data persists. More importantly it changes over time. That’s the very essence of doing business. It’s so obvious we take it for granted.

Real Life Begins at Deployment

The very same is true for business rules. Official software release is not the end of life, it’s a new beginning. They persist. More importantly they change, sometimes rapidly, because a business constantly needs to adjust its business practices.
The distinction between the software development life cycle and the life cycle of business rules is hard for some to grasp. Indeed, if you’re looking through the lens of software development methods, you’re almost certain to be confused. When you look at business rules from the business point of view, however, seeing the distinction becomes far easier. Explained correctly, business people don’t have much trouble “getting it”.
Eventually everyone will appreciate the distinction. Then the need for managing rulebooks as a separate resource (just like databases) will be obvious. We call that activity rulebook management. Has it been factored into your approach yet?