James Taylor's Decision Management

A great report by Randy Heffner of Forrester caught my eye this week on Concurrent Business Engineering. He wrote it nearly a year ago but I was reading about the Digital Business Architecture ideas Forrester has and got linked to this one.

Anyway, Randy has some good points to make about applying concurrent engineering principles to the systems (or services) development process. He notes:

The word service in "SOA" refers to your business services, which capture your business capabilities in digital form

He correctly identifies the fact that business and IT are too often separate domains with only the lightest linkage through requirements documents. I have lamented the failure of requirements to be an effective way to document an organization's business rules repeatedly on my other blog (here) so I won't repeat myself. Suffice it to say that I do not believe that better management of requirements is going to solve this alignment problem. Nor does Randy and he goes on to define "Concurrent business engineering":

A process for identification and design of business solutions wherein business and IT collaborate to simultaneously design both the "to be" business process and the technology solutions to support it

Now it seems to me that this is exactly the kind of thing for which business rules are perfect and for which they have been proven. Providing an environment in which the business and IT can collaborate over how key business strategies will be implemented - what are the business rules that will deliver the strategy. Randy describes the need for an effective, efficient implementation of the business strategy and this is where business rules shine. So many business strategies have at their core a business decision or decisions that rules can almost always be applied when implementing a strategy. For example:

• I am going to treat my best customers differently
  • When I make a decision about how to treat a customer I will make that decision based in part on how good a customer they are
• I want to retain any profitable customer as long as I can recoup the cost of retention in the first 12 months
  • When I decide what offer to make to someone threatening to leave I will consider if they are profitable and, if they are, I will make the most attractive offer I can that costs less than the profit I predict I will make in the next 12 months (notice the use of analytics in this one)
  • When a customer's contract is close to expiration if that customer is profitable then make an advance offer based on the predicted value of the customer over the next 12 months
  • And so on

I think the case study we have on the California DMV also shows how business rules can deliver the kind of concurrent business engineering of which Randy speaks. Not only have they had multiple uses of the same rules (batch, 167 local offices, self-service portal), they also delivered on the promise of concurrent engineering - here's a quote:

“I’m not a programmer, and I wasn’t familiar at all with rules-based processing. But it’s been very easy to work with…much easier than conventional programming languages. I coded a fair number of the rules myself in Blaze Advisor and it only took our five-person team a little over a week to code all the rules.”
Jim McClean DMV Senior Analyst

"Before, we would give our information systems group a concept and they would go off to analyze, design and code it. Sometimes we got what we wanted and sometimes it was not quite clear. Now we can go in and make changes ourselves. It was the software that made it possible.” Diane Mobley DMV Business Organization Project Leader

So as you can see from these quotes, business rules can make this concurrent business engineering work for you. I like the phrase concurrent business engineering, so much so I may start to use it. Perhaps "Concurrent strategy engineering" or "concurrent decision engineering" might work too.