Extreme Business Agility (Part 4): Change Deployment Hell

Ronald G.  Ross
Ronald G. Ross Co-Founder & Principal, Business Rule Solutions, LLC , Executive Editor, Business Rules Journal and Co-Chair, Building Business Capability (BBC) Read Author Bio       || Read All Articles by Ronald G. Ross

Just about every company these days is in search of agility.  They may not call it by that name, but that's what they're after.  What is it about the current situation that's so bad?  What exactly is true agility, and how do you know when you have it?  And most importantly, how do you get there in pragmatic fashion?

Case Study:  Large Health Care Organization

To go in search of agility, we must first clearly understand where we are today.  I can sketch that best by example.

At a large health care organization, a high-level manager recently cited the following statistics:

  • It takes 24 man-years per year to maintain a 30-year old monolithic COBOL legacy system.

  • Making changes to business rules of 'moderate' business complexity requires 400 person-days over a 4-month period.

The latter figures are truly staggering.  Four full months to roll out changes in their decision logic.  Four hundred person days to do it.  We can safely say that this organization is living in what I call change deployment hell.

Hopefully things are not quite so bad in your own organization.  Even so, we're all familiar with the problem.  The manager at the health-care organization described their situation this way, "Truth be told, we work for our legacy systems, not the business."

That's not all.  Beyond the frightening costs, the manager also described how a subtle stagnation had crept into the staff's very way of thinking.  "Our business leads are so familiar with the limitations of our legacy systems, they don't even consider business innovations they know from experience to be difficult for the system to handle....  Sometimes I wonder if they can even think though innovation effectively any more."

Even if the costs associated with change deployment hell don't perturb you, this loss of inventiveness should.  I say we can do better than that.  I say we can and we should!

The True Business Meaning of Agility

A second question as we go in search of agility is what exactly true agility is, and how do you know when you have it?  Again, I can sketch that best by example.

A medium-sized financial services company specializes in detection of credit card fraud.  Suspicious transactions are kicked out to fraud specialists for manual inspection.  These fraud specialists are an expensive and largely non-scalable resource.

Here's a sample scenario for their business.  The bad guys suddenly pick up and move shop from Idaho to Manhattan.  As a result, transactions deemed suspicious by zip code yield a 10x increase in volume. The company must try to keep the volume of kick-outs relatively constant because of expense, so it refines its selection criteria to reduce the rate.  For example, it adds specifications about specific locations of stores, types of stores, frequency of use, size of transaction, etc.

The elapsed time to deploy such refinements had been 30-60 days.  After introducing a rule engine, the elapsed time was reduced to 3-6 days — an order of magnitude improvement!

Would you say their business had become more agile?  You bet!

By the way, if your management is concerned with the cost or difficulty of introducing a rule engine to your company, here's something that should interest you.  This company told us that they had more than recouped the cost of the rule engine from their savings on this very first deployment alone!

One way to assess agility is through improvement in your IT methods.  Far more important, I believe, is the agility that can accrue for your day-to-day business operations.  When you hear "agility" you should automatically think business agility.  By the way, that's where I've always believed the true message of business rules lies.  Indeed, that's why they're called business rules!

What then is the true business meaning of agility?  In real business, we face difficult trade-offs all the time.  The company above certainly does.  How many cases of fraud slipping through the net add up to the cost of adding an additional resource for doing manual inspections?  How long can they safely wait before potential losses mount up to an unacceptable risk?  Achieving optimal business performance is clearly a matter of balancing costs and time against risks.  Your challenge is finding the optimal edge in that respect — not just once, but constantly over time.

How can you go about discovering that optimal edge of business performance?  One part of the answer lies with business strategy — that is, becoming deliberately and structurally strategy-driven.  I'll have much more to say about that in an upcoming article.

The second part of the answer is measurement.  For the second company above, measurement of business performance has to do far more with decision performance than process performance.

Indeed, I believe to get a true reading of business agility you need to establish enterprise decision management (EDM).  Business process management (BPM) is simply not enough.  These days, the way you differentiate yourself from your competitors is not in the processes, it's in the decisions.

Tom Davenport, author of Competing on Analytics:  The New Science of Winning says it this way:  "I have concluded that decision making and the techniques and technologies to support and automate it will be the next competitive battleground for organizations.  Those who are using business rules, data mining, analytics and optimization today are the shock troops of this next wave of business innovation."  That's spot on!


The next part of this six-part series provides a definition of business agility.  In particular,  you achieve full business agility when the IT aspect of change disappears into the plumbing.  Find out what's what at the optimal edge of business performance.

# # #

Standard citation for this article:


citations icon
Ronald G. Ross, "Extreme Business Agility (Part 4): Change Deployment Hell" Business Rules Journal, Vol. 9, No. 12, (Dec. 2008)
URL: http://www.brcommunity.com/a2008/b455.html

About our Contributor:


Ronald  G. Ross
Ronald G. Ross Co-Founder & Principal, Business Rule Solutions, LLC , Executive Editor, Business Rules Journal and Co-Chair, Building Business Capability (BBC)

Ronald G. Ross is Principal and Co-Founder of Business Rule Solutions, LLC, where he actively develops and applies the BRS Methodology including RuleSpeak®, DecisionSpeak and TableSpeak.

Ron is recognized internationally as the "father of business rules." He is the author of ten professional books including the groundbreaking first book on business rules The Business Rule Book in 1994. His newest are:


Ron serves as Executive Editor of BRCommunity.com and its flagship publication, Business Rules Journal. He is a sought-after speaker at conferences world-wide. More than 50,000 people have heard him speak; many more have attended his seminars and read his books.

Ron has served as Chair of the annual International Business Rules & Decisions Forum conference since 1997, now part of the Building Business Capability (BBC) conference where he serves as Co-Chair. He was a charter member of the Business Rules Group (BRG) in the 1980s, and an editor of its Business Motivation Model (BMM) standard and the Business Rules Manifesto. He is active in OMG standards development, with core involvement in SBVR.

Ron holds a BA from Rice University and an MS in information science from Illinois Institute of Technology. Find Ron's blog on http://www.brsolutions.com/category/blog/. For more information about Ron visit www.RonRoss.info. Tweets: @Ronald_G_Ross

Read All Articles by Ronald G. Ross

Online Interactive Training Series

In response to a great many requests, Business Rule Solutions now offers at-a-distance learning options. No travel, no backlogs, no hassles. Same great instructors, but with schedules, content and pricing designed to meet the special needs of busy professionals.