Model Driven Architecture – order out of chaos?

To say that most software design is “chaotic” is of course mostly meant as a joke here, but for those that have direct experience, well, they know just how many variables are involved in such an endeavor.  At its heart, MDA (or Model Driven Architecture) is a system of guidelines which seek to greatly simplify the entire process of creating software.  It’s much easier to deal with models or representations of something when examining the larger superstructure of anything.  Complex systems tend to be multifaceted of course, so any type of methodology which is able to simplify things is certainly welcome, particularly if we’re talking about it being for business purposes.

So, what is Model Driven Architecture, exactly?  If you can imagine that particular specifications are handled by separate models which they themselves can be modified, well, that’s sort of an easy way of describing how MDA works.  Model Driven Architecture is actually a means of implementing certain types of technologies and standards, like these for example:

  • UML – Unified Modeling Language

  • MOF – The Meta-Object Facility

  • XMI – XML Metadata Interchange

  • EDOC – Enterprise Distributed Object Computing

  • SPEM – The Software Process Engineering Metamodel

  • CWM – The Common Warehouse Metamodel

 Each of them has a very specific purpose or fulfills a very precise role.  Likewise, because MDA is technically considered to be “open” or proprietary, it can be further deployed on pretty much any type of platform, like:

  • Web Services (standard or otherwise)

  • JAVA

  • CORBA

  • .NET

  • J2EE

  • XMI/XML

 Needless to say, this is a very interesting approach toward design and it allows for a multi-tiered form of control which can be quite precise and detailed in nature.  However, what this really achieves is to create a design architecture where the basic components which are driving the technology remain largely unchanged.  As the creators of MDA (omg.org) explain:

                 “These platform-independent models document the business functionality and behavior of an application separate from the technology-specific code that implements it, insulating the core of the application from technology and its relentless churn cycle while enabling interoperability both within and across platform boundaries.”  

 It makes sense, keep the finer parts of the machine isolated so that you can focus on the layer(s) above as far as design, purpose and direction are concerned.  At the same time, software engineers can focus on relevant details instead of what might be deemed “irrelevant”.

In truth, modeling has already impacted the world of software engineering in a pretty major way.  Businesses in particular, with special focus on those which employ large-scale enterprise systems, seem to have been among the first to embrace a model-based way of examining their infrastructure and software solutions.  In any case, the point is to arrive at the most logical answer in the shortest amount of time possible; moreover, the use of models is meant to aid in terms of both easing understanding as well as cutting down development times.  So, how are the models themselves constructed and used, you ask?  The following four principles provided by OMG explain this in greater detail:

  • In order to create industry standards, acceptance and broad adoption of this model-based approach is required.  The end goal of course is to provide openness to consumers, as well as enhance competition among users/vendors.

  • Models should be expressed in a well-defined system of notation, this is critical when it comes to better understanding systems for enterprise-scale solutions.

  • A formal methodology for describing models via a set of metamodels, better facilitates meaningful integration and transformation among these same models, and is the basis for automation when relying on certain tools.

  • When building systems, a set of models can be controlled or manipulated by imposing a series of transformations between models, organized into an architectural framework of layers.

 As we have seen with other types of approaches to software engineering / design or even something like IT management, standards of practice and adherence to tested methodologies is undoubtedly the way to go.  Likewise, once you have more than a few people in any one industry using the same basic methodological approach, we can create and compile even more powerful / useful “best practices”.

If you’re an IT professional who is involved in either software design and/or overseeing some form of business-related enterprise architecture, it would do you well to take a closer look at Model Driven Architecture.  Not only will an MDA approach allow you to potentially derive better solutions in a faster, more efficient manner, it might also afford you the opportunity to achieve this with far fewer complexities.  The purpose of models is to simplify your comprehension of the system while at the same time keeping critical elements isolated, in situations where a business needs assurances that ongoing modifications to their legacy software and applications isn’t going to jeopardize basic operations, MDA is certainly one of the more attractive solutions.

Click here for high-impact MDA strategies

 

Previous post:

Next post:

live chat mac