Outwardly, the business rule approach produces many of the same deliverables as any other approach to building automated business information systems -- screens, processes, data, controls, etc.  In other words, the end result is almost sure to include some application system.  So why is the business rule approach any different from other system development methodologies?  Here's why.

As discussed in previous Newsletter issues, a business rule methodology places an emphasis on the following:

• Balancing what the company 'knows' and what it 'does.'

• Specifying requirements in a declarative manner.

• Liberating rules from processes.

• Producing thin processes and throw-away procedures.

These features have various technical advantages, but collectively they seek to ensure that the resulting application system produces an adaptable business.

This has two important implications.  First, to achieve that result, the 'application' components must be seamlessly integrated with the business itself.  To say that a business rule project aims toward producing application software misses the whole point.  The real objective is to produce a full business capacity that covers all the following areas.

The second implication is being able to address the issue of motivation.  A business capacity will be of little value if it addresses the wrong business objectives.  The key question is why the business capacity in its particular form is the right one for the company.

Traditional system development methodologies have done a poor job of answering that key question.  Information engineering, for example, sought to answer it by involving sponsors and key managers directly in producing deliverables.  This was not only expensive and time-consuming -- but worse, did not really even work.  Today, most projects are still directed based on cost.  Money is important, of course -- but it is not a substitute for knowing why.

The business rule approach offers a revolutionary new approach.  This is because core business rules are always about satisfying a particular set of business objectives involving a particular set of business risks.  These connections are not 'data' and they are not 'process.'  Instead, they represent something different altogether -- namely why.

# # #