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:
- 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.
- 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.
Comments on this entry are closed.
Hi James,
You’re definitely right! Just one sentence “If possible it should take a form which is understandable by all interested stakeholders including customers.” is way to less to underline the importance of involving the non-technical user in the process. In the part about modelling dimenstions I’ve talked about the stakeholder-modelling-dimension. My opinion is that different models are needed to create a software artefact. Most models should be at the point of the business expert on the stakeholder-modelling-dimension, but there are some models which can’t be there (like a security model).
Anyway, the business user should be in a central position! That’s also the focus we have at Mendix (the company I work for). The primary user of our MDE tooling is the business analist.
-Johan
Excellent article – cheers.
Hi,
Excellent article – I have bookmarked it for later viewing and forwarded it on.
Cheers.