1 ATHENA Final Review, 28 March 2007 – © ATHENA Consortium Project A4 Claudia Guglielmina, TXT...
-
Upload
julius-bond -
Category
Documents
-
view
217 -
download
0
Transcript of 1 ATHENA Final Review, 28 March 2007 – © ATHENA Consortium Project A4 Claudia Guglielmina, TXT...
1ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
Project A4Claudia Guglielmina, TXT e-solutions
Arne-Jørgen Berre, SINTEF
ATHENA Final Review27 - 29 March 2007Madeira, Portugal
2ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
Project goals
● To synthesise the results of the research performed in Action Line A projects into a conceptual, applicative and technical ATHENA Interoperability Framework (AIF) and instantiating it to the ATHENA Interoperability Profiles (AIPs) needed to implement the Action Line B scenarios (WPA4.2 –> DA4.2)
● To detail the technical AIF, Product/Process Interoperability frameworks, and to validate results against the requirements by describing the identified profiles
(WPA4.3 –> DA4.3, WPA4.4 –> DA4.4) and DA4.6 (Validation)
● To define and implement a Suite of Software Services to cover the whole life cycle of the implementation of an interoperability project (WPA4.5, WPA4.6 –> DA4.5)
3ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
ATHENA A4 deliverablesD.A4.2
Specification of InteroperabilityFramework and
Profiles, Guidelines and Best Practices
D.A4.3Product-based Interoperability Infrastructure
D.A4.4Process-based Interoperability Infrastructure
D.A4.5Interoperability
Life-cycleServices
specifications
D.A4.6Validation of
ResearchResults
Enterprise Modelling Tool
Web Browser
Modeling tool interface
Repository
Collaboration space portal
Task Mngmt
Web Service Plugin
Model Generated Workplace
View Mngmt
Role Mngmt
Enterprise Modelling Tool
Web Browser
Modeling tool interface
Repository
Collaboration space portal
Task Mngmt
Web Service Plugin
Model Generated Workplace
View Mngmt
Role Mngmt
Process infrastructure
Product infrastructure
AIF Website
Projectsupportsuite
4ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
Presentation outline and speakers
Topic PresenterIntroduction Arne-Jørgen Berre, SINTEF
ATHENA Interoperability Framework (AIF) – Overview
AIF – Conceptual integration Brian Elvesæter, SINTEF
AIF – Applicative integration
AIF – Technical integration
ATHENA Interoperability Profiles (AIPs)
Application of the AIF Thomas Knothe, IPK
Validation of results Lorenzo Pondrelli, FORMULA
Conclusions and future work Claudia Guglielmina, TXT
6ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
ATHENA Interoperability Framework (AIF)
Conceptual integration
- Reference architecture- Concepts- Models and metamodels- Languages
Technical integration
- Modelling tools- Execution environments
Applicativeintegration
- Methodologies- Use cases- Reference examples
Sources and usage of the AIF
integratesresearchresults ofAL A
integrates prototypesof AL Aprojectsfor a givenprofile
integrates experience from AL A prototypes and B5 technology testing
used in B5 for technology testing based on profiles
used for further identification of research requirements
used for transfer of knowledge regarding application of integration technologies
7ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
AIF success criteria (research and development)● Holistic, generic, configurable and extensible solution approach
to interoperability.
● By holistic we mean that the framework should capture and inter-relate information from many perspectives covering business, knowledge, technical (ICT) and semantic issues relevant to interoperability.
● By generic we mean that the framework should be applicable and usable in numerous user scenarios having different interoperability requirements.
● By configurable we mean that the framework should allow to be customised to specific application domains and industry sectors.
● By extensible we mean that the framework should define guidelines and to include new perspectives according to different business and/or stakeholder concerns.
● Instantiation of the framework with research results from ATHENA.
● By instantiation we mean to successfully integrate results from the three research areas enterprise modelling, architectures and platforms, and ontology of ATHENA.
8ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
Specification and development of the AIF
Foundation
• IDEAS InteroperabilityFramework
• IEEE Std. 1471
ATHENAInteroperabilityFramework (AIF)
• Conceptual integration• Applicative integration• Technical integration
ATHENASolution Space
• Action Line A1-A8• Action Line B3, B4 and B5
Objectives
1. Holistic, generic,configurable andextensible solutionapproach tointeroperability
2. Instantiation of theframework with researchresults from ATHENA.
ATHENA Use Cases
• Aeronautics andaerospace sector
• Automotive sector• Furniture sector• Telecom sector
Achieves
Ap
plic
atio
n
Inp
ut
Principles
ATHENAInteroperabilityProfiles (AIPs)
• (N)CPD profile• e-Procurement profile• PPM profile• SCM profile
Def
ines
Validation of AIFvia pilot experience
9ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
ATHENA Interoperability Reference Architecture
Enterprise/Business
Processes
Services
Information/Data
Cross-OrganisationalBusiness Processes
Collaborative EnterpriseModelling
Flexible Execution and Composition of Services
InformationInteroperability
Mo
del-D
rive
n In
tero
pera
bili
ty
Sem
an
tics
and
On
tolo
gie
s
Enterprise/Business
Processes
Services
Information/Data
Provided Required
11ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
Conceptual integration
● AIF provides a compound framework and associated reference architecture for capturing the research elements and solutions to interoperability issues that address the problem in a holistic way.
● The specification of the AIF has been formalised using a model-driven approach – the AIF conceptual model.
● The conceptual model is structured into separate model packages covering specific concept domains that we see relevant for addressing interoperability.
13ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
Interoperability reference architectureEnterprise/Business
Processes
Services
Information/Data
Cross-OrganisationalBusiness Processes
Collaborative EnterpriseModelling
Flexible Execution and Composition of Services
InformationInteroperability
Mo
del-D
rive
n In
tero
pera
bili
ty
Sem
an
tics
and
On
tolo
gie
s
Enterprise/Business
Processes
Services
Information/Data
Provided Required
16ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
ATHENA Interoperability Methodology (AIM)
Definition
Phases
Analysis Negotiation Realisation Operation Termination
Def. #1 Analyis. #1 Neg. #1 Real. #1 Real. #2 Oper. #1 Term. #1
Iterations
Support disciplines
Interoperability disciplines
Project management
Business collaboration modelling
Testing
Implementation
Interoperability maturity analysis
Deployment and assessment
Analysis and requirements
Solution mapping and design
17ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
Baseline methodology
EIMM
Interoperabilityanalysis
Requirementssolutionmapping
Test definition
Implementation
Testing
IIAM
Implicit strategicbusiness
needs Optimizedco-operation
model
Interoperabilitymaturity and
modelling approach
Requirements related to
business needs
Solution blueprint(generic solutions)
Solution instance(actual solutions)
Testprocedure
Solutionimplementation
ROI(impact)
Methodology overview(V-model view)
Formalized interoperability business needs
BIF
18ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
Requirements – solutions mapping
Interoperability Issues
B4
ATHENA Generic Solution
A4
Specific Solutions
Ax Projects
Specific Requirements
B4
Mapping through filtering based oncontext elements
C
BD
Contextelements
Annotation by the same context
elements
A
19ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
ATHENA Knowledge Base (implemented in Protégé)
20ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
ATHENA Interoperability Methodology (summary)Definition
Phases
Analysis Negotiation Realisation Operation Termination
Def. #1 Analyis. #1 Neg. #1 Real. #1 Real. #2 Oper. #1 Term. #1
Iterations
Support disciplines
Interoperability disciplines
Project management
Business collaboration modelling
Testing
Implementation
Interoperability maturity analysis
Deployment and assessment
Analysis and requirements
Solution mapping and design
EIMM
Interoperabilityanalysis
Requirementssolutionmapping
Test definition
Implementation
Testing
IIAM
Implicit strategicbusiness
needs Optimizedco-operation
model
Interoperabilitymaturity and
modelling approach
Requirements related to
business needs
Solution blueprint(generic solutions)
Solution instance(actual solutions)
Testprocedure
Solutionimplementation
ROI(impact)
Methodology overview(V-model view)
Formalized interoperability business needs
BIF
Interoperability Issues
B4
ATHENA Generic Solution
A4
Specific Solutions
Ax Projects
Specific Requirements
B4
Mapping through filtering based oncontext elements
C
BD
Contextelements
Annotation by the same context
elements
A
ATHENA Knowledge Base(implemented in Protégé)
Tool support
[Deliverable D.A4.5]
23ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
Technical architecture – Services
Enterprise/Business
Processes
Services
Information/Data
Cross-OrganisationalBusiness Processes
Collaborative EnterpriseModelling
Flexible Execution and Composition of Services
InformationInteroperability
Mo
del-D
rive
n In
tero
pera
bili
ty
Sem
an
tics
an
d O
nto
log
ies
Enterprise/Business
Processes
Services
Information/Data
Provided Required
24ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
Example configuration and implementation
MPCE
ServiceCompositionand Execution
Data Access andTransformation
Collaborative Product Design and Development
Enterprise/Business
Processes
Services
Information/Data
Knowledge ModelRepository
Enterprise/Business
Processes
Services
Information/DataXML Messages
Business ProcessModels
WSDL
BPEL
POP*
ConceptualView
“Requirements”
ConceptualView
“Requirements”
Model-GeneratedWorkplace
Model-GeneratedWorkplace
FunctionalView
“BoM”
FunctionalView
“BoM”
Context View“Ramp Up”
Context View“Ramp Up”
Context View“Qualification”Context View“Qualification”
Cross-OrganisationalBusiness Processes
ATHOS
Ontology
A*
Annotations
ReconciliationRules
THEMIS
ARGOS
ARES
Messages/Services
(Johnson)
SOA Modelling andTransformations
BPELExecution
Engine
PIM4SOA
ServiceConfiguration
(Johnson)
XML Schemas
AgentExecution
Framework
CBP Execution(Nehemiah)
Service Access(Gabriel)
CBP Definitions(Maestro
Service Enabling(Gabriel)
25ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
Process-based interoperability infrastructure[Deliverable D.A4.4]
• Service-enabled cross-organisational business processes (CBPs)
• Direct path between business level and design and execution of business processes by service composition
• Model-driven and CBP modelling approach for technical and execution levels
• Link the service level descriptions to the business processes
• Pilot examples:
• CRF Strategic Sourcing
• AIDIMA e-Procurement
26ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
Product-based interoperability infrastructure[Deliverable D.A4.3]
K N O W L E D G E
I N P U T S
S E R V I C E
O U T P U T S
B U S I N E S S
Work together concurrently
Generate seamless workplaces from heterogeneous applications and knowledge sources
Use heterogeneous knowledge sources as if they were just one homogeneous source
Product-based interoperability is characterized by the terms shared knowledge and concurrent access
Both terms refer to a collaborative situation where several people work together on the same product (business object)
The word product is used because product development and product lifecycle management are typical examples
Enterprise Modelling Tool
Web Browser
Modeling tool interface
Repository
Collaboration space portal
Task Mngmt
Web Service Plugin
Model Generated Workplace
View Mngmt
Role Mngmt
Enterprise Modelling Tool
Web Browser
Modeling tool interface
Repository
Collaboration space portal
Task Mngmt
Web Service Plugin
Model Generated Workplace
View Mngmt
Role Mngmt
Pilot examples:• EADS NCPD pilot• INTRACOM PPM pilot
28ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
Interoperability profile
Template for ATHENA Interoperability Profile (AIP)
SolutionsInteroperability issues
Use cases(scenarios)
Standard
ATHENA
External
Use case #nUse case #1
ATHENA
Standard
External
Issue #1
Issue #n
An interoperability profile means a collection of ATHENA generic solutions that work together to solve a set of meaningful interoperability generic problems (interoperability issues).
29ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
Development of interoperability profiles
ATHENA Knowledge Base(implemented in Protégé)
Tool support
Template for ATHENA Interoperability Profile (AIP)
SolutionsInteroperability issues
Use cases(scenarios)
Standard
ATHENA
External
Use case #nUse case #1
ATHENA
Standard
External
Issue #1
Issue #n
30ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
ATHENA Interoperability Profiles (AIPs)ATHENA Interoperability Profile for CPD (Automotive sector)
Solutions
ATHENA Cross-organisational Business ProcessModelling and Enactment
ATHENA Model Exchange and Management
Interoperability issues
Use cases(scenarios)
Standard
ATHENA
External
POP*Metis MO2GO
Maestro
BRMF
Gabriel JohnsonNehemiah
Data FormatInteroperability
Strategic Sourcing Virtual & Physical Testing
ProcessInteroperability
Distributed inconsistent data
Applications focus ontransactions,
not on business processes
MPCE
Business Processes "hard-coded" in applications
PSI Action Plan
OrangeCATnet
ATHENA Interoperability Profile for NCPD (Aerospace sector)
Solutions
Collaborative Service-oriented Execution Platform
ATHENA Cross-organisational Business Process Enactment
NCPD Modellingand Governance
Semantic Mediation
Interoperability issues
Use cases(scenarios)
Standard
ATHENA
External
Liferay
JBOSS
ActiveBPEL
Gabriel JohnsonNehemiah
Eclipse
ArgoUML
Business and ICT Decoupling
Networked Collaborative Product Development
Workflow Interconnection
CollaborationOn the Web
Product Data Exchange, Sharing and Retention
PDM coupling
Shark
Maestro
AndroMDA JaweActiveBPEL
DRD KB
OpenLDAP
XSLT Processor
AndroMDA
STEP Mapper
ManufacturingStandards
XPDI Server of Reference
ATHENA Interoperability Profile for e-Procurement (Furniture sector)
Solutions
e-ProcurementmodellingGRAI Tools
SemanticMediation
Interoperability issues
Use cases(scenarios)
Standard
ATHENA
External
Confusion resulting from poor product
descriptions
Electronic procurement
Missing information,both from supplier
and buyer
Lag. Time from productorder to delivery could
be shorter
Repetitive manual processfor regular bulk orders
Time spent rating supplier
ARGOSA*
ARES
Conformance Test
ATHENACross-
organisationalBusinessProcess
Enactment
Gabriel
Johnson
Nehemiah
EXP2XSD
EXP2SCH
EXP2XMI
Maestro
ATHOS
EXP2PIM4SOA2WSDL
ATHENA Interoperability Profile for PPM (Telecom sector)
SolutionsInteroperability issues
Use cases(scenarios)
Standard
ATHENA
External
Enterprise description andknowledge management
(Near) real-time aggregated views
of key business information
Ability of integrated applications through a single point of entry.
Automatic generation of workplaces
MetisMO2GO Grai
Modelling Suite
MPCEPOP*
Model Management and Sharing
iKnow
ADARESSIS
ECC5
NETWEAVER
MGWP TIP Services for Web services
TIPPA
Model-generatedWorkplaces
Test Driver
Johnson (+Lyndon)
WSDL
Product Portfolio Management
32ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
Inventory Visibility and Interoperability (IV&I) - Introduction
… to model based views required for specification and implementation
Specification andImplementation Assistant
Data Types Requirements
OEMSupplierMaterial Flow
Information Flow
Activity Models
SupplierCustomer Carrier
Communicate Consumed Kanban Container, Activity Diagram
Customer reportsconsumed Kanban
Kanban STATUSSignal: “Consumed”
Receive signalPublish signal
Contents of Kanban container
are Consumed
Supplier consumes/reviews signal
1
This Use Case is optional but recommended as best practice when using IV&I tool.
Tables for Specifying Event Data Types
Communication Event Issued By For P# Kb Id Cust/
Ship to
Supp/ Ship from Kanban Status
Consume Date Time
1 Kanban Consumed Cust Supp M M + + M: "Empty" M 2 Authorized w/ship instr Cust Supp M M + + M: "Authorized" -/- 3 copy of #2 to carrier Cust Carr " " " " " " 4 Kanban Authorized Cust Supp M M + + M: "Authorized" -/- 5 Request for Conveyance Supp Carr M M + + -/- -/- 6 Interoperable ASN Supp Cust M M + + -/- -/- 7 Kanban Received Cust Supp M M + + M: "Full" -/-
XSD – for Messages
<schema targetNamespace="http://www.example.com/Report" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:r="http://www.example.com/Report" xmlns:xipo="http://www.example.com/IPO"
Collaboration Diagramm
Collaboration DiagramMaterials Replenishment Scenario 9.0
Planning/Scheduling
Customer Organization
Manufacturing
Supplier Organization
1: SyncPlanningSchedule - 830 / DELFOR
2: SyncShipmentSchedule - 862 / DELJIT
3: SyncShipment - 856 / DESADV
9: SyncConfirm - 997 / CONTRL
ShippingReceiving
4: SyncDeliveryReceipt - 861 / RECADV
5: UpdateProductRequirement - 846 / INVRPT
6: SyncInventoryBalance - 846 / INVRPT
7: SyncConsumption - 846 / INVRPT
8: SyncQuantityOnHand - New
10: ApplicationConfirm - 824 / APERAK
Use Case Diagram
Send planning information(Out of scope)
Communicate Consumed Kanban
Container
Ship KanbanContainers
Receive KanbanContainers
Financial Settlement(Out of scope)
Electronic Kanban Guideline, Use Case Diagram
Customer
Supplier
Carrier
Authorize KanbanContainer
Textual SpecificationShip Kanban Containers Use Case
Actors Customer, Supplier, Carrier
Purpose To identify the authorized Kanban signals that need to be shipped, if any, and then proceed to ship them and communicate to the customer.
Pre-condition Supplier has received authorized Kanbans signals.
Customer and Supplier have previously agreed on when authorized Kanbans should go into a shipment. It may be explicitly communicated by the Customer (like traditional EDI shipping schedule), or the Supplier may be responsible for making the determination of what to ship and when (new opportunity afforded by web visibility). Note that for any given customer-supplier (and in some exceptions, customer-supplier-item) relationship, only one of the two business partners will make the authorization decision.
When the Carrier provides audit services, the Carrier will be familiar with the replenishment policy of the Kanbans being picked up.
OEMSupplierMaterial Flow
Information Flow
From fragmented disjoined specifications …
33ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
Objectives for application
● Completeness: Identification of all critical items to be covered into the model
● Time: Duration for determining the right modelling approach
● Adaptability: What's happen when the entry point and contingencies are not quite clear
34ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
Scope of the application
EIMM
Interoperabilityanalysis
Requirementssolutionmapping
Test definition
Implementation
Testing
IIAM
Implicit strategicbusiness
needs Optimizedco-operation
model
Interoperabilitymaturity and
modelling approach
Requirements related to
business needs
Solution blueprint(generic solutions)
Solution instance(actual solutions)
Testprocedure
Solutionimplementation
ROI(impact)
Methodology overview(V-model view)
Formalized interoperability business needs
BIF
35ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
BIF profile – To be - Approach
Activity Models
SupplierCustomer Carrier
Communicate Consumed Kanban Container, Activity Diagram
Customer reportsconsumed Kanban
Kanban STATUSSignal: “Consumed”
Receive signalPublish signal
Contents of Kanban container
are Consumed
Supplier consumes/reviews signal
1
This Use Case is optional but recommended as best practice when using IV&I tool.
Tables for Specifying Event Data Types
Communication Event Issued By For P# Kb Id Cust/
Ship to
Supp/ Ship from Kanban Status
Consume Date Time
1 Kanban Consumed Cust Supp M M + + M: "Empty" M 2 Authorized w/ship instr Cust Supp M M + + M: "Authorized" -/- 3 copy of #2 to carrier Cust Carr " " " " " " 4 Kanban Authorized Cust Supp M M + + M: "Authorized" -/- 5 Request for Conveyance Supp Carr M M + + -/- -/- 6 Interoperable ASN Supp Cust M M + + -/- -/- 7 Kanban Received Cust Supp M M + + M: "Full" -/-
XSD – for Messages
<schema targetNamespace="http://www.example.com/Report" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:r="http://www.example.com/Report" xmlns:xipo="http://www.example.com/IPO"
Collaboration Diagramm
Collaboration DiagramMaterials Replenishment Scenario 9.0
Planning/Scheduling
Customer Organization
Manufacturing
Supplier Organization
1: SyncPlanningSchedule - 830 / DELFOR
2: SyncShipmentSchedule - 862 / DELJIT
3: SyncShipment - 856 / DESADV
9: SyncConfirm - 997 / CONTRL
ShippingReceiving
4: SyncDeliveryReceipt - 861 / RECADV
5: UpdateProductRequirement - 846 / INVRPT
6: SyncInventoryBalance - 846 / INVRPT
7: SyncConsumption - 846 / INVRPT
8: SyncQuantityOnHand - New
10: ApplicationConfirm - 824 / APERAK
Use Case Diagram
Send planning information(Out of scope)
Communicate Consumed Kanban
Container
Ship KanbanContainers
Receive KanbanContainers
Financial Settlement(Out of scope)
Electronic Kanban Guideline, Use Case Diagram
Customer
Supplier
Carrier
Authorize KanbanContainer
Textual SpecificationShip Kanban Containers Use Case
Actors Customer, Supplier, Carrier
Purpose To identify the authorized Kanban signals that need to be shipped, if any, and then proceed to ship them and communicate to the customer.
Pre-condition Supplier has received authorized Kanbans signals.
Customer and Supplier have previously agreed on when authorized Kanbans should go into a shipment. It may be explicitly communicated by the Customer (like traditional EDI shipping schedule), or the Supplier may be responsible for making the determination of what to ship and when (new opportunity afforded by web visibility). Note that for any given customer-supplier (and in some exceptions, customer-supplier-item) relationship, only one of the two business partners will make the authorization decision.
When the Carrier provides audit services, the Carrier will be familiar with the replenishment policy of the Kanbans being picked up.
OEMSupplierMaterial Flow
Information Flow
Starting Information Base about the IV&I Business Objectives
Identify BIF ProfileCategory Sub Category 5
(fully interoper
able)
4 (qualified
)
3 (moderat
e)
2 (minimum)
1 (none)
Management of external relationships
Cooperation (management) process
Risk & conflict management
Cooperation contract
Collaborative Business Processes
Public Process
Process visibility
Business semantics (business documents)
Business semantics (master data)
Employees & Culture
Partnership management
Trust
Social capital
Information Systems
Interaction type
Cooperation architecture
Security & Privacy
36ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
BIF profile – To be - ResultCategory Sub Category 5
(fully interoperable)
4 (qualified)
3 (moderate)
2 (minimum)
1 (none)
Management of external relationships
Cooperation (management) process
Risk & conflict management
Cooperation contract
Collaborative Business Processes
Public Process
Business semantics (business documents)
Business semantics (master data)
Employees & Culture
Partnership management
Trust
Social capital
Information Systems
Interaction type
Cooperation architecture
Security & Privacy
Process visibility
Collaborative Business processes - "How do we collaborate with business partners?"
Public Process
A cross-organisational process is the business process between two or more independent partners within a cooperation. It describes the interactions between the partners (activties, responsibilities, input/output, messages). A public process is a special cross-organisational process, that abstracts from internal processes and can be defined independent of internal business processes. It should be clear and well documented, practical and should reflect industry standards.
Approach Public processes are co-defined with business partners and built by consensus, documented and reflect industry standards (n:m)
Cross-organisational processes are defined bilaterally (1:n) while taking into account previous and future cross-organisational business processes (building variants with limited deviations)
Cross-organisational processes are defined bilaterally (1:1) with some partners
"Best practices" are used in cooperations
No awareness of cross-organisational business processes
Deploy Public process is the "standard" cross-organisational process
Number of bilateral process agreements is limited
Bilateral process agreements are prevailing
Few cross-organisational processes are defined
Cross-organisational business processes are not defined
Review & Assess
Cross-organisational process is subject to continuous improvement
Cross-organisational process is adapted regularly to include important changes and new requirements
Updates/changes are initiated externally (requested by dominant partner, changes in legal requirements, …)
None None
37ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
Application of the AIM baseline methodology
EIMM
Interoperabilityanalysis
Requirementssolutionmapping
Test definition
Implementation
Testing
IIAM
Implicit strategicbusiness
needs Optimizedco-operation
model
Interoperabilitymaturity and
modelling approach
Requirements related to
business needs
Solution blueprint(generic solutions)
Solution instance(actual solutions)
Testprocedure
Solutionimplementation
ROI(impact)
Methodology overview(V-model view)
Formalized interoperability business needs
BIF
38ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
EIMM integrated into the Establishment Methodology
Enterprise MaturityCurrent & Future
Business Scope of Modelling Task
ModellingParameter
Model Quality
Assessment according to the Enterprise Interoperability Maturity Model
(EIMM)
Enterprise Model (Execution and continuous improvement
of enterprise model supported collaboration processes)
Deducing the Modelling Approach
&the Methodology
BIF Profile
39ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
Mapping BIF to EIMM - Approach
Identified BIF ProfileCategory Sub Category 5
(fully interoper
able)
4 (qualified
)
3 (moderat
e)
2 (minimum)
1 (none)
Management of external relationships
Cooperation (management) process
Risk & conflict management
Cooperation contract
Collaborative Business Processes
Public Process
Process visibility
Business semantics (business documents)
Business semantics (master data)
Employees & Culture
Partnership management
Trust
Social capital
Information Systems
Interaction type
Cooperation architecture
Security & Privacy
Products & Services
Representation of Products and services
Applications of modelling for products and services
Enterprise Modelling
Products and Services
Process
Organisation
SystemsModelling Aspect
Legal Environment, Security and Trust
System &Technology
Business Strategy and Processes
Collaboration Strategy
Processes
Collaboration
Interfaces
Organisation and Competences
Technical Resources
Interoperability Competences
Modelling Capabilities
Identified EIMM detailed Categories
40ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
BIF – EIMM Mapping - ResultProducts & Services
Representation of Products and services x
Applications of modelling for products and services
x
Enterprise Modelling
Products and Services x
Process x
Organisation x
Systems x
Modelling Aspect x
Legal Environment, Security and Trust x
System &Technology x
Business Strategy and Processes
Collaboration Strategy x
Processes x
Collaboration x
Interfaces x
Organisation and Competences
Technical Resources x
Interoperability Competences x
Modelling Capabilities x
Level 1
Performed
Level 2
Modelled
Level 3
Integrated
Level 4
Interoperable
Level 5
Optimized
41ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
Model granularity
ProcessValue Chain
Work Process
Activity PropertiesProperty
Values
OrganisationOrg –
StructureRoles
Respon-sibilities
Capability Types
Org, CapabilitiesCapacities
ProductGeneral Product
Structure
Detailed Product
Structure
General BOM
BOM Variants
Behaviour of Product elements
SystemsGeneral Systems elements
General Systems
Architectures
Systems Roles
(Services)
Systems Capabilities
Systems CapabilitiesCapacities
Model CompletenessPragmatic
sSyntax
Semantics Constructs
Semantics Data
SemanticsData
Level of Formalization
Business Analyst
Perspective
Technical Business Process
Perspective
Implemen-tation
Perspective
Execution Data Type Perspective
Execution Data
Perspective
Mapping to Modelling Concept - Target
Focuses on the level of detail of the collaboration that should be regarded. Here the Enterprise Aspects are covered - as now included into the ISO 19440 „Constructs for Enterprise Modelling
Aims at supporting the user to achieve an accurate visualisation of the interested aspects. Perspective of the model. The idea is to focus the different requirements for the model that can be deduced from the scope
42ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
Modelling Parameters
Model granularity
Process Value Chain Work Process Activity PropertiesProperty
Values
OrganisationOrganisation
StructureRoles Responsibilities Capability Types
Org, CapabilitiesCapacities
ProductGeneral Product
StructureDetailed Product
StructureGeneral BOM BOM Variants
Behaviour of Product elements
SystemsGeneral Systems
elementsGeneral Systems
ArchitecturesSystems Roles
(Services)Systems Capabilities
Systems CapabilitiesCapacities
Model Completeness Pragmatics Syntax Semantics Constructs Semantics DataSemantics
Data
Level of FormalizationBusiness Analyst
PerspectiveTechnical Business Process Perspective
Implementation Perspective
Execution Data Type Perspective
Execution Data Perspective
Minimum EIMM Assessment
Products & ServicesRepresentation of Products and services x
Applications of modelling for products and services
x
Enterprise ModellingProducts and Services x
Process xOrganisation x
Systems xModelling Aspect x
Legal Environment, Security and Trust x
System &Technology xBusiness Strategy and Processes
Collaboration Strategy xProcesses x
Collaboration xInterfaces x
Organisation and CompetencesTechnical Resources x
Interoperability Competences xModelling Capabilities x
Level 1
Performed
Level 2
Modelled
Level 3
Integrated
Level 4
Interoperable
Level 5
Optimized
Deducing Example
Mapping EIMM to Modelling Parameters
43ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
Application of the AIM baseline methodology
EIMM
Interoperabilityanalysis
Requirementssolutionmapping
Test definition
Implementation
Testing
IIAM
Implicit strategicbusiness
needs Optimizedco-operation
model
Interoperabilitymaturity and
modelling approach
Requirements related to
business needs
Solution blueprint(generic solutions)
Solution instance(actual solutions)
Testprocedure
Solutionimplementation
ROI(impact)
Methodology overview(V-model view)
Formalized interoperability business needs
BIF
44ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
Approach – Perform Functional Analysis based on AIF Railroad and required Interoperability Functions
DRDS Knowledge BaseInteroperability Functions
MO2GO
Data
Services
Business
Construction of Cross-Organisational Business Processes
Enterprise Modelling in the context of Collaborative Enterprises
Flexible Execution and Composition of Services
Data TransformationM
DD
Sem
anti
c
Processes
Data
Services
Processes
Business
ATHENA Railroad
Business Needs and Requirements
AIAG Scenario
List of generic functions
45ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
Functional Analysis – Result for AIAG Scenario
• Model related Solutions– Create Model– Execute Model (transform
data)– Transform Model
horizontal/– Transform Model vertical)– Enrich models– Create compatible views of
a model – Mapping of data in models
• SW Component related solution– Searching– Selecting– Invocation
• Analysis and Testing– Assessment– conformance test,– logic test – performance test– Search for content
• Connectivity– Naming– Provide Connection – Routing (messages and
models)
46ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
Application of the AIM baseline methodology
EIMM
Interoperabilityanalysis
Requirementssolutionmapping
Test definition
Implementation
Testing
IIAM
Implicit strategicbusiness
needs Optimizedco-operation
model
Interoperabilitymaturity and
modelling approach
Requirements related to
business needs
Solution blueprint(generic solutions)
Solution instance(actual solutions)
Testprocedure
Solutionimplementation
ROI(impact)
Methodology overview(V-model view)
Formalized interoperability business needs
BIF
47ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
Requirements – solutions mapping
Interoperability Issues
B4
ATHENA Generic Solution
A4
Specific Solutions
Ax Projects
Specific Requirements
B4
Mapping through filtering based oncontext elements
C
BD
Contextelements
Annotation by the same context
elements
A
Functions
48ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
Context elements modelled in Protégé – Business needs and Generic solutions are annotated with these classes
49ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
Example - Mapping Generic to Specific Solution
50ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
Mapping Solution - Summary
Generic solution Specific solution1. Assessment BIF, EIMM
2. Model creation MO²GO tool
3. Model enrichment MO²GO tool
4. Common views creation
Process Assistant application
5. Horizontal model transformation
Model exchange POP*, IEM to POP*, ARIS to POP* , GRAI to POP*
51ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
Concluding remarks on AIF application in the IV&I pilot
● Completeness: Identification of all critical items to be covered into the model – By applying BIF and EIMM the precision of the to-be modelling concept was very convincing e.g. some aspects were not foreseen in before hand by using traditional approaches
● Time: Duration for determining the right modelling approach - Elaboration of Modelling Concept based on BIF and EIMM was quite fast – less than 1hour
● Adaptability: What's happen when the entry point and contingencies are not quite clear – e.g. Functional Analysis and Assessment were done in parallel Methodology parts needs to be more modular and need a more precise architecture for that
53ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
Validation methodology [Deliverable D.A4.6]The methodology used for the validation of the other A4 results has been adapted to the theoretical nature of the AIF. Instead of the Athena Requirements and the Business needs used for the validation of the A4 tools, the AIF Success Criteria have been applied. In this context no quantitative measurement has been achieved but only qualitative variables:
No Success Criteria Validation approach
1 Holistic approach to interoperability Qualitative validation based on the results of the mapping approach.
2 Generic approach to interoperability Qualitative evaluation based on the experience of applying and using AIF within
6 ATHENA scenarios.
3Configurable approach to
interoperability Validation as part of future work within new research efforts and/or EIC
activities.
4 Extensible approach to interoperabilityValidation as part of future work within new research efforts and / or EIC
activities.
5Instantiation of AIF with research results from ATHENA
Mapping approach results provide preliminary validation input regarding gaps identified at the different AIF levels.
Pilot activities will provide more specific information related to;o Integrating individual ATHENA solutions success storieso Difficulties in integrating individual ATHENA solutions to solve an
interoperability issue.
54ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
Validation resultsSuccess Criteria Validation results
Holistic approach to interoperability
• Meet successfully the criteria to provide a holistic approach to deal with interoperability problems
• Allows the expression of business needs on all of its levels: business, processes, application and services
• The majority of ATHENA tools address at least one dimension of the framework
Generic approach to interoperability
• The genericity of the approach is difficult to be judged within ATHENA programme
• The validation on our pilot scenarios shows that AIF is considered as generic enough to be used outside ATHENA in other scenarios
Instantiation of AIF with research results from ATHENA
• AIF was used by 7 scenarios, six of which were instantiation into pilots• The instantiations of AIF in the ATHENA scenarios and pilots indicated successful
cases where individual ATHENA solutions were integrated to provide a solution to a complex interoperability issues
• Other cases highlight situation in which the integration was difficult
The identified gaps either in integrating ATHENA solutions for providing an end to end solution to a scenario or in providing a missing functionality is a valuable feedback and input to future research activities aiming at the AIF improvement and enrichment
56ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
Claimed results and major contributions
● ATHENA Interoperability Reference Architecture
● Specification of the ATHENA Interoperability
Framework
● ATHENA Interoperability Methodology (AIM)
● ATHENA Interoperability Profiles and Dynamic
Requirement Definition
● Interoperability Project Support Suite
● Process-based Interoperability Infrastructure
● Product-based Interoperability Infrastructure
Definition
Phases
Analysis Negotiation Realisation Operation Termination
Def. #1 Analyis. #1 Neg. #1 Real. #1 Real. #2 Oper. #1 Term. #1
Iterations
Support disciplines
Interoperability disciplines
Project management
Business collaboration modelling
Testing
Implementation
Interoperability maturity analysis
Deployment and assessment
Analysis and requirements
Solution mapping and design
Enterprise/Business
Processes
Services
Information/Data
Cross-OrganisationalBusiness Processes
Collaborative EnterpriseModelling
Flexible Execution and Composition of Services
InformationInteroperability
Mo
del-D
rive
n In
tero
pera
bili
ty
Sem
an
tics
and
On
tolo
gie
s
Enterprise/Business
Processes
Services
Information/Data
Provided Required
Enterprise Modelling Tool
Web Browser
Modeling tool interface
Repository
Collaboration space portal
Task Mngmt
Web Service Plugin
Model Generated Workplace
View Mngmt
Role Mngmt
Enterprise Modelling Tool
Web Browser
Modeling tool interface
Repository
Collaboration space portal
Task Mngmt
Web Service Plugin
Model Generated Workplace
View Mngmt
Role Mngmt
57ATHENA Final Review, 28 March 2007 – © ATHENA Consortium
Future work
● Towards an operational solution on the
Web
● Definition and implementation of
interoperability service utilities (ISUs)
● Refinement of interoperability profiles
● Input to the development of the European
Interoperability Framework (EIF)
Template for ATHENA Interoperability Profile (AIP)
SolutionsInteroperability issues
Use cases(scenarios)
Standard
ATHENA
External
Use case #nUse case #1
ATHENA
Standard
External
Issue #1
Issue #n