Model Driven Architecture

by Richard Soley and the OMG Staff Strategy Group

Object Management Group

White Paper

Draft 3.0 ï¿½ November 20, 2000

Preface

Itï¿½s about integration.ï¿½ Itï¿½s about interoperability.ï¿½ For eleven years, the Object Management Group (OMG) has focused on making sure that you can integrate what youï¿½ve built, with what youï¿½re building, with what youï¿½re going to build.ï¿½ As the pace of technology continues to quicken, and the demands of integrating your existing legacy systems, your new intranet, and your e-business fall on your shoulders, you need an architecture that makes interoperability central to your infrastructure.ï¿½ The bad news is that there will never be a single operating system, single programming language, or single network architecture that replaces all that has passed; the good news is that you can still manage to build systems economically in this environment.

Text Box: CORBA was a powerful first step, but we have more steps to take.
Fred Waskiewicz, OMG Director of Standards For eleven years, the OMG has led the way in providing vendor- and platform-independent interoperability standards to the enterprise. Our mission started with a focus on CORBA which took final shape in 1999 with the adoption of the CORBA 3.0 specification. To the 1995 Internet-based architecture of CORBA/IIOP, CORBA 3.0 added component-model technology that pulled together the heterogeneous computing platforms of the end of the century: the Internet, Java, Windows, SQL backends, and a thousand other technologies. While this work was going on, other additions to CORBA extended it into environments that require specialized Real-Time, Fault-Tolerant, and Embedded systems. CORBA is a huge success in these markets, and continues to be expanded down (into automotive and aerospace embedded, smart transducer markets) and up (into fault-tolerant, failover, worldwide integrated enterprise customer solutions).

CORBA, the CORBAservices, and Domain Facilities are an integral part of computing today, playing a key role in millions of installations everywhere. Nearly all the application server products on the market are based on OMG standards, and many of the thousands of OMG success stories are documented on our website at www.corba.org. CORBA programming skills are in demand; a search of the on-line job market returns thousands of job listings requesting CORBA knowledge and experience.

Since its inception, the goal of the OMG has beenï¿½ to enable a global information appliance ï¿½ that is, to make it just as easy to plug into information as it is to plug into power. Global travelers know that, although they may need an adapter or converter to plug into the mains as they move from country to country, no fundamental difference will keep them from using the power that passes through the cord. By providing transparency to operating system, platform, programming language and even network protocol, CORBA provides the adapter for the information plug, breaking down barriers to interoperability at enterprises around the world.

Text Box: Over the past decade or more, companies have endured a succession of middleware platforms.
Jon Siegel, OMG Director of Technology Transfer But heterogeneity continues to flourish in the information technology industry. By extending our vision beyond the interoperability infrastructure, our mission expands to the next frontier. CORBA is a powerful first step, but we have more steps to take.

In addition to its technologies, OMG has the worldï¿½s best standardization process. Executing our process, building consensus as they converge on technical details, OMG members produce each new specification in nine to seventeen months. Proven in the marketplace with the standardization of CORBA, the CORBAservices, Domain Facilities, UML, the MOF, and OMGï¿½s other modeling standards, the process is one of our groupï¿½s major assets. OMGï¿½s technology adoption process will play a major role in the extended standardization work proposed in this paper.

OMGï¿½s Modeling Specifications

UML, the Unified Modeling Language, allows a model to be constructed, viewed, developed, and manipulated in a standard way at analysis and design time. As blueprints do for an office building, UML diagrams allow an application design to be evaluated and critiqued before it is coded, when changes are easier and less expensive to make. The Meta-Object Facility (MOF) standardizes a model repository facility and the foundation for a companyï¿½s common reference model. The Common Warehouse Meta-model (CWM) standardizes how to represent a database schema for data warehouses, improving data mining results by matching up concepts common to multiple warehouses even where they go by different names. And finally, XML Metadata Interchange (XMI) is an interchange format for models, based on the MOF and the popular language XML.

Text Box: UML is the product of years of experience in how to model software systems.
Andrew Watson, OMG Vice President of Architecture and Technical Director Complementing, but not limited to, CORBA, OMGï¿½s modeling specifications are being used in virtually every development environment including Java/EJB, COM/DCOM/.NET and XML/SOAP. Extending the usefulness of OMGï¿½s modeling standards, forthcoming specifications will lead to automation of design flow from UML models, through coding, to running applications. Termed the Business Object Initiative (BOI), this latest OMG effort targets specific middleware environments including the CORBA Component Model (CCM) and EJB; extension to proprietary but similar environments such as MTS and .NET will appear soon.ï¿½

Middleware Proliferates

Itï¿½s difficult ï¿½ in fact, next to impossible ï¿½ for a large enterprise to standardize on a single middleware platform. Some enterprises found themselves with more than one because their different departments have different requirements, others because mergers or acquisitions created a mix. Even the lucky enterprise with a single middleware choice still has to interoperate with other enterprises or B2B markets that picked a different approach.

Whatï¿½s middleware? Middleware environments typically combine a server architecture which may be componentized but is almost certainly transactional (CCM, EJB, or MTS), with an interoperability architecture which may be standard (i.e., CORBA), proprietary (e.g., DCOM), or somewhere in the middle (e.g., XML/SOAP). Essential services beyond transactions ï¿½ such as directory, persistence, event handling, and messaging ï¿½ are usually included. There is a limited number of middleware environments, including CORBAï¿½s Component Model, Enterprise JavaBeans, XML/SOAP and .NET.

Model Driven Integration: The Architecture of Choice

At the beginning of the new century, OMG has a middleware solution that works: CORBA. Today CORBA is widely used to communicate over the Internet, integrating applications 24 hours a day, seven days a week. OMGï¿½s layered services and vertical market specifications build on CORBA, and are strongly established through the OMG community process. ï¿½Finally, OMGï¿½s modeling environment has spawned universally-recognized standards for object modeling, repositories, data modeling and data warehousing.

Text Box: Developers who adopt the MDA gain the ultimate in flexibility: the ability to regenerate code from a stable model as the underlying infrastructure shifts over time. ROI flows from the reuse of application and domain models across the software lifespan.
Dr. Richard, Soley, CEO, Object Management Group Because of the proliferation of middleware technologies, enterprises have applications on different middleware that simply have to be integrated even though this process is time-consuming and expensive. But, there is a way to simplify this situation, and itï¿½s based on the core modeling standards from OMG. The different middleware products on the market provide a reasonably consistent set of services. We already listed whatï¿½s in it: a component or component-like server infrastructure, plus transaction support, persistence, security, event-handling, network distribution, and messaging.ï¿½ What we have is the ability to apply modeling technology to pull the whole picture together.

Figure 1 lays out the Model Driven Architecture (MDA), an architecture built around an open, middleware-neutral model at its core.ï¿½ There is immense value across the software lifecycle to planning and designing your applications but, even if you donï¿½t take the time to do this, you can gain flexibility in a heterogeneous world by building your applications on a stable platform with planned, consistent, model-based components.

The core of the architecture, at the center of the figure, is based on OMGï¿½s modeling standards: UML, the MOF, and CWM. These standards, and the tools that implement them, are used to build and manipulate the core models that embody the common middleware environment.[1] There will be multiple models: One will represent Enterprise computing with its component structure and transactional interaction; another will represent Real-Time computing with its special needs for resource control; more will be added to represent other specialized environments but the total number will be small.ï¿½

The number stays small because each model represents the common features of all of the platforms in its category.[2] For example, whether your ultimate target is CCM, EJB, MTS, or some other component or transaction-based platform, if you are constructing an Enterprise application you will build it using the core Enterprise Computing model.

Figure 1: OMGï¿½s Model Driven Architecture

Mappings couple generic elements in each core model with their specific counterparts in a model of each supported platform. In Figure 1, these target platforms occupy the thin ring surrounding the core.ï¿½ Modelers, working in UML, build a platform-independent application model that specifies run-time behavior as well as business rules, and highly automated tools are able to use a mapping to convert this general application model into one targeted to a specific platform such as CCM, EJB, or MTS.

When we map a platform-independent model to a particular platform, we produce not only artifacts native to that platform (IDL, deployment descriptors, etc.) but also a platform-specific UML model. We do this because the UML model can express the semantics of the platform-specific solution much more richly than IDL or XML.

MOF and XMI are for metadata management, i.e. for managing models in repositories and streaming models via XML. UML is for object-oriented analysis & design, i.e. for producing object and component models. CWM is for data warehousing, i.e. for database models (schema), schema transformation models, OLAP and data mining models, etc.ï¿½ Both UML and CWM are MOF-based, so UML models and CWM models can be managed by MOF tools.

Maximizing automation of the mapping step is a goal; however, in most cases some hand coding will be required, especially in the absence of MDA tools. As users and tool builders gain experience, and techniques for modeling application semantics become better developed, the amount of intervention required will decrease.

The platform-specific model faithfully represents both the business rules and run-time semantics of the application. Itï¿½s still a UML model, but now realized (because of the mapping step) in a dialect of UML that precisely mirrors run-time elements of the target platform. Run-time semantics input into the platform-independent original model have been carried through mostly automatically.ï¿½

We can generate a lot of the code and reduce the need for hand programming by an order of magnitude, and in some cases we will be able to generate all of the code.

The next step is to generate the application code itself. For component environments, the system will have to produce many types of code and configuration files including Interface files, Component definition files, program code files, Component configuration files, and Assembly configuration files. The more completely the platform model reflects the actual platform implementation, the more completely the application semantics and run-time behavior can be included in the platform-specific application model and the more complete the generated code will be. In a mature MDA environment, platform models will be nearly complete and code generation will be substantial or, perhaps in some cases, even complete. Early versions are unlikely to provide this level of automation, but even initial implementations will simplify development projects and represent a significant gain, on balance, for early adopters.

Modeling as much of the application semantics as precisely as possible enables a greater degree of code generation.

As Figure 1 shows, many of todayï¿½s connection technologies will be integrated by the MDA, with room for tomorrowï¿½s ï¿½next best thing.ï¿½ CORBA provides the best middleware choice because it is vendor- and language-neutral, and bridges easily to all of the other middleware environments. But, to accommodate those enterprises with multiple middleware platforms on their network, many non-CORBA platforms will be incorporated into the MDA. One of the first will be the Java-only EJB; in fact, work on this mapping has already started.ï¿½

Because the MDA is based on a platform-independent core model, adding new middleware platforms to our interoperability environment is straightforward: After identifying the way a new platform represents and implements common middleware concepts and functions, OMG members will incorporate this information into the MDA as a mapping. XML/SOAP and .NET will be integrated in this way; going one step further, by rationalizing the conflicting XML DTDs that are being proposed in some industries, the MDA can even help you interoperate across them.

Some of the transformation standards in the CWM can be used with quite an effect to help solve the DTD transformation problems that the XML-specified interface standards will inevitably run into.

As representations of multiple middleware platforms are added to the MDA and mature over time, generation of integration tools ï¿½ bridges, gateways, and mappings from one platform to another ï¿½ will become more automated.

Interoperability will be most transparent within a domain: Enterprise applications with other Enterprise applications; Real-Time applications with other Real-Time applications. This follows from our basis on a separate core model for each domain; differences between domains prevent us from basing all of our applications on a single core model. By identifying and exploiting concepts common to two or more domains, even these boundaries can be smoothed somewhat.

Our discussion so far has assumed that we were building our application ï¿½ and its model ï¿½ from scratch. Legacy applications do not fit this pattern. With many built before component environments were even conceived, applications in this category typically will not fit smoothly into any of our core models. However, legacy applications may be brought into the MDA by wrapping them with a layer of code consistent with the MDA Enterprise component core model, or another core model if appropriate. If we build an MDA model of the wrapper first, the outer portion ï¿½ï¿½ that faces the network and interoperates with our other applications and services ï¿½ï¿½ may be generated automatically at least in part, although the other side of the wrapper ï¿½ that invokes and returns from the legacy application itself ï¿½ will typically have to be hand coded.ï¿½

Legacy wrappers will have to do all sorts of things that require programmer intervention and canï¿½t be rolled into a generic mapping rule, such as making LU 6.2 calls to mainframe transactional systems.

There is no denying that, over the past decade or more, many companies have endured a succession of middleware platforms. ï¿½Standardizing components at an platform level, through standards such as CORBA, is certainly a viable solution to the integration and interoperability problem, but we can do something additional: By standardizing a platform-independent model at the next layer above middleware, companies are assured an even easier path to integration. The MDA is OMGï¿½s strategy to deal effectively not only with the many middleware solutions which may be in use today, but also with new approaches as they appear on the market.

As the next generation of OMG standards, the MDA plays the role of the next generation Internet ORB, integrating across all middleware platforms ï¿½ past, present, and future. OMG, the organization that knows ORBï¿½s better than any other, is the ideal organization to extend this concept beyond middleware standards to a middleware-neutral model-driven approach. MDA users gain these specific advantages:

ï¿½ Your legacy applications ï¿½ that is, the ones that keep your business in business ï¿½ will interoperate with your current applications once you wrap them as we described and incorporate their functions into the MDA. You can leave them on their established platforms; the MDA will help automate the construction of bridges from one environment to another.

ï¿½ You will be able to build new MDA-based applications using the middleware of your companyï¿½s choice.ï¿½ You will have the security of knowing that interoperability bridges and gateways to other MDA-based applications within your enterprise can be generated, for the most part, automatically, as will your interconnections with customers, suppliers, and business partners,.ï¿½

ï¿½ Industry standards ï¿½ in your industry and others ï¿½ will be defined in the MDA core models: Standard facilities performing standard functions, that you can buy instead of build, with interoperability provided by their MDA roots. Weï¿½ll describe these facilities and their role in the next section of this paper.

ï¿½ As new middleware platforms emerge, the OMGï¿½s rapid consensus-based standardization process will incorporate them into the MDA by generating mappings. Because each MDA applicationï¿½s core model incorporates run-time behavior as well as business rules, MDA tools will be able to generate applications from it using this new mapping, as well as bridges between it and each of the other MDA platforms. This ensures that all MDA applications that share a core model ï¿½ wrapped legacy, current, and not-yet-built ï¿½ will work together, now and into the future.ï¿½

ï¿½ Developers gain the ultimate in flexibility, the ability to regenerate code from a stable, platform-indepedent model as the underlying infrastructure shifts over time.ï¿½ ROI flows from the reuse of application and domain models across the software lifespanï¿½especially during long-term support and maintenance, the most expensive phase of an applicationï¿½s life.

Taking advantage of our standards and tools that exploit them, OMG members have this integration task well underway. The most-used middleware platforms are being mapped to the common middleware model.ï¿½ Mappings carry this to the different target environments. Models are built, viewed, and manipulated in UML; transmitted via XMI; stored in the MOF which aids in defining the model, whose common elements can be extracted and manipulated using the CWM.

Domain Integration: A Second Level

Up to this point, weï¿½ve only discussed integration of middleware elements. Now we need to integrate our application modules themselves and, in order to do this, we have to identify and define them.

Since January 1996, OMG members have been meeting as Domain Task Forces, communities focused on standardizing services and facilities in specific vertical markets. Until now these specifications have been defined as interfaces written in OMG IDL with accompanying semantic description in English text. While not programming-language independent, these efforts did remain specific to CORBA.

Text Box: There is another dimension of instability that the relatively stable platform-independent model protects you from: Shifting enterprise boundaries. The IT manager’s challenge is how to preserve the development investment made in new components when a boundary shifts and the underlying technology must change.
Andrew Watson, OMG Technical Director and Vice President of Architecture A well-conceived service or facility is always based on an underlying model even if that model is not expressed in UML. OMGï¿½s CORBAservices, CORBAfacilities, and Domain Facilities specifications fall into this category because the model for virtually every one is not expressed separately from its IDL interfaces. Because their models are hidden, these services and facilities have received neither the recognition nor the widespread implementation and use that they deserve outside of the CORBA environment, especially considering the quality of their underlying models. Extending these implied models outside of CORBA just makes sense. ï¿½OMGï¿½s Object Transaction Service, for example, serves with distinction as the Java Transaction Service, which was generated by mapping its interfaces from IDL to Java according to the OMG specification. The Healthcare Resource Access Decision Facility, already implemented in Java and EJB in addition to CORBA, is another example. There are more.

In order to maximize the utility and impact of OMG facility specifications in the MDA, they will be specified as normative platform-independent UML models, usually (especially in the early years of MDA) augmented with CORBA-specific UML models, IDL interfaces and XML DTDï¿½s or schema generated via mapping rules derived from XMI.. This will have a number of very favorable consequences:

ï¿½ A normative UML model will serve to generate nearly all implementation definitions in all of the middleware platforms supported by the MDA (though normative interface specifications in IDL and other artifacts will often be necessary).

ï¿½ Because the common middleware model and the service or facility model are all expressed in UML, much of the gateway code that enable interoperability from one middleware environment to any other can be generated automatically.

ï¿½ Because the service or facility can be used with any middleware, as well as interoperate with implementations in other middleware environments, it will have maximum impact; used by many enterprises in an industry, each of these services will become the established tool in its field.

Today OMG has ten Domain Task Forces with several more ï¿½in the chute;ï¿½ more are added from time to time. Rather than show them all in a static diagram, weï¿½ve only included a representative sample in Figure 1 where they appear as rays emanating from the center.

The Domain Task Forces produce standard frameworks for standard functions in their application space. For example, the Manufacturing group could produce standard MDA UML models for (Figure 2) CAD/CAM interoperability, PDM (Product Data Management), and a Supply Chain integration facility. Once the MDA models for these have been completed and adopted, they can be implemented partly automatically in any middleware platform supported by the MDA.

Figure 2: UML models of frameworks for vertical facilities

The three facilities that weï¿½re using for this example ï¿½ CAD/CAM, PDM, and Supply Chain ï¿½demonstrate a benefit that only the MDA can provide: CAD/CAM and PDM applications are tightly integrated and so will probably be implemented by an individual enterprise or software vendor in, for example, CORBA or EJB. Supply Chain Integration, on the other hand, is more of an inter-enterprise facility so we might expect an XML/SOAP based implementation supported by an industry market-maker or trade organization to become popular. But, it will be essential to interoperate among the three: CAD/CAM designs feed into PDM production facilities which drive the supply chain; in turn, the supply chain will refer back to CAD/CAM for details on a particular part. By starting all three out as UML models in the MDA, we may eventually be able to generate an implementation of each on its preferred platform, as well as the bridges we need to integrate each of the facilities with the other two.

These vertical market activities are the beneficiaries of the Model Driven Architecture and Pervasive Services, which weï¿½ll introduce next. Working within the OMG process, domain standardization task forces will adopt UML models of domain-specific facilities as normative standards. The Pervasive Services and Domain Facilities, included in the modeling environment, will be called on where needed. From the UML models, automatic and mostly-automatic tools will generate implementation definitions of these domain facilities in the various mapped middleware environments, along with bridges, gateways, and mappings that enable interoperability from one to another.

Mappings to the various supported target platforms will define implementation models with high levels of automation, as weï¿½ve described. Every domain facility adopted as an OMG standard must include, in addition to its normative general UML model, a complete mapping to at least one target platform and, going further, a set of programming and modeling artifacts (platform-specific model, interface code, program code, configuration files) in that target platform. The target-specific model and the programming artifacts, which have probably been adjusted by hand to some extent, will be considered normative as well. Nothing prevents the adoption of normative mappings to more than one target, although only one is required.

Pervasive Services

Enterprise, Internet, and embedded computing rely on a set of essential services. The list varies somewhat depending on the source but typically includes Directory services, Event handling, Persistence, Transactions, and Security. In addition, computing systems or applications may take on specialized attributes in either their hardware or software ï¿½ that is, they may be scalable, Real-Time, Fault-Tolerant, or designed to fit in a confined environment (Embedded).

When these services are defined and built on a particular platform, they necessarily take on characteristics that restrict them to that platform, or ensure that they work best there. To avoid this, OMG will define Pervasive Services at the platform-independent model level in UML. Only after the servicesï¿½ features and architecture are fixed will implementation definitions be generated, nearly automatically, for all of the middleware platforms supported by the MDA.

Hardware and software attributes ï¿½ Scalability, Real-Time, Fault Tolerance, or Embedded characteristics ï¿½ may be modeled as well. By defining UML representations for these environments or, in the case of Fault Tolerance, an environment that combines it with Enterprise computing, OMG will extend the MDA to support and integrate applications with these desirable characteristics.

A separate UML profile for real time applications is in the works right now and I think that the mappings from that profile to platforms will be quite different than what the core Component model will be. An entity in a model based on the core Component model will map to a persistent, transactional component, whereas an entity in a real time model may map to something quite different.

Figure 3: OMGï¿½s MDA, showing the Pervasive Services and specialized computing environments.

In Figure 3, weï¿½ve shown the Pervasive Services as a ring around the outside of the diagram to emphasize that theyï¿½re available to all applications, in all environments. True integration requires a common model for directory services, events and signals, and security. By extending them to a generalized model, implementable in the different environments and easily integrated, the Model Driven Architecture becomes the basis of our goal of universal integration: the global information appliance.

What You Can Do

Although much of the infrastructure for the MDA is in place or under construction, there is still a lot to do.

If your company works at either the modeling or infrastructure level, you can have a voice in defining the MDA ï¿½ RFPs have been issued for UML 2.0, and all of the components of the BOI except the first are still in their formative stages in the OMG adoption process. Of the mappings to various middleware environments, only that to CORBA is even in progress ï¿½ the rest exist only as potential RFPs. UML models for the Pervasive Services have been neither constructed nor adopted.

Application models defined in this environment by OMGï¿½s Domain Task Forces will form the basis for implementations extending from CORBA to every middleware environment. Whether your company is a provider or user of domain-level applications, now is the time to get involved in their standardization if youï¿½re not doing it already. If you are a provider, this maximizes your impact on the future standards at the same time as it identifies you as a key player; if you are a Text Box: I think the requirements for business software will continue to evolve faster than the technology solutions and that business developers will continue to have "programming" jobs for the rest of my career.
Carol Burt, 2AB, Inc., and OMG Architecture Board Member user, this lets you put your companyï¿½s requirements into the RFP that defines the new standard. This is your opportunity to have your voice heard in the models and standards that you will end up using; you will be working with the best and the brightest in the industry to develop the architecture of choice, which

ï¿½ Integrates what youï¿½ve built, with what youï¿½re building, with what you will build in the future;

ï¿½ Remains flexible in the face of constantly changing infrastructure; and

ï¿½ Lengthens the usable lifetime of your software, lowering maintenance costs and raising ROI.

Expanding the Role of the Object Management Group

We are continuing our quest to support integration and interoperability across heterogeneity at all levels.ï¿½ Our first mission, to enable integration through the introduction of the distributed object model, is complete: objects are the way systems are built today, at the core of every vendorï¿½s enabling architecture and also at the core of all e-businesses.ï¿½ But the integration task is not yet done.ï¿½ To focus on this, OMG will extend our focus from a middleware-centric to a modeling-centric organization.

To support this effort, the OMG must also concentrate extra effort on conformance testing, certification of programmers and certification of products (branding).ï¿½ While OMG has been involved in the past with various testing & branding efforts for its standards, and is currently building programmer certification for the CORBA and UML technologies, the expanded role of the OMG must be built on rock-solid testing, certification and branding. In many cases these efforts will depend on strong relationships with outside organizations with relevant expertise.ï¿½ Focusing on this problem is critical to the success for OMGï¿½s new role.

The foundation for the new role of the organization will be the current Analysis and Design Task Force and its work on UML, the MOF, XMI, and CWM, along with work in progress on the BOI and UML representation of EAI.

Domain Task Forces will produce specifications that are, at their heart, normative UML models. Mappings convert these UML models to implementation definitions on the various MDA target platforms: OMG CCM, Java EJB, and soon MTS, .NET, XML/SOAP, and other environments. Mappings and interfaces will also be normative. Mapping to one target will be required, although many MDA specifications will standardize mappings to several.

Today, companies whose submissions are adopted by OMG members as our standard must agree to market or commercially use an implementation of the specification. Under MDA, the commercial availability requirement will remain, ensuring that OMG standards remain relevant to the marketplace: Successful submitting companies will have to provide a platform-independent UML model of their specification in the appropriate base, a mapping to one of the supported target platforms, and the corresponding interfaces whether generated automatically or supplemented with hand-coded additions.

CORBA is a foundation of this new architecture. As the only platform- and language-independent middleware, it is a vital and necessary part of the MDA superstructure; software bridges would be hard to build without it. Extending this superstructure, the MDA is expressed completely in terms of modeling concepts, moving the reuse equation up one level.

Conclusion

The need for integration remains strong and OMGï¿½s work is not yet complete ï¿½ we need to build on the success of UML and CORBA. With our experience, cohesive membership, established process, and tradition of consensus-based decision-making, OMG is in the ideal position to provide the model-based standards that are necessary to extend integration beyond the middleware approach. Weï¿½ve outlined the task, and directions of the solution, in this paper. Now is the time to put this plan into effect.ï¿½ Now is the time for the Model Driven Architecture.

[1] In OMGï¿½s terminology, these models are UML Profiles. A number of these profiles are already well along their way to standardization at OMG. For details, see the companion white paper Developing in OMGï¿½s New Model Driven Architecture.

[2] In technical terms, it is a metamodel of the category.