Considering the EFx Factory and its core composability features with extensible technology-independent models, a few astute people soon get around to asking the following question:
Isn’t the EFx Factory just another implementation of MDA?
“The MDA is a new way of developing applications and writing specifications, based on a platform-independent model (PIM) of the application or specification’s business functionality and behavior. A complete MDA specification consists of a definitive platform-independent base model, plus one or more platform-specific models (PSM) and sets of interface definitions, each describing how the base model is implemented on a different middleware platform. A complete MDA application consists of a definitive PIM, plus one or more PSMs and complete implementations, one on each platform that the application developer decides to support.”
There is also a good wikipedia definition here, with more references to other sources.
The EFx factory defines architectural based models (such as the one here) for parts of its product model. These are based upon common architectural implementation patterns (such as SOA contract patterns and the .NET distributed architecture). These models define views which are technology-independent abstractions of an underlying architectural framework that actually helps implement the products of the factory. The underlying framework itself, defines abstractions of the .NET framework class libraries and Enterprise Library.
The factory has been designed to define ‘base models’ of the internal architecture of applications and services – called ‘specifications’ which have no dependency on a particular technology or implementation pattern. The technologies that are used to implement the specifications are provided by other software factories that are plugged into these base models to allow extended technology-specific models, abstractions, patterns, meta-data and artefact generation from other factories suited to this architecture. This means that the technology-independent models can be specialised towards a specific technology or technology strategy. This approach prefers an extensible technology implementation to a prescriptive technology implementation.
In effect, the models and abstractions that the EFx Factory exposes, defines a technology agnostic model, where specific technology models can be provided and overlayed by other 3rd party factories. This mechanism is outlined also in this article.
The EFx Factory is not an instance of MDA.
From the definition of MDA above, it might appear that in fact, the approach taken by the EFx Factory modelling strategy, would appear to be similar to that of MDA® – that could only be true if you equate a platform independent model (PIM) is the same as the approach as taken by EFx factory which is providing an extensible technology-independent model.
The truth of the matter is that the EFx Factory approach is in no way derived from an MDA approach, nor uses any processes, technologies nor standards that are defined by MDA, such as UML, MOF or XMI.
Using MDA as an approach in the context of software factories has several challenges that should be considered in any comparison between software factories and MDA. Jack outlines some of these in the FAQ section of his book ‘Software Factories’. However these issues are more related to MDA as an alternative approach to Software Factories as a whole, rather than a specific instance of a factory – which the EFx Factory is.
You might also want to read about the concerns around MDA here which appear to address some of the undelivered promises of MDA.
The EFx factory does not provide a platform independent model (PIM). Rather, it does provide extensible, domain specific technology-independent models. I am not just splitting hairs here. The models define specific extensibility points based upon architecture, that can be addressed by other pluggable factories (‘factorettes’ in this context) that either provide a technology-specific implementation or provide strategies to implement them. This is not the same as the platform independence described by MDA.
The plugged-in factorettes provide their own abstractions of a technology-specific view of the architecture that is exposed through an extensibility point. These extensibility points (variability points) have been determined by identifying which parts of the architecture require specific technologies or implementation patterns. The factorettes provide the abstractions, user experiences and implementation of that extensibility point. The abstractions provided by the factorettes are then integrated into the technology-independent base models to provide a technology-specific view of the architecture. That view can be either overlayed onto the technology-independent view, or displayed separately. It is then the combination of the views provided by the factory and the factorettes that provide the final user experience and actual implementation of the factory products.
Instead of MDA, you might say that the EFx Factory subscribes to a Model Driven Engineering (MDE) approach – which would be more accurate. It’s worth noting that the approach used by this factory has evolved from a grass roots approach of iterating automation and modelling of an established application framework use, which is more in line with what software factories promote.