Why you should reconsider using model-driven software development

Software is complicated, and the process of application development has become much more technical over time, not less so. As a result, it's become increasingly difficult to communicate critical application questions and feature proposals to the stakeholders during the design process and to get sign-off during development. Today's model-driven software development is a pathway to facilitating that communication.

Adopting MDD effectively means understanding the critical role of models as abstractions between software and operations, using MDD as an alternative to PowerPoint diagrams, ensuring that the model-code relationship is a closed loop, and linking upstream enterprise architecture and downstream application lifecycle management into MDD plans.

It's convenient in many activities to represent complex technical steps as functional abstractions, and in software development, the concept is as old as flowcharts that were translated to code. The problem with these early model-driven software development approaches was that the level of abstraction was too low -- the flowchart was almost as complex as code, and it quickly became useless as a means of communicating, even between architects and developers, because it wasn't kept up to date with changes. Early model tools, including the widely used Eclipse framework, often followed the flowchart approach implicitly and didn't link effectively with stakeholders outside the development team.

As software development matured as a science and the need for communication among application stakeholders expanded to include line departments expected to use the software being designed, the goal of this modeling changed to focus increasingly on line operations and management of stakeholder communications with the software architect. It is this new approach that today's model-driven software development is designed to support. Today's MDD is more than flowchart conversion into code -- it's a tool empowering all the stakeholders in an application or project and links the functional front end of development to the resulting code -- and back.

To be effective, MDD has to be based on abstract models that are successively decomposed as the process of design proceeds. In terms popular in the past, MDD has to enforce top-down development because it has to first decompose an application into a set of business-supporting functions that represent goals as paths to securing the desired benefits. This is the way that senior management, line departments and end users would see the application.

A good test of this first step is to ask whether the MDD models at this level could be used instead of a PowerPoint presentation to explain the application to nontechnical stakeholders. The best of today's model-driven software development approaches would support this level of communication, if not in the form of a directly exported set of models then at least by allowing the models to be transferred to a presentation format one-to-one.

Below the top, function-driven level, the goal of a good MDD strategy is to decompose first into "externalized" functions, things a user could see; then to software-and-technology functions, such as APIs, data models; and finally to code. It's important that MDD tools cover this full spectrum to close the loop of development and changes. Otherwise, you'll find your code creeping away from the models that inspired it, and those models then become worse than useless in guiding major revisions or communicating with users.

It should be clear from these points that today's model-driven software development is a bridge between enterprise architect roles and the ongoing application lifecycle management processes. This is due in part to the fact that the model-centric basis of development encourages architect participation at a lower level in the development processes, which means EA and software architect roles interact directly and continuously through development, to the point where MDD is sometimes now called "model-driven architecture," or MDA. Because modern MDD is different largely because of the EA integration, this means that modern MDD tools are often EA-centric. For example, Sparx Systems' MDD/MDA tool is called Enterprise Architect.

The emphasis on EA is appropriate here because the differentiator of today's model-driven software development is its support for early-stage engagement of operating departments and management. Organizations with formal EA models are at an advantage in MDD adoption because they have a framework in place that defines the higher layers of their MDD models. Tools based on EA principles also seem to be gaining more traction in MDD; the Eclipse project on model-driven integration has been archived, and the OMG's Model-Driven Architecture, evolved from software-centric standards like UML, has also apparently died off. Microsoft's broad efforts in MDD have come to nothing, and IBM's Rational approach seems focused on specific platforms rather than general development. All this means that MDD deserves a fresh look largely because of the recent conceptual integration with EA.

Two things remain to be addressed in the modern MDD approach: "bidirectionalism" to feedback changes to the model from code, and ALM. There are two possible approaches to this -- a tactical one and a strategic one.

The traditional way of supporting bidirectional coordination of code and modeling is to focus development on an intermediary-level model that represents the software architect's high-level view of the application. This can be easily related to code, and because it should have been derived from an EA or business-goal-set model, it can bridge between functional and technical views of the application.

The strategic option is only now emerging. The IT4IT initiative from the Open Group is an IT architecture model that spans business to technology in a single structure. For organizations who have not adopted an EA model or who are dissatisfied with the one they have, IT4IT could represent an approach to high-level modeling that explicitly resolves change coordination problems in both the business-to-IT and code-to-model directions.

In the long run, MDD seems likely to have a resurgence because it facilitates development of applications that meet business goals. If that happens, initiatives like IT4IT may then become the preferred modeling strategy at the EA level and for high-level software architecture, as well.