I was reading Johan den Haan’s really good article on Model Driven Engineering or MDE today and a particular comment caught my eye:

MDE aims to increase the return a company derives from its software development effort.

He went on to quote Atkinson & Kühne for two ways to do this:

1. By improving the short-term productivity of developers. That is, by increasing the value of primary software artifacts in terms of how much functionality they deliver.
2. By improving the long-term productivity of developers. That is, by reducing the rate at which primary software artifacts become obsolete.

At first glance this seems fine but there is a clear gap - nothing in the comment about MDE requires that developers be the target, only that the software development effort becomes more effective. Yet the two approaches to delivering this are focused only on developers. Could we not, in fact, increase the return we get from software development by engaging and empowering non-developers? Surely an MDE approach could improve our return in other ways such as:

• Improve the ability of non-technical users to safely and effectively make changes to their software to reflect their changing needs and understanding of their business
• Increase the ability of the software to take action by effectively leveraging data gathered in the past to make useful predictions about the future

The answer, of course, is yes. If the software artifacts that manage decisions are implemented using a declarative, verbose, business-friendly approach by using a business rules management system and if the engineering team consider data as something that can be engineered into new insight, not just stored and moved around, then MDE could do all this. Adding Enterprise Decision Management, EDM, in other words.

The article goes on to talk about the challenges of knowledge being in the heads of personnel and of constantly changing requirements. Regular readers of my writing (or of the book) will know that it is the business rules that change all the time and that it is critical are not left in people’s heads. EDM, and the use of business rules management systems in particular, can really help MDE deliver on this too particularly when it comes to corrective and adaptive maintenance (two of the three types the article discusses).

A focus on developers and their productivity is not enough to get us to MDE because the model that should drive the engineering is a business model, not a technical one.

Related posts:

1. A reader asks… about development, business rules and model-driven development
2. Business Rules, Domain-Specific Languages and Models
3. Model Driven Architecture group on LinkedIn
4. Call for presentations - the new EDM Summit
5. Using EDM and adaptive control to respond to uncertainty