Programme Integrating and Strengthening the European Research Strategic Objective Networked business and government Integrated Project / Programme Title Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Application Acronym ATHENA Project No 507849 ATHENA – Project Name Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project No A1
DELIVERABLE D.A1.1.1 First Version of State of the Art in Enterprise Modelling Techniques and Technologies to Support Enterprise Interoperability Work package – A1.1 Leading Partner: ESI Document Owner: Ana Belén García Díez Security Classification: Public July, 2004 Version 1.0
IP- Project / Programme ATHENA Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
Versioning and contribution history
Version Description Comments 0.1 First draft. Based on WD.A1.1.1 0.2 Template and assignments. Prepared in Mallorca meeting. 0.3 Template updated: To be completed by Ÿ After the Mallorca meeting, University of Bordeaux kindly offered partners themselves to provide inputs for section 13 (Definitions and Acronyms), based on the definitions in existing standards. Ÿ Re-organisation of some sections to avoid 5 levels of subsections, which is a disturbing practice that makes the reader lose the context. Distribution to partners (04/06/2004) 0.4 Some minor adaptations of the template to be consistent with the one As requested by proposed by PlatteConsult, and addition of the “Deliverable Process PlatteConsult. Schedule” table. 1.0 Version 1 finalised. It includes review comments from 2 internal Delivered to the reviewers (David Chen and John Krogstie) and 1 external reviewer Programme Office (Sergio Bandinelli).
DA111-SotA-v1.0/AGD PUBLIC Page ii / ii
IP- Project / Programme ATHENA Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
Table of contents
1 Summary ...... 6
2 Introduction ...... 7
3 State of the Art Assessment Principles ...... 9
4 The Problem Space: Enterprise Modelling of Collaborative Enterprises ...... 10 4.1 Process Structure, Diversity, and Evolution...... 10 4.2 Knowledge, Communication and Learning...... 11 4.3 Infrastructure Integration and Customisation...... 11 4.4 Objectives...... 12
5 Market Situation and Industrial Usage ...... 13 5.1 Industrial Diversity of Meaning and Usage...... 13 5.2 International EM Markets ...... 14 5.2.1 The Enterprise Architecture Market...... 14 5.2.2 The Business Process Management market...... 15 5.3 Application Domains ...... 15 5.3.1 Enterprise Engineering and Reengineering Activities...... 16 5.3.2 Product Life Cycle Management...... 18 5.3.3 Choice and Implementation of IT Systems and Solution (e.g. ERP - System)...... 19 5.3.4 General Enterprise Architecture and Operations Support...... 20 5.4 Market opportunities ...... 20 5.4.1 Enterprise Engineering and Reengineering Activities...... 20 5.4.2 Product Life Cycle Management...... 20 5.4.3 Choice and Implementation of IT Systems and Solution (e.g. ERP - System)...... 21 5.4.4 General Enterprise Architecture and Operations Support...... 21 5.5 Market risks...... 21 5.5.1 Locked Alliances ...... 21 5.5.2 Weak Support for All Enterprise Actors...... 21 5.5.3 Tools Complexity...... 22
6 Modelling Approach, Standardisation and Language ...... 23 6.1 Enterprise Frameworks and Architectures...... 23 6.1.1 The Zachman Framework for Enterprise Architecture...... 24 6.1.2 GERAM...... 26 6.1.3 GRAI Framework...... 31 6.1.4 ARIS (Architecture of Integrated Information Systems)...... 33 6.1.5 CIMOSA...... 37 6.1.6 The DoDAF Architecture Methodology...... 39 6.1.7 TOGAF Architecture Methodology...... 40 6.1.8 The TEAF Methodology from the US Dept. of Commerce...... 41 6.1.9 The AKM Technology from Computas ...... 42 6.1.10 ISO 15745 - Framework for Application Integration...... 44 6.1.11 MISSION approach...... 46 6.2 Industry Initiatives, Standardisation Bodies and Organisations working on EM Concepts...... 52 6.2.1 BPMI ...... 52 6.2.2 WfMC ...... 54 6.2.3 OAGIS GIS...... 57 6.2.4 OASIS BPEL...... 59 6.2.5 OASIS BCM...... 60 6.2.6 UN/CEFACT BCF ...... 63 6.2.7 Biztalk...... 65
DA111-SotA-v1.0/AGD PUBLIC Page iii / iii
IP- Project / Programme ATHENA Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
6.2.8 Rossetta Net...... 67 6.2.9 W3C ...... 69 6.2.10 OMG...... 70 6.2.11 EN/ISO 19439 : Enterprise Integration – Framework for enterprise modelling...... 71 6.2.12 EN/ISO 19400: Enterprise Integration – Constructs for enterprise modelling...... 74 6.2.13 CEN TS 14818: Enterprise Integration – Decisional Reference Model...... 77 6.2.14 ISO CD 18629: Process Specification Language (PSL)...... 79 6.2.15 ISO 15704: Requirements for enterprise architecture and methodologies ...... 81 6.2.16 ISO 14258: Concepts and Rules for Enterprise Models...... 82 6.2.17 ISO/IEC 15414: Open Distributed Processing – Reference Model – Enterprise Language83 6.2.18 Conclusions for Standards ...... 86 6.3 Enterprise Modelling Languages ...... 86 6.3.1 IEM - Integrated Enterprise Modelling...... 87 6.3.2 Metis ITM...... 94 6.3.3 Metis BPM...... 95 6.3.4 Metis UML ...... 97 6.3.5 MEML ...... 99 6.3.6 Petri Nets...... 102 6.3.7 CIMOSA...... 104 6.3.8 GRAI ...... 105 6.3.9 IDEF ...... 110 6.3.10 PSL...... 112 6.3.11 WPDL from the WfMC ...... 113 6.3.12 XPDL from the WfMC ...... 115 6.3.13 BPML (from BPMI)...... 116 6.3.14 EDOC – UML Profile for Enterprise Distributed Object Computing Specification...... 116 6.3.15 UML profile for EAI ...... 119 6.3.16 ebXML ...... 123 6.3.17 PIF – Process Interchange Format...... 126 6.3.18 UEML ...... 128 6.3.19 Business Process Definition Metamodel...... 129 6.4 Enterprise Knowledge Spaces ...... 130 6.4.1 The Innovative Space...... 131 6.4.2 The Business Operational Space...... 132 6.4.3 Other Enterprise Knowledge Spaces...... 132 6.5 Some Conclusions for WP A1.3 and WP A1.5 Developments ...... 132
7 Methodologies ...... 135 7.1 Enterprise Engineering using Reference Models...... 135 7.1.1 IEM Reference Modelling Methodology for Simulation in Production and Logistics ...... 135 7.1.2 Reference Modelling Methodology with ARIS ...... 136 7.2 Enterprise Modelling Procedure...... 137 7.2.1 IPK Procedure...... 137 7.2.2 ARIS Procedure ...... 139 7.2.3 EEDO – Extended Enterprise Development and Operations ...... 141 7.3 Business Process Reengineering Methodology...... 145 7.3.1 IPK Procedure for Business Process Reengineering...... 145 7.4 User Enabling Modelling Methodology...... 148 7.5 Capability and Maturity Models...... 150 7.5.1 CMMI - Capability Maturity Model Integration...... 150 7.5.2 E-Business Maturity Model – EMM@ ...... 151 7.5.3 IT Architecture Capability Maturity Model - ACMM ...... 152 7.5.4 Web Presence Measurement Model...... 152
8 Modelling Platforms, Infrastructures and Tools ...... 153
DA111-SotA-v1.0/AGD PUBLIC Page iv / iv
IP- Project / Programme ATHENA Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
8.1 MO²GO...... 153 8.2 GraiTools ...... 156 8.3 Metis Enterprise...... 157
9 Execution Platforms, Infrastructures and Tools ...... 160 9.1 Research Prototypes for Enterprise Model Execution...... 162 9.1.1 The EXTERNAL Infrastructure...... 162 9.1.2 Other platforms for executing high-level models ...... 164 9.2 Industrial Solutions to Enterprise Model Execution...... 167 9.2.1 Workflow Management Systems (WMS) ...... 167 9.3 Summary and conclusions...... 172
10 Conclusions ...... 173
11 Definitions and Acronyms ...... 175
12 References ...... 183
DA111-SotA-v1.0/AGD PUBLIC Page v / v
1 Summary
The objective of this report is to determine and assess the state of the art on techniques and technologies related to modelling collaborative enterprises. This state of the art will be a reference point for the production of ATHENA A1 results. The document includes: · A definition of the problem space · An analysis of the current market situation and industrial usage of enterprise modelling approaches for collaborative enterprises. · An identification and analysis of main technologies and players in the context of enterprise modelling: o General frameworks for enterprises o Initiatives and organisations o Modelling languages o Methodologies for enterprise engineering and for establishing model-driven collaborative enterprises o Platforms, infrastructure and tools · Some conclusions · Terms and definitions (used in relevant standards in the area of enterprise modelling and integration).
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
2 Introduction
ATHENA project A1 focuses of providing enterprise modelling solutions to enable collaborative enterprises. To this end, A1 will deliver results that can be summarised in a simplified manner as: · Languages extendable and comprehensive enough to express the different concepts, contents, functions, contexts and views necessary to represent both enterprise knowledge and enhanced platforms for developing, operating, reusing, managing and governing collaborative enterprises. · Methodologies to apply these languages to modelling, operating, managing and governing all kinds of enterprises, as will be verified by the selected ATHENA test-cases. · Approaches for establishing collaborative enterprises, implementing the knowledge model- driven approach to holistic design solutions, taking into account the current enterprise context and its requirements for collaboration, and taking into account requirements for concurrently modelling, developing solutions and executing work. · Platforms and tools that implement services to manage collaboration following the model-driven approach. Within this context, the objective of this report is to determine and assess the state of the art and practice of enterprise modelling techniques and technologies related to modelling collaborative enterprises. This state of the art and practice will be a reference point for the production of the above mentioned results. The overall approach followed in this report is shown in Figure 1.
Market Situation and Industrial Usage Application Domains
Establishing A1.4 Methodology
EM Infrastructure (platforms)
EM Language EM and Approach Methodology
A1.3 A1.5
Figure 1: Overall approach for analysing the State of the Art
First, we define the problem space that determines the context and scope on which the approaches and technologies have been identified and analysed (Section 4: The Problem Space: Enterprise Modelling of Collaborative Enterprises).
DA111-SotA-v1.0 PUBLIC Page 7
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
Then, we analyse the current market situation and industrial usage of enterprise modelling approaches, methodologies, infrastructures of platforms and solution spaces for collaborative enterprises, and we identify the main application domains for this technology (Section 5: Market Situation and Industrial Usage). Once the current market situation is understood, the focus is shifted to the techniques and technologies that allow enterprise modelling of collaborative enterprises. The state of the art of these techniques and technologies is analysed for the following aspects: · General frameworks and architectures for enterprise knowledge spaces (Section 6.1: Enterprise Frameworks and Architectures) · Initiatives and organisations related to enterprise modelling (Section 6.2: Industry Initiatives, Standardisation Bodies and Organisations working on EM Concepts) · Languages (Section 6.3: Enterprise Modelling Languages) · Methodologies for enterprise engineering and for establishing model-driven collaborative enterprises (Section 7: Methodologies) · Platforms, infrastructure and tools (Section 8: Modelling Platforms, Infrastructures and Tools and Section 9: Execution Platforms, Infrastructures and Tools) All the analysed modelling techniques and technologies provide inputs for the work to be done on the technical packages of A1, mainly: · WP A1.3: Collaborative Enterprise Modelling Languages and Constructs. · WP A1.4: Establishing and Management Methodology for Model-Driven Collaborative Enterprises · WP A1.5: Development of a Collaborative Modelling Platform to Enable and Manage Collaborative Enterprises.
DA111-SotA-v1.0 PUBLIC Page 8
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
3 State of the Art Assessment Principles
This section describes the principles that have guided the development of the state of the art and practice, and the previous assessment work. These principles are: Ÿ The scope of the state of the art and practice must be very focused on the key technologies related to modelling of collaborative enterprises, where the keywords are Enterprise Modelling, Model-driven Design, Collaborative Platforms and Enterprise Interoperability. Ÿ In order to establish the right context for assessing the state of the art, it is necessary to define the problem that we are addressing, which is Enterprise Modelling for Collaborative Enterprises. Thus, the State of the art report includes an introductory section characterising the problem space and highlighting the key challenges of interoperability at enterprise modelling level. The problem guides the selection of the enterprise modelling techniques and technologies to include in the State of the art and the rationale for it. Ÿ The State of the art needs to be addressed to industry. In order to create impact on the European industry, the State of the art should be attractive to industrial readers. Ÿ The report avoids replicating the information that it is already available in other sources, creating “just another long list of technologies”. The approach is to list these technologies of interest, provide a short description to allow the reader understand if it is of his/her interest or not, and provide links to available information. Ÿ It is important to show how ATHENA will move forward the State of the art, this is, to provide opinion about the future trends and promises on enterprise modelling of collaborative enterprises and to provide a statement of how ATHENA results will contribute to move the State of the art in that direction. Ÿ The State of the art follows a structure consistent with the structure of ATHENA technical results. Thus, this report assesses technologies for: o Conceptual Integration: including knowledge models, meta-models & concepts; and modelling languages and methodologies. o Technical Integration: including modelling/specification environments; and execution environments. o Applicative Integration: including pilot applications and usage. For the State of the art, this level is interpreted as the State of the Practice, this is, a description of the current market situation and industrial usage of enterprise modelling technologies, especially in the case of modelling collaborative enterprises.
DA111-SotA-v1.0 PUBLIC Page 9
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
4 The Problem Space: Enterprise Modelling of Collaborative Enterprises
This section describes the key challenges and features that characterise the problem of enterprise modelling in the context of collaborative enterprises. Seeking to achieve Interoperability among the partner companies in collaborative enterprises, we face three core challenges: Ÿ Heterogeneity, incommensurable knowledge and information perspectives, systems and software infrastructures, working practices, etc. among the partner companies; Ÿ Need for Flexibility, due to need for innovation, learning, change and exception handling; Ÿ Complexity, the richness and uncertainties of interdependencies within and among partners, their activities, resources, skills and products. Heterogeneity, need for flexibility, and complexity must be managed at different levels: Ÿ Knowledge, approaches, methods and skills needed for innovation, problem solving and work performance, the shared language and frames of reference needed for communication, etc. Ÿ Process, the planning, coordination and management of cooperative and interdependent activities and resources; Ÿ Infrastructure, the information formats, software tools, and interoperability approaches of the participating companies. The resulting problem space is summarised in Table 1. Each level is elaborated below. For networks of small organisations (SMEs), these challenges are amplified, as resources are scarcer and high entry costs are prohibitive.
Knowledge Process Infrastructure Heterogeneity Communication, Process diversity, Interoperability across establishing a common negotiating different rules companies' knowledge languages and meanings and procedures between spaces and enterprise across companies and the partners architectures (Business, disciplines Knowledge Software). Complexity Integrate capabilities, form Work management and Enterprise architectures, effective teams across planning, task assignment, managing project and different local cultures. coordination and monitoring systems portfolios; Align views with contents of activities and tasks providing new model-driven and context among and across projects, partners approaches for solutions between stakeholders and and networks, dealing with design and development; people. uncertain avoiding featuritis interdependencies among (unmanageably complex several concurrent systems) activities. Flexibility Learning, partners must be Supporting both structured Customised and able to improve practice and ad-hoc work (with personalised support; based on common evolving plans); Handling Rapid formation of VEs, experience from the VE unforeseen exceptions allowing partners to join along the way Table 1: Problem space for collaborative enterprise integration
4.1 Process Structure, Diversity, and Evolution Unstructured creative activities are often most important for the competitiveness of an enterprise. Even in seemingly routine work, exceptions and uncertainties permeate the environment. Workers reflect upon and manage these problems in a sophisticated manner (Wenger, 1998). Most enterprise knowledge work can thus be regarded as knowledge intensive, creative and emergent as concerns the logical flows of procedure. On the other hand, most work processes also have routine activities and repetitive tasks. Based on the approach, methodologies, platforms and envisioned solutions (working environment), these activities and tasks when performed can yield very different flow patterns. Many
DA111-SotA-v1.0 PUBLIC Page 10
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
companies have prescribed quality management procedures for administration, audit, approval etc. Systems must thus integrate support for ad-hoc and structured work (Haake & Wang, 1997; Jørgensen & Carlsen, 1999). Users must be supported in selecting a suitable degree of plan specificity for the current state of their process, balancing plan complexity with the need for guidance and control. In software engineering, researchers have defined process classification schemes, e.g. to select appropriate methodologies. Reflecting the wide diversity of processes, even within a single industry, up to 15 classification dimensions with 37400 process types have been proposed (Cockburn, 2003). This number suggests that predefined ways of working cannot be constructed for all variants. Instead, base methodologies must be adapted and combined in the particular circumstances of each collaborative enterprise.
4.2 Knowledge, Communication and Learning Inter-organisational and multi-disciplinary cooperation requires not only information exchange, but also knowledge sharing. Effective teams must form across local cultures. Common frames of reference are established through working together, so support systems must allow the meaning of terms, plans and artefacts to evolve. In communities of practice, this learning process is called negotiation of meaning (Wenger, 1998). Later called participative peripheral learning (Wenger and Lave, 2001) spiralling from abstract conceptual plans and architectural views through horizons of concretised and refined knowledge, until we share adequate inter-dependent views to start working together and even be able to pro-actively share knowledge in visual collaborative views.. A collaborative enterprise platform, the MPCE, as described in DA 1.5.1, must also support new approaches to work execution and management. Tasks must be assigned to whoever are qualified and available, task execution must be monitored for re-engineering and re-assignment across the collaborative enterprise (Lillehagen 2002). Lack of integration into everyday work practice is a reported shortcoming of knowledge management (KM), enterprise modelling and process improvement (Davenport & Prusak, 1993). KM too often becomes the domain of outside experts that lack a full understanding of the complexities of work and the local language of the work community (Senge 1991, Lillehagen 1994, Wenger, 1998). Work performers become sources of information to KM activities, not active participants and contributors. Standardisation and codification, rather than local innovation, organisational and social learning, become the focal points of KM. Failure rates above 50% are common (Lawton, 2001). Knowledge Management has to exploit visual collaborative scenes (Lillehagen CE 2002). The gap between what people say and what they do, makes it difficult to use enterprise models and other official accounts of work as input to KM (Argyris & Schön, 1978). This is further explained by the horizons and layers of knowledge acquisition, encoding and representation and the proximity to the action of the encoder (Lillehagen CE 2002). Still some knowledge cannot be articulated and will remain tacit, such as alternative actions, feelings and possible experimentation. Most descriptive views in industry are just for the presently needed solution while they are used, subject to an ongoing elaboration and interpretation. Innovation and learning demand that modelling infrastructures be open and must support Reflective Views, Recursive knowledge processes, Repetitive tasks and Replicable meta-models (Lillehagen CE 2002). Models and model views are never complete, but adequate for our purpose and ambition, but they must be consistent, coherent, compliant and co-managed for interoperability of models, meta-models and model elements. This is why the EKA structures and services are mandatory, see DA 1.5.1.
4.3 Infrastructure Integration and Customisation The unique nature of each collaborative enterprise, and the dynamic set of partners, seldom makes it economically viable to integrate information systems through developing new software interfaces. Standardisation today (Chen & Vernadat, 2003) requires that a whole domain is static and well understood, and is thus seldom appropriate for knowledge work. We are encoding too much of enterprise semantics and logic from enterprise knowledge spaces into application software. Consequently, we need an open, model-supported and model-driven infrastructure for collaborative concurrent modelling and execution, supporting shared understanding, work management and learning, and allowing interoperability to emerge from work, rather than being a prerequisite for cooperation. Such flexibility is seldom offered by the tools currently available for collaborative enterprise integration, like e-business frameworks, workflow management, enterprise resource planning, etc. (Alonso et al.,
DA111-SotA-v1.0 PUBLIC Page 11
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
1999). Consequently, flexibility, exception handling and learning are important research topics in all these disciplines. Simplicity invites use, while complicatedness prohibits use. But in order to achieve simplicity we must understand and master complexity, which must not be confused with complicatedness. Software that offers a wide range of functionality often becomes incomprehensible and complicated to use. Consequently, only a small portion of the available services is utilised. This condition is known as featuritis. We thus need role and task specific user interfaces, emphasising what is needed in the current context. Interfaces and semantics should also adapt to the local needs of each project. Enterprise models, articulating who performs which tasks when and why, are powerful resources for such adaptation. Systems should also adapt to the skills and preferences of each individual. Where experts should be given freedom to exercise skilled judgment, novices need detailed guidance. Personalisation fosters a sense of ownership, motivating active participation. Studies have shown that personal templates and configurations spread informally through the organisation, improving processes and disseminating knowledge in an emergent manner (Trigg & Bødker, 1994).
4.4 Objectives This report aims to demonstrate how enterprise models can help business actors handle the problems of heterogeneity, complexity, and flexibility in layered operational Enterprise Architectures and across the enterprise knowledge spaces of network life-cycles. We will however contend that enterprise integration is as much a social problem as a technical one. Current modelling infrastructures emphasise technical integration, and the understanding of collaborative enterprises as socio-technical systems must be improved. In particular, we seek to replace the common approach of using formal computer languages to control social interaction, with the application of human languages to control and customise computing infrastructures.
DA111-SotA-v1.0 PUBLIC Page 12
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
5 Market Situation and Industrial Usage This section puts emphasis on the state of industrial practice, reflecting the current market situation and industrial use of Enterprise Modelling technologies, especially in the case of modelling collaborative enterprises. This mainly includes an analysis of current markets, market offerings, application domains, and market opportunities and risks.
5.1 Industrial Diversity of Meaning and Usage
The common meaning of Enterprise Modelling is: EM is externalising and sharing enterprise knowledge. Although the term Enterprise Modelling (EM) is widespread in industrial usage, there are many different meanings and understandings about what is EM and what it is good for. Mostly, the meanings derive from the application purpose in different projects of each enterprise. Even in the same enterprise, when the participants in a project come from different organisational units, they will by their different experiences and expertise have different understanding and different views of what EM means in their daily business. For some people, modelling the enterprise means defining the business strategy and plans, for others it means defining the quality procedures for the enterprise, and yet for other it means modelling and designing the enterprise systems, etc. In general four main categories for enterprise modelling can be distinguished: 1. Human-sense making and communication: To make sense of aspects of an enterprise and communicate this with other people. 2. Computer-assisted analysis: To gain knowledge about the enterprise through simulation or deduction. 3. Model deployment and activation: To integrate the model in an information system and thereby make it actively take part in the work performed by the organisation. Models can be activated in three ways: · Through people guided by process 'maps', where the system offers no active support. · Automatically, where the system plays an active role, as in most workflow engines. · Interactively, where the computer and the users co-operate in interpreting the model. The computer makes decisions about prescribed parts of the model, while the users resolve ambiguities. 4. To give the context for a traditional system development project, without being directly implemented. As soon as we introduce specific business areas, aspects, disciplines and roles we will have many diversified views to inter-relate, interpret and adjust. At the early stages of product design projects there are many non-coordinated views of the new product enterprise, so consistency, coherency, completeness and compliance is temporarily sacrificed for creative innovation. From a knowledge externalisation, expressiveness, representation and architecture point-of-view the present State of EM can be divided into these categories of solutions being provided and used: 1. EM tools with proprietary templates, notations, meta-models and models. Modelling is driven by a set of predefined views and diagrams 2. EM tools with user-modifiable templates, extendable meta-models and languages. Again dominated by frameworks of predefined views, and meta-views limited to OODA 3. EM tools and platforms with modifiable templates, offline modelling and meta-modelling languages and model-management services. Platforms are needed to support true holistic approaches working in knowledge spaces with reflective views and recursive work patterns 4. EM platforms, including the offerings of category 3, and with services for template, model and meta-model development and management, and offering interfacing to legacy systems and other platforms 5. Modelling and execution Platforms with customisable workplaces and services for concurrent multi-project modelling, solutions development and business execution and governance. 6. Point 5 adding self-generating, self-adapting and eventually self-adjusting (executing) services.
DA111-SotA-v1.0 PUBLIC Page 13
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
7. Points 5 and 6 adding services for developing, composing, executing and remotely monitoring business and engineering services. Today, most vendors belong to categories 2 and 3, and to our knowledge only two providers are in transition between categories 3 and 4. Most models are replications of fixed templates and the others are mostly developed and even applied by consultants or internal modelling experts. Modelling is not an integrated services adapted for and by users. Most current EM offerings have a weak holistic knowledge perception and support because EM is used to help solve isolated local problems in the enterprise. Therefore, different methodologies and tools are often used. This provokes that reusing elder results and handling many tools become necessary capabilities and activities. This also results in high costs for training and a low initial acceptance among the employees for improving methodologies and adapting tools for each new project. A further consequence of the situation is that most industries are not aware of the implications, opportunities, and the potential benefits of using a holistic and integrated EM approach based on an integrated modelling and knowledge work execution platform.
5.2 International EM Markets The market penetration of EM is about 8% in the US market and 7% in Europe according to Gartner Group, and the EM markets are still perceived and measured as separate markets with approaches, methodologies, tools and solutions separate from the operational enterprise systems and solutions. Most EM projects are performed disjoint from the operational environment and solutions being modelled. So the purpose of EM is mostly for creating improved insight, overview and common understanding across disciplines and processes. The dominant market in the US is the Enterprise Architecture (EA) Market, while in Europe the EA market is developing rather slowly, but for a few exceptions. In Europe the Business Process Modelling market has so far been the dominant markets.
5.2.1 The Enterprise Architecture Market The objectives of the offerings in this market is to get an overview of the IT systems and operational solutions in the enterprise, aligning new IT initiatives and strategic investments, and to get maximum value from vested resources The EA market can further be split into a military segment, a bank and finance segment, a public services segment and an industrial segment. The most active segment in the US is the military segment with many interest and market analysis organisations doing important educational and promotional work. The second most active in the US are the government departments. In Europe the most active segments have so far been the bank and finance segment and the industrial telecom segment. In the EA military segment the FEAF organisation with its DoDAF standard is very active. FEAF coordinates the efforts in all branches of the military market, and also has links into Europe and other areas through NATO, in the Bank and Finance segment. The Open Group is an interest organisation specializing on EA methodology, and services, such as training, certification and standardisation. The trends for the future in the EA market is for architectures to become more operational, making architecture models the foundational description for enterprise design and development, much like product architectures in certain industries, and covering most enterprise knowledge element and life- cycle services. The figure below gives an overview of the major EM markets as described at the start of 2004. The EA market will not completely disappear by the end of 2007, but it will be transformed into the Enterprise Design and Development market, where enterprise architecture will attain a different role. The transformation is predicted by Gartner Group and others to be driven by both integrated secure networking platforms as the new multi-medium for voice, video, data and knowledge sharing and management. None of the existing known approaches and offerings in these markets supports interoperable models, model-driven solutions (MDS) or systems.
DA111-SotA-v1.0 PUBLIC Page 14
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
Enterprise Design &Developm. ?.? bill EURO MDS Market Work Management Governance Market PPM Market BPM Market Enterprise Architecture market 1.8 bill. EURO (2004)
2004 2005 2006 2007 Figure 2: Overview of the major EM markets
5.2.2 The Business Process Management market The BPM market will evolve from single business process modelling and management to multiple concurrent business processes, and BPM will eventually require the same kind of knowledge and business architectures, capabilities and services as does single networked enterprises. Also the span of business processes will include more and more service provisioning. The EM methods and tools used to date support mostly the organisational and IT departments. But these are only 3% of the overall staff in the enterprise. So there is an insufficient use of EM by the other employees, especially the operational employees.
5.3 Application Domains This subsection analyses and describes the main current application domains of EM according to the support for Collaborative Enterprises. In order to get a better overview, four main Application Domains are analysed: · Enterprise engineering and reengineering · Product life cycle management · Choice and implementation of IT systems and solution · General enterprise architecture and operations support In Figure 3, POPS dimensions (Product, Organisation, Process and System) and the application domains are related to show how frequently EM is applied to each type of domain. As described, there are several overlaps between the main application domains from having common sub domains.
DA111-SotA-v1.0 PUBLIC Page 15
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
Enterprise Modelling Dimension Application Domain Product Organization Process System Virtual Organization/ Extended Performance Analysis Enterprises Enterprise Engineering Visual Enterprise Continuous Process and Reengineering Manage Product Integration Improvement Development/Choice and variants, Phase Organisational Implementation of IT management (from Change Workflow Management Systems and Solutions Idea to replacement) Management e.g Synchronisation of Product Life Cycle Qualification for new product development Management products and manufacturing engineering Choice and implementation of IT Systems and solution Quality Management General Enterprise Knowledge Management Architecture and Strategy Definition operations support Decision Making Activity type Color Continuous Periodic On demand Figure 3: Main Application Domains for Enterprise modelling
5.3.1 Enterprise Engineering and Reengineering Activities
Business Process Management (BPM) can be regarded as a kind of overall strategy. Continuous Process Improvement (CPI) is part of this strategy and Performance Analysis as well as Change Management are steps of the CPI-Cycle. The linkage between them is shown in Figure 4. The Step “Process Implementation” has been added into the figure in order to accomplish the CPI-Cycle.
Business Process Management
Continous Process Improvement
Change Performance Management Analysis
Process Implemen- tation
Figure 4: CPI-Cycle
In the following, the connection between the different parts will be explained Business Process Management (BPM) BPM includes not only the design of the business processes, but also the control and operation of common functioning procedures and services. Common views of shared risks, pooled resources, values and IPR issues, and for Work Management of distributed business tasks execution. Business Process Management implies that for each logical enterprise there will be many concurrent business processes. The involvement in many business processes has created a demand for providers
DA111-SotA-v1.0 PUBLIC Page 16
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
to support and supply replicable services allowing business partners to compose, orchestrate and perform governance, manifestation and monitoring of business process execution. This means that the cycles in figure 3 are replicated for each partner each time they pursue and enter a new business opportunity. The fact that each enterprise will be engaging in many and diverse Business Processes has some very important implications: · Top-down Business Process Modelling must be complemented by bottom-up Service-Oriented Architecture and middle-out Knowledge Architecture modelling, and be supported by a BPM model and a Governance and Portfolio Management model, · Business Process Management modelling is a layer of Collaborative Enterprise modelling on top of each partner Enterprise, which is operated and managed by an internal, continuously evolving Enterprise Knowledge Model, · The business architectural layer of each partner Enterprise Model will have to be partly replicated and adapted to each collaborative Business Process they engaged in, and · There will be a need for Monitoring, Management, Governance and Business Process Portfolio Management services and share views. Collaborative business process networks will be a kind of super-enterprise, or knowledge Extended Enterprise, where concerns for concurrency and for the core enterprise logic, knowledge and competence of each partner will require model-driven solutions and systems engineering. Continuous Process Improvement (CPI) The main objective of CPI is to adapt the business processes and, by this, adapt the enterprise to new market requirements in order to keep on being competitive. CPI has been described using a number of models. Here CPI is described by a three step procedure. After the process has been designed, the actual CPI-process starts by implementing the designed process. In order to get information about the as-is-situation of the processes the next step has to be done. Performance Analysis (PA) Performance analysis delivers to the company information about the business situation. This information can be separated into different time horizons. Indicators such as the trend in sales revenues, cash flow, profit, contribution-based accounting, sales volume figures, etc. are relying on information that is rooted in the past. Therefore real time information like, · Are some customer orders completed late, or even lost? · How cost- and time-effective are individual procurement and distribution channels? · Where are the weak points and bottlenecks in the procedures? · How good was deadline reliability for a certain product line in July? · What was the average throughput time for this product line and what were the outliers? · How successfully have improvement actions been implemented? Have the processes improved since the last quarter? is needed. When the relevant information is collected and analysed, the necessary steps to improve the current situation have to be defined and implemented. To better support performance analysis and monitoring modelling and execution platforms must be integrated in order that models can import and base the model-supported analysis on as close to real- time operations and data. This is also important for trust and confidence in the analysis. Change Management (CM) The goal of change management is to ensure that the necessary changes of a business process fulfil the following conditions [1]: · Necessary actions are initiated with an acceptable delay after the change has happened (or has been decided to happen, if pro-active change management is needed) · Necessary actions are executed in a fast and effective way · All reactions and actions are initiated and executed in a controlled manner
DA111-SotA-v1.0 PUBLIC Page 17
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
An effective management of the permanent change becomes a key success-factor for an enterprise [2]. It is of fundamental importance that the people involved in changing processes are able to understand and accept those changes and make them finally happen. Therefore, the most appropriate definition of change management is [3]: · Information · Communication · Training People have to be informed about the changes. Then their feedback is required. An intense communication starts. And finally, people have to be trained to be successful in the new business process environment. The content of the relevant information, communication, and training concerning specific business processes have to be structured. The major questions that have to be addressed in change management activities are the following: · Who (people, departments, different enterprises…) is involved in the change (Organisation view)? · What are the new or modified activities (function view)? · What new or modified information is needed or produced (data view)? · Which new or modified deliverables are expected (deliverable view)? · How do the changes fit together and how do they influence the process logic (control view)? The relevance of Enterprise Engineering and Reengineering activities for Collaborative Enterprises is rated high because of the need for enterprises to adapt their business to new collaborative requirements. In order to be able to compete, this whole adaptive process has to be performed in real time. EM can deliver the models for Enterprise Engineering and Reengineering activities in order to have a common language that is understandable by all participants. Besides that, if the models are formalised enough, it would be possible to map the Enterprise Engineering and Reengineering activities directly onto the business process execution. Extensive change management is also dependent on creating an integrated modelling and execution platform, and on being able to analyse impacts and consequences of the proposed change. Change management in design and engineering today follow very tedious change management procedures, and the work to complete these procedures are mostly administrative and paper-based. Simple proposed changes can take months to evaluate and perform, while in a holistic enterprise model providing views for all impacted and involve change management can be drastically reduced by removing the administrative paper work.
5.3.2 Product Life Cycle Management The Product Life Cycle (PLC) is a proven concept that delivers information about the competitive dynamic of products. It illustrates the sales process of a product and separates this process into five steps [4]: · First, new product development stage Characteristics: very expensive, sales revenue and losses · Second, market introduction stage Characteristics: cost high, sales volume low and losses · Third, growth stage Characteristics: costs reduced due to economies of scale, sales volume increases significantly and profitability · Forth, mature stage Characteristics: costs are very low, sales volume peaks, prices tend to drop due to the proliferation of competing products and very profitable · Fifth, decline stage Characteristics: sales decline, prices drop and profits decline
DA111-SotA-v1.0 PUBLIC Page 18
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
The progression of a product through these stages is by no means certain. The objective of the Product Life Cycle Management is simplified to take care that a product reaches the mature stage as fast as possible and stays there as long as possible. The relevance of product life cycle management for Collaborative Enterprises is rated high because it is very common to have different organisations collaborating in the development, production and delivery of products. This relevance is increasing as we are entering into a global market where partners and customers are distributed. Additionally, the shift to e-Products and e-Services to compete in the global market will require new approaches for product life cycle management. EM could be a basis for decisions that have to be made concerning the Collaborative Enterprises that work together along the product life cycle (in one or several of the stages). The modelling language could be a common language between the participants. Additionally, EM allows the specification and sharing of new and emerging approaches for product development and delivery. The flexibility in the relationships with the customers in the product production and delivery stages should be also managed by the new EM approaches, which allow fast adaptation with the proper impact analysis.
5.3.3 Choice and Implementation of IT Systems and Solution (e.g. ERP - System) In today’s business, the IT-support is one of the key success factors. In order to find the suitable IT- system, several steps must be run through. This transformation process consists e.g. of four phases [5]: · Phase 1, the IS-oriented initial strategic situation is established. ”IS-oriented” means that basic IT effects on the new enterprise concepts are already taken into account. Strategic corporate planning determines long-term corporate goals, general corporate activities and resources. · Phase 2, the requirements are defined. Individual views of the application system are modelled in detail. Here as well, business-organisational content is focused. Due to the fact that the descriptions for the requirements definition are the starting point for IT implementation, it is important that more conceptual description languages are used. The used description languages have to be understandable from a business point of view as well as sufficiently conceptual in order to be a starting point for a consistent IT implementation. · Phase 3 focuses on design specification. The business models are adapted to the requirements of the implementation tool interfaces (database, network architectures or programming languages, etc.) but at this time, specific IT products are not taken into account yet. · Phase 4, the implementation description. It deals with the implementation in physical data structures, hardware components and real-world IT products.
These four phases describe the creation of an IT-system and are therefore called ”build time”. Afterwards, it follows the operations phase which is known as ”run time”. The requirements definition is closely linked with the strategic planning level. However, it is generally independent of the implementation point of view. Implementation description and operations, on the other hand, are closely connected with the “IT equipment and product level”. If any changes were made on this level, they would have an immediate effect on the kind of implementation and operation. The relevance for Collaborative Enterprises is rated high. The requirements, design and implementation of the enterprise IT systems and solutions is highly related to the ability that those enterprise systems will have to interoperate with others. It is extremely important to identify the collaborative requirements and to design the systems so that it is easy to integrate its functionality with external systems. The EM could support the different steps for choosing and implementing IT-systems by delivering suitable models. The enterprise models provide a good view of the requirements that the IT-systems will have for collaborating with external entities. On the other hand, the EM also defines the desired functionality from enterprise systems and solutions with respect to enterprise operations when interoperating with others. Finally, in the holistic approach for enterprise modelling, the links and traceability between the enterprise model and the IT-systems architecture are clearly modelled, in fact, they are part of the model. This ensures that the enterprise is using the right systems for its operations. Additionally, it facilitates a consistent change and evolution of IT systems when the enterprise makes a business decision that impacts on the enterprise model.
DA111-SotA-v1.0 PUBLIC Page 19
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
5.3.4 General Enterprise Architecture and Operations Support This application domain includes disciplines such as strategy definition and decision making, Virtual organisations/extended enterprises definition, Visual enterprise integration, Planning, programming and controlling, Collaborative work management, Management of knowledge, Quality management, and Environmental management. The relevance of these aspects for Collaborative Enterprises is rated high, especially for those aspects that are labeled “collaborative”, but also for strategic aspects (for which stakeholders identification and relationships are key), management of knowledge (for which relationship with external sources of knowledge is key), Quality management (for which managing the quality of subcontractors and collaborating partners is key), etc. The EM could support General enterprise architecture and operations support by delivering suitable models for the different disciplines. The holistic approach to EM provides different views over the same model, allowing the enterprise to specify and analyse each discipline independently while automatically reflecting the impact of decisions in the other views.
5.4 Market opportunities This section describes and analyses the main market opportunities regarding the planned achievements of ATHENA on enterprise modelling in the context of collaborative enterprises. Overall numbers from the last Gartner Study: Gartner estimated in 2001 in a study about BPM Tools (Process Modelling, Simulation and Workflow Management) a market volume of 700 M $ in 2005. Thus, the market opportunity is recognised by widely-known market analysts. The following subsections include an analysis of the market opportunities in the main application domains previously identified.
5.4.1 Enterprise Engineering and Reengineering Activities At the moment, companies keep on changing from a resource-oriented to a process-oriented point of view. Combined with the trend towards concentration on core competences, Enterprise Engineering and Reengineering activities are needed to adapt the enterprise to the new market requirements. It is foreseeable that this trend will continue and so Enterprise Engineering and Reengineering activities will even get more important in the future if companies want to survive on the market. This development shows that the market opportunities for EM supporting Enterprise Engineering and Reengineering activities will grow in the near future. ATHENA enterprise modelling results address the need for engineering and reengineering collaborative enterprises. The results focus on providing the means (language, methodology and tools) to engineer the enterprise and to show this specification as an enterprise model. These means are specifically designed for collaborative enterprises, providing different views over the model (externalisation views), allowing the exchange of models between collaborating enterprises, and providing the necessary flexibility to adapt to the changing environment forced by external entities. Additionally, these results are complemented with establishing approaches that are based on the enterprise current maturity on enterprise modelling towards interoperability. Thus, the establishing methodology is adapted to the current modelling practices and ability to collaborate, and proposes a technology adoption path customised to that current status.
5.4.2 Product Life Cycle Management The situation today in Product Life Cycle Management is very similar to the previous point. The concentration on core competences also leads to networks of companies that need to work together in order to produce a product. Coordination with the partners is elementary and could/should be based on EM. In the future, the need to cooperate with other companies for product development, production and delivery will become much more essential. ATHENA will address the need for specifying the “Product” dimension of the enterprise. The results provide the means to specify the product development life cycle, and what is more important, the relationship of “product” aspects with the rest of the organisation dimensions (business processes, organisational structure, systems, decisions, etc.). Thus, the EM approach proposed shows the product life cycle management model in the context of the enterprise model. Let us remember that the
DA111-SotA-v1.0 PUBLIC Page 20
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
enterprise models defined in ATHENA are focused on the collaboration with external entities, so they are appropriate to specify the collaborations along the product life cycle. Additionally, ATHENA results provide the means to generate from the models the workplaces for the different roles involved in the product life cycle, in a personalised flavour.
5.4.3 Choice and Implementation of IT Systems and Solution (e.g. ERP - System) The importance of IT-systems for enterprises today has already been explained in 5.3.3. In the near future, in order to realise a real-time enterprise, business process automation will be indispensable. Therefore, the interaction between process definition, integration and application must run smoothly and the choice and implementation of IT-systems have to be closely linked to the previous steps. ATHENA will address the need for specifying the “Systems” dimension of the enterprise, which includes the IT systems. But the IT-systems are not identified and modelled in isolation, they are just a dimension of the enterprise model and the relationships with the rest of the elements of the enterprise model are clearly stated and precisely defined. The results provide the means to establish clear links and traceability between the enterprise processes, organisational structure, products, etc. and the IT systems that enact the model. ATHENA results ensures that the IT-systems are able to meet the interoperability requirements that are defined in the enterprise model. In the long term, the enterprise systems will be generated from the enterprise models, where generation should be understood in a broad sense that does not mean the generation of all the code, but also the identification and integration of services (web services) and applications (legacy, COTS). In the short term, ATHENA results provide the means to derive workplaces from enterprise models, and link those workplaces to the enterprise systems.
5.4.4 General Enterprise Architecture and Operations Support The disciplines under this title, already explained in section 5.3.4, are becoming as usual as the enterprise engineering and IT engineering activities. Although they were at a time less important for certain business managers because they considered them further form their core competences, the new business situations, especially those provoked by the global market, have brought them to the first line. Thus, the specification of the general enterprise architecture and operations support will be just another aspect of the enterprise that will need to be specified (modelled) and executed. ATHENA will address the disciplines such as decision making, knowledge management, etc. The enterprise if modelled in a holistic way and the necessary views are provided to the different users (this is, for different purposes). Because all the views are based on a single model, they maintain the consistency. Special focus is dedicated to the requirements for modelling collaborative enterprises.
5.5 Market risks This section explains the market risks from the different viewpoints.
5.5.1 Locked Alliances Locked alliances is a risk that may hinder interoperability. As an example, there is an alliance already implemented between: IDS Scheer AG – SAP AG Both companies have made the decision to integrated ARIS – Process Platform™ into SAP NetWeaver™, the open integration and application platform, to provide customers with a comprehensive BPM solution – and thus with a completely integrated process platform. The result of this integration for the customers will be the ability to link the modelling and optimisation of business processes with the physical configuration and execution of these processes. The consequence in the future will be the fact that business processes more than the software technology will be in the centre of attention [6].
5.5.2 Weak Support for All Enterprise Actors By having a helicopter view on enterprise modelling, it could be recognised that currently mostly the following roles in the enterprise are involved or supported by applying enterprise modelling: · Chief Information Officer (CIO) in order to design the IT infrastructure and the interfaces between software systems
DA111-SotA-v1.0 PUBLIC Page 21
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
· Organisational Department in order to adapt the enterprise organisational structure · Chief Financial Officer (CFO) in order to have a consistent view of all processes, organisations and infrastructure and their costs These roles are necessary for a successful enterprise but they are representing only a small part of the whole company. Today operational organisations, e.g. those responsible for the product life cycle, are less involved except by participating in interviews and by providing right information for modelling. Here is a potential for enterprise modelling in order to give active support to their work.
5.5.3 Tools Complexity The knowledge required to be able to perform consistent, fast and beneficial modelling is very hard to attain. The following knowledge aspects are relevant: · Modelling experience in order to express the enterprise reality according to the modelling goals and the customer – some authors states modelling is still a kind of art. Currently, there are only general methodologies to define formal and applicable goal function to guide the modelling process. · Business aspects in order to understand the conditions, terms and methodologies of the relevant enterprise part. · System design concepts (e.g. top down – bottom up) to follow an efficient methodology for modelling. · Modelling Languages – there are several modelling tools supporting different languages (more or less integrated), so an increasing set of possible constructs can be recognised. The last two aspects lead to quite complex tools. In conjunction with the two first aspects a lot of training is necessary. On the other hand, only a limited number of roles mostly in big companies perform enterprise modelling in their daily work. If modelling is not applied, the investment on resources for training and education is not adequately spent. It is not astonishing that a lot of companies do not use enterprise modelling yet because of complexity and less return of investment due to training and education needs.
DA111-SotA-v1.0 PUBLIC Page 22
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
6 Modelling Approach, Standardisation and Language
Most modelling approaches are top-down approaches staffed by consultants and people that build models for the purpose of shared understanding. This section describes the main enterprise modelling approaches. It is structured in three main parts: · Enterprise frameworks and architectures, where we describe two types of frameworks: those for integrating enterprise modelling (such as Zachman, CIMOSA, etc.) and frameworks for integrating enterprise applications (such as ISO 15745, the MISSION approach, etc.). · Industrial initiatives, standardisation bodies and organisations working on enterprise modelling concepts. · Enterprise modelling languages. · Enterprise knowledge spaces.
6.1 Enterprise Frameworks and Architectures We define a framework as a fundamental structure which allows defining the main sets of concepts to model and to build an enterprise. This section describes two types of frameworks: those for integrating enterprise modelling (such as Zachman, CIMOSA, etc.) and frameworks for integrating enterprise applications (such as ISO 15745, the MISSION approach, etc.). The dominant Enterprise Modelling Frameworks and Architectures that are being pursued by industry and interest organisations are: 1. The Zachman Framework from the The Zachman Institute for Architeture [ 2. The GERAM Framework from The University of Brisbane 3. The GRAI Framework from GRai Lab and Graisoft 4. ARIS (Architecture of Integrated Information Systems) 5. The CIMOSA Framework from CIMOSA Gmbh 6. The DoDAF Architecture Methodology from the FEAC Institute [ 3] 7. TOGAF Arcjitecture Methodology from the Open Group 8. The TEAF Methodology from the US Dept. of Commerce 9. The AKM technology and Knowledge Space methodology from Computas These, and others such as ISO 15745 and the MISSION approach, will be briefly described and referenced in the following sub-chapters with emphasis on their potential contribution towards future layered operational Enterprise Architectures. Here is a brief summary of possible recommendations for main contributions from all of them. The Zachman Framework has with some success been used by the Canadian Government to design their EA approach, and as a reference categorisation structure for enterprise knowledge repositories. The GERAM framework give a very good overview of the different EM modelling aspects and domains, but lacks some very important aspects such as meta-modelling capabilities, knowledge spaces and modelling platforms with repositories. The GRAI Framework from GRAI Lab and Graisoft has strong support for performance indicator management and supporting decision making, but has limited expressiveness and platform integration. ARIS (Architecture of Integrated Information Systems) has strong top-down process modelling and integration capabilities, but lacks expressiveness for other aspects and the “big picture” created by a holistic approach. The CIMOSA Framework is a good reference framework, but lacks expressiveness for multiple dependencies of types of view, for evolving concepts, contents and capabilities and for capturing context. The DoDAF Architecture Methodology from the FEAC Institute is a comprehensive framework and methodology targeted specifically at systems engineering in the military forces, and cover all kinds of
DA111-SotA-v1.0 PUBLIC Page 23
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
systems not just software systems. It has a strong categorisation of enterprise knowledge contents. TOGAF Architecture Methodology from the Open Group has a good methodology for developing an approach (the Architecture Development Methodology – ADM), but again it is just a framework of descriptive fairly abstract views. The TEAF Methodology from the US Dept. of Commerce is specifically tuned to deliver a methodology to the US Government agencies and all administrative legislative and financial systems, so this architecture is very rich for those application domains. The AKM technology and Knowledge Space methodology from Computas has its strength in the concepts of Enterprise Knowledge Spaces, knowledge architectures for reuse, and the expression and representation of work-generative knowledge. It is lacking an integrated platform and support for the knowledge architecture. Common to all of these is that they are descriptive frameworks, defining enterprise domains and their views and contents, but they are today all architecting methodologies for producing descriptive architectures detached from the operational platforms and systems out there.
6.1.1 The Zachman Framework for Enterprise Architecture Summary The Framework as it applies to Enterprises is simply a logical structure for classifying and organising the descriptive representations of an Enterprise that are significant to the management of the Enterprise as well as to the development of the Enterprise’s systems. The Framework graphic in its most simplistic form depicts the design artefacts that constitute the intersection between the roles in the design process, that is, OWNER, DESIGNER and BUILDER; and the product abstractions, that is, WHAT (material) it is made of, HOW (process) it works and WHERE (geometry) the components are, relative to one another. These roles are somewhat arbitrarily labelled PLANNER and SUB-CONTRACTOR and are included in the Framework graphic that is commonly exhibited. From the very inception of the Framework, some other product abstractions were known to exist because it was obvious that in addition to WHAT, HOW and WHERE, a complete description would necessarily have to include the remaining primitive interrogatives: WHO, WHEN and WHY. These three additional interrogatives would be manifest as three additional columns of models that, in the case of Enterprises, would depict: WHO does what work, WHEN do things happen and WHY are various choices made. The Framework, as it is applied to an Enterprise, depicting Enterprise design artefacts (models,) using Enterprise terminology appears below in Figure 5. A balance between the holistic, contextual view and the pragmatic, implementation view can be facilitated by a Framework that has the characteristics of any good classification scheme, that is, it allows for abstractions intended to: a. simplify for understanding and communication, and b. clearly focus on independent variables for analytical purposes, but at the same time, c. Maintain a disciplined awareness of contextual relationships that are significant to preserve the integrity of the object.
DA111-SotA-v1.0 PUBLIC Page 24
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
Figure 5 – The Zachman Framework for enterprise architecture
DA111-SotA-v1.0 PUBLIC Page 25
IP- Project ATHENA IP- Project - No ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number Document Deliverable D.A1.1.1 Date
In summary, the Framework is: a. SIMPLE - it is easy to understand ... not technical, purely logical. In its most elemental form, it is three perspectives: Owner, Designer, Builder ... and three abstractions: Material, Function, and Geometry. Anybody (technical or non-technical) can understand it. b. COMPREHENSIVE - it addresses the Enterprise in its entirety. Any issues can be mapped against it to understand where they fit within the context of the Enterprise as a whole. c. a LANGUAGE - it helps you think about complex concepts and communicate them precisely with few, non-technical words. d. a PLANNING TOOL - it helps you make better choices as you are never making choices in a vacuum. You can position issues in the context of the Enterprise and see a total range of alternatives. e. a PROBLEM-SOLVING TOOL - it enables you to work with abstractions, to simplify, to isolate simple variables without losing sense of the complexity of the Enterprise as a whole. f. NEUTRAL - it is defined totally independently of tools or methodologies and therefore any tool or any methodology can be mapped against it to understand their implicit trade- offs ... that is, what they are doing, and what they are NOT doing. The Framework for Enterprise Architecture is not "the answer." It is a tool for thinking. If it is employed with understanding, it should be of great benefit to technical and non-technical management alike in dealing with the complexities and dynamics of the Information Age Enterprise. Authority John Zachman is the author of the "Framework for Information Systems Architecture", which has received broad acceptance throughout the world as an integrative framework for managing change in Enterprises and in the systems that support them. John Zachman is a member of the International Advisory Board of the Data Administration Management Association, DAMA International; a member of the International Information Resource Management Advisory Council of Smithsonian Institution in Washington DC; and of the Board of Directors of the Repository/Architecture/Development Users Group. John A. Zachman Zachman International 2222 Foothill Blvd. Suite 337 La Cañada, Ca. 91011 Int'l Phone: +1-818-244-3763 Int'l Fax: +1-818-244-3763 General references (Public) 1. "A Framework for Information Systems Architecture." John A. Zachman. IBM Systems Journal, vol. 26, no. 3, 1987. IBM Publication G321-5298. 914-945-3836 or 914-945-2018 fax. 2. "Extending and Formalizing the Framework for Information Systems Architecture." J.F. Sowa and J. A. Zachman. IBM Systems Journal, vol. 31, no. 3, 1992. IBM Publication G321-5488. 1- 800-879-2755. Web site : www.frameworksoft.com/ The full explanation of the Zachman Framework is found on: http://www.zifa.com/ From their ZIFA web-site one can find explanation of its composition, use and value to users.
Analysis for interoperability Zachman’s architecture provides the set of concepts and principles to model, design and implement enterprise systems in a holistic way. It supports Integrated interoperability paradigm. A research has been reported to map Zachman’s framework to GERAM framework which is now an ISO standard (ISO 15704).
6.1.2 GERAM Summary and Scope GERAM (Generalised Enterprise Reference Architecture and Methodology) Version 1.6.2
DA111-SotA-v1.0 PUBLIC Page 26
IP- Project ATHENA IP- Project - No ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number Document Deliverable D.A1.1.1 Date
GERAM encompasses all knowledge needed for enterprise engineering / integration. Thus GERAM is defined through a pragmatic approach providing a generalised framework for describing the components needed in all types of enterprise engineering/enterprise integration processes, such as: · Major enterprise engineering/enterprise integration efforts (green field installation, complete re-engineering, merger, reorganisation, formation of virtual enterprise or consortium, value chain or supply chain integration, etc.); · Incremental changes of various sorts for continuous improvement and adaptation. GERAM is intended to facilitate the unification of methods of several disciplines used in the change process, such as methods of industrial engineering, management science, control engineering, communication and information technology, i.e. to allow their combined use, as opposed to segregated application.
Background Previous research carried out by the AMICE Consortium on CIMOSA, by the GRAI Laboratory on GRAI and GIM, and by the Purdue Consortium on PERA, (as well as similar methodologies by others) has produced reference architectures which were meant to be organising all enterprise integration knowledge and serve as a guide in enterprise integration programs. Starting from the evaluation of existing enterprise integration architectures (CIMOSA, GRAI/GIM and PERA), the IFAC/IFIP Task Force on Architectures for Enterprise Integration has developed an overall definition of a generalised architecture. The proposed framework was entitled ‘GERAM’ (Generalised Enterprise Reference Architecture and Methodology). GERAM is about those methods, models and tools which are needed to build and maintain the integrated enterprise, be it a part of an enterprise, a single enterprise or a network of enterprises (virtual enterprise or extended enterprise). Authority § IFIP – IFAC Task Force on architecture for enterprise integration. § ISO WD15704, Requirements for enterprise-reference architectures and methodologies
General references (Public) [1] CIMOSA - Open System Architecture for CIM; ESPRIT Consortium AMICE, Springer-Verlag, Berlin, 1993, (ISBN 3-540-56256-7), (ISBN 0-387-56256-7). [2] CIMOSA - Open System Architecture for CIM, Technical Baseline; Version 3.2 CIMOSA Association, private publication (March 1996). [3] G.Doumeingts, B.Vallespir, D.Chen, Decisional Modelling using the GRAI Grid, in P.Bernus, K.Mertins and G.Schmidt, Handbook on Architectures of Information Systems, Springer- Verlag., (1998). pp313-338 [4] C. Menzel, RJ. Mayer, The IDEF Family of Languages, in P.Bernus, K.Mertins and G.Schmidt, Handbook on Architectures of Information Systems, Springer-Verlag., (1998). pp209-242 [5] ISO TC184/SC5/WG1, http://www.cit.gu.edu.au/~bernus/taskforce/Meetings/brisbane98/technicalprogramme/pos- ppr/jimnell.html Standard § ENV 40 003 Computer Integrated Manufacturing - Systems Architecture - Framework for Enterprise Modelling CEN/CENELEC, 1990. § ENV 12 204 Advanced Manufacturing Technology - Systems Architecture - Constructs for Enterprise Modelling CEN TC 310/WG1, 1995. § CEN/TC310 “CIM Systems Architecture - Enterprise model execution and integration services - Evaluation report” CEN Report CR: 1831 :1995. § CEN/TC310 “CIM Systems Architecture - Enterprise model execution and integration services - Statement of Requirements” CEN Report CR: 1832 :1995.
DA111-SotA-v1.0 PUBLIC Page 27
IP- Project ATHENA IP- Project - No ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number Document Deliverable D.A1.1.1 Date
§ CD 14258 “ Industrial automation systems - Rules and guidelines for enterprise models” ISO TC184/SC5/WG1, 1996
Constructs and syntax definition (bibliography references and urls)
GERA EEM EMLs Enterprise Modelling Languages Generalised Enterprise Enterprise Engineering provide modelling constructs for Reference Architecture Methodology identifies concepts of modelling of human role, describe process of processes and technologies enterprise integration enterprise engineering
utilise employs implemented in GEMCs Generic Enterprise Modelling Concepts (Theories and Definitions) define the meaning of PEMs enterprise modelling constructs EETs Partial Enterprise Models Enterprise Engineering Tools provide reusable reference support enterprise engineering models and designs of human support roles, processes and technologies used to build
EMs Enterprise Models enterprise designs, and models to EMOs support analysis and operation Enterprise Modules provideimplementable used to implement modules of human professions, operational processes, technologies EOS Enterprises Operational Systems support the operation of the particular enterprise
Figure 6 - GERAM (Generalised Enterprise Reference Architecture and Methodology) framework components
Description of GERAM Framework Components (Figure 6) GERA – Generalised Enterprise Reference Architecture GERA defines the generic concepts recommended for use in enterprise engineering and integration projects. These concepts can be classified as: 1. Human oriented concepts: They cover human aspects such as capabilities, skills, know- how and competencies as well as roles of humans in the enterprise organisation and operation. The organisation related aspects have to do with decision level, responsibilities and authorities, the operational ones relate to the capabilities and qualities of humans as enterprise resource elements. In addition, the communication aspects of humans have to be recognised to cover interoperation with other humans and with technology elements when realising enterprise operations. Modelling constructs will be required to facilitate the description of human roles as an integral part of the organisation and operation of an enterprise. The constructs should facilitate the capture of enterprise models which describe: human roles, the way in which human roles are organised so that they interoperate with other human and technology elements when realising enterprise operations and the capabilities and qualities of humans as enterprise resource elements. An appropriate methodology will also be required which promote the retention and reuse of models which encapsulate knowledge (i.e. know-how
DA111-SotA-v1.0 PUBLIC Page 28
IP- Project ATHENA IP- Project - No ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number Document Deliverable D.A1.1.1 Date
possessed by humans expressed as an enterprise asset) during the various life phases of enterprise engineering projects. 2. Process oriented concepts: They deal with enterprise operations (functionality and behaviour) and cover enterprise entity life-cycle and activities in various life-cycle phases; life history, enterprise entity types, enterprise modelling with integrated model representation and model views; 3. Technology oriented concepts: They deal with various infrastructures used to support processes and include for instance resource models (information technology, manufacturing technology, office automation and others), facility layout models, information system models, communication system models and logistics models.
Modelling Framework of GERA GERA provides an analysis and modelling framework which is based on the life-cycle concept and identifies three dimensions for defining the scope and content of enterprise modelling. * Life-Cycle Dimension: providing for the controlled modelling process of enterprise entities according to the life-cycle activities. * Genericity Dimension: providing for the controlled particularisation (instantiation) process from generic and partial to particular. * View Dimension: providing for the controlled visualisation of specific views of the enterprise entity.
Generic Subdivision Views Partial according } to genericity
{ { { Particular
Instantiation
Identification Customer service Subdivision according to purpose Concept Management } of activity and control Requirements Software Subdivision Hardware} according to physical Preliminary design manifestation Design Resource Detailed design Organisation Subdivision according to Implementation Information } Function model content Operation
Decommission Subdivision according Machine to means of Human } implementation Life-cycle phases Reference Architecture Particular Architecture
Figure 7 - GERA Modelling Framework with Modelling Views Figure 7 shows the three dimensional structure identified above which represents this modelling framework. The reference part of the modelling framework itself consists of the generic and the partial levels only. These two levels organise into a structure the definitions of concepts, basic and macro level constructs (the modelling languages), defined and utilised for the description of the given area. The particular level represents the results of the modelling process - which is the model or description of the enterprise entity at the state of the modelling process corresponding to the particular set of life-cycle activities. However, it is intended that the modelling languages should support the two-way relationship between models of adjacent life-cycle phases, i.e. the derivation of models from an upper to a lower state or the abstraction
DA111-SotA-v1.0 PUBLIC Page 29
IP- Project ATHENA IP- Project - No ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number Document Deliverable D.A1.1.1 Date
of lower models to an upper state, rather than having to create different models for the different sets of life-cycle activities. EEMs - Enterprise Engineering Methodology Enterprise engineering methodologies describe the processes of enterprise integration. A Generalised methodology like generalised architectures is applicable to any enterprise regardless of the industry involved. An EEM will help the user in the process of the enterprise engineering of integration projects whether the overall integration of a new or revitalised enterprise or in management of on-going change. It provides methods of progression for every type of life-cycle activity. The upper two sets of these activities (identification and concept) are partly management and partly engineering analysis and description (modelling) tasks. EMLs - Enterprise Modelling Languages Enterprise Modelling Language define the generic modelling constructs for enterprise modelling adapted to the needs of people creating and using enterprise models. In particular enterprise modelling languages will provide construct to describe and model human roles, operational processes and their functional contents as well as the supporting information, office and production technologies. GEMCs - Generic Enterprise Modelling Concepts - Generic Enterprise Modelling Concepts are the most generically used concepts and definitions of enterprise integration and modelling. Three forms of concept definition are, in increasing order of formality: Glossaries, Meta-models, Ontological theories Some requirements that must be met are as follows: · Concepts defined in more then one form of the above must be defined in a mutually consistent way; · Those concepts which are used in an enterprise modelling language must also have at least a definition in the meta-model form, but preferably the definition should appear in an ontological theory
PEMs - Partial Enterprise Models Partial enterprise models (reusable reference models) are models which capture concepts common to many enterprises. PEMs will be used in enterprise modelling to increase modelling process efficiency. In the enterprise engineering process these partial models can be used as tested components for building particular enterprise models (EMs). However, in general such models still need to be adapted (completed) to the particular enterprise entity. Partial models may be expressed as: · Models which capture some common part of a class of enterprises, · Paradigmatic (reference or prototypical) models which describe a typical enterprise of a class. Prototype models can be subsequently modified to fit a particular case; · Abstract models of a part or whole of a class of enterprises which capture the commonalities but leave out specific details. This type of model is of the ‘fill-in-the-blank’ type.
EETs - Enterprise Engineering Tools Enterprise Engineering Tools support the processes of enterprise engineering and integration by implementing an enterprise engineering methodology and supporting modelling languages. Engineering tools should provide for analysis, design and use of enterprise models. EMOs - Enterprise Modules Enterprise modules are implemented building blocks or systems (products, or families of products), which can be utilised as common resources in enterprise engineering and enterprise integration. As physical entities (systems, subsystems, software, hardware, and available human resources/professions) such modules are accessible in the enterprise, or can be made easily available from the market place. In general EMOs are implementations of partial models identified in the field as the basis of commonly required products for which there is a market.
DA111-SotA-v1.0 PUBLIC Page 30
IP- Project ATHENA IP- Project - No ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number Document Deliverable D.A1.1.1 Date
EMs – Enterprise Models The goal of enterprise modelling is to create and continuously maintain a model of a particular enterprise entity. A model should represent the reality of the enterprise operation according to the requirements of the user and his application. This means the granularity of the model has to be adapted to the particular needs, but still allows interoperability with models of other enterprises. Enterprise models include all those descriptions, designs, and formal models of the enterprise which are prepared in the course of the enterprise's life history. EOSs – Enterprise Operational Systems Enterprise Operational Systems support the operation of a particular enterprise. They consist of all the hardware and software needed to fulfil the enterprise objective and goals. Their contents are derived from enterprise requirements and their implementation is guided by the design models which provide the system specifications and identify the enterprise modules used in the system implementation.
Analysis for enterprise interoperability GERAM is part of ISO 15704 standard. For the analysis of its relevance to enterprise interoperability and its use in ATHENA A1, please see section 5.2.15 on ISO 15707 standard (Requirements for Enterprise architecture and methodologies).
6.1.3 GRAI Framework First of all, we must clarify the notations: § GIM (GRAI Integrated Modelling) includes the GRAI model, modelling framework, GRAI formalisms, GIM structured approach (= GRAI structured approach adapted to the multi- model). § GRAI Methodology includes GIM, a group of specific methods. Here, we just present GIM. GIM is composed of three main constructs: ? A reference model of an enterprise system (GRAI model), ? Several modelling formalisms organised by a modelling framework, ? A structured approach, Summary The modelling framework
Reengineer an enterprise suppose to model it. Because of its high complexity, various concepts need to be defined and models to be built. In order to ensure the completeness, consistency and integration all of these concepts and models, GIM proposes a modelling framework in which all the models needed for the analysis, design and implementation of an enterprise find their places. The GIM modelling framework has two dimensions: functional abstraction and decomposition levels.
Abstraction levels
The modelling activity implies a simplification of a too complex reality. So, a model keeps only concepts and elements which will be necessary at the time of the model use. The introduction of the abstraction levels allows a 'stratified description' in the sense that GIM framework is in fact constituted of several ones which integrate specific concepts. Practically, GIM framework owns three abstraction levels ? Conceptual level. Made up without any organisational or technical consideration, it is the steadiest level and aims at asking the question 'What?'; ? Structural level. It integrates an organisational point of view and aims at asking the questions 'Who?', 'When?' and 'Where?'; ? Realisational level. It is the most specific level because it integrates the technical cons- traints of the studied case and enables the choice of real components.
DA111-SotA-v1.0 PUBLIC Page 31
IP- Project ATHENA IP- Project - No ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number Document Deliverable D.A1.1.1 Date
User Domains
System Views
Performance Information Decision Physical Functional Processes Resources Indicator
Abstraction levels Conceptual
User orientedoriented modelling frameworkframework Structural
Technical modelling frameworkframework
Realizational Production Organisation Information technology technologytechnology
Abstraction levels TechnicalDomains Domains
Figure 8 - The GIM modelling framework
Domain decomposition
A domain can be defined as a selective perception of a manufacturing system which concentrates on some particular aspect and disregards others. According to the GRAI model and, more generally, to the systemic approach, any production system may be split up into three systems: the physical system, the decisional system and the informational system. These three systems lead to three domains. To these three domains, according to the needs of enterprise, we add more: the functional view, the process view... The functional view enables to get a model very simple to build showing the main functions of the enterprise system and the flows (of any nature) moving between these functions. Another interest of the functional views is to define exactly the boundary of the study domain. The process view allows to describe the processes across the various function of the enterprise. The other view is the resource view. Crossing these two dimensions gives the GIM modelling framework (Figure 8). On this figure it is possible to see that the upper part of the modelling framework is user oriented while the other one is technical oriented.
Modelling formalisms
The three domains referring to a technical representation call upon knowledge of the experts concerned with these domains: · The organisation refers mainly to human resources as well in the definition of their role as in that of their structure · Information technologies gather the specifications hardware (computers, Nets,…) and software (operating system, data base management system, application software of CAM,…) · The Production Technology specifies the equipment of the physical level (machines, means of transport, stores...). That allows distinguishing two levels from total representation: a level user and a technical level. We will focus on the upper levels of the modelling framework (user orientation), because only the user domains levels have GRAI formalisms. We detail the needs for each sub-domain as follows: · Conceptual Information Model. The CIM is a description of all stable and 'natural'
DA111-SotA-v1.0 PUBLIC Page 32
IP- Project ATHENA IP- Project - No ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number Document Deliverable D.A1.1.1 Date
data of the organisation, of their attributes and of links between them. The formalism used here is the class diagram. · Structural Information Model. The SIM describes the data structure in relation to the distribution of data and the computerised / manual choice. The formalism used here is also the class diagram. · Conceptual Decision Model. The CDM is a description of the decision making structure, links between decision levels, analysis of links between objectives, analysis of constraints, and description of decision variables. The formalism used here is the GRAI grid at the global level and the GRAI nets at the detailed level. · Structural Decision Model. The SDM mainly enables the identification of decision makers, responsibility and authority. It links decision makers and decision-making. The formalism used here is the GRAI grid at the global level and the GRAI nets at the detailed level. · Conceptual Physical Model. The CPM is a description of process and routes with physical flows between operations. The formalism is the extended actigram. · Structural Physical Model. The SPM gives information about time, work centres and operators, elements about linking and synchronisation and indicates who does what. The formalism is the extended actigram. Authority § LAP/GRAI – University of Bordeaux and GRAISOFT General references (Public) B. VALLESPIR, C. MERLE and G. DOUMEINGTS, “The GRAI integrated method: a technico- economical methodology to design manufacturing systems”, Supporting tools § GRAI Tool 1.0 Analysis for Enterprise Interoperability GIM modelling framework introduces the decision dimension/view which is not taken into account in other modelling frameworks such as CIMOSA, ARIS, etc. The decisional aspect is important to establish interoperability in the context of collaborative enterprises. To interoperate in such an environment, decision-making structure, procedure, rules and constraints need to be clearly defined and modelled so that decentralised and distributed decision-making can be performed. The decisional model is now a European TS (technical specification) elaborated by CEN TC310 WG1. For more detail on how to use the decision model in ATHENA A1, please see the section 5.2.13 (CEN TS 14818: Decisional Reference Model).
6.1.4 ARIS (Architecture of Integrated Information Systems) Summary The Enterprise Modelling approach of ARIS is based on a view concept. The objective is to reduce the complexity by dividing the enterprise into individual views. In order to model the different views, different modelling languages are allocated to them, e.g. · Organisational charts, network diagram or shift calendars to the Organisational View. · Function trees, objective diagram or application system diagram to the Function View. · Entity Relationship Model (ERM), attribute allocation diagram or class diagram to the Data View. · Product tree to the Product View. The integration of the different languages is done by the Control View (see Figure 9). This combination process is done for two reasons. First, the structural relationships between the views are described and second, status modifications are explained that show the dynamic behavior of the system. Languages used there are, e.g. Event driven Process Chain (EPC), function allocation diagrams or value-added chain diagram. Not in all to the Control View assigned languages are existing constructs of every external view but at least from two views.
DA111-SotA-v1.0 PUBLIC Page 33
IP- Project ATHENA IP- Project - No ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number Document Deliverable D.A1.1.1 Date
Referring to the main objectives to the A1-project, the question has to be answered how the integration of a new object or model into ARIS is done. If there is the need to add a new object, this object can be defined including its attribute and then allocate this to the ARIS-object list. Additional to this, the relationships of the new object to the existing ones have to be define. After this it is necessary to assign the new object to one of the external ARIS-views. A new method is generated by choosing the needed objects. If the chosen objects belong to different views, the new method is automatically allocated to the Control View. If they all belong to the same view, the new method would be assigned to the same one. The extension of the method as well as the object list can only be fulfilled by the IDS Scheer AG.
Management
Materials administration Sales Scheduling Purchasing
Inquiry is received Sales processing
Inquiry Quotation Inquiry Inquiry Inquiry Quotation processing Sales processing processing
Inquiry is Check Credit processed rating
Customer Determine Customer Quotation quotation delivery date processing
Customer Customer Customer inquiry quotation order
Figure 9: View concept of ARIS
The advantage of this procedure is on one hand the extensibility of the actual object and method list. So, new requirements to existing methods can easily be realised. On the other hand, the disadvantage is the huge amount of already existing methods and objects in ARIS which doesn’t support the usability. In the future, extensibilities will only be done if this would cause benefit either to the usability or to the customer benefit. At the moment, it is possible to reduce the amount of methods by setting up filters to fade out unneeded methods or objects. Description of the framework ARIS has been developed by Prof. Scheer at the University of Saarbruecken in Germany. The conceptual design of the Architecture of integrated Information Systems (ARIS) is based on an integration concept which is derived from a holistic analysis of business processes. The first step in creating the architecture calls for the development of a model for business processes which contains all basic features for describing business processes. The result is a highly complex model which is divided into individual views in order to reduce its complexity (see Figure 10): o Function view: The processes transforming input into output are grouped in the function view. The designations ”function”, ”process” and ”activity” are used synonymously. Due to the fact that functions support objectives, yet are controlled by them as well, objectives are also allocated to the function view. In application software, computer-aided processing rules of a function are defined. Thus, application software is closely aligned with ”functions”, and is also allocated to the function view. o Organisation view: The organisation view presents the hierarchical organisation structure. It is created in order to group responsible entities or devices executing the same work
DA111-SotA-v1.0 PUBLIC Page 34
IP- Project ATHENA IP- Project - No ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number Document Deliverable D.A1.1.1 Date
object. This is why the responsible entities ”human output”, responsible devices, ”financial resources” and ”computer hardware” are allocated to the organisation view. o Data view: The data view comprises the data processing environment as well as the messages triggering functions or being triggered by functions. Preliminary details on the function of information systems as data media can be allocated to data names. Information services objects are also implicitly captured in the data view. However, they are primarily defined in the output view. o Output view: The output view contains all physical and non-physical input and output, including funds flows. o Control view/Process view: This view displays the respective classes with their view- internal relation-ships. Relationships among the views as well as the entire business process are documented in the control or process view, creating a framework for the systematic inspection of all bilateral relationships of the views and the complete process description.
Organization View Machine Organiza- Resource tional Unit
Computer Human Hardware Output Resource
Organiza - Machine tional Unit Human Output Event Goal
Hardware Goal
Message Event Function Event Function
Environ- mental Data Environ- Application mental Data Software Application Input Output Software
Data View Control View Function View
Output
Output View Figure 10: Views of the ARIS house [Scheer, A.-W.: ARIS, Business Process Framework, 3 rd edition, Berlin et al. 1999]
Due to this division, the contents of the individual views can be described by special methods which are suitable for this view without having to pay attention to the numerous relationships and interrelationships with the other views. Afterwards, the relationships between the views are incorporated and are combined to form an overall analysis of process chains without any redundancies. A second approach that also reduces the complexity is the analysis of different descriptive levels: o Requirements definition o Design specification o Implementation
Following the concept of a lifecycle model the various description methods for information systems are differentiated according to their proximity to information technology. This ensures a consistent description from business management-related problems all the way down to their technical implementation. Thus, the ARIS architecture forms the framework for the development and optimisation of integrated information systems as well as a description of their implementation. In this context, stressing the subject-related descriptive levels results in the
DA111-SotA-v1.0 PUBLIC Page 35
IP- Project ATHENA IP- Project - No ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number Document Deliverable D.A1.1.1 Date
ARIS concept being used as a model for creating, analyzing, and evaluating business management related process chains. Authority The further development of the ARIS-concept is done by the Institute of Information System (IWi) at the German Research Centre for Artificial Intelligence (DFKI) as well as by the IDS Scheer AG. General references (Public) Principal source of references about ARIS: Scheer, A.-W.: ARIS, Business Process Framework, 3 rd edition, Berlin et al. 1999, Scheer, A.-W.: ARIS, Business Process Modelling, 3 rd edition, Berlin et al. 1999. Another source is the IDS Scheer AG method handbook which gives an introduction to the modelling methods provided in the ARIS-Toolset. Constructs and syntax definition (bibliography references and urls) See Scheer, A.-W.: ARIS, Business Process Framework, 3 rd edition, Berlin et al. 1999, Scheer, A.-W.: ARIS, Business Process Modelling, 3 rd edition, Berlin et al. 1999. Another source is the IDS Scheer AG method handbook which gives a introduction to the constructs and the syntax of the modelling methods provided in the ARIS-Toolset. The constructs are presented as follows (see Figure 11). This is only an examples. Overall there are 210 constructs in the actual version of the ARIS-Toolset and overall there are 102 model types.
Figure 11 - Constructs and syntax definition in ARIS
Paradigms and concepts (references) Principal source of references about ARIS: Scheer, A.-W.: ARIS, Business Process Framework, 3 rd edition, Berlin et al. 1999, Scheer, A.-W.: ARIS, Business Process Modelling, 3 rd edition, Berlin et al. 1999. The ARIS concept was designed at the application independent meta level ( the different levels are: instance level, type level, meta level and meta² level) and is based on a process-oriented approach. Due to the fact that terms permissible at this level are also valid for underlying application types and instances, the ARIS concept is automatically applied to underlying modelling levels as well.
DA111-SotA-v1.0 PUBLIC Page 36
IP- Project ATHENA IP- Project - No ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number Document Deliverable D.A1.1.1 Date
Tutorials (public references) Principle source of tools tutorial is www.ids-scheer.com Case Studies (public references) There are a lot of case studies that prove the practical application of the ARIS-concept, see e.g. Scheer, A.-W.: ARIS, Business Process Framework, 3 rd edition, Berlin et al. 1999 as well as the success stories of the IDS Scheer AG. Supporting tools The ARIS concept was technical realised in the ARIS Toolset which was published in 1993. The ARIS Toolset has been consequently adapted to new market requirements and is right now available as ARIS 6 Collaborative Suite, version 6.2.3. Analysis for Enterprise Interoperability The different views of the ARIS-concept include variable modelling languages, e.g. EPC for illustrating the collaborative business processes. But there are extensions needed concerning the requirements of modelling collaborative enterprises like new role-concepts or the problem of depicting internal and external views of the same business process. At the moment there is a close cooperation with SAP concerning interoperability of modelling methodologies and software systems. The theoretical concepts of ARIS can be used in ATHENA but the use of the software would only be possible if the IDS Scheer AG would agree to this.
6.1.5 CIMOSA CIMOSA technical baseline, business modelling language, version 3.3 (2000) Summary CIMOSA was developed under the framework of the European Union ESPRIT research programme. It results from the consortium AMICE (European CIM Architecture). The first objective of CIMOSA is to provide a framework to analyse the evolving requirements of an enterprise and translating these into a system which enables and integrates the functions that match the requirements.
DA111-SotA-v1.0 PUBLIC Page 37
IP- Project ATHENA IP- Project - No ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number Document Deliverable D.A1.1.1 Date
INSTANTIATION
Generic Partial Particular Organization Organization Organization Organization View View View Resource Resource Resource Resource GENERATION View View View Information Information Information Information View View View Function Function Function Function
View View View DERIVATION Generic Partial Particular Requirements Requirements Requirements Requirements Definition Definition Definition Definition Modeling Level Building Models Model Blocks Generic Design Design Partial Particular Design Design Specification Specification Modeling Level Building Specification Specification Blocks Models Model Generic Partial Particular Implementation Implementation Implementation Implementation Description Description Description Description Modeling Level Building Models Model Blocks
Reference Particular Architecture Architecture
Figure 12 - The CIMOSA Framework for modelling
The CIMOSA framework (Figure 12) is in three dimensions which are: A dimension of genericity (three architectural levels) composed by: - A generic level which is a catalogue of basic building blocks - A partial level which is a library of partial models applicable to particular purposes - A particular level which is a model of a particular enterprise built from building blocks partial models A dimension of model (three modelling levels) composed by: - A requirements modelling for gathering business requirements - A design modelling for specifying optimised and system-oriented representation of the business requirements - An Implementation modelling for describing a complete CIM system and all its implemented components A dimension of view (to describe the model according to its four integrated aspects) composed by: - A function view for describing the expected behaviour and functionality of the enterprise - An Information view for describing the integrated information objects of the enterprise - A resource view for describing the resource objects of the enterprise - An organisation view for describing the organisation of the enterprise CIMOSA is only a framework for structuring enterprise modelling related issues. It addresses concepts and models that are necessary to model integrated enterprise systems focusing on process model-based enterprise activity control. Authority § CIMOSA Association e.V., Aachen/Germany General references (Public) The official websites: http://www.cimosa.de/ and http://cimosa.cnt.pl/ ESPRIT Consortium AMICE, editor. CIMOSA : Open System Architecture for CIM, volume 1 of Research Report ESPRIT, Project 688/5288 AMICE, Springer-Verlag, 2nd revised and extended edition, 1993. Martin Zelm (Ed.) CIMOSA : A primer on key concepts, purpose and business value. Technical Report, CIMOSA Association, Stuttgart/Germany, 1995.
DA111-SotA-v1.0 PUBLIC Page 38
IP- Project ATHENA IP- Project - No ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number Document Deliverable D.A1.1.1 Date
Constructs and syntax definition (bibliography references and urls) CIMOSA Association. CIMOSA : Open System Architecture for CIM, technical baseline - part. Technical Report TBL 3.2, CIMOSA Association, 1996. CIMOSA Association. CIMOSA : Open System Architecture for CIM, technical baseline - part. Technical Report TBL 3.3, CIMOSA Association, 2000. Tutorials (public references) http://www.cimosa.de/Modelling/FRB_BusMod97.html Supporting tools § First step designer, interfacing technologies, Canada. (www.interfacing.com) § CimTool, RGCP Consult, France. (www.rgcp.com) Analysis for Enterprise Interoperability How this Framework supports Enterprise Interoperability? There is no explicit consideration on interoperability issues in CIMOSA modelling framework. However, CIMOSA can be a contribution for integrated paradigm to establish interoperability (see ISO 14258). CIMOSA framework is the basis to establish the European Pre-standard ENV 40003 now published as a joint European and ISO standard known as EN/ISO 19439: Framework for enterprise modelling. For more information on its possible use in ATHENA A1, please see the section 6.2.11.
6.1.6 The DoDAF Architecture Methodology DoDAF was formerly called C4ISR and the name reflects its original target customer-group and market. C4 refers to systems for military operations, and Information System Resources. DoDAF is being further developed by the FEAC Institute of Washington DC in close cooperation with the Air Force, The Navy, The Army and Pentagon. Training is offered in cooperation with the California State University at Hayward, Summary This 20 CEU professional Practitioner's Enterprise Architecture Certificate program covers Enterprise Architecture as mandated, used and applied in the US Federal Government The FEAC Institute has now partitioned the training into 5 courses, see http://www.feacinstitute.org/enterprise_architecture/dod_architecture_framework/index.htm There is cooperation with ZIFA and naturally with the US Government and Dept. Defence, see http://www.gcn.com/enterprise-architecture/ DODAF is a requirement in all US military agencies and institutions, and is supported by the some ten leading Enterprise Architecture vendors. Authority The FEAC Institute, Washington d.c US, see: http://www.feacinstitute.org/ General references (Public) The US Government public web-site is a good general reference: http://www.gcn.com/enterprise-architecture/ For general information on EA in the US market foolow information exchange and events on: http://www.eacommunity.com/board.asp and Go to http://www.geao.org/ for ongoing government architecture work. Another good source for architecture spproaches and methodologies adapted to market segments is found at: http://www.enterprise-architecture.info/index.htm Constructs and syntax definition (bibliography references and urls)
Many universities and research institutes in the US give courses on DoDAF, such as CMU, see: http://www.sei.cmu.edu/pub/documents/03.reports/pdf/03tn006.pdf The Computas DoDAF model of the meta-model allow visual navigation of all core domains and their constructs and relationships to other constrcts and domains, such as: strategies, proposed initiatives, present IT portfolio, present systems and teheir use, users and vendors, all systems, their capabilities and use, and support for searching, view-generation, reporting, “what-if”
DA111-SotA-v1.0 PUBLIC Page 39
IP- Project ATHENA IP- Project - No ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number Document Deliverable D.A1.1.1 Date
analysis See also http://www.software.org/pub/architecture/teaf.asp for the specifications of most EA methodologies. For DODAF go to: http://www.software.org/pub/architecture/dodaf.asp
Supporting tools Most all leading Enterprise Architecture vendors are supporting DoDAF, such as METIS Enterprise from Computas, System Architect from Popkin, Mega, and the other top ten providers. Analysis for Enterprise Interoperability DoDAF is one of the most comprehensive enterprise frameworks and gives us a good understanding of the stakeholders and users and the minimum of information they must receive to align business and IT and get value out of their business and IT initiatives. However, as all the others it contributes little to integrated platforms, model-driven design and generation of interoperable solutions.
6.1.7 TOGAF Architecture Methodology
TOGAF has from its early days, 1997, been developed and owned by the Open Group, an international interest organisation. It now has a strong position with private industry in the US, Britain and Japan. Summary The present version of TOGAF being offered is version 8 and work on version 9 is underway. TOGAF has a good certification and training services in place since version 7. Most EA tool vendors are members and have access to these versions, and to services helping them to qualify as authorised and certified TOGAF compliant providers of the methodology, and to get access to other services like training, consulting and events participation.
TOGAF has itself an interesting architecture. It offers an Architecture Development Methodology (ADM) as a separate model, the current model is built in Metis from Computas,
Authority TOGAF is the property of the Open Group Go to:: http://www.opengroup.org/boston2004/iqm-workshop.htm General references (Public) Their official web-site at:: http://www.opengroup.org/boston2004/iqm-workshop.htm
For general information on EA in the US market follow information exchange and events on: http://www.eacommunity.com/board.asp.
Another good source for architecture approaches and methodologies adapted to market segments is found at: http://www.enterprise-architecture.info/index.htm
Constructs and syntax definition (bibliography references and urls)
Popkin System Architect has the most comprehensive model of the TOGAF methodology allowing visual navigation of all core domains and their constructs and relationships to other constructs and domains, such as: strategies, proposed initiatives, present IT portfolio, present systems and their use, users and vendors, all systems, their capabilities and use, and support for searching, view-generation, reporting, “what-if” analysis
See also http://www.software.org/pub/architecture/teaf.asp for the specifications of most EA methodologies. For TOGAF go to: http://www.software.org/pub/architecture/dodaf.asp
DA111-SotA-v1.0 PUBLIC Page 40
IP- Project ATHENA IP- Project - No ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number Document Deliverable D.A1.1.1 Date
Tutorials (public references)
Tutorials and other events are announced on their public web-site http://www.opengroup.org/boston2004/iqm-workshop.htm
Supporting tools Most all leading Enterprise Architecture vendors are supporting TOGAF, such as Metis from Computas, System Architect from Popkin, Mega, and the other top ten providers. Analysis for Enterprise Interoperability TOGAF is along with DoDAF one of the most comprehensive enterprise frameworks and gives us a good understanding of the stakeholders and users an the minimum of informations they must receive to align business and IT and get value out of their business and IT initiatives. The Open Group is now cooperating with OMG to investigate synergies by integrating the OODA, SOAD approaches and the ADM methodology.
6.1.8 The TEAF Methodology from the US Dept. of Commerce TEAF is derived from an earlier Treasury model, (1997), and the (1999). Additional direction was provided by the, also known as the Clinger-Cohen Act of 1996, and the GPRA of 1993.
Summary As stated in TEAF Version 1.0, July 2000, the purpose of this architecture framework is to: · Provide guidance for Treasury Enterprise Architecture development and management · Support Treasury Bureaus and offices with the implementation of their architectures based on strategic planning · Show the benefits of incorporating enterprise architecture disciplines and tools into normal business operations · Provide a structure for producing an EA and managing EA assets The TEAF is to guide the planning and development of enterprise architectures in all bureaus and offices of the Treasury Department. There are more than 300 agencies and bureaus around the US. The responsibility for ensuring this action falls on the office of the Treasury CIO. Authority US Dept. of Commerce, Washington DC. http://www.treas.gov/offices/management/cio/teaf/arch_framework.doc General references (Public) The US Government public web-site is a good general reference: http://www.gcn.com/enterprise-architecture/ For general information on EA in the US market follow information exchange and events on: http://www.eacommunity.com/board.asp and Go to http://www.geao.org/ for ongoing government architecture work. Another good source for architecture spproaches and methodologies adapted to market segments is found at: http://www.enterprise-architecture.info/index.htm
Constructs and syntax definition (bibliography references and urls)
A TEAF model developed in METIS Enterprise of the meta-model allow visual navigation of all core domains and their constructs and relationships to other constrcts and domains, such as: strategies, proposed initiatives, present IT portfolio, present systems and teheir use, users and vendors, all systems, their capabilities and use, and support for searching, view-generation, reporting, “what-if” analysis See also http://www.software.org/pub/architecture/teaf.asp for the specifications of most EA methodologies. For TEAF descriptions go to:
Supporting tools
DA111-SotA-v1.0 PUBLIC Page 41
IP- Project ATHENA IP- Project - No ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number Document Deliverable D.A1.1.1 Date
Four of the leading Enterprise Architecture vendors are supporting TEAF, such as Metis Enterprise from Computas, and the three other top ten providers.
Analysis for Enterprise Interoperability TEAF is another of the most comprehensive enterprise frameworks and gives us a good understanding of the stakeholders and users and the minimum of information they must receive to align business and IT and get value out of their business and IT initiatives. However, as all the others it contributes little to integrated platforms, model-driven design and generation of interoperable solutions.
6.1.9 The AKM Technology from Computas
The AKM technology and corresponding methodology is based on the concepts of Enterprise Knowledge Spaces, and its four knowledge dimensions. The AKM methodology is comparable to the four knowledge dimensions that both coordinate human action and human thinking. The AKM technology implements the methodology and just like the conceptual knowledge it has a solution space of four knowledge dimensions, we call them Approach – Methodology - Infrastructure and Solutions – AMIS. This has led us to define the AMIS principle for innovative work. It is still being developed and it is hoped that Athena will contribute towards bringing its implementation a major step forward. Summary The development of the AKM technology started in 1989 focussed on product and process design and the Innovative Enterprise Knowledge Space with the POPS knowledge dimensions. Then there was a period from 1994 when focus turned more towards the current methodology for EA, and from 1998 the work was intensified. From 2000 Computas invested heavily in the AKM methodology and technology.
Information Knowledge Models Models AKM’s
STATIC DYNAMIC Passive Responsive
Pictures + Diagrams + Schemata + Algebraic + Dynamic + Value- typing driven Rules/ Concepts Data Information Knowledge Work methods
Figure 13: Classification of Enterprise Model by expressiveness and richness of knowledge.
Computas is today considered the leading provider of Enterprise Architecture, and has around 8000 installations in the US and Europe. Computas is looking to consolidate its position in the EA market and also to revitalise the Enterprise Design and Development market, where EA will become operational architectures to support holistic solutions design and development, whether the solutions is a new approach, methodology, platform, product, organisation, process or system.
Authority Computas AS, Vollsveien 9, 1327 Lysaker, Norway, Got to www.computas.com, or www2.metis.no or www.akmii.net
DA111-SotA-v1.0 PUBLIC Page 42
IP- Project ATHENA IP- Project - No ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number Document Deliverable D.A1.1.1 Date
General references (Public) The official website for see www.computas.com and www.akmii.net Computas position in the EA market is best assessed from these web-sites: http://gcn.com/21_27/mgmt_edition/19835-1.html http://www.eacommunity.com/board.asp http://www.enterprise-architecture.info/EA_Tools.htm http://www.geao.org/
The AKM technology is best described in a dozen papers that are published on the R&D portal at www.akmii.net
Constructs and syntax definition (bibliography references and urls) The AKM technology has modelling languages for a wide variety of enterprise processes and application areas. The strength of the Metis tool set is that they share a common meta-meta model expressing how all structures, flows, views and other elements are the basis for all descriptive and meta-models and all operational models and solutions. See chapter 5.3 for details on the different pre-packed templates but with Metis you can develop your own meta- models.
Node| Company Department C Department B Leaf Department A Folder
Analyze Car Design Develop Powerline . Engine Body
Figure 14: The four main knowledge dimensions of the Innovative Enterprise Knowledge Space. The dependencies between views in these dimensions in design and engineering are complex and must be expressed by scripts and performed as modelling services.
Tutorials (public references) Got o www.computas.com, or www2.metis.no or www.akmii.net Supporting tools The AKM technology is so far mostly implemented by the Metis Enterprise tool set. Metis is today able to import, visualise and continue modelling on models imported from many of its competitors in EA and BPM. Metis client tools are supported by the Metis Team Server, a very powerful knowledge repository.
DA111-SotA-v1.0 PUBLIC Page 43
IP- Project ATHENA IP- Project - No ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number Document Deliverable D.A1.1.1 Date
Analysis for Enterprise Interoperability The AKM technology implements the layered Enterprise Architecture, is prepared for the POPS and POP* methodology, for the Enterprise Knowledge Architecture and the Intelligent Infrastructure services. Many of the right design principles and implementation architectures are defined in the AKM technology.
6.1.10 ISO 15745 - Framework for Application Integration Short description ISO 15745 – Open System Application Integration Framework is elaborated by ISO TC184 SC5/WG5. It consists of four parts: Part 1: Generic reference description; Part 2: Reference description for ISO 11898 based control systems; Part 3: Reference description for EN 50170 and EN 50254 based control systems; and Part 4: Reference description for Ethernet based control systems The application integration framework (AIF) defines elements and rules that facilitate: - the systematic organisation and representation of the application integration requirements using integration models; - the development of interface specifications in the form of application interoperability profiles (AIPs) that enable both the selection of suitable resources and the documentation of the "as built" application. ISO 15745-3:2003 defines the technology specific elements and rules for describing both communication network profiles and the communication related aspects of device profiles specific to IEC 61158-based control systems. In particular, ISO 15745-3:2003 describes technology specific profile templates for the device profile and the communication network profile. Profiles for ISO/IEC 8802-3-based control systems are outside the scope of ISO 15745- 3:2003. ISO 15745-3:2003 is to be used in conjunction with ISO 15745-1:2003 to describe an application integration framework. Generic elements and rules for describing integration models and application interoperability profiles, together with their component profiles (process profiles, information exchange profiles, and resource profiles) are specified in ISO 15745-1:2003. Figure 15 below gives an overview of ISO 15745 content and relationships between various parts of the standard.
Figure 15: ISO 15745 Content (ISO 15745-1, 2002)
DA111-SotA-v1.0 PUBLIC Page 44
IP- Project ATHENA IP- Project - No ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number Document Deliverable D.A1.1.1 Date
Type of Integration Integrated approach Description To achieve application interoperability, a key condition to be satisfied is that interfaces of the resources used to perform the function are configured to work with the corresponding resource interfaces of the other functions involved in a target manufacturing applications (DelaHostria, 2003). The three basic integration models are defined as shown in Figure 16: process integration model, resource integration model and information exchange integration model. The AIF (Application Integration framework) focuses on the integration aspects of an application system, and provides elements and rules for the development of integration models and profiles based on the process, information exchange, and resource views of the application (also see Figure 16). Integration models represent the application requirements, and profiles are interface specifications that enable both the selection of suitable resources and the documentation of the "as built" application. Integration models are in the form of UML diagrams while profiles are XML documents (ISO 15745-1, 2002).
Figure 16: Profile development using ISO 15745
More specifically, scheme for describing an integrated view of an industrial application · Based on a set of visualisation elements & composition rules · Elements include reusable, object-based representations of an application’s processes, resources, and information exchanges. · Rules include relationship, interaction, and deployment diagrams to capture the roles of the elements throughout an application’s life cycle.
DA111-SotA-v1.0 PUBLIC Page 45
IP- Project ATHENA IP- Project - No ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number Document Deliverable D.A1.1.1 Date
· Integration models expressed in UML (Unified Modeling Language -ISO/IEC 19501) diagrams which provide extensible methods for integration of new functionality Scheme for creating a concise statement of an application’s interoperability requirements · Identifies and organises the elements’ service interfaces as interoperability profiles · Standardises an extensible method to describe a profile and exchange it among the stakeholders of an application
· Interoperability profiles are denoted in XML (eXtensibleMarkup Language). Industrial Use There is no complete industrial implementation reported so far. However, some industries actively participate in the work, for example: Rockwell Automation (US and France), Fuji Electric, Hitachi and Mitsubishi Electric (Japan), Siemens (Germany), Alstom (France), etc. Strength · The standard allows to deal with interoperability of applications early in the stages of system requirements and design and through the lifecycle by using the Application Integration Framework. · Clear definition of manufacturing (enterprise) application as a set of processes, resources and information exchanges. · The desired or as-built interface configurations can be described in a set of XML files using the XML schemas defined in the standard. Weakness · This approach can work only if various standards used to specify interfaces are interoperable between them.
6.1.11 MISSION approach Short description Global enterprises have to face new ways of distributed work. Within this huge field, this approach focuses on distributed, decentralised simulation and, furthermore, on the supply chain process. The global concept based on the results of the European MISSION Module [1] and on an extension of the Enterprise Modelling tool MO²GO. The approach includes the modelling aspects which describe how a user can collect the necessary data for the distributed simulation. Furthermore, it describes how the different simulation models can be connected: starting from a template library, via an enterprise model to the automatic generation of the required interface files. A brief description of a framework for distributed enterprise simulation including configuration will be presented. The approach extends the High Level Architecture (HLA) [4,5] approach to support the industrial use of distributed simulation. This can be seen as an application-specific enrichment of the HLA standard. A simulation manager (realised as extension of MO²GO) supports the definition and the interoperability of simulation templates by exchanging objects [6]. It delivers an easy graphical way for the design of simulation scenarios by process chains and building blocks. The simulation manager secures the consistency between the federate configuration files (FCF) for a distributed simulation scenario by the generation of all FCFs for the federates and the Federate Execution Definition (FED) file for the HLA RTI, automatically.
Type of Integration Federated approach Integrated approach Modelling of distributed scenarios Supply chain network simulation and monitoring
DA111-SotA-v1.0 PUBLIC Page 46
IP- Project ATHENA IP- Project - No ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number Document Deliverable D.A1.1.1 Date
Description Actually, distributed simulation between different simulation tools (e.g. Arena, Enterprise Dynamics, eMPlant) as well as including different software components (MS Excel, 3D Visualisation, etc.) into such simulation process is still a new technology. Despite the existence or development of proprietary solutions for individual simulators (e.g. AutoMod, eMPlant, Enterprise Dynamics, etc.) a standard “plug an play” mechanism is still missing. However, big companies invest in digital enterprise concepts and within the next few years they will force their suppliers to be integrated in these concepts. That will also require new concepts of distributed, decentralised but synchronised analysis and simulation methodologies and platforms. Years ago the situation at US Department of Defence (DoD) was similar to this situation of modelling and simulation. Many simulation models already existed. The necessary effort for the developing of new simulation models increased. At the same time the available amount of money for the development decreased. So, it became more and more important to use or to reuse existing systems and existing information in a distributed decentralised environment. Moreover, the possibility to substitute systems within a runtime environment (for example to substitute an old jet fighter by its new version in different scenarios) were required. The DoD initiated a research program to develop an architecture for distributed simulation. One result of thus approach is the high level architecture (HLA) and its runtime infrastructure (RTI). Until 2002 the DoD provided a free version of this RTI to support the distribution of that technology. Now some vendors of RTIs are available. HLA becomes an IEEE and OMG standard. Beside of web based approaches the HLA is still the state of the art in distributed simulation. The HLA satisfies many requirements for distributed simulations e.g. time synchronisation, communication between independent simulation models etc. Within military applications of the HLA, for each new model a new simulator will be programmed, usually. Therefore, a flexible interface for simulation models is not required for military applications. This is completely different within civil domains where the total effort spent on one simulation study is extremely low in comparison with defence applications. The dependency of the interface description to the HLA-RTI from the specific simulation model is a critical disadvantage for regular civil applications of HLA. Based on the HLA approach different groups are founded to extend the technology and to bring the distributed simulation into the civi l domain. Examples are the Extensible Modelling and Simulation Framework (XMSF) and The High Level Architecture - COTS Simulation Package Interoperation Forum (HLA-CSPIF). The Simulation Interoperability Standards Organisation's (SISO) is also interested in such a standard. The XMSF group works on a new generation of web-based modelling and simulation e.g. using XML and web-services. HLA-CSPIF established a international group to support the interoperation of discrete event models created in commercial-off-the-shelf simulation packages by HLA.
Needs for distributed simulation comparing to achievements: – Reusability: available simulation models are implemented in different tools (off-the- shelf simulation packages) and have to be re-modelled in a single tool before they can form an executable model – Selection of Information: need to hide internals of simulation models, especially when simulation is executed cross-enterprise or organisational, e.g. for supply chains. – Simulation for SMEs: for SMEs quite often it is too expensive to support the different tools of their customers within the supply chain, especially if for each tool a special training or consulting is necessary – Modular Structures: call for efficient maintenance of very large simulation models – Flexible Test Environment: specific components, like shop floor control, have to be modelled within the simulation system again or with high effort linked to the specific simulation model and tool
The framework proposed here illustrates an approach for the use of HLA in the civil, industrial domain. The starting point for this framework was the European Module of the IMS MISSION project (EP 29 656). It based on a configuration mechanism on the top of HLA which allows a user oriented configuration of decentralised, distributed simulation by enterprise models. A template library allows the definition of different application templates. Concerning the simulation process each application template refers to simulation models. The simulation model implements the content of the application template. Each model has to be able to execute this partial simulation process standalone. Further, the notation "application template" will be used
DA111-SotA-v1.0 PUBLIC Page 47
IP- Project ATHENA IP- Project - No ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number Document Deliverable D.A1.1.1 Date
for templates which are directly applicable within a simulation scenario, in opposite to templates supporting a clear search structure within the template library. Furthermore, the definition of input and output segments of the simulation models as well as of the exchange objects between the simulation models is necessary. E.g. an output segment of a processing line could be the output buffer. Within a simulation scenario this output segment will be associated with an input segment of another simulation model, e.g. a transportation system. The data exchange is done by objects. These objects are called Exchange Objects within the framework. They have to be described for each application template. Exchanged objects are those objects which are necessary to define a communication between simulation models. They are not directly sent to a receivi ng federate. They just get a mark which indicates the receiver. A possible receiver checks the mark and identifies if the object has its address. Afterwards the object will be processed by the receiver. The application templates are used within an enterprise process model as operational resources. The graphical process model defines the general order of the different processes within a distributed simulation scenario. Each process is related to an instance of an application template. During the instantiation a setting of parameters provided by the template is possible. Based on the process model a building block structure is generated. Each operational resource represented in the process model is included as a building block within the building block structure. A building block has input and output segments related to the used application template. So it is possible to define the connection between the segments of the different building blocks. The connection includes the definition of the used exchange object classes.
Enterprise Model
Application Template Instantiation
Template Building Blocks Library
Exchange Objects Simulation Segments
FCF FCFFCF
Off-the-Shelf Tool + Model Simulation Package Including one Simulation Package Configurable Simulation Model Dependent Interface Interface but Model Independent Simulation Package and Generic Adapter Model Independent Configurable HLA - RTI Communication Platform e.g. HLA RTI Figure 17: Framework for a Distributed Federated Simulation
After this step the distributed, decentralised simulation scenario is designed. Within the simulation scenario each building block will be a federate. A federate is a running simulation model in a group of running simulation models (federation) connected to other simulation models of the group via HLA-RTI[16]. The HLA-RTI is configured by a federation execution definition file (FED-File). This file includes general information of object classes and attributes managed by the HLA-RTI. As extension the presented framework includes the definition of a configuration file for each federate: The Federate Configuration File (FCF) includes information of object classes and attributes used by the federate as well as information about connections with other federates. Each used off-the-shelf simulation package requires an interface to the generic HLA adapter.
DA111-SotA-v1.0 PUBLIC Page 48
IP- Project ATHENA IP- Project - No ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number Document Deliverable D.A1.1.1 Date
This inter-face has to be configurable by the FCF. The generic adapter is used to simplify the connection to the RTI and to hide proprietary features of the RTI implementation.
Supply Chain Case Study The MISSION methods and software have been applied within a demonstration scenario, the “MISSION Enterprise”. This enterprise is world-wide distributed. It has a main assembly facility in which electric motors are assembled. The necessary components –housing, rotor, stator, control cards and bearings- are supplied by specialised Manufacturing Shops, placed in different countries. Especially the realistic representation of the order flow was within the focus. Research conducted at the U.S. National Institute of Standards and Technology (NIST) in the framework of the IMS MISSION project (Lee and Umeda 2001) has been used for the Exchange Objects representing the order flow in this demonstrator. The Assembly Factory controls the production of the manufacturing shops depending on retailer demands. Therefore, any problem in any of the manufacturing shops could affect single parts delivery times. The manufacturing shops produce components depending on the received orders on behalf of the downstream customer (Assembly and Warehouse). After completing the production, the manufacturing shop ships the components to the assembly and warehouse simulation model. Depending on orders from the trading simulation within the OEM model the Assembly and Ware-house produces finished goods and sends them back to the OEM model. In order to fulfil this task it generates orders for buying components from the manufacturing shops. The internal component- and processing-list of the simulation scenario supports different (component-) product types from different suppliers. These components can be assembled in various variants. Additionally, the assembly and warehouse model simulates a transportation network and a ware-house. The model supports two different distribution paths: (1) direct distribution (the end products are sent directly to the customer) and (2) distribution via the warehouse. The selection of the distribution path was modelled depending on the final products. The OEM simulation contains different modules, too. One module simulates a distributor, another one the retailer and the third and fourth modules simulate the transportation. The retailer model contains a customer simulation which orders products. It sells the ordered products and sends them from his internal storage to the customer. Depending on the storage level the retailer creates orders for the distributor or for Assembly and Warehouse. The upstream supplier (and receiver of the order) depends on the distribution path. The distributor operates applying the same principles.
DA111-SotA-v1.0 PUBLIC Page 49
IP- Project ATHENA IP- Project - No ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number Document Deliverable D.A1.1.1 Date
Figure 18 : Monitoring Model
The statistical monitoring (Figure 18) is an additional module within the demonstrator. This module does not simulate anything. It collects and calculates statistical data generated by the other modules. For this purpose it uses the statistical attributes of the Exchange Object “MISSION_product” (Total_cycle_time, Total_processing_time, Total_waiting_time, Total_transport_time) on the one hand. The statistical monitoring collects and counts all incoming product entities and calculates the minimal, maximal and average values of the statistical attributes. On the other hand simulation models can be sent as user defined “MISSION_statistical_data” Exchange Objects to the statistical monitoring federate.
Figure 19 illustrates the connection of simulation tools within the distributed federated simulation scenario.
Enterprise 1 Enterprise 2 Simulation Simulation Different Tool A Tool B Off-the-Shelf runs Model X runs Model Y Simulation Tool
Interface of FCF Interface of FCF Tool A Model X Tool B Model Y
FED Generic Adapter Generic Adapter File
HLA – RTI (Synchronisation and DataTransfer)
Figure 19 : Runtime Architecture
Links · MISSION; 01.11.2003: http://www.ims-mission.de/. · Kuhl, F.; Weatherly, R.; Dahmann, J.: Creating Computer Simulation Systems. An Introduction to the High Level Architecture, Prentice-Hall, 1999. · IEEE 1516-2000 Standard for Modeling and Simulation (M&S) High Level Architecture (HLA). · Mertins, K.; Rabe, M.; Jäkel, F.-W.: Neutral Template Libraries for Efficient Distributed
DA111-SotA-v1.0 PUBLIC Page 50
IP- Project ATHENA IP- Project - No ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number Document Deliverable D.A1.1.1 Date
Simulation within a Manufacturing System Engineering Platform. In: Winter Simulation Confer-ence, Orlando (USA) 2000, pp. 1549-1557 · IEEE P1516.1[D5. Standard for Modeling and Simulation (M&S) High Level Architecture (HLA) - Federate Interface Specification, 2000. · Rabe, M.; Jäkel, F.-W.: Simulation for Globally Distributed Enterprises. In: 12th European Simulation Symposium (ESS), Hamburg 2000, pp. 322-327. · Straßburger, S.; Schulze, T.; Klein, U.: Internet-based simulation using off-the-shelf simulation tools and HLA. In: Medeiros, D. J.; Watson, E. F.; Carson, J. S.; Manivannan, M. S. (Eds.): Winter Simulation Conference, Washington 1998, Vol. 2, pp. 1669-1676. · Schumann, M.; Blümel, E.; Schulze, T.; Straßburger, S.; Ritter, K.-C.: Using HLA for Factory Simulation. Simulation Interoperability Workshop, Orlando, 1998, Paper code 98F- SIW-060 (electronic distribution). · XMSF 01.11.2003: http://www.movesinstitute.org/xmsf/xmsf.html · HLA-CSPIF 01.11.2003: http://www.brunel.ac.uk/~csstsjt/HLA CSPIF/index.html. · SISO 01.11.2003: http://www.sisostds.org/. · Straßburger, S.; Hamm, A.; Schmidgall, G.; Haasis, S.: Using HLA Ownership Management in Distributed Material Flow Simulations. Euro-pean Simulation Interoperability Workshop, London 2002, Paper code 02E-SIW-026 (elec-tronic distribution) · Jäkel, F.-W.; Arroyo Pinedo, J.S.: Development of a Demonstrator for Modelling and Simulation of Global Distributed Enterprises. In: Mertins, K.; Rabe, M. (Eds.): The New Simulation in Produc-tion and Logistics. 9th ASIM Dedictaed Confer-ence on Simulation in Production and Logistics, Berlin 2000, pp. 375-384. · Klein, U.: Simulation-based distributed system: serving multiple purpose through composition of components. Safety Science 35 (2000) 1-3, pp. 29-39. Industrial Use The use of technologies like the distributed supply chain simulation is still not popular enough. Nevertheless, the large enterprises are interested in expanding their own approaches in the field of "Digital Factory" to their suppliers and the entire delivery chain. This can already be seen in the growing pressure on the suppliers to increase transparency of their processes and to supply planning data. Therefore it is of high importance to be invested in these new technologies and standards, before the international competition imposes its own rules from outside. Moreover, it becomes more and more necessary to do simulation of supply chains including models from different suppliers. Therefore, first requests are sent by industrial partners. Strength All in all, the proposed framework consists of the following main parts: – Template Library – Exchange Objects – Enterprise Model – Building Block Structure – Simulation Model Segments (Input, Output, Monitoring, etc.) – Simulation Manager approach, – Federate Configuration File (FCF) mechanism (XML is used to describe the exchange) – Configurable Interfaces to software tools (e.g. Arena, Enterprise, Dynamics) – Generic Adapter for the HLA RTI – configurable communication Platform (e.g. HLA RTI).
It includes the following main benefits: – Scalable architecture and models for the interoperation of different simulation models (e.g. for supply chain simulation) – Configuration of the data exchange between different simulation model – Integration of different independent off-the-shelf simulation packages within one simulation scenario – Possibility to participate with the same model in different scenarios – Framework including approaches for a flexible configuration of distributed simulation scenarios as well as a supply chain scenario – Clear and structured teamwork - single parts can be developed, tested and maintained separately. – Approach to connect different tools for a distributed simulation (e.g. Enterprise Dynamics
DA111-SotA-v1.0 PUBLIC Page 51
IP- Project ATHENA IP- Project - No ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number Document Deliverable D.A1.1.1 Date
(former Taylor), ARENA, Visualisation Tools, etc.) No need to agree on common simulation tools – Interface description between enterprise models within a supply chain simulation – Template mechanism for reusing simulation models and possibility for IPR protection - only the template has to be published – Protection of the internal knowledge of business processes of the involved enterprises by using clearly defined interfaces and independent simulation models, – Easy reusability of the models as well as the parallel modelling and model maintenance, due to the modular construction of the model scenarios, – Ability of interchange between simulation models and real world systems (e.g. control systems, ERP systems), – Extensible and user definable Template Library which allows the design of reusable templates for distributed scenarios, – Flexible representation of results and animations, – Possibility for the connection of mobile devices (presentation of results), – Opportunity to create a flexible test environment (system in the loop), – Possibility to design an adaptable training environment (man in the loop), – Support of the development of simulation scenarios and the automatic generation of an XML description for the data interchange of the complete scenario. Weakness Missing standardisation is the main limitation of the approach. Standards are needed for: · Exchange Object Structure: Description of the objects exchanged within a distributed environment (potential base: ebXML) · Federate Configuration File format: Reduces reprogramming effort for simulation tool interfaces in an HLA RTI environment. Different approaches have to be synchronised in this field. · Simulation Parameters: The MISSION approach identifies missing harmonisation in the definition of simulation parameters. · Ownership Mechanism: Incompatible approaches to adapt the HLA ownership mechanism for industrial usage. Generic Adapters: Interfaces to adapters should be standardised in order to reduce the investment for distributed simulation environments.
6.2 Industry Initiatives, Standardisation Bodies and Organisations working on EM Concepts The state-of-the-art is concerned with main approaches relevant to ATHENA A1 project. This version covers: BPMI, WfMC, OAGIS GIS, OASIS BPEL, OASIS BCM, UN/CEFACT BCF, Biztalk, Rossetta Net, W3C, and OMG which are considered as industrial initiatives or not-for-profit organisations working on De facto standards. This section also reviews some European and international standards relevant to enterprise interoperability such as: EN/ISO 19439: Framework for enterprise modelling, EN/ISO 19400: Constructs for enterprise modelling, CEN TS 14818: Decisional reference model, ISO CD 18629: PSL, ISO 15704: Requirements for enterprise architectures and methodologies, ISO 14258: Concepts and Rules for Enterprise Models, ISO/IEC 15414: Open Distributed Processing – Reference Model – Enterprise Language (e.g. for RM-ODP Enterprise language). This list is not exhaustive and other potential standards might be added during the A1 project whenever necessary.
6.2.1 BPMI Summary Motivation and objective The Business Process Management Initiative (BPMI.org) is an independent organisation devoted to the development of open specifications for the management of e-Business processes that span multiple applications, corporate departments, and business partners, behind the firewall and over the Internet. BPMI.org complements initiatives such as J2EE and SOAP that enable the convergence of legacy infrastructures toward process-oriented enterprise computing and initiatives such as ebXML, RosettaNet,
DA111-SotA-v1.0 PUBLIC Page 52
IP- Project ATHENA IP- Project - No ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number Document Deliverable D.A1.1.1 Date
BizTalk, WSDL, UDDI, tpaML and E-Speak that support process oriented business-to-business collaboration. BPMI.org defines open specifications such as the Business Process Modelling Language (BPML) and the Business Process Query Language (BPQL)that will enable the standards-based management of e-Business processes with forthcoming Business Process Management Systems (BPMS), in much the same way SQL enabled the standards-based management of business data with off-the-shelf Database Management Systems DBMS). BPMI.org has been initiated by Intalio, Inc. and created in August 2000 by a group of sixteen enterprise software vendors and consulting firms. Membership is open to all companies, non- profit organisations and individuals. BPML The Business Process Modelling Language (BPML) is a meta- language for the modelling of business processes, just as XML is a meta-language for the modelling of business data. BPML provides an abstracted execution model for collaborative transactional business processes based on the concept of a transactional finite-state machine. BPML considers e- Business processes as made of a common public interface and as many private implementations as process participants. This enables the public interface of BPML processes to be described as ebXML business processes or RosettaNet Partner Interface Processes, independently of their private implementations. In much the same way XML documents are usually described in a specific XML Schema layered on top of the eXtensible Markup Language, BPML processes can be described in a specific business process modelling language layered on top of the extensible BPML XML Schema. BPML represents business processes as the interleaving of control flow, data flow, and event flow, while adding orthogonal design capabilities for business rules, security roles, and transaction contexts. Defined as a medium for the convergence of existing applications toward process-oriented enterprise computing, BPML offers explicit support for synchronous and asynchronous distributed transactions, and therefore can be used as an execution model for embedding existing applications within e- Business processes as process components. BPQL The Business Process Query Language (BPQL) is a management interface to a business process management infrastructure that includes a process execution facility (Process Server) and a process deployment facility (Process Repository). The BPQL interface to a Process Server enables business analysts to query the state and control the execution of process instances managed by the Process Server. This interface is based on the Simple Object Access Protocol (SOAP). The BPQL interface to a Process Repository enables business analysts to manage the deployment of process models managed by the Process Repository. This interface is based on the Distributed Authoring and Versioning Protocol (WebDAV). Process models managed by the Process Repository through the BPQL interface can be exposed as UDDI services for process registration, advertising, and discovery purposes. Modelling Language Constructs The modelling elements of BPMI have been compared with the modelling language constructs of ENV 12204 by K. Kosanke. A detailed interpretation and discussion of the comparison results still needs to be done. One apparent difficulty in the interpretation could be that BPML does not strictly separate user oriented and IT oriented elements (IT services), whereas ENV 12204 is concerned with user oriented modelling language constructs only. Work Status The BPMI initiative has rapidly grown and is representing an impressive portion of the IT industry. The next specification version, the ’BPML Schema’ 1.0, following Version 0.4 (presently available in the Internet [26]) was planned for release to the public in January, 2001. Authority BPMI.org Contact Information 1155 S. Havana Street, #11-311 Aurora, CO 80012 USA Tel: 303-364-8595 Fax: 303-341-7014 Questions about becoming a member? Email: [email protected] General references (Public) http://www.bpmi.org/ Analysis for Enterprise Interoperability
DA111-SotA-v1.0 PUBLIC Page 53
IP- Project ATHENA IP- Project - No ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number Document Deliverable D.A1.1.1 Date
BPMI could make it possible to find the specifications of the platform to the wp A1.4.
6.2.2 WfMC Summary: Background WfMC was founded in 1993, to develop & promote workflow integration capability. It’s a non profit-making, open to all. There are working arrangements with AIIM, OMG and IETF. The current membership is c. 220. Scope: A Workflow can be defined by three definitions: - The automation of a business process, in whole or part. - Information or tasks are passed from one participant to another for action, according to a set of procedural rules. - A number of logical steps, each of which is known as an activity. We can see the workflow overview on the Figure 20.
Process Business Process Analysis, Designer Modelling & Definition Tools Process Design & Definition
Process Definition Process change Administrator / Supervisor Workflow Management System
Distributed Infrastructure Environment
Work Application Presentation Launch
User Application & IT Tools s s
Figure 20 - Workflow overview A Workflow Management System is a system that completely defines, manages and executes “workflows” through the execution of software whose order of execution is driven by a computer representation of the workflow logic. Three functional areas are supported by WfM: - The Build-time functions, concerned with defining, and possibly modelling, the workflow process and its constituent activities - The Run-time control functions concerned with managing the workflow processes in an operational environment and sequencing the various activities to be handled as part of each process - The Run-time interactions with human users and IT application tools for processing the various activity steps Many Workflow Product exist such as: FlowMark (IBM), Lotus Notes (IBM/Lotus), Ad hoc, WorkMAN (reach software).
DA111-SotA-v1.0 PUBLIC Page 54
IP- Project ATHENA IP- Project - No ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number Document Deliverable D.A1.1.1 Date
Figure 21 - Workflow reference model Figure 21 represents the workflow reference model. The different elements are describe below. Workflow API - Workflow Application Programming Interface - The interface around the workflow enactment - A service interface which is to support workflow management functions across the 5 functional areas. Workflow Enactment Services - A software service - Consist of one or more workflow engines in order to create, manage and execute workflow instances. - Applications may interface to this service via the WAPI. Workflow Engine - A workflow enactment service consists of multiple workflow engines. - A software service or "engine" - Execution environment for a workflow instance - Responsible for part or the entire runtime control environment within an enactment service. Process and Activity State Transitions - The workflow enactment service may be considered as a state transition machine, - Individual process or activity instances change states in response to external events(e.g., completion of an activity) - Specific control decisions taken by a workflow engine(e.g., navigation to the next activity step within a process) Authority · WfMC (Workflow Management Coalition)
DA111-SotA-v1.0 PUBLIC Page 55
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
General Manager Layna Fischer Secretariat Future Strategies Inc (WfMC Services) 2436 N. Federal Highway #374 Lighthouse Point FL 33064 USA Tel: +1 954 782 3376 Fax: +1 954 782 6365 Email: [email protected] WWW: http://www.wfmc.org/
General references (Public) http://www.wfmc.org Analysis for Enterprise Interoperability How this approach supports Enterprise Interoperability?
A2 A1 A5
A3 A4 B B 2 1 B 3 B 4 C C C C 1 2 3 4 WAP Initiate I Sub- Workflow Enactment process WAP I Service WAP #1 Retur Workflow Enactment I n Service #2 Workflow Enactment Service #3
Figure 22 - Sub-Process Interoperability Model
DA111-SotA-v1.0 PUBLIC Page 56
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
Synch point across
A A A processesA 1 2 3 4
B B B B 1 2 3 4
C C C C 1 2 3 4
• To support inter-process dependencies • Uses Synch Event and optional Confirm
WAPI WAPI Sync. Event Workflow Enactment Service Workflow Enactment Service #1 #2 optional Confirm
Figure 23 - Parallel Synchronised Interoperability Model Interoperability Protocol & Bindings: - MIME (Email) (1995) - IDL / CORBA (1998) - XML (April 2000)
Interoperability Testing - Facility established at University of Muenster - First stage (MIME) - 3 vendors completed - Second stage (MIME) - 8 vendors committed - Wf-XML testing - Q3
6.2.3 OAGIS GIS Summary:
The current scope of OAGIS content: (Figure 24) • E-Commerce - e-Catalog - Price Lists - RFQ and Quote - Order Management - Purchasing - Invoice • Manufacturing - Plant Data Collection - Engineering - Warehouse Management - Enterprise Asset Mgmt.
DA111-SotA-v1.0 PUBLIC Page 57
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
• Logistics - Shipments • CRM - Customer - Sales Force Automation • ERP - Financials - Human Resources - Manufacturing - Credit Management
Value Chain Collaboration Applications
Enterprise Management Applications
Enterprise Execution Application s
Figure 24 - OAGIS Content
Authority Open Applications Group: Open Applications Group, Inc. PO Box 4897 Marietta, Georgia 30061 Phone: +1 770 943 8364 General references (Public) http://www.openapplications.org Framework definition (bibliography references and urls) The Open Applications Group Development Methodology has four phases (see figure 8): 1- Definition 2- Construction 3- Review and Approval 4- Publication
Figure 25: Development methodology
DA111-SotA-v1.0 PUBLIC Page 58
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
Process flow: The best way to visualise the entire process for building specifications and XML message is to review the diagram below (Figure 25 & Figure 26). This process will be described in more detail and each phase will be described with activities and deliverables.
Figure 26 - The process flow
6.2.4 OASIS BPEL Summary BPEL (Business Process Execution Language) for Web services is an XML-based language designed to enable task-sharing for a distributed computing or grid computing environment - even across multiple organisations - using a combination of Web services. Written by developers from BEA Systems, IBM, and Microsoft, BPEL combines and replaces IBM's Web Services Flow Language (WSFL) and Microsoft's XLANG specification. (BPEL is also sometimes identified as BPELWS or BPEL4WS.) Authority TC Chairs: Mrs. Diane Jordan (IBM) and John Evdemon (Microsoft). General references (Public) http://xml.coverpages.org/wsbpel20031204.pdf http://xml.coverpages.org/BPELv11-May052003Final.pdf Tutorials (public references) BPEL learning guide: http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci880731,00.html#t ools
DA111-SotA-v1.0 PUBLIC Page 59
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
6.2.5 OASIS BCM Summary The BCM can be viewed as three distinct steps that together provide the cycle that enables business users to formalise their needs and then deploy these into operational environments. The BCM enables this in such a way that they can manage the operational rules as well as the design of their processes and information exchanges. The three major parts to the BCM:
1. BCM Layers – (Figure 27) Formalizing the business needs into BCM Layers and supporting BCM Templates and other optional models. The first step in this process is the understanding of the use of BCM Layers to qualify aspects of the business solution. Once the business user has understood the boundaries and the scope, they can then review their own needs and categorise them accordingly using the templates that the BCM provides and extending these to fit each unique situation. Defining common semantic concept definitions, mechanisms and align to Communities of Interest.
Implementation Layer Contract - 4 Collaboration Partner Specific Physical - Message & Constraints Presentation
Legacy Extension Layer
3 Frameworks
Publish Baseline Specification per & Standards CoI
Business Layer Business 2 Drivers: Model /
Target Constructs & Process / Patterns Constraints
Conceptual Layer Business Goals
1
Concepts in Authoritative Ontology Sources
Figure 27 - BCM Layer overview
2. BCM Information Pyramid – (Figure 28) The business analysts develop the semantic details of the Information Pyramid (aka Lubash Pyramid). This provides the roadmap to all the semantic mechanisms that describe the complete information process. This model provides the key foundation on which the actual software implementation is built.
DA111-SotA-v1.0 PUBLIC Page 60
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
44 Collaboration Agreements, MOA
55 Specific Ontology 1111 Business Processes Navigation
Transaction Handling 1010
66 Content Rendering
99 Codelist subsetting 8 7 8 Services; 7 Communities of Interests Transaction Processing - CoI Figure 28 - The Information Pyramid
3. BCM Operational – (Figure 31) Ensuring that the software mplementationi technology directly leverages those semantics through a consistent context driven information architecture. The BCM operations are driven by a ‘Contract’ metaphor between stakeholders that in turn vector BCM Templates. The constraints on those applications are that they must support the key ability to have dynamic context driven business mechanisms through the use of external templates and associated semantics.
Business Goals Goal Pattern counter reject Contract Agreement Pattern propose accept Contract driven driven -
Workflow request response - Modeling & Business Patterns process process
Transaction Specification CAMAssembly template Template
Model & Schemas Template SchemaSchema
Exchange Context
Concept Registry Verbs Roles Transport Nouns Rules Events
Figure 29 - Information Architecture Component
DA111-SotA-v1.0 PUBLIC Page 61
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
In Summary, the BCM Benefits are: · Enables collaborative development. Empowers users to be both customer and business expert · Gives traceability from business vision to implementation (and status) · Promotes unified understanding of assets to ensure visibility, accessibility and interoperability between trading partners, and facilitates greater reuse · Provides ability to discover efforts across the enterprise · Allows people and machines of multiple enterprises to exchange semantic interoperability knowledge · Provides structure for business patterns · Facilitates partner connectivity via industry models, such as, UBL, PIPs, OAGIS · Addresses the root cause rather than just the symptoms of integration problems · Provi des for Enterprise-wide agility We can see the complete BCM methodology on the Figure 30: Step 1 : Step 2 : Step 3 :
Use Layers to Define Build Templates with Deploy with Declarative Business Needs Familiar Business Tools Component Operations
Examples: Business Goals Implementation Layer Contract - Outliner Powerpoint Goal Pattern 4 Collaboration Graphics tool counter reject Partner Specific Pattern(s) HTML frames PhysicalPhysical -- MessageMessage & & Presentation Contract Constraints FinancialReporting Procedures propose accept Daily Procedures Period-End Procedures Agreement Pattern Prepare Journal Voucher Obtain AccountBalancesWorksheet for
SourceDocument Post
Post General Worksheet
Ledger
Work Order Journals,Ledgers PrepareTrial Community of Journal Voucher Balance ObtainClosingBalance Post Trial Trial Balance
PrepareJournalVoucher Contract Post Closing TB Workflow Interest Post GeneralLedger Journal Voucher AnalyzeBalances.Adjusting Account Prepare Entries
and AdjustedBalance Trial driven -
Journal Voucher Bar AdjustableTrial
PrepareFinancial FinancialStatements - Statements request response Legacy Prepare WorkflowWorkflow Post GeneralLedger Journal Voucher Entries andClosingPostGL to Collaboration J.V. File Journal Voucher Models Examples: Modeling & Graphics tool Business Patterns Extension Layer process process 3 CASE tool Frameworks Structure Tool Publish Baseline Specification per CoI Transactions Baseline Specification per CoI & Standards Classifications Artifacts TransactionTransaction Specification CAMAssembly template
Model & Schemas Template Wordprocessor Schema Examples: Word Vocabularies Exchange Context Tabulations Open Office Business Layer Business Drivers: Document tool 2 Collaboration Model / Process / Agreement (CPA) Concept Target Constructs & Patterns Constraints Examples: Registry Verbs Roles Target Constructs & Patterns Spreadsheet Documents Registry Transport Lotus Notes Nouns Rules HTML / Portals Events Groove Vocabularies Examples: Business Goals Events Rules Excel Conceptual Layer Lotus 1 HTML tables ConceptsConcepts inin OntologyOntology Authoritative Sources
While Referencing the Information Architecture
Figure 30 - The Foundation of BCM Authority OASIS (Organisation for the Advancement of Structured Information Standards) Business- Centric Methodology (BCM) Technical Committee. OASIS European Representative: OASIS C/O Sonnenglanz Bakkersweg 7 3951 CS Maarn The Netherlands +31 622502011 Voice +31 357727627 Fax General references (Public) § http://www.businesscentricmethodology.com/navigation/workspace.html
DA111-SotA-v1.0 PUBLIC Page 62
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
Supporting tools UBL, PIPs, OAGIS, …
6.2.6 UN/CEFACT BCF Summary: Background UN/CEFACT was established in 1996 in response to new technological developments, a desire to officially recognise the contributions made by the above-mentioned experts (many of whom come from outside the UN/ECE region), and the need to make better use of available resources. Scope The United Nations, through its Geneva based Centre for Trade Facilitation and Electronic Business (UN/CEFACT), supports activities dedicated to improving the ability of business, trade and administrative organisations, from developed, developing and transitional economies, to exchange products and relevant services effectively. Its principal focus is on facilitating international transactions through the simplification and harmonisation of processes, procedures and information flows, and so on contributing to the growth of global commerce. UN/CEFACT itself is open to participation from UN member states, intergovernmental organisations, and sectoral and industry associations recognised by the Economic and Social Council of the United Nations (ECOSOC). It actively encourages organisations to contribute and help develop its recommendations and standards. This includes participation through AFACT, the Asia Pacific Council for Trade Facilitation and Electronic Business, with membership from Australia, Chinese Taipei, India, Indonesia, Iran, Japan, Korea, Malaysia, Mongolia, PRC, Pakistan, Philippines, Singapore, Sri Lanka, Thailand, Vietnam, and the ebXML Asia Committee. UN/CEFACT's vision is to provide "simple, transparent and effective business processes for global commerce". At the centre of this vision (e-Business strategy) are three fundamental elements: • Cross industry and government sector analysis (to promote business level interoperability and synchronicity for all parties in the value chain); • Business process and information modelling (to formally describe business requirements in Business Collaboration Models); • Leverage existing and new technologies (e.g., extensible markup language (XML), Web Services, etc.). By combining these elements of the vision, UN/CEFACT developed the UN/CEFACT Business Collaboration Framework (BCF) to enable business process and information models to be specified in a technology and implementation neutral manner that can then be implemented in software using the information exchange syntax and structures of choice.
Business Collaboration Framework (BCF) The primary goal of the BCF is to systematically capture business and administrative process knowledge that will enable the development of low cost software components for use by small and medium size companies adopting e-Business practices. By first focusing on defining the business process and information models, the BCF itself is technology-neutral. However, it facilitates e-Business implementations based on the technology of choice, whether it is EDI (Electronic Data Interchange), XML (Extensible Markup Language) or some future information exchange technology. UN/CEFACT developed the BCF as a "top-down" as detailed in these four steps: Knowledge Transfer. Guided by the UN/CEFACT Modelling Methodology (UMM), a UMM knowledgeable Business Analyst facilitates a process where Business Domain Experts define the boundaries of their business problems, identify affected business processes, define their business objectives, describe the stakeholders, and the business constraints. UMM worksheets (a forms based modelling approach) are used to guide the business and administrative knowledge capture process; and also assemble other relevant business objective requirements.
DA111-SotA-v1.0 PUBLIC Page 63
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
Create the Business Model. Using information gathered in the Knowledge Transfer step above, Modelling Experts (with the help of UMM worksheets in software tools) create a complete Business Collaboration Model. The Model involves at least two trading partners, is UMM compliant, and is technology and implementation neutral. Whenever possible, Models (or fragments of Models) already developed are re-used and retained in specific BCF libraries (repositories such as Business Process Library). During Business Model creation, existing Business Semantics can be applied. A Common Business Process Catalog stores non-UMM models that may serve as a framework for generating UMM compliant and reusable processes in the Business Collaboration Model. The Core Components Library (from industry proven information definitions as contained in existing EDI directories) is used as reference to create reusable business information structures; which are also part of the Business Collaboration Model. Transform the Business Model. The Business Collaboration Model above is a complete (including worksheets and graphics) expression of all business requirements, but it is not in a syntax that can be directly interpreted (for business operation runtime) in software. Using the Business Collaboration Specification Schema (BCSS), the Model is transformed into a technology and implementation neutral structured syntax format. Implement the Business Model. At this last stage the technology-specific production rules are applied to the Business Collaboration Model in its BCSS form. Specific technology rules include EDI, ebXML, Web Service based business objects, or other production rules with new technology. Authority Person/group/organisation responsible for the invention, maintenance and dissemination of the _approach. UN/CEFACT UN Economic Commission for Europe Palais des Nations, Room 442 CH-1211 Geneva 10 Switzerland Telephone: +41 22 917 27 73 Telefax: +41 22 917 00 37 E-mail: [email protected] General references (Public) [email protected] Framework definition (bibliography references and urls) Business Collaboration Framework overview: (Figure 31)
UML UMM Meta Model UMM Reference guide UMM User guide Business collaboration Models
Business Collaboration Schemas Technology specific infrastructure (ebxml, WS, I-EDI, CORBA, SunONE, .NET) Figure 31 - BCF Overview
DA111-SotA-v1.0 PUBLIC Page 64
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
6.2.7 Biztalk Summary The objective of Microsoft’s BizTalk Server is to enable the exchange of various documents between business partners, as well as to integrate internal business processes and applications. Authority Microsoft Windows Server. General references (Public) www.microsoft.com/biztalk Framework definition (bibliography references and urls) BizTalk Framework Sending a document within the BizTalk Framework means the serial of processing steps triggered by an event within a business application: - An event occurs within a business application. - The application, or the application adapter, creates a BizTalk document. - The application transmits the BizTalk document to the BizTalk server. - The sending BizTalk server adds any required transport- specific envelope information, and transmits the BizTalk message to the destination server. - When the message is received by the destination BizTalk server, it may be validated and staged for processing by the destination application. BizTalk Document is a SOAP message in which the body contains the Business Documents, and the header contains BizTalk specific header entries for enhanced message handling semantics with the elements lifetime, identity, acceptance, idempotence, receipts (delivery and commitment). BizTalk Message containing a primary BizTalk Document that defines the semantics of the Message within the BizTalk Framework is the unit of wire-level interchange between BFC Servers. The message may contain attachments including XML documents, some of which may themselves be BizTalk documents. The Figure 32 shows the main components of BizTalk Server 2004. BizTalk Server consists of receive and send adapters, receive and send pipelines, orchestrations, the BizTalk Server message box, and the business rules engine.
Figure 32 – Technical overview BizTalk Server Microsoft: BizTalk Server provides the development and execution environment that orchestrates business processes, both within and between businesses. BizTalk Server features include the
DA111-SotA-v1.0 PUBLIC Page 65
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
ability to define business document specifications and how these documents have to be transformed when passed between applications, and the ability to monitor and log server activity. The server provides a standard gateway for sending and receiving documents across the Internet, as well as providing a range of services that ensures data integrity, delivery, and security. BizTalk Server Architecture The logical application model for the BizTalk Framework is implemented in layers. These logical layers include the Application (and appropriate adapters), the BizTalk server, and Data Communications. The application communicates with other applications by sending business documents back and forth through BizTalk servers. Communication is facilitated by a BizTalk server, which provides a defined set of services to the application. Multiple BizTalk servers communicate with one another over a variety of data communication protocols, such as HTTP or MSMQ (Microsoft Message Queuing). The BizTalk Framework does not prescribe what these data communication protocols are, and is independent of the implementation details of each.
Functionality of the BizTalk Server BizTalk Server enables businesses to achieve application integration through five key processes, namely document transport and routing, data transformation, application integration, process automation, and scalability and manageability services. Each process is achieved through receive functions, channels, ports, schedules, and tools: - Receive functions are the starting point for documents submitted to BizTalk Server. - Channels modify the structure of these documents as well as manage encryption, digital signatures, and logging. - Messaging ports send documents to schedules or to external organisations and trading partners. - Schedules orchestrate business processes. - BizTalk Server 2002 tools enable the receive functions, channels, messaging ports, and schedules to run.
Comprehensive Toolkit BizTalk Editor provides to visualise a document’s format, to define data types for individual elements and attributes, to define required or optional data fields, etc. The Editor looks similar for EDI and Flat-file schemas. BizTalk mapper is where we can actually map out the trading partner relationship using a graphical format. It is schema driven which basically involves the scripting in a screenshot. The BizTalk orchestration is done via the VISIO User Interface, bringing together the business analyst and the IT developer. Usually, the analyst is involved in designing the process, whereas the developer is implementing the process including system software. Analysis for Enterprise Interoperability § How this approach supports Enterprise Interoperability? Connecting trading partners and integrating systems is no longer the end goal of enterprise integration. Companies require highly automated business process management functionality, with the flexibility to incorporate a human touch at appropriate stages throughout the workflow, as provided by BizTalk Server 2004 orchestration services. Additionally, with the BizTalk Server 2004 rules engine, companies can implement flexible business rules and make them visible to the information worker. Review the BizTalk Server 2004 Case Studies to learn about real-world solutions using BizTalk Server 2004 (see Figure 33).
DA111-SotA-v1.0 PUBLIC Page 66
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
Figure 33 – Business Benefit
6.2.8 Rossetta Net Summary RosettaNet Objectives RosettaNet is a non-profit consortium of more than 400 of the world’s leading Information Technology (IT), Electronic Components (EC), Semiconductor Manufacturing (SM) and Solution Provider (SP) companies working to create, implement and promote open e-business process standards. RosettaNet is named after the Rosetta Stone, which, carved with the same message in three languages, led to the understanding of hieroglyphics. RosettaNet, like the Stone, is breaking language barriers. By establishing a common language – or standard processes for the electronic sharing of business information – RosettaNet opens the lines of communication for everyone involved in the supplying and buying of today’s technologies. RosettaNet Work Done RosettaNet standards Developed with the collaboration and expertise of leading high-tech companies worldwide, RosettaNet standards offer a robust non-proprietary solution, encompassing data dictionaries, implementation framework, and XML-based business message schemas and process specifications, for e-business standardisation. These standards are free to the public on the RosettaNet Web site. They are dedicate to e-business. RosettaNet offers everyone involved in the supplying and buying of today’s technologies opportunity to profit: Businesses that offer the tools and services to help implement RosettaNet standards gain exposure and business relationships. RosettaNet-adopting companies realise global, dynamic and flexible trading networks, time- and money-saving operational efficiencies, and new business. End users enjoy speed and uniformity in purchasing practices. RosettaNet’s global Supply Chain Boards Leaders from elected Partner companies comprise RosettaNet’s global Supply Chain Boards. Representing a cross-section of RosettaNet Partner companies in terms of core competencies and regional involvement, Supply Chain Board Members drive development and priorities, serve as examples of implementation success, and actively promote RosettaNet. RosettaNet has a Supply Chain Board for each vertical industry in its current scope: The global EC Supply Chain Board consists of representatives of the EC trading network, including semiconductor suppliers, passive suppliers, connector suppliers, distributors and customers. The global IT Supply Chain Board consists of representatives of the IT trading network, including manufacturers,
DA111-SotA-v1.0 PUBLIC Page 67
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
software publishers, distributors, resellers, end users, shippers and e-Technologists. The global SM Supply Chain Board consists of representatives of the SM trading network, including integrated device manufacturers, fables device manufacturers, foundries, materials suppliers, and assembly, test and probe companies. CEO of RosettaNet is Jennifer Hamilton, a former executive at Quantum, is chief executive officer of RosettaNet. Content of the RosettaNet Standards RosettaNet Business Dictionary and RosettaNet Technical Dictionary RosettaNet dictionaries provide a common vocabulary for conducting e-business, and reduce confusion in the procurement process due to each company’s uniquely defined terminology. The RosettaNet Business Dictionary designates the properties for defining business transactions between trading partners. These Business Data Entities and Fundamental Business Data Entities are described in PIP Message Guidelines. The RosettaNet Technical Dictionary provides properties for defining products and services. RosettaNet Implementation Framework The RosettaNet Implementation Framework (RNIF) Core Specification provides exchange protocols for quick and efficient implementation of RosettaNet standards. The RNIF specifies information exchange between trading partner servers using XML, covering the transport, routing and packaging; security; signals; and trading partner agreement. Partner Interface Process RosettaNet Partner Interface ProcessesTM (PIPsTM) are specialised system-to-system XML-based dialogs that define business processes between trading partners. Each PIP specification includes a business document with the vocabulary, and a business process with the choreography of the message dialog. PIPs apply to the following core processes: Administration; Partner, Product and Service Review; Product Introduction; Order Management; Inventory Management; Marketing Information Management; Service and Support; and Manufacturing. RosettaNet Validation Program The Validation Program, a Foundational Program, is RosettaNet’s formal process for driving Partner implementation of newly published standards to ensure a high level of quality. Under the Validation Program, a group of RosettaNet Partners commit to implementing a standard upon publication. The Partners run the standard in production for a period of time, providing and reviewing feedback to enhance the standard, and ultimately attesting that the standard meets predefined requirements and has been successfully implemented in production. The Validation Program encourages rapid evolution of new standards to improve robustness and lower the frequency of change in the future. Types of programs developed by RosettaNet. RosettaNet programs are essentially divided into two types: Milestone and Foundational programs. Milestone Programs RosettaNet Milestone Programs focus on reaching implementation goals within an e-business process scenario. Milestone programs have served as unifying forces within the industry – driving collaboration to solve critical supply chain challenges, aligning priorities within the high technology trading partner and solution provider communities, and speeding development and production implementation of RosettaNet PIP standards. Foundational Programs Foundational Programs encompass the development and evolution of all RosettaNet standards, including enhanced production of standard specifications and content, improved technical architecture, convergence activities and programs designed to improve implementation and global adoption. RosettaNet references Information (including press reviews) can be found on the RosettaNet web site [3]. Authority Rossetta Net Global Consortium 16 The Moat New Malden, Surrey KT3 4SB United Kingdom Phone: +44 (0) 208 942 1726 Fax: +44 (0) 870 460 1463 E-mail:[email protected] URL: http://www.rosettanet.org
DA111-SotA-v1.0 PUBLIC Page 68
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
General references (Public) Information (including press reviews) can be found on the RosettaNet web site: www.rosettanet.org Analysis for Enterprise Interoperability The RosettaNet Interoperability Program improves software and implementation interoperability within the RosettaNet trading network through collateral, education and testing activities. A universally compatible way of connecting RosettaNet trading partners reduces cost of implementation in time, money and resources. Interoperable solution provider offerings allow companies to more accurately predict project timelines and cost, reducing implementation time from months to days once trading partners have their RosettaNet gateway installed. The cost of connecting with a new partner and adding a new Partner Interface ProcessTM (PIPTM) with an existing partner is significantly reduced. Main conclusions for ATHENA The part: “Rossetta Net business dictionary and Rossetta Net technical dictionary” is a help for ontology part (A3). The part: “Partner Interface Process” allows a standardisation of practices and business process.
6.2.9 W3C Summary The World Wide Web Consortium (W3C) creates Web standards. W3C's mission is to lead the Web to its full potential, which it does by developing technologies (specifications, guidelines, software, and tools) that will create a forum for information, commerce, inspiration, independent thought, and collective understanding. This summary in 7 points explains W3C's goals and operating principles:
1. Universal Access W3C defines the Web as the universe of network-accessible information (available through your computer, phone, television, or networked refrigerator...). Today this universe benefits society by enabling new forms of human communication and opportunities to share knowledge. One of W3C's primary goals is to make these benefits available to all people, whatever their hardware, software, network infrastructure, native language, culture, geographical location, or physical or mental ability. W3C's Internationalisation Activity, Device Independence Activity, Voice Browser Activity, and Web Accessibility Initiative all illustrate our commitment to universal access.
2. Semantic Web People currently share their knowledge on the Web in language intended for other people. On the Semantic Web ("semantic" means "having to do with meaning"), we will be able to express ourselves in terms that our computers can interpret and exchange. By doing so, we will enable them to solve problems that we find tedious, to help us find quickly what we're looking for: medical information, a movie review, a book purchase order, etc. The W3C languages RDF, XML, XML Schema, and XML signatures are the building blocks of the Semantic Web.
3. Trust The Web is a collaborative medium, not read-only like a magazine. In fact, the first Web browser was also an editor, though most people today think of browsing as primarily viewing, not interacting. To promote a more collaborative environment, we must build a "Web of Trust" that offers confidentiality, instils confidence, and makes it possible for people to take responsibility for (or be accountable for) what they publish on the Web. These goals drive much of W3C's work around XML signatures, annotation mechanisms, group authoring, versioning, etc.
4. Interoperability Twenty years ago, people bought software that only worked with other software from the same vendor. Today, people have more freedom to choose, and they rightly expect software components to be interchangeable. They also expect to be able to view Web content with their
DA111-SotA-v1.0 PUBLIC Page 69
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
preferred software (graphical desktop browser, speech synthesiser, braille display, car phone...). W3C promotes interoperability by designing and promoting open (non-proprietary) computer languages and protocols that avoid the market fragmentation of the past. This is achieved through industry consensus and encouraging an open forum for discussion.
5. Evolvability W3C aims for technical excellence but is well aware that what we know and need today may be insufficient to solve tomorrow's problems. We therefore strive to build a Web that can easily evolve into an even better Web, without disrupting what already works. The principles of simplicity, modularity, compatibility, and extensibility guide all of our designs.
6. Decentralisation Decentralisation is a principle of modern distributed systems, including societies. In a centralised system, every message or action has to pass through a central authority, causing bottlenecks when the traffic increases. In design, we therefore limit the number of central Web facilities to reduce the vulnerability of the Web as a whole. Flexibility is the necessary companion of distributed systems, and the life and breath of the Internet, not just the Web.
7. Cooler Multimedia! Who wouldn't like more interactivity and richer media on the Web, including resizable images, quality sound, video, 3D effects, and animation? W3C's consensus process does not limit content provider creativity or mean boring browsing. Through its membership, W3C listens to end-users and works toward providing a solid framework for the development of the Cooler Web through languages such as the Scalable Vector Graphics (SVG) language and the Synchronised Multimedia Integration Language (SMIL). Authority World Wide Web Consortium Contact Janet Daly, Head of Communications Tel: +1.617.253.5884 Fax: +1.617.258.5999 e-mail: [email protected]
General references (Public) www.w3.org
6.2.10 OMG Summary Organisation: Founded in April 1989 by eleven companies, the Object Management Group™ (OMG™) began independent operations as a not-for-profit corporation. Through the OMG's commitment to developing technically excellent, commercially viable and vendor independent specifications for the software industry, the consortium now includes approximately 800 members. The OMG is moving forward in establishing the Model Driven Architecture ™ as the "Architecture of Choice for a Connected World" ™ through its worldwide standard specifications including CORBA ®, CORBA/IIOP™, the UML™, XMI™, MOF™, Object Services, Internet Facilities and Domain Interface specifications.
Mission: The OMG was formed to create a component-based software marketplace by accelerating the introduction of standardised object software. The organisation's charter includes the establishment of industry guidelines and detailed object management specifications to provide a common framework for application development. Conformance to these specifications will make it possible to develop a heterogeneous computing environment across all major hardware platforms and operating systems. Implementations of OMG specifications can be found on many operating systems across the world today. The OMG's series of specifications detail the necessary standard interfaces for Distributed
DA111-SotA-v1.0 PUBLIC Page 70
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
Object Computing. It’s widely popular Internet protocol IIOP (Internet Inter-ORB Protocol) is being used as the infrastructure for hundreds of technology companies. OMG specifications are used worldwide to develop and deploy distributed applications for vertical markets, including Manufacturing, Finance, Telecoms, Electronic Commerce, Real-time systems and Health Care. The OMG defines object management as software development that models the real world through representation of "objects." These objects are the encapsulation of the attributes, relationships and methods of software identifiable program components. A key benefit of an object-oriented system is its ability to expand in functionality by extending existing components and adding new objects to the system. Object management results in faster application development, easier maintenance, enormous scalability and reusable software. Authority
Location: The OMG is headquartered in Needham, MA, USA with a subsidiary in Japan. The OMG has international marketing offices in Bahrain, Brazil, Germany, India and the UK, along with a government representative in Washington, D.C. Contact: Object Management Group 250 First Avenue, Ste 100 Needham, MA 02494 +1 781-444 0404 +1 781-444 0320 Email: [email protected]
General references (Public) www.omg.org
6.2.11 EN/ISO 19439 : Enterprise Integration – Framework for enterprise modelling Summary EN/ISO 19439 was elaborated jointly by ISO TC184 TC5/WG1 and CEN TC310 WG1 and was approved in 2002. This approach is based on the early work known as ENV 40003 (1990) elaborated by CEN TC310/WG1. The origin of ENV 40003 is mainly from CIMOSA. The objective of this standard is to define the generic concepts that are required to enable the creation of enterprise models for industrial business and constitutes a conceptual basis for model-based enterprise engineering. Enterprise modelling consultancies and tool vendors have developed enterprise modelling methodologies and supporting tools that address phases of the enterprise life cycle and various aspects of enterprise modelling. These methodologies and tools support business decision-making (such as process visualisation and simulation), enterprise process management, control and monitoring of operational processes (such as workflow) and performance monitoring (such as visualisation of work in progress). This framework provides a unified conceptual basis for model-based enterprise engineering that enables consistency, convergence and interoperability of the various modelling methodologies and supporting tools. The framework does not encompass methodological processes; it is neutral in this regard. Link or description Not public available because of the current status (final draft). Authority The person/group/organisation responsible for the invention, maintenance and dissemination of the approach is ISO TC184 SC5 WG1 and CEN TC310 WG1. General references (Public) - ENV 40003 (1990), Computer Integrated Manufacturing - CIM systems architecture framework for modelling, CEN, Brussels. - EN/ISO 19439 (2002), Enterprise Integration – Framework for enterprise modelling
DA111-SotA-v1.0 PUBLIC Page 71
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
- AMICE (1993), CIMOSA - Open System Architecture for CIM, 2nd edition. Springer-Verlag, Berlin. Standard definition (bibliography references and urls)
EN/ISO 19439 defines a framework for enterprise modelling. It is an extension of previous ENV 40003 – Modelling Framework for CIM as shown in Figure 12 - The CIMOSA Framework for modelling. The EN/ISO 19439 framework has the same dimensions than ENV 40003. It is structured according to three dimensions: enterprise model phase, enterprise model view and genericity. The dimension enterprise model phase comprises: (1) domain identification, (2) concept definition, (3) requirements definition, (4) design specification, (5) implementation description, (6) domain operation and (7) decommission. At each phase, four enterprise model views are defined: - function, - information, - resource and - organisation. Three levels of genericity allow building an enterprise model at - the particular level using partial models defined at - the partial level and/or generic constructs provided at - the generic level. The graphical representation of the framework is given in Figure 34.
DA111-SotA-v1.0 PUBLIC Page 72
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
Figure 34 - Framework for enterprise modelling (EN/ISO 19439)
Tutorials (public references)
There is no tutorial on this standard
Case Studies (public references)
None Supporting tools
This is a conceptual standard. There is no tool developed so far. However, within the frame of CIMOSA promotion initiative, the University of Valencia, Spain has developed a CIMOSA framework demonstration tool. Industrial Use Because of the general definitions this standard is used in several variants of enterprise modelling methodologies and tools. But the standard is today not used for model exchange or orchestrating different enterprise modelling approaches. Strength The holistic approach is very useful to identify already existing concepts. System design phases are integrated completely. The definitions are clear . Weakness The approach is not applicable directly, because there are no rules for application views exists, It describes only a framework for modelling instead for model integration (except the model granularity and instantiation). Analysis for Enterprise Interoperability
- How this approach supports Enterprise Interoperability? This approach supports enterprise interoperability adopting the Integrated Paradigm. It provides a standard framework to describe and model enterprise systems in a consistent and complete way.
DA111-SotA-v1.0 PUBLIC Page 73
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
- How this approach supports Enterprise Modelling of Collaborative Enterprises? This approach provides a standard framework to describe enterprise systems. Two different enterprises modelled using this standard framework can easily be compared and mapped one to another. This will support collaborative works between enterprises. - How this approach could be used in ATHENA, and more specifically in project A1? This is a proposal to map OMG model to EN/ISO 19439 for ATHENA A1, as follow: There would be three potential dimensions in POP*: (1) Dimension of model stages (Requirement definition, design specification, implementation description,…). This dimension is already in ISO 19439. We are only concerned with the first three stages. (2) Dimension of model vi ews (Process, Resource, Organisation, Decision, Control…). This dimension is already in ISO 19439 but A1 may have different views. (3) Dimension of model genericity (Meta-model, Model, Enterprise assets). This is a mapping of OMG layered model to the ISO 19439 genericity dimension. It seems that these three dimensions would cover all aspects of POP* Comments The new EN/ISO 19439 is consistent with ISO 15704 and is considered as an implementation of the requirements defined in ISO 15704. The scope of ISO 15704 includes any type of manufacturing control mode while EN/ISO 19439 more specifically focuses on model-based and computer executable process monitoring and control. Nevertheless, the modelling framework is compliant with GERA (Generic Enterprise Reference Architecture), which is a component of the ISO 15704. The major change with respect to the previous ENV 40003 is the extension of the framework along the enterprise model phase dimension to cover activities at higher and lower levels (domain identification, concept definition and decommission definition).
6.2.12 EN/ISO 19400: Enterprise Integration – Constructs for enterprise modelling Summary This document (prEN DIS 19440) has been prepared by Technical Committee CEN/TC 310 "Advanced Manufacturing Technologies", in collaboration with Technical Committee ISO/TC 184 "Industrial automation systems and integration". This approach is based on the previous work performed known as ENV 12204 (1995) elaborated by CEN TC310/WG1. The origin of ENV 12204 is mainly from CIMOSA approach and IEM. The objective of this standard is to define the set of modelling constructs enable the creation of enterprise models for industrial business and constitutes a conceptual basis for model-based enterprise engineering. This approach is mainly process modelling oriented and aims at supporting the use of the framework for enterprise modelling defined in EN/ISO 19439. This standard contains definitions and descriptions of the core constructs necessary for computer-supported modelling of enterprises, possibly as a precursor to computer integration or mediated human-system intermediation. It focuses on, but is not restricted to, the computer integration of the information aspects of manufacturing, including the management and control technology and the requisite human tasks. Models generated using constructs in accordance with that framework will be computer processable and ultimately enable the daily operations of an enterprise to be monitored and controlled by such models (EN/IS 19440, 2003). Authority The person/group/organisation responsible for the invention, maintenance and dissemination of the approach is ISO TC184 SC5 WG1 and CEN TC310 WG1. General references (Public)
- ENV 12204 (1995), Advanced Manufacturing Technology - Systems Architecture - Constructs for Enterprise Modelling, CEN Brussels
DA111-SotA-v1.0 PUBLIC Page 74
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
- FDIS EN/ISO 19440 (2003), Enterprise Integration – Constructs for enterprise modelling, N211, 30/04/2003. - AMICE (1993), CIMOSA - Open System Architecture for CIM, 2nd edition. Springer-Verlag, Berlin. Standard definition (bibliography references and urls)
EN/ISO 19440 defines a set of user oriented constructs (and associated templates) for enterprise modelling. It is business process oriented enterprise modelling. Therefore, the enterprise entities to be represented are Business Processes with their dynamics (control flow/process behaviour), functionalities (activities), inputs / outputs, control, resources and organisational aspects. Figure 35 gives an overview of constructs and relations between them as defined in ENV 12204 which is the basis for EN/ISO 19440.
Between ENTERPRISE RELATION OBJECT State of OBJECT View of STATE Type of OBJECT VIEW Involved in Can play the role of SEQUENCING BUSINESS RELATIONSHIP PROCESS Used in
ORDER Employs Combined by RESOURCE Used in
ENTERPRISE Provides EVENT ORGANISATION ACTIVITY PRODUCT CELL CAPABILITY SET Required by
For illustration only
Figure 35 - Previous ENV 12204 set of constructs (for illustration only)
The complete set of modelling language constructs defined in EN/ISO 19440 (without their associations) is shown in Figure 36. Most of the constructs defined in previous ENV 12204 remain in EN/ISO 19440.
DA111-SotA-v1.0 PUBLIC Page 75
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
Figure 36 - The set of constructs (Association not shown, for illustration only)
The relationship between constructs is shown in separated figures and not presented in this document. Each construct is described using a template (but also, text and graphics) as illustrated by Figure 37.
Figure 37 - Construct template constituents
DA111-SotA-v1.0 PUBLIC Page 76
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
Tutorials (public references)
There is no tutorial on this standard Case Studies (public references)
None Supporting tools
This is a conceptual standard. There is no tool developed so far. However, within the frame of CIMOSA promotion initiative, the University of Valencia, Spain has developed a tool. Analysis for Enterprise Interoperability
- How this approach supports Enterprise Interoperability? This approach supports enterprise interoperability at the enterprise model level i.e. interoperability between enterprise models and tools. The standard can be used in two ways. It would support the Integrated Interoperability Paradigm if two enterprise models are built using the (same) set of constructs provided by the standard. This standard also supports Unified Interoperability Paradigm in the case where the set of constructs are used at a meta level to allow mapping between enterprise models/tools built using different formalisms and constructs, for example the UEML initiative. - How this approach supports Enterprise Modelling of Collaborative Enterprises? This approach focuses on the business process and user oriented modelling. This is particular relevant to the modelling of Collaborative enterprises as most of the interactions between two collaborative enterprises are action/activity flows at the business process level. - How this approach could be used in ATHENA, and more specifically in project A1? We think this standard is quite relevant to ATHENA A1 project (focusing on process aspect). Most of the proposed constructs such as: Domain, Business Process, Activity, Event, Product, Order, Resource, Capability, Decision centre and organisation related constructs (Organisation unit, cell, responsibility,…) can be adapted for A1 purpose. The adaptation might be concerned with the content of templates i.e. the attributes used to describe a construct.
6.2.13 CEN TS 14818: Enterprise Integration – Decisional Reference Model Summary CEN TS 14818 – Decisional Reference Model has been prepared by CEN TC310/WG1. It defines an integrated decision-making environment so that main decisions of interest and its associated decision frames are identified and modelled to allow consistent system-wide decision-makings. A decision is characterised by its functional category, decision level (horizon and period), and decision frame (objective, variables, constraints and criteria). This CEN TS is based on the original work of GRAI decisional model elaborated by LAP/GRAI of University Bordeaux 1. CEN TS 14818 is also an input for ISO/IEC 62264 – Enterprise Control System Integration multi part standard. Basic concepts of decisional reference model are taken into account in this standard. CEN TS 14818 is also being integrated in ISO 15704 by ISO TC184 SC5 WG1 to develop a Decisional View’ of enterprise model. Authority The person/group/organisation responsible for the invention, maintenance and dissemination of the approach is ISO TC184 SC5 WG1 and CEN TC310 WG1. General references (Public)
- CEN TS 14818: Enterprise Integration – Decisional Reference Model, CEN TC310/WG1, April 2004. - DOUMEINGTS, G., VALLESPIR, B. and CHEN, D. (1998), Decision modelling GRAI grid, in: Handbook on architecture for Information Systems (Peter Bernus, Kai Mertins, Gunter Schmidt. (Eds.), Springer.
DA111-SotA-v1.0 PUBLIC Page 77
IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004
- VALLESPIR, B., CHEN, D. and DOUMEINGTS, G. (2002), Argumentation for Explicit Representation of Control within Enterprise Modelling and Integration, in Enterprise Inter- and intra Organisational integration, Building International Consensus, edited by K. Kosank, Roland Jochem, James Nell and Angel Ortiz Bas, Kluwer Academic Publishers, 2002. Standard definition (bibliography references and urls)
The decision model aims at: · Identifying those significant decisions that are taken periodically within the manufacturing operations · Identifying decision objectives, decision variables and decision constraints associated to those decisions · Identifying horizon and period of the decisions so that they can be properly linked in a hierarchy for possible consistency analysis. The main items influencing decision-making are (also see Figure 36 for illustration): · the decision objective or set of objectives that the decision has to meet; · the decision variables that enable the decision-maker to know scope of available actions and their constraints; · the decision criteria that guide the choice in decision-making For example, consider a ‘Plan Production’ decision at the short term level; if production load is 250h superior to available production capacity, a decision is needed. Possible decision variables are: (1) Do extra hours and (2) Sub-contracting. Constraints are for example: (1) Min and Max extra hours 50 Attributes Descriptions Example Decision name Name of the decision to be taken Shop n°2 production overload decision Decision type One of the functional categories defined Plan Production Decision level One of the time categories defined (with Short term (H = 2 weeks, P = 1 week) Horizon and Period values) Decision objective A piece of information indicating which Minimise external sub-contracting types of performances are targeted Decision variable The item that a decision maker acts on to Extra hours, sub-contracting make its decisions Decision constraints The limitations on values of decision Extra hours/week 50 Tutorials (public references) There is no tutorial on this standard Case Studies (public references) None Supporting tools There is no tool developed so far. However, GRAISOFT (France) has developed a tool to support the modelling of decisional system and the creation of a decisional model. DA111-SotA-v1.0 PUBLIC Page 78 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 Analysis for Enterprise Interoperability - How this approach supports Enterprise Interoperability? This standard would support enterprise interoperability at the level of decision-makers. In other words, the approach allows enterprise deciders to better interact and interoperate by an explicit modelling of the decisions they must take and the decision frames they must take into account. - How this approach supports Enterprise Modelling of Collaborative Enterprises? This standard provides the concepts of Decision-making and associated Decision frame. These concepts allows to model collaborative enterprises from decisional point of view. - How this approach could be used in ATHENA, and more specifically in project A1? The decision-making and associated decision frame constitute an important part of the Workplace that ATHENA A1 project aims to model, design and implement. 6.2.14 ISO CD 18629: Process Specification Language (PSL) Summary ISO 18629 is jointly developed by joint working group between ISO TC184 SC4 and SC5 (JWG8) and led by SC4 Industrial data. ISO 18629 – PSL is based on NIST’s work. The goal of the PSL is to develop a neutral representation of manufacturing process information based upon formal theories and principles. The aim is to enable the integration of manufacturing process-related applications. It is an interchange format designed to help exchange process information automatically among a wide variety of manufacturing applications such as process definition, process planning, and scheduling or simulation tools. It involved the development of a formal semantic layer (called PSL ontology). Within the PSL ontology, the semantics of terminology is specified using KIF (Knowledge Interchange Format). The structure of PSL consists of a Core (fixed set of constructs) and Extensions (constructs to be developed according to needs). Authority The person/group/organisation responsible for the invention, maintenance and dissemination of the approach is ISO TC184 SC4 and SC4/SC5 JWG8 group. General references (Public) - Schlenoff, C., Knutilla, A., Ray, S., Unified Process Specification Language: Requirements for Modelling Processes: NISTIR 5910, 1996, National Institute of Standards and Technology, Gaithersburg, MD. - ISO/DIS 18629-1 (2003) Industrial automation system and integration -- Process specification language: Part 1: Overview and basic principles, 2003. Framework definition (bibliography references and urls) The goal of this standard is to create a process specification language, not a process characterisation language. The process specification language is composed of a lexicon, an ontology, and a grammar for process descriptions. A process specification language provides names, definitions and axioms for processes independently of the behaviours and capabilities of the processes. A process characterisation language describes the set of possible behaviours and capabilities for processes. ISO 18629 provides semantics to the computer-interpretable exchange of information related to manufacturing processes. It provides a language for describing a manufacturing process throughout the entire production process within the same industrial company or across several industrial sectors or companies, independently from any particular representation model. The nature of this language makes it suitable for sharing process information related to manufacturing during all the stages of a production process (ISO 18629, 2003). PSL is a language for specifying manufacturing processes based on a mathematically well defined vocabulary and grammar. In the context of an exchange of information between two processes, PSL specifies each process independently of its behaviour. For example, an object viewed as a resource within one process can be recognised as the same object even though it is viewed as a product within a second process. DA111-SotA-v1.0 PUBLIC Page 79 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 PSL is based on first order logic. The meaning of the concepts defined within PSL follows from sets of axioms and definitions provided within each extension of PSL-Core. A set of supporting notes and examples are provided within each part to aid the understanding of the language. The axioms of ISO 18629 are the set of KIF sentences that constrain the interpretation of the terminology in the non-logical lexicon of ISO 18629. These axioms are organised into PSL-Core and a partially ordered set of extensions to PSLCore. An ISO 18629 extension provides the logical expressiveness to express information involving concepts that are not explicitly specified in PSL-Core. The components of ISO 18629 are grouped into the following parts: a) Part 1: Overview and basic principles. There are two types of extensions within ISO 18629 core theories and definitional extensions. b) Part 1x series: Core theories. The current contents of these series of parts addresses: Part 11: PSL-Core; Part 12: Outer Core; Part 13: Time and ordering theories; Part 14: Resource theories; Part 15: Activity performance theories. Any new core theory shall be included in the Part 1x series. c) Part 2x series: External mappings. The current expected content of this series of part includes: Part 21: EXPRESS; Part 22: XML; Part 23: UML. This set of mappings may evolve according to industry needs and technology changes. d) Part 4x series: Definitional extensions. In addition to the core theories, ISO 18629 provides a series of definitional extensions that shall be used to capture the semantics of process terminology in different applications. All definitions in these extensions use the terminology of the core theories. The series currently includes: Part 41: Activities; Part 42: Time and state; Part 43: Ordering; Part 44: Resource roles; Part 45: Kinds of resource sets; Part 46: Processor activities; Part 47: Process intent. Additional extensions are to be developed later according to industry needs by any standardisation committee. Any new extension that is a definitional extension of PSL-Core shall be included in the Part 4x series. e) Part 2xx series: Translator Implementation Guidelines. Parts of this series shall be developed according to industry needs and technology changes. Tutorials (public references) There is no published tutorial on this standard Case Studies (public references) Case study has been performed in France (Automobile industry) to established interoperability (translation) between a IDEF3 model and a Microsoft Project model. Supporting tools There is no commercial tool available. Analysis for Enterprise Interoperability - How this approach supports Enterprise Interoperability? PSL adopted a unified paradigm to establish interoperability between various process models and tools. It consists in defining a mapping mechanism via a neutral format. The approach is similar to UEML approach. The difference is that PSL has an ontology while UEML not. - How this approach supports Enterprise Modelling of Collaborative Enterprises? This standard can provide some semantic definitions relative to processes involved in Collaborative Enterprises. However, this needs to be further investigated against the modelling requirements concerning Collaborative Enterprises. - How this approach could be used in ATHENA, and more specifically in project A1? This standard is quite relevant to ATHENA A1, because both A1 and PSL focus on process model/tool interoperability. There are two ways to use PSL. Either we adopted PSL ontology in A1 and define a neutral format to allowing mapping between various process models/tools; either we adopted the approach of PSL and define A1’s own ontology and associated neutral format. DA111-SotA-v1.0 PUBLIC Page 80 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 Comments PSL is not a process modelling language. Adopting PSL in ATHENA A1 does not mean to use PSL in the modelling stage. On the contrary, a set of modelling constructs still needs to be developed by A1. However, it is desirable that the process oriented modelling constructs be developed in relation to PSL. This SoA only provides a partial and very limited view on PSL standard. The standard itself is still in development. If ATHENA A1 uses PSL, a more detailed study is necessary; some working relations to ISO SC5/SC4 JWG8 group need to be established. 6.2.15 ISO 15704: Requirements for enterprise architecture and methodologies Summary In the mid-90’s, with the support of the IFAC-IFIP Task Force on Enterprise Integration, a pre- standard effort has been carried out with a more generic and larger coverage than the early version of ENV 40003. The result is ISO 15704 - Requirements for Enterprise Reference Architecture and Methodologies. It is supported by groups involved in developing enterprise- reference architectures such as the Purdue Enterprise-Reference Architecture (PERA) (Williams, 1996), the GRAI Integrated Methodology (GRAI/GIM) (Doumeingts, 1998; Chen, 1996), the Computer Integrated Manufacturing Open System Architecture (CIMOSA) (Amice, 1993) and the Generalised Enterprise-Reference Architecture and Methodology (GERAM) (Bernus, 1997). Authority The person/group/organisation responsible for the invention, maintenance and dissemination of the approach is ISO TC184 SC5 WG1. General references (Public) - Bernus, P. and Nemes, L. (1997), The Contribution of GERAM to Consensus in the Area of Enterprise Integration, in: Kosanke K. and Nell J.G. (Eds.) Enterprise Engineering and Integration: Building International Consensus, Springer-Verlag, Berlin, pp. 175-189. - Chen, D., Doumeingts, G. (1996), The GRAI-GIM reference model, architecture and methodology, in: Bernus P. et al. (Eds.) Architectures for Enterprise Integration, Chapman & Hall, London. - AMICE (1993), CIMOSA - Open System Architecture for CIM, 2nd edition. Springer-Verlag, Berlin. - Williams, T.J., Rathwell, G.A., Li, H. (Eds.) (1996), A Handbook on Master Planning and Implementation for Enterprise Integration Programmes, report 160, Purdue Laboratory for Applied Industrial Control, Purdue University, W. Lafayette. Framework definition (bibliography references and urls) The requirements for enterprise reference architecture and methodologies are developed on the basis of GERAM, as illustrated by Figure 6 - GERAM (Generalised Enterprise Reference Architecture and Methodology) framework components. The framework identifies, in its most important component called GERA (Generalised Enterprise Reference Architecture), the basic concepts to be used in enterprise engineering and integration. GERAM distinguishes between the methodologies for enterprise engineering (EEMs) and the modelling languages (EMLs), which are used by the methodologies to describe and model the structure, content and behaviour of the enterprise entities in question. The modelling process produces enterprise models (EMs), which represent all or part of the enterprise operations. These models can be used to guide the implementation of the operational system of the enterprise (EOSs). The methodology and the languages used for enterprise modelling are supported by enterprise engineering tools (EETs). The semantics of the modelling languages may be defined by ontologies, meta-models and glossaries, which are collectively called generic enterprise modelling concepts (GEMCs). The modelling process is enhanced by the use of partial models (PEMs), which are reusable models of human roles, processes and technologies. DA111-SotA-v1.0 PUBLIC Page 81 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 ISO 15704 (1998) should be considered as a requirements specification that will help business users to evaluate/compare the completeness of enterprise integration and engineering approaches that exist or will exist in the field. It is not a prescriptive standard and does not provide any operational methodology, language or tool to be used for a particular enterprise integration and engineering project. It is neutral in this regard. ISO 15704 allows the combined use of various approaches available in the market, as opposed to segregated applications, and thus facilitates their unification. Tutorials (public references) There is no tutorial on this standard Case Studies (public references) None Supporting tools This is a conceptual standard. There is no tool developed so far. Analysis for Enterprise Interoperability - How this approach supports Enterprise Interoperability? This standard is developed at a higher level abstraction. It supports integrated interoperability paradigm and provides a framework to name and link various enterprise engineering and integration components. - How this approach supports Enterprise Modelling of Collaborative Enterprises? The GERA architecture (not described in this SoA) can be used to support enterprise modelling of collaborative enterprises. - How this approach could be used in ATHENA, and more specifically in project A1? The GERAM framework can be used to categorise ATHENA expected research results and better structure ATHENA solution components. A draft paper proposal has been elaborated to discuss the mapping of ATHENA projects results to GERAM framework (Reference: David Chen, Thomas Knothe and Martin Zelm, ATHENA Integrated Project and the mapping to ISO 15704 international standard). Comments The GERA architecture is similar to EN/ISO 19439. It contains some details which are not explicitly defined in EN/ISO 19439. 6.2.16 ISO 14258: Concepts and Rules for Enterprise Models Summary ISO 14528 (1999) aims at defining concepts and rules for enterprise models to guide and constrain other standards or implementations. It does not define standard enterprise processes, organisation or data, but establishes a basis on which enterprise modelling standards can be developed. Its elaboration has been influenced by the earlier European initiative ENV 40003. Authority The person/group/organisation responsible for the invention, maintenance and dissemination of the approach is ISO TC184 SC5 WG1. General references (Public) - ISO 14258 (1999), Industrial Automation Systems – Concepts and Rules for Enterprise Models, ISO TC184/SC5/WG1, 1999-April-14 version. Framework definition (bibliography references and urls) The main concepts and rules defined in ISO 14258 are: (1) elements to be used when producing an enterprise model, including systems theory, methodologies derived from systems theory, factors of production (such as people, capital, materials, information, energy DA111-SotA-v1.0 PUBLIC Page 82 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 and tools), scope, semantics and syntax, etc., (2) concepts for life-cycle phases, (3) hierarchy, (4) structure, (5) behaviour and (6) model views. Table 3: gives a mapping between common names for system life-cycle phases as well as for what, how and do activities. “What” Activities “How” Activities “Do” Activities Plan and Build Phase Develop goals Develop requirements Produce parts (e.g. before sell/buy title Define strategy Define concept Produce product transfer) Define product needs Design product Test product Plan to produce product Ship product Plan to support product Use and operate Phase Define support needs Define use requirements Use the product (e.g. after the sell/buy transfer) Define use Define support Support product requirements Dispose and Recycle phase Define recycle/dispose Define recycle / dispose Recycle product (e.g. after product is no longer needs requirements Dispose product useful) Table 3: Mapping between system life-cycle phases and the system activities W, H and D Tutorials (public references) There is no tutorial on this standard Case Studies (public references) None Supporting tools This is a conceptual standard. There is no tool developed so far. Analysis for Enterprise Interoperability - How this approach supports Enterprise Interoperability? This standard provides a categorisation of interoperability scenarios known as the three basic paradigms/approaches: integrated, unified and federated. - How this approach supports Enterprise Modelling of Collaborative Enterprises? The standard defines basic concepts and rules for the creation of enterprise models. These concepts and rules are general applicable including the modelling of Collaborative Enterprises. - How this approach could be used in ATHENA, and more specifically in project A1? Possible use of this standard is to map various potential scenarios of collaborative enterprises into the three basic interoperability paradigms. Comments ISO 14258 would be the highest level standard to comply with in developing other standards in the area of enterprise modelling and integration. A proposal to review and merge this standard to ISO 15704 in 2005 is being elaborated and would be submitted to national standardisation bodies for approval. 6.2.17 ISO/IEC 15414: Open Distributed Processing – Reference Model – Enterprise Language Summary ISO/IEC 15414 (2000) – ODP Enterprise Language is elaborated by the joint working group ISO/IEC JTC 1/SC 7/WG 17. This standard provides a) a language (the enterprise language) comprising concepts, structures, and rules for developing, representing, and reasoning about a specification of an ODP system from the enterprise viewpoint (as defined in ITU-T 10 Recommendation X.903 |ISO/IEC 10746-3); b) rules which establish correspondences between the enterprise language and the other DA111-SotA-v1.0 PUBLIC Page 83 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 viewpoint languages (defined in ITU-T Recommendation X.903 |ISO/IEC 10746-3) to ensure the overall consistency of a specification. Previously ISO/IEC 10746-3 – ODP - architecture has proposed to model an enterprise from five viewpoints: enterprise, information, computational, engineering and technology (ISO/IEC 10746-3, 1994). In this standard, enterprise concepts and rules of structure are defined as a Reference Model. A Meta-model using UML notation is also provided to define the structure of an enterprise specification. UML (Unified Modelling Language). Authority The person/group/organisation responsible for the invention, maintenance and dissemination of the approach is the joint working group ISO/IEC JTC 1/SC 7/WG 17. General references (Public) - ITU-T Recommendation X.902 (1995) | ISO/IEC 10746-2: 1994, Information technology – Open Distributed Processing – Reference Model – Foundations - ITU-T Recommendation X.903 (1995) | ISO/IEC 10746-3: 1994, Information technology – Open Distributed Processing – Reference Model – Architecture - ITU-T Recommendation X.904 (1997) | ISO/IEC 10746-4: 1997, Information technology – Open Distributed Processing – Reference Model – Architectural semantics - ITU-T Recommendation X.911 (2000) | ISO/IEC 15414: 2000, Information Technology – Open Distributed Processing – Reference Model – Enterprise Language, , Version 303, ISO/IEC JTC 1/SC 7/WG 17. Framework definition (bibliography references and urls) Figure 38 presents a part of the meta-model of the enterprise viewpoint defined in ODP. This meta-model is not complete, but it is helpful for the understanding of the enterprise viewpoint. The main objective of the enterprise viewpoint is to identify roles and policies of enterprise objects (or groups of objects) in terms of: (1) Permission (what can be done), (2) Prohibition (what must not be done), (3) Obligation (what must be done) and (4) Security decisions. The term ‘Object’ in ODP means ‘a model of entity’. An entity is any concrete or abstract thing of interest. An object is characterised by its behaviour and, dually, by its state. Depending on the viewpoint, the emphasis may be placed on behaviour or on state. When the emphasis is placed on behaviour, an object is informally said to perform functions and offer services. DA111-SotA-v1.0 PUBLIC Page 84 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 Enterprise Meta-model Action Policy Process 1 1..* Step ActorRole Party 0..* 0..* 0..* expresses 1 0..* ActerfactRole S-Community Community 1 1..* Role 1..* realises 0..* Owner 1 0..* 1..* expresses ResourceRole 0..1 1 1..* fills 1 1 Object Objective represents realises Purpose 1 InterfaceRole 0..* 1 0..* 1 1 System 1..* 0..* State Scope 1 C-Object exports 1 ScopingStatement 0..* Figure 38 - ODP Reference Model - Enterprise Language – Structure of an Enterprise Specification An enterprise specification for an ODP system is a model of that system and relevant parts of its environment. A fundamental structuring concept for enterprise specifications is that of community. A community is a configuration of enterprise objects modelling a collection of entities (e.g. human beings, information processing systems, resources of various kinds and collections of these) that are subject to some implicit or explicit contract governing their collective behaviour (IEC/ISO 15414, 2000).. The ODP system may play a role in more than one community. Thus, the enterprise specification describes, within the areas of interest of the specification users: - roles fulfilled by the ODP system; - activities undertaken by the ODP system within processes in which it participates; - policy statements about the system, including those relating to environment contracts. In other words, the scope of the system is defined in terms of its intended behaviour and in enterprise language this is expressed in terms of roles, processes, policies and their relationships. Tutorials (public references) There is no tutorial on this standard Case Studies (public references) Case study has been performed at EDF (Electricté De France). Supporting tools There is no tool developed so far. Analysis for Enterprise Interoperability - How this approach supports Enterprise Interoperability? The ODP-RM standard creates an architecture within which support of distribution, inter-working, and portability can be integrated. It is concerned with Integrated and Federated Interoperability Paradigms rather than unified approach. The standards supports enterprise interoperability at the application and software levels rather than Enterprise modelling level as it is in EN/ISO 19440 and ISO 18629 (PSL). DA111-SotA-v1.0 PUBLIC Page 85 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 - How this approach supports Enterprise Modelling of Collaborative Enterprises? ODP – RM supports the modelling of distributed processing entities. The modelling concepts defined in this standard focus on high level enterprise concepts such as Purpose, Scope, Role and Policies of a computerised system. Distributed Processing capability is an important functionality of Collaborative Enterprises, most of the concepts are relevant to described virtual enterprise and extended enterprise. - How this approach could be used in ATHENA, and more specifically in project A1? The role concept which is absent in EN/ISO 19440, is defined in ODP-Enterprise Language standard. Role is defined with respect to a community. Four kinds of role are proposed: Actor role, Artefact role, Resource role, Interface role. Detail can be found in (ISO/IEC 15414, 2000). Comments ISO/IEC 15414 (2000) - ODP Enterprise language is quite similar to EN/ISO 19440 in the sense that they both identify high-level enterprise concepts from multiple views. ISO/IEC 15414 and EN/ISO 19440 do not have the same viewpoints and coverage. EN/ISO 19440 is more a business process-oriented modelling approach aiming at producing an operational process monitoring and control model. The ODP Enterprise Language is complementary rather than contradictory. 6.2.18 Conclusions for Standards The existing international standards of enterprise modelling are necessary inputs to ATHENA A1 project. There is no Enterprise Modelling standard for interoperability per se. However, most of the approaches reviewed in this document are relevant to Io issues. In particular, it seems important to: - map OMG 4-layer model to EN/ISO 19439 to define POP* modelling framework (we consider that the M0, M1 and M2 are covered in someway by EN/ISO 19439, M3 is out because it is not directly concerned with the EM issue). - reuse most of the constructs of EN/ISO 19440 (adapting template attributes needed) as basis to develop additional constructs dedicated to interoperability - integrate content of CEN TS 14818 as part of Workplace (decision-making and associated decision frame). The decision centre is also a construct defined at EM level by EN/ISO 19440. - take ISO 15704 as a basis to categorise ATHENA research results/solutions. This is even more important for A1 to structure its solution components according to GERAM framework. - use ‘role’ definitions as proposed by ISO/IEC 15414 ODP – RM Enterprise Language. Note that ODP is not only an enterprise language, but also architecture/platform (computational view etc.) - take into account ISO 18629 PSL and possible use as an ontology-based language for process model translation/mapping ATHENA A1 also aims at actively contributing to the above standardisation activities. Research and experimentation results from A1 should be as a source for future standardisation projects and existing standard revisions. 6.3 Enterprise Modelling Languages Enterprise Modelling (EM) can be define as the art of “externalising” enterprise knowledge, i.e. representing the enterprise in term of its organisation and operations (e.g. processes, behaviour, activities, information, objects, and material flows, resources and organisation units, system infrastructure and architecture). The goal is to make explicit facts and knowledge that add value to the enterprise or can be shared by business applications and users in order to improve the performance of the enterprise. Enterprise Modelling Language (EML) should allow building the model of an enterprise according to various points of view such as: function, process decision, economic, etc. in an integrated way. This section presents several EMLs. There are two categories of languages: those defined at high level of abstraction as Constructs for enterprise modelling (for example, EN/ISO 19440, ODP, UEML, DA111-SotA-v1.0 PUBLIC Page 86 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 GRAI,…) which are independent of the technology of implementation; and languages more related to a specific technology such as INTERNET technology based languages (example, ebXML, etc.). 6.3.1 IEM - Integrated Enterprise Modelling EML Identifier IEM-Integrated Enterprise Modelling Version Developed since 1989 Extension in 1996 (additional attribute types) Extension in 1998 (additional element types to enable the change of roles) Extension in 2001 (additional view of physical connections of resources) Summary The Integrated Enterprise Modelling Method (IEM) is a holistic methodical basis for modelling of relevant business aspects of an enterprise. The IEM models are of high transparency and easy to understand. There is no need for large-scale training to handle the models. IEM uses the object-oriented modelling technique for modelling business processes, related organisational structures, required information systems, etc. It provides analysing and optimising of processes and organisational structures of enterprises. In order to evaluate the variety of planning information and description requirements it allows different views on one consistent model. Authority Fraunhofer Institute: Production Systems and Design Technology (IPK Berlin) Division: Corporate Management Leader: Prof. Dr.-Ing. K. Mertins Related aspects of enterprise modelling, architectures, engineering and integration Introduction to enterprise modelling method IEM The Integrated Enterprise Modelling (IEM) methodology [1, 2, 3] is used by small, medium and big companies, consultancies and within different projects at IPK to model internal process structures of companies as well as cross organisational structures including SMEs and big enterprises. The scope is the description and analysis including performance figures of the processes according to product structures, resources like organisations, IT systems and manufacturing equipment. The following description includes a brief illustration of the methodology and some examples derived from industrial and research projects. Additional applications and case studies are available for the health sector, public services, IT services, IT requirement analysis, implementation of ERP systems, modelling of big enterprises etc. The method is developed by IPK since 15 years. It is used and applied by IPK as well as by different partners of IPK (consultants, universities, etc..). IEM Methodology of enterprise modelling The IEM uses the object oriented approach including inheritance and flexible definition of attributes and operation for enterprise modelling. This description of the IEM gives a brief background about the methodology. More detailed information can be found in the references. An object class is a pattern to describe objects, real things or occurrences, in a model. At the same time, the behaviour of the objects is described through functions. All objects of one class are described by the same, common features (attributes). Modifications of objects are described by the same functions. When instantiating objects, specific values are assigned to the attributes of the objects. The condition (status) of an object is being described by the entirety of the values of its attributes. The execution of functions changes the status of the objects. From an object class you may develop subclasses. The subclasses inherit all attributes of this superior class (parent class) – the objects of the subclasses are described by the same attributes. Additionally, each subclass is described in detail by class-specific DA111-SotA-v1.0 PUBLIC Page 87 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 attributes. The subclass is a specification of the parent class. For the subclass, users can newly define or eliminate individual attributes of the parent class. These changes are then passed down to all subclasses. IEM object classes are the basis of a comprehensive enterprise model. The unit of descriptive attributes and the defined functions to illustrate changes and interactions of the objects in the system ‘company’ ensure consistency and the reusability of the model. In a model, a company is described by objects, its relations and its behaviour. Business process Object ClassClass Process Chain StructureStructure Information model Process model Order Action Order Products Orders Resources InheritanceInheritance (State n) (State n+1) Product Action Product (State n) (State n+1) Resource Action Resource (State n) (State n+1) (red) (blue) (green) Figure 39: Main Views of IEM According to the purpose of the objects in the company we can distinguish the generic object classes ‘product’, ‘order’ and ‘resource’. Modelling then takes place exclusively through objects of these generic classes or newly defined subclasses. Any aspect may then be illustrated as a view onto the objects of these classes. The sub-models that are on this basis defined as views are integrated through the relations to the same objects. Figure 39 illustrates the main views of IEM. The “information model” view includes the class structures, the part-of relations and the attribute definitions of classes. This can be flexible adapted to the problem domains. The “process chain” view includes the graphical representation of the process sequences in relation to state descriptions derived from the information model. Figure 40 illustrates the description of the 3 generic object classes of the IEM. These classes can be detailed for the process analysis (e.g. Organisation and IT-System as subclass of Resource). To product belong all objects which an enterprise sells e.g. machines, services or software and product components which may come in into the final product. Product Orders control the activities in the enterprise e. g. customer orders, design and production orders Order Resources are the service carriers of the enterprise. To the resources belong e. g. employees, organizational units, and the required documents. Resource Resource Figure 40: Definition of the IEM Generic Object Classes DA111-SotA-v1.0 PUBLIC Page 88 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 Basic Elements Connection Elements Description of object states Connection between actions Product Resource Order and objects or between actions. Process description Split: both processes run In parallel. Action X = 1 Decision: the process sequence Basic Structure of the Process model depends on the object states X = 0 following the decision element „Generic Activity Model“ Join: different sequences are control joining to one sequence X = 1 Loop: several iterations transformation of process steps support X = 0 Figure 41: IEM Modelling Elements The modelling elements of IEM are illustrated in Figure 41. An additional element is the action. Also for actions, a class structure can be defined. This allows the definition of different process classes and a detailed analysis according these processes. In the process chain the action connects the input, output states, the controlling order and the necessary resources to proceed the process. The description of the whole network of processes within the enterprise contains also elements for alternative sequences (Decision), elements for parallel processing (Split) and the junction of different sequences (Join). The modelling of bill of materials and part of relations is also supported. All structures within IEM and MO²GO are related to the class structure. The class structure ensures the consistency of the whole model including all structures (classes, part of relations, process sequences and hierarchies, attributes and so on). DA111-SotA-v1.0 PUBLIC Page 89 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 Product type class structure Bill of material Process sequence Figure 42: Main visual structures of IEM The basic concept of process modelling is the hierarchical structuring of the view business process model. For a certain field of the company the modeller only studies the essential information about the processes. Detailed studies are described on lower levels through connected sub-processes, global studies are described on superior levels through the total process, that is connected with other processes. The object states establish the connection between the levels and thus the consistency of this view. The object states describe the introductory and concluding requirements of the process (Figure 43). The IEM methodology is supported by the MO²GO tool. Method and tool are used in several different applications from enterprise modelling, analysis, enterprise network building, supply chain analyse etc. (Figure 44). Product Product Idea considered system at customer Subsystems TheThe objectobject statesstates definedefine thethe boundaries of the Product Product Product boundaries of the Idea Designing process designed consideredconsidered systemsystem (Processes)(Processes) Product Manufacturing Product designed process produced Product Product Trading process TheTheIEMIEM permitspermits thethe linkinglinking ofof produced at customer subsub--modelsmodels oror projectsprojects alongalong thethe object’sobject’s lifelife cyclecycle Figure 43: Delimitation by Object States and Design of Subprojects DA111-SotA-v1.0 PUBLIC Page 90 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 Process Assistant Organisations- Handbuch 1. Grundsätze 2. Unternehmensaufbau und Ziele 4. Ablauforganisation IT-Concepts 5. Aufbauorganisation Business Engineering IT-Concepts Business Engineering Anhang: Verzeichnis der Prozesse QM-Handbuch Verzeichnis der Dokumente 1. Verantwortung der Leitung Organizational structuring 2. QM-System Organizational structuring IIEMEM andand concepts concepts 20. Statistische Methoden Anhang: Verfahrensanweisungen Arbeitsanweisungen Musterdokumente QualityQuality Management Management Prozeßkosten 6000 5000 4000 3000 EDV -Kosten [DM] Identifizieren 2000 Wissensziele 1000 Betriebsmittelkosten [DM] Kosten [DM] 0 Personalkosten [DM] Vertrieb Produktions- MO²GO faktoren MO²GO versenden mischung anwenden bereitstellen erzeugen Komplett fertigen Produkt. Vertrieb AktivitätenBusinessBusinessGummi Process Process Wertschöpfende ManagementManagement Geschäftsprozess Strategie Produkt. Vertrieb e verteilen speichern Harmonisation of Distributed Knowledge Management Harmonisation of Distributed Knowledge Management EnterprisesEnterprises ProcessProcess Indicator Indicator Lines Lines Figure 44: Application Domains Techniques used for providing Syntax and Semantics Coloured attributed typed channelled (hierarchies) Petri Net. Graphical symbols and classification structure according to IEM meta model. Paradigms and concepts (references) The IEM method was developed regarding an enterprise proceeding from an integral view of the manufacturing process and its tasks. As part of the planning process, this method results, meeting the demands set by the market, in the organisation and architecture of the business processes, as well as in the development of the required information. IEM enables the definition of the individual interfaces though reasonable, process-organisational divisions of functions within the business processes, This method leads the user from a general architecture to a specific architecture of system support and interfaces in this enterprise by way of modelling business processes and the necessary information /Mer93a,Spu93/ Exemplary requirements on enterprise modelling: Application-orientation The data within a company are to be structured according to applications, not according to fields, EDP systems or organisational units. The redundant collection, storage and processing of data as incorrect repeated inputs are avoided the data collection should take place where data is needed. The data should be processed suitable. A low level of abstraction ensures an application-oriented design. Flexibility Processes develop. The description of newly added information or changed relations must be enabled. The conditions of an enterprise are changing dynamically. Accordingly, the model must be adaptable as well as extendable. Openness with regard When modelling enterprises many different information structures to form and system and data types arise. All these structures and types should be connectable as well as compatible. In case of multiply occurring or repetitive processes, model modules help to ensure the independence of the model from the location of execution. Elements or processes to describe are to be modelled independently from specific operating or industry specifications. Openness with regard Considering different views of different people or groups involved to different views allows a better understanding and communication between the participants within the modelling process. DA111-SotA-v1.0 PUBLIC Page 91 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 User support In the course of an especially user-friendly use of methods or models the use of tools to support the modelling process is important. Computer-based tools enable the development and adjustment of complex models without, e.g. necessarily having to learn the special features of a computer language. Known applications The IEM and the tool MO²GO are used in production, government and service providing domains. Known supporting tools MO²GO The IOM-Toolbox with pre-defined evaluation for the IT-supported business life cycle, inclusive the IOM-Class tree with the necessary object classes for Modelling and evaluation. Known methodologies using the language · Management Systems Engineering Methodology · Business Process Benchmarking Methodology · Quality oriented Design for Enterprise Modelling · Business Process oriented Knowledge Management · Model based Enterprise Planning Methodology · Model based selection of ERP Systems · Model based Integration of IT-Service Engineering and Operation · Distributed Simulation · Flexible adaptable Software Systems · Virtual Enterprise Network Building General references (public) Kai Mertins and Roland Jochem. Quality-Oriented Design of Business Processes. Kluwer Academic Publishers, Boston/Dordrecht/London, 1999. ISBN 0-7923-8484-9. G. Spur, K. Mertins, and R. Jochem. Integrated Enterprise Modelling. Beuth Verlag GmbH, Berlin, 1996. ISBN 3-410-13310-0. Krause O., "Beyond BSC: a process based approach to Performance Management", Emerald Publishing UK, Vol 7 No 3 2003 PP4-14 Siebert, G.: Process-Benchmarking – Method to compare Business independent Processes. Dissertation TU Berlin, 1997. IPK, Berlin, 1998 Jochem, R.: Integrated Enterprise Planning on Basis of Enterprise. Dissertation an der TU Berlin, 2001 Business Process Oriented Knowledge Management. In: Mertins, K., Heisig, P., Vorbeck, J. (Ed.): Knowledge Management. Concepts and Best Practices. Berlin: Springer Verlag 2003, 2. Edition Knothe, T.: Synchronisation of Service Engineering and Operational Processes, International Conference on Competitive Manufacturing, COMA’04, Stellenbosche 2004 Neubauer, G.: Process oriented choice of PPS-Systems. Dissertation TU Berlin. IPK, Berlin, 1997 Schwermer, M.: Modelling Procedure for Business Process Planning, Dissertation TU Berlin. IPK, Berlin, 1997 Krause, H.: Flexible adjustable Software Systems computer aided production control. Dissertation TU Berlin. IPK, Berlin, 1997 Rabe, M.; Jäkel, F.-W.; Dassisti, M.; Erriquez, M.: Generic Adaptor for Distributed Simulation, 2002 www.viento-web.com Constructs and syntax definition (bibliography references and urls) In order to utilise its advantages and to provide a comprehensive and extendible enterprise model, the IEM method uses the object-oriented modelling approach, thus allowing the integration of different views on an enterprise in one consistent model as well as the easy adaptation of the model to changes within the enterprise. Required enterprise data and the DA111-SotA-v1.0 PUBLIC Page 92 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 business processes, i.e. the tasks referring to objects, are structured in accordance with the generic object classes of IEM and their subclasses. The generic classes ’Product’, ’Resource’ and ’Order’ are the basis of the Integrated Enterprise Modelling Method. Classes and their subclasses are describable by attributes. Subclasses derive attributes from their parent class. The process chain description based on object states derived from the IEM class structure (Product, Order, Resource, Action and their subclasses). This object states are connected via activities to describe state transitions. Actions are also connected with necessary resources and controlling (enabling) orders. Elements to describe parallel splitting, decisions, joins and loops are available. A main condition is that each element used within the process chain description of an IEM model is an instance of a class described within a related IEM class structure. Semantic definition (bibliography references and urls) The semantic of the IEM elements is easy expandable by the definition of additional subclasses of the classes product, order, resource and action. For example: organisation units are described by a resource subclass ”organisation” with an special set of attributes. Within the process chain description each organisation unit can be derived from the ”organisation” class or its subclasses. So the organisation units are describable and detectable within the business process model. These can be done for each semantic of an element within the business process model. Reference class structures for special usages are available. Tutorials (public references) Tutorials exist together with the MO²GO Tool description and within several publications in English and German. Case Studies (public references) The IEM is used in all kinds of enterprises (small, medium, large). It is actually used in production companies, service enterprises, government services (e.g. police) and in the health sector. Tutorial examples and reference models exist (e.g. organisational structuring, order processing). Related languages (older or newer versions, variants, ...) The IEM development was influenced mainly by: OOA, OOD and IDEF. Analysis for Enterprise Interoperability ? Is this language dedicated or usable for Enterprise Interoperability? How this EML supports Enterprise Interoperability? One common enterprise model can be the basis for many different application fields. By describing the processes the different interfaces are visible in a better way. This visibility is very useful e.g. for organisational interoperability issues. It is also helpful to have one reference model of enterprises which act in different locations in order to organise and control these distributed enterprises. ? How this EML supports Enterprise Modelling of Collaborative Enterprises? The IEM is used to express collaborative processes and the relation between different roles along the processes. With the IEM process model different role types can be defined as well as the relationships among them. This procedure can be applied within an enterprise but also between different collaborative enterprises. ? How this EML could be used in ATHENA, and more specifically in project A1? Because of the openness of the IEM it could be easily adapted to given languages and POP* dimensions. The kernel concept of the classes, states and attributes definition could be an input for the repository structure to be defined in A1.3. Comments IEM is successfully in use within commercial projects since 1992. For more information please contact: Dipl.-Inform., Dipl. Ing. Frank-Walter Jäkel Tel.: +49/30/39006-174 E-Mail: [email protected] Dipl.-Ing. Thomas Knothe Tel.: +49/30/39006-195 E-Mail: [email protected] DA111-SotA-v1.0 PUBLIC Page 93 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 6.3.2 Metis ITM EML Identifier ITM is one of four commercial templates and modelling languages available from Computas. ITM is used to implement the four leading EA methodologies. The ITM template also has expressiveness to start modelling of most other enterprise needs, such as project models, business and impact analysis models. Version The current version is 3.4.7, which was released in June 2004 with the new BPM template and joined modelling using constructs from all Metis templates Summary ITM implements many modelling languages allowing modellers to express knowledge in some 25 different domains that are relevant for Enterprise Architecture according to the frameworks and architectures mentioned in chapter 4.2. The template can easily be extended with new views and new modelling capabilities either by copying from the other template meta-models, such as GEM, BPM, UML, and ABM. Most customer projects are buying template extensions for new views to support decision- making, legacy systems integration or database content import and export. The ITM template will be complimented by a new template, called the CAPBC this Autumn. CAPBC supports portfolio management, performance monitoring and governance, and is developed in close cooperation with three leading customers. Figure 45 is a model view from the Model of the ITM meta-model in Metis. In this template there are some 300 different object types and some 40 different relationship types. Figure 45 – The ITM domain languages for EA, also support project modelling and model scaffolding for most top-down enterprise application areas and purposes. DA111-SotA-v1.0 PUBLIC Page 94 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 Figure 46: The expressiveness of the analyses domain, on of the 25 domains, notice the many relationships to other logically related domains. Authority Computas AS, P.O.Box 482, 1327 Lysaker, Norway. Known supporting tools METIS Constructs and syntax definition (bibliography references and urls) See the two views above, Figure 45 and Figure 46, more views of all 25 domains and there languages elements can be published as views from the model of the ITM template and meta- model. Figure 45 is a model view from the Model of the ITM meta-model in Metis. In this template there are some 300 different object types and some 40 different relationship types. 6.3.3 Metis BPM EML Identifier BPM is one of four commercial templates and modelling languages available from Computas. BPM is a new template aimed at the BPM market and implements most of the BPMN constructs plus integrates it with IDEF and other process modelling language yielding the expressiveness required in practical situations., Version The current version is 3.4.7, which was released in June 2004 with the new UML template and joined modelling using constructs from all Metis templates Summary BPM implements many modelling languages allowing modellers to express knowledge in some 18 different domains that are relevant for Business Process modelling and BPM. The template can easily be extended with new views and new modelling capabilities either by copying from the other template meta-models, such as GEM, ITM and UML. DA111-SotA-v1.0 PUBLIC Page 95 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 Most customer projects are buying template extensions for new views to support decision- making, legacy systems integration or database content import and export. Figure 47: The modelling domain languages available in the standard BPM template. Figure 48: The BPM template implements most of the BPMN language standard for Business Process Modelling and combines it with other modelling languages. DA111-SotA-v1.0 PUBLIC Page 96 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 Authority Computas AS, P.O.Box 482, 1327 Lysaker, Norway. Known supporting tools METIS Constructs and syntax definition (bibliography references and urls) See the two views above, Figure 47 and Figure 48, for an impression of the language construct. The BPM template can be combined with the ITM and the UML template, and also with GEM, the generic modelling domains of Metis with generic functions and features. Externally defined meta-models and templates can be used of associated sub-models. 6.3.4 Metis UML EML Identifier Metis UML is one of four commercial templates and modelling languages available from Computas.UML implements 9 of the diagrams described by OMG as part of the UML version 2.0 specifications, but all has expressiveness to start modelling of most other enterprise needs, such as project models, business and impact analysis models. Version The current version is 3.4.7, which was released in June 2004 with the new BPM template and joined modelling using constructs from all Metis templates Summary UML implements nine of the most useful diagramming techniques as defined by OMG in the specifications of UML version 2.0, such as shown in the model view of Figure 49. The template can easily be extended with new views and new modelling capabilities either by copying from the other template meta-models, such as GEM, BPM, ABM and ITM. Most customer projects are buying template extensions for new views to support decision- making, legacy systems integration or database content import and export. DA111-SotA-v1.0 PUBLIC Page 97 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 Figure 49: The UML diagramming languages available in the standard UML template. Any of these can be combined with other templates. DA111-SotA-v1.0 PUBLIC Page 98 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 Figure 50: The expressiveness of the analyses domain. In particular notice the many relationships to other logically related domains. Authority Computas AS, P.O.Box 482, 1327 Lysaker, Norway. Known supporting tools METIS Enterprise Constructs and syntax definition (bibliography references and urls) See the two views above, Figure 49 and Figure 50, for the diagram modelling languages. There are capabilities to link contents of the various diagrams to other views in models create by other languages and templates. 6.3.5 MEML EML Identifier MEML – Monesa Enterprise Modelling Language. Version EEML (from EXTERNAL) MEML 1.0 (UEML compliant) MEML 2.0 Summary MEML is a modelling language devised based on the work in the European Thematic Network UEML and the EXTERNAL IST project (the language EEML) in addition to the concrete input from work within MONESA (an ongoing Norwegian research project). DA111-SotA-v1.0 PUBLIC Page 99 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 As the Extended Enterprise Modelling Language (EEML), MEML is made to support process and enterprise modelling across a number of layers. The four layers of interest are: Generic Task Type, Specific Task Type, Manage Task Instances, Perform Task Instances. Process modelling occurs often at several layers concurrently, and may start at any layer, thus the simplified model (Figure 51) does not show sequence of work. The results from all of these processes input to Manage Task Knowledge, and can be used to tune the processes at any layer (not only the same layer). For instance, results from Manage Task Instances can be generalised and be used to change the model on the Specific Task Type layer. Figure 51 - Layers of Process Model Layer 1 – G – Generic Task Type: At this layer, we identify the constituent tasks of generic, repetitive processes and the logical dependencies between these task. A process model at this layer should be transferable across time and space to a mixture of execution environments. Examples are conceptual value chains and normative descriptions of “ways of working” for particular types of organisations (so-called reference processes). Layer 2 – S – Specific Task Type: Here process models are expanded and elaborated to facilitate business solutions. Elaboration includes concretisation, decomposition, and specialisation. Integration with local execution environment is achieved e.g. by describing resources required for actual performance. Thus, more reasons for dependencies between the sub-activities of a plan are uncovered. The specialisation can be along one or more of the following axes: Organisation, Business domain, service/product offered, and technological infrastructure Layer 3 – M - Manage Task Instances: The more abstract layers of generic and specific task types provide constraints but also useful resources (in the form of process templates) to the planning and performance of each extended enterprise process. At layer 3, more detailed decisions are taken regarding the performance of work in the actual work environment with its organisational, information, and tool resources; the scope is narrowed down to an actual DA111-SotA-v1.0 PUBLIC Page 100 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 process instance. Concrete resources increasingly are intertwined in the model, leading to the introduction of more dependencies. Management of activities may be said to consist of detail planning, co-ordination and preparation for resource allocation. Layer 4 – P - Perform Task Instances This lowest layer of the model covers the actual execution of tasks according to the determined granularity of work breakdown, which in practice is coupled to issues of empowerment and decentralisation. When a group or person performs the task, whether to supply a further decomposition may be left to their discretion, or alternatively candidate decompositions might be provided as advisory resources. At this layer resources are utilised or consumed, in an exclusive or shared manner. Manage Task Knowledge can be defined as the collection of processes necessary for innovation, dissemination, and exploitation of knowledge in a co-operating ensemble where knowledge seekers are linked to knowledge sources and a shared knowledge base is cultivated. This is active at all layers of this model. In particular, models of past task instances can be subject to a harvesting process in order to update templates available at the type level. Authority SINTEF, particularly John Krogstie Computas, particularly Dag Karlsen Known supporting tools METIS Constructs and syntax definition (bibliography references and urls) The main visual modelling tool for using MEML is currently METIS. On the other hand, we need to take into account that we transfer parts of a MEML-model as a basis for creation of adaptable work- places (currently to the Workware-environment). The modelling language currently includes four modelling domains, in addition to general modelling mechanisms and primitives provided in METIS, like swimlane-diagrams. § Process modelling § Resource modelling § Goal modelling § Data modelling (currently implemented with UML Class Diagram) Additional domains from other available METIS-templates e.g. ABM, UML or ITM can be freely added through standard functionality in METIS, but will not be directly usable in other tools or modelling services. The overview of the process modelling domain (Figure 52) includes also important links to other domains, especially the resource domain. The figure illustrates a process model being started at a given milestone. The first task '1.Task' includes examples of the different types of roles possible in a resource signature, and how roles can be filled by different types of resources- The flow from task goes further, either to '2. Task' or to 'Meeting' in which case it is indicated that an information-flow goes from 'Task' to 'Meeting', which is typically filled by an information object. DA111-SotA-v1.0 PUBLIC Page 101 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 Figure 52 - Main MEML modelling concepts Analysis for Enterprise Interoperability ? Is this language dedicated or usable for Enterprise Interoperability? How this EML supports Enterprise Interoperability? EEML as the forerunner of MEML was originally made in EXTERNAL to support the modelling of extended enterprises, and the methodology EEDO (6.2.3) is made specifically to support cooperation across organisational borders ? How this EML supports Enterprise Modelling of Collaborative Enterprises? The MEML is used to express collaborative processes and the relation between different roles along the processes. With the MEML process model different role types can be defined as well as the relationships among them. This procedure can be applied within an enterprise but also between different collaborative enterprises. ? How this EML could be used in ATHENA, and more specifically in project A1? Because of the openness of MEML it could be easily adapted to given languages and POP* dimensions. Also being complient with UEML it is a useful starting point also in connection to looking at the further relationship with the UEML work in e.g. INTEROP WP5 6.3.6 Petri Nets EML Identifier EML Identifier Petri Net Family includes: Place Transition Net, Control Event Net, Predicate Transition Net, Algebraic Petri Net, Colored Petri Net, Timed Petri Net, Stochastic Petri Net, Generalised Stochastic Petri Net, Hybrid Petri Net, and Fuzzy Petri Net. Summary The Petri Nets are a formal, graphical, executable technique for the specification and analysis of concurrent, discrete-event dynamic systems; a technique undergoing standardisation DA111-SotA-v1.0 PUBLIC Page 102 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 Initially developed by CA Petri for the specification of concurrent (parallel) systems. The main application domains in Enterprise Modelling (process analysis and implementation): 1. Manufacturing/Logistics 2. Workflow Management Other Application Domains (behaviour modelling of software products): 1. Distributed systems 2. Embedded systems 3. Hardware and software architectures 4. Software engineering in general 5. User interfaces The recognised benefits in the context of Enterprise Modelling of Petri Nets are: 1. Modelling power (resource sharing, conflicts, mutual exclusion, concurrency, non- determinism, visual modelling) 2. Analysis (deadlock detection, bottleneck analysis, animation, simulation) 3. Code generation for Controlling Manufacturing Systems However, below there is a list of recognised problems with Petri Nets: 1. Net size in real world problems 2. Difficult to understand due to its operational semantics and to the lack of real abstraction mechanisms 3. Code generation in generic distributed systems is hard because many important information (e.g., lack of abstraction) may be hidden or not represented, generating an inefficient code. It seems, in any field of application, that Petri Nets are positioned at too low level for direct modelling: therefore, they should be used in the context of complete methodologies that, first, provide high level models and then make possible to transform (automatically or not) these models into (a kind of) Petri Nets. Authority The steering committee is responsible for the International Conferences on Application and Theory of Petri Nets, including selection of organisers, PC members, invited speakers, tutorials and workshops, etc. The committee also supervises other activities of the Petri net community, such as the Advanced Courses on Petri Nets, the Petri Nets Newsletter, and the Petri Nets Mailing list and Web-pages. Petri Nets Steering Committee Known supporting tools A comprehensive comparative table about existing tools can be found at: http://www.daimi.au.dk/PetriNets/tools/quick.html General references (Public) http://www.daimi.au.dk/PetriNets/bibliographies/ Constructs and syntax definition (bibliography references and urls) – Basic constructs: 1. place 2. transition 3. arrow 4. marking Advanced concepts: 1. Time as stochastic, deterministic, discrete, continuous 2. Variable, Function 3. Colour 4. Predicate 5. Guard 6. Priority 7. Inhibitor arrow DA111-SotA-v1.0 PUBLIC Page 103 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 Semantic definition (bibliography references and urls) The basic mechanism is described through a transition rule (weak or strong). Other specific mechanisms (ways for expressing the transition rule which also depend on Petri Net) are: 1. operational semantics 2. algebraic semantics 3. linear logic semantics 4. linear equation semantics Some well know formal techniques related to Petri Nets are: 1. process algebras 2. control theory 3. transition systems A single net can be analysed against the following kinds of property (for understanding the net with respect to the real problem (world) they represent or for net implementation): 1. P and T Invariants 2. Reductions 3. Flows and semiflows 4. Reachability structure 5. Model checking (based on temporal logic) 6. Siphons 7. Partition 8. Unfolding 9. Constrains on Petri Nets for checking property (classes of Petri Nets, for instance, free choice Petri Nets) Tutorials (public references) http://www.daimi.au.dk/PetriNets/introductions/aalst/ Case Studies (public references) http://www.daimi.au.dk/PetriNets/applications/ Related languages (older or newer versions, variants, ...) This section reports many extensions to Petri Net family that have been developed for specific tasks, mainly in manufacturing and workflow domains (each entry can be used as keyword to search related papers on http://www.daimi.au.dk/PetriNets/: Controlled-entity- message/transition (CEM/T), extended resource control net (ERCN), MCTPN, DCTPN, Object-oriented colored Petri net (OOCPN), generalised stochastic colored timed Petri net (GSCTPN), stochastic colored Petri net (SCPN), colored stochastic Petri net (CSPN), automation Petri net (APN), colored timed object-oriented Petri net (CTOPN), colored resource-oriented Petri net (CROPN ), knowledge-based Petri net (KBPN), colored and/or Petri net (CARPN), fuzzy coloured Petri net (FCPN), controlled Petri net, Petri net with objects (PNO), co-operative objects, Grafcet. 6.3.7 CIMOSA EML Identifier CIMOSA technical baseline, business modelling language, version 3.3 (2000) Other general information on CIMOSA can be found in section 6.1.5. Summary CIMOSA developed by ESPRIT Consortium AMICE, is an architecture for enterprise integration consisting of a framework for enterprise modelling (reference architecture), an enterprise modelling language and an integrated infrastructure for model enactment all to be supported by a standards based common technology. Semantic definition (bibliography references and urls) Martin Zelm. CIMOSA constructs - extract from the technical baseline and express notation. Technical report, CIMOSA Association, 1998. DA111-SotA-v1.0 PUBLIC Page 104 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 G. Salvato and Al. Presentation and exchange of business model with CIMOSA – XML. Computers in industry, special issue, 40(2-3), 1999. Tutorials (public references) CIMOSA Association. CIMOSA computer aided tutorial v4.0. 1995. Agel Ortiz. VRCILT – Virtual reality CIMOSA learning and training tutorial. 2000. Case Studies (public references) K. Kosanke; F.B. Vernadat and M. Zelm (Eds.). CIMOSA : CIM Open System Architecture – Evolution and application in enterprise engineering and integration. Computers in industry, special issue, 40(2-3), 1999. Related languages (older or newer versions, variants, ...) IEM, GRAI, IDEF, ARIS … for detail see: § François B. Vernadat. Enterprise modelling and integration: principles and applications. Chapman and Hall, 1996. § Martin Zelm. Enterprise modelling – Constructs comparison (State of the Art). Technical Report, CIMOSA Association, December 2001. Main conclusions for ATHENA CIMOSA support ICT http://www.cimosa.de/IctSupport/IctSupport1.html 6.3.8 GRAI GRAI is the set of methodological modules, which contributes to the improvement of companies’ performance through enterprise modelling. GRAI Methodology The GRAI Methodology is an Enterprise Modelling Technique. This methodology was developed by the GRAI Group of the LAP (Laboratoire d’Automatique et de Productique) of University Bordeaux 1, from the middle of 80’s, based on: § A set of basic concepts describe in the GRAI conceptual reference model, § Graphical formalisms which describe the model, § A generic formalised approach which allow to implement the various methods. From these components, application domains were defined to contribute to the improvement of enterprise performance for industries and services. Twelve Methodological Modules supported by the GRAI Tools software were developed: § GIMTM (GRAI Integrated Method) : Re-Engineering and elaboration of target enterprise § GRAI AUDITTM : Audit § GRAI LOGITM : Choice of Information Technology (I.T.) solutions § GRAI PLANTTM : Implementation of I.T. solutions § GRAI PERFTM : Performance Indicators § GRAI BENCHTM : Benchmarking § GRAI STRATEGYTM : Business Plan § GRAI QUALITYTM : Relationships between GRAI TM Methodology and quality approach § GRAI ENGINEERINGTM : Management of design department § GEMTM (GRAI Evolution Method) : Management of enterprise evolution § GRAI-KNOWLEDGETM : Knowledge management Known applications http://www.graisoft.com/gb/exemplegb/exemgb1.php Known supporting tools: GRAITool 1.0 DA111-SotA-v1.0 PUBLIC Page 105 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 § Function coverage : Supports all GRAI Methodology Modules, Distributed (Client/Server) environment, Report Generation, Enhanced modelling formal concepts (integration, meta-model, customisation), Enhanced modelling ergonomy. § Graisoft web site : www.graisoft.com Known methodologies using the language GRAI Methodology General references (Public) G. DOUMEINGTS, B. VALLESPIR, D. CHEN – “GRAI Grid Decisional Modelling” – In Handbook on Architecture of Information Systems – Edited by P. Bernus, K. Mertins, G. Schmith – International Handbook on Information Systems – Springer Verlag – 1998 – pp 313- 337 G. DOUMEINGTS, Y. DUCQ – “Enterprise Modelling techniques to improve efficiency of enterprises” – In International Journal of Production Planning and Control – Volume 12 – Number 2 – March 2001 – pp 146-163 Constructs and syntax definition GRAI - Actigram The language is derived from IDEF0 but without the associated method § Inventor : ICAM Project Comments § GRAI / ACTIGRAM can be used for a large range of problems and systems and so, it is used all over the world. GRAI - Extended Actigram The language is derived from IDEF3 but without the associated method. Comments GRAI / Extended Actigram have more modelling capabilities than GRAI / Actigram and are more oriented towards business processes modelling. In this way, extended actigram would be suitable for the ATHENA project. GRAI - GRAI Grid The GRAI GRID represents the global decisional structure of a company or part of a company Inventor: LAP/GRAI Constructs and syntax definition (bibliography references and urls) § GRAI Grid : Formalism DA111-SotA-v1.0 PUBLIC Page 106 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 External To manage to manage To manage To manage to manage stocks To manage To manage quality Internal information Information commercial activity purchase production information system resources IE F F F F F F F II H = 2 ans P = 6 mois Inventory Commercial Purchase business Industrial business Distribution General quality Information Previous results Market, Actors management business plan plan plan strategy plan strategic planning plannings, parameters Strat H = 1 an Implementation P = 3 mois Implementation of Implementation of Implementation of inventory Inplementation of Quality plan Information system ROI, VAN, TIR, Local strategies commercial purchase business distribution management Business Plan implementation implementation associed risk, ... business plan plan planning planning Tact H = 6 mois P = 1 mois Project Project Project Project Project Project Project Availability of Local plannings management management management management management management management resources Opér IE F F F F F F F II Figure 53 - GRAI Grid Example DA111-SotA-v1.0 PUBLIC Page 107 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 Comments Among EM formalisms, the GRAI GRID is alone to be able to globally model the decisional structure (of an enterprise) of a company. GRAI - GRAI NETS The GRAI NET (Figure 54) represents the detail behaviour of a decision centre (management centre) in relation to the overall structure of decision (GRAI GRID) Inventor: LAP University Bordeaux 1 Business PL/30 CB Urgent order Plan MT Business Business complete the Plan Refocus the business Plan on 3 1 2 business plan completed Plan on 3 months months on 3 months Objective PL/30 Respect of 3 Rules Delivery Priorities dates State of production’s Needs’ GR/10 advance plan origin DV • Quantity Business delivered Adjust business Plan MT PL/30 PL/30 • Res. Int. TO PLAN H = 3 months P = 1 jour OF no Business plan PL/30 distributed by To make the PL/20 realizable PL/10 business plan period and operations Figure 54 - GRAI Nets example Case Studies (public references) http://www.graisoft.com/gb/telechargementgb/telegb1.php Related languages (older or newer versions, variants, ...) UML 1.0+ is used as a description language for GRAI. Both share the same most abstract layers of their meta-model for: - diagram-based hierarchical modelling - future implementation convenience Analysis for Enterprise Interoperability § How this EML supports Enterprise Interoperability? So that two enterprises can communicate, it is necessary that they have the same organisation. For this, we apply the GRAI methodology at two enterprises concerned. The GRAI Grid (enterprise global coordination) and GRAI Nets (enterprise local description) formalisms allow two enterprises to exchange the same type of information (see Figure 55). DA111-SotA-v1.0 PUBLIC Page 108 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 Requirement requirement Answer Answer Gérer les Gérer la qualité et Gérer les Gérer la qualité et Gérer les Gérer la qualité et Gérer les activités Gérer les activités Gérer les activités Gérer les activités Gérer les activités Gérer les activités Info. Externe prestations de le service après Info. Interne Info. Externe prestations de le service après Info. Interne Info. Externe prestations de le service après Info. Interne commerciales Terrains commerciales Terrains commerciales Terrains service vente service vente service vente Elaboration de la Historiqueclients, Elaboration de la Historiqueclients, Elaboration de la Historiqueclients, Stratégiede Elaboration de la Elaboration de la Planstratégique Stratégiede Elaboration de la Elaboration de la Planstratégique Stratégie de Elaboration de la Elaboration de la Plan stratégique stratégie relève,tournées stratégie relève,tournées stratégie relève, tournées groupe stratégieServices stratégie Terrains qualité et SAV groupe stratégieServices stratégie Terrains qualité et SAV groupe stratégie Services stratégie Terrains qualité et SAV commerciale IP... commerciale IP... commerciale IP... 10 10 10 Prévisions AO, Prévisions AO, Prévisions AO, contrats Coordonner les Coordonner les Définition des contrats Coordonner les Coordonner les Définition des contrats Coordonner les Coordonner les Définition des Coordonner les Planification des Coordonner les Planification des Coordonner les Planification des Budget actions prestations de actions qualité et Budget actions prestations de actions qualité et Budget actions prestations de actions qualité et activités terrains tournées activités terrains tournées activités terrains tournées Evolution commerciales service SAV Evolution commerciales service SAV Evolution commerciales service SAV contextuelle contextuelle contextuelle 20 20 20 Procédures Procédures Procédures historique historique historique Contrats, AO Contrats, AO Contrats,AO Planifierles Planifier les réclamation Planifierles Planifier les réclamation Planifier les Planifierles réclamation Evolution Planifierles Planifier les Evolution Planifierles Planifier les Evolution Planifier les Planifier les actions actions Qualité et En-cours actions actions Qualité et En-cours actions actions Qualité et En-cours contextuelle prestations réalisations contextuelle prestations réalisations contextuelle prestations réalisations commerciales SAV indicateurs de commerciales SAV indicateurs de commerciales SAV indicateurs de Réclamations Réclamations Réclamations 30 performance Requirement 30 performance Requirement 30 performance SiègeCIS SiègeCIS SiègeCIS Objectifsstratégiques Objectifs stratégiques Objectifsstratégiques CD-Commerc. Siège CIS CD-Commerc. SiègeCIS CD-Commerc. Siège CIS Aspectsbudgétaires Aspects budgétaires Aspectsbudgétaires Mettre à jour la Mettre à jour la Mettre à jour la DRH stratégiede DRH stratégiede DRH stratégiede Donnéespersonnel Plande charge global Données personnel Plan de charge global Donnéespersonnel Plande charge global Objectifscommerciaux l'agence Objectifscommerciaux l'agence Objectifscommerciaux l'agence client client client Plan de charge prévisionnel Réal-prest. Plan de charge prévisionnel Réal-prest. Plan de charge prévisionnel Réal-prest. Demandes directes Demandesdirectes Demandes directes Exprimerle besoin du Infode suivi Actions correctrices concertées Exprimerle besoin du Info de suivi Actions correctrices concertées Exprimerle besoin du Infode suivi Actions correctrices concertées Commercial DemandeMotivée client Réaliser le suivi des activités et le client Commercial DemandeMotivée client Réaliser le suivi des activités et le client Commercial DemandeMotivée client Réaliser le suivi des activités et le client service après ventes Lettretype ciblée serviceaprès ventes Lettretype ciblée service après ventes Lettretype ciblée Définitionde Besoin Définitionde Besoin Définitionde Besoin Fiches suiveuses complétées Fiches suiveuses complétées Fiches suiveuses complétées MKG Propositions Infode suivi QHSE MKG Propositions Info de suivi QHSE MKG Propositions Infode suivi QHSE RH-a RH-a RH-a Réaliser le contrat Commercial RH-a Réaliserle contrat Commercial RH-a Réaliser le contrat Commercial RH-a Contrat CorrespondantSAV Contrat Correspondant SAV Contrat CorrespondantSAV RH-a RH-t RH-a RH-t RH-a RH-t Commercial RH-t Responsable Commercial RH-t Responsable Commercial RH-t Responsable Technicien-plombier d'exploitation RH-a Technicien-plombier d'exploitation RH-a Technicien-plombier d'exploitation RH-a Responsable Responsable Responsable RH-a Answer RH-a RH-a Secrétaire Infode suivi Secrétaire Infode suivi Secrétaire Infode suivi commerciale commerciale Answer commerciale RH-a RH-a RH-a RH-a RH-a RH-a Commercial Secrétaire CommercialSecrétaire Commercial Secrétaire commerciale commerciale commerciale GPexploit GPexploit GPexploit Objectifs GP exploit. ObjectifsGP exploit. Objectifs GP exploit. client client client GPadm GPadm GPadm ObjectifsGP adm Objectifs GP adm ObjectifsGP adm Donnéesclients éditées Données clients éditées Donnéesclients éditées SI SI SI Avis de passage Avisde passage Avis de passage Réaliserles prestations Réaliser les prestations Réaliserles prestations Fournisseurs Résident Fournisseurs Résident Fournisseurs Résident Materiel et bureautique Solutionssatisfaisantes Materielet bureautique Solutionssatisfaisantes Materiel et bureautique Solutionssatisfaisantes Pret-terrain Pret-terrain Pret-terrain Demandede matériel terrain Demandede matériel Demandede matériel terrain Demandede matériel Demandede matériel terrain Demandede matériel Gérerles achats appros et Gérer les achats appros et Gérerles achats appros et stocks stocks stocks Prest-adm Prest-adm Prest-adm Demandede matériel bureautique RH-t RT-SI Demande de matériel bureautique RH-t RT-SI Demandede matériel bureautique RH-t RT-SI Releveur RT-SI TSP Releveur RT-SI TSP Releveur RT-SI TSP Support Support Support RH-a informatique RH-a informatique RH-a informatique Ressources Ressources Ressources administratives administratives administratives RH-a SI RH-a SI RH-a SI Gestionnairestock ModuleStock Gestionnairestock ModuleStock Gestionnairestock ModuleStock Figure 55 - Requirement of coordination at a global level § How this EML supports Enterprise Modelling of Collaborative Enterprises? The GRAI Grid allows an enterprise global coordination. For a collaborative enterprise, we have got to do a GRAI Grid for each enterprise and a global GRAI Grid, which allow us to do the Coordination and management of the logistic projects (see the Figure 56). Collaborative Enterprise (A + B) External To manage to manage To manage To manage to manage stocks To manage logistic To manage quality Internal information Information commercial activity purchase production information system IE F F F F F F F II H = 2 year P = 6 month Inventory Commercial Purchase business Industrial business Distribution General quality Information Previousresults Market, Actors management business plan plan plan strategy plan strategic planning plannings, parameters Strat H = 1 year Implementation P = 3 month Implementation of Implementationof Implementation of inventory Inplementation of Quality plan Information system ROI, VAN, TIR, Local strategies commercial purchase business distribution management Business Plan implementation implementation associed risk, ... business plan plan planning planning Tact H = 6 month P = 1 month Project Project Project Project Project Project Project Availability of Local plannings management management management management management management management resources Opér IE F F F F F F F II Gérer les produits Gérer les produits Informations Planifier gérer les Informations Informations Planifier gérer les Informations Gérer les ventes Gérer BE/BM (Achats, Appros, Gérer la logistique Gérer les ventes GérerBE/BM (Achats, Appros, Gérer la logistique Externes Synchroniser ressources Internes Externes Synchroniser ressources Internes Stocks) Stocks) Etablir les Faire le Affectation Etablir les Prévisions, Plan commercial Mise en oeuvre paramètres de Affectation des Faire le Affectation Programme globale des < Commandes ferme Affectation des Suivi des Faire le Plan de Adéquation Planning des < Entrées en Essais, Entrées en Essais, commande, Prise de prototypage, màj Entrées/sorties Lancement et suivi < Enterprise A Enterprise B Figure 56 – The global coordination DA111-SotA-v1.0 PUBLIC Page 109 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 6.3.9 IDEF EML Identifier EML Identifier IDEF (Integrated DEFinition methodology) Summary IDEF (for Integrated Definition) is a group of modelling methods that can be used to describe operations in an enterprise. IDEF was created by the United States Air Force and is now being developed by Knowledge Based Systems. Originally developed for the manufacturing environment, IDEF methods have been adapted for wider use and for software development in general. Sixteen methods, from IDEF0 to IDEF14 (and including IDEF1X), are each designed to capture a particular type of information through modelling processes. IDEF methods are used to create graphical representations of various systems, analyze the model, create a model of a desired version of the system, and to aid in the transition from one to the other. IDEF is sometimes used along with gap analysis. The following list describe the IDEF methods either current or in development. IDEF0 through IDEF4 are the methods most commonly used. - IDEF0: Function Modelling - IDEF1: Information Modelling - IDEF1X: Data Modelling - IDEF2: Simulation Model Design - IDEF3: Process Description Capture - IDEF4: Object-Oriented Design - IDEF5: Ontology Description Capture - IDEF6: Design Rationale Capture - IDEF7: Information System Audit Method - IDEF8: User Interface Modelling - IDEF9: Scenario-Driven IS Design - IDEF10: Implementation Architecture Modelling - IDEF11: Information Artefact Modelling - IDEF12: Organisation Modelling - IDEF13: 3-Schema Mapping Design - IDEF14: Network Design Authority Knowledge Based Systems, Inc. Corporate Headquarters: 1408 University Dr. East College Station, TX 77840 Phone: 979.260.5274 Fax: 979.260.1965 [email protected] Known supporting tools o IDEF Tools (Supplier: Knowledge Based Systems, Inc - http://www.kbsi.com ) - AI0 Win 6.0 (Supporting IDEF0) - SmartER 5.0 (Supporting IDEF1-IDEF1X) - ProSim 6.0 (Supporting IDEF3) - SmartClass (Supporting IDEF4) o Business Modelling Workbench (Supplier: IDEFine - http://www.idefine.com ) - Workflow Modeller - Workflow Simulator - Workflow Generation o WizdomWorks! (Supplier: Wizdom Systems, Inc. - http://www.wizdomsystems.com ) o WorkFlow Modeler (Supplier: Meta Software - http://www.metasoftware.com ) o AllFusion Process Modeler (Supplier: Advantage Software Limited - http://www.advantages.co.nz ) o System Architect (Supplier: Popkin Software - http://www.popkin.com ) DA111-SotA-v1.0 PUBLIC Page 110 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 Constructs and syntax definition (bibliography references and urls) Depending on the IDEF method used, different syntaxes exist to represent the models. The most representative construct of IDEF methodology is the generic IDEF0 diagram (a meta- model) shown on Figure 57. IDEF0 allows the user to depict a view of the process including the inputs, outputs, controls and mechanisms (which are referred to generally as ICOMs). - Inputs are resources consumed or transformed (refined) by the process. - Outputs are the elements created through the consumption / transformation of the inputs by the process. - Controls are the objects guiding the process: policies, guidelines, standards, laws. - Mechanisms are the agents that accomplish the actions (activities) contained by the process. Examples: people or manual and automated tools. Figure 57 - Generic IDEF0 diagram More information sources about IDEF constructs and syntax definition are available at: http://www.idef.com/Downloads/free_downloads.html Tutorials (public references) http://www.idef.com/Downloads/free_downloads.html Case Studies (public references) - General Company Documentation - Database design / Database management - Software development - Simulation - Business Process Re-engineering - Workflow management Related languages (older or newer versions, variants, ...) SADT (Structured Analysis and Design Technique), CIMOSA, GRAI, METIS ITM Comments The IDEF methodology is well suited to the business modellers’ endeavours to understand and capture the business operations and the supporting information system requirements. IDEF provides a reliable base for Business Process Engineering and Re-engineering. The IDEF family of modelling languages has succeeded because of the right timing, US Defence organisations support and of the fact that it was perceived as being a user-friendly methodology, as opposed to the other (many) modelling methods. As a consequence, many tools started to support the IDEF methodology. Also, many business stakeholders are regarding the CASE (Computer Aided Software Engineering) tools as being too complicated and more suitable for the software developers and other IT people, as opposed to the simplicity of IDEF languages. Some IDEF methods may also be used in software development, for example IDEF1x (relational databases) and the newer IDEF4 (object- oriented analysis and design). Making an analogy between IDEF and UML, we could find some similarities with the models they use. - IDEF0 may find an equivalent in the UML activity diagrams using the specialised business extensions for process modelling. - IDEF1 and IDEF1x are similar to the UML class and object diagrams that express the static (architectural) aspect of a system. DA111-SotA-v1.0 PUBLIC Page 111 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 - IDEF2 may be equivalent - to an extent - to the collaboration diagrams, activity and state diagrams in the UML language. - IDEF3’s process description diagram is similar to the UML activity diagram, while the object state transition diagram is similar to the state diagrams. IDEF3 is also similar to the use case diagram regarding the concept of scenario. - IDEF4 is specifically targeted towards software development and as such has similarities with the class, object, activity and state diagrams in the UML. - IDEF5 may only be compared to the meta-meta-model (and maybe meta-model level) in UML, where the language ontology is defined. 6.3.10 PSL Summary The Process Specification Language (PSL) defines a neutral representation for manufacturing processes. Process data is used throughout the life cycle of a product, from early indications of manufacturing process flagged during design, through process planning, validation, production scheduling and control. In addition, the notion of process also underlies the entire manufacturing cycle, coordinating the workflow within engineering and shop floor manufacturing. The goal of PSL is to create a process representation that is common to all manufacturing applications, generic enough to be decoupled from any given application and robust enough to be able to represent the necessary process information for any given application. This representation would facilitate communication between the various applications because they would all “speak the same language.” In addition, communication would be easier between different organisations or branches of organisations that need to work together for a specific project. Instead of being constrained to using the same software packages (that have the same process representations which can be easily transferred between companies), and having to introduce a new learning curve to one of the organisations that possibly doesn't usually use that package, two different packages that are “PSL compliant” could be used. Now the companies could use their native software package and then export files in the common representation to be read by the partner company. Authority PSL is being standardised within Joint Working Group 8 of Sub-committee 4 (Industrial data) and Sub-committee 5 (Manufacturing integration) of Technical committee ISO TC 184 (Industrial automation systems and integration). http://www.tc184-sc4.org/SC4_Open/SC4_Work_Products_Documents/PSL_(18629)/ Manufacturing Systems Integration Division NIST, 100 Bureau Drive, Stop 8260, Gaithersburg, MD 20899-8260. General references (Public) § General bibliography references and URLs about the language § http://www.tc184-sc4.org/ § Gruninger, M., Sriram, R.D., Cheng, J., Law, K., "Process Specification Language for Project Information Exchange," International Journal of IT in Architecture, Engineering & Construction, 2003. § Bock, C., Gruninger, M., "PSL: A Semantic Domain for Flow Models," Software and Systems Modeling Journal, 2003. Case Studies (public references) In September 1998, the Process Specification Language was used to exchange manufacturing process information between the IDEF3-based ProCAP process modelling tool and the C++ based ILOG Scheduler. The scenario being exchanged was developed by Ken McKay as part of the CAM-I State of the Art Scheduling Survey. This page describes the steps that were performed to accomplish this exchange. 1. The ProCAP tool is spawned showing the graphical representation of the CAMILE Motor Works scenario. DA111-SotA-v1.0 PUBLIC Page 112 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 2. The IDEF3 textual version of the CAMILE scenario is displayed. 3. An IDEF3 to PSL translator is run which converts the CAMILE scenario from IDEF3 to KIF (the exchange representation for PSL). 4. The KIF representation of the CAMILE scenario is shown. 5. The KIF representation is run through a KIF to HTML convertor which links all concepts in the scenario to their respective definitions. The HTMLized KIF file is shown. 6. A sample object-oriented presentation of the KIF file is displayed. 7. A PSL to ILOG translator is run which converts the CAMILE scenario from KIF to C++ using the ILOG libraries. (NOTE: the PSL to ILOG translator is actually multiple files - trans.plrc is the executable which accesses aux-idef.pl, syn2.pl, and gen.pl). 8. The textual version of the C++ file is displayed. 9. The C++ file is compiled, linked, and fed into ILOG to optimise it with respect to makespan. Comment: PSL initially elaborated by NIST is now moved to ISO TC184 SC4 for standardisation. For more information, please also see section 5.2.14 ISO 18629 PSL – Process Specification Language. 6.3.11 WPDL from the WfMC EML Identifier WPDL : Workflow Process Definition Language Version 1.1 Summary The Workflow Process Definition Language (WPDL) was first introduced by Workflow Management Coalition (WfMC) in 1994. The Workflow Process Definition Language (WPDL) was established as a meta-language for the exchange of build time workflow process models through a batch procedure (import/export of process models). The language design is based on a minimum meta-model that defines the elementary components that have to be supported by a tool that reads and/or writes WPDL. This minimum meta-model can be extended by vendor-specific extensions. The meta-model of the process part of WPDL is depicted in Figure 58 (for reasons of simplicity the cardinalities of the relationship types have been left out of the diagram). The organisational/resource model of WPDL is a specialisation of the Workflow Participant Specification Entity Type and thus not displayed in the figure. Core concept of the WPDL is a Workflow Process Definition that is composed of one or many Workflow Process Activities. The ordering of activities is determined by Transition Information elements that connect single activities. For more complex routings a Transition may rely on Workflow Relevant Data, that is, data from application systems which is relevant for the sequence of activities (i. e. the amount of a credit request that determines, whether the VP of the bank has to sign the approval or not). The entity types of WPDL are not extendable, however, user-defined attributes may be added to the single entity types. Moreover, references to external data sources as connecting points are explicitly denoted, such as the referral to an external organisational repository, to system and environmental data or to invoked application systems. In order to establish conformance for workflow management systems that follow different modelling paradigms, several conformance classes have been defined. These conformance classes limit the number of elements a workflow management system has to support in order to claim conformance to WPDL. These restrictions include e. g. a block-restriction for workflow systems that require each split in the process to be followed by a similar join in a later part of the process. Currently a mapping between WPDL and XML is under discussion in order to enable the exchange of process models through an internationally defined standard encoding language. DA111-SotA-v1.0 PUBLIC Page 113 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 Figure 58 - Meta model of the WPDL process modelling elements Authority § Workflow Management Coalition (WfMC) General references (Public) The following documents are associated with this document and should be used as a reference. General background information: · WfMC Terminology & Glossary (WfMC-TC-1011) · WfMC Reference Model (WfMC-TC-1003) http://www.wfmc.org Constructs and syntax definition (bibliography references and urls) The document “Interface 1: Process Definition Interchange Process Model” (Technical Report WfMC TC-1016-P, July 1998) describes a common interface for the exchange of workflow process definitions. This interface is based on a standardised language - the Workflow Process Definition Language, ”WPDL” - which can be supported by vendors of workflow management products to allow the exchange and documentation of workflow process definitions. It describes the syntax and content of information exchanged across the interface. Semantic definition (bibliography references and urls) DA111-SotA-v1.0 PUBLIC Page 114 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 Michael Zur Mühlen and Jörg Becker. Workflow process definition language - development and directions of a meta-language for workflow processes. In Proceedings of the 1st KnowTech Forum, September17th-19th 1999, Potsdam, 1999. Related languages (older or newer versions, variants, ...) XML Process Definition Language (XPDL). Analysis for Enterprise Interoperability § How this EML supports Enterprise Interoperability? Workflow process interoperability, used to support process invocation on a remote workflow service: · Workflow Interoperability - Abstract Specifications (WfMC-TC-1012) · Interoperability - Internet E-mail MIME Binding (WfMC-TC-1018) There are two accompanying documents: · The Resource Model (Organisational Model: WfMC TC-1016-O) currently being revised · The representative business example (WfMC TC-1016-X) explaining the use of WPDL. Comments Actually XPDL “replaces” WPDL, and the accurate materials concern XPDL. 6.3.12 XPDL from the WfMC Summary The WfMC has identified five functional interfaces to a workflow service as part of its standardisation program. This specification forms part of the documentation relating to “Interface one” - supporting Process Definition Import and Export. This interface includes a common Meta-model for describing the process definition (this specification) and also an XML schema for the interchange of process definitions. Authority § Workflow Management Coalition (WfMC) General references (Public) http://www.wfmc.org Constructs and syntax definition (bibliography references and urls) XPDL uses an XML-based syntax, specified by an XML schema. The main elements of the language are: Package, Application, Workflow- Process, Activity, Transition, Participant, DataField, and DataType. The Package element is the container holding the other elements. The Application element is used to specify the applications/tools invoked by the workflow processes defined in a package. The element WorkflowProcess is used to define workflow processes or parts of workflow processes. A Patterns and XPDL 4 WorkflowProcess is composed of elements of type Activity and Transition. The Activity element is the basic building block of a workflow process definition. Elements of type Activity are connected through elements of type Transition. There are three types of activities: Route, Implementation, and BlockActivity. Activities of type Route are dummy activities just used for routing purposes. Activities of type BlockActivity are used to execute sets of smaller activities. Element ActivitySet refers to a self contained set of activities and transitions. A BlockActivity executes such an ActivitySet. Activities of type Implementation are steps in the process which are implemented by manual procedures (No), implemented by one of more applications (Tool), or implemented by another workflow process (Subflow). The Participant element is used to specify the participants in the workflow, i.e., the entities that can execute work. There are 6 types of participants: ResourceSet, Resource, Role, OrganisationalUnit, Human, and System. Elements of type DataField and DataType are used to specify workflow relevant data. Data is used to make decisions or to refer to data outside of the workflow, and is passed between activities and subflows. Semantic definition (bibliography references and urls) DA111-SotA-v1.0 PUBLIC Page 115 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 The Meta-Model describes the top-level entities contained within a Process Definition, their relationships and attributes (including some which may be defined for simulation or monitoring purposes rather than for enactment). It also defines various conventions for grouping process definitions into related process models and the use of common definition data across a number of different process definitions or models. Tutorials (public references) The quoted WfMC document (The Workflow Management Coalition. Workflow process definition interface – XML process definition language. Technical Report WFMC-TC- 1025, July 2002) contains a didactic example of a workflow representing an order entry system in which an order enters the system as a formatted string. The example is “solved” and the corresponding XPDL schema is displayed. Related languages (older or newer versions, variants, ...) WPDL (Workflow Process Definition Language) Comments Actually XPDL “replaces” WPDL, and the accurate materials concern XPDL. 6.3.13 BPML (from BPMI) See the description of the BMPI initiative in Section 5 “Industry Initiatives, Standardisation Bodies and Organisations working on EM Concepts” for a summary of BPML. 6.3.14 EDOC – UML Profile for Enterprise Distributed Object Computing Specification EML Identifier EDOC (Enterprise Distributed Object Computing) version 1.0 Summary EDOC is an UML Profile (set of stereotypes, tag values and constraints) which provides a modelling framework for describing how objects are used to implement enterprise systems. It is based on UML 1.4 and conforms to the OMG Model Driven Architecture (http://www.omg.org/mda/specs.htm ). See below for further details. EDOC is defined by the Enterprise Collaboration Architecture (ECA) composed of: o the Component Collaboration Architecture (CCA) which details how the UML concepts of classes, collaborations and activity graphs can be used to model, at varying and mixed levels of granularity, the structure and behaviour of the components that comprise a system; o the Entities profile, which describes a set of UML extensions that may be used to model entity objects that are representations of concepts in the application problem domain and define them as composable components; o the Events profile, which describes a set of UML extensions that may be used on their own, or in combination with the other EDOC elements, to model event driven systems; o the Business Process profile, which specialises the CCA, and describes a set of UML extensions that may be used on their own, or in combination with the other EDOC elements, to model system behaviour in the context of the business it supports; o the Relationships profile, which describes the extensions to the UML core facilities to meet the need for rigorous relationship specification in general and in business modelling and software modelling in particular. It also includes a pattern Meta-model used to represent modelling know-how or techniques that help developers to maintain efficiency and consistency in products. In the world of object modelling, many approaches to the use of patterns have been proposed, for example, ”Design Pattern” proposed by E. Gamma et al [Gamma 95], ”Analysis Patterns” proposed by M. Fowler [Fowler 97], or ”Catalysis Approach” proposed by D. D’Souza [D’Souza 99]. In its use of patterns EDOC focuses more on improving sharability and reusability of object models than on assisting modelling efforts by illustrating good modelling techniques. Authority DA111-SotA-v1.0 PUBLIC Page 116 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 Object Management Group (http://www.omg.org ) General references (Public) EDOC specification (ftp://ftp.omg.org/pub/docs/ptc/02-02-05.pdf ) Constructs and syntax definition (bibliography references and urls) EDOC specification Semantic definition (bibliography references and urls) EDOC specification Case Studies (public references) ebXML Business Process Specification Schema (BPSS) (http://www.ebxml.org/specs/index.htm ) Related languages (older or newer versions, variants, ...) UML (Unified Modelling Language) (www.uml.org ), MOF (Meta Object Facility) (http://cgi.omg.org/cgi-bin/doc?ptc/2001-08-25 ) Further Description: This section contains a description of the UML Profile for Enterprise Distributed Object Computing Specification (EDOC). EDOC defines, using the UML extension mechanisms, different constructs in the Enterprise Collaboration Architecture (ECA) framework. This framework comprises five UML profiles which specifies a Component Collaboration Architecture (CCA) , entities objects that are representations of concepts in the application problem domain, events to model event driven systems, business processes to model system behaviour in the context of the business it supports and, finally, relationships profile to meet the need for rigorous relationship specification in general and in business modelling and software modelling in particular. Each profile consists of a set of UML extensions that represent concepts needed to model specific aspects of EDOC systems. The concepts are described in terms of UML profiles. EDOC could help the UEML specification by giving parts of its definitions and meta-models (such as Processes, Events, and relationships). Objective: The vision of the EDOC Profile is to simplify the development of component based EDOC systems by means of a modelling framework, based on UML 1.4 and conforming to the OMG Model Driven Architecture, that provides: o A platform independent, recursive collaboration based modelling approach that can be used at different levels of granularity and different degrees of coupling, for both business and systems modelling. o Modelling concepts for describing clearly the business processes and associated rules that the systems support, the application structure and use of infrastructure services, and the breakdown of the system into configurable components. o An architectural approach that allows the integration of “process models” and “information models.” o A development approach that allows two-way traceability between the specification, implementation and operation of Enterprise computing systems and the business functions that they are designed to support. o Support for system evolution and the specification of collaboration between systems. o A notation that is accessible and coherent. Content: The EDOC Profile is composed by: o A loosely coupled, re-useable business collaboration architecture that can be leveraged by business-to-business (b2b) and business-to-customer (b2c) applications, as well as for enterprise application integration. o A business component architecture that provides interoperable business components and services, re-use and composability of components and re-use of designs and patterns, while being independent of choice of technology (e.g., component models), DA111-SotA-v1.0 PUBLIC Page 117 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 independent of choice of middleware (e.g., message services) and independent of choice of paradigms (e.g., synchronous or asynchronous interactions). The vision addresses key business needs by enabling the development of tools that support: o Business collaborations as a central concern - covering alliances, outsourcing, supply chains, and internet commerce, and dealing with relationships that are in constant flux where what is inside the enterprise today is outside tomorrow, and vice versa. o Process engineering by assembling services - so that basic business functions can remain relatively constant while who performs them and in what sequence changes, and services themselves can become proactive. o The ability for parts of the enterprise to react quickly and reliably to change through: o Shorter development time and improved quality of applications meeting market needs, improved interoperability between systems and support for distributed computing. o Reduced lead time and improved quality resulting from the ability to generate a substantial portion of application code. o More robust specification by removing ambiguity and enabling more rigorous analysis of designs. o A new marketplace for interoperable collaboration based infrastructures and business components. The EDOC Profile provides this modelling framework by defining: o A set of Profile Elements comprising: – A technology independent profile, the Enterprise Collaboration Architecture (ECA) allowing the definition of Platform Independent Models as defined by the MDA. – A Patterns Profile that can be applied in specifications that use the ECA. – A set of Technology specific Models allowing the definition of Platform Dependent Models as defined by the MDA. o A structure for the application of the Profile Elements in the specification of EDOC systems that conforms to the MDA. The Enterprise Collaboration Architecture (ECA) comprises a set of five UML profiles: o The Component Collaboration Architecture (CCA) which details how the UML concepts of classes, collaborations and activity graphs can be used to model, at varying and mixed levels of granularity, the structure and behaviour of the components that comprise a system. o The Entities profile, which describes a set of UML extensions that may be used to model entity objects that are representations of concepts in the application problem domain and define them as composable components. o The Events profile, which describes a set of UML extensions that may be used on their own, or in combination with the other EDOC elements, to model event driven systems. o The Business Process profile, which specialises the CCA, and describes a set of UML extensions that may be used on their own, or in combination with the other EDOC elements, to model system behaviour in the context of the business it supports. o The Relationships profile, which describes the extensions to the UML core facilities to meet the need for rigorous relationship specification in general and in business modelling and software modelling in particular. Each profile consists of a set of UML extensions that represent concepts needed to model specific aspects of EDOC systems. The concepts are described in terms of UML profiles. The enterprise specification of an EDOC system provides the essential traceability between the system design and the business processes and the business domain that are the basis for the requirement for the system. The basis of the enterprise specification is provided by the concepts of the ODP enterprise language (modelled using the ECA (Enterprise Collaboration Architecture defined in EDOC) elements. An enterprise specification models the structure and behaviour of the system in the context of the business organisation of which it forms a part in the following terms: o the business processes supported by the system, o steps in those processes and relationships between steps, DA111-SotA-v1.0 PUBLIC Page 118 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 o business rules (policies) that apply to the steps, o artefacts acted on by each step, o enterprise objects representing the business entities involved, o the roles that they fulfil in supporting the business processes, and o the relationships between roles (including interaction relationships) where roles identify responsibility for steps in the business processes. An EDOC system or each component of that system is modelled as an enterprise object and is assigned a role or roles in the community: hence, it is associated with specific parts of one or more processes. These roles identify the parts of the business processes for which the system is responsible and the artefacts that are involved. Such artefacts and resources represent the information held and acted upon by the system. The central concept of any enterprise specification is that of a community that models a collection of entities interacting to achieve some purpose, which is defined by the objective of the community concerned. Each community is modelled as a configuration of enterprise objects in roles. The EDOC system of concern (or the components of that system) is modelled as one or more of the enterprise objects that are the members of the community. The behaviour of the members of the community is identified by the roles they fulfil, and is defined in terms of a set of actions, each of which may also be modelled as a step of one or more processes. Each process is designed to achieve the objective of the community. Depending upon what it models, an enterprise object may be further refined as a community in a process of recursive decomposition. Policies (business rules) may be associated with any other enterprise language concept and may be expressed in the form of constraints on any concept, or relationship between two concepts. References Unified Modeling Language Specification, Version 1.4, OMG document: http://www.ift.ulaval.ca/~bui/21454_Hiv2003/OMG_14.pdf EDOC UML Profile, final adopted specification, February 2002: http://www.omg.org 6.3.15 UML profile for EAI EML Identifier EML Identifier UML Profile and Interchange Models for Enterprise Application Integration (EAI) Specification Summary The goal of EAI is to ease enterprise application integration thanks to the standardisation of application metadata for invoking and translating application information. Objective: As enterprises adapt to business change and new opportunities, they seek to build on their existing strengths and assets for competitive advantage. This frequently entails building new applications by coupling existing ones, which is known as Enterprise Application Integration (EAI). There is no single mechanism to describe how one application may allow itself to be invoked by another. UML EAI intends to solve this problem by defining and publishing a metadata interchange standard for information about accessing application interfaces. The goal is to simplify application integration by standardizing application metadata for invoking and translating application information. Work done: Enterprise Application Integration (EAI) technology is being promoted to integrate legacy systems with new packages. But integrating legacy applications with new software is a difficult and expensive task due, in large part, to the necessity of customizing each connection that ties together two disparate applications. There is no single mechanism to describe how one application may allow itself to be invoked by another. UML EAI intend to solve this problem by defining and publishing a metadata interchange standard for information about accessing application interfaces. The goal is to simplify application integration by standardizing application metadata for invoking and translating application information. Such connected systems are inherently complex to define and manage. A well-known approach to managing complexity is to define levels of concern. Modelling with UML has been shown to be DA111-SotA-v1.0 PUBLIC Page 119 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 successful at representing differing levels of detail. The appropriate level for EAI is application architecture - the treatment of the interfaces and interactions between applications. UML has been used successfully for modelling at this level, UML EAI can be seen as the best practice for using the existing UML for modelling application architectures, i.e., architectures composed by enterprises to enable application integration. The EAI specification is delivered as a complete MOF-based meta-model and a UML profile. Contents: As said before, the EAI specification is delivered as a complete MOF-based meta- model and a UML profile. In one hand, the EAI Integration meta-model is a specialisation of the Flow Composition Model from the UML Profile for EDOC. The EAI Integration meta-model reuses the concepts of flow, flow node and composition and adds Asynchronous communication, Message queuing, and Message content which are basic required concepts in EAI architectural modelling. It additionally uses the FCM to define as flow components a number of concepts common to the message oriented middleware used in EAI, such as message routing, transformation, and publish/subscribe communication. As is the common practice, the MOF-based meta-model is captured as an object oriented model expressed using a suitably restricted subset of the UML notation. The UML elements used in this specification are: - Classes with attributes and (query) operations. - Binary associations, where composite and navigation adornments are permitted. - Association classes and qualified associations are not permitted - Packages, including nesting and imports - The object constraint language, OCL, for expressing well-formedness constraints In the other hand, the UML profile allows modellers to use UML as a concrete notation for producing EAI models using UML modelling tools which support the UML extensions mechanisms, chiefly stereotypes, tagged values and custom icons. Some tools are available, which can accept a profile definition and configure a modelling tool to force modellers to conform to that profile by using only elements of the UML subset and only the stereotypes, tagged values and icons declared in the profile. A mapping between the meta-model and the UML profile is defined as part of the EAI specification. This is intended as a basis for the development of tools that will transform models expressed using the UML profile into models conforming to the meta-model, and vice versa. The details of the mapping are given as part of the definition of the profile. At this point of the presentation we have to make explicit the relationship of the EAI specification to the four-layered architecture defined by the OMG. MOF is at level 3, so the EAI meta-model is at level 2. The EAI UML profile is also at this level - it is just a set of additional constraints (what stereotypes, tagged values, etc.) on how UML is to be used when notating EAI models. The EAI Meta-model should be thought of as the definition of the abstract syntax of EAI models. An EAI model, which is at level 1, is an expression of this abstract syntax. An EAI model is a specification of the architecture of an event-based system and the allowable information flows through that system. Level 0, then, represents actual behaviours of an event-based system, for example a particular instantiation of the architecture or a particular message flow through that system. These behaviours and instantiations must conform to the specification of behaviour captured by the EAI model. The EAI meta-model is, as already said, MOF compliant. The Meta-model captures the essential EAI concepts. It may also be viewed as the abstract syntax of a language for specifying architectures for enterprise application integration. The meta-model is two fold: - the Integration Meta-model dealing with connectivity, composition and behaviour; - the Common Application Meta-model dealing with interfaces and formats. The EAI Integration meta-model is a specialisation of the Flow Composition Model (FCM) from the UML Profile for EDOC. The following sections make extensive use of terms described in the FCM, and consequently it is assumed that the reader is familiar with it. The UML Profile for EDOC also presents the Component Collaboration Architecture (CCA), part of the EDOC Enterprise Collaboration Architecture. A mapping exists between EAI Integration meta-model and the CCA. The EAI Integration meta-model reuses the concepts of flow, flow node and DA111-SotA-v1.0 PUBLIC Page 120 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 composition. It adds the following basic concepts which are required in EAI architectural modelling: - asynchronous communication - message queuing - message content and format Figure 59 - EAI meta-model for application interfaces It additionally uses the FCM to define as flow components a number of concepts common to the message oriented middleware used in EAI, such a message routing, transformation, and publish/subscribe communication. Business integration technology requires connectors to provide interoperability with existing applications. Connectors support leveraging and reuse of data and business logic held within existing application systems. The job of a connector is to connect from one application system server ”interface” to another; it is not meant for an individual application program. Therefore, an application-domain interface meta-model describes signatures for input and output parameters and return types for a given application system domain (e.g. IMS, MQSeries); it is not for a particular IMS or MQSeries application program. The meta-model contains both syntactic and semantic interface metadata. Figure 59 showing the EAI meta-model for application interfaces enables integration of application components into event-based messaging model including Flow models. The EAI Common Application Meta-model (CAM) consists of meta-definitions of message signatures, independent of any particular tool or middleware. Different connector builder tools can use this information to ensure the “handshaking” between these application programs, across different tools, languages, and middleware. For example, if you have to invoke an MQSeries application, you would need to build a MQ message using data from a GUI tool and deliver it using the MQ API. Similarly, when you receive a message from the MQSeries application, you would need to get the buffer from MQSeries, parse it and then put it into a GUI tool data structure. These functions can be designed and implemented efficiently by a connector builder tool using EAI CAM as standardised meta-models for application interfaces. EAI CAM can be populated from many sources, including copy books, to generate HTML forms and JavaServer Page (JSP) for gathering inputs and returning outputs. An example of a connector as depicted in the previous figure is that the flow and message middleware makes a function call to an enterprise application by calling the connector that then calls the enterprise application API. The connector does language and data type mappings, for example, to translate between XML documents and COBOL input and output data structures based on EAI CAM. Connectors and EAI CAM provide the end-to-end integration between the middleware and the enterprise applications. CAM is a group of interface meta-models that consist of enterprise application interface meta- models, language meta-models and physical representation meta-models. These include C, C++, Java, COBOL, PL/I, Type Descriptor, TDLang, IMS transaction messages, IMS MFS, and CICS BMS, etc. Note that the Java meta-model is defined in the OMG EDOC (Enterprise Distributed Object Computing) submission. CAM is highly reusable and independent of any DA111-SotA-v1.0 PUBLIC Page 121 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 particular tool or middleware. CAM is an incentive to connector suppliers. It reduces work to create and develop connector and/or connector-builder tools. With CAM, tools can now easily access enterprise applications, e.g. IMS and CICS applications; and tools can also access any CAM enabled applications. CAM is used to describe information needed to easily integrate applications developed in common programming models with other systems. CAM can be used for both synchronous and asynchronous invocations. Because CAM also provides physical representation of data types and storage mapping to support data transformation in an enterprise application integration environment, it enables Web services for enterprise applications. In a nutshell, CAM is needed for: - connector and/or connector-builder tools (Development time) - data transformation in an enterprise application integration environment(Execution time) - data type mapping between mixed languages - data translations from one language and platform domain into another - data driven impact analysis for application productivity and quality assurance - viewing of programming language data declarations by developers CAM uses MOF and UML class modelling mechanisms. All CAM models are instances of MOF classes at the M2 level. Casting the meta-model as a UML profile allows EAI architecture models to use standard UML notation. This means that most UML tools (specifically ones which support the extension mechanisms of UML, such as stereotypes and tagged values) can be used to define EAI architecture models. Standard practice for defining UML profiles has been adopted providing a mapping of meta-model classes to their base UML classes, with accompanying stereotypes, tagged values and constraints. Specialised EAI tools will more likely use the meta-model than the UML profile as a basis for storing and manipulating models. The EAI UML profile has been designed to provide the best fit possible with UML, so that the notation is natural for a modeller in the relevant domain (EAI in this case), and fits with one’s general intuitions about the meaning of the elements of UML that are used in the profile. Conclusion: To demonstrate the validity of the EAI approach, some models have been built using the profile to map to practical implementations using generally available products and services. A non-normative mapping to an implementation in JMS ( ”Java Message Service”) has been made. Another non-normative mapping to IBM’s WebSphere MQ (formerly MQSeries) and WebSphere MQ Integrator (formerly MQSeries Integrator) has also been made. This ongoing work around UML EAI seems to be promising but the approaches have to be heavily used to fully demonstrate its powerfulness and usefulness. Possible benefits for ATHENA of UML EAI UML EAI intends to solve the problem of building new applications by coupling existing ones, which is known as Enterprise Application Integration . UML EAI intent to do so by defining a metadata interchange standard for information about accessing application interfaces. Even if the aim is not the same, the EAI specification delivered as a complete MOF-based meta-model can be used as a list of potential solutions for POP* meta- model. Short list of references http://www.uml.org . Authority OMG (http://www.omg.org) General references (Public) http://www.omg.org/technology/documents/formal/xmi.htm : Location of the UML for EAI draft adopted specification document, January 2002. Constructs and syntax definition (bibliography references and urls) EAI Integration meta-model is a specialisation of the Flow Composition Model from the UML Profile for EDOC. It reuses the concepts of flow, flow node and composition. It adds the concepts of asynchronous communication, message content and message format, message queuing, routing and transformation. For more details, see the previous reference where application integration is examined along three axes: integration through connectivity, integration through information sharing and integration through process collaboration). Semantic definition (bibliography references and urls) DA111-SotA-v1.0 PUBLIC Page 122 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 No formal semantics is provided. Semantics is expressed in English. Case Studies (public references) Proof of concepts is provided in the above general reference Related languages (older or newer versions, variants, ...) Unified Modelling Language (UML); UML Profile for Enterprise Distributed Object Computing (EDOC); OMG/Meta Object Facilities (MOF); OMG/Common Warehouse Metamodel (CWM) 6.3.16 ebXML Summary ebXML (Electronic Business using eXtensible Markup Language), is a modular suite of specifications that enables enterprises of any size and in any geographical location to conduct business over the Internet. Using ebXML, companies now have a standard method to exchange business messages, conduct trading relationships, communicate data in common terms and define and register business processes. ebXML Value - Provides the only globally developed open XML-based Standard built on a rich heritage of electronic business experience. - Creates a Single Global Electronic Market Enables all parties irrespective of size to engage in Internet-based electronic business. Provides for plug and play shrink-wrapped solutions. - Enables parties to complement and extend current EC/EDI investment expand electronic business to new and existing trading partners. - Facilitates convergence of current and emerging XML efforts. ebXML delivers the value by - Developing technical specifications for the open ebXML infrastructure. - Creating the technical specifications with the world's best experts. - Collaborating with other initiatives and standards development organisations. - Building on the experience and strengths of existing EDI knowledge. - Enlisting industry leaders to participate and adopt ebXML infrastructure. - Realizing the commitment by ebXML participants to implement the ebXML technical specifications. ebXML was started in 1999 as an initiative of OASIS and the United Nations/ECE agency CEFACT. The original project envisioned and delivered five layers of substantive data specification, including XML standards for: - Business processes - Core data components - Collaboration protocol agreements - Messaging - Registries and repositories Authority OASIS - Open Group : www.ebxml.org · Jamie Clark OASIS Manager for Technical Standards Development [email protected] · Patrick Gannon President and CEO, OASIS [email protected] +1.978.667.5115 x201 General references (Public) DA111-SotA-v1.0 PUBLIC Page 123 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 http://www.ebxml.org/ebxml_resources.htm Constructs and syntax definition (bibliography references and urls) Federation SQL & XML Queries Standards Based Secure Cataloguing Federated & Validation Web Accessible Database / of any Directory Content Content Web Server Management ebXML System Extensible Registry Knowledge Event Bus Management System Content based Taxonomy User defined Server publish/subscribe relationships Event Notification User defined taxonomies, between Content classification content Figure 60 – ebXML Registry The ebXML registry is: - Run time usage – not only design time o Metadata registry, content repository o Controls access, secures content o Manages XML schema, vocabulary o Enables eForms based workflow DA111-SotA-v1.0 PUBLIC Page 124 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 Traction XML W3C SOAP SOAP Market Adoption ebMSG v1.1 v1.2 v2 OASIS WSDL WSDL v1.1 v1.2 eb Reg v2 W3C OASIS UDDI UDDI v2,3 v2,3 OASIS SGML ISO Proprietar JC Consorti SDO y V a Sanction Open Standardization Figure 61 - ebXML Standards: Open & Adopted ebXML Registry Specifications: - Publish and discover web services - Basic identification - Industry classification - Technical capabilities - Search capability - Retrieval of business process, business document, and business profile objects in repositories ebXML Messaging Services Specifications: - Flexible message payloads - P2P & conversational / transactional messaging - Sophisticated security - Sophisticated reliability - Integrated with open security, authentication, process, and related standards / functions ebXML CPP/CPA Specifications: - Describe the web service - Information about service name and parameters, and how to invoke - Information about organisation’s role in service context - Error handling and failure scenarios Case Studies (public references) http://www.ebxml.org/case_studies/index.htm Standards bodies and industries supports - eBES - ebXML.org.tw - e centreUK - Korea Institute for Electronic Commerce - Open Applications Group - Open Travel Alliance - RosettaNet - Tradegate ECA DA111-SotA-v1.0 PUBLIC Page 125 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 6.3.17 PIF – Process Interchange Format EML Identifier Process Interchange Format Version 1.0 Summary A PIF process description consists of a file of objects, such as ACTIVITY, ACTOR, and RESOURCE objects. Each object in the file has a unique id that other objects can use to refer to it. Each object type (or class) has a particular set of attributes defined for it; each attribute describes some aspect of the object. For example, an ACTOR object has a Skills attribute listing the actor's skills. Object classes fall into a class hierarchy (see Figure 62). Each object class has all of the attributes of all of its superclasses, in addition to its own attributes. For example, all PIF objects have a Name attribute, since the class at the root of the PIF hierarchy (ENTITY) has a Name attribute. When an attribute of one object has another object as its value, the attribute represents a relationship between the two object classes. For example, an ACTOR's Skill attribute takes SKILL objects as values, so Skill represents a relationship between the ACTOR and SKILL classes. Figure 62 depicts the relationships among the PIF classes. The PIF hierarchy has grown out of the efforts of the PIF Working Group to share process descriptions among the group members' various tools. We have used the following guidelines in developing this hierarchy: · Generality is preferred over computational efficiency when there is a trade off, for the reason that PIF is an interchange language, not a processing language. Therefore, the organisation of the object classes is not necessarily well-suited to performing any particular task such as workflow management or process simulation. Instead, our goal has been to define classes that can express a wide variety of processes, and that can be readily translated into other formats that may be more suitable for a particular application. · The PIF constructs should be able to express the constructs of some existing common process representations such as IDEF or Petri Nets. · PIF should start with the minimal set of classes and then expand only as it needs to. The minimal set was decided at the first PIF Workshop (October 1993) by examining those constructs common to some major existing process representations and to the process representations used by members of the PIF Working Group. · Additions to the standard PIF classes could be proposed by anybody, but the proposal must be accompanied by concrete examples illustrating the need for the additions. The Working Group decided, through discussions and votes if necessary, whether to accept the proposal. PIF allows groups to define local extensions at will, so new classes or attributes should be added to the standard PIF classes only if they seem to be of sufficiently general usefulness. DA111-SotA-v1.0 PUBLIC Page 126 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 The current PIF class hierarchy is by no means complete and is still under development. For more detail see http://ccs.mit.edu/pif5.html . Figure 62 - The PIF class hierarchy Figure 63 - Relationships among PIF classes Primitive value types The value of an attribute in a PIF object is either the unique identifier of another PIF object or a literal value of one of the following primitive PIF value types · NUMBER: A numeric value. The NUMBER type is subdivided into INTEGER and FLOAT types. · STRING: A sequence of characters. DA111-SotA-v1.0 PUBLIC Page 127 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 · SYMBOL: Symbols are denoted by character sequences, but have somewhat different properties than strings. PIF symbols are a much-simplified version of symbols in the Lisp programming language (Steele, 1990). In PIF, the main difference between strings and symbols is that symbols are not case-sensitive unless specially quoted, but strings are always case-sensitive. · RESTRICTED-KIF-SENTENCE: A logical expression that may include quantifiers as well as the more common Boolean operators. This type is named as it is because the expressions PIF allows are a subset of those allowed in KIF, a logic-based knowledge interchange format. Appendix A has more details on KIF. Authority § PIF Working Group : To contact the PIF Working Group send mail or write to: Jintae Lee Associate Professor, Information Systems Univ. of Colorado, Boulder. CO 80303 Tel: 303-492-4149 Fax: 303-492-5962 E-mail:[email protected] General references (Public) Genesereth, M. & Fikes, R. (1992). Knowledge Interchange Format v.3 Reference Manual. Available as a postscript file via anonymous ftp from www-ksl.stanford.edu:/pub/knowledge- sharing/papers/kif.ps. Gruber, T. (1993). Ontolingua: A translation approach to portable ontology specifications. Knowledge Acquisition, 5(2), 199-200. Available via anonymous ftp from www- ksl.stanford.edu:/pub/knowledge-sharing/papers/ongolingua-intro.ps Lee, J. & Malone, T. (1990). Partially Shared Views: A scheme for communicating between groups using different type hierarchies. ACM Transactions on Information Systems, 8(1), 1-26. Neches et al. (1991). Enabling technology for knowledge sharing. AI Magazine, 12(3), 16-36. Steele, G. (1990). Common Lisp: The language. Second edition. Digital Press. Constructs and syntax definition (bibliography references and urls) Jintae Lee, Gregg Yost and the PIF Working Group, The PIF Process Interchange Format and Framework, Version 1.0, December 22, 1994. http://ccs.mit.edu/pif7.html Case Studies (public references) Jintae Lee, Gregg Yost and the PIF Working Group, The PIF Process Interchange Format and Framework, Version 1.0, December 22, 1994. http://ccs.mit.edu/pif8.html 6.3.18 UEML Short Description The main objective of the UEML - Unified Enterprise Modelling Language is to provide industry with a unified and expandable enterprise modelling language. The concept of UEML was born in 1997 in the frame of ICEIMT (Torino conference) organised in cooperation with NIST. The UEML Thematic Network project (2002 – 2003) was actually the first concrete action to develop UEML involving key Research Centres and some European solution providers in the domain of Enterprise Modelling. The following results are relevant: Ÿ Framework to evaluate enterprise modelling methodologies Ÿ Requirements for constructs and methodologies Ÿ First set of Enterprise Modelling constructs Ÿ Demonstrator (for model exchange between different tools) Type of Integration DA111-SotA-v1.0 PUBLIC Page 128 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 UEML followed an unified approach. In fact until today only some parts of process models are integrated Link www.ueml.org Industrial Use The UEML project elaborated only a demonstrator for showing the feasibility. So the UEML concepts are not used in the industry. Strength In the UEML project a wide community in Europe were build up representing: · Standardisation · Consultants · Research Organisations · Initiatives · Vendors · Industrial and public end users · European Projects · Professional Organisations The community is involved into the next activities in the Network of Excellence “INTEROP”. The UEML meta model is the first attempt to focus on ENTERPRISE models instead only on information models. So additional aspects like products are integrated. Weakness The concept to exchanging enterprise models via standardised interfaces between different enterprise modelling tools leads to loose information by executing model exchange through direct interfaces. The following figure illustrates this gap. Because of the complexity of enterprise modelling languages a lot of gaps by following this way are foreseeable. The mapping problem by using direct interfaces like UEML Model A Model B Tool A Tool B UEML Interface UEML currently do not support meta modelling. The UEML meta model is a first draft. Some weak points are inherent e.g. different expression of several information objects relevant for expressing process models. The meta model contains no organisational or product structuring elements as well decisional aspects of an enterprise. The strategy for evolving UEML is today not clear and will be elaborated in the INTEROP project. 6.3.19 Business Process Definition Metamodel Short description The meta-model provides a common language, for describing business processes in an implementation independent manner. This is not to say that the models are abstract from DA111-SotA-v1.0 PUBLIC Page 129 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 execution details, on the contrary it is our aim to describe executable processes, these models are intended to be abstract from the detailed implementation (platform) mechanisms. This shared subset of UML 2.0 also acts as an agreed base for translation to such implementations where required. The adopted UML 2.0 superstructure meta-model provides much of what is required for the definition of business processes (OMG BPDM 04). The status of the meta- model is “final draft”. The initial developers are IBM, Adaptive, Borland, Data Access Technologies, EDS and 88 Solutions. Type of Integration Integrated Approach Link and description OMG BPDM 04: http://www.bpmn.org/Documents/BPDM/OMG-BPD-2004-01-12-Revision.pdf In the following figure the meta-model is described. Strength The large community behind the meta-model will ensure impact in case the POP* methodology relates to the meta-model. On the other hand exists a direct mapping to BPEL4WS and so to runtime models. Very interesting is the compensation construct e.g. for handling situated processes and exceptions Weakness By following BPDM only integrated approaches can be supported. The meta-model gives no solutions for role changes of enterprise object between EM technologies. The BPDM will also only support the business process part of an enterprise model. 6.4 Enterprise Knowledge Spaces To communicate Enterprise Knowledge Spaces (EKSs), their design principles, implementations as visual models using the AKM technology, enabling model-driven solution design, and model-generated workplaces we need to describe core concepts and terms using words that are already in use and having different meanings to different people. People are using the same terms in many different ways, and some new terms and expressions are constructed. Thus it is important to have a common understanding and agreement on how we apply and use terms within our projects. Active Knowledge Models implements types of views from the knowledge dimensions of the major Enterprise Knowledge Spaces described in this sub-chapter. These models are very different from other types of models as shown in figures in section 6.1.9. DA111-SotA-v1.0 PUBLIC Page 130 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 Enterprise Knowledge Spaces are externalised knowledge spaces of four or more knowledge dimensions that contain mutual and complex dependencies of domains and elements in the four dimensions. The dimensions have many knowledge layers and aspects with partly overlapping views. This knowledge spaces are formed according to the AMIS principle. AMIS AKM ED&D EKS OEA techn. • Model-driven • Visual Scenes • AKMii • Model-driven Designs • Visual KC,SE • EKA structures • Task & Rules • Model-integr. Scripting • Evolving meta- • EKA Services systems models • Layered EKA • Generic • Model gen. • POPS methods services • Plug-and-Play Workplaces Figure 64: The AMIS Enterprise Design Principle, the Enterprise Design and Development approach, the Enterprise Knowledge Spaces methodology ,the AKM technology and platforms, and the Operational Enterprise Architectures and Solutions space. The AMIS design principle is the core scientific principle of some 12 scientific discoveries and principles that form the basis for the Active Knowledge Modelling technology and Enterprise Knowledge Modelling methodology 6.4.1 The Innovative Space Authority Computas . Objectives The objectives of the Innovative space implemented as active knowledge models.To support a holistic approach to enterprise design and development, whether the focus is improved or new process, organisation, product or system. To facilitate model-driven design and engineering of solutions within the four main dimensions of this space, see section 4.2.11 for the AKM technology and the implementation of Enterprise Knowledge Spaces. Description The Innovative Space (invent, reuse, test, design and learn)have these main concept: Enterprise Visual Scenes, (Industrial War-room), implemented as: the POPS (Process, Organisation, Product, System) core meta-modelling methodologies. Holistic process and task modelling is underway, but the EMEA methodologies need re-engineering and re- implementation. The innovative scene manages continuous change in product, process and organisational structures of the Enterprise Knowledge Architecture (EKA). Representation See the figure of the POPS knowledge dimensions of the Enterprise Innovative Knowledge Space in section 4.2.11. This will be developed in the A1 project. DA111-SotA-v1.0 PUBLIC Page 131 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 References See Computas web-sites: www.akmii.net and papers presented at CE 2003 and CE 2004. See also DA 1.3.1 and DA 1.5.1 for implementations based of the Innovative Knowledge Space abbreviated POPS. Implications for ATHENA Enterprise Knowledge Spaces are key knowledge concepts for the future of EM, and the implementation of the Innovative Knowledge Space is key to implementing reflective views, recursive work process and flows, repeatable task, and replicable meta-models. 6.4.2 The Business Operational Space Authority Computas AS Objectives The objectives of the Innovative space implemented as active knowledge models.To support a holistic approach to enterprise design and development, whether the focus is improved or new process, organisation, product or system. To facilitate model-driven design and engineering of solutions within the four main dimensions of this space, see section 4.2.11 for the AKM technology and the implementation of Enterprise Knowledge Spaces. Description The Business Operational Space (Pursue, Bid, Negotiate, contract, Develop, Deliver, Maintain and Support) have these main concepts:: Business Visual Scenes, (Collaborative Views), implemented as Business Operational Models, core meta-modelling methodologies. Business Process modelling of multiple competing business processes. Representation The knowledge dimensions of the Business Operational Knowledge Space has these four main dimensions: Business Strategy, Portfolio Management, Platform-family and Solution- space. Each enterprise will concurrently be involved in many business processes, so services must support the extension and adaptation to competing business projects and opportunities. This will require not just top-down business process modelling and bottom-up task and component modelling, but also middle-out Services composition and packaging. References See Computas web-sites: www.akmii.net and papers presented at CE 2003 and CE 2004. See also the Computas BPM template at www.computas.com Implications for ATHENA Enterprise Knowledge Spaces are key knowledge concepts for the future of EM, and the implementation of the Innovative Knowledge Space is key to implementing reflective views, recursive work process and flows, repeatable task, and replicable meta-models. 6.4.3 Other Enterprise Knowledge Spaces There are two more main spaces, see: www.akmii.net, but they are not crucial at this point in time. Implementing the Innovative Space is the focus of the A1 project. 6.5 Some Conclusions for WP A1.3 and WP A1.5 Developments The solutions available today take into account a lot of useful aspects for integrating modelling methodologies. In the following figure, some of the approaches, languages and methodologies for EM are evaluated according to the main criteria: · Scope/Integrated concepts, means the current scope to integrate or federate a large number of enterprise modelling concepts and views in order to allow widely EM tool interoperability DA111-SotA-v1.0 PUBLIC Page 132 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 · Extensibility/Flexibility, means the ability to adapt, exchange or orchestrate technologies to additional modelling concepts, constructs or new relationship types So in the ISO 19439 and connected ISO 19440 (former ENV 12204) a large number of enterprise modelling concepts are defined, but missing is a generic type definition of e.g. classes and relationships. So the meta-model is fixed and not flexible. On the other hand an exchange of current EM tool is today not possible. The reason is the ambiguity because of missing mapping concepts and overlapping constructs (e.g. decision centre and activity) in the meta-model. In ARIS a lot of different constructs are integrated e.g. into the extended EPC. But new concepts have to be integrated by the tool vendor. The METIS AKM approach is the most flexible one. But like ARIS this follows only an integrated approach. But by having the large capabilities for meta-modelling the flexibility is very suitable. The ISO 15745 (application integration) has today the main focus on resource definitions. There are a lot of other dimensions for an enterprise. UEML 1.0 today only supports the process dimension but e.g. without attribute definition. The IMS Mission approach is the only one that supports federated and integrated approaches. The Simulation focus makes this concept limited to the dynamic elements in enterprises. Especially static concepts (decisions, organisations) are not in the focus. The BPDM approach is very interesting in order to relate enterprise modelling closer to the implementation of processes and systems. The focus on business processes makes today the BPDM limited for integrating and federating enterprise models. 100 90 80 ISO 19439 and ISO 70 19440 60 ARIS ISO 50 AKM 15745 40 30 UEML BPDM Mission Approach Scope/Integrated concepts 20 10 0 0 10 20 30 40 50 60 70 80 90 100 Extensibility/Flexibility Figure 65: Evaluation of the given integration technologies The main suggestions for the A1.3 development are: · Support federated and integrated approaches by providing interfaces to a common repository. The interfaces should not be used for model transformation only for viewing in order to keep all information, · Support new ways of thinking. This means to provide rules for improvement and extension of the integrating kernel, · Support different views according to the needs of the enterprise stakeholders, · The views should be derived from one model without additional transformation. The main suggestions for the A1.5 development are: DA111-SotA-v1.0 PUBLIC Page 133 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 · Provide concepts to handle role changes (e.g. from a product state to an event) of enterprise objects · Provide concepts for managing extensions coming from additional EM methodologies or adapted meta models DA111-SotA-v1.0 PUBLIC Page 134 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 7 Methodologies This section analyses and describes the state of the art on methodologies for Enterprise Engineering and methodologies for establishing Model-Driven Collaborative Enterprises. It also includes conclusions that can be inferred from the state of the art with respect to ATHENA. A methodology, generally speaking, defines the process (or a set of structured steps) to follow to model, design and implement enterprise systems. 7.1 Enterprise Engineering using Reference Models Reference models provide enterprises with an initial engineering solution, letting them determine the degree of detail of the model and the business content. Adapted to company-specific requirements, reference models evolve into company-specific models. Reference models can be developed in real- world situations (best practices) or by theoretically, document process know-how. We can distinguish between procedural models or the implementation of standard software, and business models such as for order processing or product introductions. [5] Although reference models are not methodologies themselves, we describe them here because they are re-usable models employed by methodologies. 7.1.1 IEM Reference Modelling Methodology for Simulation in Production and Logistics Reference Model ‘Order Throughput’ The reference model ‘order throughput’ was developed to structure and optimise the order processing and order control processes with regard to processing times, cost structure, quality requirements, resource expenses and the support of information systems. Reference models consist of basic models, example models and modelling rules. Basic models are predefined model structures that can be used to create complete models. The component ‘basic model’ is further detailed into generally accepted modules. All modules can be combined and adjusted to specific tasks. This facilitates the creation of specific models greatly [Mer94]. The reference model is created according to the principle of modularity (cf. chapter 3.4.1). Modules are: · order, product and resource classes, · basic functions and structures of order processing, and · business process structures. Due to the integral study of business processes, product and resource classes are usually defined neutrally. With resources, the main focus is usually on organisational units and the assigned capacities. The structure of order classes is explained in detail in the document. On a general level, the basic functions of order processing represent typical functions of order processing. The basic structures of order processing consist of these basic functions. The structures either represent typical processes, such as order preparation and tracking, or typical organisational forms of order control (centralised or decentralised, push or pull principle). The basic structures are used to model the order processing and control structure of the typical business process structure. The basic structures are oriented at the morphological features of order handling. Based on the class elements all relevant attributes for definition of a simulation model can be fulfilled in an instantiated model. Simulation experiments can be made by using specific simulation tools. Link Mertins, Kai; Jochem, Roland: Quality-Oriented Design of Business Processes Kluwer Academic Publishers, Boston, July 1999 DA111-SotA-v1.0 PUBLIC Page 135 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 Order Classes A ORDER A INTERNAL ORDER A EXTERNAL ORDER A PLAN Functions Order Processing Order has not been the Order has been processed A processed A Basic Structures Process Structures Specific Model of a Company Figure 66: Principle of Modularity of a Reference Model – the Example of the Reference Model ‘Order Throughput’ The reference model is used in several projects done by IPK and partners. Especially the modular structure enables flexible usage and supports model consistency. The modular approach should be used as a framework for the establishing methodology and model management. The patterns can be directly integrated into the POP* repository. 7.1.2 Reference Modelling Methodology with ARIS Reference modelling methodology with ARIS is shown for the process-based configuration of a SAP/R3-System. Figure 67: Individualising reference models[5] DA111-SotA-v1.0 PUBLIC Page 136 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 First, the reference model of the respective business line is determined such as retail, banks, industry, etc. In our example, we have selected the vertical market customer “industry“. Within the vertical market solution, specific business processes are selected, in our example, production, purchasing and sales. In order to obtain customer-specific business processes, unnecessary functions and events dependent upon them are deleted from the processes, illustrated as EPCs. Redlining stores certain rules so business plausibility and dependencies can be observed. For example, if the function “storing“ is cancelled, the Function “releasing from stock“ must be deleted as well. [5] As in process models, other model types such as data models, function models and organisation models can be used for configuring standard software. For example, information objects can be deleted from or added to the standard software data model. Attributes can be deleted or their length can be modified. This information is also passed on to the system, automatically customizing the screens.[5] For example see [7]. 7.2 Enterprise Modelling Procedure In addition to the methodologies described in this report, other approaches such as CIMOSA, GRAI, or IDEF have also developed enterprise modelling methodologies, known as ‘Structured approach’ for GRAI, ‘user guide’ for CIMOSA, etc. It has been considered that the defined ones already give a good overview of the state of the art. 7.2.1 IPK Procedure The following procedure is closely linked with methodology for user enabled modelling. 7.2.1.1 Steps of Brief Modelling Process Step 1 WhichWhich objectobject isis beingbeing consideredconsidered (order,(order, resource,resource, product)?product)? ? Step 2 WhatWhat areare thethe boundariesboundaries ofof youryour chains?chains? Start End Step 3 WhichWhich functionsfunctions dodo modifymodify thethe statestate ofof thethe objectobject (action)?(action)? Step 4 HowHow isis thethe objectobject describeddescribed beforebefore andand afterafter anan action?action? Step 7 Step 5 HowHow isis thisthis functionfunction beingbeing controlledcontrolled ?? Step 6 WhichWhich resourcesresources areare necessarynecessary toto carryingcarrying outout thisthis function?function? Figure 68: The Modelling Process of the Process Chains within the Project 7.2.1.2 Model based on SCOR (Brief Description of a Real Case) The main focus of the project is the communication between companies and its support by IT systems. Therefore the modelling of the order transfer between the enterprises is modelled in more detail than the product transfer (Figure 69). DA111-SotA-v1.0 PUBLIC Page 137 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 INPUT OUTPUT Controlling Planning and Chain Product Figure 69: Process Model for one Enterprise within the Supply Chain The structure of the process model is based on the highest level of SCOR (Supply Chain Operational Reference Model) terminology (Figure 70). So each enterprise within the supply chain is modelled in a similar structure. This will increase the comparability of the different models and also allows a simpler merge of the models into a general overall model. INPUT OUTPUT PLAN PLAN PLAN PLAN Controlling Sourcing Making Delivery Planning and Manage Returns Chain Source Make Deliver Product Figure 70: Modelling according to SCOR The merge and comparability of the models is also supported by predefined class structures. This class structures should clarify common wording for objects and allow evaluation procedures of the model. Examples of the class structures are illustrated in Figure 71 and Figure 72. DA111-SotA-v1.0 PUBLIC Page 138 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 Figure 71: Resource and Product Classes (draft structure) Figure 72: Order (Control) Classes (draft structure) Afterwards, the different process models for single enterprises will be combined to an overall supply chain model (Figure 73) and illustrate a section of the whole supply chain. The real whole model will not be a single sequence. Moreover it will be a network of different customer supply relations. TierTier 3 Tier 22 TierTier 1 INPUT OUTPUT INPUT OUTPUT INPUT OUTPUT Figure 73: Section of the Supply Chain Model 7.2.2 ARIS Procedure At first glance, the ARIS procedural model follows the views and phases of the life cycle defined in ARIS. Using these objects and the respective methods, however, the ARIS procedural model can be implemented in much greater detail. Figure 74 depicts the procedural model as an EPC, consisting of functions and events. DA111-SotA-v1.0 PUBLIC Page 139 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 Project Start Requirements Definition of Control View (EPC) Require- ments Definition of Control View Concluded Create Require- Create Require- Create Require- Create Require- ments Definition ments Definition ments Definition ments Definition of Organiza- of Function View tional View of Data View of Output View Require- ments Definition Concluded Create Design Create Design Create Design Create Design Create Design Specification Specification Specification of Organiza - Specification Specification of Function View tional View of Data View of Output View of Control View Design Specifications Concluded Implementation Implementation Implementation Implementation Description Implementation Description of of Organiza - Description of Description of Description of Function View tional View Data View Output View Control View Project Concluded Figure 74: EPC of an ARIS procedural model draft [5] The ordering relationships enable the function, organisation, data, output and control views, respectively, of a single phase to be executed simultaneously. The requirements definition begins with the control view, i.e., a description of the process. When dividing the processes into small and specific steps, overlapping of detailed areas is possible. Within the processes, various detailing levels can be determined; however, it should be understood that a rigid phased concept, such as in a waterfall model, is not binding. Rather, development forms, such as prototyping, can be illustrated by certain ordering relationships. In addition to functions and events, other elements of describing processes, such as the organisational units, data and output involved, can be included. Figure 75 depicts the ”create requirements definition of function view”. DA111-SotA-v1.0 PUBLIC Page 140 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 Output View Requirements Requirements Model Definition of Definition of Repository Control View Function View Data View Requirements Create Require- Requirements Definition of ments Definition Definition of Control View Function View concluded of Function View concluded Requirements Personal Modeling Definition Project Computer Group Software Organization View Function View Figure 75: ARIS views of ”create requirements definition function view”[5] · Data views contain the milestones of the procedural model, i.e., events and messages initiating or finishing a process, and of environment descriptions, such as models stored in the model repository. · Function views provide the building blocks of the IT architecture. The respective software, whether it is word processing or modelling tools, is allocated to them. · Organisation views describe the departments, employees and machine resources necessary for the individual processes. · Output views define the inputs and outputs of function execution, i.e., control and function models. The ARIS-House shows the linkage between the different views (see Figure 9 and Figure 10) 7.2.3 EEDO – Extended Enterprise Development and Operations The following document is a brief description of EEDO, developed in the EXTERNAL-project for the formation, delivery, operations, management, and termination of Extended Enterprises (EE). In EXTERNAL, EE is synonymous with virtual or smart organisations, and any future networked organisation. This is a consequence of the integrated methodologies supported by the integrated infrastructure which separates the IT architecture from the enterprise knowledge architecture and the business architecture. The main differences between the EXTERNAL methodology and competing enterprise modelling methodologies are: · It is specifically geared towards the development of extended enterprises. Whereas most methodologies look at the development within an existing organisational reality, the outset of this methodology is rather that one has several existing organisations that go together to be able to provide support for a new, potentially short-lived organisational entity, which is intertwined with existing organisations. That said, most part of the methodology is also relevant for other areas, including the development of solutions within an existing organisation. · The methodology is to a large extent model-driven. Several model driven methodologies exist in e.g. Software Engineering (such as RUP for the use of UML). A main difference is that EEDO is not about developing software, but business solutions based on existing software infrastructure. Hooks to a software engineering methodology is however provided, e.g. when it is necessary to develop additional application services. Another main aspect is that the modelling languages are meant to be updated as part of the development. This is in a way similar to a Domain Specific Modelling (DSM) approach, but these are typically geared to support technical design rather than the development of business solutions. · The methodology is reflexive, including tasks for how it could be adapted to specific cases. The methodology is expressed in EEML (the forerunner of MEML as described above), the same language as is used for developing business process descriptions to be activated in the DA111-SotA-v1.0 PUBLIC Page 141 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 EXTERNAL infrastructure. Hence, methodology with proper specialisation to the project using it, can act as an outset for an active model to support the different phases of EE as this emerges in practice. · The modelling languages and methodology provide constructs to support all traditional objectives of enterprise modelling (see introduction), and are able to combine models at all levels (see levels described in MEML). Most importantly the approach supports the simultaneous modelling, meta- modelling and work based on the modelled solutions. The main methodology-representation is a methodology-browser prototype, being developed as a methodology-model with attached documents for more detailed information. The table below highlights the overall task breakdown structure of the methodology. Note that it is possible to start the use of the methodology at any relevant top-node (i.e. in some cases, one would like to start directly with operation) An ID is used to indicate the structure and positioning of each task, and to make it easier to discuss the content on the task, even if the name potentially changes (e.g. if one want to translate the methodology into another language, or specialises it to a certain context). The view column indicates the main of the parallel and reflective processes of EE development: · Solution-oriented, (SO) with its activities of installation, training, model customisation, integration and EE-solution generation. · EE Infrastructure extension (IX) and refinement. Extensions to the technical infrastructure/software supporting the EE-solution. · EE Methodology application (MT). Includes the methodology customisation process making sure that the methodology reflects the customer solutions and the infrastructure delivered to the customer. Includes also the model engineering and management processes making sure that the evolution of the model, the templates (model languages), the meta-knowledge and the work process solutions are repeatable and re-computable. · PM: Project Management Tasks: Traditional project management tasks. The name below is the same name as is used in the methodology model, where information (description, inputs and deliverables, tool, roles and skills, and planning considerations) and task dependencies are described in more detail. Some modelling tasks act as generic tasks (numbered as G1, G2…). These are reused in several places. ID View Name 1000 Create EE Business Foundation 1100 SO Scope EE 1110 SO Delimit Scope and Level Ambitions 1120 SO Develop EE Business Goals 1300 SO Gather Partner Information 1320 IX Gather Partner Infrastructure Information G1 SO Describe Process Logic 1600 SO Analyse EE Potential 1610 SO Develop As -is EE Architecture 1620 SO Develop Hope-to-be EE Architecture G1 SO Describe Process Logic 1640 SO Perform Solution Analysis G2 SO Engineer Activities G10 IX Install Base EE-infrastructure 1660 PM Establish Business Case 1700 PM Develop EE Proposal 1710 PM Clarify Constraints and Possibilities 1730 PM Write Proposal 1770 PM Communicate with Financing Institution 1790 PM Deliver Proposal 1900 MT Plan and Manage Development of EE Business Foundations 1910 MT Chose Business Foundation Methodology 1920 MT Chose Base Delivery Methodology DA111-SotA-v1.0 PUBLIC Page 142 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 ID View Name G6 MT Adapt Methodology to EE situation 1930 PM Capture and Organise Teams and Roles 1940 PM Identify Resource Needs 1960 PM Organise Resources 1990 PM Finalise and Sign Contract 3000 Deliver EE Solution 3100 SO Model EE G2 SO Engineer Activities 3130 SO Develop EE-requirements G10 IX Install base EE-infrastructure 3300 SO Simulate and Analyse Models 3310 SO Perform Simulations 3320 SO Analyse EE models 3330 SO Choose Solution for Implementation 3600 SO Implement Model 3620 SO Design and Implement Organisation 3630 IX Design and Implement Changes to Technical Infrastructure 3631 IX Develop Technical Infrastructure Requirements 3632 IX Analyse and Update Technical Infrastructure Architecture 3634 IX Design and Adapt Technical Infrastructure Services 3635 IX Select and Reuse Existing Service 3636 IX Implement Technical Infrastructure Services 3637 IX Test Technical Infrastructure Services 3638 IX Integrate Infrastructure Services 3639 IX Test Technical Infrastructure 3640 SO Build Model for Work Management 3650 SO Generate Solution for Work Performance 3652 SO Generate Portal-based User Environment 3655 SO Adapt Portal-based User Environment 3680 SO Test EE-solution 3900 PM Plan and Manage EE Delivery G6 MT Adapt Methodology to EE-situation 3910 MT Adapt Modelling Languages and Tools 3911 MT Develop, Adapt and Manage Modelling Language Constructs 3912 MT Develop, Adapt, and Manage Modelling Domains 3913 MT Develop, Adapt, and Manage Modelling Language 3914 MT Develop, Adapt, and Manage Type-Hierarchies 3918 MT Validate Language Design 3919 MT Manage Access to Modelling Languages 3920 PM Plan EE Delivery 3921 PM Finalise Workplan 3923 PM Finalise Resource Allocation 3928 PM Finalise budgets G11 IX Manage EE Infrastructure 3940 PM Organise Delivery Teams 3960 PM Manage EE Delivery 3961 PM Manage Risk G2 SO Engineer Activities 3963 PM Perform Quality Management 3964 PM Manage Suppliers 3965 PM Manage Issues and Problems 3966 PM Control Scope Changes 3967 PM Manage Business Case G3 PM Manage Work DA111-SotA-v1.0 PUBLIC Page 143 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 ID View Name G8 PM Manage Communication 3980 MT Select Methods for Knowledge Management, System Integration, and Work Management 3990 PM Terminate EE-delivery 3992 PM Finalise and Report on EE-delivery Performance 3995 PM Evaluate EE-delivery 3999 PM Release Resources 7000 SO Run EE 7100 SO Deploy EE-solution 7120 IX Deploy Infrastructure, Processes and Applications G10 IX Install Base EE-infrastructure 7125 IX Install Extended EE-Services 7150 SO Compose and Train Work Management Teams 7160 SO Train EE-workers 7300 SO Operate EE-solution G4 SO Perform Work 7320 SO Manage Service to Customers 7321 SO Establish Service Level Agreements 7322 SO Maintain Agreements 7325 SO Manage Request 7329 SO Report on Service 7340 PM Manage Human Resources 7341 PM Hire EE Workers 7342 PM Train EE Workers 7345 PM Perform Competency Management 7346 PM Evaluate Human Performance 7349 PM Release EE Workers G11 IX Manage EE-infrastructure 7370 IX Manage EE-infrastructure Changes 7371 PM Receive, Analyse and Prioritise Change Requests 7372 SO Perform Process Model Changes 7373 IX Change Parameterisation of User Environment 7374 IX Perform Corrective Maintenance 7374.1 IX Analyse Request 7374.2 IX Design Change 7374.3 IX Implement Changed Services 7374.5 IX Test Changed Services 7374.6 IX Test Technical Infrastructure After Change 7374.8 IX Deploy Change 7374.9 IX Finish Documentation of Change 7377 IX Upgrade Infrastructure Service 7600 SO Evaluate EE-solution G2 SO Engineer Activities G5 SO Manage Process Knowledge 7610 PM Assess Process Maturity 7620 SO Assess Customer Satisfaction 7640 SO Assess EE-worker Satisfaction 7680 SO Implement Improvements 7800 SO Re-engineer EE G3 MT Manage Work G6 MT Adapt Methodology to EE-situation 7910 IX Adapt Infrastructure 7920 MT Specify Work for Individual Roles 7930 MT Delegate and Allocate Work DA111-SotA-v1.0 PUBLIC Page 144 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 ID View Name 7950 MT Schedule Work 7960 MT Co-ordinate Work 7970 MT Supervise and Control Work 7980 MT Perform Work Re-scheduling and Re-allocation G5 MT Manage Process Knowledge 7990 MT Sign-off Completed Work G7 PM Manage Contract G8 PM Manage Communication G9 PM Manage Financials 9000 PM Terminate EE G5 SO Manage Process Knowledge 9200 PM Plan and Manage EE-termination G6 MT Adapt Methodology to EE-situation 9240 PM Release Resources Generic Tasks (i.e. tasks that are reused several places) G1 Describe Process Logic G2 Engineer Activities G3 Manage Work G4 Perform Work G5 Manage Process Knowledge G6 Adapt Methodology to EE-situation G7 Manage Contract G8 Manage Communication G9 Manage Financials G10 Install base EE infrastructure G11 Manage EE Infrastructure 7.3 Business Process Reengineering Methodology Previous business process reengineering approaches tended to focus on a radical change of processes, regardless of the existing structures [8]. Other works stress the need for stepwise and continuous process improvement [9]. What all these approaches have in common is the importance of IT as an instrument for altering processes. In light of the wide range of possible optimisation measures and their complexity, sound procedures and the deployment of appropriate methods and tools plays a major role. 7.3.1 IPK Procedure for Business Process Reengineering The application of a modelling method should not only support single steps of factory planning. It has to guide and support the whole project. Therefore, it is necessary to reveal all aspects which are relevant to clarify weak points, to show potentials for optimisation and their contribution to the objectives of the enterprise. The following modelling phases can be distinguished: · system delimitation, · model design, · model evaluation and utilisation and · model modification. The purpose of the system delimitation is a well-aimed selection and limitation of the model which is to be prepared. It is indicated which enterprise-specific object classes and function areas have to be considered. The motto is ‘fewer equals more’. DA111-SotA-v1.0 PUBLIC Page 145 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 The model design is the phase of the composition of models. In operational planning projects enterprise-specific models are usually used to illustrate the actual state with so-called ‘actual state models’. The model design is carried out in three basic steps: 1. Identification of the relevant enterprise-specific class structures for products, resources and orders within the delimited system; 2. Development of the two main perspectives: information model (identification of the class- describing attributes as far as necessary) and function model (description of functions and processes performed on the objects); 3. Derivation of partial models to clarify relevant planning aspects. In the phase of model evaluation the developed models are identified. The potentials for improvement are estimated and possible suggestions for optimisation are evaluated. Improvement potentials, which can be realised by means of abolishing weak points, should be evaluated according to · the degree of an improved accomplishment of enterprise goals, and · the expenditure necessary to abolish weak points. The phase of model modification transfers the actual state into an ideal state. In general, the extended use of actual state models is far more effective and entails less expenditures. (Figure 76 shows the modelling sequences). For the participants, the results of a model-based business process reengineering project appear to include an effective support of teamwork, a fairly simple opportunity to participate and an easiness to follow and understand the entire project. However, it also has an effect on costs, time demand and quality of the project work and the concepts to be compiled. s m modelling y m o st m o d em o d e phases d el l de el e m li f v o m or a di ita m lu fi ti in a ca on g tio ti project phases n on determination of re- project specification quired model delimita- tion and detail model of goals, i.e. goal determination in a goal tree analysis of the actual state actual state description + main modelling views + inquiry of the actual state + special views analysis of actual + identification of weak points state description comparison: actual estimation of improvement potentials state /goals comparison: actual description of ideal development of concepts state/ideal concepts state description of realization realized state Figure 76: Relation between the Phases of Projects and Modelling Phases Example: Analysis of Potentials To fulfil the objectives of cost reduction as well as lead time and product quality improvements, the process of developing gears in an automotive enterprise is to be optimised. The aim is to utilise potentials which can be revealed through an application of CAD/CAM technologies as information- and communication instruments. It should optimise the overlapping communication between all departments involved in the simultaneous engineering process. In the first step, this should occur with regard to the processes of product development and the simultaneous production design of gears. The expected results included: · the reduction of costs and times to start a new series of products, · the reduction of costs and times to modify the running batch production, and DA111-SotA-v1.0 PUBLIC Page 146 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 · the reduction of the lead times for a newly developed gear by one year. Here, the CAD/CAM development should be realised according to the motto ‘Do what is necessary, not what is possible!’. For the optimisation of the pre-production processes and for a meaningful information management an analysis and understandable description of the overlapping process chains is necessary. For that purpose, IEM was used as a ‘tool’ to represent the actual state and possible ideal concepts transparently. Especially in order to gain the synergies of overlapping or simultaneous processes, a common basis of understanding of all involved departments is necessary in a way which considers all decision-relevant aspects and which relates them to each other. The analysed business processes concerned the departments of development/construction, shop floor planning, work preparation, quality assurance, production and assembly. To identify the demands for an effective and inexpensive production of a new gear as well as possibilities for an intensified early inclusion of the relevant skills the analysis began with the production and assembly. The following procedure was chosen to identify weak points and potentials for the use of know-how and intensified communication: In the first step of the model design, the essential application of specific IEM object classes and the processes for their development and planning were identified and modelled. The following classes were formed: · product class ‘gears’, subdivided into ‘automatic gears’ and ‘mechanical gears’, · product class ‘gear parts’, subdivided into ‘cases’, ‘shaft’, ‘toothed gears’ and ‘mechanical small parts’, and · resource class ‘organisational units’ which execute the functions. The different functions in their logical process, the departments and staff involved in the function execution, the used data documents, the information systems and existing data flows, the average execution times and the data which the production know-how which is regarded as necessary were identified and modelled. Using the detailed models, misunderstandings, contradictions and diverging opinions about the actual process were identified, discussed and eliminated. The result was an adjusted and verified description of the process chains for the product development and the production design from the point of view of the production and assembly departments. Subsequently, corresponding inquiries of the other involved plant areas occurred. The processes could therefore be completed, detailed, clarified and verified. A gradual completion of the process documentation throughout all involved areas took place. This led to a common understanding of the total process. During the entire actual state analysis further models were developed in order to illustrate aspects which during the analysis turned out to be relevant. Examples for documents generated during the actual state analysis were descriptions of: · the logical work flow, · the chronological work flow in a GANTT-diagram, · a matrix for organisational units executing the functions, · a description of data documents and their applications, and · a data flow-diagram describing the communications between the functions. The analysis of the actual state resulted in: · the transparency and common understanding of the entire process chains, · the identification of weak points, · the evaluation of improvement potentials, and · the specification of the necessary data and the data quality necessary to synchronise the execution of functions. The identified weak points were associated with the following subjects: · an early and appropriate distribution of information in the required (data) quality, · a task distribution and delimitation between areas, · an establishment of organisational interfaces, · inquiring and bringing in of know-how beyond department boundaries, and · cooperation of different organisational units. DA111-SotA-v1.0 PUBLIC Page 147 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 Concept and Measure Derivation Based on the actual state analysis two procedures for the development of optimisation concepts and realisation measures were executed in close relation to each other. On the one hand, weak points, their causes and effects were analysed. Corresponding measures to abolish these weak points were derived. Simultaneously, a synchronised ‘ideal scenario’ was prepared in which the approaches of Lean Production and Simultaneous Engineering concepts were adjusted according to enterprise-specific demands. By means of a comparison with the actual state improvement measures were derived from this ‘ideal scenario’. This concept was very effective because it was based on neutral verified models. Especially the constructive discussion on sensitive subjects such as process reorganisation was enabled. Discussing the chronological work flow with the staff of involved departments enabled the identification of ‘time gaps’ and the estimate of effects of ideas for the improvement of the process. The object-oriented approach of Integrated Enterprise Modelling looking at ‘products’, ‘resources’ and ‘orders’ insured a clear separation between the requirements of the development process for a new gear, the requirements for the production means for that gear and the requirements for the resources executing these developments. All measures were estimated with regard to efficiency, expenditure and feasibility. They were listed according to priority. Examples for these measures included: · an agreement on advanced standards, modalities and structures for the optimised, more intense use of CAD/CAM in production planning processes. The departments and employees to be involved, their information requirements and the necessary support through information systems could be determined in detail; · an agreement on advanced standards, modalities and structures for the optimised application of existing CAD/CAM systems as an information, communication and documentation instrument between the development, the production plant and the supplier; · an early information of the production and assembly departments about intermediate results of developments and an optimised determination of development dates, e.g. for modification stops, for the reduction of development times. The necessary data and data quality as well as the corresponding contact person and communication instruments could be determined; · a concept of the CAD-supported integration of the quality assurance in the processes of product development; · an improvement of the modification management and an early inclusion of relevant know-how carriers to reduce the modification frequency and the processing time for necessary changes. 7.4 User Enabling Modelling Methodology The Integrated Enterprise Modelling Method (IEM) and the business process modelling tool MO²GO are used in the project to have a clear common understanding of the processes. Following the project description as an abstract of the real project illustrates how the members of the organisation learn the usage of modelling for their own work: Therefore a pilot project plays a major role to train the “User Enabled Business Process Modelling”. The training within the organisation is based on a “snow ball principle” to reduce the necessary training effort. The benefits of enabling an organisation to model, analyse and optimise business processes by them self are e.g. short term benefits in operational business tasks. As long term benefits it should be mentioned that the reference model for the whole enterprise is useful for many tasks in the enterprise e.g. such as financial controlling, quality management or change management). Especially the short term benefits can help to increase the acceptance of business process modelling as an advantage for the daily work and future planning in the enterprise. This approach has already been carried out successfully by the IPK. It includes the following main steps and procedures. 1. Project organisation and initialisation: The project starts with the setup of a project group (steering) and a technical group. The project group includes consultants and members of the police. The technical group includes members of each main organisation unit (10 persons). The first step into the project is the definition of an adapted usage of the model elements. This step is important to get a common understanding about the wording within the enterprise specific domain and to have a mapping between application domain and methodology. DA111-SotA-v1.0 PUBLIC Page 148 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 2. Training during the project: The pilot project is used to motivate and train the members of the technical group by the consultants. Additional the members of the technical group get intensive tutorials along the states of the modelling project. The main content are “use of the modelling elements”, “starting a modelling project”, “design of the first level”, “modelling of refinements”, “interview techniques”, “model verification” and “identification of potentials”. An additional training of the modelling tool is not necessary. It is used more or less intuitively. Parallel procedure for concept development and teaching Results: Concept ProjectProject progressprogress Concept definition Analysis + Define Potentials and prioritising Pilot Knowledge library for Development and evaluation of a process orientated critical Methodology for knowledge transfer optimisation processes Teaching:Teaching: analysis--,, processprocess design,design, evaluation,evaluation, projectproject Staff is able for management active process management 3. Motivation: The first project results of clearness and usage of processes are used to motivate the members of the project and technical group. They get an idea about benefits but also about necessary know-how and effort. 4. Visualisation and distribution of processes: The process flows related to an organisational unit are put up within this organisation unit by a member of the technical group. This person is available for the staff of the organisation unit to answer questions about the process descriptions. The members of the organisation unit are invited to make comments and recommendation about the model. 5. Presentation of the pilot project: The pilot project is presented to the organisation. 6. Partial projects: The members of the technical group receive self standing small modelling tasks. The results are discussed together with the consultants. 7. Projects initialised by the members of the project group: The members of the technical group work in complex projects. The “snow ball principle” is initialised and runs by invi ting the process owner of the organisation units to do small modelling tasks. 8. Derive different views according to the roles and competencies A process assistant represents relevant business processes, organisations and systems as html text with links to a graphical viewer the. By deriving reflective views the enterprise stakeholder is able to surf through the enterprise without need for special modelling knowledge. DA111-SotA-v1.0 PUBLIC Page 149 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 Project results: The organisation is able to run own modelling projects (technical group). Members of the organisation units use modelling to support their daily work. The organisation can realise the potentials identified during the pilot project. In order to review the impact of enterprise modelling into the business one year after finishing the initial modelling project the use of modelling should be analysed. In the following figure a partial result of a real example is explained. So mainly to analyse, coordinate and execute processes or new business structures between the enterprise and external organisations were supported by enterprise modelling. More than 50% of the users involved in modelling stated “EM” is very useful to support the business. Use of Enterprise Modelling 12 Month after initial project finished 3 direct defined To be models 19 Projects with MO²GO 9 12 Implementation To be models or to 18 be concepts As is Models 24 Projects From 24 6 Org. 18 Projects are: internal External The relevance for the ATHENA project is that this approach can be an initial input especially for the WP A1.4 Establishing Methodology. The steps to motivate the enterprise participants for modelling could be integrated into the maturity and scalability framework. Especially scalability levels according to the involved roles and their capabilities have to be defined. 7.5 Capability and Maturity Models Capability and maturity models allow a company to assess and improve its capacity in a certain field. The focus of capability and maturity models is on the definition of the roadmap to improve a certain ability of the company. In ATHENA, the focus will be on interoperability and for this end a set of capability and maturity models will be described. These models are included in the section related to methodologies because they are considered as reference models for defining “establishing methodologies”, this is, they are a reference point for defining the process to establish Model-Driven Collaborative Enterprises. 7.5.1 CMMIÒ - Capability Maturity ModelÒ Integration Authority SEI (Software Engineering Institute). Objectives This model is focused on assessing and improving performance in software engineering, systems engineering, integrated product and process development and supplier sourcing. Ò CMMI is registered in the U.S. Patent and Trademark Office by Carnegie Mellon University. Ò “Capability Maturity Model” is registered in the U.S. Patent and Trademark Office by Carnegie Mellon University. DA111-SotA-v1.0 PUBLIC Page 150 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 Description CMMI defines process areas inside an organisation and a set of objectives and best practices for each area. Each of the bodies of knowledge identified above is considered as a “discipline”. CMMI is an evolution of previous maturity models based on CMM, namely: - The Capability Maturity Model for Software (SW-CMM) - The Systems Engineering Capability Model (SECM) - The Integrated Product Development Capability Maturity Model (IPD-CMM) CMMI has integrated all these approaches and established four disciplines drawing on these previous models. Representation Staged model This model uses predefined sets of process areas to define an improvement path for an organisation. This approach is the one used by the CMM and establishes maturity levels that are applied to a given set of processes. It is a static approach that is adequate if you don’t know which processes to improve. The identified maturity levels are the following: initial, managed, defined, quantitatively managed, and optimizing. Continuous model This model allows an organisation to choose a specific process area and improve it. This approach is the one used by the SECM and the IPD-CMM and uses capability levels that are applied to an individual process area. It is a flexible approach as it allows selecting the processes you want to improve. The identified capability levels are the following: incomplete, performed, managed, defined, quantitatively managed, and optimizing. References http://www.sei.cmu.edu/cmmi/ Implications for ATHENA This model will be very useful as a source for the structure of the maturity model that will be developed in ATHENA. The possibility to include the maturity model developed in ATHENA as a CMMI discipline. 7.5.2 E-Business Maturity Model – EMM@ Authority PricewaterhouseCoopers and Carnegie Mellon University. Objectives This model is focused on helping organisations to identify and manage the risks associated with implementing new and emerging technologies. Description EMM@ is based on a best practices knowledge base of over 1200 cases and a framework that incorporates nine functional domains which it addresses: security, legal, tax, delivery and operations, systems and technology, performance management, processes, organisations and competences, and strategy. The model offers best practice recommendations that address business issues within each domain. Representation EMM@ identifies five e-business growth stages: online presence, online business, integrated online business, fully integrated e-business and continuous evolution. This representation applies to a given set of processes and establishes different maturity levels. The attainment of a maturity level implies the fulfilment of a certain set of practices for the processes specified in that level and sets the foundation for the next level. References http://www.pwcglobal.com/ http://advisor.com/doc/05900 Implications for ATHENA This model could be useful for the definition of the maturity stages. DA111-SotA-v1.0 PUBLIC Page 151 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 7.5.3 IT Architecture Capability Maturity Model - ACMM Authority US Department of Commerce. Objectives This model is focused on enhancing the overall odds for success of IT Architecture by identifying weak areas and providing a defined evolutionary path to improving the overall architecture process. Description The ACMM comprises three sections: the IT architecture maturity model, the IT architecture characteristics of operating units’ processes at different maturity levels, and the IT architecture capability maturity model scorecard. The first two sections explain the Architecture Capability Maturity levels and the corresponding IT Architecture characteristics for each maturity level to be used as measures in the assessment process. The third section is used to derive the Architecture Capability Maturity level that is to be reported to the Department of Commerce Chief Information Officer. Representation The ACMM consists of six levels that go from no IT architecture program definition to the continuous improvement of the IT architecture process. These levels are defined in a growing IT architecture development basis. The levels are none, initial, under development, defined, managed and optimizing. References https://secure.cio.noaa.gov/hpcc/docita/files/acmm_complete.pdf Implications for ATHENA This model could be useful for the definition of the maturity stages. 7.5.4 Web Presence Measurement Model. Authority United Nations. Objectives This model is focused on measuring the generic aptitude of governments to employ e- government as a tool to inform, interact, transact and network. Description The Web Presence Measurement Model is part of the E-Government Readiness Index that measures generic capacity of the government to use ICT to offer services to citizens. This model is used as a Web Measure Index together with a Telecommunications Infrastructure Index and a Human Capital Index. Representation The Web Presence Measurement Model is a quantitative five-stage model, ascending in nature, and building on the previous level of sophistication of a government’s online presence. The stages are the following ones: emerging presence, enhanced presence, interactive presence, transactional presence, and networked presence. References http://unpan1.un.org/intradoc/groups/public/documents/un/unpan012733.pdf (p. 76) Implications for ATHENA This model could be useful for the definition of the maturity stages. DA111-SotA-v1.0 PUBLIC Page 152 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 8 Modelling Platforms, Infrastructures and Tools This section describes Enterprise Modelling platforms, infrastructures and/or tools. In addition to the tools described here, many other modelling tools also exist in the market, for example, there are a lot of Business Process modelling tools. Looking at the languages described previously, we have already mentioned CIMOSA based tools, IDEF based tools, etc. The ones described here are a good example of the state of the art in this aspect. 8.1 MO²GO Enterprise Fraunhofer Institute: Production Systems and Design Technology(IPK-Berlin) Contacts Division: Corporate Management Leader: Prof. Dr.-Ing. K. Mertins Fax: 030/393 25 03 Pascalstr. 8-9, 10587 Berlin Dipl.-Inform., Dipl. Ing. Frank-Walter Jäkel Tel.: +49/30/39006-174 E-Mail: [email protected] System MO²GO Version 2.4b MO²GO Macro Editor Version 2.1 MO²GO Viewer Version 1.07 and Process Assistant MO²GO WEB Publisher Version 1.0 Application Domain · What are the areas where the tool is use MO²GO is a software tool for representation, analysing and optimisation of enterprise structures and business processes. The program is used in all kinds of enterprises (small, medium, large). A comfortable description and efficient analysis of products, resources, orders and therefore needed business processes is reached through the graphical interface of MO²GO. Alternatives of design and optimisation can easily be compared. · Sectors where it is use The system is used in production companies, service enterprises, government services (e.g. police) and in the health sector. · Domains where it is use Enterprise Engineering, Quality Management, Organisational Analysis, Knowledge Management, Process Benchmarking, IT System Introduction (ERP, Engineering Systems, etc.), Requirement Analysis and Motivation for IT System usage, Supply Chain Analysis, Supply Chain Network Analysis, Enterprise Network Building, Supply Chain Building, Enabling of SME for Acting in Networks, Information Collecting for different analysis like simulation, Process Owner Participating Modelling or Modelling by Process Owners, Harmonisation of Distributed Enterprise Processes, Functional Specification for Manufacturing System Engineering Vendors, etc. Platform · Platform independent components The MO²GO Viewer can be executed in the Internet-browser Netscape and MS Explorer. Precondition is the Java Plug-In of SUN in the Version 1.3.1_02 or higher. The MO²GO Viewer can be also executed standalone on different platforms the precondition is a actual SUN Java version. The Process Assistant generated by the MO²GO WEB Publisher only requires a WEB Browser. · Platform specific components The MO²GO core component requires MS Windows (Win95/98/ME/NT/2000/ and higher). More flexibility in the platform for this component is under development and will be available at late 2005. The actual MO²GO Version requires a 486’er PC or higher and at least 32 MB main DA111-SotA-v1.0 PUBLIC Page 153 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 storage and about 50 MB hard disk. The required storage depends on the size of the model. The MO²GO Macro Editor requires MS Windows (Win95/98/ME/NT/2000/ and higher). Internet / Intranet Browser capabilities The MO²GO Viewer and MO²GO Assistant runs within WEB browsers. The viewer runs as Java applet and the Assistant is generated as a “html” application. The XM L export format form MO²GO to the WEB publisher allows also the connection to content management systems. Distributed Projects MO²GO contains export- and import mechanisms for partial models, as well as the possibility to define a master model. These mechanisms allow the definition of partial projects. Projects can be processed independently and later be brought together to one complete model. Check in and Check out mechanism are actual under development and will be available by the end of 2004. Distributed modelling on one model at the same time is available for the Beta Version of MO²GO NG. This requires a network connection of each partner in the modelling process. Therefore, the customers prefer the check-out/check-in mechanism which allows distributed modelling without network connection. Modelling Method Integrated Enterprise Modelling (IEM) methodology including the procedures for modelling. Enterprise Modelling Language MO²GO is based on the method: Integrated Enterprise Modelling (IEM). Therefore the basic classes for products, orders and resources exist, which can be detailed optional (e.g. resource classes for organisation units to illustrate the organisational structure of an enterprise). Process chains are defined by using the action element and the connecting elements (join, split, decision). IEM includes a language which is similar to coloured, attributed and channelled Petri networks. However, it is its own language like EPC. Project Procedure - definition of the project targets (operational targets)· - identification of the relevant types of objects (products, orders, resource) and the objects themselves· - delimitation of the system (input states and output states of the objects)· - modelling of the processes· - classification of the needed resources (organisational units, documents, IT systems, machines, ...)· - classification of the needed orders - discussion about the model with the process owners responsible for the process The process is in several stages an iterative process. Interface The MO²GO macro language permits an easy definition of interfaces to other programs. On this basis interfaces exist e.g. with MS Office and accounting systems. Further on, there is an interface for the configuration of distributed simulation scenarios based on the High Level Architecture (HLA). A XML interface including a schema definition (XSD) allow the information exchange via XML. Executable attributes allows the call of programs as well as of MO²GO macros from a MO²GO model. Evaluations MO²GO allows the calculation of performance indicators (i.e. costs and times). A detailed analysis within MO²GO is supported by process indicator lines. This technique allows the analysis of processes on the basis of manufacturing order data and performance data. It delivers the bottleneck resources and the throughputs of the process model on all process levels. The macro language delivers possibilities to define additional evaluation mechanism. Therefore, it exist additional evaluation tools for MO²GO on the customer side. An example is the IOM tool set. MO²GO models are also used to derive simulation models based on the information captured DA111-SotA-v1.0 PUBLIC Page 154 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 in the MO²GO model. Adaptation (Macro Language) The programming takes place in the macro language of MO²GO. It permits the access of all model data and can be used for calculations, data access, etc. The import/export of data from other systems can be realised via macro language. Class structures containing macro operations can be integrated into existent MO²GO models. For example operations for organisational units, documents, or processes (like the generation of organisational handbooks or the accounting of process indicators) can be defined. The MO²GO macro language is a powerful mechanism to extent and adapt the features provided by MO²GO and the MO²GO macro editor provides a development environment to design macros. However, the adoption is also supported by the MO²GO meta-modelling which allows the definition of additional classes. This classes can be used within the model as additional modelling elements. The visual representation of these elements can be defined via “jpg”. Service The service offer contains the following training: ? IUM/MO²GO Introduction and Advancement· ? Training for special usage: business planning, quality management, organisational structures, environmental management, Knowledge management, etc. With MO²GO the following consulting projects are supported by IPK-Berlin: Planning of business processes, preparation for certification, choice of IT concepts, organisational development, harmonisation of distributed businesses, business process analyses, knowledge management and benchmarking, business strategy and time planning, supply chain management, system of reference numbers (score numbers). Features The Integrated Enterprise Modelling (IEM) is a holistic methodical basis for modelling of business processes. The IEM/MO²GO models are of high transparency and easy to understand. There is no need for large-scale training to handle the models. MO²GO allows a very fast model building process. So that modelling is possible simultaneously to interviews directly on the computer. MO²GO permits a flexible adaptation to the problem domain and the needs of projects. E.g. for processes and objects the user can define his products, orders and resources and then use them during the business process modelling. The process model can be specified as much (deep) as desired. Own attributes can be created and evaluated freely. References to main literature Spur,G;,Mertins,K.;Jochem,R.: Integrated Enterprise Modelling, Berlin, Wien, Zürich Beuth, 1996. Mertins,K; Jochem,R.: Quality-Oriented Design of Business Processes. Boston: Kluwer Aca- demic Publishers, 1999. Bernus, P. ; Mertins, K. ; Schmidt, G.: Handbook on architectures of information systems, Berlin : Springer, 1998, (International handbook on information systems) ISBN 3-540-64453-9, S.589-600. Jochem, R.; Uhlmann, E.: Integrierte Unternehmensplanung auf der Basis von Unternehmensmodellen , Stuttgart: Fraunhofer IRB Verlag, 2001, III, 155 S. : Ill. Zugl.: Berlin, TU, Diss., 2001, Berichte aus dem Produktionstechnischen Zentrum Berlin, ISBN: 3-8167-5623-9. Analysis for Enterprise Interoperability How this tool supports Enterprise Interoperability? The modelling method within MO²GO does not depend on single enterprises also the relations between enterprises can be represented and can be evaluated. MO²GO models can be modelled independently and combined afterwards. Together with a template approach, MO²GO allows the analysis of complex supply chain networks and the introduction of new “across organisational” services. One example of such an approach is done in the Spider-Win project. Another approach which arises on customer side is the use of MO²GO for functional specifications. The company used MO²GO together with manufacturing system suppliers for defining the supply chain based on the model descriptions coming from the suppliers. This DA111-SotA-v1.0 PUBLIC Page 155 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 was mainly to identify possible interoperability problems and to solve them. The MO²GO XML exchange format allows to exchange models. The Java API of MO²GO NG allows interactions with other tools. How this tool supports Enterprise Modelling of Collaborative Enterprises? Usage within enterprise networks: MO²GO is already used to capture all required processes and discuss them with the network manager and the involved partners (companies) about the supply chain. How this tool could be used in ATHENA, and more specifically in project A1? The MO²GO tool is available for the ATHENA project. Extensions could be realised based on the Macro mechanism or via Java API of MO²GO NG. The Java API is free. Therefore, it can be used by the ATHENA partners. However, it is also possible that IPK supports the fulfilment of ATHENA requirements for the MO²GO tool. Known drawbacks in supporting inter and intra enterprise interoperability. The tool does not address culture problems between organisation which is a big issues also for interoperability. A mechanism within MO²GO which can be used to identify the border between enterprises is already prepared within the tool. 8.2 GraiTools Enterprise Graisoft (Bordeaux, France) Contacts Julien Rossignol: [email protected] User forums: www.graisoft.com/forum System Newest available version: GraiTools v1.0 b040 Application Domain Sectors where the tool is/was used: · Civil Service · Clothing business · Consultancy · Training and research centers · Mechanical engineering · Road safety Domains where the tool is/was used: · Integration of organisation and information systems, · Choice and implementation of enterprise management software packages: ERP, SCM, CRM or I.T. solutions (decisional, …) · Design and implementation of Performance Indicators System · Design, development and implementation of Industrial Strategy · Quality systems deployment · Enterprise Modelling and Re-engineering · Modelling of a Water Control System Platform · Technical hardware requirements GraiTools Server: SQL Server 2k/MSDE 2k running on a PII 233Mhz+ or compatible, IIS4 SP6 GraiTools Client/Standalone: Win32 (Windows NT4/9X/2k/XP), running on a PII 233Mhz+ or compatible, IE5.5 SP2. · Platform independent components Web generated modelsite · Platform specific components GraiTools Server/Client/Standalone DA111-SotA-v1.0 PUBLIC Page 156 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 Internet / Intranet Browser capabilities WebSite generation (XHTML compliant). Distributed Projects Possibilities of simultaneous and distributed modelling: – Client-server distributed modelling – Check-out/check-in paradigm – On-the-fly reservation and concurrent modelling Modelling Method & Language GRAI Methodology GRAI Modules GRAI Language UML Language (class diagrams). Project Procedure GRAI Module dependant. Interface Office tools (MS-Office, OpenOffice, ...): Report generation; CSV/Excel dynamic import (performance indicators). Evaluations Model consistency (syntax checking). System analysis (semantic/expert checking). Adaptation (Macro Language) Properties specialisation. in development: stereotypes (properties and visual aspect). Service Hotline, Training Coaching, User Community (Best practices, user forums). Features Tools: – Model Analyser – Search Engine – Documents/URL attachments – Model annotations (weak/strong points, proof, solutions, risks, notes) Views: – Hierarchical view – Diagram multiviews (elements can be projected on many diagrams) Facilities: – Unlimited undo/redo,clipboard facilities, object aliasing, studio customisation, etc. Analysis for Enterprise Interoperability How this tool supports Enterprise Interoperability? Platform independent business & IT modelling. How this tool supports Enterprise Modelling of Collaborative Enterprises? Distributed modelling. How this tool could be used in ATHENA, and more specifically in project A1? GRAI language meta-model Kernel meta-metamodel (Multiview diagramming concepts). 8.3 Metis Enterprise Enterprise Computas As DA111-SotA-v1.0 PUBLIC Page 157 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 Contacts Marketing and Sales Manager Emilio Marisei; [email protected] Information request; [email protected] Sales request; sales @computas.com System Metis Enterprise version 3.4.7, released June 2004. Got to www.computas.com or www.computas.com for more information on the products set. Application Domain Enterprise Architecture: considered the leading tool-set by customer panels and Gartner Group. Enterprise Asset Management Enterprise Governance and Portfolio Management Business Process Management Visual Project Management Knowledge and Model Management Legacy System and Database Integration Enterprise Design and Development is under development Internet / Intranet Browser capabilities See the B4 portal in the ACP for the use of model views generated from the DRDS knowledge model. Any model may perform data and knowledge input and output to the web. Distributed Projects The Metis Enterprise platform and repository support up to 3000 simultaneous knowledge workers with one of its reference customers. Some workers are handling rather large sub- models and a few are handling the large main model. Modelling Method & Language See previous section for the ITM, BPM,UML, MEML and the GEM templates and reference languages. Customers may build their own languages and templates. Project Procedure Can exchange models and meta-data with other tools, and information and data with other systems. Interface The DIF interface model offer services to interface most modelling tools, legacy systems, e.g. Windows applications, and SQL and Oracle Dtabases. Evaluations Supports many forms for analysis from generic “what-if” to discrete parameter calculations, can also integrate other analysis tools. Adaptation (Macro Language) Provides a Meta-model Developer to adapt, modify and extend existing templates or to build new templates and meta-models on demand. Service Hotline, Extensive Training Program, Model Building, Coaching and Consulting., Metis User Community., see own portal and network services. Features Go to www.computas.com and look at product description. Metis Enterprise is the market leader by customer EA. Evaluations. Analysis for Enterprise Interoperability How this tool supports Enterprise Interoperability? The Metis tools are integrated by a common meta-meta model, which is extended and adapted by the tools. This is a principle for interoperable knowledge elements. DA111-SotA-v1.0 PUBLIC Page 158 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 Metis Enterprise has the expressiveness for developing active models and creating model- driven solutions. DA111-SotA-v1.0 PUBLIC Page 159 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 9 Execution Platforms, Infrastructures and Tools In order to evaluate execution platforms for enterprise models, we must first establish the context and basic terminology where such execution makes sense. Models are defined as explicit representations of some portions of reality as perceived by some actor (Wegner & Goldin, 1999). A model is active if it directly influences the reality it reflects. Model activation involves actors interpreting the model and adjusting their behaviour accordingly. This process can be (Carlsen et al., 1999) Ÿ Automated, where a software component interprets the model, Ÿ Manual, where the model guides the actions of human actors, or Ÿ Interactive, where prescribed aspects of the model are automatically interpreted and ambiguous parts are left to the users to resolve. We define a model to be interactive if it is interactively activated (Jørgensen, 2001; Jørgensen, Krogstie, Ohren, & Johnsen, 2003). By updating such a model, users can adapt the system to fit their local plans, preferences and terminology. This concurrent activation and articulation (modelling) is depicted in Figure 77. Articulation Domain Interactive model Activation Figure 77. The interplay of articulation and activation. Any software that uses the models can be thought of as a model-activating component, whether it works automatically, interactively or manually. Research should investigate the utility of enterprise models in supporting different functions of the system, i.e. which model-activating components (henceforth called interactors) that we can usefully include in the architecture. Examples include: Ÿ Personal work organisation through worklists and workspaces for each task, Ÿ Coordination through interactive process enactment, Ÿ Articulation integrated with rich visualisations in the model editor, Ÿ Coordination through awareness, notifying users about the actions of others, Ÿ Access control, so that each user's assignment to tasks influence which information is made accessible, on a need-to-know or a need-to-hide basis, subject to local policies, Ÿ Communication support for collaborative tasks and negotiations, for informal handling of unforeseen situations etc., Ÿ Warnings when modelled rules are violated, Ÿ Guidance for novice users, taking them step by step through unfamiliar procedures, Ÿ Information management and workspaces for document-centric collaboration, Ÿ Enterprise resource management integrated with personnel allocation to processes, Ÿ Project management functionality, monitoring progress, time, money, and resources. For each of these components the distribution of work between the system and its users needs to be studied. It is unlikely that one solution fits all processes, hence we must facilitate customisation. Though adding details about access control, communication and resource management can make the model more complicated, these difficulties can be helped with visualisations that filter out dimensions from the model. Also, template policies can be offered for different domains, and in many cases be reused with little or no modifications. Anyway, the utilisation of enterprise models to provide a wider range of context-sensitive functionality, removes the overhead of having multiple representations, and increases the users' benefits of keeping the models up to date. An interactive execution architecture makes no separation between build time and run time. Though a model editor and an enactment engine are separate components, they have the same position in the system, that of using and updating the model. The modelling editor's visualisation capabilities can be a DA111-SotA-v1.0 PUBLIC Page 160 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 powerful activation tool, supporting manual coordination by giving users an overview of the current state of the process. In other words, the component conventionally thought of as the process definition tool (WfMC, 2000), also plays a role in model activation. Conversely, users can articulate a process structure through a textual worklist, so conventional activation tools are suitable for process definition as well. Model-executing interactors thus integrate articulation and activation. Figure 78 shows how the core concepts of interactive models (articulation and activation) extend those of workflow management, bridging the gap between modelling/definition and enactment. Articulation Activation Modelling Enactment Figure 78. Core concepts in workflow management and interactive models. An overview of how interactive enterprise model execution platforms complement the fully automatic business process and workflow management approaches is given in Figure 79. To the left of the figure, we find conventional software development approaches, viable for work processes that are repeating and follow a predefined structure. Service oriented architectures raise the level of abstraction, and offer increased runtime flexibility in service discovery and selection, composition and choreography. Business process management and automation are even more flexible, enabling direct execution of business process and workflow models. The level of details that must go into such models to enable a completely automatic execution, implies that they are more low-level than common enterprise models. Enterprise models demand an open, interactive, and partially automated execution framework, in order to allow high-level, incomplete models evolving during execution. Executable Model driven Service Business enterprise architecture oriented process models development development automation Enterprise model (Computation independent model) Enterprise model Platform independent model execution platform Platform specific Business process model execution platform (PSM) Code Web service execution platform (PSM) Programming platform Figure 79. Complementary execution platforms. Given this framework, the following information should be provided for each execution platform. Ÿ What kind of activation support is offered (manual, automatic, or interactive with static or dynamic automation boundaries)? Ÿ If no direct activation support is available, to what extent does the methodology support system development (down to e.g. business process execution or code) as an alternative to live activation? DA111-SotA-v1.0 PUBLIC Page 161 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 Ÿ What kind of model-driven functionality is offered (process enactment, event notification, model- driven user interfaces, model-driven access control, model-driven document management etc.)? Ÿ Who are the target users of the execution tool? Are they also the modellers? Ÿ Does the execution platform allow dynamic changes to enterprise models during execution? Ÿ Does the execution platform handle incomplete models (e.g. by interacting with users to resolve ambiguities)? Ÿ Does the execution platform allow users to adapt modelling languages to their domain (meta- modelling)? Ÿ Does the execution platform allow users to adapt the execution semantics of models, e.g. through policies or user-defined activation rules? Reconsidering Formality The rigidity of current workflow architectures have been attributed both to the formal nature of the modelling languages and to the tight coupling of modelling and enactment. Agostini and DeMichelis (Agostini & DeMichelis, 2000) argue that neither conception is accurate, that simple models, easy to change for process participants, can remain formal and tightly coupled to enactment without causing rigidity. The real problem is not formality, but lack of interaction. Our perspective complements this view with the need for interaction also in model interpretation and enactment. This provides guidelines for avoiding the problems of formalisation while preserving the benefits. To enable automatic error checking, verification, deduction, simulation etc., the modelling language should have a formal definition with syntactic and semantic rules. This definition should however not prevent users from re- interpreting the model in situations that arise. Models should not be required to completely schedule all tasks, or always know which task is the next to be performed. The formal interpretation of the model is just one of many alternatives; it is the one that will be enacted if no further changes are made; it is the context-insensitive interpretation. What is needed is thus a language where complete models can be formalised but incomplete models are also allowed. The interaction framework advocates holistic enactment semantics. It views the model as a system of autonomous components (Wegner & Goldin, 1999). Each component can be formalised, but their interaction, controlled by users, cannot. Hence, the system exhibits emergent behaviour. This behaviour is non-deterministic and irreducible to algorithms, as shown by Wegner (Wegner, 1997). Thus, formality of components need not stop the system from mediating the situated, local, emergent, contingent, vague, and open nature of its environment (Goguen, 1996). This just requires interactive components and semantic holism. Most workflow systems today apply atomic or limited molecular semantics, not holistic. In Petri nets the firing of a transition depends on the presence of tokens on its input places. Some molecular non-determinism can arise when overlapping token sets enables multiple transitions. This is often automatically resolved, or even prohibited as in free-choice Petri nets (W. M. P. van der Aalst, 1999). Some systems however let the users decide (Willumsen, 1993). User Involvement in Enactment A key question that the interaction paradigm puts to workflow designers is how users can be involved in the enactment process. As with other interactive systems, user involvement can be reactive or proactive. Reactive involvement means that the system asks a user to resolve ambiguity in the model. The follow-up questions in this scenario are: Which user(s)? When and how are they asked, and what support are they offered to solve the problem? Proactively, users can involve themselves by complementing or overriding the modelled scheduling of work. An example of this from the workflow literature is opportunistic involvement: That someone starts to work on a task although its inputs are not yet ready (Dourish, Holmes, MacLean, Marqvardsen, & Zbyslaw, 1996). Such proactive actions can be facilitated by awareness notifications (Rodden, 1996) and visualisations (Jørgensen, 2003) of the current state of the process. 9.1 Research Prototypes for Enterprise Model Execution 9.1.1 The EXTERNAL Infrastructure The EXTERNAL project (Extended Enterprise Resources, Networks and Learning, EU IST, 2000- 2002) aimed to support the whole lifecycle of a virtual enterprise, from inception, planning, working, DA111-SotA-v1.0 PUBLIC Page 162 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 management and coordination, to decommission. In the project, interactive models were applied to support three virtual enterprises, in business consulting, software development, and research. The EXTERNAL infrastructure integrates five model-driven tools (Figure 80): Ÿ WORKWARE (Jørgensen, 2001, 2004; Jørgensen & Carlsen, 1999), an interactive workflow and groupware system, providing worklists, process enactment, awareness notifications, access control and document management (all the white components in Figure 80). Ÿ METIS (Lillehagen, Dehli, Fjeld, Krogstie, & Jørgensen, 2002), a general purpose, open enterprise modelling tool, used for building and visualizing rich, up-to-date models of the joint enterprise, fostering common understanding among the participants and enabling them to plan their cooperation. Ÿ XCHIPS (Haake & Wang, 1997), a hypermedia tool with synchronous collaboration and process support. It facilitates real-time collaborative modelling sessions, and also close collaboration in the context of particular tasks Ÿ FRAMESOLUTIONS a framework for building traditional workflow applications, Ÿ SIMVISION (Kuntz, Christiansen, Cohen, Jin, & Levitt, 1998), a process simulation tool, which can be used to identify backlogs and potential sources of delay, given the current work plans, personnel allocation and organisation. Together the tools offer a comprehensive suite of functionality for creating, maintaining, and utilizing shared models of the virtual enterprise. XCHIPS provides contextual work support for focused, real-time collaboration, whereas WORKWARE does the same for asynchronous collaboration. The models are managed by a shared repository residing on a web server. For the representation and interchange of models, an XML DTD is defined. At the user interface, WORKWARE provides access to services from all the tool through a model-generated workplace environment. Personalisable and model-driven user interface (HTML) METIS XCHIPS Sim- model- Work Enact- Aware- real Vision Document Access ling manage- ment ness time simulat manager controller and ment core engine engine collab- ion visuali- oration sation User Enact- Aware- Docu- Access interface ment ness ment control policies policies policies metadata policies Process models Shared model repository (WebDAV server, XML format) Figure 80. The architecture and components of the EXTERNAL Infrastructure. The modelling language of EXTERNAL (EEML) emphasises the process dimension of enterprises. A key idea of the EXTERNAL infrastructure, is to combine workflow with groupware, in order to offer a wider range of model-driven functionality. Groupware lets users share process models, and keeps them informed about what is happening in the project. This supports manual coordination by mutual adjustment, complementing standardisation of processes and automated scheduling by the workflow engine. Where conventional workflow separates users' tasks into personal worklists and automates coordination and information exchange, groupware integrates users around a shared, co-constructed model. Groupware and other model-driven services are implemented by the tools of the EXTERNAL infrastructure. Most of them support both articulation and activation of models. Our infrastructure currently includes these kinds of model-driven functionality, but more may be added: DA111-SotA-v1.0 PUBLIC Page 163 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 Ÿ Work management. Worklists allow people to organise their own work, and worktops provide tailored interfaces for each workitem (Jørgensen, 2004). All information contained in models is shared, so worklists also provide overview of the current state of a project. Ÿ Interactive enactment engine, executing the process structures when they are complete, and involving users when complementary manual decision making is required. Ÿ Model editors enable articulation, but it also provides visual overviews of the current state of affairs for coordination and management (manual activation). Ÿ An awareness engine notifies users about the actions of others, utilising the models to decide who needs to know about what, and in which context. Ÿ Access control, so that each user's assignments to workitems influence which information and services are made accessible. Ÿ Communication support and application sharing for collaborative tasks and negotiations, informal handling of unforeseen exceptions etc. Ÿ Information management and workspaces for document-centric collaboration (Natvig & Ohren, 1999), utilising process models to aid document retrieval and classification. Ÿ Simulation of modelled processes to aid planning and resource management. 9.1.1.1 Model-Generated Workplaces The tool components listed above offers functionality that adapts to the current process model, thus offering a partial interpretation of what the model means. Tool specific metadata and policy models allow further customisation. Policies are attached to the model elements to which they apply. Each tool offers services to users, available in an integrated, user interface, dynamically generated based on user interface policies and the content of the process model. It offers role, task and user specific views. 9.1.2 Other platforms for executing high-level models In the workflow literature, model activation mainly deals with fully automated process enactment. ATHENA A1 proposes interactive enactment of incomplete, evolving models as an alternative perspective. In addition to increased flexibility, we should aim at integrating a larger set of model driven functionality. 9.1.2.1 Milano A few adaptive workflow systems have applied interactive techniques. In MILANO (Agostini & DeMichelis, 2000) exceptions are handled by user-controlled jumps, policies control users access to make jumps, and negotiation support is integrated in the exception handling process. Differences between adaptive and interactive workflow are however evident in how models are interpreted. MILANO requires that all allowed paths be computed from the workflow model. WORKWARE recognises that the set of paths cannot be predetermined in an open system. Instead the chosen path unfolds in step-by- step situated activation. Users may also take actions that override the current model. 9.1.2.2 Ariadne Computational coordination mechanisms in ARIADNE (Divitini & Simone, 2000) can be incompletely defined. When some information is lacking, users are asked to provide it at runtime. However, Divitini and Simone claims that significant user contributions at runtime "is in general not reasonable" (Divitini & Simone, 2000). Consequently, the modelling in their case studies are performed by the researchers themselves, and the language makes few concessions towards end user participation. 9.1.2.3 Echoes On the other hand, some designers of process support systems (Herrmann, 2000; Mehandjiev, Bottaci, & Phillips, 1994), stress the potential of visual models to enable user involvement. ECHOES utilise instance modelling to support local modifications. However, users participate in model articulation, and not in unfolding activation of the models. On the other hand, ECHOES offer better means for process automation, e.g. service modelling, user interface content and layout definition (Mehandjiev et al., 1994). DA111-SotA-v1.0 PUBLIC Page 164 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 9.1.2.4 Orchestra Antunes et al. (Antunes & Guimaraes, 1995) argue that the separation between workflow support for formal procedures and groupware support for informal processes is artificial. Their ORCHESTRA engine identifies situations where formalised solutions do not exist. When such an exception occurs, the ORCHESTRA MATCHER selects the most appropriate group interaction technique, tools and actors to solve the problem. The system thus includes interaction in its model activation portfolio. It also offers powerful group interaction support (e.g. brainstorming, cognitive maps, and deal-making negotiation). However, ORCHESTRA relies on models built by external experts, and does not support articulation of ad-hoc tasks. 9.1.2.5 Obligations OBLIGATIONS (Bogia & Kaplan, 1995; Bogia, Tolone, Kaplan, & Tribouille, 1993) supports ad-hoc evolving webs of interdependencies among tasks. Any state transition in one task can be related to any transition in another task. New obligations, where one person or group commits to performing work requested by another, can be dynamically added at any time, but once they have been assigned to a performer, they can no longer be modified. While it contains a rich vocabulary for coordination, the system is thus not sufficiently flexible. Opposite to this and most workflow research, enterprise modelling started with ad-hoc processes and added support for routine procedures later. This leads to a different design, e.g. with a simpler modelling language and more manual control. 9.1.2.6 Hierastates HIERA STATES (Teege, 1994) is a formalism for model-driven, state-dependent object behaviour, which uses STATECHARTS (Harel, 1987) actively at runtime, e.g. to present alternative actions to the user. The language is refined with non-atomic transitions that interact with users during their activation, enabling users to stop the transition or select among alternative targets. The TACTS workflow prototype is built on top of HIERA STATES in order to support a mix of structured and unstructured activities, taking a clearly interactive perspective (Teege, 1996). TACTS' support range from no explicit process, via the process model as a guide, to partially and fully automated processes. In order to make STATECHARTS interactive HIERA STATES adds constructs for exception handling and allows partially structured models. Processes are modelled at the instance level. TACTS does not provide a full-scale work support system, just a prototype dealing exclusively with the process dimension (tasks and flows). Consequently, it has a limited modelling language and poor support for end user articulation. TACTS relies on user involvement in modelling, but not interaction during execution. On the other hand, HIERASTATES includes an open, rule-based enactment engine, and flexible model reuse mechanisms. 9.1.2.7 Reflection ENDEAVORS (Kammer, Bolcer, Naylor, & Bergman, 2000) and NETS-IN-NETS (W. v. d. Aalst, Moldt, Valk, & Wienberg, 1999) are examples of reflective workflow systems, which enable dynamic model interpretation. They allow the engine to be configured at runtime, selecting which set of enactment rules should be enforced. RECONFIGURABLE NETS (Badouel & Olivier, 1998) is a class of Petri nets that can dynamically modify its own behaviour by rewriting some of its components. For such nets, boundedness and soundness can be determined, i.e. it is a primary objective to guarantee that the model can be enacted in a closed system. However, since the flow relations in the model depend on the whole marking (set of tokens in the model), a form of dynamic semantic holism is achieved. This enables e.g. routing decisions of process instances to be made depending on the amount of work currently queuing in different parts of the process. The ROK framework (Edmonds & ter Hofstede, 1998) utilises reflection through a metaobject protocol (Kiczales et al., 1997) to support programmers in ongoingly adapting workflow definitions to changing business needs. 9.1.2.8 Agent-based approaches Software agents (Nwana, 1996) distribute functional support among semi-autonomous components. An agent has some degree of autonomy and adaptability, and it interacts with the environment (Singh, 1999). A number of research prototypes have applied agents for flexible process support (Huhns & Singh, 1998; Kosoresow & Kaiser, 1998; Wang, 2001). In the COORDINATION LANGUAGE FACILITY (CLF) multiple agents interact to facilitate distributed enactment in virtual enterprises (Borghoff, Bottoni, Mussio, & Pareschi, 1996; Grasso, Meunier, Pagani, & Pareschi, 1997). ALLIANCE (Alloui, Cimpan, DA111-SotA-v1.0 PUBLIC Page 165 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 Oquendo, & Verjus, 2001) provides similar malleability, distribution and decentralisation for software- intensive processes, utilising fuzzy logic to reason about uncertain and incomplete models. The ALLIANCE architecture includes agents for user interaction, tool integration, enactment, timing, monitoring, process change and decision making. Agents are dynamically assigned to tasks in the process model, but activation is separated from articulation, so these agents are not designed as model interactors. 9.1.2.9 Extending activation beyond enactment A number of tools provide model-driven collaboration support. For instance ORCHESTRA (Antunes & Guimaraes, 1995), OBLIGATIONS (Bogia & Kaplan, 1995; Bogia et al., 1993), XCHIPS (Haake & Wang, 1997) and MILANO (Agostini, De Michelis, & Grasso, 1997) provide a rich integration with conversation tools and shared workspaces. The strength of EXTERNAL lies in its alignment with email and Internet technology (simplicity), and the service concept, which allows uniform configuration of and access to internal and external functionality. The integration with XCHIPS in the EXTERNAL infrastructure has also provided more sophisticated communication support in the context of workitems and processes. Integration of workflow and awareness notification is proposed by a number of researchers (Rodden, 1996; Rolfsen, 1997; Sandor, Bogdan, & Bowers, 1997). WORKWARE's awareness customisation approach is inspired by TVIEWS (Wasserschaff & Bentley, 1997), but utilises holistic event propagation through complex structures to a greater extent. INCONCERT, INTERMEZZO (Edwards, 1996) and some specialised approaches (Bertino, Ferrari, & Atluri, 1999; Botha & Eloff, 2000) have combined workflow with access control, although not with the same flexibility and reusability as our implementation. Project management has also been prototyped in LAW (Faustmann, 2000), and INCONCERT is integrated with MS PROJECT. Time, resource and project management have been designed, but not yet implemented in EXTERNAL. 9.1.2.10 Customisation of groupware A number of tailorable information systems apply techniques suitable for enterprise model execution (Kahler, Mørch, Stiemerling, & Wulf, 2000). In AMULET and GARNET (Myers et al., 1997) instances are the primary objects, and Teege (Teege, 2000) shows the utility of feature composition for customisation, configuration, and extension. Feature composition allows properties and behaviour features to be added dynamically to objects. But while these systems apply software-oriented terms in their customisation, enterprise modelling utilises a domain-oriented language. DIVILAB (Pinkwart, Hoppe, & Grasser, 2001) defines a framework for domain-specific visual languages with operational semantics. Their hypertext meta-metamodel consists of objects and relationships. For each object type, users can define model, view, and controller aspects. HYPEROBJECT SUBSTRATE (HOS) (F. M. Shipman & McCall, 1994, 1999) is another flexible hypertext system. It facilitates incremental formalisation by end users. Starting with an unstructured model, users may add visual and textual features as they see fit. As the work progresses, text can be converted into lists, then further into objects with attributes, relationships and even inheritance. HOS uses prototype inheritance to facilitate this. These techniques have been thoroughly validated (F. Shipman et al., 2001; F. M. Shipman & Marshall, 1999; F. M. Shipman & McCall, 1999). Dangelmaier et al. (Dangelmaier, Hamoudia, & Klahold, 2002) highlights the importance of accommodating both personal preferences and domain nuances in workflow systems. They develop a multi-level preference model, where customised instances of system components are selected for different workflow states. WORKWARE's customisation features utilise more dimensions of the current state, and its reuse framework also is more general. On the other hand, Dangelmaier et al. have simpler user interfaces for end user tailoring. OVAL (Thomas W. Malone, Lai, & Fry, 1995) is another framework for cooperative applications. Its basic constructs are objects, views, agents and links. Usage experience with OVAL shows that nearly every time a user wants to perform a schema operation such as adding an attribute or setting default values, he is already in the context of a specific instance. This caused OVAL to include reflection operations on the instances, while remaining to separate class schemas from instance data. DA111-SotA-v1.0 PUBLIC Page 166 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 9.1.2.11 Policies, Media and Mechanisms In groupware design, mechanisms that directly support existing work practices in many cases become too inflexible. Instead media that can be tailored to suit each participant's needs, making the cooperation policies and protocols adaptable at runtime, have been proposed as an alternative metaphor (Abbot & Sarin, 1994; Bentley & Dourish, 1995; Edwards, 1996). Following this scheme, each model executing component in WORKWARE is controlled by a set of policies. Policies are themselves model objects and their scopes are determined by reuse policies. Conventionally, policies are more system oriented than primary model elements. This language problem has been recognised as a general limitation for deep tailorability (below the user interface) (Bentley & Dourish, 1995). While a number of organisational and social issues interplay in overcoming the barriers to end user customisation (Trigg & Bødker, 1994), designs that integrate customisation with work performance are found to be important (Bentley & Dourish, 1995). 9.1.2.12 Dynamic Object Models Dynamically interpreted and active object models have been utilised for adaptive workflow systems (Konstantas, Morin, Barziv, Koumpis, & Kobel, 2000; Manolescu & Johnson, 1999). Experience indicates that such designs work better with intellectual processes than in manufacturing (Manolescu & Johnson, 1999). These dynamic object models (DOM) use the property, strategy, metadata and visual builder design patterns (Gamma, Helm, Johnson, & Vlissides, 1994). However, by allocating strategies to types rather than instances, DOM becomes more complex and rigid. 9.2 Industrial Solutions to Enterprise Model Execution 9.2.1 Workflow Management Systems (WMS) Workflow is defined as "the automation of a business process, in whole or part, during which documents information or tasks are passed from one participant to another for action according to a set of procedural rules" (WfMC, 2000). This definition and most research focus on automatic activation. Miers (Miers & Hunt, 1995) categorise organisations and workflow technologies according to degree of empowerment and autonomy, the dominant coordination mechanism, and the depth of relationships between groups (Figure 81). Adhocracy Empowerment Position Trusting Professional Bureaucracy Divisional Form Unbounded Machine Knowledge Bureaucracy Dynamicsharing process Linkedlinkage sub - Simple Adjoinedprocesses functions Structure Controlling Super- Standard Standar Standar Mutual Data & Depth of vision processe d d adjustment transactions Relationship Bounded Coordinations outputs Mechanisms skills Figure 81. Miers' workware evaluation framework (Miers & Hunt, 1995). The top right corner is identified as the main challenge for further technology innovation. The interaction perspective attacks this challenge by viewing workflow as "active support for planning, DA111-SotA-v1.0 PUBLIC Page 167 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 performance and coordination of work based on an evolving, more or less complete, explicit process model". This definition broadens the scope by Ÿ Including groupware support for other forms of coordination (e.g. mutual adjustment), not just standardised processes and automated sequencing of tasks, Ÿ Allowing incomplete and evolving process models, managed by empowered users, Ÿ Integrating process articulation (planning), as part of the process, facilitating knowledge sharing and dynamic linking of process parts. 9.2.1.1 Static Workflow Management Systems Static WMS (WfMC, 2000) separate process definition (articulation) from process enactment (activation), and do not handle changes to the definition during enactment. These activities are supported by different tool components (Figure 21), and performed by different roles. Process definition is the work of process experts, while process participants perform work through workflow clients and invoked applications. Managers administer and monitor the work. This resembles the separation between conception and execution in Scientific Management (Braverman, 1974; Taylor, 1911). Production workflow follows mechanistic principles, as indicated by the fact that the enactment service is called the workflow engine (Carlsen & Gjersvik, 1997; Morgan, 1986). Static WMS aims to "increase efficiency by concentrating on the routine aspects of work activities" (Georgakopoulos, Hornick, & Sheth, 1995). The core research challenges thus include transaction processing, interoperability, reliability, performance and scalability, monitoring and management of large numbers of routine, well-defined processes. These challenges are clearly different from the ones uncovered here for executable enterprise models, so a detailed investigation of static WMS is of little relevance to this report. 9.2.1.2 Adaptive Workflow Management Systems Flexible workflow is a hot research topic (Bernstein & Jablonski, 2000; Klein, 1998; Klein, Dellarocas, & Bernstein, 2000). Most work within this area looks at how conventional systems can be extended, how static workflow systems can be made adaptive and dynamic. Research challenges for adaptive workflow include: Ÿ Controlled handling of exceptions (Chiu, Li, & Karlapalem, 2000; C. Ellis & K. Keddara, 2000; C. S. Ellis & Maltzahn, 1997; Faustmann & Wikarski, 1996; Klein & Dellarocas, 2000; Z. Luo, Sheth, Kochut, & Miller, 2000), Ÿ Dynamic change, migration of instances from an old class schema to a new (Agostini & DeMichelis, 2000; F. Casati, Ceri, Pernici, & Pozzi, 1996; C. Ellis & K. Keddara, 2000; C. Ellis, Keddara, & Rozenberg, 1995; W.M.P. van der Aalst & Basten, 1997). Most research in this area recognises that change is a way of life in organisations, but still regards work as repetitive and prescribable. Within the community, an understanding seems to have emerged that change requires process definition and process enactment to be intertwined (C. Ellis & K. Keddara, 2000). Most systems are however based on the premise that the enactment engine is solely responsible for interpreting the workflow model. In other words, users contribute by making alterations to the model, not by interpreting any part of it. Thus, the model must be formally complete to prevent ambiguity and deadlock from paralysing the process. This view of the engine as a Turing machine (Wegner, 1997) complicates the models, because all process variants must be included (Klein et al., 2000). It makes exception handling controllable, but cumbersome. Hence, some researchers challenge the feasibility of articulation by end users, arguing that they cannot be expected to change models correctly (Heinl et al., 1999). Although this research targets closed system automation rather than open interaction, many of its algorithms and design principles are relevant for enterprise models as well. An overview of adaptive WMS also helps us get a clearer picture of what the innovative capabilities of executable enterprise models is, and in which situations these capabilities are needed. 9.2.1.2.1 Workflow Enactment in Petri Nets Several approaches to adaptive workflow are based on the manipulation of Petri nets (C. S. Ellis & Maltzahn, 1997; W. v. d. Aalst, Desel, & Oberweis, 2000). The execution of Petri nets is based on tokens moving along the arcs (flows) of the model. Tokens reside in the places of the model, and the DA111-SotA-v1.0 PUBLIC Page 168 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 token population (the marking) represents the current state of the process. Transitions are enabled when all of their input places contain tokens. An enabled transition may fire, causing one token to be removed from each input place and one token to be added to all of the output places. In this way, each token can be viewed as a thread in the work process. Threads may split and later merge at transitions. 9.2.1.2.2 Adaptive Enactment in Petri Nets Exception handling is one area where the closed system assumption in adaptive workflow is temporarily relaxed, and human actors can influence the interpretation of the model. A lot of research into adaptive WMS has focussed on ways in which the token population in a Petri net can be altered in order to handle typical exceptions. The CHAUTAUQUA system (C. S. Ellis & Maltzahn, 1997) includes operators for splitting threads, and conflicts between threads are resolved interactively in a merge operation. Exceptions are handled by jumping to another activity. MILANO (Agostini et al., 1997; Agostini & DeMichelis, 2000) also allow user-controlled token jumps. Organisational policies determine which users are authorised to make what kinds of jumps. This technique can handle redo, loops, skipping an activity, parallelisation and sequentialisation. MILANO applies an integrated conversation tool to support negotiation in the exception handling process. These approaches handle simple changes to the execution order of tasks, partially meeting the requirement for local modification (R5). More far-reaching changes, e.g. re-definition of a process model, are poorly supported. Situated interpretation (interactive or manual activation) of incomplete models is not allowed, so the models must be formally complete and consistent. Users are supposed to react upon the arrival of tokens to tasks that they are responsible for, not to make proactive decisions regarding the flow of work. 9.2.1.2.3 The Dynamic Change Problem In most adaptive WMS there is an implicit assumption that workflows are modelled at the class level (often called the schema), and that instances are enacted according to the rules specified for the class. In this context changes must be dynamically propagated from the class schema to ongoing instances (C. Ellis et al., 1995). Given the large number of instances that follow the same model, manual transfer is expensive. Dynamic change may also introduce deadlocks that halt some of the instances. Automated or semi-automated change management is thus needed. In Petri net models, the dynamic change problem is formalised as the search for a mapping of token markings from one model version to another. Ellis et al. (C. Ellis et al., 1995) propose a combination of immediate and delayed transfer of instances to the new model. The model is partitioned into change regions. If a region is not changed in the new version, or if the changes applied in a region represent an up-sizing (the new version can do what the old one could and more), immediate transfer is possible for all instances currently in the region. Instances that reside in a down-sized or more complexly changed region, are not transferred until they leave the region (delayed transfer). This approach, called synthetic cut over change, is also implemented in MILANO (Agostini & DeMichelis, 2000). While it ensures correctness, e.g. that no deadlocks are introduced in the migration process, the method is complex, and only handles a few change scenarios. 9.2.1.2.4 Metaprocess Support for Workflow Evolution Ellis and Keddara (C. A. Ellis & K. Keddara, 2000) claims that "a workflow change is a workflow" in itself, arguing that metaprocess support for workflow change is needed. Neeb (Neeb, 2000) makes a similar proposition, discussing to which extent metaprocesses can manage unforeseen and anticipated changes. In ML-DEWS (Modelling Language to support Dynamic Evolution within Workflow Systems) (C. A. Ellis & K. Keddara, 2000), change can be modelled, enacted, analysed, and monitored just like any primary process. ML-DEWS integrates the handling of instance and schema changes, and provide predefined change process schemes for typical approaches like abort, defer, edit, continue and synthetic cut over. Instance changes are handled as temporary schema changes. ML-DEWS is based on UML, with all workflow constructs represented as classes. Although their default change processes include an ad-hoc scheme, it is not clear (from (C. Ellis & K. Keddara, 2000; C. A. Ellis & K. Keddara, 2000)) to what extent this case is facilitated by their implementation. The modelling language seems complex, rigid and system-oriented. Casati et al. (F. Casati et al., 1996) also propose a language for specifying the change management metaprocess. A separate language is selected because it needs to be more flexible than the basic process definition language, and the performance and scalability requirements for change processes are not as strict as those for the core production processes. Casati et al. use Event-Condition-Action DA111-SotA-v1.0 PUBLIC Page 169 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 (ECA) rules for change management. An ECA rule declares what action should be performed when an event occurs and the condition statement is fulfilled. They are also used to control transitions in state diagrams (Harel, 1987). The NETS-IN-NETS prototype (W. v. d. Aalst et al., 1999) allows dynamic model interpretation through reconfiguration of the enactment rules at runtime. The enactment rules are represented as a Petri net meta-model. In other words metaprocess modelling and process modelling is done in the same language. 9.2.1.2.5 Exception Handling In ADOME (ADvanced Object Modelling Environment) (Chiu et al., 2000), a WMS is built on top of an active object oriented database system. Other approaches (Alonso et al., 1999; Fabio Casati, 1998), have also built exception handling on top of transaction mechanisms in databases. ADOME was designed to minimise the need for human intervention in resolving exceptions. Consequently, trivial exceptions are handled by the system component where they arise. If the component is incapable of handling it, the exception may be forwarded to automatic exception handling. Exception handlers are defined declaratively with ECA rules or operationally with metaprocesses. If no automatic handler exists, users are involved, either interactively or with full manual control. If nothing works, the exception is regarded as a failure. ADOME advocate an ongoing harvesting of user-defined exception strategies into a repository for reuse. Defeasible workflow (Zongwei Luo & Sheth, 1998; Z. Luo et al., 2000) is a similar approach. Here workflows are modelled by justified event-condition-action (JECA) rules. The justification part describes the context in which the rule can be applied (R11). This perspective on exceptions as a source for learning is not shared by Klein and Dellarocas (Klein & Dellarocas, 2000), who define "an exception to be any departure from a process that achieves the process goals completely and with maximum efficiency". They use a taxonomy of coordination mechanisms in the PROCESS HANDBOOK (T.W. Malone, Crowston, Lee, & Pentland, 1993) to classify and diagnose failure situations. Cugola (Cugola, 1998) argues that inconsistencies in process models should be tolerated. This is partly implemented in the SENTINEL and PROSYT prototypes, but mainly for temporal deviations from an otherwise complete model. Some designers of adaptive WMS thus suggest that designing exception handling as an interactive process, works better than full automation. However, human involvement is only triggered when no acceptable procedure is found. This approach applies interaction in exception handling, but not in normal activation. Consequently, incomplete and evolving models are not adequately supported. Human involvement is reactive, but not proactive. · Adaptive Workflow - Summary Adaptive WMS offers important flexibility compared to static systems. Changes to workflow models affect running instances, and exception handling is supported. Adaptive workflow still shares the basic assumption of static WMS: that the process should be completely predefined at the class level. As we have seen, the situated and contingent nature of most project work demands local articulation in each project. New enactment concepts should thus be investigated. 9.2.1.3 InConcert INCONCERT is a commercial WMS that incorporates flexible collaboration features (Abbot & Sarin, 1994; S. Sarin, 1995; S. K. Sarin, Abbott, & McCarthy, 1991). The original design goals included mutable process models, allowing for human judgement, and provision of a shared workspace for task performance. The system works on workflow instances, rather than classes. Templates with varying degree of structure are offered as starting points for local articulation by process participants. Instance- orientation also simplifies the modelling language. For instance, repetitive tasks generate new instances for each repetition, so loops are linearised. Although INCONCERT meets many of the requirements, it has some limitations. The system does not allow collaborative tasks with more than one actor. It does include some groupware features, like shared workspaces for documents, but not extensive support for e.g. negotiations or project management. 9.2.1.4 Endeavors TEAMWARE FLOW includes user-oriented process models as a design goal (Swenson, Maxwell, Matsumoto, Saghari, & Irwin, 1994; Young, 1994). Collaborative planning of work is approached DA111-SotA-v1.0 PUBLIC Page 170 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 through divide and conquer, with individuals taking responsibility of their own parts of the process. The focus is complete workflow models, not models consisting of more or less articulated fragments. Instance level modifications are supported, as long as they are in compliance with the class schema. ENDEAVORS (Bolcer & Taylor, 1996; Hitomi & Le, 1998; Kammer et al., 2000) is the successor of TEAMWARE FLOW. It combines a number of techniques for exception detection, avoidance, tolerance and handling (Kammer et al., 2000): Ÿ Runtime dynamism, late binding of resources, data, process structure and behaviour. Ÿ Configurable and partial execution. The engine can be reconfigured to enforce different rules for each instance. Users can also define new rules. Ÿ Typed modelling, extensible typing, generalisation and specialisation of model elements. Ÿ Reflexivity, changes to the model are allowed during enactment. Ÿ Instances can be promoted to templates, capturing local process improvement. Ÿ A library of reusable, composable model fragments. Alongside INCONCERT, ENDEAVORS seems to be the WMS that offers the most support for the requirements uncovered here. It combines conventional adaptive workflow techniques with some interactive features, but support for local modification and incomplete models is limited. An interactive execution component can never assume to have complete control of the model. Instead different components should complement each other in a context-dependent manner. In WORKWARE, the assignment of functional features to model objects is determined by policies. Such an architecture separates functionality from the model objects, following the strategy design pattern (Gamma et al., 1994). This flexible binding enables personalisation and contextualisation. ENDEAVORS (Bolcer & Taylor, 1996) similarly decouples object data from the handlers that control behaviour. Less flexible environments directly map model elements to software components. 9.2.1.5 Case Management Systems Case management systems (Miers & Hutton, 1996) such as VECTUS (Miers, 1998) and FLOWer (W. M. P. van der Aalst & Berens, 2001), recognise the unique characteristics of each case. They facilitate manual handling of exceptions, manual selection and scheduling of tasks subject to predefined constraints etc. Cases are less complex than knowledge intensive projects and require fewer participants. Often the objective is to enable as few persons as possible to deal with the whole case, minimising hand-off overhead, speeding up the process and removing extra work in answering customer enquiries. 9.2.1.6 Reflection in Baan In a design for extending the flexibility of the BAAN workflow engine (Meijler, Kessels, Vuijst, & le Comte, 1998), shoot tip activities trigger meta-activities for defining the next steps of the process. The shoot tips are growing points for the process model, allowing ad-hoc modelling at predefined places. The EXTERNAL project similarly modelled the meta-process of project planning, but here changes were allowed at any place in the model, so any task could become a shoot tip through concurrent modelling and execution. Similarly, planning tasks are modelled just like ordinary tasks. BAAN also jumps to the meta-level when exceptions arise, providing transaction support, which is not implemented in the EXTERNAL infrastructure. 9.2.1.7 Computas FrameSolutions Computas has for many years developed a task declaration, management and execution platform that is widely used in its customised solutions within e-Government. This platform and its capabilities are being integrated with the Metis platform to form an integrated modelling and execution platform. The EXTERNAL infrastructure capabilities will be supported. DA111-SotA-v1.0 PUBLIC Page 171 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 9.3 Summary and conclusions The concept of executable enterprise models extends conventional techniques for customisation, integration, and extension with model-driven contextualisation. A visual model where domain knowledge is articulated influences the operation of the system. The interactive enactment concept improves the support for emergent, ad-hoc processes. Such support is seldom prioritised in existing business process management systems, although it is often mentioned as a requirement. The complexity and rigidity of modelling infrastructures effectively hinders end-user participation in articulation and activation. While research projects in adaptive workflow management have proposed human intervention, e.g. in the handling of exceptions, this is commonly a last resort, when all else fails. Utilising user involvement to simplify the languages and mechanisms of the WMS, and integrating support for manual interpretation, is a new research topic for the workflow community. Widening the scope of model- driven support, is another challenge for further research. DA111-SotA-v1.0 PUBLIC Page 172 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 10 Conclusions The objective of this section is to make a brief statement of the conclusions that can be extracted from this state of the art and practice report, taking into account that the document already draws opinion and conclusions on the different topics. Enterprise modelling is a technology that many companies would say they are applying. The application of EM in industry is predominantly for EA and BPM, and the comprehension of what it is and how to use it is linked to consultancy and modelling expertise. Industrial use spans from the definition of business plans to the definition of the ISO 9000 compliant quality system. Many practices are considered as enterprise modelling by the industry. However, EM is rapidly developing and transforming into providing visual languages, best-practice patterns and visual knowledge spaces. The new era for EM is driven by the advent of more advanced approaches, methodologies, infrastructures and platforms and a need for families of solutions that allow predictable customisation. There are four major lessons to learn from our state of the art and practice analysis and our technology trends and visions: 1. Improved Usability – modelling must become part of executing work just like document preparation and working environments must have support for a wide range of modelling techniques and languages to interactively, using active models, engage stakeholders and users throughout the project and knowledge element life-cycles 2. New approaches, integrated methodologies, families of platforms and families of solutions must be co-designed and co-evolve – this means that we must understand the potential of externalizing and sharing Enterprise Knowledge Spaces and that each of these dimensions have architectures that must be co-developed in order to create and maintain interoperability. 3. New ways of designing and developing computing systems and solutions – recognizing the layers of Enterprise Architecture as Business, Knowledge and ICT, and that the Knowledge Architecture must store logic and descriptive (meta) knowledge as separate from the functional meta-knowledge we have to encode (compile) for the computer to work on. We have to find a better work sharing between the human mind and the computer. 4. Systems Architecting and Engineering must and will undergo dramatic development in the years ahead. With current practices too much enterprise logic and knowledge is frozen into compiled computer code. Discussions have been underway in industry and among vendors for the last ten years. We are getting ready for a major paradigm-shift in industrial computing. The overall effect of this is that interoperability will be easier to achieve, but must still be a design quality for the enterprise. Thus, first there is a need to make the industry understand the future meaning and impact of enterprise modelling as a comprehensive definition of the enterprise knowledge spaces and their knowledge dimensions and inter-relationships. EM must build on aspects such as business processes, organisation, products and services, information systems, decision making approach, etc. Enterprise modelling comprises also the ability to show the information is many different ways, this is, to provide different views depending on the observer, the perspective and the objective pursued. Finally, enterprise modelling is the framework and the mean to establish a knowledge based organisation that is able to keep, manage and share the appropriate information among the appropriate players. Moving to the context of the collaborative enterprise, new requirements are imposed over enterprise modelling technology and, on the other hand, the potential of profiting from the technology increases exponentially. Enterprise models provide in this sense the basis for a common understanding of the collaboration and the means for the specification of such collaboration. In the context of enterprise modelling of collaborative enterprises, the model is the key concept and the model drives both the design-time specification and the run-time operation of the enterprise. The model is the element that is in the centre and provides the integration among people and the different enterprise elements:- enterprise systems, methodologies, processes, workplaces, networked collaborations, etc. In the ideal world, the model is the element from which all the enterprise views and systems are generated. This is probably the dream towards which the technology on enterprise modelling will progress. Modelling collaborative enterprises requires specific constructs and methodologies, and requires a certain level of wide-consensus for exchanging and merging behaviours of several entities into an DA111-SotA-v1.0 PUBLIC Page 173 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 orchestrated operation. Flexibility and ability for rapid adaptation are other features that are key for establishing collaboration among enterprises. The state of the art reveals the existence of different technologies and tools for enterprise modelling and the existence of initiatives that try to look for consensus on some aspects. However, a big effort still needs to be performed to make the model-driven approach a reality, to address collaboration/interoperability requirements, and to reach the industry with the appropriate strategy to adopt the new technologies in a non-disruptive but efficient and effective manner. Project A1 of ATHENA will work on improving the current technology for enterprise modelling of collaborative enterprises, sometimes building upon existing technologies to advance the state of the art, other times proposing breakthrough approaches that are necessary to move towards the model- driven approach that we pursue. The focus on project A1 will be reviewed from time to time to be consistent with the state of the art. To this end, the state of the art itself will be reviewed periodically. The objective is to ensure that our work is consistent with the world-wide progress in the field. DA111-SotA-v1.0 PUBLIC Page 174 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 11 Definitions and Acronyms The terms and definitions were defined within the frame of some standards and/or standardisation projects relating to enterprise integration and interoperability. This list is not exhaustive but contains some selected terms which are relevant to ATHENA A1 Project. abstraction a shortening in duration or extent with no sacrifice of sense, used to differentiate between a real-world system and a model of the real world [ISO 14258:1998] activity all or part of functionality [ISO 15704, 1999] application a classification of computer programs designed to perform specific tasks, such as word processing, database management, or graphics [Open Group, 2000] application platform the collection of hardware and software components that provide the services used by support and mission-mission- specific software applications [Open Group, 2000] application software software entities which have a specific business purpose. [Open Group, 2000] architecture a description (model) of the basic arrangement and connectivity of parts of a system (either a physical or a conceptual object or entity) NOTE There are two, and only two, types of architectures that deal with enterprise integration. These are: a) System architectures (sometimes referred to as "type 1" architectures) that that deal with the design of a system, e.g. the computer control system part of an overall enterprise integration system; b) Enterprise-reference projects (sometimes referred to as "type 2" architectures) that deal with the organisation of the development and implementation of a project such as an enterprise integration or other enterprise development programme. [ISO 15704, 1999] architecture the fundamental organisation of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution [Open Group, 2000] attribute a piece of information stating a property of an entity NOTE An attribute models an intrinsic property of something, for example, the geometry of a part, the condition of a tool, or the qualifications of a worker. [ISO 15704, 1999] behaviour how the whole or part of the system acts and reacts [ISO 15704, 1999] business process a partially ordered set of enterprise activities that can be executed to realise a given objective of an enterprise or a part of an enterprise to achieve some desired end-result [ISO 15704, 1999] DA111-SotA-v1.0 PUBLIC Page 175 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 capability set of functions and services with a set of criteria for evaluating the performance of a provider [ISO 15704, 1999] capability profiling selecting a set of offered services defined by a particular interface within a software interoperability framework [ISO I6100, 2000] class description of a set of objects that share the same attributes, operations, methods, relationships, and semantics [UML] constraint a restriction or limitation or condition placed upon a system that originates from inside or outside the system under consideration NOTE Adapted from ISO 14258:1998 construct template: common structure that allows the identification and description of particular modelling language constructs and the assignment of their properties [ISO 19440, 2002] data a representation of facts, ideas, or instructions in a formalised manner, suitable for communication, interpretation, or processing by humans or by automatic means. (This definition refers to a group of facts taken as a unit, thus it is used with a singular verb) [ISO/IEC 11179-1, 3] database structured or organised collection of information, which may be accessed by the computer [Open Group, 2000] database management system computer application program that accesses or manipulates the database [Open Group, 2000] decision the result of choosing between different courses of action [ISO 19439, 2003] decisional relating to those processes that are concerned with making choices [ISO 19439, 2003] Decision Centre DA111-SotA-v1.0 PUBLIC Page 176 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 domain DA111-SotA-v1.0 PUBLIC Page 177 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 hardware (1) physical equipment, as opposed to programs, procedures, rules, and associated documentation (2) contrast with software [Open Group, 2000] generic having the property of generalizing a number of distinguishable entities based on their shared characteristics [ISO 19439, 2003] information any communication or representation of knowledge such as facts, data, or opinions, in any medium or form, including textual, numerical, graphic, cartographic, narrative, or audio-visual forms [Open Group, 2000] information system the computer-based portion of a business system [Open Group, 2000] information technology (IT) the technology included in hardware and software used for information, regardless of the technology involved, whether computers, communications, micro graphics, or others [Open Group, 2000] information view an enterprise model view that enables the representation and modification of the information of the enterprise (material and information) identified in the function view [ISO 19439, 2003] instance entity that has unique identity, a set of operations that can be applied to it, and state that stores the effects of the operations [UML] interface interconnection and interrelationships between two devices, two applications, or the user and an application or device [Open Group, 2000] interoperability - the ability of two or more systems or components to exchange and use shared information, and - the ability of systems to provide and receive services from other systems and to use the services so interchanged to enable them to operate effectively together [Open Group, 2000] language combination of a lexicon and a grammar [ISO 18629-1, 2003] lexicon set of symbols and terms NOTE The lexicon consists of logical symbols (such as Boolean connectives and quantifiers) and non-logical symbols. For ISO 18629, the non logical part of the lexicon consists of expressions (constants, function symbols, and relation symbols) chosen to represent the basic concepts of the ontology. [ISO 18629-1, 2003] life cycle the set of distinguishable phases and steps an entity goes through from its creation until it ceases to exist [ISO 19439, 2003] DA111-SotA-v1.0 PUBLIC Page 178 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 manufacturing application group of resources, within a manufacturing domain of an enterprise, co-operating to realise a definite objective or role [ISO 16100, 2000] manufacturing software type of resource within an automation system that provides value to a manufacturing application by enabling the flow of control and information among the automation system components involved in the manufacturing processes, between these components and other enterprise resources, and between enterprises in a supply chain or demand chain [ISO 16100, 2000] manufacturing software application use of a manufacturing software unit in a particular manufacturing application, to perform a specific set of functions, while running of a given hardware platform and execution environment [ISO 16100, 2000] manufacturing software component class of manufacturing software resource intended to support the execution of a particular manufacturing task [ISO 16100, 2000] manufacturing software unit instance of a class of software resources performing a definite function or role within a manufacturing activity while supporting a common information exchange mechanism with other units and consisting of one or more manufacturing software components [ISO 16100, 2000] NOTE A software unit can be modelled using UML as a software object. manufacturing system set of manufacturing resources co-ordinated by a particular information model to support the execution and co-ordination of manufacturing processes involving the flow of control, information, material, and energy in a manufacturing plant [ISO 16100, 2000] manufacturing software capability set of manufacturing software functions and services evaluated against a set of criteria under a given set of conditions [ISO 16100, 2000] manufacturing software capability profile concise representation of a manufacturing software capability to facilitate the evaluation of a software component to meet a requirement of a manufacturing application [ISO 16100, 2000] manufacturing software interoperability ability to share and exchange information using common syntax and semantics to meet an application- specific functional relationship through the use of a common interface [ISO 16100, 2000] manufacturing software interoperability framework a set of elements and rules to model a common environment to manage software interoperability [ISO 16100, 2000] material matter used in manufacturing the product [ISO 15745-1, 2002] EXAMPLE Raw materials, consumables, catalysts. methodology a set of instructions (provided through text, computer programs, tools, etc.) that is a step-by-step aid to the user DA111-SotA-v1.0 PUBLIC Page 179 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 [ISO 15704, 1999] metadata data that defines and describes other data [ISO/IEC 11179-1, 3] meta model model that defines the language for expressing a model [OMG] metaview (also known as a viewpoint) a specification of the conventions for constructing and using a view. A metaview acts as a pattern or template of the view, from which to develop individual views. A metaview establishes the purposes and audience for a view, the ways in which the view si documented (e.g., for visual modelling), and the ways in which it is used (e.g., for analysis) [Open Group, 2000] model an abstract representation of reality in any form (including mathematical, physical, symbolic, graphical, or descriptive form) to present a certain aspect of that reality for answering the questions studied [ISO 15704, 1999] modelling language construct a textual or graphical part of a modelling language devised to represent in an orderly way the diverse information on common properties and elements of a collection of phenomena NOTE Adapted from CEN ENV 12204:1995. A modelling language construct is a basic architectural entity at the generic level that is designed to be re-used in a wide range of applications. As a part of a modelling language, it models common features of structure and/or behaviour in a modelled domain. [ISO 19439, 2003] objective a statement of preference about possible and achievable future situations that influences the choices within some behaviour NOTE Adapted from ISO/IEC FCD 15414:2000 [ISO 19439, 2003] ontology a lexicon of specialised terminology along with some specification of the meaning of terms in the lexicon. NOTE 1: structured set of related terms given with a specification of the meaning of the terms in a formal language. The specification of meaning explains why and how the terms are related and conditions how the set is partitioned and structured. NOTE 2: The primary component of a process specification language such as ISO 18629 is an ontology The primitive concepts is the ontology according to ISO 18629 are adequate for describing basic manufacturing, engineering, and business processes. NOTE 3: The focus of an ontology is not only on terms, but also on their meaning. An arbitrary set of terms is included in the ontology, but these terms can only be shared if there is an agreement about their meaning. It is the intended semantics of the terms that is being shared, not simply the terms. NOTE 4: Any term used without an explicit definition is a possible source of ambiguity and confusion. The challenge for an ontology is that a framework is needed for making explicit the meaning of the terms within it. For the ISO 18629 ontology, it is necessary to provide a rigorous mathematical characterisation of process information as well as a precise expression of the basic logical properties of that information in the ISO 18629 language. [ISO 18629-1, 2003] open system a system that implements sufficient open specifications for interfaces, services, and supporting formats to enable properly engineered applications software: (a) to be ported with minimal changes across a wide range of systems, (b) to interoperate with other applications on local and remote systems, and (c) to interact with users in a style that facilitates user portability [Open Group, 2000] DA111-SotA-v1.0 PUBLIC Page 180 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 organisational Unit DA111-SotA-v1.0 PUBLIC Page 181 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 [ISO/IEC 11179-1, 3] software architecture fundamental organisation of a system embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution [IEEE 1471-2000] software environment that which is inhabited by software and which determines the setting and circumstances of developmental, operational, political, and other influences upon the software NOTE The software environment can include other systems that interact with the system of interest, either directly via interfaces or indirectly in other ways. The environment determines the boundaries that define the scope of the system of interest relative to other systems. [ISO 16100, 2000] state (of an object): at a given instant in time, the condition of an object that determines the set of all sequences of actions in which the object can take part [ISO 15745, 2002] system a collection of real-world items organised for a given purpose [ISO 15704, 1999] NOTE A system is characterised by its structure and its behaviour. stakeholder an individual, team, or organisation (or classes thereof) with interests in, or concerns relative to, a system [Open Group, 2000] transaction interaction between a user and a computer in which the user inputs a command to receive a specific result from the computer [Open Group, 2000] user (1) any person, organisation, or functional unit that uses the services of an information processing system (2) in a conceptual schema language, any person or any thing that may issue or receive commands and messages to or from the information system [Open Group, 2000] view a representation of a whole system from the perspective of a related set of concerns [Open Group, 2000] viewpoint a model or schema of the information in a view NOTE viewpoint can be defined as a specification of the conventions for constructing and using a view. A viewpoint acts as a pattern or template from which to develop individual views by establishing the purposes and audience for a view and the techniques for its creation and analysis. [Open Group, 2000] DA111-SotA-v1.0 PUBLIC Page 182 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 12 References Abbot, K. R., & Sarin, S. K. (1994). Experiences with Workflow Management: Issues for The Next Generation. Paper presented at the ACM CSCW Conference. Agostini, A., De Michelis, G., & Grasso, M. A. (1997). Rethinking CSCW systems: the architecture of MILANO. Paper presented at the ECSCW Conference, Lancaster, UK. Agostini, A., & DeMichelis, G. (2000). A Light Workflow Management System Using Simple Process Models. Computer Supported Cooperative Work, 9(3-4), 335-363. Alloui, I., Cimpan, S., Oquendo, F., & Verjus, H. (2001). A Software Framework for Software-Intensive Process Modelling, Enactment and Fuzzy Control. Transactions of the Society for Design and Process Science, 5(4), 39-53. Alonso, G., Fiedler, U., Hagen, C., Lazcano, A., Schuldt, H., & Weiler, N. (1999, March 23-24). WISE: Business to Business E-Commerce. Paper presented at the International Workshop on Research Issues on Data Engineering, Sydney, Australia. Antunes, P., & Guimaraes, N. (1995). Beyond Formal Processes: Augmenting Workflow with Group Interaction Techniques. Paper presented at the ACM Conference on Organisational Computing Systems (COOCS), Milpitas, California, USA. Argyris, C., & Schön, D. (1978). Organisational Learning: A Theory of Action Perspective. Reading, MA, USA: Addison Wesley. Badouel, E., & Olivier, J. (1998). Reconfigurable Nets, a Class of High Level Petri Nets Supporting Dynamic Changes within Workflow Systems (Technical Report No. 3339). Rennes, France: INRIA. Bentley, R., & Dourish, P. (1995). Medium versus mechanism: Supporting collaboration through customisation. Paper presented at the ECSCW Conference, Stockholm, Sweden. Bernstein, A., & Jablonski, S. (2000, December 2). Workshop: Beyond Workflow Management: Supporting Dynamic Organisational Processes. Paper presented at the ACM CSCW Conference, Philadelphia, USA. Bertino, E., Ferrari, E., & Atluri, V. (1999). Specification and Enforcement of Authorisation Constraints in Workflow Management Systems. ACM Transactions on Information and System Security, 2(1), 65-104. Bogia, D. P., & Kaplan, S. M. (1995). Flexibility and Control for Dynamic Workflows in the wOrlds Environment. Paper presented at the ACM Conference on Organisational Computing Systems (COOCS), Milpitas, California. Bogia, D. P., Tolone, W. J., Kaplan, S. M., & Tribouille, E. (1993). Supporting dynamic interdependencies among collaborative activities. Paper presented at the ACM Conference on Organisational Computing Systems (COOCS). Bolcer, G. A., & Taylor, R. N. (1996, December, 2-6). Endeavors: A Process System Integration Infrastructure. Paper presented at the International Conference on Software Process (ICSP4), Brighton, U.K. Borghoff, U. M., Bottoni, P., Mussio, P., & Pareschi, R. (1996, October 30-31). Reflective Agents for Adaptive Workflows. Paper presented at the Practical Aspects of Knowledge Management (PAKM) Conference, Basel, Switzerland. Botha, R. A., & Eloff, J. H. P. (2000). A Framework for Access Control in Workflow Systems. Information Management and Computer Security, 9(3). Braverman, M. (1974). Labor and Monopoly Capital. Chicago, USA: The University of Chicago Press. Carlsen, S., & Gjersvik, R. (1997). Organisational Metaphors as Lenses for Analyzing Workflow Technology. Paper presented at the ACM GROUP Conference, Phoenix, Arizona USA. Carlsen, S., Johnsen, S. G., Jørgensen, H. D., Coll, G. J., Mæhle, Å., Carlsen, A., et al. (1999). Knowledge re-activation mediated through knowledge carriers. Paper presented at the MICT Conference, Copenhagen, Denmark. DA111-SotA-v1.0 PUBLIC Page 183 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 Casati, F. (1998, November 14). A Discussion on Approaches to Handling Exceptions in Workflows. Paper presented at the ACM CSCW Workshop: Towards Adaptive Workflow Systems, Seattle. Casati, F., Ceri, S., Pernici, B., & Pozzi, G. (1996). Workflow Evolution. Paper presented at the ER Conference, Cottbus, Germany. Chen, D., & Vernadat, F. (2003). Enterprise Interoperability: A Standards View. In J. Kosanke, Nell, Bas (Ed.), Enterprise Inter- and Intra-Organisational Integration. Boston: Kluwer. Chiu, D., Li, Q., & Karlapalem, K. (2000). A Logical Framework for Exception Handling in ADOME Workflow Management System. In B. Wangler & L. Bergman (Eds.), CAiSE Conference, Springer LNCS 1789 (pp. 264-278). Stockholm, Sweden. Cockburn, A. (2003). People and Methodologies in Software Development. Unpublished PhD, University of Oslo. Cugola, G. (1998). Tolerating Deviations in Process Support Systems via Flexible Enactment of Process Models. IEEE Transactions on Software Engineering, 24(11), 982-1001. Dangelmaier, W., Hamoudia, H., & Klahold, R. F. (2002). Domain Preferences for End-User Tailoring in Shared Workflow Interfaces. Paper presented at the CRIWG Workshop, Darmstadt, Germany. Davenport, T. H., & Prusak, L. (1993). Working Knowledge. Boston, Massachusetts: Harvard Business School Press. Divitini, M., & Simone, C. (2000). Supporting Different Dimensions of Adaptability in Workflow Modeling. Computer Supported Cooperative Work, 9(3-4), 365-397. Dourish, P., Holmes, J., MacLean, A., Marqvardsen, P., & Zbyslaw, A. (1996). Freeflow: Mediating Between Representation and Action in Workflow Systems. Paper presented at the ACM CSCW Conference, Boston, USA. Edmonds, D., & ter Hofstede, A. H. M. (1998, November 14). Achieving Workflow Adaptability by Means of Reflection. Paper presented at the ACM CSCW Workshop: Towards Adaptive Workflow Systems, Seattle. Edwards, W. K. (1996). Policies and Roles in Collaborative Applications. Paper presented at the ACM CSCW Conference, Boston, Mass. Ellis, C., & Keddara, K. (2000). ML-DEWS: Modeling Language to Support Dynamic Evolution within Workflow Systems. Computer Supported Cooperative Work, 9(3-4), 293-333. Ellis, C., Keddara, K., & Rozenberg, G. (1995). Dynamic Change Within Workflow Systems. Paper presented at the ACM Conference on Organisational Computing Systems (COOCS), Milpitas, CA, USA. Ellis, C. A., & Keddara, K. (2000). A Workflow Change is a Workflow. In W. v. d. Aalst, J. Desel & A. Oberweis (Eds.), Business Process Management. Berlin, Germany: Springer LNCS 1806. Ellis, C. S., & Maltzahn, C. (1997). The Chautauqua Workflow System. Paper presented at the Hawaii International Conference on System Sciences (HICSS-30), Maui, Hawaii. Faustmann, G. (2000). Configuration for Adaptation - A Human-Centered Approach to Flexible Workflow Enactment. Computer Supported Cooperative Work, 9(3-4), 413-434. Faustmann, G., & Wikarski, D. (1996, October 30-31). Exception Handling in Petri-Net-Based Workflow Management. Paper presented at the Practical Aspects of Knowledge Management (PAKM ) Conference, Basel, Switzerland. Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Design Patterns - Elements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley. Georgakopoulos, D., Hornick, M., & Sheth, A. (1995). An Overview of Workflow Management: From Process Modeling to Workflow Automation Infrastructure. Distributed and Parallel Databases, 3, 119-153. Goguen, J. A. (1996). Formality and Informality in Requirements Engineering. Paper presented at the Fourth International Conference on Requirements Engineering. DA111-SotA-v1.0 PUBLIC Page 184 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 Grasso, A., Meunier, J.-L., Pagani, D., & Pareschi, R. (1997). Distributed Coordination and Workflow on the World Wide Web. Computer Supported Cooperative Work, 6, 175-200. Groth01: Groth, A.; Schwermer, M.: Model Based Process Analysis for Suitable CAD/CAM -Application in Automotive Industry, Proceedings of 27th ISATA'94, p. 487-493, Aachen, 1994. Harel, D. (1987). Statecharts: A Visual Formalism fro Complex Systems. Science of Computer Programming, 8, 231-274. Heinl, P., Horn, S., Jablonski, S., Neeb, J., Stein, K., & Teschke, M. (1999). A Comprehensive Approach to Flexibility in Workflow Management Systems. Paper presented at the ACM Work Activities Coordination and Collaboration Conference (WACC), San Francisco, USA. Herrmann, T. (2000). Evolving Workflows by User-driven Coordination. Paper presented at the DCSCW Conference, München, Germany. Hitomi, A. S., & Le, D. (1998, October). Endeavors and Component Reuse in Web-Driven Process Workflow. Paper presented at the California Software Symposium. Huhns, M. N., & Singh, M. P. (1998). Workflow Agents. IEEE Internet Computing, 2(4). Haake, J. M., & Wang, W. (1997). Flexible Support for Business Processes: Extending Cooperative Hypermedia with Process Support. Paper presented at the ACM GROUP Conference, Phoenix, Arizona USA. Jørgensen, H. D. (2001). Interaction as a Framework for Flexible Workflow Modelling. Paper presented at the ACM GROUP Conference, Boulder, USA. Jørgensen, H. D. (2003). Model-driven work management services. Paper presented at the Concurrent Engineering (CE) Conference, Madeira, Portugal. Jørgensen, H. D. (2004). Interactive Process Models. Unpublished PhD, Norwegian University of Science and Technology, Trondheim, Norway. Jørgensen, H. D., & Carlsen, S. (1999, November 9). Emergent Workflow: Integrated Planning and Performance of Process Instances. Paper presented at the Workflow Management Conference, Münster, Germany. Jørgensen, H. D., Krogstie, J., Ohren, O. P., & Johnsen, S. G. (2003). Interactive Models for Tailorable and Evolving Information Systems. Journal of Applied Systems Studies. Kahler, H., Mørch, A., Stiemerling, O., & Wulf, V. (2000). Special Issue on Tailorable Systems and Cooperative Work. Computer Supported Cooperative Work, 9(1). Kammer, P. J., Bolcer, G. A., Naylor, R. N., & Bergman, M. (2000). Techniques for Supporting Dynamic and Adaptive Workflow. Computer Supported Cooperative Work, 9(3-4), 269-292. Kiczales, G., Lamping, J., Lopes, C. V., Maeda, C., Mendhekar, A., & Murphy, G. (1997). Open Implementation Design Guidelines. Paper presented at the International Conference on Software Engineering (ICSE), Boston, USA. Klein, M. (1998, November 14). Workshop: Towards Adaptive Workflow Systems. Paper presented at the ACM CSCW Conference, Seattle. Klein, M., & Dellarocas, C. (2000). A Knowledge-based Approach to Handling Exceptions in Workflow Systems. Computer Supported Cooperative Work, 9(3-4), 399-412. Klein, M., Dellarocas, C., & Bernstein, A. (2000). Special Issue on Adaptive Workflow Systems. Computer Supported Cooperative Work, 9(3-4). Konstantas, D., Morin, J.-H., Barziv, O., Koumpis, A., & Kobel, C. (2000). Active Business Objects (ABOs): A Novel Paradigm for Building (and Using!) Business Information Systems. In D. Tsichritzis (Ed.), Internet Objects. Switzerland: Centre Universitaire d'Informatique, Université de Genéve. Kosoresow, A. P., & Kaiser, G. E. (1998). Using Agents to Enable Collaborative Work. IEEE Internet Computing, 2(4). DA111-SotA-v1.0 PUBLIC Page 185 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 Kuntz, J. C., Christiansen, T. R., Cohen, G. P., Jin, Y., & Levitt, R. E. (1998). The Virtual Design Team: A Computational Simulation Model of Project Organisations. Communications of the ACM, 41(11), 84-92. Lawton, G. (2001). Knowledge Management: Ready for Prime Time? IEEE Computer, 34(2), 12-14. Lillehagen, F., Dehli, E., Fjeld, L., Krogstie, J., & Jørgensen, H. D. (2002, May 1-3). Active Knowledge Models as a Basis for an Infrastructure for Virtual Enterprises. Paper presented at the IFIP Conference on Infrastructures for Virtual Enterprises (PRO-VE), Sesimbra, Portugal. Luo, Z., & Sheth, A. (1998, November 14). Defeasible Workflow, its Computation and Exception Handling. Paper presented at the ACM CSCW Workshop: Towards Adaptive Workflow Systems, Seattle. Luo, Z., Sheth, A., Kochut, K., & Miller, J. (2000). Exception Handling in Workflow Systems. Applied Intelligence, 13(2). Malone, T. W., Crowston, K., Lee, J., & Pentland, B. (1993). Tools for inventing organisations: Toward a handbook of organisational processes. Paper presented at the IEEE Workshop on Enabling Technologies Infrastructure for Collaborative Enterprises, Morgantown, USA. Malone, T. W., Lai, K.-Y., & Fry, C. (1995). Experiments with Oval: A Radically Tailorable Tool for Cooperative Work. ACM Transactions on Information Systems, 13(2), 177-205. Manolescu, D. A., & Johnson, R. E. (1999). Dynamic Object Model and Adaptive Workflow. Paper presented at the OOPSLA Workshop on Metadata and Active Object-Model. Mehandjiev, N., Bottaci, L., & Phillips, R. (1994). User Enhancability for Fast Response to Changing Office Needs. Paper presented at the 27th Annual Hawaii International Conference on System Sciences (HICSS-27). Meijler, T. D., Kessels, H., Vuijst, C., & le Comte, R. (1998, November 14). Realising Run-time Adaptable Workflow by means of Reflection in the Baan Workflow Engine. Paper presented at the ACM CSCW Workshop: Towards Adaptive Workflow Systems, Seattle. Miers, D. (1998). Vectus Version 3 (Evaluation Report No. 1-Oct-1998 1:1). UK: Enix. Miers, D., & Hunt, R. (1995). Process Product Watch - Work Management Technologies Report - Evaluation Framework Process Support Systems. UK: Enix. Miers, D., & Hutton, G. (1996). The Business Case for Case Handling. UK: Enix. Morgan, G. (1986). Images of Organisation. Beverly Hills: Sage. Myers, B. A., McDaniel, R., Miller, R., Ferrency, A. S., Faulring, A., Kyle, B. D., et al. (1997). The Amulet Environment: New Models for Effective User Interface Software Development. IEEE Transactions on Software Engineering, 23(6), 347-365. Natvig, M. K., & Ohren, O. (1999). Modelling shared information spaces (SIS). Paper presented at the ACM GROUP Conference, Phoenix, Arizona USA. Neeb, J. (2000, December 2). Supporting Dynamic Organisational Processes by Administration Workflows. Paper presented at the ACM CSCW Workshop: Beyond Workflow Management, Philadelphia, USA. Nwana, H. S. (1996). Software Agents: An Overview. Knowledge Engineering Review, 11(3). Pinkwart, N., Hoppe, U., & Grasser, K. (2001, September 6-8). Integration of Domain-Specific Elements into Visual Language Based Collaborative Environments. Paper presented at the CRIWG Workshop, Darmstadt, Germany. Rodden, T. (1996). Populating the Application: A Model of Awareness for Cooperative Applications. Paper presented at the ACM CSCW Conference, Boston, USA. Rolfsen, R. K. (1997). Distribuert Samarbeid- Hva skjer? (Distributed Work - What's happening?). Unpublished M.Sc., Department of Informatics, University of Oslo, Norway. Sandor, O., Bogdan, C., & Bowers, J. (1997). Aether: An Awareness Engine for CSCW. Paper presented at the ECSCW Conference, Lancaster, UK. DA111-SotA-v1.0 PUBLIC Page 186 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 Sarin, S. (1995, 14. August). Flexible Workflow Architectures: The New Adaptive Workflow. Paper presented at the Workflow Conference, San-Jose, USA. Sarin, S. K., Abbott, K. R., & McCarthy, D. R. (1991). A Process Model and System for Supporting Collaborative Work. Paper presented at the ACM Conference on Organisational Computing Systems (COOCS). Shipman, F., Airhart, R., Hsieh, H., Maloor, P., Moore, J. M., & Shah, D. (2001). Visual and Spatial Communication and Task Organisation Using the Visual Knowledge Builder. Paper presented at the ACM GROUP Conference, Boulder, USA. Shipman, F. M., & Marshall, C. C. (1999). Formality Considered Harmful: Experiences, Emerging Themes, and Directions of Use of Formal Representations in Interactive Systems. Computer Supported Cooperative Work, 8(4), 333-352. Shipman, F. M., & McCall, R. J. (1994). Supporting knowledge-base evolution with incremental formalisation. Paper presented at the ACM Human Factors in Computing Systems Conference, Boston, MA. Shipman, F. M., & McCall, R. J. (1999). Incremental formalisation with the hyper-object substrate. ACM Transactions on Information Systems, 17(2), 199-227. Singh, M. P. (1999). Conceptual Modeling for Multiagent Systems: Applying Interaction-Oriented Programming. In P. P. Chen, J. Akoka, H. Kangassalo & B. Thalheim (Eds.), Conceptual Modelling. Berlin, Germany: Springer LNCS 1565. Swenson, K. D., Maxwell, R. J., Matsumoto, T., Saghari, B., & Irwin, I. (1994). A Business Process Environment Supporting Collaborative Planning. Journal of Collaborative Computing, 1(1), 15- 34. Taylor, F. W. (1911). The Principles of Scientific Management. Mineola, New York, USA: Dover Publications, Inc. (this edition 1998). Teege, G. (1994). HieraStates: Flexible Interaction with Objects (Report No. TUM-I9441): Technische Universität München. Teege, G. (1996, October 30-31). HieraStates: Supporting Workflows which Include Schematic and Ad-Hoc Aspects. Paper presented at the Practical Aspects of Knowledge Management (PAKM ) Conference, Basel, Switzerland. Teege, G. (2000). Users as Composers: Parts and Features as a Basis for Tailorability in CSCW Systems. Computer Supported Cooperative Work, 9(1), 101-122. Trigg, R. H., & Bødker, S. (1994, October 22-26). From Implementation to Design: Tailoring and the Emergence of Systematisation in CSCW. Paper presented at the ACM CSCW Conference, Chapel Hill, North Carolina, USA. Tølle, M., Bernus, P., & Vesterager, J. (2002, May 1-3). Reference Models for Virtual Enterprises. Paper presented at the IFIP Conference on Infrastructures for Virtual Enterprises (PRO-VE), Sesimbra, Portugal. Wang, A. I. (2001). Using a Mobile, Agent-based Environment to Support Cooperative Software Processes. Unpublished PhD, Norwegian University of Science and Technology, Trondheim, Norway. Wasserschaff, M., & Bentley, R. (1997). Supporting Cooperation through Customisation: The Tviews Approach. Computer Supported Cooperative Work, 6, 303-325. Wegner, P. (1997). Why interaction is more powerful than algorithms. Communications of the ACM, 40(5), 80-91. Wegner, P., & Goldin, D. (1999). Interaction as a Framework for Modeling. In P. P. Chen, J. Akoka, H. Kangassalo & B. Thalheim (Eds.), Conceptual Modeling. Berlin, Germany: Springer LNCS 1565. Wenger, E. (1998). Communities of Practice. Learning Meaning and Identity. Cambridge, UK: Cambridge University Press. DA111-SotA-v1.0 PUBLIC Page 187 IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Enterprise Modelling in the Context of Collaborative Enterprises ATHENA - Project Number A1 Document Deliverable D.A1.1.1 Date 23/07/2004 WfMC. (2000). Workflow Handbook 2001. Lighthouse Point, Florida, USA: Workflow Management Coalition, Future Strategies Inc. Willumsen, G. (1993). Executable Conceptual Models in Information Systems Engineering. Unpublished PhD, Norwegian Institute of Technology, Trondheim, Norway. Young, P. S. C. (1994). Customizable Process Specification and Enactment for Technical and Non- Technical Users. Unpublished PhD, University of California, Irvine, USA. Aalst, W. M. P. v. d. (1999). Formalisation and Verification of Event-driven Process Chains. Information and Software Technology, 41(10), 639-650. Aalst, W. M. P. v. d., & Basten, T. (1997). Life-cycle Inheritance: A Petri-net-based approach. In P. Azema & G. Balbo (Eds.), Application and Theory of Petri Nets (pp. 62-81). Berlin, Germany: Springer LNCS 1248. Aalst, W. M. P. v. d., & Berens, P. J. S. (2001). Beyond Workflow Management: Product-Driven Case Handling. Paper presented at the ACM GROUP Conference, Boulder, USA. Aalst, W. v. d., Desel, J., & Oberweis, A. (2000). Business Process Management. Berlin, Germany: Springer LNCS 1806. Aalst, W. v. d., Moldt, D., Valk, R., & Wienberg, F. (1999, November 9). Enacting Interorganisational Workflows Using Nets in Nets. Paper presented at the Workflow Management Conference, Münster, Germany. ISO/FDIS 15745-1:2002(E), Industrial automation systems and integration — Open systems application integration framework — Part 1: Generic reference description, ISO TC 184/SC 5/WG 5, 2002-04-26 DelaHostria EM, (2003), Interoperability of standards to support application integration, In Proc. of ICEIMT97: Enterprise Inter-and-Intra Organisational integration: Building international consensus, Eds.: K. Kosanke et al., Springer, 2003. [1] Spath, D., Baumeister, M., Barrho, T., Dill, C.: Change Management im Wandel. In: Industrie Management – Zeitschrift fuer industrielle Geschaeftsprozesse, 4/2001, pp. 9-13. [2] Collins, J.: Good to Great – Why some companies make the leap…and others don’t. New York 2001. [3] Hammer, M., Stanton, S.: The Reengineering Revolution. Glasgow 1995. [4] Kotler, P.; Bliemel, F.: Marketing-Management, 8th ed., Stuttgart 1995. [5] Scheer, A.-W.: ARIS – Business Process Frameworks, 3rd ed., Berlin, 1998. [6] Scholz, T.; Wagner, K.: ARIS Process Platform and SAP NetWeaver: Next Generation Business Process Management, in: Scheer, A.-W. et al. (ed.): ARSI in Practice: Business Process Automation, Berlin, 2004, pp. 29-37. [7] Scheer, A.-W.: ARIS – Business Process Modeling, 3rd ed., Berlin, 1999. [8] Hammer, M., Champy, J.: Business Reengineering: Die Radikalkur fuer das Unternehmen, 5. ed., Frankfurt/Main;New York 1995. [9] Harrington, H. J.: Business Process Improvement, New York et al. 1991. DA111-SotA-v1.0 PUBLIC Page 188