What users want from these models, however, is portability. They want to be able to reuse models across applications and not be dependent on specific application and tool configuration. The solution appears to be unified or integrated models that would provide a single information template for any application. Users want to implement technology that will improve their capability to provide for information from currently differing models to be usable by applications and platforms enterprise wide. It seems that a set of standard models would help promote this. The problem to accomplish this is that there are as many different ways of presenting a model as there are reasons for wanting to model the domain of interest.
A namespace is a binding space for generically interfacing and managing transactions that covers all platforms, applications, and models. The namespace requires a definition about the manner in which models are interrelated. It also needs to know the state of the models that it will encounter. Is the grammar predetermined and constrained, or is it taken as it exists or is found in the enterprise(s).
With integrated models there is a standard model form. Diverse models are interpreted against the common template. Standard or reference models must be as rich as the constituent models. Perhaps all models are stored in standard form and information is filtered or translated by the applications; e.g. IRDS. Or, standard models can be agreed to by constituent model owners, e.g. STEP. Of course there are enormous difficulties associated with standardizing large numbers of models. Therefore the ability to deal with something less than integrated models most certainly is necessary.
The unified approach assumes that there exists a common meta-level template across constituent models, providing a means for establishing semantic equivalence. The metamodel is not an executable form as it is in integrated situations. Using the metamodel, any model can be translated into any other. Loss of some semantics is possible. Normalized semantics is established by owners of constituent models. The ISO/IEC JTC1 Semantic Unified Metamodel, SUMM, is an example of a unified-model template.
The federated model scenario exists if one assumes that no agent successfully or globally can impose requirements for semantic equivalence across all models of an enterprise. Models must be taken as encountered. The template is at the meta level and, like in the unified situation, the template is not executable. Some degree of integration or unification would help the communication process. Interoperability requires that models be dynamically accommodated rather than having a pre-determined metamodel. This would be furthered with some sort of predetermined terminology system. Federated models in a name space is identified as the most difficult defining problem in process interoperability.
In reality many applications will be dealing with models as encountered, or in the form in use at the time the model was created. This will be more common in interenterprise communications. This is often referred to as legacy information. For that reason, in a standard that states rules for enterprise models, where model interoperability is important, the assumption is that the federated situation exists and that the rules presented in the standard shall be rich enough to accommodate the encountered models, whatever the state. A standard for enterprise models can enhance interoperability by establishing the elements that must be present in an enterprise model. These elements would come into play when there is need for one process to communicate with another. The querying process would address the responding process. The responding process would present its standard-model elements, which include its capabilities to communicate, to the querying process, whose abilities to communicate are also in standard form. There would be a mediation to find the best fit from among the set of capabilities.
The degree of successful communication then will depend on the skills of the humans observing the process and the quality of the software employed to effect the communication. Therefore, users must analyze and predetermine, if interoperability is to be accomplished, which processes must communicate and place procedures and tools so that necessary communication can occur. The more that users wish their process to communicate with processes inside and outside the enterprise, the more pressure there would be to arrange the models in a standard way and to present their process capabilities on the medium on which interprocess communication is exchanged.