A reader asks… about development, business rules and model-driven development

I got an interesting series of questions from a reader that seemed to me to justify a longish post. The initial question was quite harmless looking:

Can you give a clue as to what software engineering approach you use/recommend for EDM, but especially business rules that non-IT staff can alter safely?

But the whole thing got more interesting as they explained some follow-up items:

[is this] ‘just’ putting non-developer friendly interfaces on the process business rules inherent in MDD [Model Driven Development] or something completely different?

Has all this effort been put into business rules engines because of the current limitations of MDD approaches: ie they are a stop gap or an ultimate end in themselves?

Is the software engineering approach of the business rules engine a temporary convenience or something fundamental?

Very interesting questions. Taking on the software engineering approach question first I would refer everyone to Enterprise Decision Management and the Software Development Lifecycle, a post I wrote not that long ago on the topic. Personally I think the Agile approach works especially well as I said in my recent Application Development 2.0 post. To repeat an article I wrote on agile business rules, I find the use of business rules to be completely complementary to the four tenets of Agile development:

• Tenet 1: Individuals and interactions over processes and tools.
  One of the key interactions is between developers and domain experts. The use of busines rules facilitates this conversation.
• Tenet 2: Working software over comprehensive documentation
  Business rules can deliver working software that is easier for domain experts to read and manipulate making it more “self-documenting” and lessening the pressure for documentation.
• Tenet 3: Customer collaboration over contract negotiation
  The fact that both developers and domain experts can read and understand business rules allows true collaboration over the implementation of business logic.
• Tenet 4: Responding to change over following a plan
  Business rules deliver business agility by making the actual code you write easier to change both during the project, and after it.

So, to summarize: It does not really matter what approach you use (they can all work well) but Agile or Agile-like approaches will be highly compatible with using business rules. In particular, fast iterations and test-driven development work well with the kinds of short-cycle changes that business users make themselves.

Now on to the Model Driven Development(MDD)/Model Driven Architecture (MDA) questions.

I regard business rules as a part (and a very important one) of a Model-Driven Development approach or a Model-Driven Architecture (MDD/MDA) as they allow you to specify business logic without the nitty-gritty of code. No approaches to MDD/MDA manage business logic well today – they mostly assume it will still be coded by developers. As long as designers and developers are embedding business rules in use cases, statecharts, class models etc then MDD/MDA will not deliver on its promises. In the context of MDD/MDA a model cannot be limited to things that can be diagrammed – a model-driven approach must include a declarative language for business decisions – something like the current business rules languages. After all, improved business/IT cooperation requires a shared language and when it comes to the details of business logic I have yet to see anything better than business rules. Business rules allow for IT departments and business users to truly work together. As one of the key drivers for MDD is the need to build systems that can cope with faster business change and to do so by improving business/IT alignment, business rules would seem to be ideal. Too many MDD/MDA approaches seem more worried about tracing requirements to code (which won’t fix the problem).

Without a truly declarative language to describe the business logic of business decisions, MDD/MDA is just another technical approach for generating code – a new form of CASE (Computer Aided Software Engineering) tools based on UML. MDD/MDA removes the burden of lots of programming from developers but still expects them to deliver the code that implements interesting things such as business logic and algorithms. But business logic and algorithms require business verification and business users hate code. Adding business rules to the MDD/MDA mix would address this. Furthermore, while projects using MDD/MDA have shown a reduction in time from problem identification to working code, it is still code and the IT department is still making the change rather than the business. Again, business rules would help with this. Finally, some of the benefits stated for MDD/MDA seem simple to someone used to a Business Rules Management System (BRMS) or even of a Business Process Management Suite (BPMS) – easy change of logic or process steps without regenerating the whole application for example – so business rules and business process would seem natural components of MDD/MDA.

Current MDD/MDA approaches do have limitations because they don’t handle business logic the way a business rules approach does (or business process the way a business process approach does). This was not the motivation for current business rules products (they mostly pre-date MDD/MDA being widely discussed) but they remain a hugely beneficial and complementary approach for anyone doing MDD/MDA. I don’t see anything on the horizon that makes me think of them as stop-gap but I would never be rash enough to say that ANYTHING was “fundamental”.

I think the effective mangement and automation of business decision making is now and will continue to be critical for the next generation of systems – helping to make current systems and infrastructure (and models) “smart (enough)”. For now there is nothing better than business rules for this.