Model Driven Disadvantages
Proponents of model driven development seem to spout countless benefits, “it captures intellectual effort more effectively”1, “it bridges the gap between business and IT”2, “Models offer greater extensibility and portability”3. This weeks panel presented a very interesting look at model driven development, specifically, what some of the issues associated with it are, and why it hasn’t had the impact some hoped it would. Shayne offered a fairly in depth exploration of, at a high level, why model driven approaches to engineering, and software development, are not ready for the prime time. His focus was somewhat abstract, not really touching on problems with model based approaches that manifest themselves at the implementation level. In this weeks entry, I’d like to have a closer look at some of the criticisms of model driven approaches at this level, in an attempt to gain a better understanding of why this approach hasn’t seen widespread adoption.
“MDD introduces a lot of rigidity”4
Abstraction is a powerful tool, it’s one of the key factors in enabling large software systems to exist. The tradeoff is, of course, a reduction in flexibility; you can’t manipulate memory in Java the same way you can in C. As technology has advanced however, the need to manipulate that memory has dissipated. So to do I believe, that the need for high levels of flexibility within large systems, where MDD makes the most sense, will also begin to reduce. We’re starting to see this now, with businesses and government departments favouring commercial off the shelf software over bespoke productions. This shift has been driven by the reduced cost and increased reliability outweighing the flexibility of custom software 5. MDD’s attributes are well positioned to take advantage of this shift in priorities; I predict it won’t be long before the loss of flexibility is more than made up for in the increased efficiency.
“Development isn’t the slowest part of developing software, deploying and taking it into production is”6
One of the key benefits of model driven software engineering, is that the models themselves are platform agnostic. In theory the translation tool that generates code from the models is supposed to fill in this gap, and whilst current tools do a decent job of creating code, they are unable to assist in actually getting that code running effectively6. Deploying the generated code to a production environment requires, amongst others, security, infrastructure and corporate policy considerations. In a traditional approach, it is argued that these considerations are captured and implemented during the development process. It’s a tough issue, you’ve just generated this web of code, but now you need to correctly position it over the resources. I believe Shayne’s video presented a way of thinking that may help solve this issue. If we treat the deployment environment as a domain that can be modeled, as well as the actual software, then a specification archetype can be generated detailing how these models can be “woven” together7. This interfacing preserves the agnosticism associated with MDD; the same programmatic model can be combined, via a specification archetype, with differing infrastructure models.
MDD has a long way to go, I don’t believe anyone would argue otherwise. I also believe that it is the next logical step in the evolution of abstraction. Future large scale systems development demands another layer of abstraction. Without one, just as the assembly programmer is unable to create enterprise level software, we too will be ill equipped to handle the requirements of the future.
References and Further Reading