Model Driven Architecture (MDA) is one of those stealth technologies that is gaining ground very quickly yet remains below or beyond most people’s radar. MDA is a set of standards from the Object Management Group (OMG) that effectively extends the OMG’s UML to deal with the entire software lifecycle, from enterprise architecture to code generation to component deployment and maintenance.
MDA was announced in 2002 and is still under development, but parts of it are already being used extensively in various well-known modeling and development tools, such as Rational’s XDE and the open source Eclipse toolkit, as well as some popular enterprise platforms, such as IBM’s WebSphere. In addition, there is a variety of lesser-known products based on MDA.
Although MDA is relatively new, we’ve been reporting on its progress for some time, and plenty of background information is available on the OMG site. In addition, there are increasingly more MDA-related articles in the popular computer press, several new MDA tool announcements, and every couple of months, it seems a new book on MDA is published. However, judging by these events alone, nobody would ever suspect the sizable — and sometimes unexpected — impact that MDA is already having on some areas of software development.
If you want to find out what’s really going on with MDA, go where the MDA groupies hang out: OMG’s semiannual MDA Implementers’ Workshop. At the latest workshop, held in May in Orlando, Florida, USA, case studies were presented representing a wide range of applications and industries, including public utilities, telecommunications, electronics, healthcare, public services, and transportation. The main message from the previous conference held in December 2003 was reiterated: MDA may be relatively new, but it is already being applied successfully in nearly every field.
Nonetheless, the two workshops were markedly different in at least one area: the substantial presence of the military community among both the presenters and the attendees. Military interest in MDA is not new — there were some defense-related presentations at the December conference — but the recent event highlighted the aggressive application of MDA to a range of very important military initiatives. Why is the military so interested in MDA, and why now?
Before I attempt to answer these questions, let me take a step back and explain a little about MDA. UML was introduced in 1996 to unify and standardize several popular application modeling approaches. Over the next few years, as UML gained popularity and UML tools became ubiquitous, many people began to push the UML envelope by using it to model things like enterprise architectures, service-oriented infrastructures, workflow models, and component packaging and deployment schemes. People also started to use UML models as the basis for automatically generating code, database schemas, message structures, systems documentation, test harnesses — the list goes on and on.
While UML itself is standard, how it should be applied to different steps in the software development process was not (until MDA came along, that is). From a standards point of view, UML quickly became a victim of its own success. The gurus at OMG watched with joy and amazement as the use of UML invaded almost every niche of the software lifecycle; at the same time, however, these gurus worried about a brave new model-driven world spiraling out of control. In response, MDA was hatched. Currently, MDA includes upgrades to UML and its close cousin, the Meta-Object Facility (MOF), plus a number of other modeling-related standards.
MDA is already being used as an organizing principle for the many previously discrete and disparate tools and techniques used to apply formal modeling — especially UML modeling — to specific problems. For example, even before MDA, many vendors offered tools that generated code or other artifacts from UML models, but each used its own proprietary approach. Now, by following MDA, these tools can employ a common approach and can better interoperate and exchange information. In its purest form, the MDA vision is an all-encompassing approach that both embraces and extends the principles behind UML, creating a “model of models,” or a “model-driven architecture.”
In the ideal MDA world of the future, a complete and integrated set of MDA standards will allow us to move seamlessly from defining business processes to designing systems to generating running systems, all by deterministically manipulating formal models. Each step in the software lifecycle will map neatly into the next through formal model transformations defined by those MDA standards. In short, the thorough application of MDA will ultimately turn the software development and deployment lifecycle into a highly deterministic industrial process, much like manufacturing. The resulting systems will be highly standardized, highly interoperable, and relatively easy to reconfigure and/or port to new operating environments.
SEND IN THE TROOPS
This is where the military comes in. For decades, the US military (and the armed forces of other countries) employed silo systems — the very antithesis of MDA. It was almost a point of honor that the various components of any military system, including software, were highly proprietary. To the extent that they had to be physically distributed or operationally integrated, they were hard-wired using equally proprietary hardware and software connections and protocols.
This is partly the result of the military’s long-held policy of outsourcing its weapons and related command-and-control (C2) systems. The various weapons programs were funded separately by different services and on completely different time lines so there was little incentive or real opportunity for projects to collaborate on technology. Contractors competed on a per-contract basis, so even projects run by the same contractor had little opportunity to share resources.
This approach also fit in nicely with the Cold War mentality of developing monumental and highly discrete weapon and C2 systems for each service, each independently and often redundantly capable of overkill on a global scale.
In any case, the result is that the military now finds itself with a number of critical systems, particularly battlefield systems, that are difficult to integrate or redeploy in new environments or on new computing platforms. So if weapons system A has a reconnaissance capability, it can’t readily be shared with system B, even if both operate under the same or joint command. Integrating C2 systems isn’t much easier.
This hardly fits with the current popular notion of a post-9/11 “agile” military, supposedly capable of rapidly assembling and integrating units from different services — not to mention different countries — under a unified command and then crafting and recrafting the battle plan to suit changing circumstances on the ground using the latest computing technologies. Clearly, highly mobile terrorists and guerrillas are not likely to be deterred for long by fixed weapons systems that take months to redeploy or reconfigure and require a set of techno-magicians to interoperate.
How bad is this problem? Well, judging by the participants at the recent MDA Implementers’ Conference, pretty bad. Much of the military top brass has already concluded that simply adding interoperability to the list of contractor requirements isn’t enough. To ensure that kind of interoperability, the military will have to try some radically new approaches, such as MDA, even if this completely upends its customary way of doing business. The pressure to change is so strong that some elements in the military are already willing to stake the success of several major new initiatives
