EM1 - Enterprise
Modelling as a way
to achieve
Interoperability
Module 4 - How does Enterprise
Modelling address these
interoperability issues?
© 2005-2006 The ATHENA Consortium.
Module 4 - How does Enterprise Modelling
address these interoperability issues?
Module Structure:
1. Model Driven Architecture (MDA)
2. Introduction to POP*
3. Modelling Platform for Collaborative Enterprises
(MPCE)
4. Execution Platforms, Infrastructures and Tools
5. Model Generated Workplaces (MGWP)
© 2005-2006 The ATHENA Consortium.
2
What is MDA?
Model Driven Architecture (MDA)
is a new way to look at software
development, from the point of view
of the models.
"The MDA defines an approach to
system
specification
that
distinguishes
between
system
functionality specification and the
implantation of this functionality
taking into account a platform
consideration."
MDA provides a means to
transform the system specifications
into a platform dependent system.
© 2005-2006 The ATHENA Consortium.
3
MDA Transformation and Code generation
© 2005-2006 The ATHENA Consortium.
4
How to advance in the MDA adoption
© 2005-2006 The ATHENA Consortium.
5
MDA and Interoperability
MDA approach tries to build a interoperable model, from enterprise
models and processes to apply MDA mechanisms.
© 2005-2006 The ATHENA Consortium.
6
Introduction to POP*
The POP* Methodology aims to
provide a mechanism that allows the
exchange of different enterprise
models without loss of information.
Five dimensions are included in
POP*,
namely
the
Process,
Organisation, Product, Decision
and Infrastructure dimensions.
© 2005-2006 The ATHENA Consortium.
7
General Concepts
The General Concepts package includes concepts and relationships that are
applicable for use in any dimension.
An Enterprise Object may represent anything or
anybody that performs work, makes something
happen or is just part of some activity in the
enterprise.
An Enterprise Object takes part in the enterprise
through playing roles
Enterprise
Objects
may
have
capabilities, and may have a location.
© 2005-2006 The ATHENA Consortium.
certain
8
Process Dimension
The Process Dimension includes constructs related to activities, tasks and
processes going on in the enterprise or between enterprises.
Process Roles, in addition to being Decision
Points may have Enterprise Objects attached
to them via the “plays role” relationship.
A Flow is a relationship between two Decision
Points; Process Roles (input, output, control,
or resource) or Gateways in a process.
Decision Point is a generic concept
representing anything which – when
interconnected by Flows – defines the overall
process sequence.
Gateways are Decision Points owned by a
Process.
Process is used to represent processes, tasks
and activities of any kind.
© 2005-2006 The ATHENA Consortium.
9
Organisation Dimension
The Organisation Dimension focuses on organisational structures, as well
as members and positions thereof. Also, focus is set on interaction between
structures, both as a whole and between members.
Organisation Unit is a specialisation of
Enterprise
Object
used
to
represent
organisations and parts of organisations of any
kind.
Organisation Role is a subtype of Role which is
defined in the context of an organisation.
Examples are: President, General manager,
Department manager, Front desk clerk, etc.
A Person designates an individual human being.
© 2005-2006 The ATHENA Consortium.
10
Product Dimension
The Product Dimension is used to model product architectures or product
structures, for the purpose of design, development and engineering, or
product data management.
A Product Concept is a specialisation of Enterprise Object, and
represents an idea or a notion of a product, including the
characteristics and features of the product.
Product Element is a specialisation
of
Enterprise
Object,
and
designates objects used to build
typical product structures.
Product Function represents part of an answer
to a question about why a product evolved or
was designed to achieve some goal.
© 2005-2006 The ATHENA Consortium.
11
Decision Dimension
The Decision Dimension is concerned with the collection of concepts and
constructs that allow describing the decision-making structure in terms of
decision centres and decision activities.
Decision Structure is defined in terms of
decision centres and decision links as well as
information links between decision centres.
Decision Activity is a specialisation of Process
and aims at making a choice, more specifically
choosing between different courses of action.
© 2005-2006 The ATHENA Consortium.
Decision Centres are ‘places’ where
decisions are taken according to
objectives and under constraints.
12
Infrastructure Dimension
The purpose of the Infrastructure Dimension is to support modelling of
infrastructures and the services they provide.
is part of
0..*
IT Infrastructure
0..*
0..*
Logical Architecture
has architecture
0..*
0..*
0..*
provides
consists of
0..*
IT Service
0..*
IT Infrastructure represents the set of
interconnected components that provide
the services required to support IT
activities.
is part of
connected to
0..* 0..*
0..*
0..*
Logical Architecture
Element
0..*
Logical
Architecture
represents
a
structure of logical components combined
to serve a specific purpose.
0..*
corresponds to
is part of
0..*
encapsulates
0..*
0..*
An IT Service is
equivalent of a good.
IT Component
0..*
uses
the
non-material
0..*
0..*
performs
Application
is part of
0..*
0..*
© 2005-2006 The ATHENA Consortium.
Technology
Component
0..*
IT Component
Function
0..*
13
What is a MPCE?
The Modelling Platform for Collaborative Enterprises (MPCE) is envisioned
to become part of a general core enterprise modelling and execution platform.
The MPCE will therefore provide generic repeatable modelling, model execution,
knowledge management capabilities and services required to build more
purpose and user specific platforms.
© 2005-2006 The ATHENA Consortium.
14
Usage scenarios of a MPCE (Scenario 1)
MPCE will provide structures and services to develop interchangeable enterprise
models. The main usage scenarios for the modelling platform are the following:
Scenario 1. MPCE used in a single enterprise, with one EM tool
Use the MPCE as the new platform within one enterprise that currently uses only
one enterprise modelling (EM) tool. This would simply mean that the EM tool uses
MPCE as its repository, as shown in this figure (legend on the right):
© 2005-2006 The ATHENA Consortium.
15
Usage scenarios of a MPCE (Scenario 2)
Scenario 2. MPCE Used in a single enterprise, with multiple EM tools
Use MPCE as the new platform within one enterprise, to integrate models and
capabilities from various enterprise modelling tools. This would mean that the EM
tools use MPCE as their common repository and service provider, transforming
their knowledge models into a suitable MPCE format during load and save.
© 2005-2006 The ATHENA Consortium.
16
Usage scenarios of a MPCE (Scenario 3)
Scenario 3. MPCE Used as main storage repository between enterprises
Use MPCE to share new enterprise models when two enterprises both use
enterprise tools that can directly share models in the MPCE repository.
© 2005-2006 The ATHENA Consortium.
17
Usage scenarios of a MPCE (Scenario 4)
Scenario 4. MPCE Used as exchange repository between enterprises
Use MPCE to exchange (part of) existing enterprise models between two
enterprises that are using different and non-interoperable enterprise modelling
tools.
© 2005-2006 The ATHENA Consortium.
18
The MPCE Architecture
The main idea is to have a
general platform with a
central knowledge repository,
providing basic services. The
services can then be invoked
from models and modelgenerated views.
The main parts in the MPCE
architecture are:
POP*
enterprise
model
repository
• Modelling support services
• Administration services
• Repository services
© 2005-2006 The ATHENA Consortium.
19
Execution Platforms,
Infrastructures and Tools
Models are defined as explicit representations of some portions of reality as
perceived by some actor.
A model is active if it directly influences the reality it reflects.
Model activation involves actors interpreting the model and adjusting their
behaviour accordingly.
By updating an interactive model, users can adapt the system to fit their local
plans, preferences and terminology. This concurrent activation and articulation
(modelling) is depicted in the Figure.
© 2005-2006 The ATHENA Consortium.
20
Activation and articulation
An interactive execution architecture makes no separation between build time and
run time.
The modelling editor's visualisation capabilities can be a powerful activation tool 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, 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.
© 2005-2006 The ATHENA Consortium.
21
Complementary execution platforms
• To the left, we find conventional software development approaches, viable for
work processes that are following a predefined structure.
• Service oriented architectures offer increased runtime flexibility in service
discovery and selection, composition and choreography.
• Business process automation are even more flexible, enabling direct execution of
business process and workflow models.
© 2005-2006 The ATHENA Consortium.
22
Model Generated Workplaces
The Model Generated Workplaces
(MGWP) connect different kind of work
activities between different organisations
by keeping individual and adapted work
environments.
MGWP contains two interconnected parts:
• Navigation View is based on a holistic
enterprise model and provides enterprise
standards,
templates
and
the
relationships between actors along the
lifecycles.
• Workplace View is related to enterprise
projects, tailored from the company’s
enterprise model and adapted to certain
project needs.
© 2005-2006 The ATHENA Consortium.
23
Model Generated Workplaces (2)
MGWP increase interoperability between different actors in the enterprise in
case of:
• Not very repetitive activities
• Processes that can not be totally planned in advanced
• Collaborative work whilst sequences are not fully predictable
• Situated work
MGWP will not replicate legacy systems but will link to them as much as
possible.
MGWP ensure:
• Navigation through the organisational assets
• Consistency between the different work places related to a project
MGWP are used for:
• Customisation of a distinct work place
• Analysing effect for changes inside projects
© 2005-2006 The ATHENA Consortium.
24
MGWP concept and related views
for a quality engineer - overview
As an example, the figures present the
workplace for a quality engineer.
• On one hand there is the process
assistant
that
supports
the
navigation through all enterprise
processes related to the Product
Portfolio Management.
• On the other hand the work place
of a quality engineer.
© 2005-2006 The ATHENA Consortium.
25
Quality Engineer:
Detailed view of the work model
In the figure the overview of the workplace is described.
© 2005-2006 The ATHENA Consortium.
26
Quality Engineer:
Detailed view of the work model (2)
The specific view of standards and certifications which have to be observed are
described.
© 2005-2006 The ATHENA Consortium.
27
This course has been developed under the funding of the EC with the support of the EC ATHENA-IP Project.
Disclaimer and Copyright Notice: Permission is granted without fee for personal or educational (non-profit) use, previous notification is needed. For
notification purposes, please, address to the ATHENA Training Programme Chair at [email protected]. In other cases please, contact at the same e_mail address
for use conditions. Some of the figures presented in this course are freely inspired by others reported in referenced works/sources. For such figures copyright
and all rights therein are maintained by the original authors or by other copyright holders. It is understood that all persons copying these figures will adhere to
the terms and constraints invoked by each copyright holder.
© 2005-2006 The ATHENA Consortium.
28