« Brainstorm conference, BPM/SOA/BRM/PM/EA | Main | Modernizing COBOL with business rules »

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.

Posted by jtaylor in Business Agility • Business Rules • SOA |Digg This|Add to del.icio.us

Trackback Pings

TrackBack URL for this entry:
http://www.ebizq.net/mt/mt-tb.cgi/222

Listed below are links to weblogs that reference Concurrent Business Engineering with Business Rules:

» The problem with programmers from Enterprise Decision Management - a Weblog
Firstly let me say that not only are some of my best friends programmers but that I have been a programmer, development manager, product manager, architect and methodology author in my career so please don't consider this some marketing guy [Read More]

Tracked on November 30, 2006 11:54 AM

» 5 Business Reasons to Service-Orient and 3 to decision-automate from James Taylor's Decision Management
I got a note from the folks at ZapThink about an article in SAP Netweaver magazine called "5 Business Reasons to Service-Orient". The 5 reasons given are "reduced integration costs, automated business-to-business interaction, easier regulatory complian... [Read More]

Tracked on December 15, 2006 11:43 AM

» More on Model-Driven Development from Enterprise Decision Management - a Weblog
Diego Lo Giudice of Forrester published The State of Model-Driven Developmentrecently. This is a well-written paper and does a nice job covering Model Driven Development of which it says "Forrester expects model-driven development (MDD) to play a key r... [Read More]

Tracked on April 19, 2007 03:40 PM

» Lean application development and maintenance - some thoughts from Enterprise Decision Management - a Weblog
I recently came across this McKinsey paper - Applying lean to application development and maintenance (subscription required). The abstract has a few key bullets: Lean techniques, originally developed to reduce waste in manufacturing, are boosting perf... [Read More]

Tracked on May 31, 2007 02:14 PM

» Book Review: The Enterprise Unified Process from Enterprise Decision Management - a Weblog
I have just read (skimmed, really) Scott Ambler's book The Enterprise Unified Process: Extending the Rational Unified Process.If you are using theRational Unified Process (from IBM), or considering doing so, and worried about applying it to a whole IT ... [Read More]

Tracked on June 1, 2007 02:32 PM