Model Driven Architecture (MDA): Are You Ready?

1. Do you currently have highly skilled modelers? MDA only works when you have people with the right skills, and gut feel tells me that at best only one or two percent of all developers have these skills.
2. Do you have people on staff that could become highly skilled modelers? If you don’t have sufficient numbers of modelers now, perhaps over the next few years you might be able to identify and then train and mentor people in those skills.
3. Are you able to attract and retain highly-skilled modelers? If you don’t have the uber-modelers that the MDA requires you can always hire them, although many other organizations will also think along these lines and will be desperate to hire these people away from you so you’ll need to be very good at retaining them.
4. Do you have people who are both strong modelers and strong coders? Even when you’re creating these sophisticated models you’ll still need to code, be it action semantic language (ASL) code in your platform independent models (PIMs), object constraint language (OCL), or even platform specific source code in Java or C# to implement the logic which your tool(s) didn’t generate.
5. Are your stakeholders sophisticated enough to understand PIMs? In the late 1980s, when complex modeling tools were first popularized, we discovered that our business stakeholders had great difficulty understanding the abstract models which we created. We learned that we needed to use simpler techniques and simpler tools with our users, and that when we did so that they could become actively involved with specifying systems.
6. Can you find a modeling toolset which fulfills your actual needs? How usable/learnable is the tool(s)? MDA only works if you can find modeling tools which meet your actual needs. You will likely discover that you need to find a single modeling tool – although the OMG’s XML model interchange (XMI) sounds great in theory the reality is that there doesn’t yet seem to be a combination of tools which doesn’t exhibit a loss of information when sharing models between them.
7. Do you have a viable testing strategy in place? Part of building a system is validating that it works. Unfortunately I don’t know of any modeling tools which support some form of test-driven modeling (TDM), or perhaps we should call it test driven MDA (TDMDA), so how are you going to prove that your system actually works? See Jason Gorman’s thoughts on the issue.
8. Are you willing to tie your fortunes to that of the tool vendor? With the MDA approach to development you become extremely reliant upon the modeling tools which you use. This wouldn’t be so bad if it was easy to share models between various tools, but frankly the tool vendors have little motivation to actually support this functionality because they prefer to have you locked into their product. Worse yet, because each tool has it’s own unique extensions (e.g. their own ASL, various non-UML models) you won’t be able to easily transition staff between tools.
9. Will senior management stay the course long enough to succeed? To truly reap the benefits of MDA you need to have a cross-system, multi-year strategy in place. How well have these sorts of strategies worked out in the past?
10. Are you allowed to be agile? Are you adopting the MDA to soothe the worries of the bureaucrats among us, or are you doing it to actually be successful at software development. Hopefully it’s the latter, and if so shouldn’t you try to take an agile approach to the MDA?

When you stop and think about it there is very little opportunity for MDA within business application development. Yes, there are very likely wonderful opportunities using MDA tools for software simulation or the development of embedded software; these environments tend to have developers with the requisite skillset and there are several tools specifically targeted at these market niches. However, this is a spectacularly small percentage of the overall market.