Project A4 Claudia Guglielmina, TXT e-solutions Arne-Jørgen Berre, SINTEF

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


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)


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


Web Browser


Repository


Task Mngmt

Web Service Plugin


View Mngmt

Role Mngmt

Process infrastructure

Product infrastructure

AIF Website

Projectsupportsuite


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


ATHENA Interoperability Framework (AIF)


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


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.


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


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


AIF – Conceptual integration


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.


Interoperability framework


Interoperability reference architectureEnterprise/Business

Processes

Services

Information/Data





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


Interoperability modelling


AIF – Applicative integration


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


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


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


ATHENA Knowledge Base (implemented in Protégé)


ATHENA Interoperability Methodology (summary)Definition

Phases



Iterations

Support disciplines


Project management


Testing

Implementation





EIMM



Test definition

Implementation

Testing

IIAM



model


modelling approach


business needs



Testprocedure


ROI(impact)



BIF


B4


A4

Specific Solutions

Ax Projects


B4


C

BD

Contextelements


elements

A

ATHENA Knowledge Base(implemented in Protégé)

Tool support

[Deliverable D.A4.5]


AIF – Technical integration


Technical architecture


Technical architecture – Services

Enterprise/Business

Processes

Services

Information/Data





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


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”


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)


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


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


Web Browser


Repository


Task Mngmt

Web Service Plugin


View Mngmt

Role Mngmt


Web Browser


Repository


Task Mngmt

Web Service Plugin


View Mngmt

Role Mngmt

Pilot examples:• EADS NCPD pilot• INTRACOM PPM pilot


ATHENA Interoperability Profiles (AIPs)


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).


Development of interoperability profiles

ATHENA Knowledge Base(implemented in Protégé)

Tool support




Standard

ATHENA

External


ATHENA

Standard

External

Issue #1

Issue #n


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


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



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



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)



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


Application of the AIF


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.


Information Flow

From fragmented disjoined specifications …


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


Scope of the application

EIMM



Test definition

Implementation

Testing

IIAM



model


modelling approach


business needs



Testprocedure


ROI(impact)



BIF


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.


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


BIF profile – To be - ResultCategory Sub Category 5

(fully interoperable)

4 (qualified)

3 (moderate)

2 (minimum)

1 (none)






Public Process



Employees & Culture


Trust

Social capital

Information Systems

Interaction type


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


Application of the AIM baseline methodology

EIMM



Test definition

Implementation

Testing

IIAM



model


modelling approach


business needs



Testprocedure


ROI(impact)



BIF


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


Mapping BIF to EIMM - Approach

Identified BIF ProfileCategory Sub Category 5

(fully interoper

able)

4 (qualified

)

3 (moderat

e)

2 (minimum)

1 (none)






Public Process

Process visibility



Employees & Culture


Trust

Social capital

Information Systems

Interaction type


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


BIF – EIMM Mapping - ResultProducts & Services

Representation of Products and services x


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


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


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


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



EIMM



Test definition

Implementation

Testing

IIAM



model


modelling approach


business needs



Testprocedure


ROI(impact)



BIF


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


Data TransformationM

DD

Sem

anti

c

Processes

Data

Services

Processes

Business

ATHENA Railroad

Business Needs and Requirements

AIAG Scenario

List of generic functions


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)



EIMM



Test definition

Implementation

Testing

IIAM



model


modelling approach


business needs



Testprocedure


ROI(impact)



BIF


Requirements – solutions mapping


B4


A4

Specific Solutions

Ax Projects


B4


C

BD

Contextelements


elements

A

Functions


Context elements modelled in Protégé – Business needs and Generic solutions are annotated with these classes


Example - Mapping Generic to Specific Solution


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*


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


Validation of results


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.


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


Conclusion and future work


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



Iterations

Support disciplines


Project management


Testing

Implementation





Enterprise/Business

Processes

Services

Information/Data





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


Web Browser


Repository


Task Mngmt

Web Service Plugin


View Mngmt

Role Mngmt


Web Browser


Repository


Task Mngmt

Web Service Plugin


View Mngmt

Role Mngmt


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)




Standard

ATHENA

External


ATHENA

Standard

External

Issue #1

Issue #n


Thank you

Documents

Project A4 Claudia Guglielmina, TXT e-solutions Arne-Jørgen Berre, SINTEF