Interoperability of Enterprise Applications is a serious and multi-facetted problem. One of the tasks of the recently-started INTEROP Network of Excellence is to address this problem at the modelling level through the elaboration of a Unified Enterprise Modelling Language (UEML). In this paper, some methodological hints and an embryonic mission statement are submitted to discussion with peers.
Today’s “business trends are clearly towards the need for managing organizational and operational changes within companies in order to face global competition and fluctuating market conditions” [16]. This situation forces enterprises to tackle a number of integration and therefore interoperability problems: integration of markets, integration between several development and manufacturing sites, integration between suppliers and manufacturers, integration of design and manufacturing, integration of multi-vendor hardware and software components.
“Things to be integrated and coordinated need to be modelled. Thus, Enterprise Modelling (EM) is clearly a prerequisite for enterprise integration” [16]. However, the current status of the EM domain is characterized by a Tower of Babel situation in which many Enterprise Modelling Languages (EMLs) and tools are used. All these languages and tools have different (but sometimes similar) syntaxes, semantics, purposes and capabilities. Models of parts of the enterprise expressed in the different languages are therefore hard to understand, compare and combine. This situation hinders true enterprise integration, interoperability, and shared enterprise knowledge.
The recently-started INTEROP project [
Due to the nature of the UEML project1, UEML 1.0 allows mainly the
modelling of process aspects but leaves out other aspects (such as informational or
organisational aspects) and covers only a small set of the identified requirements.
It was defined by integrating three existing EMLs (namely subsets of GRAI [
Within INTEROP, UEML’s expressiveness will be extended beyond process aspects and more requirements will be covered.
In this paper, basing on the experience in defining UEML and other modelling
languages (i.e. the Albert language [
Three important inputs for the definition of UEML 2.0 are (i) UEML 1.0 itself, (ii) the list of UEML requirements and (iii) the methodology that was used for elaborating UEML on the basis of existing languages.
Due to the goals and duration of the UEML project explained above some of these results have limitations.
First, the requirements list, which was elaborated by collecting requirements from a large number of EM actors, suffers from some weaknesses: – it is weakly structured; – it mixes requirements of different levels of detail; – it does not attach rationales to requirements; – it does not offer a big picture of what UEML is about; – it seems to address requirements that are beyond the “reasonable” scope of a UEML; – it contains requirements that are not sufficiently clear or too complex and need further refinement.
Consequently, it may be difficult to base the UEML 2.0 requirements on this list of requirements and to get a consensus among the UEML designers and users on what requirements UEML 2.0 has to address.
Secondly, although UEML 1.0 is a powerful process modelling language,
building it on only three languages is insufficient to claim that the language
is a reference or standard. Other EMLs should be considered, compared and
integrated into UEML. Currently, the three languages used come from the EM
community. Since many enterprise languages also come from the Ontology
community some of them should also be considered for integration e.g. [
To address these problems, we propose the following more top-down methodology:
1Two characteristics of the UEML project explain these limitations: its short
duration (15 months) and its objectives (investigating and demonstrating the feasibility
of using UEML for exchanging models among three EM software environments).
1. Start by defining a scope document (mission statement) for UEML 2.0. This
document would identify the main problems to be solved by UEML, the main
goals and non-goals of UEML needed to solve these problems, and the main
alternative solutions for elaborating an UEML (and their comparison with
respect to the goals and non-goals), as well as the main risks of proposing a
UEML (see Sect. 3);
2. Progressively refine top goals into more detailed requirements. This
refinement should use some existing goal refinement methodology (such as those
existing in software requirements engineering like i* [17]). The top goals
would then be decomposed progressively into simpler goals until the
requirements from UEML project or new requirements are identified.
3. Analyse and select existing EM languages and ontologies that currently best
meet some of the requirements.
4. “Integrate” these languages and ontologies into UEML. For this, the
methodology applied in the UEML project [
The methodology should also take advantage of the successes, difficulties and failures of similar initiatives (e.g. UML). Existing requirements documents written for similar purposes should also be considered (e.g. list of general requirements for programming languages [14], requirements list for PSL [13], . . . ).
In the following section, we discuss some initial ideas for the first step of the proposed methodology, namely, the scope definition. They are clearly all but complete and should be further discussed with the INTEROP partners before being elaborated. 3 3.1
The UEML should at least answer to the following two problems.
Problem 2. Scope of modelling unclear Modelling of non-software artifacts
is not common practice while it has potentially many benefits e.g. understanding
and improving the enterprise and expressing assumptions on the environement
of software [
Goal 3. UEML should be considered the EM standard for EML users and providers.
Goal 4. UEML should minimize adaptation/transition efforts and costs of current enterprise EM users and providers.
Goal 5. UEML should foster the convergence of EML providers’ contributions.
Goal 6. UEML should be an EML, a coordinated set of EMLs or a family of
related EMLs (e.g. through profiling). Based on the concept of language defined
in [
Goal 7. UEML should not be a mere exchange format (e.g. an XML-based syntax for exchanging enterprise models).
Goal 6 will help to solve both problems 1 and 2. Goal 7 is required because a mere exchange format (that is a tool-oriented language, hidden from the user) would not help to solve problem 1. This would not be sufficient to encourage the convergence of user-oriented languages.
UEML should additionally possess a number of qualities to insure its acceptance, which reduces problem 1 and 2: Goal 8. UEML should be expressive: it should offer enough constructs to allow expressing all reasonably needed EM concepts.
Goal 9. UEML expressiveness should be minimal: it should not offer more constructs than those reasonably needed for EM.
Goal 10. UEML should be natural: it should allow to express EM concepts in a reasonably intuitive/natural way, that is, straightforwardly, without cumbersome “coding”.
3.3
The definition of UEML as a standard EML could be compared e.g. to the definition of UML as a standard language for object-oriented modelling of software. The UML experience suggests the following risks for UEML’s definition: 1. Definition of a unified language is a huge and tricky task; 2. The definition and evolution process of a language might endanger its quality. Important aspects to be defined are the composition of the consortium defining UEML and the decision protocol used; 3. Acceptance by the community is uncertain.
In this paper, we underline important methodological issues for a reference EML, one of the main tasks of the INTEROP project. We suggest to start the definition process of the so-called UEML by a mission statement aimed at driving future efforts. Parts of its content are proposed and submitted to discussion.
On the basis of this scope definition, candidate enterprise representation languages and ontologies will have to be selected for integration in UEML. 13. Craig Schlenoff, Amy Knutilla, and Steven Ray. Unified process specification language: Requirements for modeling process. Technical Report NISTIR 5910, National Institute of Standards and Technology (NIST), Manufacturing Engineering Laboratory, Manufacturing Systems Integration Division, Gaithersburg, MD 20899, September 1996. http://www.mel.nist.gov/msidlibrary/doc/schlen96/ req-paper.pdf. 14. Ulf Schu¨nemann. Home-page of programming language design. http://www.cs.
mun.ca/~ulf/pld/, April 2004. 15. Mike Uschold, Martin King, Stuart Moralee, and Yannis Zorgios. The enterprise ontology. The Knowledge Engineering Review, 13, 1998. Special Issue on Putting Ontologies to Use (eds. Mike Uschold and Austin Tate). Also available from AIAI as AIAI-TR-195, http://www.aiai.ed.ac.uk/project/pub/ documents/1998/98-ker-ent-ontology%.ps. 16. Fran¸cois B. Vernadat. Enterprise modeling and integration: principles and applications. Chapman & Hall, 1996. 17. E. Yu. Modelling Strategic Relationships for Process Reengineering. Ph.D. Thesis, Univ. of Toronto, 1994.