It occurred to me the other day that Model Driven Architecture (MDA) is a lot like waterfall processes. For those of you who don’t know, MDA is a kind-of different approach to writing software systems. Basically the idea is to define a software system in a platform independent way (e.g. using some kind of DSL for example) and then once the system is fully defined your MDA tools will be able to generate a platform specific version of your system which you can then deploy and run (yeah as simple as that :)). To simplify it even more, the MDA ideal is to be able to represent a system diagrammatically (i.e. draw it) and then press a button and get a fully operational version of the software system that you were after. If you still need to know more there is Google or Wikipedia.

MDA

MDA has been around for a few years now, and when the idea first reared it’s head it was (like many others) touted as a potential ‘silver bullet’ solution to building software quickly and efficiently. The surprising thing is how many people have bought into this, I mean, there are companies out there who have built a business around MDA. The reason I am surprised is that waterfall processes tried to do the same thing to process, as MDA tries to do to software implementation. Any developer worth his salt knows exactly how ‘well’ waterfall processes work, so what made anyone believe that doing the same thing to actual implementation of the software system would be any more successful?

How Are MDA and Waterfall Similar?

Waterfall processes try to fully define all the steps needed to create a software system from a process perspective. They attempt to create a perfect roadmap that will cover every contingency you’re likely to encounter when building a software system. The great delusion here is the fact that no-one can ever fully take into account every possible combination of domain, people, circumstances, organizational differences, etc. and did I mention people. Of course it quickly became apparent that no process can create a perfect roadmap for all those reasons. Although when I say quickly I mean it in cosmic terms a veritable blink of an eye – in human terms it was a few decades. And it will take a few more before we put waterfall processes in the grave where they belong.

What MDA tries to do is to create an abstraction of the system you’re trying to build. It is either a visual abstraction or a DSL based one, either way it is still an abstraction, you then try to generate a system based on this abstraction. Leaving aside any issues related to deploying what you generated, in order for your system to do what you need; your abstraction would have had to be spot on. So, in essence you’re trying to create a perfect system metaphor. I am not sure if that’s an oxymoron, but I do know that I’ve never been able to come up with a perfect metaphor for anything, and I don’t know anyone who has.  But, that is exactly what we’re striving towards when we do MDA, while the metaphor holds up, everything is fine, but a soon as it breaks down – as it must, what do we do?

What DO We Do When The Metaphor Breaks Down?

We do the only thing we can do, we go back to the tried and true. We crack open an editor and try to fill in the gaps by hand. But of course we can no longer use our DSL for this or our nice picture, we must work within the bounds of our platform. And this of course is where the system gets orders of magnitude more complicated. MDA tools generate the platform specific version of our system so we must find a way to hook-in our little ‘abstractional patches’ into the generation process. And of course we need to make sure that it all still fits together as the system evolves. Not to mention the fact that it is really difficult to visualize how our patches fit into the overall architecture (since we are now trying to fit a little bit of reality into an abstraction and we’re just not wired to do that easily). And should I even bother to mention that we’re no longer platform independent!

What you end up with is an environment where the further you go along the more you feel like everything is a little bit out of control. In reality it may not actually be as bad as some systems that are developed in the normal way (should I say ‘traditional’ – I better not :)). But you can’t keep the two separate representations of parts of the system in your mind at the same time and that creates a very real sense that you can’t quite get a handle on what you’re doing.

All this brings us back to me being really surprised that MDA got even the little bit of traction that it does have. We had an almost perfect example of a situation where a similar solution just didn’t work (waterfall processes), more, it was pretty much in the same domain. But that’s the thing, what we had was an abstraction, a metaphor if you prefer, it was a good one but it wasn’t perfect and so many of us missed it and MDA was born – so I guess I shouldn’t really be surprised. We’re not incompetent though, we’ve twigged on to the fact that waterfall is not the way to go and so it is going the way of the dinosaur; MDA is going to go the same way – eventually. It just that is takes us a cosmic eye-blink to get our act together.