Patrick Sitek, Sergio Gusmeroli

Marco Conte, Kim Jansson, Iris Karvonen (Editors)

The COIN Book
Enterprise Collaboration and Interoperability
Bibliografische Information der Deutschen Bibliothek
Die Deutsche Bibliothek verzeichnet diese Publikation in der
Deutschen Nationalbibliografie; detaillierte bibliografische Da-
ten sind im Internet ber http://dnb.ddb.de abrufbar.
Vertrieb:
1. Auflage 2011
Verlagsgruppe Mainz GmbH Aachen
Ssterfeldstr. 83, 52072 Aachen
Tel. 0241/87 34 34
Fax 0241/875577
www.Verlag-Mainz.de
Herstellung:
Druck und Verlagshaus Mainz GmbH Aachen
Ssterfeldstrae 83
52072 Aachen
Tel. 0241/873434
Fax 0241/875577
www.DruckereiMainz.de
www.Druckservice-Aachen.de
Satz: nach Druckvorlage des Autors
Umschlaggestaltung: Druckerei Mainz
printed in Germany
Das Werk einschlielich seiner Teile ist urheberrechtlich geschtzt. Jede Verwendung ist ohne die
Zustimmung des Herausgebers auerhalb der engen Grenzen des Urhebergesetzes unzulssig und
strafbar. Das gilt insbesondere fr Vervielfltigungen, bersetzungen, Mikroverfilmungen und die
Einspeicherung und Verarbeitung in elektronischen Systemen.
Patrick Sitek, Sergio Gusmeroli, Marco Conte, Kim Jansson, Iris Karvonen (Editors)
The COIN Book
Enterprose Collaboration and Interoperability
1. Auflage 2011
ISBN 3-86130-713-8


I
List of Authors
Achilleas Achilleos (University of Cyprus), Juncal Alonso (TECNALIA), Leyla Arsan
(LODER), Gorka Benguria (ESI), Duan Buen (GIZ-ACS), Gulcin Buyukozkan (LODER),
Vittorio Cannas (CANNAS), Davide Cerri (STI-Innsbruck), Otakar erba (WirelessInfo), Karel
Charvt (WirelessInfo), Karel Charvt jr (WirelessInfo), Elia Conchione (Soluta.Net), Marco
Conte (ESoCE-Net), Enrico Del Grosso (TxT e-Solutions), Brian Elvester (SINTEF), Jens
Eschenbcher (BIBA), Andrew Faughy (VEN), Pierfranco Ferronato (Soluta.Net), Daniel Field
(ATOS), Klaus Fischer (DFKI-GmbH), Pavel Gnip (WirelessInfo), Sergio Gusmeroli (TxT e-
Solutions), Konstantin Hristov (FAVIT), Mikko Hynlnmaa (POYRY), Kim Jansson (VTT),
Francisco Javier Nieto (ATOS), Aslihan Kagnici (LODER), Iris Karvonen (VTT), Mindaugas
Kiauleikis (Kaunas University of Technology), Valentinas Kiauleikis (Kaunas University of
Technology), Srdjan Komazec (STI-Innsbruck), Szabolcs Ktai (IND/IVSZ), Gerardo Lancia
(FILAS), Man-Sze Li (IC Focus), Aurelian Mihai (University Polytechnic Bucharest),
Alexandru Mihnea (University Polytechnic Bucharest), Nerijus Morkeviius (Kaunas University
of Technology), Zoltn Mzes (IND/IVSZ), Alberto Olmo (ISOIN), Simon Oman (Polycom
d.o.o.), Leire Orue-Echevarria (TECNALIA), George Papadopoulos (University of Cyprus),
Antonio Panazzolo (Soluta.Net), George Sielis (University of Cyprus), Michele Sesana (TxT e-
Solutions), Patrick Sitek (BIBA), Florian Skopik (Distributed System Group Vienna University
of Technology tuwien), Fabrizio Smith (TxT e-Solutions), Ioan Stefan Sacala (University
Polytechnic Bucharest), Hannes Suttner (Siemens), Timo Syrjnen (POYRY), Jess Snchez
(ISOIN), Francesco Taglino (CNR-IASI), Mehmet Tanyas (LODER), Drago Trebenik (Joef
Stefan Institute), Hong-Linh Truong (Distributed System Group Vienna University of
Technology tuwien), Mikel Vergara (TECNALIA), Ingo Zinnikus (DFKI-GmbH)


Thanks to all the Authors for their valuable contributions.
II
Preface of the Series
High performing co-operations between independent companies with the aim to develop and to
realise customised products are an important success factor for the competitiveness of the
European industry. Due to immense political changes and global markets, new ways of co-
operations, so called enterprise networks, can be seen in addition to the traditional supply chains.
These enterprise networks are often formed to realise a single customers order and play an
important role during the conceptual phase (product design) as well as during the realisation
phase (production).
The Bremer Schriften zur integrierten Produkt- und Prozessentwicklung (Bremen scientific
series for integrated product and process development) bases on the works performed by the
research field ICT application for production (IKAP) from BIBA Bremer Institut fr
Produktion und Logistics GmbH (www.biba.uni-bremen.de) and on the works performed by
BIK Bremer Institut fr integrierte Produktentwicklung (www.bik.uni-bremen.de).
The research unit IKAP prepares, develops and realises methods and tools to support co-
operative, inter-organizational enterprise networks. The research concentrates on efficient and
effective collaborative design and production processes by applying innovative information and
communication technologies (ICT). As focus can be seen the collaborative acting of enterprises
during distributed design and production processes as well as during the late processes of the
product life cycle such as the usage phase or the recycling phase.
Additionally, the BIK research expertise is concentrated on the integrated development of
products focusing on methods, tools and systems (like FMEA, QFD, CAD, CAE, and PDM).
The main focus lies on products constructed by renewable resources, glass fibre or carbon fibre
materials.
The research results are integrated in the academic education of the next generation engineers
(Production Enginnering, Systems Engineering, Engineering and Management) at the University
of Bremen. Another application field of the research results are industrial projects where
innovative approaches are transferred to practical problems.
The institute is publishing the results of its work in a series. The objective of this series is to
disseminate dissertations, project reports and proceedings of institute-hosted conferences to a
larger circle of interested people.

The Series Editors

Prof. Dr.-Ing. K.-D. Thoben
Prof. Dr.-Ing. D. H. Mller


III
The COIN Integrated Project: a flagship project of the Future
Internet Enterprise Systems domain

The Future Internet Enterprise Systems (FInES) Cluster
1
was launched in 2009 by the
Networked Enterprise and RFID unit of the Information Society and Media Directorate-General
as a follow-up to the work already accomplished in the domain of networked businesses. This
innovative domain was considered necessary given the upcoming challenges for our European
enterprises in the Future Internet era, in a context of increased globalization and competition. The
Cluster inherited the very rich advancements of three research domains previously supported by
the unit: Enterprise Interoperability, Enterprise Collaboration and Digital Ecosystems, but the
domain has never lost its scope on the usage and integration of ICT by enterprises. Encouraging
disruptive innovation, its mission remains to orient research priorities towards new business
approaches and business values supported by Information and Communication Technology,
where the Internet is the business ecosystem.
After the first FP7 call for proposals, COIN became the flagship project of the FInES Cluster and
one of its most ambitious, complex and wide-ranging projects. As the full name of the project
Collaboration and Interoperability for Network Enterprise may suggest, its primary objective was
to aggregate two separated areas Enterprise Collaboration and Enterprise Interoperability -
developed by the precursors of the FInES Cluster. COIN rightfully observed that the two must be
put together in order to have a coherent and efficient approach on the technology needed by our
businesses. In this endeavour, the COIN partners gathered valuable research results from several
EU funded projects that focused, however, solely on one of the two domains (see, for instance,
the European ATHENA, INTEROP, ABILITIES, SATINE and TRUSTCOM projects on
Enterprise Interoperability and the ECOLEAD, DBE, E4 or ECOSPACE projects on Enterprise
Collaboration).
One of COIN's most ambitious objectives is the provision of a universal service infrastructure
capability based on the concept of the Interoperability Service Utility (ISU),
2
a concept of high
importance for the FInES community. The ISU, already announced by the Enterprise
Interoperability Research Roadmap version 4.0,
3
is destined to be a 'utility-like' interoperable
technology capability that can be "invoked on-the-fly by enterprises in support of their business
activities". The implementation of the ISU should play a key role in granting easy access for
small businesses to the business ecosystem it supports, in line with the priorities for SMEs
outlined in the Digital Agenda for Europe
4
and in the Innovation Union
5
Europe 2020 Flagship
Initiatives. In this sense, COIN's potential achievements are of tremendous value, tracing the
lines for further developments that the European Commission fully encourages.
However, the numerous and ambitious objectives of COIN could not have been credible if they
were an easy task to accomplish. It is our experience that projects aiming at building service
platforms are bound to be confronted to serious obstacles. Furthermore, a project of the length
(four years), size (twenty-nine partners) and complexity (seven sub-projects) of COIN meets
even more unsteady grounds in conducting its research, having to deal with a continuous

1
http://cordis.europa.eu/fp7/ict/enet/ei_en.html and http://www.fines-cluster.eu
2
The first Grand Challenge of the Enterprise Interoperability Research Roadmap [European Commission, 2006 and
2008
3
ftp://ftp.cordis.europa.eu/pub/ist/docs/directorate_d/ebusiness/ei-roadmap-final_en.pdf
4
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2010:0245:REV1:EN:HTML
5
http://ec.europa.eu/research/innovation-union/pdf/innovation-union-
communication_en.pdf#view=fit&pagemode=none
IV
redefinition of the questions and needs it was trying to answer to. Moreover, the achievements of
the COIN project, as well as the results of the FInES domain, are and will always be "work in
progress". A work that can be a source of inspiration for all of us, interested in the evolution of
applied technology. A work made of blood, sweat and tears reaching out to other communities.
And for all these reasons, a work that needed to be written down and published.
I would like to acknowledge the considerable efforts and the valuable substance that is offered by
the COIN consortium through this book. I congratulate them for its realisation and hope that the
reader will find it an interesting, helpful and rewarding introduction to the subject area of next
generation service platforms.


Cristina Martinez,
Head of Future Internet Enterprise Systems cluster


V
Preface of the Volume
This book presents the key results of the COIN Enterprise Collaboration and Interoperability
project. COIN is an integrated project in the European Commission Seventh Framework
Programme - EU FP7 Project 216256, which has been running for four years from January 2008
to December 2011. COINs dimension and impact is represented by its size of 32 industry,
scientific and technological partners from Western and Eastern parts of Europe.
The COIN book addresses the current state of the art and current practice, future scenarios and
challenges for research and innovation of networking enterprises in the context of Future Internet
Enterprise Systems. The COIN book is made of diverse parts following the projects main sub-
projects trying to cover the broad research results and recapitulate them to a manageable
overview for an interesting reading. The COIN book describes the main parts of the developed
COIN IT Systems as well as consolidated baseline and innovative Enterprise Collaboration and
Interoperability IT-services. It describes the COIN demonstrators in the field of stable industrial
Supply Chains, more dynamic Collaborative Networks and most dynamic Business-Innovation
Ecosystems. One chapter is dedicated to discuss the approach to bring COIN to the market in
order to force our philosophy about the importance of the correlation between the achieved
research results and the business world.
Looking at the COIN main outcomes, the value of the project is not only constituted by the
numerous public research reports which are available through our website www.coin-ip.eu and
about 330 international and national events that we have organized. To our conviction COIN
results may also impact the EU and the Commission in terms of future work and research
priorities in the field of Future Internet Enterprise Systems (FInES).
The COIN consortium wishes to acknowledge all those who have contributed to our results. The
work has been co-funded by the European Commission under the ICT priority within the 7th
Framework programme. We are grateful to the EU project officer Cristina Martinez, Head of
Future Internet Enterprise Systems cluster, who has full supported the project throughout four
years of research work. Our thanks go also to the COIN review committee Alberto Bonetti,
Wolfgang Reisig, Carles Sierra and Joseph Tah for professional and productive discussions and
exchanges at anytime.

Sergio Gusmeroli, COIN Project Coordinator
TXT e-solutions SpA
Corporate Research Manager
VI
Table of Contents
1 The COIN Motivation, Object and Vision ............................................................................... 1
2 COIN IT System ....................................................................................................................... 7
2.1 The COIN Generic Service Platform for Enterprise Interoperability and Collaboration
Service Provision ......................................................................................................................... 10
2.1.1 Introduction ................................................................................................................. 10
2.1.2 The COIN Generic Service Platform ......................................................................... 10
2.1.3 Semantic Execution Environment .............................................................................. 12
2.1.4 Agent-Based Negotiation ........................................................................................... 12
2.1.5 Trust and Security ....................................................................................................... 14
2.1.6 Peer-to-Peer Registry and Repository ........................................................................ 15
2.1.7 Conclusion .................................................................................................................. 16
2.2 The COIN Front End for Generic Service Platform Federation Consuming ............... 18
2.2.1 Introduction ................................................................................................................. 18
2.2.2 GSP nodes and Services provisioning to the GSP Federation .................................. 19
2.2.3 Consume the GSP Federation by a Human Oriented Interface ................................ 25
2.2.4 Guiding User Semantic Search by Free Text Wishes Expression - JSI .................... 28
2.2.5 Conclusion .................................................................................................................. 29
2.3 The COIN Collaboration Platforms Federation for Enterprise Networks and Business
Ecosystems .................................................................................................................................. 31
2.3.1 Introduction ................................................................................................................. 31
2.3.2 Modelling, executing and outsourcing cross-enterprise collaborative business
processes .................................................................................................................................. 31
2.3.3 Extended Products and Distributed Collaborative Innovation in Virtual Factories . 40
2.3.4 Conclusion and Future Work ..................................................................................... 43
3 COIN Enterprise Collaboration (EC) and Interoperability (EI) Services ............................. 45
3.1 COIN research results for enterprise innovation - Enterprise Collaboration Baseline
Services ........................................................................................................................................ 46
3.1.1 Introduction ................................................................................................................. 46
3.1.2 Related Work .............................................................................................................. 47
3.1.3 EC Baseline Reference Model ................................................................................... 48
3.1.4 Conceptual architecture .............................................................................................. 50
3.1.5 Conclusion and key benefits ...................................................................................... 52
3.2 COIN Innovative Enterprise Collaboration Services ................................................... 54
3.2.1 Introduction ................................................................................................................. 54
3.2.2 Methodology and Workplan ...................................................................................... 54
3.2.3 Background and Previous Research ........................................................................... 55
3.2.4 Results - Overview of Developed Services ............................................................... 56
3.2.5 Innovations .................................................................................................................. 58
3.2.6 Conclusions and Key Benefits ................................................................................... 65


VII
3.3 COIN Enterprise Interoperability Baseline Services ..................................................... 66
3.3.1 Towards Enterprise Interoperability services ............................................................ 66
3.3.2 COIN EI framework ................................................................................................... 67
3.3.3 Enterprise interoperability baselines .......................................................................... 69
3.4 COIN Innovative EI Services ......................................................................................... 72
3.4.1 Introduction ................................................................................................................. 72
3.4.2 Information Interoperability services ......................................................................... 73
3.4.3 Process Interoperability services ................................................................................ 73
3.4.4 Knowledge Interoperability services ......................................................................... 74
3.4.5 Main innovation issues ............................................................................................... 75
3.4.6 Conclusions ................................................................................................................. 76
4 COIN Demonstrators .............................................................................................................. 78
4.1 The COIN EI/EC Services in industrial Supply Chains ................................................ 78
4.1.1 An EI/EC Pilot in an Automotive Supply Chain ....................................................... 79
4.1.2 Production Planning and Knowledge Interoperability Services in the Lazio
Aerospace Cluster ................................................................................................................... 85
4.1.3 An EI/EC Pilot in a Railways Supply Chain (KTU) ................................................. 90
4.1.4 An EI/EC Pilot in a Construction Supply Chain (UPB) ............................................ 95
4.2 The COIN EI/EC Services in Collaborative Networks ................................................. 99
4.2.1 An EI/EC Pilot in Andalusia Aeronautics Cluster (ISOIN) .................................... 100
4.2.2 An EI/EC Pilot in The Hungarian ICT Cluster (IND) ............................................. 109
4.2.3 An EI/EC Pilot in a Marine Shipping Network (UCY) .......................................... 114
4.2.4 An EI/EC Pilot in a Logistics Network (LODER) .................................................. 121
4.3 The COIN EI/EC Services in Business-Innovation Ecosystems ................................ 126
4.3.1 An EI/EC Pilot in a Healthcare Ecosystem (VEN) ................................................. 127
4.3.2 An EI/EC Pilot in Pyry business eco-system ......................................................... 135
4.3.3 An EI/EC Pilot in an Agro-Food Living Lab (WirelessInfo) ................................. 139
4.3.4 An EI/EC Pilot in a Digital Media Living Lab (FAVIT) ........................................ 145
5 COIN in the Business ............................................................................................................ 149
5.1 Supporting EC&EI service usability and take-up ........................................................ 150
5.1.1 Introduction ............................................................................................................... 150
5.1.2 Barriers and Challenges for IT take up .................................................................... 150
5.1.3 Development approach: Cross-teams ...................................................................... 152
5.1.4 Contributing to usability in EC &EI context ........................................................... 152
5.1.5 Development of COIN take-up guidelines .............................................................. 153
5.1.6 Conclusion ................................................................................................................ 157
5.2 Saas-U Value Proposition and Business Models ......................................................... 159
5.2.1 Introduction ............................................................................................................... 159
5.2.2 Assumptions and Hypotheses .................................................................................. 161
5.2.3 ISU Value Proposition and Business Model ........................................................... 161
VIII
5.2.4 Conclusions ............................................................................................................... 167
5.3 Bringing COIN to the Market ...................................................................................... 170
5.3.1 Challenges ................................................................................................................. 170
5.3.2 Logic adapted ............................................................................................................ 170
5.3.3 Development of business scenarios ......................................................................... 173
5.3.4 Type of Activity ........................................................................................................ 174
5.3.5 Scenarios in COIN .................................................................................................... 175
5.3.6 Conclusion ................................................................................................................ 178
5.4 Enterprise Collaboration Maturity Model .................................................................... 180
5.4.1 The problem description ........................................................................................... 180
5.4.2 Objectives and Use of the ECMM ........................................................................... 181
5.4.3 ECMM Design Process and Background ................................................................ 181
5.4.4 COIN ECMM Structure and Description ................................................................ 183
5.4.5 ECMM Application into End Users ......................................................................... 185
5.4.6 Conclusions ............................................................................................................... 188
Conclusions - The heritage of the COIN Integrated Project: how to move forward in the Future
Internet Enterprise Systems domain ............................................................................................. 190



IX
Table of Figures
Figure 1 The COIN Butterfly model .............................................................................................. 8
Figure 2 COIN GSP Architecture ................................................................................................ 11
Figure 3 Composed services in the COIN context ...................................................................... 13
Figure 4 - Main components and relationships in the TSD Platform ............................................ 14
Figure 5 - P2P Repository/Registry Architectural viewpoint ........................................................ 16
Figure 6 - GSP evolution cube .................................................................................................... 20
Figure 7 - COIN GSP model ontology stack .................................................................................. 22
Figure 8 - COIN Assets Download ................................................................................................. 23
Figure 9 - GSP Model Configuration .............................................................................................. 23
Figure 10 - nodes waiting for approval ........................................................................................... 24
Figure 11 - The Web form for defining service pre-/post-conditions ............................................ 24
Figure 12 Generic User Functionalities ....................................................................................... 25
Figure 13 - COIN Front-End deployment schema and COIN System upper Cloud interaction .. 26
Figure 14 - Browse & Search interface ........................................................................................... 27
Figure 15 - detail of the semantic search results ............................................................................. 27
Figure 16 - from the left: try-me button form, trust values and COIN SMW for information on
the service ........................................................................................................................................ 28
Figure 17 - FTWE pipeline ............................................................................................................. 28
Figure 18 - Enrichment services ..................................................................................................... 29
Figure 19 - Industrial User - CP Integration Step 1 ........................................................................ 35
Figure 20 - Industrial User - CP Integration Step 2 ........................................................................ 35
Figure 21 - Injection in the business process of a discovered service ........................................... 36
Figure 22 - Industrial User - CP Integration Step 3 ........................................................................ 36
Figure 23 - GAP Identification - Flow diagram ............................................................................. 37
Figure 24 - COIN Step 2 Overview ............................................................................................. 37
Figure 25 - Transformation Found .................................................................................................. 38
Figure 26 - Available Transformations ........................................................................................... 38
Figure 27 - Process Overview ......................................................................................................... 39
Figure 28 - automatic execution ...................................................................................................... 39
Figure 29 - Moving to an Extended Product .................................................................................. 41
Figure 30 - Evolution towards distributed, collaborative innovation ............................................ 42
Figure 31 - Extended products and collaborative distributed innovation in Virtual factories ...... 43
Figure 32 - EC Baseline Reference Model ..................................................................................... 49
Figure 33 - Conceptual architecture of the COIN Baseline EC software services and tools ........ 50
Figure 34 - Example of decoupling of an existing software .......................................................... 51
Figure 35 - Baseline IT Services Portal .......................................................................................... 52
Figure 36 - COIN overall development strategy ............................................................................ 55
Figure 37 - Overview of developed services .................................................................................. 56
X
Figure 38 - Healthcare sector ontology draft .................................................................................. 58
Figure 39 - Collaborative Production Planning .............................................................................. 60
Figure 40 - Example of meeting process and steps ........................................................................ 62
Figure 41 - Interoperability reference model .................................................................................. 67
Figure 42 - Baseline categories according to AIF .......................................................................... 68
Figure 43 Commercial Process .................................................................................................... 81
Figure 44 - Technical process ......................................................................................................... 81
Figure 45 - Integration process for the legacy system users .......................................................... 83
Figure 46 - Integration process for the non-legacy system users ................................................... 83
Figure 47 - Knowledge Interoperability Pilot ................................................................................. 87
Figure 48 - Collaborative Production Planning Pilot ..................................................................... 88
Figure 49 - Manufacturing process of VAE Legetecha (fragment) ........................................... 91
Figure 50 - University Politehnica of Bucharest COIN implementation strategy ..................... 96
Figure 51 - The process of ordering materials from suppliers ....................................................... 97
Figure 52 - The process of collaborative project planning and change management ................... 97
Figure 53 - The Andalusian Aeronautic Cluster main competences and entities. ....................... 101
Figure 54 Workflow example .................................................................................................... 102
Figure 55 - Some COIN Innovative services tested. Collaborative 3D designer service (left) and
Interoperability Spaces (right) have been tested, for product design and contract negotiation,
respectively .................................................................................................................................... 104
Figure 56 Challenges and COIN Expectations .......................................................................... 110
Figure 57 - Use Case 1: Formulating the Recap Pre-Fixture Document ..................................... 115
Figure 58 - Use Case 2 Creation and Settlement of the Proforma Disbursement Account (PDA)
........................................................................................................................................................ 115
Figure 59 - Use Case 1 Formulation of the Recap Voyage Document using ProcessMaker .. 118
Figure 60 - Initialisation of the recap document business use-case ............................................. 119
Figure 61 - Dincer Lojistik business network for collaborative transportation ........................... 122
Figure 62 - The general business processes of Dincer Lojistik for use cases .............................. 123
Figure 63 General development process for order transformation ........................................... 124
Figure 64 - Business Eco-System with actors in facility engineering projects ........................... 135
Figure 65 - Accelerate transition to global operation and networked engineering ...................... 136
Figure 66 - Interrelation of different knowledge levels ............................................................... 140
Figure 67 Three Layers Architecture ......................................................................................... 141
Figure 68 System overview ........................................................................................................ 142
Figure 69 - Architecture of Machine searching ............................................................................ 143
Figure 70 - COIN take-up process ................................................................................................ 157
Figure 71 ISU Summary ............................................................................................................ 160
Figure 72 ISU Stakeholder Categories ...................................................................................... 164
Figure 73 - Applying Competitive Models to the Supply of Utility Services ............................. 167
Figure 74 - Core and peripheral assets .......................................................................................... 172
Figure 75 - Value Chain for the core COIN technology .............................................................. 172


XI
Figure 76 - The complete value chain for COIN .......................................................................... 173
Figure 77 - Legend for value chain activities ............................................................................... 175
Figure 78 - Facebook Scenario 1 .................................................................................................. 175
Figure 79 Facebook Scenario 2 .................................................................................................. 176
Figure 80 - Open Source Scenario ................................................................................................ 176
Figure 81 - Markeplace Scenario 1 ............................................................................................... 177
Figure 82 Franchise Scenario ..................................................................................................... 178
Figure 83 - ECMM Maturity Levels ............................................................................................. 182
Figure 84 - ECMM Results: Comparison between the three companies ..................................... 185




1
1 The COIN Motivation, Object and Vision
COIN Background
Enterprise Collaboration (EC) and Enterprise Interoperability (EI) have represented for
European Commissions FP6 research programme two of the major research domains in the field
of ICT for Networked Enterprises (DG INFSO D4 Networked Enterprise & Radio Frequency
Identification) and aggregated tens of projects and hundreds of researchers in their projects
initiatives.
Research in Enterprise Collaboration comes from a business perspective and identifies the
process of enterprises - mainly SMEs - to set-up and manage cross-enterprise win-win business
relations in response to business opportunities. The aim is to find new paradigms for European
enterprise aggregation, process synchronization and people co-operation in response to the more
and more demanding and complex business opportunities coming from the global market. In
order to fully exploit its tremendous potential, EC research not only aims at achieving important
and relevant results from the scientific, organizational, business standpoint, but it also magnifies
the investments on resources in the Information Technology (IT) implementation of the key
collaboration processes and cross-enterprise applications needed to make collaboration easier
and profitable.
However, most of the completed EU funded EC research initiatives have achieved significant
results in the field of IT support to collaboration management and performance management, but
they couldnt address properly the problem of Enterprise Applications Integration (EAI).
Research in Enterprise Interoperability originated by the IT world and identifies the capability
of enterprise software and applications to be integrated at the level of data, applications,
processes and models. Enterprise Interoperability started from an IT perspective of Enterprise
Application and Software interoperability and focused on enterprise modelling, architecture and
platforms, ontologies and semantics as the basic pillars for EI. This research stream proceeded
very well in an analytical way to deeply investigate the various interoperability problems which
affect European enterprises and has come out with a set of solutions for Enterprise Models
Interoperability, Cross-organizational Business Processes, Semantic Business Document
Reconciliation, IT Service selection and composition and Model-driven Architectures.
However, EI solutions so far have been proved as efficient and effective in the IT and research
community but have some way privileged in their field adoption the big enterprises while there is
a tremendous need for EI efficient and effective solutions in the SMEs environment and in some
less IT-developed sectors. Moreover, it seems that EI solutions so far lack flexibility and
adaptation to different business scenarios and collaboration forms like Supply Chains,
Collaborative Networks and Business Ecosystems.
Hence, it is evident that research in EC lacks the adoption of innovative and advanced IT
architectures and tools, while research in EI lacks best practices, clear business justification
mostly for SMEs and real-life collaborative business applications.
In synthesis, it is true that EC and EI are different concepts which cannot be merged, confused
and mixed up, but that they are so interdependent, interconnected and simultaneously present in
every networked enterprise, that they can be really considered as the two sides of the same coin!

COIN Motivation
Since more than a decade, the adoption of advanced Information Technology methods and tools
has been considered one of the strongest competitive advantages for collaborative enterprises.
However, so far EI/EC solutions in networked enterprises have mostly been implemented in
hierarchical static supply chains, by forcing the installation and adoption of the same IT solutions
2
in all networked enterprises. But what happens in the presence of less hierarchical collaboration
forms like in innovation ecosystems or when SMEs simultaneously belong to different supply
chains and cannot simply adopt one single IT solutions.
Networked Enterprises simply need more flexible and adaptable EC and EI solutions.
On the other hand, the advent of Internet and the so-called Service Web has introduced
unprecedented opportunities for e-commerce and e-business processes: the Internet has become a
Universal Business System and service oriented architectures have completely revolutionised the
traditional software engineering methods and tools. How to implement this huge potential for
innovation in the field of EI/EC among networked enterprises?
Networked Enterprises need more simple and easy to use access to Internet web services.
So, there is a more general question which says How to bridge the gap between Business and
IT, making the Internet of Services easily accessible and integrated in business processes? and a
more specific question which focuses the topic to EI/EC: How could networked enterprises
have access and easily use the most advanced web services available in the Internet to solve their
Interoperability and Collaboration problems?
The EI Cluster [13] in its research roadmap v 4.0 identified in the implementation of the ISU
(Interoperability Service Utility) Grand Challenge a way to provide all enterprises, including
SMEs, with a basic set of Interoperability Services to implement their collaborative business.
Such an ISU was conceived both as a utility infrastructure (i.e. a service delivery platform for
basic fundamental services) and as a set of innovative business models accompanying it.
The fundamental motivation of the COIN project was the urgent need by collaborative business
processes to easily access-compose-orchestrate-execute EI/EC services available to all in the
Internet at a very low cost and under guaranteed service levels; in one sentence to implement the
ISU and its most relevant business models applied to EI/EC services for any form of more or less
hierarchical networked enterprise.

COIN Project 2020 Vision Statement
By 2020 enterprise collaboration and interoperability services will become an invisible,
pervasive and self-adaptive knowledge and business utility at disposal of the European
networked enterprises from any industrial sector and domain in order to rapidly set-up,
efficiently manage and effectively operate different forms of business collaborations, from the
most traditional supply chains to the most advanced and dynamic business ecosystems
The COIN Vision (COIN DoW) implies that in 10 years time, Enterprise Interoperability and
Enterprise Collaboration services will be commoditized and factorized in the Internet of the
Future as a set of Utility Services, available to all enterprises at a very low or zero cost and under
non-discrimination and non-exclusivity policies: Interoperability and Collaboration as Public
Services.
From an IT architectural viewpoint, the COIN Vision implies that commercial Enterprise
Systems of the future [13] should focus on the most added value services they could provide (e.g.
supporting supply chains, customer relationships, product life cycle, financial and HR issues, in
one word supporting Business Innovation) and leave the most commoditized IT services to the
Future Internet open platforms developers.
The COIN Vision is in agreement with the most recent EC policies and in particular with the
Digital Agenda for Europe [12] which identifies 7 key themes to be solved in order to build the
European Digital society. One of these pillars is: Interoperability and Standards: a digital
society can only take off if its different parts and applications are interoperable and based on
open platforms and standards.


3
From a business viewpoint, the distinction between Value Added (pay-as-you-go) and Utility
(free) services is stimulating the development of innovative business models bundling Value
Added services and Utility Services in a very similar way the media industry is bundling free and
premium services. The latest outcomes of COIN business research show however that the full
adoption of so called SaaS-U business models (merging SaaS and Utility models) will be
effective for EI/EC services just starting from 2020, when Value Added services could be on-
the-fly and dynamically selected in the private clouds by Enterprises and therefore the need of
standardized EI/EC services available in the open clouds will become essential.
Moreover, the present perception in COIN is that in the current business and market landscape
for providing enterprises with just EI/EC Utility Services is not guaranteeing the IT providers
with the necessary economical returns from the needed huge investments in ICT, according to
the current costs of Cloud Computing and similar infrastructures.
By 2020, thanks to the implementation of the Digital Agenda for Europe, it is supposed that
current obstacles hindering the implementation of the COIN 2020 Vision (e.g. EI/EC services
hard-wired, high costs to set-up a cloud service infrastructure, low bandwidth and network
performance, predominance of on-premises monolithic solutions, huge availability of EI/EC
services/information in the open Internet, legislative and regulatory issues which will combat
monopoly positions and support open specifications and open standards) could disappear and
make the provision for the ISU profitable also from a mere economic point of view.

The COIN Metaphor
The COIN coin metaphor is also useful to describe the 5 major research topics of the project:
The SIDE A of the COIN: Enterprise Collaboration.
The COIN Project develops innovative services for enterprise aggregation, synchronization
and co-operation, adaptable to any collaboration form and suitable for SMEs needs. COIN
will develop innovative services for Enterprise Collaborative in Product Development (c-
PD), Collaborative Production Planning (c-PP), Collaborative Project Management (c-
PM), as well as in Human Centric Collaboration (c-HI). The first three group of services
directly support the corresponding collaborative operational functions; product
development, production planning and project management, while the forth group of
services are more general and not specifically dedicated to a business function. The c-HI
services encompass services for human collaboration and data sharing and can be utilized
as supporting services, for example in c-PD, c-PP and c-PM. The EC services are
explained in more detail in chapter 3 of this book [4][5][6][7]

The SIDE B of the COIN: Enterprise Interoperability.
Enterprise Collaboration is a term that describes a field of activity with the aim to improve
the manner in which enterprises, by means of information and communications technology
(ICT), interoperate with other enterprises or organisations to conduct their business. In the
COIN context, EI services provide functionality for applying IT solutions that overcome
interoperability gaps between two or more enterprises and thus enabling them to set-up and
run collaborations. The COIN Project provides innovative integrated-unified-federated
solutions for bridging interoperability gaps at the level of data, service, process and
knowledge. The main goal of the EI services is to reduce the costs of data reconciliation,
systems integration and business processes synchronization and harmonization. The COIN
project adopted the ATHENA EI reference framework [1] which addresses interoperability
at different levels, by using two main approaches (i.e., model-driven and semantics-based)
The EI services are explained in more detail in chapter 3 of this book [8, 9 and 10]
4
Interoperability at the information/data level is related to the exchanging and sharing
business documents among organizations, by filling interoperability gaps related to the
format and content and to the messages and/or structures to be exchanged.
Interoperability at the service level is concerned with discovering, ranking, selecting,
composing, orchestrating and executing various applications implemented as a service.
Interoperability at the process level is the capability to make proper external views of
enterprise internal processes synchronised by a collaborative inter-enterprise business
process.
Interoperability at the knowledge level should be seen as the organisational and
operational ability of an enterprise to co-operate with other, external organisations in spite
of e.g., different working practices, legislations, cultures and commercial approaches.
For both sides of the coin, COINs main objective here is i) to be the catalyst of previously
developed EI/EC services, by harmonising their semantic descriptions and by supporting
their registration into the same web site and discovering mechanism and ii) to develop
innovative EI/EC services, extending the available ones with new methods, techniques and
functions, as for instance the implementation of a federated interoperability platform or the
integration of social networks in collaboration.

The Metal of the COIN: Generic Service Platform.
The COIN Project develops a pervasive, adaptive service delivery platform to host COIN
services for Enterprise Collaboration and Enterprise Interoperability. A generic
Semantically Enabled Service Architecture has been customised for the EI/EC domain and
empowered with peer-to-peer, trust & security and intelligent reasoning / negotiation
capabilities.

Here the objective of COIN is to develop an open-trusted federation of service delivery
platforms, namely the ISU (Interoperability Service Utility) aimed at making accessible,
browsable, composable and executable from a single one-stop-shop the myriad of EI/EC
services developed not only in COIN but in any other research project or
standardisation/commercial initiative. In the Future Internet (FI) perspective, the objective
is to integrate such a federation with the FI Core Platform and its Generic Enablers, with
the final aim to develop a set of Enterprise-oriented utilities and to realise the vision of
FI as the Universal Business System. [3]

The Generic Service Platform that has to provide COIN with a platform with a reliable
layer for models and services. Regarding the interaction and interoperability with other
COIN components, the Evolutionary and Pervasive Service Platform is simply seen as a
Web Service, that holds information that is critical to the functioning of the COIN services
and models. The pervasiveness of the platform is accomplished through the usage of a
decentralization technique; the information is distributed and replicated in a set of
connected nodes. The peer to peer protocols are a valuable technology for the organization
of the information and for the communication infrastructure. In a peer to peer network the
information is shared across the members of the community (represented by nodes) and it
is not under the control of a single institution or organization. This approach is a promise
for true equality; there is not a single point of failure inside the network and hence the
services are more reliable.

The Value of the COIN: Software as a Service Utility


5
The COIN project supports the establishment of business models for interoperability
service utilities that will match current market condition and completion. The Information
Technology vision of Software as a Service (SaaS) finds its implementation in the field of
interoperability among collaborative enterprises, supporting the various collaborative
business forms, from supply chains to business ecosystems, and becoming for them like a
utility.

In order to describe, reason and where possible assess change on different levels, the COIN
research into EI Value Proposition needs to integrate the relevant key developments
[11]. There are of course different schematics for integrating and characterising those
developments. Given that the overall context for COIN is enterprise networking, the
research will be concerned with developments that are ICT based and/or ICT enabled. In
conformity with the vision and mission of COIN, the research is particularly concerned
with market developments and trends with reference to the themes of Software as a
Service (SaaS) and Interoperability Service [as] Utility (ISU). SaaS is a market reality
while ISU is a research challenge premised upon a re-structuring of the current Internet.
The notions of interoperability and collaboration are changing in perspective and scope as
a result of both market reality and new research orientation towards a Future Internet. On
the basis that the Future Internet represents the future of ICT, this could be elaborated as
the Future Internet will provide a critical infrastructure for all enterprises, which is itself an
articulation of the FInES Cluster vision of the Internet being a universal business system.

The basic assumptions are that the Future Internet represents the future of ICT, this could
be elaborated as the Future Internet will provide a critical infrastructure for all enterprises,
which is itself an articulation of the FInES Cluster vision of the Internet being a universal
business system. Enterprise processes will be subject to increasing commoditisation and IT
capabilities will be subject to increasing contextualisation in order to better serve business
needs.

The Market of the COIN: Manufacturing Enterprises, mainly SMEs.
The COIN original project encompasses six industrial test cases in different domains
(Automotive, Space, Aeronautics, Healthcare, ICT, Plants Engineering). The test cases
have been extended to twelve, by adding new six domains coming from the so-called
Enlarged Europe (Marine Shipping, Railways Components, Agro-food, Civil
Construction, Logistics & Transport, Media).

All the developed constituents of the COIN metaphor need to be deployed and adopted in
realistic business scenarios and carefully evaluated in their business benefits and
exploitation potential. To achieve this objective, specific attention is being spent in COIN
to cover the different industrial sectors, European Countries, application domains, EI/EC
heterogeneous requirements and legacy systems and applications.

References
[1] Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Applications
(ATHENA) - IST-507849 FP6 - Integrated Project
[2] Grant agreement for Collaborative Project, FP7 IP 216256 - COIN Large-scale integrating project, Annex I
- Description of Work
[3] COIN deliverable D3.2.1b - Evolutionary and Pervasive Service Platform, 2009
6
[4] COIN Deliverables D4.2.1b - cProduct Development Services, 2009
[5] COIN Deliverables D4.3.1b - cProduction Planning Services, 2009
[6] COIN Deliverables D4.4.1b - cProject Management Services, 2009
[7] COIN Deliverables D4.5.1b - cHuman Interaction Services, 2009
[8] COIN Deliverables D5.2.1b - Information Interoperability Services, 2009
[9] COIN Deliverables D5.3.1b - Knowledge Interoperability Services, 2009
[10] COIN Deliverables D5.4.1b - Business Interoperability Services, 2009
[11] COIN deliverable D6.2.1b - Integrated EI Value Proposition, 2009
[12] DAE: A Digital Agenda for Europe, EUROPEAN COMMISSION Communication from The Commission
to The European Parliament, The Council, The European Economic and Social Committee and The
Committee Of The Regions Brussels, 26.8.2010. COM(2010) 245 final/2
[13] FInES 2010: Future Internet Enterprise Systems (FInES) Research Roadmap FINAL REPORT, June 2010.


7
2 COIN IT System
The COIN system is a complex cross-enterprise environment encompassing several different
components, platforms and services, which could be represented as a double cloud (COIN
butterfly) visible in Figure 1. By mission, COIN aims at attracting as many EI/EC service
providers and as many EI/EC service consumers as possible, becoming this way the reference
service platform for EI/EC services. This means that the architecture of COIN system should be
open, evolutionary, scalable, incremental, so that to become a catalyst for those who want to
publish their services (according to their standards and business models) and those who want to
access EI/EC services from the open Internet. During and after the COIN project life time,
additional nodes have been and will be added to the initial COIN configuration, by integrating
contributions coming from external sources (e.g. research projects like SOA4ALL
6
and
DEN4DEK
7
or business-oriented initiatives like ITA - Information Technology for the German
Automotive Industry - or GENESI DEC - Digital Earth Community -), this way experimenting
and assessing the openness, scalability and interoperability of our technical choices.
The COIN Integrated System is a federation of Platforms, Services and Web Interfaces which
allow EI/EC Services to be searched, discovered, ranked, orchestrated and executed by cross-
organizational business processes.
There are three basic components of the COIN system, which could be interfaced in several
different ways:
A COIN Generic Service Platform (GSP) which is an open source instantiation of a generic
SESA (Semantically Enabled Service Architecture), specialized in the EI/EC domain, and
empowered with advanced capabilities for trust & security, distribution & scalability,
reasoning & negotiation.
A constellation of COIN EI/EC Services which are able to implement state-of-the-art and
innovative technologies to support information, knowledge and business interoperability as
well as Human Collaboration in a collaborative business context of Product Development,
Production Planning and Project Management.
A COIN Collaboration Platform (CP) which is a generic open source web portal
encompassing Social Networking interaction, Knowledge Assets accession and Business
Process management in a unique integrated multi-enterprise collaboration environment
customized for more or less hierarchical organizational networks.
The COIN Integrated System Butterfly Model represents the complete vision of the COIN
system integrating the previous identified basic components with the work provided in the final
part of the project. The focus of the work, apart the empowering of basic components, is the
integration and consumption of them through a more general vision of the system including
several users and methodologies.
The model is made of two distinct clouds, one for service provision (upper cloud) and the other
for service consumption (lower cloud), being also supported the pro-sumers case; in the middle
is the integration software allowing the communication among the two clouds and the service
consumption by other kind of actors.

6
Service Oriented Architectures for All, http://www.soa4all.eu/
7
Digital Ecosystems Network of regions for (4) DissEmination and Knowledge Deployment,
http://www.den4dek.org/
8

Figure 1 The COIN Butterfly model

A first upper cloud of open COIN and non-COIN service delivery platforms (providing utilities
for service development, registration, publication, search & discovery, orchestration &
execution) federated by EI/EC interoperable ontologies forms the COIN Upper Federation,
which could be seen as a subset of the Future Internet of Services core platform (or
Interoperability Service Utility) devoted to provide Smart Applications with common EI/EC
commodities like human interaction, data mapping, service reconciliation and process
synchronization functions.
A second lower cloud of domain- and sector-specific COIN and non-COIN Collaboration
Platforms provides Supply Chains, Collaborative Networks and Business Innovation Ecosystems
with advanced EI/EC services supporting the whole product/service life cycle and collaboration
phases, integrating legacy systems and data, constituting this way the COIN Collaboration
Federation, a part of next generation FI-based Enterprise Systems (FInES).
A third component is the integration software which is called COIN Front End and it is a plug-
in either for the service delivery or for the collaboration platform, depending on the case. The
scope of this component is to provide the communication among the two clouds and a set of
services for the consumption of the capabilities of the upper cloud for users not facing the system
from the lower cloud.
Four main typologies of users could access the COIN System:
i. Individual users (humans COIN Front End) who are browsing the content of the GSP
and of the CPs (e.g. configuration, nodes federation, services, business models, various
info);


9
ii. IT users (humans COIN Front End) who are able to build and develop their own
solutions (with or without the help of COIN platforms) and to link them to the COIN IT
System;
iii. Industrial users (humans and/or automatic business processes COIN Front End and
lower cloud) who are able to model and run their business processes in collaborative
enterprise environments (supply chains, collaborative networks, business ecosystems)
with the help of the COIN System.
iv. Federation Authority (humans COIN Front End) managing administrative issues of the
upper and lower cloud federations.
As depicted in the previous picture, the service delivery and collaboration platforms federations
are made of COIN platforms and non-COIN platforms. The COIN Platforms are platforms
which are based on the COIN open source developments, developed inside the COIN project by
our partners or by external third parties, for example in the community of COIN Multipliers. The
non-COIN Platforms are based on other service delivery and collaboration platforms and could
be provided by COIN Multipliers as well.
Utility and value-added COIN EI/EC services (Value Added Services) are available to both
clouds: they are registered in the COIN service delivery platforms nodes to be discovered-
composed-executed inside the upper cloud federation, they can be downloaded and integrated
with COIN collaboration platforms in order to be directly targeted by Industrial Users.
10
2.1 The COIN Generic Service Platform for Enterprise Interoperability and
Collaboration Service Provision

Srdjan Komazec1, Davide Cerri
1
, Klaus Fischer
2
, Ingo Zinnikus
2
, Francisco Javier Nieto
3
,
Pierfranco Ferronato
4
, Elia Conchione
4
, Antonio Panazzolo
4

1
STI Innsbruck, Universitt Innsbruck, Technikerstrae 21a, 6020 Innsbruck, Austria
{srdjan.komazec, davide.cerri}@sti2.at
2
DFKI GmbH, Campus D3_2, 66123 Saarbrcken, Germany
{klaus.fischer, ingo.zinnikus}@dfki.de
3
ATOS Research and Innovation, Atos Origin, Capuchinos de Basurto 6, 48013 Bilbao, Spain
francisco.nieto@atosresearch.eu
4Soluta.Net, via Edificio 2, 31030 Altivole, Italy
{pferronato, econchione, apanazzolo}@soluta.net

Abstract
The COIN Generic Service Platform (GSP) represents the core pillar of the COIN system. The platform is founded
on top of Semantic Web Service technologies and further extended in order to meet additional enterprise-level
functional requirements in terms of trust and security, negotiation and composition capabilities and scalability. The
platform provides the necessary capabilities for Enterprise Interoperability and Enterprise Collaboration service
provisioning, and at the same time offers a fertile environment to implement novel service provisioning business
models. This chapter sheds some light on the main COIN GSP components and their functionality.

2.1.1 Introduction
The central role of the COIN system is to fulfill a variety of lower-level (i.e., technical) and
higher-level (i.e., business) enterprise-level requirements for Enterprise Interoperability and
Enterprise Collaboration service provisioning, on top of which original business models, such as
Software as a Service (SaaS), can be implemented. In order to reduce difficulties in completing
such a challenging vision, the COIN system identifies the main aspects that need to be covered.
In particular, proper means to enable precise and automated goal-based discovery, selection and
invocation of service offerings is the core of the infrastructure. Additionally, sufficient support to
establish trust and security between the service provisioning stakeholders is needed.
Furthermore, facilities to enable (semi-)automated negotiation of the service provisioning terms
and policies, as well as composition of services are playing a significant role in this environment.
The platform should also exhibit proper means to scale in a peer-to-peer fashion over service
usage tasks exercised over resources contributing to the service descriptions (e.g., service
discovery, ranking and selection and invocation). All those aspects are blended together in a
platform called COIN Generic Service Platform (GSP), explained in the following sections.
2.1.2 The COIN Generic Service Platform
The Web service technology stack allows exchanging messages between Web services (SOAP),
describing the technical interface for consuming a Web service (WSDL), and advertising Web
services in registries (UDDI). However, in traditional Web service implementations, the lack of
information to express the meaning of the data and of the vocabulary referenced by the interface,
as well as the lack of formalisation of the Web service behaviour, implies the requirement of
human intervention in tasks such as Web service discovery, composition, ranking and selection,
thus severely hindering the automation of the envisioned tasks.


11
Semantic Web Services (SWS) [6] aim at providing more sophisticated Web service
technologies through the introduction of semantic Web technologies. SWS utilise ontologies as
the underlying data model in order to support semantic interoperability between Web services
and clients, and apply semantically enabled automated mechanisms that span the whole SWS
usage lifecycle, comprising discovery, selection, composition, mediation, negotiation, and
execution of Web services. More generally, the introduction of semantics as an extension of
Service-Oriented Architectures, and thus the creation of Semantically Enabled Service Oriented
Architectures (SESAs), provides for next generation of service-oriented computing based on
machine-processable semantics. The advantages of SWS stem from the fact that explicit, formal
semantics is associated with the Web service description, and that the execution environment for
SWS is able to interpret and use this semantics appropriately. This supports direct understanding
of the Web service functionality at design time as well as at run time.
The SWS platform represents the heart of the COIN Generic Service Platform (GSP), as shown
in Figure 2. Alongside the core aforementioned tasks, the platform functionality is extended
towards providing support for the platform execution monitoring (Monitoring component) and
deferred goal resolution (Notification Broker component). In addition, the platform is
complemented with the three pillars, addressing following aspects: distributed peer-to-peer
service registries and evolutionary model repositories (P2P Federation Registry) that improve
scalability and availability of the platform and reduce single-point-of-failure risks; trust-security
mechanisms (Trust Negotiator, Trust Manager, TSD Portal and Security ESB components) that
provide support to establish and maintain trust in a transparent way between parties involved in
conversation with the platform (service requesters/providers), as well as secured access to the
resources and dependability policies; and intelligent agent-based service negotiation and
composition (Agent platform with Negotiation and Composition components) which provides
support for flexible service composition and usage policies negotiation.


Figure 2 COIN GSP Architecture

A single instance of a GSP can fulfil the requirements of scenarios characterised by limited scale
and closeness. There are however scenarios in which the above assumptions do not hold, and
which raise the need to support a distributed deployment because of scalability or dependability
reasons. The deployment is achieved thorough federation of GSP instances (Federation Adapter
component) and provided functionalities so that users of each one can benefit also from services
provided by other ones.
12
2.1.3 Semantic Execution Environment
As explained in the previous section, the core of the COIN GSP is a Semantic Execution
Environment (SEE), able to perform Web service discovery, ranking, invocation and monitoring
by leveraging semantic Web service descriptions. The COIN GSP SEE is based on WSMX,
which is the reference implementation of the Web Service Modeling Ontology (WSMO) [3], and
provides functionalities to discover and invoke semantic Web services. The COIN GSP SEE
extends WSMX along several directions, detailed in the following paragraphs.
First of all, the COIN GSP SEE includes a complex event processing engine coupled with
WSMX monitoring facilities. A Semantic Execution Environment constitutes a rich source of
events: at the level of the overall platform (e.g., the start of a Web service invocation process), at
the level of single functionalities (e.g., tracking of the functionality provided by the discovery
engine) and regarding external services (e.g., a fault during a Web service invocation). In order
to monitor such events, all internal components have been appropriately instrumented, thus
enabling detection and extraction of low-level events and generation of semantically-enhanced
event descriptions. These descriptions are defined in the context of the COIN ontology stack and
of the SEE ontology, which specifies structure and relationships inside the SEE. Since events
have an ontological representation, the complete event history is preserved in an RDF repository
for convenience purposes (support for massive storage, inference and querying). Before reaching
this repository, events must be adequately processed in order to detect and react in a timely
manner to potentially complex situations of interest (e.g., three failed attempts to invoke a
particular Web service may trigger another round of Web service discovery, in order to find a
different solution). For this processing step, the COIN GSP SEE integrates an RDF-based
Complex Event Processing engine (RDF-CEP). The primary objective of RDF-CEP is to detect
occurrences of RDF triples which satisfy expressive RDF patterns. When a complex event is
detected, the engine executes the appropriate actions associated with the detected event (e.g.,
updating the aggregated statistical measures, notifying the administrator about successive failed
attempts to access GSP facilities, etc.).
In order to enable asynchronous notification of discovery results, the COIN GSP SEE includes a
Notification Broker component. This component is responsible for registering and storing user
subscriptions and for sending notifications when new results are available. The COIN GSP SEE
supports subscriptions to goal-based discovery, so that a user can register a goal and then be
notified when a service which matches that goal has been registered. The notification can be
delivered via email or by invoking an external Web service. The notification mechanism is not
limited to goal-based discovery, and can be easily extended to other processes.
WSMX can only support single-instance deployments while, as previously discussed, in COIN
there is a need to support a federation of multiple GSPs. The Federation Adapter component is
responsible for forwarding discovery requests (goals) and responses between different GSPs.
Target GSPs for a request can be chosen basing on the category of registered services, on GSP
non-functional properties (e.g., offering free services), and on the platform services provided by
the GSP (e.g., a certain GSP may offer service discovery but not invocation, whereas the client
may want only services that can be automatically invoked). Multiple federations and clusters can
be supported, as each GSP that receives a forwarded request may in turn forward it to another
GSP which is unknown to the previous GSP in the path.
Last but not least, the COIN GSP SEE includes a ranking engine to rank discovered services
according to user preferences. The ranking engine is capable of invoking external services to be
used as additional sources of information, e.g. regarding reputation of services.
2.1.4 Agent-Based Negotiation
In the first place services, as they are registered in the COIN GSP, can be seen as atomic services
provided by individual service providers and made available for execution through the COIN
platform where the details of how the service is actually provided is hidden from the user who


13
requests the service. However, it is not realistic to assume that a user of the platform always
specifies requests which can be directly matched with the available services. Therefore, the
platform should also be capable of handle requests that require combinations of available
services. Such combinations of services are commonly investigated under the topic of service
composition (for an overview see e.g. [5,9]).
Service composition is a complex field and comprises several aspects. For the purpose of this
discussion, the distinction between design time and runtime and the difference between
predefined and automatic compositions is emphasized. These distinctions might be regarded as
related, however they are rather orthogonal, as e.g. automatic composition could be used at
runtime, but also at design time when a process designer requests support for potential service
compositions to be integrated into a workflow at design time. So while the process designer is
quite likely interested in the details of how a service is provided, a platform end-user most
probably wants to use the service in a black box manner and therefore is not interested in these
distinctions.

Figure 3 Composed services in the COIN context

Accordingly, three roles can be distinguished within the COIN setting: the service provider who
owns a service and provides a service description (in WSML) when registering the service, a
process designer who uses and combines available services to define workflows (including
automatic compositions if necessary) providing them through or on top of the platform and a
platform end-user who consumes these services and processes according to his or her business
goals. Note that design time is in general different for service provider and process designer.
Predefined compositions can be further distinguished into static and hybrid compositions. A
static process is usually defined with a business process development tool. An agent-based
modelling and service invocation environment is used, because it allows flexibility in service
composition in the sense that the services can be composed in a goal-oriented manner. Hybrid
processes could contain parts where the concrete service to be used at runtime would be
determined according to runtime information (late binding).
Predefined compositions constitute an essential part of business processes in service-oriented
architectures. The nature of many services requires adjusting the business process in terms of
process adaptation and data conversion. For defining and executing agent-based service
compositions, a modelling environment which allows specifying complex interaction and
workflow patterns for service composition and agent-based negotiations is developed (see e.g.
[4]).
14
For automatic service composition, the approach for semantic services in OWL-S to the COIN
scenario is adopted. For OWL-S, the conversion of services to the planning domain definition
language PDDL has been proposed (see [7]). In an analogous way, the conversion can be done
for WSML services. A WSML service with preconditions and post-conditions defined in a
capability is transformed into a PDDL planning operator with corresponding pre- and post-
conditions. To solve the corresponding planning problem, a PDDL planner can be used. The
result of an automatic composition is in general a sequence of services (see [2]).
2.1.5 Trust and Security
One of the challenges to be solved in COIN is to improve the security in enterprise
interoperability and collaboration scenarios, where it is important to guarantee the secure
interaction between parties. For doing so, traditional security mechanisms have been combined
with so called soft security mechanisms, more oriented to social-based solutions and other non-
functional aspects of the communication, such as trust on services, negotiation of trust-related
aspects for interactions and policy management.
All these elements have been combined in such a way that the information about trust is used as
input for the trust aspects in negotiation and policy management, while the result of the
negotiation, moreover, is an agreement which becomes a policy in the system, to be enforced
with traditional mechanisms already deployed in an Enterprise Service Bus (ESB). All the
components together, interacting automatically, conform the Trust, Security and Dependability
Platform (TSD Platform) in COIN, as seen in Figure 4.
The basic features are provided by the ESB, where typical components for basic security features
are deployed: policy enforcement, authentication and encryption/decryption, etc.
ESB
(PEP, PDP, STS)
Policy
Administrator
Trust
Negotiator
Trust
Manager
SOAP SOAP
Policies
TLA based Policies
Trust Value Trust Value

Figure 4 - Main components and relationships in the TSD Platform

The Trust Manager is a component which calculates the trust associated to services and service
providers based on a wide model divided in four main parts: General (location, releases, age,
etc.), Capability (announced functionalities and non-functional properties), Measure (monitored
values for response time, data volumes, scalability, agreements fulfilment, etc.) and Reference
(evaluation from users and other platforms, information in news, etc.). Using the monitoring
capabilities of the GSP Semantic Execution Environment and other information sources (service
description, information in DBs, etc.), it is able to perform different calculations based on a fuzzy
set and combined with a special weighted average which exploits an ontology containing
information about used aspects in the model and their relationships, performing a specific control
of the consistency between the aspects in the model.


15
One of the components which use the Trust Manager results as input is the Trust Negotiator,
which follows a two stages negotiation. In the first one, credentials are interchanged between
participants, in order to determine which information to disclose and how to advance the
negotiation. Once both parties trust on who they are, a set of concrete security terms are
negotiated (bits number for keys, minimum trust values of services and providers, etc). Finally, a
Trust Level Agreement (TLA) is obtained, and a policy is generated, for the TLA fulfilment.
The Policy Administrator is the component which receives the policies, performing a hot
deployment of those policies in the ESB components, retrieving context information required in
the policies (such as trust values). In the case several policies must be activated at the same time,
this component is in charge of merging the actions.
Finally, there is a portal which serves as a front-end for facilitating management tasks. It
accesses to the Trust Manager, the Trust Negotiator and the Policy Administrator for showing
information about trust values, negotiations performed and policies stored to administrative
users.
2.1.6 Peer-to-Peer Registry and Repository
This section describes the key motivations that were at the base of the definition of the
architecture for the Registry and Repository which are the main components of the COIN
Evolutionary and Pervasive Service Platform.
The strategy is to have a system that does not move data across the architecture when it is not
needed. The goal is also to support different architectures, namely: information, model, and
application.
The service is created and maintained by the service provider, while models are persisted in a
separate repository. Models are horizontal with respect to the information and are also shared
across services. This separation of concerns, as implemented in this project, helps to avoid data
replication and it aims at providing a better alignment between IT and the business.
Inside the COIN Evolutionary and Pervasive Service Platform, registered services are associated
to models that are stored in the Repository. A registry entry contains only attributes that are used
for:
consuming the service,
retrieving the business model instance,
retrieving information about the service vendor,
retrieving the WSDL associated with the service,
retrieving models that are associated with the service.
The service is thus described by models that are associated with it. A user who wants to find a
certain type of services must first of all search the models that contain the desired contents, and
then search for all the services associated with these models.
The Registry works like a DNS server: it does not contain any meta-data that describes services
but rather contains only information for associating a service to a model or an ID. Like a DNS
server, it must have a fully decentralized architecture for ensuring availability and reliability, and
also an automatic synchronization mechanism.
The Registry also manages the deletion of a registered service entry, to support the lease concept,
implemented by a 3rd party COIN component, which is external to the Model Repository and
Service Registry. A dedicated operation, in the Registry interface, is used to delete a specific
service entry.
16
The concept of template is introduced (as defined and used by Jini
8
) to improve models search.
To describe models are used tags as a folksonomy
9
, this is a way for creating a model description
that is driven by the community growing around models development.
The use of standards is considered very important in a project and in this way WSDL are used
for web services, the JAXR
10
API for storing and retrieving models.
Is also suggested the use of a service crawler and a data warehouse for performing data mining
on the data which is collected by inspecting business model instances. The data warehouse can
also contain model meta-data for performing powerful queries on clients requests. The
information contained in business model instances is collected by the service crawler that
retrieves them by querying the service provider, inspecting the business model instances and
reporting information to the data warehouse.

Figure 5 - P2P Repository/Registry Architectural viewpoint

2.1.7 Conclusion
This chapter clarified the notion of COIN GSP and its constituent parts. In the context of the
COIN system the platform serves as the broker, blending together needs of different service
provisioning stakeholders. In a nutshell, the COIN GSP is built on top of Semantic Web Service
technologies which enable basic platform functionality such as service discovery and invocation
in a federated manner. The platform is extended to meet the appropriate means to: establish trust
and security between the service provisioning stakeholders, provide agent-based (semi-)
automated service provisioning negotiation and composition facilities, and enable evolutionary
and pervasive aspects based on the usage of P2P service repository and registry. As such, the
platform provides the needed functionality to implement envisioned service provisioning
business models such as Software as a Service-Utility.


8
http://www.jini.org/wiki/Main_Page
9
http://en.wikipedia.org/wiki/Folksonomy
10
http://jcp.org/en/jsr/detail?id=93


17
References
[1] COIN Deliverable D3.2.1b, Evolutionary and Pervasive Service Platform, Final Specifications, 2010
[2] COIN Deliverable D3.4.1b, Business Knowledge and Negotiation Platform, Final Specification, 2010.
[3] Dieter Fensel, Holger Lausen, Axel Polleres, et al. Enabling Semantic Web Services: The Web Services
Modeling Ontology. Springer, 2007.
[4] Ingo Zinnikus, Xiaoqi Cao, Klaus Fischer. Agent-Supported Collaboration and Interoperability for
Networked Enterprises. In: Marten van Sinderen, Pontus Johnson (Eds.): Enterprise Interoperability. Proc.
of the Third International IFIP Working Conference, IWEI 2011, March 2011, Stockholm. Springer 2011,
pp. 204-215.
[5] J. Rao and X. Su. A Survey of Automated WebService Composition Methods. Proceedings of the1st Intl.
Workshop on Semantic Web Services and Web Process Composition, San Diego, 2004.
[6] Jorge Cardoso (edt.). Semantic Web Services: Theory, Tools and Applications. IGI Global, March, 2007.
[7] Klusch, M., Gerber, A. and Schmidt, M. (2005). Semantic Web Service Composition Planning with
OWLS-XPlan. Proceedings of the AAAI Fall Symposium on Semantic Web and Agents, Arlington VA,
USA, AAAI Press.
[8] Schahram Dustdar, Wolfgang Schreiner. A survey on web services composition, International Journal of
Web and Grid Services, v.1 n.1, p.1-30, August 2005.
18
2.2 The COIN Front End for Generic Service Platform Federation Consuming
Michele Sesana
1
, Sergio Gusmeroli
1
, Srdjan Komazec
2
, Davide Cerri
2
, Drago Trebenik
3

1 TXT e-solutions, Via Frigia 27, 20126 Milano, Italy
{michele.sesana,sergio.gusmeroli}@txtgroup.com
2STI Innsbruck, Universitt Innsbruck, Technikerstrae 21a, 6020 Innsbruck, Austria, {srdjan.komazec,davide.cerri}@sti2.at
3Joef Stefan Institute, Jamova cesta 39, 1000 Ljubljana, Slovenia
drago.trebeznik@ijs.si
Abstract
The involvement of users/stakeholders is a recognized key condition for the consumption of the GSP (Generic
Service Platform for EI/EC service delivery) federation and its further exploitation as well as the possibility to have a
fast and easy way to access the COIN system and to have a prior feedback about the system capabilities to further
adopt it in a deeper way. The COIN Front-End is the unique point of access (one-stop-shop) for both technical and
non-technical users of the COIN system, providing a set of functionalities for the consumption and evolution of the
Generic Service Platform Federation reported in the previous 2.1 chapter of this book. In this chapter two major
developments of the COIN Front End are highlighted and described. The first functionality is devoted to IT user/s
willing to publish their software products EI/EC services and/or platforms - through the COIN GSP federation. An
editable and customizable model of the federation is supporting the registration of new platforms and services, while
an interactive wizard is guiding the IT user step-by-step in the process of downloading COIN open source assets
platforms, services, knowledge bases, ontologies - in several forms (source code, binaries, pre-configured virtual
machines, open data and creative commons knowledge), configuring and customising them and finally linking them
to the existing federation and search-discovery-orchestration-execution functions. The second major development is
devoted to generic users, either registered or not registered, willing to know more about the COIN EI/EC services
and how to access and consume them. A Google-like semantic and contextual search engine is able to analyse
complex queries and find the best matching with COIN service and knowledge bases, while a service try-me
experimental facility is providing users with concrete hands-on technical and business use cases.
2.2.1 Introduction
The Generic Service Platform Federation described in chapter 2.1 is the upper level of the COIN
System, providing a big set of innovative functionalities to handle with registered services. In
order to fully exploit the federation capabilities, it is necessary to have a component able to
communicate with it in different forms and customised for different users and business cases
(automatic or human driven). In particular, in the presence of complex technological artefacts,
human factors in accessing and using conveniently the COIN GSP Federation are a key aspect
for its successful adoption and take-up: likability, friendliness, usability, but above all clear
messages about functionality, costs and business benefits need to be taken in due account; users-
stakeholders early and participative involvement could make the federation a real exploitable
asset of the project. In this chapter, the COIN Front End is described, a COIN System component
focusing on one hand to the consumption of the GSP Federation capabilities and on the other
hand to support the evolution of the system itself acting as a facilitator for the involvement of
service providers in the system.
The COIN Front End supports two access modalities: i) direct access by humans ii) API offered
for the usage by other IT systems. In COIN Front End design, two major users have been
identified to be part of the system: IT user willing to become service providers of different pieces
of software of the COIN System exploiting the evolutionary perspective of the solution and
Generic user willing to explore the COIN capabilities like services discovery, invocation,
composition, etc.. The Generic User is a non-technical person with few or no IT experience (e.g:
a businessman, a manager, a BP designer) without deep knowledge about ontologies
preconditions/postconditions and other technicalities of the EI/EC domain which are indeed
necessary to deeply understand the services the COIN system is hosting.
This book section focuses on the direct access to the Front-End by humans: sub-chapter 2
focuses on the Front End support to IT user, sub-chapters 3 and 4 highlight the access by non-IT


19
people defined as generic users. The following book chapter (2.3) provides a view of the CP
Federation accessing the GSP Federation through the COIN Front End API.
2.2.2 GSP nodes and Services provisioning to the GSP Federation
A single instance of a GSP can fulfil the requirements of scenarios characterised by limited scale
(i.e., in which a single instance can handle all the knowledge, e.g. ontologies and service
descriptions, and all the requests) and closeness (i.e., in which all the relevant knowledge is
available in a single instance, controlled by a single authority). There are however scenarios in
which the above assumptions do not hold, and which raise the need to support a distributed
deployment. Besides cases in which a distributed infrastructure is needed because of scalability
or dependability reasons, but it is still under the control of a single authority, there are scenarios
in which different GSP instances are established independently by different providers or groups.
These providers can then want to allow users of one GSP to be able to use also services provided
by the other ones, and therefore to federate their GSPs. In particular, we can distinguish between
emergent and planned distributed approach. An emergent approach is one in which
different GSP instances are established independently and grow and evolve in a Platforms
ecosystem, e.g. because they are owned by different providers / groups / consortia. A planned
approach is one in which the owner of a GSP decides that a single instance is not enough (e.g. for
scalability reasons, but also for different business models), and therefore needs to deploy a
distributed platform architecture which includes multiple instances. The two approaches can be
implemented at multiple levels: a distributed instance resulting from the planned approach can
act as a single node of the federation in the emergent approach. They are however different, both
technically (e.g., the planned approach naturally brings the accent to topics like scalability and
self-organisation, while trust between different instances is not an issue) and from a business
perspective.
The central question to address is whether the knowledge (e.g. the service descriptions) used by
each GSP node is local (i.e. every instance has its own knowledge, which is not directly
available to other instances) or global (i.e. each instance has access to the same knowledge, by
retrieving it from some globally accessible source, that is accessible to all GSP instances).
With respect to the two approaches, it is quite clear that in the planned approach the issue of
local or global knowledge is mainly a technical choice, because from a higher point of view the
distributed architecture is always seen as a single entity. On the contrary, the emergent approach
seems to present a much better fit with the local knowledge approach, as the owners / users of
each instance may want to keep their own knowledge (e.g. their own service descriptions) in
their own platform, and make it only indirectly accessible to federated platforms (i.e., through the
services provided by the GSP, e.g. service discovery). For this reason, and considering that the
global knowledge approach would be, due to the technical constrains, hard to realise in COIN
GSP, we follow the local knowledge approach. This means that each GSP instance has its own
repository which is not directly accessible to other instances, but only through the services
provided by the GSP. This does not exclude the presence of a more lightweight global
registry/repository used to store general information about GSP instances (used e.g. in order to
discover other GSP instances). Therefore, the starting-point scenario is a single instance
capable of discovering and invoking Semantic Web Services. Starting from this, we envision the
evolution of the GSP along three dimensions:
Goal decomposition and service composition,
ranking based on non-functional properties (nfp),
node federation.
These three dimensions can be used to define a cube, shown in Figure 6, which represents
possible evolutionary paths and points starting from the base. We now describe the issues to be
addressed in each of these scenarios (i.e., each vertex of the cube).
20
A
D
C
B
E
G F
base
+ federation
+

c
o
m
p
o
s
i
t
i
o
n
+

n
f
p

r
a
n
k
i
n
g
+ federation
+ federation
+

c
o
m
p
o
s
i
t
i
o
n
+

c
o
m
p
o
s
i
t
i
o
n
+

n
f
p

r
a
n
k
i
n
g
+

n
f
p

r
a
n
k
i
n
g

Figure 6 - GSP evolution cube

While moving through the cube node the following scenarios and their characteristics are
identified:
Scenario A (Base) in which there is a single GSP instance which is capable to discover and
invoke single services that match the users goal.
Scenario B (Federation) in which each node must be able to forward the user goal to other
nodes. In larger scale deployments a mechanism to identify a subset of relevant nodes as
targets for forwarding the request is needed. Such mechanism can exploit some
specialisation of the nodes (e.g. w.r.t. the domain), however, especially in the emergent
case, this is not by design. Moreover, all nodes will be capable of offering more or less the
same functionalities (discovery, invocation, etc.). Therefore, a lightweight mechanism can
be appropriate, based on some simple categorisation (taxonomy or simple ontology). Such
a mechanism is called COIN GSP Model and it is described below.
Scenario C (Single instance with service composition) in which a composition of services
that can fulfil the users goal, rather than only a single service, can be identified as a match.
Scenario D (Federation with service composition) which is the composition of scenarios B
and C. In this scenario, each node can forward the goal to other nodes as in B, decompose
it into subgoals as in C, and forward subgoals to other nodes. Different decompositions
may be realised by different nodes.
Scenario E (Federation with nfp ranking) which is built on top of scenario B (federation),
adding ranking based on non-functional properties. The federated architecture implies the
fact that multiple lists of matches, coming from different nodes, need to be merged, taking
into account ranking.
Scenario F (Single instance with service composition and nfp ranking) which is built on
top of scenario C (single instance with service composition), adding ranking based on non-
functional properties. In this scenario, matches can be composed by one or more services,
so there is a need to define nfp-based ranks for compositions of services, rather than just
for single services.


21
Scenario G (Federation with service composition and nfp ranking) which is the most
complex scenario, built on top of scenarios E and F. It includes all the three dimensions we
considered.
It is worth noting that each and every next step is adding additional complexity level, thus asking
for advanced solutions when treating interdependencies. COIN project has provided solutions for
the scenarios A, B, C and D while the more complex cases, i.e., scenarios E, F and G, are
considered as future work.
In a federated environment, the different nodes (i.e. GSP instances) of the federation need to be
characterised, so that requests can be directed to nodes that can be able to fulfil them. This
encompasses two different aspects:
Functional aspects. These cover both the functionalities of the GSP itself (i.e. from
service discovery to service invocation) and the functionalities of the services registered in
the GSP. While the former ones can be seen just as regular service platform descriptions
(i.e. what a single GSP node is able to do in terms of service discovery-execution
monitoring cycle, including intelligence, negotiation and decomposition capability), in
order to cover the latter ones, some aggregated and more complex [semantic] descriptions
are needed. In the COIN federation this is done through a functional taxonomy: federation
nodes are therefore annotated with the categories of services registered at them. These
annotations are used for service discovery, in order to decide to which nodes of the
federation a goal (i.e. a request to discover services) should be sent.
Non-functional aspects (e.g., availability, reputation, price). Again, descriptions covering
these aspects can be applied both to the GSP itself and as an aggregated image of the
services registered at the GSP. Non-functional aspects are used together with functional
aspects to support the decision process in discovering and selecting Web services, and in
particular for ranking purposes. A typical case is when two or more services are
functionally equivalent (and thus can functionally fulfil the users goal), but they differ in
some non-functional aspect (e.g. the price). The problem of how to aggregate and
harmonize end-to-end different, heterogeneous non-functional aspects and policies at both
platform and service levels is still an open research domain, which COIN is just partially
and incompletely addressing.

In order to describe federation nodes according to these dimensions, COIN provides a set of
ontologies, as shown in Figure 7. At the top there is the COIN Federation Ontology, which
defines fundamental concepts such as Service Category and Federation Node. On the lower
level, the COIN Platform Taxonomy describes services offered by the node itself, the COIN
Functional Taxonomy provides categories for registered services, and the COIN Non-Functional
Property Taxonomy is used to describe non-functional aspects. All taxonomies are modelled
using SKOS [1]; a fragment of the COIN Functional Taxonomy is shown in Listing 1.
22

Figure 7 - COIN GSP model ontology stack



Listing 1: Fragment of the COIN Functional Taxonomy

This model is used in the COIN Front-End by IT User/s, who are able to build and develop their
own solutions and to link them to the COIN IT System; the COIN Front-End provides a specific
kind of access and set of functionalities allowing him/her to explore the COIN technical assets
(source code, binaries and pre-configured virtual machines), to download and customize them
<http://www.coin-ip.eu/ontologies/COINFunctionalTaxonomy.owl> rdf:type owl:Ontology ;
owl:imports <http://www.w3.org/2004/02/skos/core> ;
owl:imports <http://www.coin-ip.eu/ontologies/COINFederationOntology.owl> .

:COINFunctionalTaxonomy rdf:type cfo:ServiceTaxonomy ,

:EnterpriseService rdf:type cfo:ServiceCategory ,
skos:inScheme :COINFunctionalTaxonomy ;
skos:topConceptOf :COINFunctionalTaxonomy .

EnterpriseCollaborationService rdf:type cfo:ServiceCategory ,
skos:inScheme :COINFunctionalTaxonomy ;
skos:broader :EnterpriseService .

:EnterpriseInteroperabilityService rdf:type cfo:ServiceCategory ,
skos:inScheme :COINFunctionalTaxonomy ;
skos:broader :EnterpriseService .

:Messaging rdf:type cfo:ServiceCategory ,
skos:inScheme :COINFunctionalTaxonomy ;
skos:broader :EnterpriseCollaborationService .

:SMSMessaging rdf:type cfo:ServiceCategory ,
skos:inScheme :COINFunctionalTaxonomy ;
skos:broader :Messaging .

:EmailMessaging rdf:type cfo:ServiceCategory ,
skos:inScheme :COINFunctionalTaxonomy ;
skos:broader :Messaging .

:CollaborationNetwork rdf:type cfo:ServiceCategory ,
skos:inScheme :COINFunctionalTaxonomy ;
skos:broader :EnterpriseCollaborationService .

:DataTransformation rdf:type cfo:ServiceCategory ,
skos:inScheme :COINFunctionalTaxonomy ;
skos:broader :EnterpriseInteroperabilityService .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix cfo: <http://www.coin-ip.eu/ontologies/COINFederationOntology.owl#> .
@base <http://www.coin-ip.eu/ontologies/COINFunctionalTaxonomy.owl> .
@prefix : <http://www.coin-ip.eu/ontologies/COINFunctionalTaxonomy.owl#> .


23
and finally to exploit such assets by creating a new federation node and merging it in the COIN
GSP Federation (upper cloud of the COIN butterfly model). The human computer interaction
primitives have been specifically designed to support a technical person. New services
registration functionality is also provided by GSP nodes and briefly described afterwards.


Figure 8 - COIN Assets Download

The previously presented model is provided as a wizard to the IT user through the COIN Front-
End; it is pre-configured at the time the user accesses the menu and divided into three different
forms. The user has just to complete the template and to insert the new GSP node characteristics.
Finally the submit form makes the description available to the federation authority that will
check and approve/reject it.

Figure 9 - GSP Model Configuration

The node creation process should be mediated by the COIN Federation Authority taking in
charge of the control of the compliance of the new GSP node registration to the federation.
Browse
Download
24

Figure 10 - nodes waiting for approval

The prerequisite to register a new service at a COIN GSP node is to build its WSMO [3]
compliant semantic description. Such a description dictates, in a formal and unambiguous way,
functional (service capability and behavior) and non-functional (e.g., price, reputation, reliability,
etc.) service aspects. In order to reduce complexities while building the description COIN has
developed a Web-based wizard consisting of five consequitive forms focusing on different
semantic Web service description aspects. Apart from the Web form shown at Figure 11 (which
provides a user friendy way to define service pre-/post-conditions) the other forms include
definition of general Web service atributes (service name and namespace), definition of non-
functional properties (e.g., service price), and definition of behavioral aspects (service
choreography).

Figure 11 - The Web form for defining service pre-/post-conditions



25
2.2.3 Consume the GSP Federation by a Human Oriented Interface
As stated in the introduction, the consuming of GSP federation by non-technical users (e.g.
business man, managers, BP designers) is very important to actually exploit the COIN system.
The generic user is defined as a person willing to explore through a simple web interface the
COIN capabilities like services discovery, invocation, composition, etc. In addition to that,
he/she is a non-technical person with few or no IT experience and without any deep knowledge
about ontologies preconditions/postconditions and other technicalities of the EI/EC domain and
he does not have time/willingness to learn any technical stuff. The COIN Front-End provides this
user with a set of functionalities to explore the COIN assets through an interface and features
specifically designed to support this kind of non technical person and guiding him through in the
COIN assets exploration and understanding. The implementation of the system for the Generic
user comprises the GUI by which the user can access the functionalities visible in Figure 12.

Figure 12 Generic User Functionalities

Services searching by templates allow the user to browse services and interrogate the GSP
federation searching for services. Browse&Search (semantic search) are guided by templates:
pre-configured goals that the user can easily customize for its searches. The understanding of
COIN assets is based on two main streams: on the one hand, knowledge about the service and its
reputation is provided; on the other hand the user can try the services (both automatic web
services and interactive services) from the user interface. The knowledge is based on the
Semantic Media Wiki [2], a free, open-source extension to MediaWiki based on an ontology
driving the link between contents. The user is involved in the process with an additional
functionality that allows him/her also to subscribe to a news notification service about some
goals: for example in case the businessman is not satisfied by found services or he/she did not
find anything, he/she can subscribe itself to the goal created (e.g: transformation from Format a
to Format b) and receive information on further registered services matching with this goal.
Interactions between the COIN Front-End for the generic user and the other components of the
COIN System are depicted in Figure 13
26

Figure 13 - COIN Front-End deployment schema and COIN System upper Cloud interaction

The access to the tool could be done anonymously or by a simple registration (username,
password and email address to receive notifications about services). The Browse & Search
interface (Figure 14) guides the user in the process of easily composing a semantic search; the
panel is composed by 5 main parts:
1. Search scope defining the scope of the search (one specific node or the whole federation).
2. Functional Concept Selection this interface allows the user to select, on top of a
functional taxonomy, the desired functionalities that the service should fulfill. Concept
can be accessed in three different ways: i) exploring the taxonomy tree ii) typing in the
fast search the initial characters of the word iii) insert free text in the proper free text
box and let the system interpret the text and match it with the taxonomy (please refer to
the next subchapter for more details)
3. Template Box: to simplify the creation of the semantic search, a set of templates
associated to functional taxonomy concepts are provided; few intuitive clicks by the user
are enough to create a correct request for the GSP federation.
4. Suggestion Box automatically at the time a functional taxonomy concept is selected, the
system does a fast search to the closest GSP and retrieves some services to be presented
to the user. The search is done by a fast SPARQL query. The goal of this box is to
provide the user with a fast check about what he/she will retrieve with the further
semantic search.
5. Semantic Search based on the selected template, the structure of the semantic search is
provided. User has to click on all the trees visualized selecting the concepts closer to
his/her wishes. Selecting the roots of every tree the user will create the higher level
search available. Clicking on leaves the search will be more specific. The search can be
tailored by the user on its need using the non functional properties expressing its own
preferences that will rank found services; price, reputation and time are available for this
purpose.



27

Figure 14 - Browse & Search interface
Clicking the submit button, a new form shows found services. In this case the search is semantic
and involves the GSP federation. The system hides completely the details of the search process
that is not relevant for the user. As better visible in Figure 15 results are divided in three different
areas:
Exact Match (services marching exactly with user whishes)
Plugin (services more specific in respect with the request)
Subsumption (services less specific in respect with the request)

Figure 15 - detail of the semantic search results

For each service found, the system provides a small description of itself; to let the user
understand better the service purpose and capabilities the system provides different
functionalities accessible by buttons close to the service description:
28
Try-me button shows a pop-up able to invoke the corresponding service. The form is
created automatically starting from the ontological description of the service returned by
the GSP to which is registered.
Wiki The wiki button drives the user to the second tab of the interface (maintaining all
the data in the previous tab) opening the wiki page describing the service. Depending of
the service different information is displayed containing in some cases the example I/O
files for the service test.
Trust button displays summary information of the selected service. A global value is
provided and four sub values composing the global value are detailed: i) general, ii)
capability, iii) measure and iiii) reference


Figure 16 - from the left: try-me button form, trust values and COIN SMW for information on the service

2.2.4 Guiding User Semantic Search by Free Text Wishes Expression - JSI
Free Text Wishes Expression (FTWE) service is aimed at helping users to use natural language
expressions for efficient search through various text descriptions in COIN platform. The first
case in which the service has been used is the natural language search through the extensive
COIN services registered.
The main feature behind is that the free text query as well as documents contained in the COIN
Semantic Media Wiki are being processed through the Enrycher service pipeline. Both
constructed triples graphs are then being matched. By using similarity measures the hit ranks are
being calculated and presented in a ranked list of hits. Figure 17 presents the main FTWE
pipeline which consists of four main service sets that are manipulating texts from the language
level to the document level.
Lnr
CCln LemplaLe
descrlpLlons daLaseL
LAnCuACL-
LLvLL
8CCLSSlnC
Ln1l1?-LLvLL
8CCLSSln
Ln1l1? C8AP
8CCLSSlnC
uCCuMLn1-
LLvLL
8CCLSSlnC

Figure 17 - FTWE pipeline

Languagelevel processing are background services that include sentence splitting, tokenization,
part of speech tagging and entity extraction. Entity-level processing services identify potential
entities. This is done with anaphora resolution, where pronoun mentions are merged with literal


29
mentions, co-reference resolution that merges similar literal mentions and entity resolution,
which links the in-text entities to ontology concepts. Document-level processing operates on the
document instead of entities. Here we first construct semantic graphs out of extracted triples
using several entity and context matching methods. In such graphs nodes are entities (objects,
subjects) that are connected with relations presented by verbs. Such graphs are then being used
for matching functionalities in search but also for other more semantically heavy features like
ontology construction services, taxonomy categorisation and summarisation. Figure 18 presents
the complexity of the enrichment services.

Figure 18 - Enrichment services

This is why all textual documents (templates descriptions in our case) are being processed and
enriched and presented as a graph of triples of all descriptions. The created graph is then used to
create inverted index that enables fast, cheap and efficient search.
FTWE service also includes heavy semantics features like classification, overall semantic graph
construction out of n-grams, cross lingual support and reasoning. In the service search case these
features are not being used since it would be too costly in respect to the preferences. For other
COIN services that are using large scale document repositories like process descriptions, reports,
formalised descriptions, external databases, etc, these features can be easily switched on. By
including neutral language representation model that are being constructed out from many
multilingual aligned corpuses some additional features dealing with cross and multilingualism
can be implemented i.e. multilingual search, cross-lingual search, graphs (ontologies) translation,
language detection, etc.
2.2.5 Conclusion
The implementation and the availability of the COIN Front End for accessing the COIN Generic
Service Platform Federation allows the involvement of stakeholders who are not yet connected to
the COIN system and supports the loyalty of existing stakeholders in collaborative networks
using the COIN Collaboration Platform (see chapter 2.3). The early and participative
involvement of final users is a recognized key condition for the success of the GSP federation
and for further take-ups and exploitation opportunities. There are two major developments
reported in this chapter. The former one is related to the nodes and services in the GSP
Federation and supports IT user/s willing to publish their software products through the COIN
System, an editable and customizable model of the GSP is provided to support the registration of
30
a new GSP node to the federation and a GUI supports the user in the process of downloading
COIN assets in several forms (source code, binaries and pre-configured virtual machines) and of
providing new ones. The second major development is the support to the generic user by
Consume the GSP Federation by a Human Oriented Interface and Guiding User Semantic
Search by Free Text Wishes Expression. By using this interface non-IT user/s can easily search
for COIN services, understand them by accessing related knowledge and experiment them. The
COIN Front End has been integrated in the Final COIN System and demonstrated in COIN
project reviews.

References
[1] SKOS Simple Knowledge Organization System Reference, W3C Recommendation 18 August 2009,
http://www.w3.org/TR/2009/REC-skos-reference-20090818/
[2] Semantic Media Wiki http://semantic-mediawiki.org/wiki/Semantic_MediaWiki
[3] Dieter Fensel, Holger Lausen, Axel Polleres, Jos de Bruijn, Michael Stollberg, Dumitru Roman, and John
Domingue. 2006. Enabling Semantic Web Services: The Web Service Modeling Ontology. Springer-Verlag
New York, Inc., Secaucus, NJ, USA.


31
2.3 The COIN Collaboration Platforms Federation for Enterprise Networks and
Business Ecosystems
Michele Sesana
1
, Sergio Gusmeroli
1
, Jens Eschenbcher
2

1 TXT e-solutions, Via Frigia 27, 20126 Milano, Italy
{michele.sesana,sergio.gusmeroli}@txtgroup.com
2

BIBA - Bremer Institut fr Produktion und Logistik GmbH, Hochschulring 20, 28359 Bremen, Germany, esc@biba.uni-bremen.de
Abstract
In a global economy, Enterprise Collaboration represents the most promising solution for European industry (and
SMEs) to stay competitive and to continuously innovate its products and services. IT support to collaboration among
the members of a networked enterprise, being it a supply chain, a collaborative network or a business ecosystem, is a
central point of the COIN system. The possibility to promptly react to a Business Opportunity (BO) building Virtual
Organisations, managing the operational and dissolution phase as well as the support to the interoperability among
different partners is addressed by the COIN Collaboration Platforms Federation. In this paper it is presented how
COIN supports networked enterprises by the COIN Collaboration Platform (CP) illustrating its functions,
characteristics, BPM facilities and the implementation connected to the other parts of the COIN system allowing the
injection of a smart support in the construction of the collaborative business processes. At the end of the paper, the
concept of Extended Products and Distributed Collaborative Innovation in Virtual Factories is also introduced as a
promising future research topic in which the support on networked enterprises by COIN Collaboration Platforms
federation could be exploited.
2.3.1 Introduction
In the overall COIN Vision, networked enterprises are organized in supply chains, collaborative
networks and business/innovation ecosystems. Their collaboration is often supported by IT
Collaboration Platforms (CP) and whenever cross-network interconnection is needed the
community of CPs in different domains and sectors needs to be supported by an open and trusted
federation of CPs. Lets imagine for instance cross-sector collaborations like those established
between textile industry and automotive to build innovative car seats covers, between furniture
industry and shipbuilding to build cruise ships interiors resistant to marine environments; or also
imagine cross-domain collaborations when a product-oriented collaboration (design,
development, production, post-sales, end-of-life) needs to be extended and complemented by a
service-oriented collaboration (service life cycle management to be reconciled with the PLM) or
by a market-oriented collaboration (marketing & sales, new business and revenue models, online
vs. physical selling).
In the COIN interpretation, Collaboration Platforms [1] [2] [3] provide utilities for social
collaboration (e.g. wikis, blogs, communities, user profiling), knowledge collaboration (e.g.
repositories, search engines, up- down-load facility, classification) and business collaboration
(e.g. workflow, workgroup and business process management services). A Collaborative
Platform is not a monolithic and static entity but it is very modular and easily composable in
order to adapt itself to the specific characteristics of the enterprise network, giving to every
cluster the possibility to work in a personalized environment built on top of their specific needs
such as domain, sector, country, i.e. via the ontology for classifying documents or the ontology
for classifying human competencies in the different domains. Next chapters of this paper will
show how COIN supports Networked Enterprises and Business Ecosystem by a Collaboration
Platforms Federation.
2.3.2 Modelling, executing and outsourcing cross-enterprise collaborative business processes
The lower cloud of the COIN System (please refers to the introduction of chapter two for more
information) is composed by an incremental set of domain- and sector-specific COIN and non-
COIN Collaboration Platforms (CPs).
32
2.3.2.1 The COIN Collaboration Platform: main functions and characteristics
The COIN collaboration platform provides a complete set of collaboration functionalies to
support the human collaboration on the CP; the basis set of fuctionalites provided natively by the
portal is increased by COIN service (both baseline and innovative) that can be plugged into the
environment; messaging services, maps about the human collaboration in the portal, blogs,
shared calendars are just a part of the big set of collaboration services available. The huge data
set of the portal composes the Knowledge Base of the cluster that can be used as base for further
smart services.
COIN Collaboration Platforms are also addressing web services to implement business
processes: such web services allow the integration of legacy databases and legacy system and the
direct invocation of EI/EC services. Such web services could be concentrated in the center of the
network (hierarchical supply chains) or be fully distributed among the network partners,
depending on the organizational form chosen by each network. In any case, a distributed or
concentrated Enterprise Service Bus, interoperable with the ESB of the COIN EI/EC Platforms,
is the best technical solution to integrate them.
2.3.2.2 The COIN Collaboration Platform in the COIN System: the BPM facility
A first key aspect of the COIN System is how to connect the Internet of Enterprises (including
hierarchical and non-hierarchical collaboration forms) with the Internet of Services (including
clouds of automatic web services and user generated services perhaps generated from linked
open data), i.e. to link service providers with service consumers or to finally bridge the gap
between IT and Business in the field of EI/EC obviously. For instance, it is foreseen that big
ESA (Enterprise Software and Applications) providers will soon put in the public domain or
provide at a very low cost their interoperability services/information as an adjunct to their Cloud
SaaS offer (e.g. under freemium-like business models); on the other side, the Service Web and
Linked Open Services movements will allow non-profit and/or standardization organizations to
publish their open standards and specifications to support every single Internet user (SMEs,
micro-enterprises but also individual entrepreneurs) in developing and using his/her own EI/EC
solution. The COIN system is giving visibility of both Internet of Services opportunities to the
Internet of Enterprises.
Secondly, in a Future Internet perspective the same challenge could be seen as how to link FI
platforms services (in this case EI/EC services) with Smart Socio-technical Applications (in this
case Smart Enterprises). In the FI PPP, the so-called Core Platform is providing Generic
Enablers to be accessed, composed, customized and used by the chosen Use Cases (ICT for
environment, healthcare, transport, mobility, smart city, safety, etcetera). COIN adds a new layer
to the Core Platform Generic Enablers with its EI/EC utility services and knowledge, some of
them domain-independent (e.g. UBL data transformation services), some others domain-
dependent (e.g. Odette or MODA-ML data transformations). In this perspective, COIN can be
seen as an additional layer to the FI architecture centered upon the Core Platform.
A third key aspect of COIN System is the distinction between service engineering-development
platform and service delivery platforms. A service delivery platform is a catalyst for service
providers who already developed their own services and just want to give them visibility and
access to service consumers (i.e. providing utility services for easy registration, search,
discovery, orchestration, composition, execution, authorization-authentication-accounting,
monitoring); a service engineering platform is instead providing an Integrated Development
Environment for IT professionals (e.g. a Service Development Kit) and/or for nave providers
(e.g. a Mash-up environment) in order to facilitate the creation and development of new services.
Indeed, COIN was initially conceived with the notion of being a GSDP (Global Service Delivery
Platform) for EI/EC services and the notion of development platform was just marginally
addressed. In fact, the COIN view of Plug-Switch-Tap evolution is suitable for industrial end
users willing to access EI/EC services, as normal telephony users see the different contracts with


33
operators: in a plug mode you just need the right adapter in order to change operator; in a switch
mode you can close your contract with one operator and open a new one on-the-fly and in a
seamless way; in a tap mode several parallel contracts do exist and an intelligent decision support
system (fully automatic in some cases) is able to dynamically match and select the best offer
with users requests, also within the same day, the same hour or the same phone conversation.
More recently, the convergence between user-oriented development platforms and globally
accessible delivery environments (e.g. the so-called Application Stores) as well as the open
innovation, crowd-sourcing and co-creation societal trends has inspired in COIN a fourth
evolutionary step (named EI/EC Store) where the borders between development and delivery is
blurring. In this Store evolution, the need for model-driven architecture methodology and tools to
bridge the gap between CIM-PIM-PSM specifications is becoming more and more urgent again,
calling for a new revision of EI life cycle under this new Store dimension.
The key question of the COIN System is How to integrate the life of Enterprises with the
Internet of Services and simultaneously taking into account the three aspects of: i) The co-
existence of Cloud Computing SaaS and Open Services; ii) The architecture of the Future
Internet and its first implementations; iii) The Store model and the convergence between
development and delivery platforms?
In the COIN system architecture, the role of zip between the two clouds is played by our
Business Process Management facility of the Collaboration Platform. We in fact postulate that
business men design and develop their collaborative business processes across organizations and
across their information systems, this way encountering and facing collaboration and
interoperability gaps.
Business Interoperability challenge in COIN is intended neither horizontally (different
languages to express BPs at the same level of abstraction, e.g. xPDL or BPEL), nor vertically
(same notations/language at different levels of abstraction e.g. CIM-PIM-PSM), but across
organizations: how to synchronize internal Business Process across organizations, by avoiding in
the meantime interoperability gaps like deadlocks, interface mismatches and
synchronism/visibility problems derived from the juxtaposition of BP pieces, which are
individually correct but do not work well if put together in collaboration.
The COIN BPM facility is therefore facing:
i. The co-existence of Cloud Computing SaaS and Open Services. In the EI/EC domain,
there is the co-presence of de-jure open standards, de-facto industrial standards (mostly
not open) and a myriad of non-standard solutions which however are the most simple and
immediate solution to EI/EC problems. For instance, we have well defined de-jure
standards for Automotive, Fashion, Furniture Business Documents interoperability, as
well as de-facto standards given by software vendors like IBM or SAP or Oracle.
However, both resources solve just a minimal part of the EI/EC problems and in most of
the cases, the most simple and cheap method is to look for a similar case and adapt the
existing solution to the new requirements or to dynamically compose together micro-
services solving micro-gaps into an overall solution. The COIN BP facility shall have an
efficient and rigorous access to well coded standards as well as a more intuitive
constructionist approach in the absence of standards and in the presence of a myriad of
solutions available in the open Internet (e.g. support to the so-called federated approach
to interoperability).
ii. The architecture of the Future Internet and its first implementations. In the
preliminary FI Architecture, three main functions are deemed necessary to link core
services with applicative services: virtualization, self-management and orchestration. The
COIN BPM facility represents the orchestration function but with a much wider
perspective than just sequence of web services. One important aspect in COIN is the
possibility to hide from the business men all the technical details of the EI/EC
34
implementations by providing him/her a semi-automatic decision support for the
selection and implementation of the most suitable EI/EC services.
iii. The Store model and the convergence between development and delivery platforms.
In the EI/EC domain, it is very seldom that a given automatic service is best suitable for
many domains and processes: in most of the cases, a process of adaptation and
customization is necessary. In COIN we have automatic web services (to be invoked and
executed without any human intervention and control) and more interactive EI/EC
services which in most of the cases are development environment of customized and
specific EI/EC services (e.g. the semantic reconciliation suite for Business Documents
interoperability). The former ones are therefore available in delivery platforms and
juxtaposed into BPEL automatic service execution environments; the latter ones are
instead activated as intelligent wizards and drive the end-users towards the development
of the required service. In this sense, the Store paradigm is implemented in COIN.
For implementing our BPM facility, weve identified three possible evolutionary steps:
i. Step I, where EI/EC service demand/offer is not supposed to vary along time and also
among different instances of the same business process. In this case, the process of
selection-composition-juxtaposition of EI/EC services can be performed once at design
time and remains unchanged for long time. The human business user is therefore
prompted with the interactive COIN Front End interface where he/she could select the
most suitable service and then link it permanently with the business process in question;
ii. Step II, where EI/EC service requirements are supposed to vary along time for instance
among the different instances of the same business process. The process in this case is
semi-automatic, as the COIN system is invoked by means of automatic APIs, the
selection of the best combination of services is manual, while its juxtaposition into the
chosen instance of BP is again automatic.
iii. Step III, where EI/EC service requirements either change very dynamically or depend on
the execution time of the business process. In COIN, we have identified two distinct Step
III scenarios where human collaboration EC services are automatically selected on the
basis of the context (e.g. user, his/her location/presence, his/her device) in a projects
meeting life cycle domain; and where data interoperability EI services are automatically
composed on the basis of the organizations, their accepted data formats and data access
services.
The three steps are to be intended neither incompatible nor exclusive: for instance, in the same
BP we could have cases where Step I is more suitable, or Step II, or Step III.
2.3.2.3 The COIN Collaboration Platform implementation
The CPs, beyond supporting the collaboration environment for Supply Chains, Collaborative
Networks and Business Innovation Ecosystems, provide the industrial user (business man of
the companies clusters) with a set of functionalities based on the API of the COIN front end
communicating with the GSP federation (please refers to chapter two introduction for more
information). Using them, the Industrial user can access to the whole set of COIN system
functionalities and services to integrate its collaborative environment supporting the whole
product/service life cycle, integrating legacy systems and data and legacy services the COIN
services in a smart way. As mentioned above, there are three different integration scenarios
connecting the CP functionalities to the other components of the COIN System.
The CP Integration Step 1 (Figure 19) is the integration of COIN EI/EC services into some
business processes / workflows in the COIN Collaborative Platform. This means that the
Industrial User needs to insert by hand the end-points of the services in the lowest level of
his/her business process.


35
COIN Collaboration Platform
Knowledge Interaction Social Interaction
Business Interaction
Start
End
Service1 EI Service2 Service3 EC Service4
COIN Collaboration Platform Service Bus

Figure 19 - Industrial User - CP Integration Step 1

The CP Integration Step 2 [4] for the industrial User is the integration between COIN CP and
COIN EI/EC Platform through the API and interfaces of the COIN Front-End. All the
EI/EC Services are brought to the EI/EC Platform and subject to the basic USs of the platforms:
search, composition, negotiation, models distribution. In the BPs of the COIN CP, the Industrial
User (Business Manager) can inject some Service Requests to be managed by the EI/EC
Platform and transformed into service end-points (automatically or semi-automatically). In
implementation terms, there is a Business Process pre-processing (preparation for execution)
phase at modeling time where all the service requests will be sent and substituted with the
relevant service endpoints. If some of them are service generation environments they will be
executed again before the execution time of the BP.
COIN Collaboration Platform
Knowledge Interaction Social Interaction
Business Interaction
Start
End
Service1 Service3
SaaS Platforms
(legacy systems)
Enterprise
Applications
VAs
Service1 Service3
SaaS Platforms
(legacy systems)
Enterprise
Applications
VAs
SaaS Platforms
(legacy systems)
Enterprise
Applications
VAs
SaaS Platforms
(legacy systems)
Enterprise
Applications
VAs
COIN EI/EC Service
Platform
EIServiceRequest2 ECServiceRequest4
EI Service2
EC Service4
Enterprise
I/op / Collab.
VAs
GSP Utility
Services
COIN EI/EC Service
Platform
EIServiceRequest2 ECServiceRequest4
EI Service2
EC Service4
Enterprise
I/op / Collab.
VAs
GSP Utility
Services
COIN EI/EC Service
Platform
EIServiceRequest2 ECServiceRequest4
EI Service2
EC Service4
Enterprise
I/op / Collab.
VAs
GSP Utility
Services
EI Service2
EC Service4
Enterprise
I/op / Collab.
VAs
GSP Utility
Services
Service1
EI
Service2
Service3
EC
Service4
Service1
EI
Service2
Service3
EC
Service4

Figure 20 - Industrial User - CP Integration Step 2

The graphical User Interface used by the Industrial User to search for EI/EC services is an
adaptation of the Front-End interface accessed by the individual User and providing all the
functionalities of that interface like: search, invocation, ranking based on non-functional
properties, subscription, etc. Finally the user can download the endpoint of the found service in
its own business process.
36

Figure 21 - Injection in the business process of a discovered service

The CP Integration Step 3 [5] aims at injecting smartness in the discovery, link, and usage of
COIN services in the Industrial User business process. This integration process leveraging on
COIN Front-End APIs used to solve in a semi-automatic way a particular set of EI gaps that can
be generalized in the future to cover a wider spectrum of gaps. During the project two
evolutionary solutions have been experimented.
COIN Collaboration Platform
Knowledge Interaction Social Interaction
Business Interaction
Start
End
COIN EI/EC Service Platform
US EI Service2 US EI Service2
EI: Service3
after Service1?
EI: Service3
after Service1?
SaaS Platforms
(legacy systems)
Service1
Service3
Enterprise
Applications
VAs
SaaS Platforms
(legacy systems)
Service1
Service3
Enterprise
Applications
VAs
SaaS Platforms
(legacy systems)
Service1
Service3
Enterprise
Applications
VAs
Enterprise
I/op / Collab.
VAs (Tools)
GSP + EI/EC
U. Services
EI
Service2
EI
Service2
Service1
Service3
Service1
Service3

Figure 22 - Industrial User - CP Integration Step 3

In CP Integration Step 3 for EI aims to solve in a semi-automatic way a particular set of EI gaps
that can be generalized in future implementations to cover a wider spectrum of gaps. The basic
idea of integration step 3 EI is that some EI Services will be specified and requested to the EI/EC
Platform (namely the Value Added EI/EC Services, similarly to Step 2), while some other EI
Services are automatically identified and juxtaposed in the BPs. The two steps could be in
sequence (first EI/EC VAs discovery and then automatically insert the USs ones) but perhaps the
selection of the VAs could be dependent on the USs available, so a closer interaction could be
needed.
The implementation of the EI scenario has focused on the format transformation case in which
the Industrial User could have some format mismatches between electronic business documents
and need, in a smart and automatic way to find a solution. The process for the identification and


37
solving of gaps is available as flow diagram in Figure 23 and based on three cross lights. If the
process check ends without problems the green light is activated and the process could be
executed at runtime. Otherwise gaps identified are warnings or errors. In the first case the gap
could be solved manually changing the business process due to the fact that in the CP knowledge
base are available the formats to accomplish the cooperative work. In case of red light the
services are searched by the COIN Front-End API. If the transformation service is found it is
inserted in the business process that will be checked again before to be run. In the other case
(service not found) the same interface will automatically search for services able to create that
transformation. The generation of the service is manual while the registration of it in the GSP is
automatic; at the end of this process the service is searched again, then found and inserted in the
business process.

Figure 23 - GAP Identification - Flow diagram

The following picture describes the technical overview of EI Step 3; novel developments are on
top of the business process to connect the different items and the connection with the Front-End
API.

Figure 24 - COIN Step 2 Overview
38

1. In the workflow modeler has been created a button; clicking it the XPDL file is sent to the
CBPip web-service (COIN WP5.4) that identifies if there are gaps concerning electronic
business document formats to be exchanged by different actors together with the
permission to access the CP Knowledge base (KB) in which resides the registry of services
of the companies of the cluster. By this KB the service can identify if the mismatch could
be solved inside the cluster or if needs a new external service.
2. If there is an identified gap the user can click on the submission button and send the
request to the GSP federation to fill the gap (e.g: Input invoice in F1 or F2 and Output
invoice in F4 or F5).
3. The GSP federation will search for a direct transformation between formats; if there is a
transformation will be returned to the caller to be inserted in the business process. If not the
federation will search for a composition of services by usage of just PRE or POST
conditions match. If the transformation is found it is returned; null otherwise. The
management of the reasoning in the GSP is handled by the negotiation tool.
4. In the worst case (no direct or composed transformation available) the user is redirect to
search for a service able to create this transformation (e.g: SP5.2 data interoperability
services).

At the time a new web-service able to perform the needed transformation is created the data
interoperability service supports, in a semi-automatic way, its registration in the GSP. This
allows the further reuse of it, increasing the number of services available in the GSP federation.
Without inserting anything the system sends the right credentials to the GSP Federation and
shows the output to the user (Figure 25) that can select one service to be linked in the business
process to solve the gap.


Figure 25 - Transformation Found


Figure 26 - Available Transformations


Step 3 for EC [5] aims to solve in a semi-automatic way a particular set of EC challenge that can
be generalized in the future to cover a wider spectrum of challenges. The focus of the EI
implemented scenario is the message notification applied to a virtual meeting process (provided
by the MSMS service COIN WP 4.4). The system allows the user to dont lose time in notifying
other meeting participant but the system take in charge of it.
In Figure 27 is depicted the architecture of the Integration Step 3 for Enterprise Collaboration


39

Figure 27 - Process Overview

The execution process is composed by several steps:
The user access to a step willing to send messages to individuals (people). The step has
an ontological description that is sent to the Step 3 EC interface based on COIN Front End
API with other parameters:
a. virtualTeamID: containing the IDs of individuals targeted; it comes from the
COIN CP centralized database;
b. Ontological description: pre/post conditions of the needed service, e.g:
messageSent(message, individual, individual)
c. message: string identifying the message to be sent
The interface send the parameters to the expert system that, after a data gathering from
the Knowledge Base, evaluates rules, choose the right terms of the EC ontology, build a
goal and send it to the GSP federation
The GSP federation finds the service and execute it passing the message parameter coming from
the Step 3 EC interface. In tests the Collaboration services from WP4.1 have been used as targets



Figure 28 - automatic execution

40
2.3.3 Extended Products and Distributed Collaborative Innovation in Virtual Factories
The discussion of extended products and distributed collaborative innovation in Virtual Factories
raises a complex discussion. Basically it is necessary to briefly introduce the concept of extended
products, distributed and collaborative innovation processes in order to discuss their
implementation in Virtual Factories.
2.3.3.1 Extended products
The origin of the extended product concept can be clearly traced back to product-centric
engineering and their relation to service engineering in the nineties. Consequently the basis for
the development of the extended product concept was a discussion on product engineering,
innovation processes and virtual, extended enterprises which took place in parallel.
The discussion on product and service engineering that took place in the last centuries (Chao,
1993, Aurich et al 2006, Mont 2002, Bowen et al. 1989). Both time-to-market and service-
product offer leverage to gain sustained competitive advantage. A paradigm shift is taking
place from consumers buying products towards consumers buying solutions and benefits
(Thoben 2003).
Additionally there was an intensive debate on the virtual, extended enterprise concept
(Jagdev and Browne 1998, Thoben & Jagdev, 2001; Jagdev & Thoben, 2001).
Finally innovation processes in distributed setting were subject of many investigation such as
Chesborough (2003), Hippel 2005), Eschenbaecher et al, 2005).

These three developments have contributed to the extended product concept which has been
introduced in 2001 (Thoben et al, 2001). The extended product can be defined as follows:

An extended products itself describes the bundling of value added products and
services to a core product to fulfill customer needs over the whole product
lifecycle. As the term extended enterprise comprises more than just a single
enterprise, the term extended product should comprise more than just the core
or tangible product. Because of these characteristics, our view clearly focuses
on extending a formerly tangible product. For that reason, the intangible shells
and segments around the tangible product should be in the focus. Accordingly,
all services related to an extended product which are relevant for our
discussion do have a certain link to a tangible product.

The concept of extend products grounds on the shift of expectations from customers when
buying new products and services. Today, many customers are interested not only in products
but in a benefiting solution that often go beyond the mere physical core product. In this sense,
Extend Products aim at the provision of benefits and may intertwine many tangible and
intangible product compounds. As an example one could raise the issue of e-mobility: In the
context of e-mobility, the provision of "green mobility" as such would be the main benefit.
Customers do get the feeling to contribute to the environment preservation by reducing e.g. CO2
emissions. Figure 29 shows the development from products in a narrow sense, like physical
products and components systems, as the electric car itself (i.e. the Mitsubishi iMiev) towards
products with a broader perspective (e.g. car sharing service). One major shift is indicated by the
transfer from production of products and components such as cars for a sometimes known and
sometimes anonymous market towards mobility solutions.


41
Core Product Tangible Product Tangible and Intangible Product Assets
Shift of Business Focus
Provision of
Benefits
Manufacturing
of Parts
Offering of
Products /
Systems
Offering of
Solutions

Figure 29 - Moving to an Extended Product

2.3.3.2 Evolution towards distributed, collaborative innovation processes
The term collaborative innovation or distributed innovation (DIN) has been discussed intensively
over the last 10-15 years (OSullivan and Dooley, 2008 Kelly, 2006). Within the framework of
this concept, innovation is seen as a distributed process that involves the collective efforts and
the interaction of heterogeneous organizations. Each actor is specialized in specific activities,
technologies and knowledge and innovation is seen as the result of the combination and
integration of their competences. Coordination is therefore a key determinant for the viability of
distributed innovation stimulating complementary activities across otherwise dispersed
competences (Consoli et al., 2007). The following views on DINs illustrate a few varying
opinions:
Moller and Rajala (2007) define innovation networks as relatively loose science and
technology-based research networks involving universities, research institutions, and
research organizations of major corporations guided by the ethos of scientific discovery.
Nevertheless, innovation networks themselves are seen as relatively loosely tied
organizations (Freeman, 1991).
Rampersad and Quester (2009) point out that innovation networks are relatively loosely tied
groups of organizations that may comprise of members from government, university and
industry continuously collaborating to achieve common innovation goals.
OSullivan (2009) sees DINs as innovation processes that spread across an extended
organization. Distributed innovation is the successful implementation of creative ideas, tasks,
or procedures by employees in different geographic locations. The global availability of ICT-
systems, resources and competencies accelerates the increasing distribution of innovation
processes (Cummings, 2008).
There has been a long discussion about both representation and differentiation of innovation
processes. The following diagram (Eschenbcher, 2009) differentiates between internal
innovation management and in-between innovation management and therefore incorporates two
main concepts. These two general concepts can be divided into five general approaches on how
to deal with innovation processes. Basically, the model shows evolutionary steps towards greater
dynamics of innovation in value creating networks.
42

Figure 30 - Evolution towards distributed, collaborative innovation

The inventor: The very origin of innovation and the imagination is the inventor, who
represents the beautiful mind working in a cellar or garage on new inventions.
R&D department: The R&D (research & development) department is still a pre-dominating
imagination of intra-organisational innovation processes. Even today many companies run
R&D departments for the sake of innovating. Nevertheless the trend of open innovation leads
to a reduction of such traditional departments.
Cross-functional teams: Cross-functional teams are of major importance to successful, intra-
organisational innovation processes. In contrast to the traditional R&D department, here,
many different departments collaborate in a cross-functional manner to enable innovation.
This leads to both higher market orientation and increasing complexity of innovative
products and services.
Supply Chain innovation processes: The supply chain innovation processes deliver a good
example for inter-organisational and distributed innovation processes. The outside world is
integrated into the innovation processes, which leads to distributed innovation processes.
Nevertheless, the innovation process is coordinated from a supply chain hub which means
complete control by a large MNC (multi-national company).
Distributed innovation networks: Currently, only very few world class companies such as
Apple are really able to work in DINs. Here the main focus is the bundling of the best
resources available.

2.3.3.3 Extended products and collaborative distributed innovation in Virtual factories
After the introduction of extended products and collaborative distributed innovation it is
important to understand their role in virtual factories. We have in mind that any production
activity is caused by the needs of a potential customer. Precisely extended products can even
help to define or identify new customer needs. Servicing the customer means also to support the
customer in deriving new business ideas. The new business ideas can be considered as
distributed, collaborative innovation efforts of several companies as shown in Figure 31.
Consequently Virtual Factories of the Future have to extend their offerings in a dramatic way.
Customers may not be interested in buying products; they may very well be satisfied to obtain an
added value and for sure - an innovation. For this reason Virtual Factories of the Future have to


43
collaboratively offer total holistic solutions which might support the customer in achieving these
benefits.
Extension of products in terms of service-products will often constitute physical products as well
as the associated accessories or services. The combined package is supposed to make the
purchase of product attractive to the customer. Thus, depending on the type and core
competencies required to supply the associated services, there may be several business partners
collaborating very closely towards the common goal of making the sale of the package attractive.
This collaborative arrangement may very well operate in Virtual Factories Ecosystems.
We believe that it is necessary to create more than one representation of the service-products.
Here the Supplier bundles additional Accessories and Services around the core product to
develop an Service-Products to make the sale more attractive to the Customer, who is the end
user/consumer. If we take the picture with the shell we should ask who is providing the service-
products? It is not just the manufacturer or supplier of the core / tangible product. To provide
intangible assets of the product the concept of Virtual Factories Ecosystems comes in. These
Virtual Factories Ecosystems are replacing the former single enterprise and take over the lifetime
responsibilities for the product. The following shows a representation of this logic. Every
enterprise provides some part of the extended product.
Enterprise A
Enterprise C
Enterprise B
Enterprise D
Virtual factories to produce
Extended products:
-Preparation of extended products
-Integration of intra-organizational
processes to an inter-organizational
process chain
- Dynamic collaboration (reconfigurable
within one order)
- Duration: max. 1 order
- Allocation of Power: Hub-and-Spoke
(strong centralization of power)
- Web-based ICT-support
- Externally conceived as one enterprise

Figure 31 - Extended products and collaborative distributed innovation in Virtual factories

2.3.4 Conclusion and Future Work
The work reported in this paper has been carried out in the framework of the COIN project by
the implementation of the COIN Collaboration Platform and its usage by the COIN end-users.
The BPM facility has been deeply adopted by COIN partners allowing them to build up this
cross-organisational business processes leveraging on the availability of COIN services put at
their disposal. This process allowed the end users to actually measure the business enhancement
to their business processes. The work carried out, especially in respect with the so-called step2
and step 3 doesnt end in the scope of the project but it is just a starting point to be generalised
and possibly applied to other domains and circumstances. The COIN view of EC services as
utilities could therefore on the one side stimulate the concept of a common Core Platform in the
Future Internet embedding collaboration fundamental services, on the other side it could be the
basis for a new Enterprise Information System supporting open innovation in collaborative
enterprises and SMEs networks.
44

References
[1] COIN D3.5.1a COIN 1st Integrated Service Platform (CP)
[2] D3.5.2a COIN 1st Integrated System (CP2)
[3] D3.5.2b COIN Final Integrated System (CP3)
[4] D3.5.2b COIN Final Integrated System Annex IX (STEP2)
[5] D3.5.2b COIN Final Integrated System Annex X (STEP3EI)
[6] D3.5.2b COIN Final Integrated System Annex XI (STEP3EC)


45
3 COIN Enterprise Collaboration (EC) and Interoperability (EI) Services
The second main objective of COIN was to consolidate and stabilize the ICT results of both EC
and EI FP6 research into some Baseline Services (free or charged; open-source or proprietary)
which constitute the service foundations for COIN. It was not an easy task to put together in a
harmonized and coherent way, so diverse and heterogeneous results, but COIN main partners
have been the most active actors in their respective FP6 projects and could therefore be the boost
for that. So, COIN effectively built and implemented since the beginning of the project a solid
service-oriented Technology Platform for Enterprise (SMEs) Interoperability and Collaboration,
by putting together FP6 research results (chapter 3.1 and 3.2).
Those results have been then enriched by new innovative services developed in COIN (see
chapter 3.3 and 3.4) and in order to improve its usability and accessibility (mostly by SMEs) in
different business and knowledge contexts. The Innovative Services in the EC and EI fields, took
into account the most recent and promising technology challenges (in the field of Web 2.0,
semantic web, space computing) and put them at service of EC and EI purposes. In the field of
EC, we deem essential for SMEs some more configurable and flexible (not sector-specific)
services for collaborative product development, distributed and participative production
planning, co-opetitive multi-project management and finally some standardized services for user
interaction and co-operation. In the field of EI, we basically approached most of the Grand
Challenges identified in the EI Roadmap and we developed services for semantic, web-enabled
business documents interoperability; for Knowledge interoperability and for Business models
and policies harmonization and combination.

46
3.1 COIN research results for enterprise innovation - Enterprise Collaboration Baseline
Services
Patrick Sitek
1
, Michele Sesana
2
, Hong-Linh Truong
3

1 Bremer Institut fr Produktion und Logistik GmbH, Hochschulring 20, 28359 Bremen (Germany)
(sit@biba.uni-bremen.de)
2 TXT e-Solutions S.p.A, Via Frigia, 27, 20126 Milano (Italy)
(michele.sesana@txt.it)
3

Distributed Systems Group, Vienna University of Technology, Argentinierstrasse 8/184-1, 1040 Wien (Austria)
(truong@infosys.tuwien.ac.at)
Abstract
Enterprise Collaboration (EC) is a broad subject. Thus, a variety of different opinions can be formed mainly based on
the scientific discipline behind it. In the context of COIN IP project, Enterprise Collaborations are based on inter-
organisational relationships between network members, making the analysis and support of those relationships one of
our main objectives. To this end, in the first year of the project, we consolidated and harmonised results from
previous RTD projects concerned with Enterprise Collaborations to provide the Baseline Enterprise Collaboration
(EC) Services for the COIN project. In this chapter, we present our consolidating results in which EC Baselines
Services are introduced to support most dynamic enterprise collaborations, like Business Ecosystems, by
harmonising individuals and organisations profiles under the same model.

Keywords: Baseline Services, Enterprise Collaboration, COIN IP
3.1.1 Introduction
Inter-organisational relations are gaining unprecedented momentum for enterprises [9] and are a
widely discussed subject. Many researchers reviewed the topic of such enterprise collaborations
(EC). In collaboration, parties are more closely aligned in the sense of working together to
reach the desired outcome, rather than that outcome being achieved through individualistic
participation constrained by contextual factors such as those imposed by client-supplier
relationships and pre-defined roles, like in supply chains. An EC is an alliance constituted by a
variety of entities (e.g. organisations and people) that are largely autonomous, geographically
distributed, and heterogeneous in terms of their operating environment, culture, social capital and
goals, but that collaborate to better achieve common or compatible goals, and whose interactions
are supported by computer networks [2]. In todays society, enterprise collaborations manifest in
a large variety of forms, including virtual organisations, virtual enterprises, professional
associations, industry clusters, professional virtual communities, collaborative virtual
laboratories, etc.
EC has been a major catalyst in the 6th Framework Program of the European Commission. It led
to several projects aiming at finding new paradigms for enterprises aggregation, synchronisation
and cooperation in response to the more and more demanding and complex business
opportunities coming from customers. The research done so far focuses on three different
collaborative network contexts, from the most static to the most dynamic one:
o Supply Chains, where long term relations and stable organisational and
economic structures among enterprises allow the adoption of the most optimised
and important IT solutions;
o Collaborative Networks, where the SMEs long term aggregations (i.e. clusters,
districts and breeding environments of ECOLEAD IP) are finalised to get the
members prepared to create and sustain more short term and dynamic alliances
based on specific business opportunities (i.e. virtual enterprises, virtual teams);


47
o Business Ecosystems, where SMEs are left free to evolve as they like, just
following the market evolutionary law that it is the fittest species which survive
(i.e. open networks, de-focused networks) and the ecosystem just supports and
encourages this emergent and evolutionary approach by providing SMEs with
several services (e.g. legal, organisational, ICT).

Significant results in the field of IT infrastructure and IT support to EC management have been
achieved so far. But evidently they could not address properly the problem of EAI (Enterprise
Applications Integration) and operational support to collaborative processes in the different
industries and application domains.
3.1.2 Related Work
Recently, many projects have developed various collaborative systems which could be classified
into systems for virtual teams, such as the inContext system (http://www.in-context.eu) or for
virtual enterprises, such as ECOLEAD (http://www.ecolead.vtt.fi) or E4 (http://e4.cognovis.de/).
The first type of systems is generic enough to be used in team collaboration of cross-enterprises
but they are not integrated into real business context of enterprises in collaborative networks. The
latter typically includes separate tools for different purposes in different life-cycle-phases of
virtual enterprises (following [8], [1], [3], [6]):

1. EC Preparation (Sourcing of partners)
2. EC Formation and Setting up (Legal issues, contracts)
3. EC Operation (Day-to-day management)
4. EC Dissolution and Decomposition

While collaborative services are increasingly used for EC, a platform including well-integrated
collaborative services which cover different aspects is missing, forcing the user to utilize
different tools in separate ways. A detailed analysis of existing EC tools, in particular from the
EU IST 6th Framework Program, has been performed. Table 1 summarises some major tools (a
detailed survey can be found in [7]).

Table 1 - Existing EC tools and systems
Category Software Number
of Tools
Tool Name
Web
application
Tomcat 10 Virtual Breeding Environment Management
(VMBS), Professional Virtual Community (PVC)
Management and Governance, PVC Rewarding
Tool, Requirement Identification Service
(refQuest), E4 (Extended Enterprise Management
in Enlarged Europe) Platform, Supported
Indicator Definition (SID), Collaboration
Opportunity Characterization (COC) Plan,
Virtual Organization (VO) Model Repository,
Partner Selection (PS), VO Formation
Apache
Web server
2 Collaboration Opportunity (CO) Finder,
Customer Support Service (DISCO)
Microsoft
IIS
4 PVC Management and Governance, Planned,
Mediated, and Ad-hoc Collaborations
48
Web service Axis 2 Communication Service Set, Activity
Management
Database MySQL 9 PVC Management and Governance, PVC
Rewarding Tool, Planned, Mediated, and Ad-hoc
Collaborations, Communication Service Set,
Activity Management, refQuest, DISCO
PostgreSQL 5 VBMS, E4 Platform, CO Finder, COC-Plan, VO
Formation
Programming
Language
Java 10 VBMS, PVC Rewarding Tool, Communication
Service Set, Activity Management, refQuest,
SID, COC-Plan, VO Model Repository, PS, VO
Formation
C# 5 PVC Management and Governance, Planned,
Mediated, and Ad-hoc Collaborations, E4
Platform
PHP 2 CO Finder, DISCO

Most of the tools are specific for EC but some are generic, such as the Communication service
set and the Activity Management service. Most of the shown tools did not follow the SOA
paradigm but Web application, and they are designed to work in an isolated manner with a focus
on the end user, not the service integrator. Thus, while useful for Enterprise Collaboration, most
of the tools are designed for isolated use, diverse types of data are not integrated and it is difficult
to compose different tools and services for newly-emerging collaboration needs. Moreover, the
tools focus separately on Virtual Organisations and Professional Virtual Communities, while the
business concept presented in this paper concentrates on dynamic enterprise collaborations
between organisations and individuals in business ecosystems.
3.1.3 EC Baseline Reference Model
The formal duration of EC describes the contractually fixed duration of that collaboration. It can
be classified as unique if the intention is to realize just one product/offering based on a specific
customer request. The collaboration can be classified as limited if the intention is to realize a
fixed series of complex products. To support ability of collaboration and rapid formation of
collaborative networks, the researchers came to the conclusion that it is necessary to have
potential partners ready and prepared to participate in such collaboration [5]. Therefore
enterprise collaborations can be differentiated in different life-cycle phases. This preliminary
study on life-cycle phases and on existing EC tools and systems led to the identification of the
EC Baseline Reference Model. The different phase of the life-cycle does require various baseline
services. Therefore they were the best candidates to be part of the EC Baseline Reference Model.
The following picture shows the EC Baseline Reference Model along the EC life-cycle. A set of
EC Services has been designed as an IT solution and implemented according to the EC Baseline
Reference Model.


49

Figure 32 - EC Baseline Reference Model

During the Preparation Phase of EC interested parties register and are able to define their
profiles, e.g. editing administrative, contribution (product/ service), processes and performance
data. The innovation lies in the combination in the management of originations and also
individual profiles. This combination supports the management of highly dynamic collaborative
networks like Business Ecosystems. Life-cycle independent communication web services are
implemented to be used to announce news (like new members) and support communication
between network members. The further innovative EC Baseline Service provides the possibility
to either create a Business Opportunity (product/ service) from inside (based on the network
competencies) or optional discovering Business Opportunity by market research. For the creation
option a new serious game has been implemented that supports the creative ideation process
between networks members. One member opens a creative session to seek for Business
Opportunities and is able to sent invitation to other members by the Communication Service.

Once the Business Opportunity has been identified the Formation Phase starts and with the
Business Opportunity Characterisation Service it is possible to define the Work-Break-Down-
Structure (WBS), the tasks to be performed and the special competencies needed. Active
members can be rewarded for their activities in seeking for Business Opportunities. Right
partners for the characterised Business Opportunity are to find with the EC Partner Search
Service following chosen search criteria. While finding the right partners the support of
communication, discussion and agreements between members is also provided by the
communication service. The selected partners for the specific Business Opportunities are to
register and collaboration performance indicators are to be set for the Operational Phase.

Enterprise Collaboration Service and Product Management Services (PSM) support the
Operational Phase of the collaborative network where the added value for the customer is to be
realised. The PSM Service provides a structured storage in catalogues of all relevant product
information and documentation to be realised. Complex products can be stored in different
configurations. Following the (WBS), planned and mediated tasks can be defined for each
50
network partner. Ad-hoc task force teams can be set up in critical collaboration situations. The
execution of the defined tasks is supported by an activity service, which links acting people with
used resources, and tracks the state of each task. Exchange of product data and progress
information related to the tasks are supported by the communication service again. Good
collaboration performance can be rewarded and has a positive impact on the members profile.

Finally during the Dissolution Phase it is possible to gather feedback from all active partners and
the end customer and store the collaboration experience gained for a reuse in future Business
Opportunities. Finally the end customer receives access to the product catalogue and product
information.

3.1.4 Conceptual architecture
Based on the analysis of existing tools in the field of Enterprise Collaboration, a conceptual
architecture for a Baseline IT-Platform has been designed that follows the SOA model. The
following picture shows the architecture that includes data, service and tool layers which aims at
integrating and harmonising existing EC tools and services.

Figure 33 - Conceptual architecture of the COIN Baseline EC software services and tools

Data, services, and tools for EC that was previously created in an integrated way including strong
relationship between presentation, business logic and data access layers are decoupled in these


51
three layers and integrated through SOA principles and technologies. Through the integration, a
core set of services and tools has been realized available for use; services previously integrated
and used by one tool now can be reused by other services or composed to support more complex
scenarios. The central point of the EC Baseline IT services is the centralized model implemented
as a database; data layer provides necessary data for any activities performed in the four phases
of the EC lifecycle and the Business Opportunity to be achieved.

In the next picture the process of decoupling is shown from a software built to be used alone (on
the left) where the three levels are integrated in the same environment to a software where layers
are completely separated; the business logic is provided as web service and data is gathered by
usage of a centralized model.

Figure 34 - Example of decoupling of an existing software

During the decoupling the attention focused on the harmonisation of concept that previously
have been taken completely separated: the organisation world (organisation, Virtual
Organisation, cluster, etc) and the individual world (individual and virtual teams). The result is a
model more than 60 entities implemented in 80 database tables allowing tools to share data in an
easy way. In order to allow user to experience the whole EC Baseline services and tools has been
provided a single point of access to the entire system: user should access to a portal based on
Liferay by a single sign on mechanism based on Central Autenthication Service (CAS). On the
website are displayed circles representing baseline services available for the user role; by
clicking on that the user can access to the desired tool.
52

Figure 35 - Baseline IT Services Portal

The extension of the baseline IT service by inclusion of other services is easy because on the
access of the common model allows new services to interact with data provided by existing
services without knowledge about their internal processes.

3.1.5 Conclusion and key benefits
Organisations need IT solutions that are able to support dynamic enterprise collaboration
involving many organisations, individuals, resources and software services. First, due to the
dynamics of collaboration and rapid formation of collaborative networks, these networks require
different services for different collaboration phases [2]. By combining the management of
organisations and individuals and their virtual forms, this approach supports the formation of
highly dynamic collaborations including business ecosystems because rich sources of common
data, such as profiles, product/service, processes and performance data, is linked and available in
a common data-as-a-service. Converged collaboration services are provided by composing
different services, i.e., communication services with other services to support realtime
information dissemination among collaborators. Furthermore, a business opportunity
(product/service) can be created from inside (based on the network competencies) or discovered
through third party services. Third, business opportunities and collaborations are manageable
through activities associated with individuals, teams, and their competencies and processes, and
relevant product information and documents. Finally, through the portal, feedback can be
collected and evaluated in a coherent way from individuals, organizations, customers and also
from many software services to evaluate the success of collaborations. Such evaluations are
valuable for determining trust and plans in future business opportunities.

The portal enables the composition of commodity EC services: many existing EC services are
common because we can use them for different purposes. With such a portal, new EC services
can be created through the composition of common EC services. The portal enables the
acquisition of rich data sources for understanding collaboration interactions and performance
evaluation. Without such a portal, it is very difficult, to obtain different kinds of data
characterising interactions for analysis. With the portal, profiles, activities, operations, contexts,


53
etc., can be logged and retrieved through a Web services-based platform, supporting many
research activities, such as trust analysis and collaboration adaptation, which rely on realistic data
for experiments.

Acknowledgment
This work has been partly funded by the European Commission through ICT Project COIN:
Collaboration and Interoperability for networked enterprises (No. ICT-2008-216256). The
authors wish to acknowledge the Commission for their support. We also wish to acknowledge
our gratitude and appreciation to all the COIN project partners for their contribution during the
development of various ideas and concepts presented in this paper. An early version of this paper
appeared in the International Conference on Concurrent Engineering - ICE 2009 conference.

References
[1] Camarinha-Matos, L.M. and Afsamarnesh, H. (2005) Collaborative networks: A new scientific discipline,
in Journal of Intelligent Manufacturing, Vol.16, No.4-5, pp.439-452
[2] Camarinha-Matos, L.M. and Afsamarnesh, H. (2006) Collaborative networks Value Creation in a
knowledge Society, in Proceedings of Prolamat 2006, Shanghai, China
[3] Eschenbcher, J., Graser, F. and Hahn, A. (2005) Governing Smart Business Networks by Means of
Distributed Innovation Management, in: Smart Business Networks, Springer Verlag, Berlin Heidelberg
New York, S. 307-323
[4] Eschenbaecher, J. (2008) Gestaltung von Innovationsprozessen in Virtuellen Organisation durch
Kooperationsbasierte Netzwerkanalyse Dissertation an der Universitt Bremen (to be published)
[5] Romero, D. and Molina, A. (2010) Virtual organisation breeding environments toolkit: Reference model,
management framework and instantiation methodology, in Production Planning & Control, 21: 2, pp. 181-
217
[6] Seifert, M. (2007) Untersttzung der Konsortialbildung in Virtuellen Organisationen durch perspektives
Performance Measurement, Dissertation an der Universitt Bremen
[7] Sitek, P., Eschenbaecher, J., Sesana M., Truong, H.L., Aguilera, C. (2008) D4.1.1 State of the art and
baseline EC services specification. COIN Consortium
[8] Thoben, K.-D. and Jagdev, H. S. (2001) Typological Issues in Enterprise Net-works, in Journal of
Production Planning and Control, Vol.12, No.5, pp.421-436
[9] Zhao, F. (2000) Quality and Collaborative Quality Management in Cooperative Research Centres, in
Conference Proceedings of 4th International & 7th National Research Conference, Sydney
54
3.2 COIN Innovative Enterprise Collaboration Services
Kim Jansson
1
, Michele Sesana
2
, Florian Skopik
3
, Alberto Olmo
4

1 VTT, Technical Research Centre of Finland, kim.jansson@vtt.fi
2 TXTe-solutions S.p.A., Italy, michele.sesana@txtgroup.com
3

Distributed Systems Group, Vienna University of Technology, Austria, skopik@infosys.tuwien.ac.at
4 ISOIN, Ingenieria y Soluciones Informaticas, Spain, aolmo@isoin.es
Abstract
The COIN project has developed services for Enterprise Collaboration. Based on the analysis of industrial needs and
market available enterprise collaboration tools COIN has identified missing services on the market. A special focus
has been put on identifying the needs of SME networks. COIN has specified, developed and delivered services in the
following domains: Collaborative Product Development, Collaborative Production Planning, Collaborative Project
Management and Collaborative Human Interaction. This chapter provides an overview of the methodology and
workplan used together with an overview of the developed services. For each individual service the main innovations
and progress beyond state-of-the-art are presented.

Keywords: Enterprise Collaboration, Enterprise Interoperability, Innovative Services, Product Development, Project
Management, Production Planning, Human interaction
3.2.1 Introduction
Today Internet technology has made it possible to establish different types of Collaborative
Networked Organisations (CNO). The costs of using modern Internet technology is no longer an
obstacle for a large scale take up of collaboration services. The COIN Project develops services
for European SMEs enterprise aggregation, synchronization and co-operation in response to the
demanding and complex business opportunities coming from the global market [COIN]. In
particular the COIN project develops services for Enterprise Collaboration (EC) and Enterprise
Interoperability (EI).
Based on analysis of industrial needs and identification of missing services on the market, COIN
has further specified, developed and delivered services in the following domains.
Collaborative Product Development (c-PD)
Collaborative Production Planning (c-PP)
Collaborative Project Management (c-PM)
Collaborative Human Interaction (c-HI)

In the COIN context the developed services to support the above mentioned domains are called
Innovative Enterprise Collaboration Services.
This article first describe, in section 2, the methodology and workplan used in COIN to identify
needed services. Section 3 will briefly go into the background and previous research on the EC
topic. Section 4 gives an overview of the functionality in the COIN innovative EC services.
More detail can be found in the corresponding COIN Deliverables listed in the References
section. The most important part of this article is the section 5, which presents the main
innovations in the services and the innovative ways of using the services.
3.2.2 Methodology and Workplan
The COIN project has used a research approach that relies on previous research projects and
market available solutions. The development of COIN EC services has been guided by the
following principles:
Build on state-of-the-art knowledge and previous results from research and development.


55
Be continuously open for adopting new emerging and breakthrough technologies and de-
facto standards.
Take advantage of existing work and avoid inventing the wheel again.
Favour open source and free of charge solutions.

COIN has used a user-centric (and SME-oriented) approach in the development work. The
industrial partners networks have a crucial role in ongoing interaction with the research and
development parties.
A two-cycle spiral approach has been followed. Each of the two cycles has delivered
independent prototypes for EC services followed by integrated versions. The main industrial
evaluation and feedback was scheduled between the iteration cycles. However the on-going
interaction, between developers and the industrial partners, throughout the project has
encouraged the development of innovative service features also within the iteration cycles.
The following Figure 36 illustrates the overall development strategy, where the second
development cycle in the approach is followed by an industrial take-up and demonstration phase.


Figure 36 - COIN overall development strategy

3.2.3 Background and Previous Research
In the European CNO research cluster VOSTER, two main concepts for inter-enterprise
collaboration were identified according to the objective and duration of the collaboration [12]:
Network / breeding environment which is a more stable, though not static, group of
organisations which have developed a preparedness to co-operate.
Virtual organisation (VO) / virtual enterprise which is a temporary consortium of partners
from different organisations established to fulfil a value-adding task, for example a product
or service to a customer.
The ECOLEAD-project has enhanced previous frameworks for understanding the relationships
between entities in a CNO [12]. Software tools developed in e.g. the ECOLEAD as well as other
projects have been aggregated into COIN forming the Enterprise Collaboration Baseline
Services, explained in the previous article of this book. They support the collaboration life cycle
for both long-term, mission-driven and short-term, opportunity-driven collaboration [3].
56
3.2.4 Results - Overview of Developed Services
As stated in the introduction section COIN has developed innovative services for c-PD, c-PP, c-
PM and c-HI Services. The first three groups of services directly support the corresponding
operational functions; product development, production planning and project management, in a
CNO, while the fourth group of services are more general and not specifically dedicated to a
function in the CNO. The c-HI services encompass services for human collaboration and data
sharing and can be utilized as supporting services, for example in the c-PD, c-PP and c-PM.
Figure 37 gives an overview of the functionality in the COIN innovative EC services. The
individual services are explained in some more detail in the following section.
Production Planning
Production Planning Portal & Service
Quality Management
Supply Chain Information& Text enrichment
Project Management
Project Alignment
Social Gantt building
Project Meeting Process Management
Human Interaction Support
Collaboration Visualization
Trusted Information Sharing
Trusted Online Help & Support
Product Development
Semantic Cluster Management
Automatic Ontology Building
3D Viewing & Annotation

Figure 37 - Overview of developed services

3.2.4.1 Services for Product Development (c-PD)
Product development is a very wide process, covering different activities from the original ideas
and requirements collection to partner search for production, first prototype building, architecture
and design, product manufacturing, testing, deployment and maintenance. Collaborative Product
Development is the application of team-collaboration practices to an organizations total product
development efforts. It is concerned with creating the necessary environments for effective, free
flowing information and ad-hoc collaboration among peers involved in these mostly external
knowledge worker partnerships [13]. Often used tools include computer-aided design (CAD),
computer-aided engineering (CAE), computer-aided manufacturing (CAM), enterprise resource
planning (ERP) and product data management (PDM) systems, that can be integrated to support
intra- and inter-enterprise collaboration. The following innovative services have been developed:
Semantic Cluster Management Services (SCMS).
Automatic and Intelligent Construction and Instantiation services (AICIS).
Collaborative 3D Designer Service (C3DDS).
3.2.4.2 Services for Planning Support (c-PP)
Production Planning is a large concept and could be defined as the function for the efficient
planning, scheduling, and coordination of all production activities. In this function a huge
number of variables are involved: resources, planning horizon, costs, capacity constraints, bill of
materials, warehouse availability, quantity, delivery dates, etc. The configuration of production
planning system requires the set-up of a large set of parameters comprising the input data related
to the company structure, the environment on which production takes place, and the


57
configuration algorithms for the master production scheduling creation. For those reasons, these
services have been created in complex professional systems for enterprises. The information
flow and the collaboration among actors of the value chain to coordinate their work are also
included in the definition of production planning. The following innovative services have been
developed:
PnP Collaborative Production Planning Portal (C3P).
SaaS Production Planning Service (PPS).
Collaborative Quality Management Service (cQMS).
Supply Chain Intelligence Service (SCIS).
Service-oriented Text Enrichment Services (SOTES).
3.2.4.3 Services for Project Management (c-PM)
Project Management (PM) is the discipline of planning, organizing, and managing resources to
obtain the successful completion of specific project goals and objectives, while adhering to
classic project constraints; scope, quality, time and budget. Collaborative Management of
projects involves, shared and delegated project management responsibility, often self-organized
and trusted approaches, non-hierarchical and participative management organization.
The discipline of project management is well established and an application area well supported
by software solutions. However development within Internet technology, social media,
participative co-creation, and Web 2.0 applications also enables new working methods on the
PM area. Based on industrial requirements and from analysing the current state of the art and
research progress in the area of CNO, PM and Web2.0, COIN has recognized a real need for
development in the area of Collaborative Project Management (c-PM).
The developed c-PM innovative services are grouped into the following three tools with the
objective to support social and collaborative internet based project management
1. Project Alignment Booster (PAB).
2. Collaborative Project Meeting Process Management (PMPM).
3. Collaboration for Project Management (Coll4PM).
3.2.4.4 Services for Human Interaction Support (c-HI)
Web-based collaborations and cross-organizational processes typically require dynamic and
context-based interactions between people and services. Product development, production
planning and project management are supported by services and tools developed by partners as
well as market available complex professional system. However, there is currently only little
support and a lack of solutions to tackle problems arising from dynamic aspects of execution,
e.g. how to handle exceptions and deviations from the planned progress. These situations often
require a human intervention. Thus, there is a need to monitor on-going collaborations,
characterized by human interactions in the operational phase of a virtual organization to retrieve
a holistic view about the performance of a collaboration scenario.
The developed c-Hi concepts and tools support dynamic human interactions in cross-
organizational environments. People use these services to interact in a context-aware manner.
Interactions are monitored by using logging services. On top of logged interactions, trust
relations can automatically be inferred using a rule-based interpretation of interaction metrics.
Using these concepts the following c-Hi services are provided:
1. Collaboration Visualization Tool (CVT).
2. Trusted Information Sharing Service (TIS).
58
3. Trusted Online Help and Support (TOHS).
3.2.5 Innovations
The previous chapter contained on overview of the developed EC services. This chapter will
present the main innovations in the services and the innovative ways of using the services.
3.2.5.1 Progress beyond State-of-the-Art in Semantic Cluster Management Services (SCMS)
Heterogeneous tools and multiple designers are frequently involved in collaborative product
development, and designers often use their own terms and definitions to represent a product
design. Thus, to efficiently share product information, a designers intentions should be
persistently captured and the semantics of the designers terms and intents should be interpreted
in a consistent manner. For this purpose, a standardized data format is a prerequisite.
The objectives of the Semantic Cluster Management are to support engineering knowledge
management to enable the search of right partners for product development, with the needed sub-
products or services, and with the needed competences. The Semantic Web supports integrated
and uniform access to information sources and services as well as to intelligent applications by
the explicit representation of the semantics buried in an ontology. The SCMS extends the
collaborative product development ontologies to the companies that form a CNO (be it supply
chains, collaborative network or business ecosystems), to improve collaborative product
development through a formalised description of companies, competences, services, products
and documentation. The main innovation of this ontology is its interest for diverse end users that
can model their knowledge domain with a more generic tool than those currently available.
Figure 38 shows an example.

Figure 38 - Healthcare sector ontology draft

This service is complemented with Automatic and Intelligent Construction and Instantiation
Services (AICIS), which is explained in the next section.
3.2.5.2 Progress beyond State-of-the-Art in Automatic and Intelligent Construction and
Instantiation Services (AICIS)
The SCMS has been complemented with automatic and intelligent semantic web services that
deals with 1) automatic building of the ontology, based on relational databases used in the cluster


59
or on unstructured data and 2) automatic instantiation of the ontology, based on cluster
documents. The service aims at providing intelligent searching and browsing through crawled
data about cluster companies. The main part of developed services has been integrated in the free
accessible ontology management environment OntoGen [2].
The innovation in COIN is to implement OntoGen services to function automatically i.e., to
build up ontologies automatically from a given set of documents. A part of the ontogeny services
has been redeveloped to offer the option of unsupervised ontology learning. Unsupervised
learning is based on clustering methods from text-mining where the clusters of instances from
selected concept are treated as sub-concept suggestions.
3.2.5.3 Progress beyond State-of-the-Art in Collaborative 3D Designer Service (C3DDS)
3D collaborative product development is essential in current industrial processes. Proprietary file
formats have traditionally locked 3D CAD users into one vendor. The technology of Web
services opens new opportunities for CAD applications, enabling viewing and sharing 2D and
3D designs, without the need to download or install any software, allowing the collaboration of
any user with the only requisite of accessing the Web. With the C3DDS prototype, the following
objectives have been addressed:
Online viewing of 3D files, including a wide variety of formats and de-facto standards.
Web service architecture, avoiding the need to install software.
Online annotations, to enable virtual meetings to comment 3D designs.
History of annotations and authoring of annotations.
Adaptation of C3DDS to different types of CNOs (collaborative networks, supply chains,
business ecosystems) has been the object of development.
3.2.5.4 Progress beyond State-of-the-Art in Collaborative Production Planning Portal (C3P)
Production Planning systems give to the user a great amount of functionalities concerning
product managements, company resources management, scheduling algorithms, warnings and
errors can be defined and evaluated through a graphical user interface (GUI) , and so on, as
shown in figure 39. Employees of the same company can easily work together on company data
and solve internal problems. What is missing in these systems is the collaboration among
different organizations of the supply-chain; this is due to several factors:
Different production planning systems do not give mutual access to company data.
Production agreements between partners (orders) are exchanged in different structures and
usually exchanged by archaic methods (FTP, email).
Collaboration on data is performed only through old communication channels (telephone,
emails, face-to-face meetings, etc.).
There are few data available to actors to solve exceptions and warnings and partners do not
have information about other partners internal processes.
Unavailability of production planning systems for some partners (mainly SMEs).

60

Figure 39 - Collaborative Production Planning

These factors cause an enormous loss of time, that means money, in order to make systems
connected (data exchange, format harmonization, manual data insertion from one system to
another), to solve misunderstandings, exceptions and warnings. SMEs without an interconnected
IT infrastructure (or without any production planning) experience these problems more than big
industries, and their risk is to stay outside the market.
The innovations in C3P include:
The implementation of a Collaborative Production Process composed by internal actors
processes by which different companies can share their production planning to collaborate
with other parties of the chain: collaboration is put on top of arrows connecting different
private blocks of different companies and managed by virtual rooms.
Possibility to have shared changes at public (inter-organisations) or private level (intra-
organisation).
Implementation of a collaborative bill of material.
Agent negotiation implemented through the adoption of the COIN agent negotiation services
generated at the end the agreed order in the UBL standard format.
Possibility, through the collaborative production planning process to start different
negotiations at the same time with different competitors and select the best one.
Native support for the communication among individuals through the inclusion of the virtual
team concept on top of virtual rooms and the integration of human communication services.
3.2.5.5 Progress beyond State-of-the-Art in Production Planning Service (PPS)
Production planning is usually a module of Enterprise Resource Planning (ERP) solution, both
open source and commercial, that are widely adopted and used since decades by enterprises.
ERP systems are widely adopted by medium/big enterprises but not by SMEs that cannot afford
the costs and the complexity of the software. The innovation of PPS is to provide a simple
Production Planning system as a Software as a Service (SaaS) service able to provide common
functionalities such:
Data Import service.
Execution of algorithms to calculate the feasibility of the production and needed time/price.
Data output service.
Warning and Exception service.


61
The availability of this service by web interfaces leverages SMEs from any cost related to the
required technical infrastructure and can be easily adopted by them. The service is natively
integrated in C3P.
3.2.5.6 Progress beyond State-of-the-Art in Collaborative Quality Management Service
(cQMS)
Inter-organisational relations result in inter-organisational interdependencies which make new
demands on managing quality in enterprise networks. Managing interdependencies in enterprise
networks, means to understand that the work, changes in processes and output of any single
network member might have consequences for the work, processes and outputs of other
members in the network. These consequences, if not identified in sufficient time, might result in
not reaching the initial customer requirements and failing in quality of the network product.
cQMS suggest an innovative approach to analyse interdependencies between enterprise network
members by analysing their competence profiles [4]. By combining the information entities
product/service, business processes and technologies a representation of the competence as
definition is given. Each actors unique combination of products, resources and activities
constitutes its identity as competence. The competence defines the actors specific need for
information to be exchanged.
In cQMS a similarity algorithm approach is used to compare the partners competence
descriptions. Through cQMS network members make use of a word comparison algorithm,
which determines the similarity of two word sequences using the dice coefficient and reveals, in
this way, potential interdependencies. With the introduced cQMS members of CNO receive a
comprehensive approach that enables them to investigate inter-organisational interdependencies
based on their competence profile descriptions stored in the C3P [5].
3.2.5.7 Progress beyond State-of-the-Art in Service Oriented Text Enrichment Services
(SOTES)
Service oriented Text Enrichment Services (SOTES) have been developed because they present
the basic infrastructure for many planned and future semantically enriched services. With
SOTES the content is being enriched with the large contextual information that then provides far
better results in semantic services ranging from machine learning algorithms, data, text and Web
mining, social software, network modelling tools to semantics and reasoning. Content is being
enriched through many different types of information ranging from domain specific, common
sense knowledge, technical, multilingual, etc. SOTES presents a unique approach that gathers
together many technology innovations in a software stack for automatic content enrichment.
3.2.5.8 Progress beyond State-of-the-Art in Supply Chain Intelligence Services (SCIS)
Traditional logistics and corresponding Supply Chain Management (SCM) systems rarely use
algorithms from the area of artificial intelligence (AI). This is why they are using very
deterministic approaches that can just partly take into consideration the complexity of a logistic
system. The functionalities that are usually covered are; planning, monitoring and offline re-
planning in the case of problems.
There are two main innovative features in SCIS:
Implementation of new features for prediction, trend detection and anomaly detection.
Services are based on various methods that have been developed to handle vast amounts of
data in real-time.
Integration of top-down (knowledge driven) methods and bottom-up (data driven methods)
for the SCIS. Here the main innovative features comprise among others knowledge
formalization of SCIS domain, justifying methods with reverse reasoning, and integration
62
with a knowledge base and formalized representation of a vast quantity of fundamental
human knowledge: [14].
3.2.5.9 Progress beyond State-of-the-Art in Project Alignment
Collaborative project management requires that the participating organizations and people share
a common commitment and understanding of project objectives, requirements and practices, and
that the partners have sufficient competencies and skills for the project tasks.
PM software is a term commonly used to cover software targeted to aid the project managers in
managing their projects. This type of software usually cover functions for scheduling, budgeting,
forecasting, resource allocation, progress monitoring, quality management, communication and
documentation.
The developed methodology and the Project Alignment Booster services include the following
innovations and new development:
The project alignment process.
Collaborative and participative definition of unified and shared project work processes.
A self-evaluation methodology to announce partners capability and engineering
competence.
Possibility to analyse gaps between project demanded skills and capabilities offered by the
project partners. Based on the analysis, the collaborative project management can identify the
need for additional capabilities and competencies. The monitoring of deviations assists in
detecting project risks and possible timing problems.
The Project Alignment Model (PAM) is a configurable framework that describes for
alignment tasks and elements different levels how they can be carried out. The PAM is
configurable and more flexible than existing Maturity Models as CMMI.
Inclusion of organisational culture elements into the PAM.
3.2.5.10 Progress beyond State-of-the-Art in Collaborative Projects Meeting Process
Management (PMPM)
The development of the PMPM is based on the vision that global collaboration project
organizations need distributed meetings. Distribute meeting should be conducted more
efficiently than a traditional local meeting, through new processes and IT tools. The main
concept of the developed services is to support the management of the whole long meeting
processes. The process extends from the planning of the meeting all the way to finalization of the
meeting, e.g., from agenda planning to distribution of meeting minutes. The individual steps in
the meeting process will invoke existing tools and services, preferably opens source based
services. An example is illustrated in Figure 40.

Figure 40 - Example of meeting process and steps

The development contains the following innovations:
Support of the management of asynchronous and long meeting process involving steps e.g.
participative definition of agenda, call for participation, scheduling, standard agenda,


63
contribution asynchronously in advance, reminding of meeting, online meeting, follow up.
The innovation is in the management of the whole meeting process.
Establishment of application domain specific process libraries for typical project meetings,
for example complex engineering projects.
Integration with the COIN GSP to find most suitable meetings services. The best suited tool
to be used in each step is based on the partners on-line status, role in project, importance
etc. The tools used in the various steps can be defined on forehand or dynamically selected
during the process execution.
3.2.5.11 Progress beyond State-of-the-Art in Collaboration for Project Management
(Coll4Pm)
The Collaboration for Project Management Service (Coll4Pm) focuses on the collaborative
management of a collaborative project, taking as a central point of the application the Gantt chart
on which users coming from different environments and backgrounds can socially collaborate.
There is a wide availability of tools (both open source and commercial) on the market giving the
possibility to work on Gantt charts. Interfaces are mature and the user experience is also mature.
Building and managing a Gantt, in a CNO is a complex task. The complexity is related to the
discussions behind the decision summarized in the Gantt file. Focusing on the collaborative
management of collaborative projects the innovation aspect of the Coll4Pm service is to provide
a collaborative environment in which social interactions among humans takes place based on
trust relationships among humans. To provide this, a number of innovations have been created:
A social integrated web environment in which people can collaborate on Gantt charts.
A personalised notification system by news feeds of events occurred in different
project/discussion rooms.
A social collaborative management of changes based on Web2.0.
Availability of human/company profiles and the management of social relationships among
them by assessment of co-workers, integration of communication services and injection of
trust based mechanism coming from COIN c-HI services in project management.
3.2.5.12 Progress beyond State-of-the-Art in Collaboration Visualization Service (CVT)
Trust relies on previous interactions and collaboration encounters [21]. Recently, trust in social
environments and service-oriented systems has become a very important research area. SOA-
based infrastructures are typically distributed, comprising a large number of available services
and huge amounts of interaction logs. Therefore, trust in SOA has to be managed in an automatic
manner [9]. Although several models define trust on interactions and behaviour, and account for
reputation and recommendation, there is hardly any case study about the application of these
models in service-oriented networks. Fundamental research questions, such as the technical
grounding in SOA and the complexity of trust-aware context-sensitive data management in
large-scale networks are still widely unaddressed.
Depending on the environment, trust may rely on the outcome of previous interactions. Trust is
not simply a synonym for quality of service. Instead, metrics expressing social behaviour and
influences are used in certain contexts. Utilizing interaction metrics, in particular calculated
between pairs of network members, enables the incorporation of a personalized and social
perspective. Progresses beyond the State of the Art include:
Trust models for service-oriented cross-organizational collaborations using data collected
through common human interaction services, such as e-mail or IM; thus, unburden actors
from managing relations manually.
64
Exploiting trust networks to support actor discovery (e.g., in social campaigns) and
compositions (e.g., team formation) in highly dynamic networks that are frequently updated
based on occurring interactions (and not only based on manual relation definitions).
3.2.5.13 Progress beyond State-of-the-Art in Trusted Information Sharing Service (TIS)
In collaborations, activities are the means to capture the context in which human interactions take
place. Activities describe the goal of a task, the participants, utilized resources, and temporal
constraints. Studies regarding activities in various work identify patterns of complex business
activities, which are then used to derive relationships and activity patterns. Studies on distributed
teams focus on human performance and interactions even in Enterprise 2.0 environments. Based
on log analysis, human interaction patterns can be extracted [21].
Trusted information sharing, as applied in COIN, is related to selective dissemination of
information (SDI), that deals with questions regarding which (parts of) data are shared with
others, and mechanisms to disseminate data. TIS adopts the concepts of SDI, such as the
representation of information through mechanisms to process XML-based data. However, SDI
does not deal with underlying social models to control sharing of information. Progresses beyond
the State of the Art include:
Trusted information sharing can be considered as a soft access control model that allows only
trusted partners to see ones private profile or uploaded business documents. Once
configured, TIS adapts the amount of shared information flexibly without human
intervention based on dynamically changing trust relations.
TIS can be used in social campaigns, e.g., to control the dissemination of invitations based on
interest profiles and expertise levels. This way, spamming individuals with documents and
messages that are definitely not of interest for them is avoided.
3.2.5.14 Progress beyond State-of-the-Art in Trusted Online Help and Support (TOHS)
Service-oriented Architectures (SOA) typically comprise software services only. Many
collaboration and composition scenarios involve interactions between human actors as well as
software services. Current tools and platforms offer limited support for human interactions in
SOA, therefore Human-Provided Services (HPS) are introduced. HPSs are offered by human
actors. Web services technology is used to describe HPSs and to enable interactions with real
people. HPSs can be used in various collaboration settings on the Web to facilitate expert
discovery and interactions in a service-oriented manner. In COIN, the concept of HPS enables
the expert seeker to discover the right collaboration partners [7] [10].
Compared to other tools and approaches applying expert discovery, THOS does not demand for
manually maintained skill profiles that need to be frequently updated by the user. The used
approach is based on dynamic profiles and collaboration behavior. Dynamic profiles are based
on monitoring of interactions and analysis of relations.
Progresses beyond the State of the Art include:
Unified view on human and software services capturing characteristics of humans, Human-
Provided and Software-based Services. It enables the specification and matching of
multidimensional service descriptions which is essential in the context of Human-Provided
Services. Such an approach is beyond current state-of-the-art and opens up unprecedented
opportunities for future platforms.
Context model capturing social and community aspects. Social information includes friend
networks and can be used to recommend services or compositions. Community aspects
describe the evolution of, for example, preferences and interests, at a global level.


65
3.2.6 Conclusions and Key Benefits
The developed services support key operational functions in a CNO. In this respect, the COIN
project has gone beyond current work by not only building on various existing work, but also
introducing new innovative concepts and services that support dynamic collaboration models in
networks of enterprises. The COIN Innovative Enterprise Collaboration services have been
successfully demonstrated in real life industrial settings in a number of cases.
The process of analysing the usability and take-up of the services as wells as the process of
bringing COIN to the market and creating value for the various stake holders is being described
in a later section of this book.

References
[1] Ollus M., Jansson K., Karvonen I., Uoti M. Riikonen H. On Services for Collaborative Project
Management Taylor & Francis, Production Planning & Control. ISSN: 1366-5871 (electronic) 0953-
7287 (paper)
[2] OntoGen. Text-Mining Software. http://ailab.ijs.si/publications/ accessed 16.6.2011
[3] Sitek, P., Sesana, M., Truong, H-L. (2009), On Baseline IT-Services to Support Enterprise Collaboration, in
Proceedings of the 15th International Conference on Concurrent Enterprising (ICE2009), Sofia Antipolis,
France
[4] Sitek, P., Seifert, M., Thoben, K.-D. (2010a) Towards an inter-organisational perspective to manage quality
in temporary enterprise networks, in International Journal for Quality and Reliability Management, Volume
27, Issue 2, 2010, pp 231 246
[5] Sitek, P., Seifert, M., Thoben, K.-D., Cannas, V. (2010b) Impact of Inter-Organisational Inter-dependencies
on collaborative Quality Management in Enterprise Networks, in Proceedings of the 16th International
Conference on Concurrent Enterprising (ICE2010), Lugano 2010, Switzerland, ISBN 978 0 85358 2700
[6] Sesana M., Taglino F., Cannas V., Gusmeroli S., Production Planning and Knowledge Interoperability
Utility and Value-Added Services in Aerospace Domain , in proceedings oft he eChallenges 2010
conference 27-29 October 2010 Warsaw - Poland
[7] Schall D., Truong H.-L., Dustdar S. (2008) Unifying Human and Software Services in Web-Scale
Collaborations,
[8] IEEE Internet Computing, vol. 12, no. 3, pp. 62-68, May/Jun, 2008.
[9] Skopik F., Schall D., Dustdar S. (2010). Modeling and Mining of Dynamic Trust in Complex Service-
oriented Systems. Elsevier Information Systems Journal (IS), Volume 35, Issue 7, November 2010, pp 735-
757. Elsevier.
[10] Skopik F., Schall D., Psaier H., Dustdar S. (2011). Adaptive Provisioning of Human Expertise in Service-
oriented Systems. 26th ACM Symposium On Applied Computing (SAC), March 21-25, 2011, Taichung,
Taiwan. ACM.
[11] COIN Project Portal: http://www.coin-ip.eu/ accessed 20.5.2011.
[12] Kurumluoglu, M., Nostdal, R., Karvonen, I. 2005. Base concepts, in Camarinha-Matos, L., Afsarmanesh,
H., Ollus, M. (eds.), Virtual organizations. Systems and Practices, Springer-Verlag. 2005; 11-28.
[13] Mills, A. (1998). Collaborative Engineering and the Internet: Linking Product Development Partners via the
Web. Society of Manufacturing Engineers, Dearborn, Michigan.
[14] CycKB The Cyc Foundation. http://www.cyc.com/ accessed 20.5.2011.
[15] COIN Deliverables D4.2.1b c-Product Development Services, 2009
[16] COIN Deliverables D4.2.2b c-Product Development Services Prototypes and Factsheets, 2009
[17] COIN Deliverables D4.3.1b c-Production Planning Services, 2009
[18] COIN Deliverables D4.3.2b c-Production Planning Services Prototype and Factsheets, 2009
[19] COIN Deliverables D4.4.1b c-Project Management Services, 2009
[20] COIN Deliverables D4.4.2b c-Project Management Services Prototypes and Factsheets, 2009
[21] COIN Deliverables D4.5.1b c-Human Interaction Services, 2009
[22] COIN Deliverables D4.5.2b c-Human Interaction Services Prototypes and Factsheets, 2009
66
3.3 COIN Enterprise Interoperability Baseline Services
Enrico Del Grosso
1
, Gorka Benguria
2
, Francisco Javier Nieto De-Santos
3
, Francesco Taglino
4
,
Brian Elvester
5

1TXT e-Solutions, Italy (enrico.delgrosso@txt.it)
2ESI, Spain (Gorka.Benguria@esi.es)
3ATOS, Spain (francisco.nieto@atosresearch.eu)
4CNR-IASI, Italy (taglino@iasi.cnr.it)
5SINTEF, Norway (Brian.Elvesater@sintef.no)
Abstract
Enterprise Interoperability [3] is a relatively recent term that describes a field of activity with the aim to improve the
manner in which enterprises, by means of information and communications technology (ICT), interoperate with other
enterprises, organisations, or with other business units of the same enterprise, in order to conduct their business. This
paper describes part of the work that COIN project has performed in the context of Enterprise Interoperability.
Starting from past experiences in European projects, COIN has developed a set of baseline interoperability services
that aims to solve and cover most of the Interoperability problems that SMEs are currently facing.

Keywords: COIN, enterprise, interoperability, services, ATHENA, baseline, EI service framework
3.3.1 Towards Enterprise Interoperability services
Experiences from piloting activities in the ATHENA project suggested that Enterprise
Interoperability is very challenging and that the expected gains from interoperability research
will consist in finding technologies and methods that will fasten interconnection of applications
through standardised Web infrastructure for software application communication and for
collaboration [1].
The research projects on interoperability in the European Commission Sixth Framework
Programme have developed a vast set of standalone software products and tools, as well as some
Web-based services to address interoperability issues. However, some of these solutions are
difficult to integrate and use for SMEs because of the lack of technology background.
Furthermore, numerous architectural frameworks and sector-specific specifications have arisen
from the standardisation arena. Moreover, the service-oriented computing paradigm and service-
oriented architecture (SOA) have emerged as a major evolutionary step, with Web services, Grid
services and peer-to-peer (P2P) services comprising the major trends. This has been joined by
developments in Semantic Web Services, enterprise modelling, as well as other modelling and
process languages to describe business processes and their executions.
Today, the market is saturated with technology-based solutions that claim to support
interoperability for enterprises, with several commercial middleware solutions among the most
prominent.

Within the context of an enterprise, flexibility, fast development and re-configuration are
important properties for software applications. This implies to avoid as much as possible the
intervention of software engineers and developers, and to prefer direct parameterisation and
configuration by software users. This also implies accurate ways to architecture enterprise
applications that facilitates publication of information managed by the application, publication of
services made available by the application for other applications and finally publication of
services made available for the human users. Finally such architectures should make it possible
to manage coherency of the application systems despite numerous existing interfaces and
adaptation of the application systems within the whole enterprise.


67
In the COIN context, Enterprise Interoperability (EI) services provide functionality for applying
IT solutions that overcome interoperability gaps between two or more enterprises and thus
enabling them to set-up and run collaborations. The main goal of the EI services is to improve
enterprise interoperability, mainly for SMEs, which means to reduce the costs of data
reconciliation, systems integration and business processes synchronization and harmonization.
Typical indicators will be in the cost of service composition and of data mediation and
reconciliation.
3.3.2 COIN EI framework
The COIN EI Services Framework adopts the ATHENA Interoperability Framework (AIF)
[1].
A framework is a structure for supporting or enclosing something else, especially a skeletal
support used as the basis for something being constructed. An interoperability framework
provides a set of assumptions, concepts, values and practices that constitutes a way of viewing
and addressing interoperability issues.
3.3.2.1 ATHENA Interoperability Framework
The interoperability reference model relates the solution approaches coming from the three
different research areas of ATHENA, namely enterprise modelling, architectures and platforms,
and semantic mediation and ontology. Figure 41 illustrates the reference model that focuses on
the provided and required artefacts of two collaborating enterprises. Interoperations can take
place at the various levels (enterprise, process, service and information/data).
Enterprise
(Business)
Processes
Services
Information/Data
Cross-Organisational
Business Processes
Collaborative Enterprise
Modelling
Flexible Execution and
Composition of Services
Information/Data
Interoperability
M
o
d
e
l
-
D
r
i
v
e
n

I
n
t
e
r
o
p
e
r
a
b
i
l
i
t
y
S
e
m
a
n
t
i
c

M
e
d
i
a
t
i
o
n

I
n
t
e
r
o
p
e
r
a
b
i
l
i
t
y
Enterprise
(Business)
Processes
Services
Information/Data
Provided Required

Figure 41 - Interoperability reference model

An interoperability reference architecture relates a set of interoperability levels and a set of
interoperability approaches. An interoperability level denotes the capability level of two or more
collaborating entities to support interoperation.
Interoperability at the enterprise level should be seen as the organisational and operational
ability of an enterprise to factually co-operate with other, external organisations in spite of
e.g., different working practices, legislations, cultures and commercial approaches.
68
Interoperability at the process level is the capability to make proper external views of
enterprise internal processes synchronised by a collaborative inter-enterprise business
process.
Interoperability at the service level is concerned with discovering, ranking, selecting,
composing, orchestrating and executing various applications implemented as a service.
Interoperability at the information/data level is related to the exchanging and sharing
business documents among organizations, by filling interoperability gaps related to the
payload (format and content) and to the messages and/or structures to be exchanged.
The interoperability approaches help us to support interoperations at the various interoperability
levels. A model-driven interoperability approach that cuts across the four interoperability levels
implies that models are used to formalise and exchange the provided and required artefacts that
must be negotiated and agreed upon. ATHENA defines a set of meta-models and languages that
can be supported by tools and methods to construct the models in question.
To overcome the semantic barriers which emerge from different interpretations of syntactic
descriptions, precise, computer processable meaning must be associated with the models
expressed on the different levels. It has to be ensured that semantics are exchangeable and based
on common understanding in order to enhance interoperability. This can be achieved using
ontologies and an annotation formalism for defining meaning in the exchanged models.
3.3.2.2 COIN EI services framework
After a preliminary study of the services and tool that constitute the state of the art, 6 EI service
categories have been chosen from the AIF model:
1. model-driven
2. enterprise modelling
3. business process
4. service*
5. information/data
6. semantic mediation

Enterprise
(Business)
Processes
Services
Information/Data
Cross-Organisational
Business Processes
Collaborative Enterprise
Modelling
Flexible Execution and
Composition of Services
Information/Data
Interoperability
M
o
d
e
l
-
D
r
i
v
e
n

I
n
t
e
r
o
p
e
r
a
b
i
l
i
t
y
S
e
m
a
n
t
i
c

M
e
d
i
a
t
i
o
n

I
n
t
e
r
o
p
e
r
a
b
i
l
i
t
y
Enterprise
(Business)
Processes
Services
Information/Data
Provided Required
*Service
interoperability
is addressed by
the COIN Service
Platform (SP3)

Figure 42 - Baseline categories according to AIF

Since the service interoperability is being addressed by the COIN Service Platform the COIN EI
Services Framework adopts five service categories for EI:


69
Model-driven interoperability services support enterprises to formalise, exchange and align
models that are relevant to set up collaborations.
Enterprise modelling interoperability services support enterprises to factually co-operate
with other, external organisations in spite of e.g., different working practices, legislations,
cultures and commercial approaches.
Business process interoperability services support enterprises to make proper external views
of enterprise internal processes synchronised by a collaborative inter-enterprise business
process.
Semantic mediation interoperability services support enterprises to apply ontology-based
techniques for semantic mediation such as semantic reconciliation of business documents in
order to support interoperability among heterogeneous software applications.
Data interoperability services support enterprises to exchange and share business documents
among organizations, by filling interoperability gaps related to the payload (format and
content) and to the messages and/or structures to be exchanged.
3.3.3 Enterprise interoperability baselines
Services to include in the COIN EI Services Framework have been chosen according to a precise
methodology.
First step has been the analysis of existing state of the art. A lot of work has been done in the
field of interoperability by past European Projects, so all the existing work have been evaluated
to choose which one to include and how.
As a result of this first step, a list of sub-service categories has been found for each framework
categories. These sub-service categories represent specializations and specific domains of each
EI service framework category.
Final step of the process has been the definition of the services to implement for some of these
sub-service categories. The ratio used to select the services to implement derived from end user
requirements and available software from previous works.
The following table shows the list of services that constitute the COIN EI Services Framework.
Table 2 - COIN EI Baseline Services and descriptions
# Baseline EI service Service description
1
COIN Model
Transformation
Service Engine
The engine will be a service entry point for storing model transformations that are aimed
at aligning the huge diversity of models used in the design, integration and
implementation tasks of enterprise applications and systems.
2
COIN POP*
Transformation
Service
The service will provide the functionality of modelling in the context of POP* to JPDL
transformation. The results of the transformation should be published into the open
source JBPMN platform.
3
COIN Enterprise
Interoperability
Maturity
Assessment
Service
The service will help to assess an organization's maturity level concerning the use of
enterprise models as well as the capability of these models to enable the company to be
part of collaboration. Based on this assessment, companies will be guided to choose the
right concepts for improving their capabilities, by taking into account actual market and
enterprise challenges.
4
COIN Semantic
Business Process
Modelling Service
The service will help to reduce the complexity of tasks related to transformation
between different BP models as well as transformation in executable process models
with semantic annotations.
5
COIN Semantic
Business Process
Management
Service
The service will manage the life cycle of deployed Business process models
independently on the underlying engines actually executing the model.
70
6
Athos Ontology
Service
The service will provide functionalities for ontology management. Ontology is a pre-
requisite for semantics-based mediation and reconciliation of business documents.
7
Astar Semantic
Annotation Service
The service will provide functionalities for management of semantic annotations.
Semantic annotation allows digital resources to be described in terms of a common
reference represented by a domain ontology. Such an activity represents a first
identification of semantic and structural mismatches among different information
structures, which is needed for fulfilling interoperability issues among heterogeneous
information systems.
8
Argos Semantic
Transformation
Rules Service
The service will provide functionalities for management of transformation rules service.
Transformation rules represent the semantic mapping able to drive the mediation and
reconciliation.
9
Ares Semantic
Reconciliation
Service
The service will represent the final step towards the actual mediation and reconciliation
of business documents among heterogeneous information systems.
10
COIN Massive Data
Interoperability
Service
The service allows communication among a set of multiple data providers and a set of
multiple data consumers. In a multi-point communication, the interoperability problem
grows exponentially according to the number of entities involved in the communication.
The service will allow the data providers to map their data structure to the requested
schema and fill the schema itself with the data coming from their data sources.
11
COIN Transactional
Data
Interoperability
Service
The service allows the communication between two actors; a customer and a supplier.
The scenario of the communication is the exchange of business documents in the order
to invoice procurement process.

In this other table are listed the sub-service categories of each EI service framework category and
which services correspond to each sub-category.
Table 3 - COIN EI Baseline Services according to framework category
Sub-service category Service Name
Model-driven
interoperability
services
Metamodelling -
Language engineering -
Model mapping and transformation COIN Model Transformation Service Engine
Method engineering -
Enterprise
modelling
interoperability
services
Enterprise modelling -
Enterprise models interchange COIN POP* Transformation Service
Enterprise model deployment
Enterprise interoperability maturity
assessment
COIN Enterprise Interoperability Maturity
Assessment Service
Business process
interoperability
services
Cross-organizational business process
modelling
-
Semantic business process modelling COIN Semantic Business Process Modelling Service
Semantic business processes
management
COIN Semantic Business Process Management
Service
Business process monitoring -
Business process analysis -
Semantic
mediation
interoperability
services
Ontology editing Athos Ontology Service


71
Ontology engineering and maintenance -
Semantic annotation Astar Semantic Annotation Service
Semantic transformation rules building Argos Semantic Transformation Rules Service
Semantic reconciliation engine Ares Semantic Reconciliation Service
Data
interoperability
services
Data mapping COIN Massive Data Interoperability Service
Data infrastructure framework -
Business document modelling -
Business document interchange COIN Transactional Data Interoperability Service
Business document process integration -

References
[1] ATHENA A4, "D.A4.2: Specification of Interoperability Framework and Profiles, Guidelines and Best
Practices", ATHENA IP, Deliverable D.A4.2, 2007a. http://interop-vlab.eu/ei_public_deliverables/athena-
deliverables/.
[2] B. Elvester, G. Benguria, A. Capellini, E. Del Grosso, F. Taglino, COIN D5.1.1 State-of-the-Art and
Baseline EI Services Specifications, July 2008.
[3] M.-S. Li, R. Cabral, G. Doumeingts, and K. Popplewell, "Enterprise Interoperability Research Roadmap,
Final Version, Version 4.0", July 2006.
72
3.4 COIN Innovative EI Services
Enrico Del Grosso
1
, Fabrizio Smith
2
, Hannes Suttner
3
, Francesco Taglino
2

1

TXT e-solutions, Via Frigia, 27 20126 Milano)
2

Istituto di Analisi dei Sistemi ed Informatica A. Ruberti, Viale Manzoni, 30 00185 Roma)
3

Siemens IT Solutions and Services, Gudrunstrae 11 1101 Wien
Abstract
To create added value in a highly competitive, global market, nowadays organisations especially Small and
Medium-sized Enterprises (SMEs) more than ever have to cooperate with appropriate business partners, identify
state-of-the-art business processes and select the best technologies available. This business environment positively
affects demand for Enterprise Interoperability Services (EIS) aiming to provide services to facilitate co-creation, and
services to surmount or even to prevent interoperability issues.
The COIN project adopted the ATHENA EI reference framework which addresses interoperability at different levels.
COIN adapted and substantiated the established concepts, and implemented several services particularly with regard
to information interoperability, process interoperability and knowledge interoperability. This summary highlights a
few out of the many COIN results in the EI domain, i.e. semantic reconciliation of business documents, introduction
of the visibility rules concept, business process gap detection, as well as knowledge sharing of key competences and
skills of enterprises cooperating in a cluster.

Keywords: Enterprise Interoperability, Semantics, Business Process, Information Interoperability, Knowledge
Interoperability, Process Interoperability
3.4.1 Introduction
Enterprise Interoperability [3] is a relatively recent term that describes a field of activity with the
aim to improve the manner in which enterprises, by means of information and communications
technology, interoperate with other enterprises or organisations to conduct their business. In the
COIN context, Enterprise Interoperability (EI) services provide functionality for applying IT
solutions that overcome interoperability gaps between two or more enterprises and thus enabling
them to set-up and run collaborations.
The main goal of the EI services is to reduce the costs of data reconciliation, systems integration
and business processes synchronization and harmonization. The COIN project adopted the
ATHENA EI reference framework (see Chapter 3.3 Baseline EI Services), which addresses
interoperability at different levels, by using two main approaches (i.e., model-driven and
semantics-based). In particular, in this chapter we focus on the following three interoperability
levels:
Information/data level which is related to the exchanging and sharing business documents
among organizations, by filling interoperability gaps related to the payload (format and
content) and to the messages and/or structures to be exchanged.
Process level which is the capability to make proper external views of enterprise internal
processes synchronised by a collaborative inter-enterprise business process.
Enterprise (knowledge) level which refers to the organisational and operational ability of an
enterprise to factually co-operate with other, external organisations in spite of e.g., different
working practices, legislations, cultures and commercial approaches.
In the rest of this chapter, COIN interoperability services are presented. In particular, in section 2
Information Interoperability services; in section 3 Process Interoperability services and in section
4 Knowledge Interoperability services. Then, Section 5 presents the main innovative issues of
the COIN Interoperability services.


73
3.4.2 Information Interoperability services
Information Interoperability services are focused on enabling enterprise information systems to
exchange business documents (e.g., invoices, purchase orders) even if they are not natively
conceived for this purpose. In the COIN project, this activity was mainly devoted to allow:
Exchanging business documents written in UBL (Universal Business Language) in new
interoperability spaces, evaluating several possibilities of exchange: 1:1, 1:n and n:m.
Semantic annotation of business object documents in order to automatically derive the
mediation rules necessary for the semantic reconciliation of formats and contents.
Study how to create federated spaces where the business documents can interoperate each
other without the needs of a common reference models.
In the rest of this section, a description of the main aspects of the information interoperability
services is presented.
3.4.2.1 Data Payload Services
Data Payload services consider the interoperability among business documents in UBL format at
payload level. Payload means that only the content of the document is considered (and not the
structure). Data Payload services apply a rule based logic to manage the change of content in the
different documents. Users can write their own business rules using a graphical tool that translate
such rules into an engine specific XML based language. A dedicated engine applies then all the
rules defined according to specific business logic, like the role of the rule creator or the
sender/receiver of the business document.
3.4.2.2 Semantic Reconciliation services
The semantic reconciliation approach [19]is based on the use of domain ontology as common
reference for the harmonization of heterogeneous data. This harmonization is accomplished into
two different moments: a preparation phase and a run time phase.
In the preparation phase, the schemas of the documents from the software applications are
mapped against the reference ontology. The mapping starts from the semantic annotation and
ends with the building of two sets of semantic reconciliation rules for each document schema: a
forward and a backward set of rules, which allow data transformation from the original format
into the ontology representation and vice-versa, respectively.
The run-time phase concerns the actual exchange of data from an application to another. For
instance, when an application, say, SA
1
, wants to send a document to another application, say,
SA
2
, the reconciliation between the format of SA
1
and the format of SA
2
, is done by applying
first the forward rules set of SA
1
, and after the backward rules set of SA
2
.
3.4.2.3 Federated Interoperability
Federated interoperability is a special approach to interoperability that aims to avoid the use of
any kind of reference model. The interoperability domain is the structure of document, but
instead of putting a middle reference model (ontology) between the two documents, federated
approach is based on the application of several micro-services. Micro-services are atomic
functionalities that apply on single pieces of documents, transforming them into other format.
3.4.3 Process Interoperability services
Cross-organisational Business Process Interoperability (CBPip) Services aims at ensuring a
successful business process collaboration of participating enterprises. In the COIN project, we
concentrated on two services [18]:
74
One service is rule-based transformation of private business processes into public processes.
The public processes of different organizations are then joined together thus forming the
cross-organizational business process which defines the way the organizations cooperate.
The other service is to identify and eliminate interoperability gaps in CBPs.
3.4.3.1 Private2Public Process Transformation
The aim of the Private2Public transformation is to produce a public view of a private process of a
given company, in order to hide all the private and critical data of the private process, resulting in
a simplified process. To this end, we adopted the SBVR (Semantics of Business Vocabulary and
Business Rules) [3] business rule language in order to describe the visibility of different process
elements of a private process. Among the several existing rule languages, SBVR allows a
representation of rules in structured English, which is easily understandable by humans.
The proposed approach and developed services allow describing how a public view should be
produced from a private process, by way of business rules. This is achieved through three
principles:
A Vocabulary (in SBVR) which describes the semantic of Process elements, as well as
the roles of partners in a CBP. The vocabulary defines noun-concepts related to the
modelling of Process elements (Activity, Data) or to their semantics (Sales Department,
Customer, etc.), as well as verb-concepts to specify associations.
The SBVR rules are linked to specific elements of Processes. Indeed when reading a rule,
the transformation service needs to know which elements are described in the rule.
Business rules which specify what should be public. By default, nothing is shown to
partners
11
. The rules are then based on the RBAC principle (Rule-Based Access Control
[4]). The business rules are based on the verb-concept is visible to, and tell which element
in the process should be visible to which kind of partner.
Once a private process has been described by rules, its public view can be extracted. This step is
performed by an ATL [5] transformation, which reads the visibility rules in SBVR and operates
on the XPDL representation of the process.
3.4.3.2 Gap Detection
COIN defines Business interoperability as the capability of two or more systems to cooperate
using exchanged information, and an interoperability gap is a situation when interoperating
business processes do not deliver the expected results while each of the business processes does.
The following kinds of interoperability gaps are addressed by COIN:
Deadlocks: According to the literature [2], deadlocks are situations in which a certain
instance of the model (but not necessarily all) cannot continue working, while it has not yet
reached its end). Deadlocks are classified in the following way: Loop deadlock, multiple
source deadlock, improper structuring deadlock.
Interface Mismatches (e.g., Number of Messages Interface Mismatch, Message Types
Interface Mismatch) which are serious impediment that prevents two separately-modeled
business processes of successful interoperation due to different design assumptions.
3.4.4 Knowledge Interoperability services
In the COIN project, Knowledge Interoperability refers to the capability of exploiting at best the
knowledge of each cooperating enterprise, leveraging on their complementarities, avoiding
unnecessary overlapping. To this end, the main functions of the Knowledge Interoperability

11
This is in fact not described in SBVR, but rather implemented in the transformation itself


75
Services are based on the possibility of identifying the key competences and skills of each
enterprise, matching and contrasting such knowledge among the partners cooperating in a
cluster, identifying missing knowledge to allow for a target enlargement of the cluster.
According to that, Knowledge Interoperability services have been developed for:
acquiring, gathering and organizing knowledge about Competencies and Skills (CS) in a
collaborative network (CN) in the form of a reference ontology (Social Ontology Building
and Evolution service [6]);
describing enterprises CS by means of ontology-based semantic profiles (Enterprise
Semantic Profiling service), in order to represent all the enterprises in a CN in terms of the
same common and shared reference Angelucci et al., 2010];
reasoning on profiles, through semantics similarity techniques, to assess the actual CS asset
of the network, and the impact and added value on the CN due to the entrance of a company
in the CN (Enterprise Semantic Matchmaking service [7]).
In the rest of this section, a brief description of the SOBE service is given.
3.4.4.1 Social Ontology Building and Evolution
The Social Ontology Building and Evolution (SOBE) service supports the building of ontology
about competencies in the context of a cluster of enterprises. SOBE is characterized by three
main aspects:
Automatic knowledge extraction from unstructured enterprise documents, by using natural
language processing techniques [8]. Enterprise documents indeed, are pregnant with
enterprise knowledge. They are data containers that record and drive the processes of the
company.
Social participation of a community of experts. Social aspects during ontology building
and evolution are required since an ontology needs community acceptance. To this end,
SOBE enables the community of experts to validate, discuss about for reaching a consensus,
and enrich the results of the automatic extraction [9].
Step-wise approach that, for reaching the final aim of a domain ontology construction, goes
through intermediate results (i.e., lexicon, glossary, taxonomy).
3.4.5 Main innovation issues
This section underlines what are the main innovative issues introduced by the interoperability
services developed in the COIN project.
3.4.5.1 Information Interoperability services
Concerning the Information Interoperability services for semantic reconciliation of business
documents, the main innovations, with respect to existing solutions [15], [16] [17], regard the
automatic support to the mapping process and the adopted pattern-based approach. This
approach hides to the end user the technicalities of the logic-based underline representation, and
allows the definition of complex data transformations through the instantiations of a limited set
of patterns.
Considering the federated approach for information interoperability, based on application of
micro-services in sequence, compared to the semantic approach, it has both pros and cons. The
main pro is that reconciliation is simpler and more immediate, making this approach suitable for
quick, one shot transformations. The main con is that the format of the document should be
comparable (ideal situation is different versions) in order to have an effective transformation.
This makes semantic approach more complete and general, even if the creation of the middle
ontology can be a very complex work.
76
3.4.5.2 Process Interoperability services
COIN introduces the concept of Visibility Rules, which specify what process elements are
visible to which partner. There are two innovation aspects concerning those rules. Firstly,
Visibility Rules are specified in SBVR, which allows a representation in Structured English. This
means that it is easily readable and understandable by business actors, and provides a very high
usability and friendliness profile. Secondly, such rules are specified in a separate file, and are not
specific to a particular private process: they can be applied to the whole set of private processes a
company has.
COIN allows defining several public views from a single private process, without any change
needed in neither the private process nor the Visibility Rules. This is because the transformation
takes into account three parameters: the private process, the Visibility Rules, and, most important
here, for whom the public process is generated for (e.g. a customer, a finance department or
a supplier). This means that the company can easily parameterise the transformation to its
needs, without having to redefine its strategy concerning the choice of what is private/public.
3.4.5.3 Knowledge Interoperability services
With respect to [10], [11], the SOBE service presents the complete ontology evolution process
and provides a detailed description of the collaborative process (i.e., debating, and voting) and
clear indication of the needed steps and relative milestones. Furthermore, SOBE introduces
automatic supporting tools trying to integrate at best human and software-based activities.
Considering the existing proposals of frameworks for enterprise modelling [12] [13] [14], they
are in general rather complex, trying to capture within a single framework all the different
aspects and dimensions that characterise an enterprise. For this reason, enterprise semantic
profile is here represented as a CS profile in the form of an Ontology-based Feature Vector
(OFV) [7], which is basically a set of concepts from the reference ontology adopted by the
enterprise cluster. It avoids entering the complex theory of enterprise frameworks and it
concentrates on the production capacity of an enterprise, synthesized by its competencies and
skills (CS). Representing each profile as an OFV guarantees the uniqueness of the interpretation
representation. The fact that the representation is not ambiguous derives from the nature of the
terms appearing in the vector(s), which are representative of ontology concepts (hence, ontology-
based feature vectors). This non ambiguity of the representation implies that the represented
enterprises CS are universally intended within the enterprise cluster with a (unique) meaning
accessible to all because connected to the clusters ontology.
3.4.6 Conclusions
In this paper, we presented the Enterprise Interoperability services studied and developed within
the context of COIN project. The research work produced a set of services that can be applied in
different kinds of interoperability domains. Current services have been developed following the
ISU (Information Service Utility) idea, and have been thought to be put in clouds of other
services to be found, orchestrated and executed in different kind of processes according to the
needs of the users. At the moment, these services can be seen as working prototypes that
demonstrate that the ISU idea can be applied to interoperability, and that general services can be
developed to address several kinds of problems in different domains. The next step in this path
will be the development of smart services that can auto-configure themselves according to the
specific problem they are facing.

References
[1] [Li, et al. 2006] M.-S. Li, R. Cabral, G. Doumeingts, and K. Popplewell, "Enterprise Interoperability
Research Roadmap, Final Version, Version 4.0", July 2006.
[2] [Awad and Puhlmann, 2008] Ahmed Awad and Frank Puhlmann: Structural Detection of Deadlocks in
Business Process Models, BIS 2008, LNBIP 7, pp.239250, Springer-Verlag Berlin Heidelberg 2008


77
[3] [SBVR, 2010] Semantics of Business Vocabulary and Business Rules, version 1.0, OMG,
http://www.omg.org/spec/SBVR/1.0/, last visited: 16.04.2010
[4] [RBAC, 2010] http://www.techstreet.com/standards/INCITS/359_2004?product_id=1151353.
[5] [ATL, 2010] ATLAS Transformation Language, version 3.0.0, http://www.eclipse.org/m2m/atl/, last
visited: 16.04.2010
[6] [Angelucci et al., 2010] Angelucci D., Barbagallo A., Di Mascio T., Missikoff M., Taglino F.: A social
platform for enterprise ontology building. Proc. of Open Knowledge Models Workshop. October 2010,
Lisbon, Portugal.
[7] [Formica, 2010] Formica A., Missikoff M., Pourabbas E., Taglino F. : Semantic Search for Enterprises
Competencies Management. Proc. of KEOD 2010.
[8] [DAmadio, 2008] D'Amadio P., Velardi P., Navigli R. Mining the Web to Create Specialized Glossaries -
IEEE Intelligent Systems, 2008
[9] [Barbagallo et al., 2010] Barbagallo A., De Nicola A., Michele Missikoff: eGovernment Ontologies: Social
Participation in Building and Evolution, in the Proceedings of Forty-Third Annual Hawaii International
Conference on System Sciences, IEEE Computer Society Press, 2010
[10] [Tempich et al., 2007] Tempich C., Simperl E., Luczak M., Studer R., Pinto H. S.. Argumentation-Based
Ontology Engineering. IEEE Intelligent Systems 22(6): 52-59 (2007).
[11] [Karapiperis and Apostolou, 2006] Karapiperis S. and Apostolou D.. Consensus building in collaborative
ontology engineering processes, Journal of Universal Knowledge Management 1 (3), 2006.
[12] [CIMOSA, 1996] CIMOSA - Open System Architecture for CIM, Technical Baseline; Version 3.2
CIMOSA Association, private publication (March 1996).
[13] [Zachman, 1987] "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.
[14] [Williams, 1998] Williams T. J. PERA and GERAM - Enterprise Reference Architectures in Enterprise
Integration. Proceedings of the IFIP TC5 WG5.3/5.7 Third International Working Conference on the
Design of Information Infrastructure Systems for Manufacturing II table of contents Vol. 144 archive, pp. 3
- 30 (1998)
[15] [Kerrigan et al. 2007] Kerrigan, M., Mocan, A., Tanler, M., & Fensel, D. The Web Service Modeling
Toolkit - An Integrated Development Environment for Semantic Web Services. Proc. ESWC 2007,
Innsbruck, AU.
[16] [Mocan et al. 2007] Mocan, A., & Cimpian, E. (2007). An Ontology-based Data Mediation Framework for
Semantic Environments. International Journal on Semantic Web and Information Systems , 3 (2), 66-95.
[17] [Kabak et al. 2009] Kabak, Y., Dogac, A., Ocalan, C., Cimen, S., & Laleci, G. B. (2009). iSurf Semantic
Interoperability Service Utility for Collaborative Planning, Forecasting and Replenishment . eChallenges
Conference. Instanbul, Turkey.
[18] [Huber, et al. 2011] S.Huber, C.Carrez and H.Suttner. Development of Innovative Services Enhancing
Interoperability in Cross-organizational Business Processes. IWEI 2011, Lecture Notes in Business
Information Processing, Volume 76, Part 2, Part 2, pp. 75-88, Springer Berlin Heidelberg, 2011.
[19] [Missikoff et al., 2010] Missikoff M., Smith F., Taglino F.: Semantic Services for Business Documents
Reconciliation. Chapter in the book "Interoperability in Digital Public Services and Administration:
Bridging E-Government and E-Business". Ed. Yannis Charalabidis. 2010. ISBN 978-1-61520-887-6
(hardcover); 978-1-61520-888-3
[20] [Angelucci et al., 2010] Angelucci D.., Barbagallo A. , Taglino F D5.3.1b Innovative Knowledge
Interoperability Services Final Specifications (Deliverable COIN project).
78
4 COIN Demonstrators
4.1 The COIN EI/EC Services in industrial Supply Chains
The impact of COIN Project has been spread on four Supply Chains. Supply Chains are the most
static and long-lasting collaboration form addressed by the project; here is where long term
relations and stable organisational and economic structures among enterprises allow the adoption
of the most optimized and important EI solutions, where optimization and efficiency are of key
importance
This chapter focuses on the four COIN supply-chains pilots, two in the Western Europe: the
EIEC Pilot in an Automotive Supply Chain (ACS) and the Aerospace pilot in the Lazio region in
Italy and two in the Eastern Europe: the Pilot in a Railways Supply Chain (KTU) and the pilot in
a Construction Supply Chain (UPB).



79
4.1.1 An EI/EC Pilot in an Automotive Supply Chain
Simon Oman, Duan Buen
2

1 Polycom d.o.o., Poljane nad kofjo Loko 76 d.o.o., Polycom d.o.o., Poljane nad kofjo Loko 76, Slovenija, simon.oman@polycom.si
2 GIZ ACS, Dimieva 9, 1000 Ljubljana, Slovenija, dusan.busen@acs-giz.si
Abstract
In business environment where supply chains strive to remain flexible, data exchange with the use of information
systems represents a competitive advantage. Ontology has been proposed as an important concept of business
collaboration so as to achieve interoperability of information systems in the supply chain. This paper presents internet
based collaboration in the automotive supply chain. Enterprise Collaboration and Interoperability (EC & EI) brings a
new concept of business collaboration into the automotive supply chain, namely the so-called computing in the
clouds. At the same time, the paper demonstrates a prototype solution presenting a model of data exchange in the
Automotive Cluster of Slovenia (ACS). The presented prototype solution facilitates the companies in the Cluster to
operate more swiftly and ensures a more reliable flow of information.

Keywords: collaboration, interoperability, automotive supply chain, pilot solution
4.1.1.1 Brief History of Automotive Cluster of Slovenia
The market conditions pose an additional challenge to the Automotive Cluster of Slovenia
(henceforth also referred to as the ACS), in particularly, to adapt to the renewal of certain
processes. Companies representing the association in the ACS, therefore, pay more and more
attention to research and development with an objective to keep pace with the development in
the most rapidly growing industry in the world, so as to ensure the introduction of new products
and technologies and thus affect the increased volume of demand. The objective is clear,
effective and profitable growth. Potential for scientific and technological breakthrough in the
automotive industry proves to be extensive and extremely diverse. Collaboration and
interoperability, integration and constant search of potential partners in the construction of
electrical machinery and devices represents a huge potential breakthrough for the ACS. In the
search of new partners focus is paid on equipment and systems of power electronics, systems and
algorithms for the management, supervision and management. Furthermore, the ACS wishes to
streamline in the development of methods for rapid prototyping, as well as the design and
integration of different information technology systems. The latter affects not only the events in
business environment, but also acts decisively on setting strategies, reeling business processes
and organization of companies. Information technology provides valuable contribution to the
replacement of more expensive production since the creators of cheaper, established, more
effective connections between processes facilitate simpler and more reliable integration between
processes and thus contribute to value added in designing new products. Information technology
improves business processes by modifying or transforming activities taking place within the
process, thereby replacing expensive or less efficient process with cheaper and more effective
ones.

It still proves extremely important for the Slovenian automotive industry to strengthen its
position in the world markets, namely through innovation and investment in knowledge and
technology. This should be done now when there are many possibilities for the Slovenian
suppliers arising from the transfer of R&D and manufacturing capability of the vehicle
manufacturers to suppliers of systems. Therefore, the ACS intends to accelerate and enhance the
development of more complex products, such as electronics in the passenger compartment
interior, pedal box, hand brake, brake system, body and lighting equipment, systems, doors,
mirrors, exhaust system, suspension, window systems washer, air conditioning, heating, seats
cooling, steering and safety systems, engine and transmission components (including castings
80
and forgings). Simultaneously, the ACS seeks to establish the development infrastructure for the
development of new solutions for the electrification of vehicles, internal combustion engines,
security and comfort, and technological and manufacturing excellence. In order to provide the
integration of the Slovenian and international associations, the ACS shall upgrade network
connections to share and acquire new skills. By providing extremely flexible environment with
the concentration of development resources on specific development areas the ACS shall seek to
position itself as a flexible development and pre-development suppliers to global vehicle
manufactures. Successful implementation of all R&D projects is a lengthy process that requires a
lot of cooperation and may take several years before its objectives are fully accomplished. As
stated above, in addition to single R&D projects and their objectives, great attention should be
paid to the establishment of strong horizontal and vertical, as well as physical and intellectual
integration, taking into account the specificities of various environments and in accordance with
the principle of partnership and concentration. In this way, R&D projects have an additional
positive effect on the ACS as well as in other fields and areas.
4.1.1.2 Description of relevant facts
Modern manufacturing companies need to establish an efficient strategic cooperation with the
purpose of improving their competitiveness on the market [4]. While attention was paid to
optimisation of production processes in the previous decade, now proves to be the right time to
align supply chain all the way from suppliers to customers [1]. The objective of managing the
supply chain is faster and more flexible coordination among customers and their suppliers [7].
Suppliers operating in the manufacturing field, in particularly, small and medium-sized
companies (SME) call for constant improvement of their operations in the business environment,
thus setting such companies in more favourable economic position [8].

So as to improve organisational interoperability into a complex adjustable system definitely
proves as a challenge and at the same time almost an impossible undertaking. The existing
approaches to modelling a company (e.g. UEML, ARIS), modelling of business processes (e.g.
SCOR model) and work process modelling (e.g. BPEL) definitely strive towards establishing
integration among companies [8]. Increasingly present software allows large and small-sized
companies to join computing in clouds. Services in clouds ensure connectivity of databases and
form a part of information infrastructure allowing companies and organisations to move or
integrate a particular quantity of data on the location in the cloud. Disadvantage of such
integration is the difference among the companies and organisations wishing to collaborate. In
particularly, a question arises as to how collaboration of companies using different software may
be improved.

Empirical studies [3,6] show that the integration of supply chain ensure better operative and
business success. In order to make use of all advantages offered by the integration of supply
chain, it is important to reorient operations into an exchange of information among companies
[2]. There are many sub-suppliers in automotive sector using simple software to manage
information flow. However, different translators are used to meet the needs of collaboration. The
role of small and medium-sized companies in the automotive sector has been increasing
dramatically the fact being that they provide various support to large companies. In doing so,
they constantly face with software technology, which proves extremely expensive and hard to
manage for small and medium-sized companies, bearing in mind that software with its
maintenance is becoming more and more expensive, while the needs for staff and knowledge on
managing such software are becoming ever greater. Alignment of processes for joint projects
proves extremely important since the collaboration and alignment of operation in the supply
chain brings valuable value added. The existing solutions represent provision of comprehensive


81
information support for companys internal processes [5]. Said processes are generally roughly
divided into commercial and technical processes both requiring intensive collaboration.

Commercial process (Figure 43) is characterised with the fact that most orders and call-offs are
received with the help of software which enables computer data exchange. All orders and call-
offs are recorded and archived in business information system and allow the company to make
necessary and required forecasts.

Figure 43 Commercial Process

Technical process, on the other hand, requires that business information system accepts
development detailed lists elaborated on the basis of the CAD/CAD/CAE technical system. Each
production detailed list contains all component parts of the tool for injecting thermoplastic
material. Each semi-manufactured product is accompanied with the order system or work order
system. Calculation of needs for material and cooperation is performed on the basis of semi-
manufactured product status. Calculation facilitates elaboration of purchase orders (needs for
cooperation and material). This is followed by processing technology which, in principle,
represents the drawing up of technical processes and work instructions. Feedback serves for
reporting on the status of work order or, in this case, for reporting on the status of tool, however,
it is important to emphasise that technical process envisages managing of data on different levels
which includes also the production of electrodes for a particular semi-manufactured product and
cooperation (Figure 44).

Figure 44 - Technical process
- BOR (Book Of Requirements)
- BOM (Bill Of Materials)
4.1.1.3 Presentation of pilot solutions
A developing software feature enables large and small-sized businesses to take part in computing
in the clouds. Services in the clouds provide database connection and are a part of the IT
infrastructure, enabling companies and organisations to connect or integrate an amount of data
82
on the location in the cloud. All the aforementioned allows the Automotive Cluster of Slovenia
to offer a business model which provides a variety of open source solutions (orders, call-offs,
plans, preview of 3D models, etc.) on the market. These open source services shall allow an
integration of businesses that are different in manpower and industrial branches in the supply
chain. Advantage of business model provides various benefits such as:
new business opportunities;
connections with partners who do not have internal IT platforms (SMEs & smaller);
connections with partners who have different and/or unrelated IT platforms (SMEs &
smaller);
better communication between partners who have different SW or without it (for example
CAD);
safe work on common documents that are on the same platform;
time savings in product development (henceforth referred to as PD) phase;
reduce total cost of PD phase;
From technical point of view the solution provides a new mental dimension which shall be
presented hereafter. First of all, a joint ACS server with different services installed (orders, call-
offs, plans, preview of 3D models, etc.) needs to be set up. Each company shall be able to
integrate these services into their business processes. However, the users shall be divided into
two groups:

legacy system users
non-legacy system users

Legacy system users are those users who use one of the legacy systems (SAP, Navision, Baan,
etc.). Nonetheless, there are also non-legacy system users, who fail to have the aforementioned
ERP systems yet use only the Internet Explorer. Due to the said reason the system of integration
of individual users shall be different.

4.1.1.3.1 Process of integration
As mentioned before, the users shall be divided into the legacy system users and non-legacy
users. The characteristic of the legacy system users is that both parties send information to the
ACS server providing the COIN (Enterprise COllaboration & INteroperability) services. This is
followed by the alignment of information on the ACS server with the help of COIN service.
When information is aligned, the information on agreement is created. This is followed by a
feedback indicating the confirmation of the already agreed data.


83

Figure 45 - Integration process for the legacy system users

It is characteristic for the non-legacy users that one of the clients is not using the legacy system
but uses the Internet Explorer for the purposes of alignment. In such a case only one client sends
information to the ACS server containing the COIN services. The information on the ACS server
uses COIN services and offers them for the preview also to the non-legacy system user. This is
followed by alignment of information on the ACS server as is the case with the legacy system
users. Mutual alignment or coordination between the clients ends when the agreement is
concluded. At the end feedback information is provided indicating a confirmation of already
aligned data.


Figure 46 - Integration process for the non-legacy system users

4.1.1.4 Conclusion
The companies in the Slovenian automotive industry establish that cloud computing may follow
the technological trend well, while it is necessary that the said technology is integrated into
business processes as swiftly as possible, with the purpose of maintaining the companies
84
competitive advantage with their apposite vision of development and business ethics of global
operations. The COIN system provided represents a group of applications that reduces total costs
of ownership and may assist companies in the automotive industry of Slovenia to adapt more
rapidly to the more and more demanding business environment and global markets. There are
also some disadvantages such as data safety in the clouds, as well as control and reliability of
services offered.

References
[1] Abele, E., Elzenheimer, J., Liebeck, T., Meyer, T. (2006), Reconfigurable Manufacturing Systems and
Transformable Factories Globalization and Decentralization of Manufacturing, 1st edition. Springer. pp.
45.
[2] Cagliano R., Caniato, F., Spina G.(2004), Lean, agile and traditional supply: how do they impact
manufacturing performance? Journal of Purchasing & Supply Management, 10 (45), 151164.
[3] Frohlich M.T., Westbrook R. (2000), Arcs of integration: an international study of supply chain strategies,
Journal of Operations Management, 19 (2), 185200.
[4] Humphreys, P.K., Lai, M.K., Sculli, D. (2001), An Inter-Organizational Information System for Supply
Chain Management, International Journal of Production Economics, 70, 245255.
[5] Panetto H., Arturo Molina A.(2008), Enterprise integration and interoperability in manufacturing systems:
Trends and issues, Computers in Industry, 59 , 641646.
[6] Rosenzweig E.D., Roth A.V., Dean J.W. (2003), The influence of an integration strategy on competitive
capabilities and business performance: an exploratory study of consumer products manufacturers, Journal
of Operations Management, 21 (4), 437456.
[7] Teruaki, I., Mohd, R.S. (2000), A Blackboard-Based Negotiation for Collaborative Supply Chain System,
Journal of Materials Processing Technology, 107, 398 403.
[8] Weichhart G., Feiner T., Stary C. (2009), Implementing organisational interoperabilityThe SUddEN
approach, Computers in Industry, 61, 152160.


85
4.1.2 Production Planning and Knowledge Interoperability Services in the Lazio Aerospace
Cluster
Vittorio Cannas
1
, Gerardo Lancia
1

1 Filas SpA Aerospace Technological District,
Piazza della Liber 20, Rome, 00192, Italy, +39 06 32885257, {cannas,lancia}@filas.it
Abstract
This paper reports the work done in the adoption of innovative Production Planning and Knowledge Interoperability
Services in the end-user business processes. With knowledge interoperability it is here intended to exploit at best, by
using semantics-based technologies, the knowledge of enterprises cooperating in a cluster, leveraging on their
complementarities, and avoiding unnecessary overlapping. With Production Planning it is here addressed the
enhancement of collaboration among cluster partners in the creation of production plans and complementary
activities. The work is applied to a test case in the aerospace technological district located in the Lazio region of Italy.
The test case has been extensively documented with a particular focus on the description of scenario challenges and
on the expected benefits coming from the adoption of COIN services. Results and business benefits are presented.

Keywords: Enterprise Interoperability, Enterprise Collaboration, Collaborative Production Planning, Knowledge
Interoperability, Aerospace Domain
4.1.2.1 Introduction
One of the trends in the global market is the increasing cooperation among enterprises.
Organisations have to flexibly and continuously react to (imminent) changes in markets and
trading partners. Large companies but also small and medium enterprises (SMEs) have to cope
with internal changes from both a technical (e.g. new information, communication, software and
hardware technologies) and an organisational point of view (e.g. merging, re-organisation, virtual
organisations, etc.). In this context, the competitiveness of an enterprise depends not only on its
internal performance to produce products and services but also on its ability to seamlessly
collaborate and interoperate with other enterprises.
The past decade has seen significant advances in enterprise collaboration and interoperability
areas. Numerous paradigms, architectures (e.g., Service Oriented Architecture frameworks [1]),
enterprise modelling and process languages to describe business processes (e.g., BPMN [2]) and
their executions (e.g., BPEL [3]) have arisen. However, more than a decade after, interoperability
and collaboration issues are still concrete problems for enterprises, causing indirect costs due to
lost business during down time, lost productivity of staff, inability to build products, and loss of
company image, and so on.
12

In this paper, production planning and knowledge interoperability services from the COIN IP
project perspective will be described. Services will be presented in the context of a complex
environment like the Technological Aerospace District in the Lazio Region.
4.1.2.2 Business Case Description: The Filas test case
The Technological Aerospace District (DTA) located in the Lazio Region of Italy sees a major
concentration of large, medium and small enterprises involved in the aerospace supply chain.
This position has been strengthened during the last two decades by specific government
commitment at national, regional and local levels. The large industrial companies and smaller
enterprises operating in the Region are characterised by strong technical capabilities, high quality
productivity and broad diversification in national and international projects. Filas, the financial
investment agency of the Lazio Region, which coordinates and promotes the activities of the

12
http://www.smartgridnews.com/pdf/SGNInteroperabilityWhitePaperJune2007.pdf
86
technological aerospace district, focuses on the management of tools related to innovation, acting
as the regional instrument to support the socio-economic development and full employment of
Lazio. The technological aerospace district shows a five Billion Euro turnover with 30,000
employees, 250 prominent sized companies concentrated in different areas of industrial
expertise, 10 Research Centres, 5 Technological Parks, 5 Universities, 4 Engineering Faculties,
3.000 professors, researchers and specialists involved in aerospace R&D activities, incubators
and support services for technology transfer and start-up creation.
Test cases are structured in the aerospace domain and aim at demonstrating end-users benefits
deriving from the adoption of innovative collaborative and interoperability COIN services. Here
two test cases are described: the first has to do with collaborative production planning (c-PP) of
satellite antennas and the second with knowledge interoperability applied to competence and
skill management mapping of DTAs stakeholders.
The test case scenario of c-PP sees the involvement of a DTA enterprise which main business is
to produce satellite antennas for high-speed trains for a major European railways company.
Specifically, such SME operates in a supply chain network and manages a network of worldwide
suppliers producing antennas components. Such SME assembles tests and ships antennas to a
final client. The SME has the need to improve its production planning process in order to
increase the production density and make more efficient and effective all business processes, for
example in negotiating orders terms, in selecting antenna components suppliers, in planning the
whole production process, in producing and shipping final products. The SME business needs
have been identified by depicting as-is and to-be scenarios and by listing performance indicators
that elicit real business benefits resulting from the use of innovative COIN services. In particular,
COIN innovative services allow the selected SME to have effective collaborative tools that
overcome traditional inefficient management of supply chain networks. Generally speaking,
SMEs in the DTA do not make use of innovative collaborative tools to support their business
processes and therefore, the set-up of such test case could eventually represent a best-practice in
the aerospace domain.
The test case on knowledge interoperability has to do with competences management of the
enterprises in the DTA. In particular, Filas manages a DTA web portal
13
where actors
(enterprises/research organizations), working in the aerospace sector, can register themselves,
declaring their main fields of interest (i.e., products, components, technologies). Currently, this
activity is performed manually and the accuracy of the provided information is poor and scarcely
usable for inferring information on the value of the DTA as whole. In fact, the objective of the
web portal is to create a large community of DTA actors wishing to display their business
activities and technological competencies in order to establish business synergies. To this end,
the introduction of knowledge interoperability services will aim to ease the whole company
registration process (i.e., enterprise profiling) in the DTA web portal. By doing that, Filas could
significantly increase the quantity and quality of information inserted by enterprises and research
organizations into the web portal. This would allow to better map actors needs in order to address
specific measures, policies and incentives to support DTA actors business development. This
would in turn increase competitiveness and create new business opportunities for DTA cluster
actors.
4.1.2.3 COIN solutions
4.1.2.3.1 Knowledge Interoperability pilot

13
Aerospace Technological District. WWW page. http://www.lazio-aerospazio.it


87
Knowledge Interoperability is here intended as the way to exploit at best the knowledge of the
enterprises cooperating in a cluster (e.g., Collaborative Network), leveraging on their
complementarities, and avoiding unnecessary overlapping.
To this end, a fundamental aspect is the representation of the enterprises knowledge. Many
existing proposals for enterprise modeling, such as Zachman [4], CIMOSA [5], GERAM [6] are
in general rather complex, trying to capture within a single framework all the different aspects
and dimensions that characterise an enterprise. We take advantage of the POP* [8] framework
focused on Products, Organization, Processes, and we concentrate on Organization, and in
particular on the production capacity of an enterprise, synthesized by the competencies and skills
it is able to deploy and put at work to produce value.
Evaluation of COIN EI services has been performed by using the COIN service platform
equipped with the following innovative EI services: i) Enterprise Semantic Profiling service
(ESPS), ii) Enterprise Semantic Matchmaking service (ESMS) iii) Collaborative Network
Semantic Assessment Service (CNSA), iv) Semantic Assessment of Company Entrance in the
Collaborative Network (SACE).
ESPS service is for representing the knowledge asset of the single enterprises in the cluster. For a
given enterprise, a semantic profile is built in order to represent the competences of the enterprise
at best. To build an enterprise semantic profile, the service uses knowledge extraction techniques
applied to a corpus of documents specific of the given enterprise, and semantics-based matching
techniques to suggest the feature vector. A human validation of the feature vector will allow the
desired enterprise semantic profile to be defined.
ESMS service: enterprise semantic profiles are used as input by a semantic matchmaking service
that allows their comparison in order to identify semantic similarities and coverage of two
profiles.
The above services will be at the basis of the CNSA and SACE services providing:
Semantic assessment of the knowledge asset of the whole enterprise cluster, in order to
detect: (i) the Competences and Skills (CS) requested by the cluster, and covered by the
member enterprises; (ii) the CS requested by the network, but not currently covered by any
enterprise in the network (CS gap); (iii) the CS strongly and poorly owned by the network.
Semantic assessment of company entrance in the cluster, in order to evaluate the impact on
the cluster due to the entrance of an enterprise.
By doing this, transfer of new competencies gained by a Virtual Organization formed by
enterprises in the cluster to the cluster itself is then performed. Figure 47 shows a schematic view
of the interactions in the Knowledge Interoperability pilot.
Companles users
u1A Web orLal
knowledge
lnLeroperablllLy Servlces

Figure 47 - Knowledge Interoperability Pilot
88

4.1.2.3.2 Collaborative production planning pilot
This pilot has been developed in the context of the collaborative Production Planning (c-PP)
paradigm of the COIN project. Services tested and evaluated are: i) Collaborative Production
Planning Portal Service (C3P); ii) Production Planning Service (PPS); iii) Collaborative Quality
Management Service (cQMS). These services are cross-used in several satellite antennas
production planning business processes.
The major collaboration targets are the agreement on a collaborative production plan, the plan
update, and the support on the exception handling which are very often raised in the real
environment. To our knowledge, such support it is not well structured in similar existing systems
and there are several research directions aiming to create collaboration systems among value-
chain actors [7] [8].
C3P service is used to support collaboration among different organizations that have different
production planning systems. The major collaboration targets are the agreement on a
collaborative production plan, the plan update, and the support on the exception handling which
are very often raised in the real environment.
PPS service is used to provide a production planning system according to the software as a
service (SaaS) paradigm, able to unburden SMEs of the workload related to software installation,
maintenance and update. PPS represents the manager of production plan information of different
actors and it has been integrated into C3P services.
cQMS enables enterprises in the cluster to investigate inter-organisational interdependencies
based on their competence profile descriptions stored in the C3P. This service helps enterprises
to prevent production planning errors.
Figure 48 shows a schematic view of the interactions in the c-PP pilot.
AnLenna roducLlon lannlng
Schedule
u1A LnLerprlse
u1A LnLerprlse's
suppllers
CollaboraLlve roducLlon
lannlng Servlces

Figure 48 - Collaborative Production Planning Pilot
4.1.2.4 Results and Business Benefits
Final evaluation of COIN innovative services have highlighted that the adoption of EC&EI
COIN services can increase business benefits through adoption of the SaaS paradigm and
without increasing IT systems costs. Key business indicators for demonstrators activities have
been identified. Specifically, regarding the indicators of EC pilot, the process of gathering
requirements implies a faster collection of several typology of information in the whole supply
chain network. By using C3P and PPS, all actors (client, supplier and sub-suppliers) share all
project information and communicate in a faster and simpler fashion. Also, the process of
assessing resources through a proper planning of work activities implies a cost saving both in
human resources and in production processes. At present, enterprises involved in the pilot do not


89
use any collaborative tool and they complain a poor performance of their production planning
process.
Concerning EI pilot, the indicators are focused on governing the Filas aerospace cluster
performance. The process of governing cluster rules makes the cluster information more reliable
and easily accessible as it conforms to certain common standards for all cluster actors. COIN
services allow a better performance control by increasing reliability of cluster competences
information. Govern cluster information means improve its dissemination to the whole cluster.
The possibility to speed up information collection and cluster competences mapping, increases
the frequency of information dissemination to the whole cluster network. In fact, communicate
the value added coming from a new company entrance in the cluster is very important. This also
implies that the cluster itself is able to be continuously updated allowing a better response to
business opportunities. Presently, competence and skill management mapping in the DTA is
done without any use of knowledge interoperability services and DTA cluster recognises the
poor of the present solution.
4.1.2.5 Conclusions
The presented services are the final version of COIN collaborative platform prototype. Some
lessons learnt can be depicted from analysis of the addressed scenario. First of all the aerospace
domain has been recognised as a suitable case for Production Planning and Knowledge
Interoperability services that can be very effective in this sector. In particular collaboration in
production planning is strongly required by SMEs mainly for the fast recovery in case of failure,
production delays and in production rescheduling due to customer support (maintenance). In
these tasks, SMEs are able to significantly enhance efficiency and effectiveness of processes that
is reflected in a reduction of planning time and faster answers to customers needs.
As to Knowledge Interoperability services, the analysis of the Filas scenario gives positives
expectations with respect to their application and effectiveness. In fact, a very large district, like
the DTA, in a very complex and heterogeneous domain, like the aerospace one, needs some
instruments for maintaining an up to date map of the knowledge asset of the involved enterprises,
in order to be able to understand how the needs of the cluster and the capabilities of the
enterprises in the cluster itself evolve with respect to those needs.

References
[1] Erl T.; Service-Oriented Architecture: Concepts, Technology, and Design. Pearson Education Ed (2005).
[2] OMG: Business Process Model and Notation. Version 2.0, August 2009,
http://www.omg.org/spec/BPMN/2.0.
[3] Business Process Execution Language. See: http://www.oasis-open.org/specs/#wsbpelv2.0
[4] "A Framework for Information Systems Architecture." John A. Zachman. IBM Systems Journal, vol. 26,
no. 3, 1987. IBM Publication G321-5298.
[5] CIMOSA - Open System Architecture for CIM, Technical Baseline; Version 3.2 CIMOSA Association,
private publication (March 1996).
[6] Williams T. J. PERA and GERAM - Enterprise Reference Architectures in Enterprise Integration.
Proceedings of the IFIP TC5 WG5.3/5.7 Third International Working Conference on the Design of
Information Infrastructure Systems for Manufacturing II table of contents Vol. 144 archive, pp. 3 - 30
(1998)
[7] Quan L., Hui M. - A Collaborative Production Planning Model for Multi-Agent Based Supply Chain - 2008
International Conference on Computer Science and Software Engineering
[8] Hyun Joon S. Abstract - Collaborative production planning in a supply-chain network with partial
information sharing Int J Adv Manuf Technol (2007) 34:981-987 DOI 10,1007/s00170-006-0664-6 (C)
Sringer-Verlag London Limited
90
4.1.3 An EI/EC Pilot in a Railways Supply Chain (KTU)
Valentinas Kiauleikis, Nerijus Morkeviius, Mindaugas Kiauleikis
1

1 Kaunas University of Technology, Computer Engineering Department,
Studentu st. 50, LT-58631 Kaunas, Lithuania
Abstract
Pre-manufacturing business processes, i.e. customer order analysis and evaluation, ordering from manufacturing
partners, and agreements signing in enterprise producing railway parts, are analyzed in this paper. Main purpose of
this research was to analyze possibilities of putting into practice EI/EC services on COIN platform. Three appropriate
use cases were extracted and gathered to show how business scenarios change when modern EC/EI services replace
traditional communication means and what benefits are expected in such cases. Specifics of currently used Enterprise
Resource Planning (ERP) systems in Lithuania and requirements to develop and implement services on COIN
platform are introduced. Possibilities to implement EI/EC services and potential benefits for other industrial areas
(food industry) are also discussed. Finally lessons learnt from taking part in consortium to research and develop
COIN and appropriate services are presented at the end of the paper.

Keywords: Enterprise Interoperability services, Enterprise Collaboration services, Supply Chain, Ordering-invoicing
processes
4.1.3.1 Introduction
Current state of Lithuanian SMEs could be defined as:
transitional to market intercourse with revolutionary changes in thinking, practices,
products, processes or organizations... [2], maintaining by young generation of businessmen
which has grown after Lithuania went out from Soviet Union, as well as stimulating by best
practices of western enterprises which became visible and available after Lithuania was join
with EU;
active implementing of newest technologies, including ICT, to keep European standards
and qualities and to withstand competition with advanced countries Lithuanian products and
services.
ICT-based technologies, ERP systems, accounting systems in local networks of enterprises
entrenched in Lithuania until 2000. Currently the quick Internet covers all Lithuania country
including rural areas; internet-based communication means (e-mail, Skype) replace traditional
inter enterprise communication means (mail, phone). EI/EC e-services [1], [3], [4] could be
welcomed, but such services are unknown and incomprehensible for Lithuanian businessmen.
These services could be introduced starting from the most advanced enterprises, and the most
helpful cases.
Considering before-referred state and tendencies an EI/EC Pilot in a Railways Supply Chain was
chosen. It should be noted that any other industrial area (food, garment, furniture, building trade,
etc.) could be chosen for Pilot; this choice was determined by high computerization level of VAE
Legetecha, variety business partners as well as close relationship with KTU (representatives of
KTU at COIN consortium are Legetechas ERP system developers and supporters). Use cases
for Legetechas Pilot were constructed and developed thus they could be applied in any other
industrial areas without crucial reconstruction. This is discussed in the last section of this paper.
4.1.3.2 JSC VAE Legetecha as the EC/EI Pilot
VAE Legetecha is a manufacturer of railway parts such as turnouts, base plates, crossings, etc.
[http://www.voestalpine.com/vaelegetecha/lt.html]. These railway parts are complex products,
have large amount of parts and are manufactured in series of stages. Some parts are bought from
suppliers, some parts are manufactured by VAE Legetecha and some are sent out to be modified
by other enterprises. Fragment of manufacturing process of VAE Legetecha is shown in Fig. 49


91
To create the EI/EC Pilot preproduction stage in Legetecha was analyzed, i.e. order receiving,
bill of materials and cost estimate making, orders to suppliers preparing as well as negotiation
process and preparation of agreements between customer and suppliers. Workflows of these
processes contains operations which can be replaced or reconstructed by EI/EC services, thus
preproduction processes can be improved in respect of time, quality and employment criteria. A
few use cases (UC) for testing were proposed and three of them which use essential COIN
services were developed:
Order (Legetecha acts as supplier) analysis and evaluation
Legetecha (acts as customer) orders from manufacturing partners
Order preparation and agreement signing (Legetecha acts as customer and supplier)

Raw material
suppliers
Service
suppliers
Buyer of
semimanufactures
Buyers of
final product
Railway parts manufacturer
JSC VAE Legetecha
Manufacturing
of parts
Assembling of
semimanufactures
Assembling of
final products

Figure 49 - Manufacturing process of VAE Legetecha (fragment)

COIN service called Collaborative Production Planning Portal (C3P) was chosen as central,
integrating entity in Pilot solution design. C3P service provides a platform where
manufacturing partners can easily join collaborative manufacturing process, invite other partners
and cooperate on the preparation of Production Plan, collaborate on ordering, manufacturing and
shipping exceptions and other issues common in manufacturing process.
In Pilot implementation C3P service is central point where all manufacturing partners meet, plan
their work and collaborate. All exchanges of business documents (production plans, orders, and
bills of materials) between ERP systems of supply chain partners are done through C3P services.
4.1.3.3 Use cases: gaps and services
3.1 Order analysis and evaluation. This use case starts when Legetecha receives order from
customer to produce final product. Legetechas sales manager transmits the order to internal
offices (design, production, financial, general manager) for initial estimation. If order was
preliminary accepted by these offices, Bill of Materials (BOM) and Cost Estimate is made and
negotiation process between supplier and customer starts. Use case ends when order is refined
and accepted as well as loaded into Legetechas ERP system. List of semimanufactures and
appropriate Technical Requirements (TR) for semimanufactures are prepared and loaded into
Legetechas ERP
92
Nowadays there is no electronic exchange of order document between customers and
Legetechas ERPs. Legetechas staff must manually enter it to their ERP system for evaluation
and planning purposes. From speed, efficiency and error rate point of view it is useful to use
COIN collaboration services to transform electronic order document from internal C3P format
(Universal Business Language (UBL) order format) into format supported by Legetechas legacy
ERP system and load this transformed document on demand to ERP system. Legetechas ERP
system is custom application based on traditional client/server architecture using Borland
Interbase Database Management System (DBMS). Preliminary orders from customers in this
system are represented by records in some relational tables. COIN service should be able to load
data from UBL Order document to corresponding records in relational database. The ERP
system is available for testing purposes, so COIN service can directly access database tables
using standard interfaces (JDBC, ODBC or BDE). Implementation of this services and new
model of activities into order analysis and evaluation processes could bring a growth of
productivity in this business stage at about 30%.
3.2 Legetecha orders from manufacturing partners. This use case starts when Legetechas
negotiation with customer is finished and all documents, i. e., BOM, list of semimanufactures
and TR for them, are prepared to start looking for suppliers of semimanufactures. Legetecha
starts with searching for potential suppliers, puts forward a proposal to potential suppliers and
considers received answers. Potential suppliers of semimanufactures analyze possibilities to
pursue the order confining all required conditions (TR, financial limitation) and to give ones
okay as preliminary agreement with customer what really is the postcondition of this UC.
Activities to search manufacturing partners and to prepare to negotiate contracts using COIN
services could reduce time of this stage from two weeks to 7 days, i.e. about 40%.
Two requirements for new services should be met in this use case:
Requirement 1. It should be possible to transform electronic order document from internal
C3P format (UBL order format) into formats supported by suppliers legacy ERP systems
and load this transformed document to ERP systems on demand. Two legacy ERP systems
used by Legetechas manufacturing partners were chosen. These ERP systems are Rivil
and Centas, widely used by many Lithuanian SMEs. Rivil is commercial application
developed in Lithuania using MS Visual FoxPro. For data storage it uses standard FoxPro
DBF files. This application also has special interface for import and export of business
documents and order is one of supported documents. Format used for import/export is
similar to XML, but does not follow all requirements of XML specification. This interface
could be used to import order documents from COIN C3P service. Rivil is available for
testing purposes as demo application with some restriction on functionality. Centas is
commercial ERP application developed Lithuania. For data storage it can use standard
Paradox DB files or work in client/server configuration using Advantage Database Server
DBMS. Most Legetechas partners are still using cheaper configuration using Paradox DB.
Preliminary orders from customers in this system are stored as records in several relational
tables. COIN service should be able to load data from UBL Order document to
corresponding records in database. Centas is available as demo version with limited
functionality for testing purposes. COIN service could directly access database tables using
standard interfaces (ODBC or BDE)
Requirement 2. COIN service should provide interface capable to convert production plan
and BOM document created in Legetechas ERP system to format compatible with C3P
services BOM format, and means for loading this document into C3P service on demand.
Legetecha is using its legacy ERP system to perform Material Requirements Planning (MRP)
and to find out time and quantity of required semimanufactures for final product. This
information would be useful for BOM preparation in COIN C3P service. Time and error rate
would be reduced if special interface capable of converting production plan information
residing in Legetechas ERP system to one compatible with C3P service is provided. BOM


93
document loading to C3P service would be also very useful. All related information in
Legetechas ERP system is stored as relational tables records, so COIN service can directly
access database tables using standard interfaces (JDBC, ODBC or BDE).
3.3 Order preparation and agreement signing. Preconditions of this UC are: BOMs and Cost
Estimate of final product, list of semimanufactures suppliers and preliminary agreements with
them are prepared and loaded into ERP of Legetecha. Until the start of manufacturing processes,
agreements between Legetecha and semimanufactures suppliers have to be signed by their
general managers. Preparing of final agreements, introducing it to general managers of all sides
participating in this business, and signing these agreements complete this UC and UCs
dedicated to pre-manufacturing stage scenarios at all.
The core of this UC is collaboration between Legetechas purchase/sales managers and
corresponding parties of customer and semimanufactures suppliers. They collectively discuss
orders and prepare corresponding sell/purchase agreements projects. General Managers of all
participating sides approves prepared agreements and sign them. If required, other working
groups, such as production or financial groups may take part in this UC. In this process many
discussion and document exchange sessions between management and technical working groups
may occur. These tasks are supported by COIN collaboration platform, using document
management system for document exchange and baseline collaboration services for instant
messaging, voice conversation, etc. Services to transform electronic order document from
internal C3P format into formats supported by suppliers legacy ERP systems and changes
between Legetecha and partners ERP should be repeatedly used. Expected benefits from
implementation of final order preparation and agreement signing services are time reduction of
this business stage to one week, i. e. about 42%.
4.1.3.4 Benefits for majority SMEs
Gathered use cases are typical in preproduction stages of majority industrial enterprises which
produce and sell any products in the local and international market. Generally objective benefits
can be evaluated only for particular cases. Looking for cases with valid benefit of EI/EC
services, we performed exploration of Lithuanian SMEs focusing on ones where replacement of
traditional communication means by EI/EC services could bring elimination of redundant staff,
equipment like office computers, phones, production costs as well as production and services
quality betterment, time economizing etc. Results will be presented in the wider reports or
research papers. Only some aspects which were observed looking for possibilities to attract an
attention of businessmen to ITC novelties for SMEs are mentioned here.
EI/EC services apparently demonstrate their benefits in food industry where hundreds of orders,
invoices and claims are running between every day food (meet, milk, bread) producers and
shops. Interoperability services could eliminate big part of staff engaged in ordering-invoicing-
claiming operations with their phones, computers and workplaces thus reducing mistakes and
total business costs. Benefits from implementation of interoperability services could be
calculated using simple arithmetic. Collaboration services can replace traditional communication
means and provides some benefits, main of which is time saving as well as respectively money
saving. Businessmen present number of facts from their business experience where delays
caused by bad communication bring big loss. That is why implementation of collaboration
services is useful and important for majority of SMEs. Usefulness of collaboration services and
loss warning can be established or determined by modeling where output parameters are possible
losses (decision making and action delay, profit, potential orders, entering a tender, and so on) as
well as input parameters (for example emerged by season or fashion demand of some goods,
growing of competition, prognosis of cost dynamics, information delay and so on). Analytical
model and modeling results as well as methodology to clarify possible benefit of EI/EC services
for SMEs will be presented in scientific conferences and papers.
94
4.1.3.5 Lessons learnt and conclusions
A number of meetings, workshops and discussions with businessmen to analyze current
problems on improvement their business activities using modern ICT helped us to understand
and gather needful e-services which should be developed looking at the next five-seven years.
The best practices of this will be useful in future working on new EC/EI scenarios for new
industrial and social areas on the COIN base.
COIN strategy and technological basis as well as participation in creation and testing of modern
e-services increased skills and provided knowledge which will be deliver to students and used in
the new projects and research works.
Working together with skilled partners of FP7 integrated project COIN consortium gave us a lot
of lessons how to solve collectively matured problems. This takes authors on trust to integrate
into new projects providing new skills and new ideas.

References
[1] Duin Heiko, Hofbauer Peter, Karacan mer, Markl Erich, Withalm Josef, Wlfel Walter, Zand Darius,
Collaborative Demand Capacity Planning, ICE2009 - Proceedings of the 15th International Conference on
Concurrent Enterprising. Collaborative Innovation: Emerging Technologies, Environments and
Communities. Leiden, The Netherlands, 22-24 June 2009.
[2] European Commission CORDIS, Future Internet Enterprise Systems (FInES) Research Roadmap, June
2010 [http://cordis.europa.eu/fp7/ict/enet/documents/fines-researchroadmap-final-report.pdf].
[3] Fischer Klaus and Zinnikus Ingo, Agent-Supported Collaboration and Interoperability for Networked
Enterprises, Proceedings of the 4th ATOP Workshop at the 9th International Conference on Autonomous
Agents and Multiagent Systems, May 2010.
[4] Karvonen Iris, Conte Marco, Supporting and facilitating the Enterprise Collaboration (EC) & Enterprise
Interoperability (EI) solution take-up, ICE 2010 16th International Conference on Concurrent Enterprising
Lugano, June 2010.


95
4.1.4 An EI/EC Pilot in a Construction Supply Chain (UPB)
Aurelian Mihai Stanescu, Mihnea Alexandru Moisescu, Ioan Stefan Sacala
1

1 University Politehnica of Bucharest, Faculty of Automatic Control and Computers
313 Splaiul Independentei, Bucharest, Romania, +40.21.4029167, ams@cpru.pub.ro mamihnea@gmail.com, sacalaioan@yahoo.com
Abstract
The paper is concerned with reporting the progress of the work done in the area of innovating services for
Collaboration and Interoperability within the Romanian Civil Engineering test case. The as-is situation in Civil
Engineering is presented with regard to the COIN objectives. The to-be situation, with regard to the implemented
COIN solution, is then addressed. The main focus of the to-be scenario is the two use cases: Use Case 1 - Order
construction materials from suppliers and Use Case 2 - Collaborative project planning and change management.
Identified business benefits are presented with regard to the proposed Value Reference Model within the COIN
project.

Keywords: Enterprise Interoperability, Enterprise Collaboration, Civil Engineering Domain.
4.1.4.1 Short Description of Civil Engineering Case, As-is situation
One of Romanias most important development directions is concerned with the development of
infrastructure facilities including highways, roads and bridges. Complementary to this direction
are major civil engineering private investments in the area of housing projects. There has been
an important increase in the demand for ICT services to support project collaboration and
management within the project consortium.
In this context, COIN collaboration and interoperability services along with the Generic Service
Platform will provide a solid development pillar for sustaining the development of
comprehensive ICT support facilities for the civil engineering domain development.
The as-is Romanian business case for civil engineering includes major government founded
infrastructure projects and a lack of ICT support to facilitate the implementation.
The as-is Romanian business case for civil engineering includes major public founded
infrastructure projects and a gap in ICT support to facilitate the implementation.
The civil engineering sector is characterized by a necessity of intercompany collaboration.
Such cases can include:
Consortiums of project development and management oriented companies formed to
undertake major construction projects.
Consortiums of companies which undertake subcontracted activities form large infrastructure
projects.
Civil engineering project planning
Special factors which influence the civil engineering sector include:
A highly multinational spectrum of companies in the area of consulting, project planning and
management.
Local companies involved in project execution tasks.
Highly regulated policies for public founded projects.
4.1.4.2 Objectives and Expectations from COIN
The to-be scenario will include the implementation of collaboration and interoperability
services providing the necessary ICT support.
The COIN innovative services for Civil Engineering will have an impact in the following areas:
96
facilitate the integration of Romanian SMEs within the European common Business
Ecosystem
facilitate the access to Romanian and EU business opportunities by providing Enterprise
Collaboration tools
promote the development of mixed European (including Romanian) SME networks by
providing Enterprise Collaboration tools
optimize border-less mixed SME networks by offering the access to Enterprise
Interoperability services
experiment and assess the project results into a developing Business Ecosystem using real
industrial and SME networks experiences.
University Politehnica of Bucharest (UPB) facilitates the demonstration of COIN innovative
services impact on Romanian Civil Engineering with the help of Digital Bit, a Romanian SME
partner in ARCHES Living Lab. Digital Bit is the ITC service provider for Astaldi Romania,
member of Astaldi Spa, a major contractor for the Romanian civil engineering infrastructure
projects.
To demonstrate the COIN innovative service impact, four business use cases have been selected
within the civil engineering projects: UC1: Order construction materials from suppliers, UC2:
Collaborative project planning and change management, UC3: Construction project monitoring,
UC4: Construction Planning for Civil Engineering. The first two use cases will be discussed in
this paper.

Figure 50 - University Politehnica of Bucharest COIN implementation strategy

4.1.4.3 COIN solutions identified and used
In this section two use cases will be discussed: Use Case 1 - Order construction materials from
suppliers and Use Case 2 - Collaborative project planning and change management
Use Case 1 - The use case starts when Astaldi opens a new construction site. In this context, in
order to acquire new materials, there is a necessity to buy new products. In order to select the
best supplier, the appointed project manager selects from 2 collaborative services the needed
materials according to the suppliers description and competences / ontology for profiling and
matchmaking, using collaborative service. The acquisition department and the suppliers work in


97
a safe and secure environment, using Trusted Information Sharing Service. The use case ends
with the selection of the best offer from the suppliers.

Figure 51 - The process of ordering materials from suppliers

The innovative services selected for ordering the construction materials from the suppliers are:
Enterprise Collaboration Services: Semantic Cluster Management Service (SCMS), used in
choosing the materials from a list of suppliers; Online Meeting Service (OM) and Trusted
Information Sharing (TIS), used for contract negotiation in a secure environment
Enterprise Interoperability Services: Enterprise Semantic Matchmaking Service (ESMS) used to
facilitate the search for the right supplier and Enterprise Semantic Profiling Service (ESPS) used
for defining the profiles of suppliers.
Use Case 2 - The use case starts with the necessity to collaborate on the project planning phase.
After developing the project plan in a collaborative way, the project manager and the company
management discuss all the problems and the risks using collaborative services. After all the
changes have been done in the project plan, the plan is finalized.

Figure 52 - The process of collaborative project planning and change management

The services selected for collaborative project planning and change management are:
Enterprise Collaboration Services: Collaborative for Project Management (Coll4PM) enable the
project manager and the enterprise management to realize the project plan in a collaborative
manner.
98
Coll4PM + new service will enable for the project manager to: monitor the entire evolution of
the project in real time, implicate the entire management team in the development of the plan,
monitor the entire evolution of the project, modify the project plan in real time and notify the
persons involved.
4.1.4.4 Measured Business Benefits
In order to measure the business benefits a series of Key Process Indicators have been identified
for each use case, using the Value Reference Model as developed within COIN project:
Use Case 1 includes processes in the area of Planning and Supply Chain regarding the
assessment of resources. The identified indicators are used to assess the impact of requirements.
The measured indicators refer to the elapsed time for the cycle of a given process, cost for a
given process and frequency of planning analysis as a measure for adaptability.
Use Case 2 includes processes in the area of Create Plan, Supply Chain. The identified
indicators are used to assess the course of action regarding supply chain planning. The measured
indicators refer to the value of assets dedicated to a specific process, total cost and elapsed time
of a specific process.
Several business benefits have been identified with reference to the COIN results:
Business Benefit #1 Reduce time for ordering products from suppliers
There is no electronic platform in ordering the construction materials from the suppliers. All the
materials are ordered by phone or by mail from a list of suppliers and all the offers are received
by fax. The communication is slow and the time in receiving the materials is very long.
Therefore, the need of COIN services is more than necessary to facilitate the communication.
Business Benefit #2 Improve efficiency of co-operation process for project planning
There is no electronic platform in creating the project plan in a collaborative way and the status
of the project cannot be monitored. If any change appears, the project manager acts instantly,
based on his experience, with no pre-planned steps.
Business Benefit #3 Reduce time for project monitoring and reporting
The project manager monitors the execution of project plan by on-sight inspection and
collaborative services.
Business Benefit #4 Improve efficiency of construction planning
The project manager uses collaborative services to develop the construction plan and to establish
or modify deadlines.
4.1.4.5 Conclusions
The presented use cases and services are currently being implemented in order to experiment and
demonstrate the COIN system and EI/EC new developed innovative services. The
implementation of COIN services has been planned according to the developed COIN
methodology for enterprise collaboration and interoperability. The conclusions identified during
this implementation stage prove the efficiency of the COIN collaborative and interoperability
platform in solving the identified problems within the civil engineering sector.

References
[1] Stanescu, A.M.; Ionescu, L.M.; Georgescu, V.; Badea, L.; Moisescu, M.A.; Sacala. I.S.; (2010) Toward
Digital Business EcoSystem Analysis In Gunasekaran,A.; Sandhu,M. (Eds): Handbook On Business
Information Systems, World Scientific Books, 2010
[2] Stanescu,A.M.; Dumitrache,I.; Pouly, M.; Caramihai,S.I.; Moisescu,M.A; (2007) Towards a General
Systems Theory approach to design the future of Concurrent Engineering Science, In Loureiro,G.;
Curran,R.; (eds.) Complex Systems Concurrent Engineering Collaboration Technology Innovation and
Sustainability, pp 3-10, Springer Verlag 2007


99
4.2 The COIN EI/EC Services in Collaborative Networks
Nowadays, it is usual to find business processes and situations in which several parties need to
collaborate in order to achieve common objectives. These collaborations require a good level of
understanding between different parties, as well as collaborative tools which enable and facilitate
communication and interaction in different moments and activities of the business process.
One of the objectives in COIN is to enable enterprise collaboration by creating a set of services
which will be invoked during the business process execution. These services are mainly focused
on solving two problems: improve the understanding between different parties and enabling the
direct collaboration working together.
Some of the COIN partners defined and implemented four scenarios where enterprise
collaboration was a key aspect in order to carry out the activities in business processes: an
aeronautics cluster, an ICT cluster, a marine shipping network and a logistics network. In all the
mentioned cases, COIN services were applied where collaboration was necessary at different
levels. 3D collaborative design, document sharing, communication and collaborative
visualization services were used, highlighting the role of the semantic mediation services,
improving collaboration in each case. This chapter explains in detail the context and scenarios,
and how COIN solved the problems found.

100
4.2.1 An EI/EC Pilot in Andalusia Aeronautics Cluster (ISOIN)
Jess Snchez, Alberto Olmo
1

1Ingeniera y Soluciones Informticas, ISOIN
Abstract
The Andalusian Aeronautic Cluster, one of the Spain's main aerospace production regions, promotes research and
innovation processes, supporting enterprise collaboration as a core part of the regional Strategic Plan for the
evolution of the Cluster. The participation in COIN is considered a key step towards the collaborative networked
business vision, as an effective instrument to enforce this positive evolution and increase its competitiveness in the
global market. Indeed, COIN has shown to be really useful in supporting collaboration and interoperability services
for the networked enterprises, designing and developing a pervasive, adaptive Service Platform to host Baseline and
Innovative COIN services, and demonstrating and assessing the project results into realistic Industrial Scenarios. The
application of the SaaS business model overcomes some of the problems encountered in previous software
implementations, helping companies to adapt a new tool, with the necessary reduction in time and costs for the
implementation.

Keywords: Collaboration, Interoperability, Aeronautics, SaaS.
4.2.1.1 Introduction and background
The Andalusian Aeronautic Cluster has a consolidated position in the European aircraft Industry,
operating since 1930. Strategic projects strengthen the importance of Andalusia as one of the
Spain's main aerospace production regions, such as production of structural components of the
A380 program and the final assembly of all-new A400M military aircraft. Besides the final
assembly line, the excellence centre in sheet metal production and composites are the key
services provided to the aeronautic industry.
The Aeronautic Cluster of Andalusia brings together prime contractors of the aeronautic world
with about 125 subcontractors and supporting entities (Universities, Research Centres and
Regional Government). Most of the companies are located in the provinces of Seville and Cadiz
at the South of Spain. The main prime contractors of the cluster are EADS-CASA and AIRBUS,
although other prime contractors like BOEING, EUROFIGHTER, EMBRAER or
BOMBARDIER are also starting businesses activities with the companies of the cluster [6].


101

Figure 53 - The Andalusian Aeronautic Cluster main competences and entities.

The cluster main goals are to increase and to diversify its activities, attracting a higher number of
prime contractor companies or counting with Tier 1 Andalusian companies. Another important
objective is increasing the productivity with the coordination of innovation activities among the
cluster companies. The advanced Virtual Organization paradigm is pursued, in order to increase
process efficiency and collaboration opportunities while fostering innovation in a sustainable
structure [9].
4.2.1.2 Collaborative network creation and current management overview
The network has established collaboration initiatives since its origin, evolving to the current
situation (structured as a Foundation, 2002) promoted by the Regional Development Agency to
foster collaboration activities and improve the cluster competitiveness in the European aeronautic
market. The regional aeronautical sector has dramatically multiplied the number of companies,
personnel and turnover, increasing to 125 companies, 6206 employees 850 million Euros.
The entities related to the aeronautic sector currently operate under an Extended Enterprise
model, with common supporting ICT infrastructure, derived from an ERP model (SAPECMA
and SAPORTAL), together with methodologies, services, and tools for facilitating the delivery
of supplied parts [8].
ISOIN promotes research and innovation projects in the cluster, supporting collaboration
processes together with Hlice Foundation [5]. Its activities in the context of the regional
Strategic Plan for the evolution of the Aeronautic Cluster of Andalusia cover:
Definition of the technological capabilities and readiness for the evolution to the advanced
networked structure, as a key factor to achieve world-excellence in the global market.
Definition, launch and execution of research and development activities to foster innovation
in the cluster,
Provision of suitable infrastructure to match collaboration demand and offer, based on
collected competencies and availability.
102
COIN [1] continues currently with this vision, supporting collaboration and interoperability
services for the networked enterprises, designing and developing a pervasive, adaptive Service
Platform to host Baseline and Innovative COIN services, and demonstrating and assessing the
project results into realistic Industrial Scenarios offered by 6 test cases among which it is
included the Andalusian Aeronautic Cluster [9] [4].
4.2.1.2.1 COIN Service Test
Workflow creation
The test phase involved the evaluation of COIN EC/EI innovative services. Four workflows have
been created to support this phase. The workflows were called tailored because they are directly
derived from scenario uses-cases.
ProcessMaker [2], an open source business process management software and workflow
software, has been used for developing the four workflows. These workflows derived from real
use-cases gave values to several indicators measured concerning business performance. COIN
services have been added to the workflows and, this way, the business context has been taken
into account into the innovative tools. This has given the possibility to understand the possible
business benefits of theirs usage inside the end-users environment, making easier the indicators
measuring, once that COIN has been used in the cluster.

Figure 54 Workflow example

Analysis of requirements and services selection
There is a need for the Andalusian Aeronautic Cluster to be open to other prime contractors,
other clusters and other business opportunities. It is necessary to have a collaborative product
development portal, where products and services of different clusters, companies and prime
contractors are offered, in order to find the best partners to develop a product.
As a way to increase collaboration inside the cluster, and with other external clusters and prime
contractors, a formalised description of companies, competences, services, products and
documentation is required. This is necessary to enable exchange of information about products


103
and services, and searching for existing knowledge, in order to enable the possibility of reusing
this information for new projects.
There is also a need for an online viewer for aeronautic products, open source software or
software as a service which can perform an historic version control of aeronautical product 3D
designs, enabling on-line annotation, and linking these functionalities with project management
tools.
In the Aeronautical Cluster of Andalusia, 3D design process is mostly performed with CATIA
and ENOVIA, standardized by AIRBUS to the companies in the cluster. This makes it difficult
for another company to work without these proprietary formats in the cluster.
Aeronautical companies find particularly useful these tools. Interoperability of 3D format and
online access to these services are ranked as the most interesting functionalities. Online
annotation is also seen as particularly useful for working with a 3D design. It was also suggested
by the companies that these services were associated with the tasks of project management.
Some of the innovative COIN services studied are:
Semantic Cluster Management System
The objectives of the Semantic Cluster Management Service (SCMS), in relation with the
Andalusian Aeronautic Cluster, are to provide:
o Have access to the entire set of products, services, companies that exist in the in
the cluster, in order to speed up the process of setting up a collaboration with the
right partner online and using SaaS, avoiding the installation of proprietary
database software.
o Semantic search for products or services that are needed in the product
development process, based on the product structure ontology.
o Semantic search for companies that provide the required product / service in a
product development process, taking into account related competences.
o Semantic search for products or services that exist in the cluster, giving the
possibility to the end user to rank them, and propose new requirements or new
business opportunities.
Collaborative 3D designer Service
With Collaborative 3D Designer Services (C3DDS) prototype, the following specifications have
been addressed, taking into account the needs of the Andalusian Aeronautic Cluster:
o Online viewing of 3D files, including a wide variety of formats.
o Web service architecture, avoiding the need to install software and contributing to
collaborative processes, making use of SaaS advantages.
o Online annotations, to enable virtual meetings to comment 3D designs
development.
o Historic of annotations and author of annotations, to enhance the product
development process.
Interoperability Spaces
With Interoperability Spaces problems of interoperability in the negotiation of contracts and
problems with different formats in documents is addressed:
o Allowing online negotiation of contracts among companies of the cluster that
want to set up a VO.
104
o Speeding up the negotiation process among companies inside and outside of the
cluster. This way is possible to reduce the loss of time in such kind of process,
which are very common in the cluster.
Semantic Reconciliation Suite
With Semantic Reconciliation Suite (SRS) the aim is to provide functionalities for document
format reconciliation, aiming to the cluster requirements in:
o Exchanging orders and invoices in different formats, a very usual problem
occurring in the Andalusian Aeronautic Cluster.
o Conciliating different ERP systems used by different companies inside the cluster
and allowing the exchange of documents with different formats among them.
o Conciliating different ERP systems used by different companies outside the
cluster and allowing the exchange of documents with different formats among
them.
Cross-organizational Business Process Interoperability Gap Detection Service
The aim of Cross-organizational Business Process Interoperability Gap Detection Service
(CBPiP) is to analyze and detect interoperability gaps (deadlocks, interface mismatches) in cross-
organizational business processes. This SaaS tool addresses the following cluster needs:
o Scanning the CBP processes (xPDL file) of companies.
o Detecting deadlocks based on flow analysis of the CBP processes.
o Analysing MessageFlows where documents are exchanged between companies.
o Detecting interface Mismatch based on analysis of MessageFlows.
o Allowing the companies to check the compatibility of their processes before
starting business collaboration.
The most important feature comes from the application of a SaaS business model, which
overcomes some of the problems encountered in previous software implementations, namely the
difficulty of companies to adapt a new tool, with the costs and time needed for that purpose

Figure 55 - Some COIN Innovative services tested. Collaborative 3D designer service (left) and
Interoperability Spaces (right) have been tested, for product design and contract negotiation, respectively

4.2.1.3 COIN experience in the Andalusian Aeronautic Cluster
Some of the competitive advantages and benefits COIN has preliminarily shown into the
Andalusian Aeronautic Cluster are:
Openness for the cluster, to other prime contractors and other business opportunities.
Relation with other clusters.
Open call for tender processes. Competence selection of partners.


105
SaaS business models used in software implementation reduce costs, time and difficulty for
companies in the use of new services. Some examples are:
o Percentage demand-offer matched (the percentage of offers that a company can
access successfully) increases.
o Time to set up a VO is reduced, with the use of services to search for partners.
o /Project in the quotation and performance of the project decreases.
o Fixed costs are reduced, due to the fact that companies can collaborate remotely.
o Time/project is decreased in all phases.
The ROI (Return on investment) is significantly increased, due to the following reasons:
o The value of investment in SaaS business model is not high.
o The benefits obtained are improved, as can be deduced from last points
Increase collaboration in business opportunities among companies, sharing valuable
information without neglecting security.
Increase communication between companies, University and research centres.
Increase Interoperability among companies of the cluster and outside the cluster, facilitating
the use of these services to the end user. SaaS can use accepted standards in aeronautics and
by main software developers, enabling the integration of applications and platforms.
4.2.1.3.1 Measured business benefits
Selected COIN services have been tested after the development phase performed, with following
the generic conclusions. After analyzing the different COIN services results and their relation
with the workflows in the Andalusian Aeronautic Cluster and the business involved in it we can
conclude about the processes and indicators:
A relevant number of indicators relevant to the cluster can be improved with the use of
COIN services, being the most important ones:
o Number of companies that have access to a BO
o Time spent in partner search and forming a VO
o Time needed to process an order or invoice
o Reduction in errors / complaint per project
o Cost reduction in product development
In the following table the summary of the different performance indicators, with the as-is and
foreseen to-be situation are summarized.
106
Table 4 - Foreseen benefits of COIN use in the Andalusian Aeronautic Cluster














Some of these indicators have already shown improvements when using COIN services within
the cluster, however its still needed more testing to reach the foreseen benefits shown in the
Table 4.
4.2.1.3.2 Lessons learned
Apart from the innovation shown by COIN services in the first tests beds developed in the
Andalusian Aeronautic Cluster, the success in many cases will depend on the maturity, risks and
reduction of costs when using the specific tool and the entire COIN platform.
The Andalusian Aeronautic Cluster has shown an increased investment in R&D year in, year out,
mainly in the auxiliary companies; this investment has seen its trend changed after year 2008, but
it improved again its figures in the last year. In 2010 the indicator related to the R&D investment
of the auxiliary companies of the cluster shown the best values ever within the cluster.
Indicator 2009 2010 Rate (%)
% R&D Investment / Turnover 4,3 9,0 109,3

However, in comparison with all the activities performed by the clusters companies, the R&D
sector still has the lowest growth rate in the latest years. The figures of this R&D activities have
risen only 0,2% since the 2009 (taking into account the number of employees), so this situation
represents that in the Andalusian Aeronautic Cluster is still not as open as it would be desired [3].
Several issues have arisen when integrating COIN services with legacy systems from the cluster.
The lack of openness in some legacy systems doesnt permit COIN to show its real performance,
as for example in the case of the private portal of the main contractor of the cluster, where
business opportunities are published and communication among the main contractor and other
companies of the cluster is held through private services.
Should COIN being run completely integrated within the companies processes and services, this
will provide real feedback about its improvements in the Andalusian Aeronautic Cluster. This
way, the previous indicators shown in Table 4 will provide real values of the results expected.
An analysis of the Andalusian Aeronautic Cluster presents advantages towards the COIN vision,
as the listed below:
Metric Typology AS-IS Foreseen Benefits
Number of companies / BO 22 50%
% demand-offer matched 10%
30%
Time reduction to send a VO quotation 10 d
8%
Reduction of time for partner search 7 d 8%
Time to send/receive an order 8 d
12,5%
Time to send/receive an invoice 15 d 50%
Invoice errors / project 4
25%
Number of complaints / project 9
36%
Cost reduction in Product Development - 5%


107
o The sector is very specific, and the industrial network is more than 100 years old
in the region.
o Three main long-term projects assure the continuity of the activities in the cluster.
o Six airports within the region, being two them high-capacity ones.
o Positive growth rate in the sector every year since its beginning.
On the other hand, some disadvantages came up with this analysis, and they could have direct
consequences in the future adoption of COIN system and platforms [7]:
o Technological profiles of the auxiliary companies need improvements.
o The size of auxiliary companies presents limitations and their activities are
affected by these.
o Low number of alliances among the auxiliary companies.
o Low private investment in R&D activities.
In many cases, the future exploitation and use of a service will depend on the refinement and
consolidation of the services, with individual contracts between companies interested and
developers.
The success of other services will also depend on the overall adoption of the platform, and the
number of customers that will finally use it. This will be properly addressed in final assessment
phases.
4.2.1.4 Conclusions
The Andalusian Aeronautic Cluster continues promoting research and innovation projects in the
cluster, supporting collaboration processes with research projects such as FP7 COIN.
These new business models, based on Software as a Service bring the following benefits to the
Andalusian Aeronautic Cluster:
New Business Opportunities
Openness of the cluster to other prime contractors and other business opportunities, which will
access to the published services of companies. Open call for tender processes, with competence
selection of partners and relation with other clusters.
Costs reduction due to interoperability
Interoperability of formats will suppose a cost reduction as long as the formats are compatible
with the aeronautical standards used by prime contractors.
Increase of project profitability
Project profitability will increase, as the companies will not have to change their ERP tools,
having the support of software developers to use the collaborative and interoperability web
services, reducing costs of implementation and training.
Increased turnover, due to the previous mentioned facts.

References
[1] COIN project (FP7 IP 216256). COllaboration and INteroperability for networked enterprises. 2008.
www.coin-ip.eu.
[2] Colosa, Inc. ProcessMaker Workflow Simplified. 2011. http://www.processmaker.com/.
[3] Fundacin Hlice. Sector Aeroespacial Andaluz Informe estadstico 2010. Sevilla, 2010.
[4] Galeano, Nathalie, y otros. VBE pilot demonstrators. En Methods and Tools for Collaborative
Networked Organizations, de Luis M. Camarinha-Matos, Hamideh Afsarmanesh y Martin Ollus, Part 6.
Springer, 2008.
108
[5] Ingeniera y Soluciones Informticas S.L., ISOIN. COIN: collaboration and interoperability for greater
competitiveness in the Andalusian aeronautical sector. Aeronutica Andaluza. Sevilla: Fundacin Hlice,
Septiembre-Diciembre de 2009.
[6] Junta de Andaluca. Datos del sector Aeronutico en Andaluca. 11 de Diciembre de 2009.
http://www.juntadeandalucia.es/compromisos20082012/principal_noticia.php?id_noticia=4046.
[7] Junta de Andaluca. Programa de Accin Sector Aeroespacial 2010-2013 Sevilla, 2010.
[8] Parque Tecnolgico y Aeronutico de Andaluca, Aerpolis. Fundacin Hlice. 2009.
http://www.aeropolis.es/opencms/opencms/es/serviciosAvanzados/fundacionhelice/.
[9] Romero, David, y Arturo Molina. Virtual organisation breeding environments toolkit: reference model,
management framework and instantiation methodology. Production Planning & Control 21, Issue 2
(2010): 187-217.


109
4.2.2 An EI/EC Pilot in The Hungarian ICT Cluster (IND)
Szabolcs Ktai (IND/IVSZ), Zoltn Mzes (IND)
Abstract
IVSZ, acting as an end-user business network, has participated at an FP7 research project - COIN - which intends to
develop supporting software services in a networked environment. IVSZ role was to provide business requirements,
follow the development process and test the services developed. For this purpose IVSZ has chosen one particular
innovative project - the "developing other industry relations and market development" project - and defined two test
cases which can demonstrate the potential benefits of some EI/EC innovative services developed in the COIN
project. In the test process three COIN service classes were tested, namely Collaborative project management
services, Collaborative human interaction services and Knowledge interoperability services. It has been shown that
these services can effectively increase productivity and intensify the involvement of members in the business
network.

4.2.2.1 Introduction
4.2.2.1.1 IVSZ
IVSZ, the Association of Hungarian IT, Communications and Electronic Companies was
founded in 1991. By today IVSZ has grown to be the only major ICT National Trade
Association in Hungary. With more than 300 members - composed of SMEs, large Hungarian
companies and multinationals representing over 70% of the total annual output of the Hungarian
ICT sector - it represents the interest of the Hungarian information, communication technology
and electronics sector.
4.2.2.1.2 The IVSZ Innovation Programme
The IVSZ Innovation Program was launched early 2007 with the purpose to bring together and
support those Hungarian innovative ICT companies that see the key of their competitiveness in
continuously developing products and services and they actively do act for this goal. Two main
objectives were identified: "innovation capability building" and "developing an innovation
friendly market environment, market development".

A number of activity areas - many of them involving collaborations - were defined [1] and
implementation of some of these has started in the IVSZ Innovation Working Group composed
of more than 40 IVSZ member companies.
4.2.2.2 Business Case Description: The IVSZ test case
4.2.2.2.1 ICT industry background
The ICT industry is one of the fastest developing industry sectors, wider and wider utilization of
info communications technologies is the main tool for economic growth, increasing
competitiveness as well as better life quality. The European Commission estimates that roughly
50% of [2] all economy growth originates from ICT. As for the future, ICT technologies
penetrate more and more into everyday life as well as in all different industry sectors.
Consequently ICT continues to be a primary growth sector - especially taking into account that
ICT is one of the most innovative industry sectors.

ICT industry has a multiplicative effect, which means that all other industries where ICT
technologies are used become more competitive as a result of efficiency gains among other
factors.
110
4.2.2.2.2 Business case background
The argument that ICT technologies are enabling technologies for other industries is a very
strong one. Intuitively, this is felt by the majority of professionals and on a large scale
demonstrated in many industries [3]. However, on a smaller scale this needs to be demonstrated
at a practical level. This is not a very easy task, however, it also provides opportunities for those
being able to demonstrate this.

The above line of thought has lead to the emergence of an IVSZ project within the Innovation
programme. This project is called "developing other industry relations and market development",
and aims at turning the above statements into practice and provide opportunities for smaller
companies as well in order to increase the ICT penetration in a number of industry segments [4].

In the earlier phase of the project the methodology for the process of creating new business
opportunities for ICT companies has been defined. The process has the following phases for each
industy approached

Bringing together clusters from ICT and the other sectors
Understanding each other and existing challenges
Exchanging information on experiences and knowledge
Defining ICT based innovation projects

This process aims not only at encouraging the establishment of business contacts on a one-on-
one basis, but also on a cluster-to-cluster basis, elevating the conversation and understanding to
the industry level. This innovative approach provides far larger benefits than the traditional one-
on-one approach, if successful.
4.2.2.2.3 Challenges and COIN expectations
However, we find several challenges when successfully implementing this methodology.
Though the process steps do not seem very difficult, working at a collective level is far more
complex than working at an individual level. Figure 56 shows the identified challenges and the
expectations about how the COIN project [5] supports overcoming these challenges.

Figure 56 Challenges and COIN Expectations

The COIN services which implement the solutions for the IVSZ challenges can be grouped into
three of the COIN service classes:


111
Collaborative project management services
Collaborative human interaction services
Knowledge interoperability services

For the exploration of the possible support that COIN services can provide, five business use
cases have been developed and from these two test cases have been set up.

One of the test cases describes the process of creating a project group for cooperation with
another industry organisation. This case has the goal to initiate a new project, where there is an
interest for forming a new group to explore potential business relations with a group of
companies from another industry segment (other than ICT). Currently, many of the activities in
this test case are performed manually, dominantly using knowledge "in the head" of project
managers. The expectation using COIN is that the process becomes partly automated and some
knowledge is externalised, becoming available within the network.

The test case involves services from all three COIN service classes, namely the "Collaboration
for project management" service, the "Collaboration visualisation tool" and the "Enterprise
semantic matchmaking service".

The other test case describes the process of creating and updating an ICT Ontology and company
semantic profiles. This case on the one hand has the goal to create - or at an annual or semi-
annual basis update - the ICT ontology used to describe the competencies and experiences in the
IVSZ network of companies. On the other hand, it has the goal to create and regularly update the
company profiles. Currently this process is done manually and requires great effort from IVSZ
member companies. As it is a tedious exercise, IVSZ members are relluctant to update profiles,
so information is not updated or it is missing, leading to mismatches and waste of time. The
expectation is that the process becomes partly automated and that the workload of IVSZ member
companies greatly decreases.

The test case involves services from the knowledge interoperability service class, namely the
"Social ontology building service" and the "Enterprise semantic profiling" service.
4.2.2.3 COIN solutions
4.2.2.3.1 Project initiation test case
The test case focusing on initiating a new project involves dominantly two types of activities.
One is to find potential companies which are expected to be interested in the particular intustry
segment that the new project intends to focus on. The other is to involve these companies
effectively into the project.

For the support of the search type of activity, the COIN Enterprise Semantic Matchmaking
service is integrated into the test case. This service provides a semi-automated company
recommendation solution based on semantic keywords of an ICT ontology. In order to utilise this
service, the prerequisite is that an ICT ontology needs to be built and company semantic profiles
need to be created.

112
For the support of the involvement type activity, the COIN Collaboration for Project
Management service and the COIN Collaboration Visualisation tool are integrated into the test
case. These tools make it easier for companies selected by the project manager to communicate
with each other, to look at what other IVSZ members are involved and how they relate to these
companies. Such services encourage the active involvement of companies by pointing out
potential partnerships right from the beginning and by increasing the level of trust withing the
group under formation. The prerequisite for the Collaboration Visualisation services to operate is
to build a database of inter company communications.
4.2.2.3.2 Creating/updating ontologies and company profiles test case
The test case focusing on creating/updating an ICT ontology and company profiles is in fact a
"back office" service providing the background information for other IVSZ services. It involves
analysing company information, extracting keywords and arranging these into an ontology.

For the support of the ontology creation the COIN Social Ontology Building Service is used.
This tool makes the analysis of information about a large number of IVSZ member companies in
a semi-automated way, and provides an effective tool for the collaborative creation of an
ontology, which utilises the business knowledge of several professionals.

For the support of the company profiling, the COIN Enterprise Semantic Profiling service is
used. This tool provides a semi-automatic method to create a profile of an IVSZ member
company, which a project manager is able to do. This alleviates the need to ask each IVSZ
company member to create/update their own profile and reduces this task to asking them to
check that their profiles are correct.
4.2.2.4 Results and Business Benefits
For the evaluation of the effectiveness of the COIN solutions they were integrated into the
processes of the "Developing other industry relations and market development" project. This also
involved the integation of these services with the existing IT systems of IVSZ where necessary.
Results were evaluated from two points of view.

One point of view was the business benefits that COIN services can provide to IVSZ when
applied to the IVSZ processes. The semi-automation of processes accelerates these processes and
at the same time allows more systematic selection based on a broader selection base. The
enhancement of communication and the provision of more "pre-digested" information allows
more efficient communication and information seeking. These result in time savings in the
processes and, even more importantly for IVSZ, in a better involvement of member companies
and a feeling of higher satisfaction from IVSZ services. The possibility of integrating different
COIN services provides potentially cost savings.

The other point of view was the current "business-readiness" of the COIN services. From a
technical perspective, it seems that - contrary to the fact that these services have been developed
within the framework of an FP7 research project and thus concentrate more on developing new
technology and less on developing market-ready products - services show considerable values
not only in their technology background but also in their usability. Nevertheless, different
services are at different levels of readiness and can benefit from further development at the late
stage of the COIN project. Regarding usability or user experience, services are on a good track,
however, easiser integration into existing company systems could increase adoption. Services
effectively support cooperative working, nevertheless, more automated processes would further


113
increase productivity. In order to encourage the widespread adoption in a multilingual Europe,
the extention of multi language support would be beneficial.
4.2.2.5 Conclusions
IVSZ, as a professional association and a business network in the ICT industry domain, tested
software service prototypes designed for collaborative working in a software as a service
environment. It has been concluded that the services which were tested within the IVSZ test
cases can potentially provide tangible benefits both for the association itself (ie. the network
manager organisation) and for the individual members of the network as well.

The test example of the "Developing other industry relations and market development" project,
in particular, can potentially benefit from COIN services by gaining tools to better assess, reach
and mobilise IVSZ member companies (through a faster and more systematic partner selection
process and through more efficient communication tools), to reduce organisational processes
duration and costs (through (semi-)automatic information analysis tools and through
collaborative working tools).

From a technical perspective, it seems that COIN services show considerable values not only in
their technology background but also in their usability. Nevertheless, in order to develop these
into fully market ready services a number of factors still beed to be considered. Technically such
factors include for example robustness, scalability, ergonomy and multilinguality. From a
business perspective such factors include for example business model, maintenance services and
legacy integration services.

In addition to the particular benefits gained from the COIN system, by participating in this
project, IVSZ has been confronted with a number of innovative technologies for enterprise
collaboration as well as with several other collaborative groups. This has allowed IVSZ to gain a
better understanding of collaborative working environments, challenges and opportunities. The
IVSZ Innovation group will have an opportunity to improve its own operations towards
becoming a better service provider to its own members. As IVSZ participates in several "national
technology platforms" (eg. NESSI HU, Artemis HU, Multimedia and Mobility), these practices
can be communicated towards these as well.

References
[1] IVSZ Innovation program (in Hungarian): http://ivsz.hu/tagsag/munkacsoportok/innovacio
[2] European Commission: i2010- First Annual Report on the European Information Society, Brussels May
2006
[3] "A transformational agenda for the digital age - DIGITALEUROPE's vision 2020", DigitalEurope, 2010
[4] "Other industry marketdevelopment program" (in Hungarian), http://ivsz.hu/projektek/hazai-projektek/mas-
iparagi-piacbovites
[5] COIN project (FP7 IP 216256). www.coin-ip.eu
114
4.2.3 An EI/EC Pilot in a Marine Shipping Network (UCY)
Achilleas ACHILLEOS, George SIELIS
and George PAPADOPOULOS
1

1

Department of Computer Science, University of Cyprus,
Nicosia, 1678, Cyprus
Tel: +357 22 892700, Fax: + 357 22 892701
Email: {achilleas, sielis, george}@cs.ucy.ac.cy
Abstract
The COIN platform allows exposure, combination and integration of interoperability and collaborative services for
their application to specific business domains. The objective is the exploitation of the COIN platforms technological
capabilities and services to the Cyprus maritime shipping sector; together with our industrial partner Donelly Tanker
Management. In particular, two highly suitable business use cases have been identified on the basis of which the
pilots have been developed using the COIN platform and the provided COIN services. The development of the pilots
demonstrated how the COIN platform and its offered services can aid in simplifying and expediting the processes of
the maritime shipping domain. On the basis of the pilots initial results are presented in this chapter.

Keywords: Enterprise Interoperability, Enterprise Collaboration, Civil Engineering Domain.
4.2.3.1 Introduction to Cyprus Shipping Sector and Business Use Cases
The contribution of the shipping industry to the Cyprus economy is as high as 5.5% of the Gross
Domestic Product (GDP) ship management and ship owning combined, a value higher than in
most other European countries [6]. The Cyprus Registry is classified as the 10th largest merchant
fleet globally and third in the European Union, with approximately one thousand shipping
vessels; gross tonnage in excess of 19 million [6]. Limassol is considered to be the largest third
party ship-management centre in the EU and one of the largest in the world (in excess of 130
ship-owning, management and other shipping related companies maintain offices there). The
European merchant fleet capacity was significantly increased upon Cyprus accession to the EU,
with the island contributing 15% 25% of the EU fleet [8]. Among the ship-
owning/management companies established and operating in Cyprus, it is estimated that 87% are
controlled by EU (including Cypriot) interests. Approximately 4.500 persons are employed
ashore and 40.000 seafarers of different nationalities are employed onboard vessels controlled
and/or managed from Cyprus [6].
The distributed nature of partners involved in the marine shipping domain and the complexity of
managing such processes calls for technological developments that will simplify these processes
and reduce the time required to carry out this processes. For this reason, two business use cases
have been identified and the developments necessary for building the pilots using the COIN
platform and services were performed. The first use case describes the actions undertaken by
DTM and other parties (e.g. charterers) to complete the voyage pre-fixture. Initially pre-fixture
queries, a prerequisite for the voyage fixture establishment and completion, are issued and
subsequently standard documents (i.e. standard charter party forms) are formulated after
negotiations between United Product Tankers (UPT) and charterers. The outcome of these
negotiations is a recap document, containing details of the cargo such as laycan dates,
loading and discharge ports and speed advisories. Once formulated, the recap must be made
available to the vessels captain for any final queries or clarifications.


115

Figure 57 - Use Case 1: Formulating the Recap Pre-Fixture Document

Figure 57 shows in the form of a UML use-case diagram the aforesaid tasks performed for
formulating the recap pre-fixture document. As illustrated in the figure, the Charterers and UPT
(United Product Tankers) negotiate the standard charter party forms in order to produce the recap
document. The recap document is then distributed to DTM who in turn sends this to the vessels
captain for any outstanding clarifications or queries. Using the recap, DTM may already instruct
the captain of the ship to begin the voyage towards the general geographic area identified (e.g.
Eastern Mediterranean). At this point DTM will request precise voyage orders that contain more
specific details, such as the specific load/discharge ports, details regarding the cargo (e.g. exact
tonnage) as well as issues like draft restrictions at the load port (e.g. depth of port).

Figure 58 - Use Case 2 Creation and Settlement of the Proforma Disbursement Account (PDA)

The second business use-case refers to the process executed so as to formulate the Proforma
Disbursement Account (PDA). The PDA details the estimated costs that a Port Agent will have
to pay for the vessel to have a smooth and quick turnaround at the port (e.g. harbor and pilot
DTM
Port agent
Accounts dept.
Provide pre-arrival
documentation
Notify accounts for payment
of agent (CVT)
Provide port details
(berthing, cleaning)
Captain
Negotiate agency fees
and PDA (ISS)
Notify agent
appointment
Create PDA
Provide updates +
feedback to DTM
Select and appoint port
agent (CVT)
Charterers
Request
Voyage Orders
Negotiate standard charter
party forms (CVT, ISS)
UPT
Create recap
document
DTM
Distribute recap document to
DTM (CVT, TIS)
Review/confirm
recap
Captain
116
dues, towage expenses). DTM identifies and appoints a suitable Port Agent on the basis of skills
such as personal trust, voyage management, voyage establishment, etc., with whom the DTM
operator negotiates the terms of the PDA. The main article up for negotiation between DTM and
Port Agent are the agency fees. Once PDA terms are agreed the DTM operator notifies the DTM
accounting department for arranging the payment of the fees related to the appointment of the
Port Agent and forwards the PDA to the captain. The process continues by direct communication
between the captain and the Port Agent for the execution of the loading and discharge procedures
at the starting and destination ports. Furthermore, daily updates are communicated to DTM by
both the captain and the Port Agent. After completion of the process described above, the Port
Agent sends the final disbursement account to DTM (the PDA is an accurate estimate of costs).
At this point DTM can close the voyage using the DA-Desk legacy system.
Figure 58 presents the UML-based use-case diagram, where DTM and the Port Agent negotiate
the terms of the PDA. First, the agent is commonly appointed by the ship owner, i.e. DTM
operator, to begin negotiations with. The main article up for negotiation between DTM and the
port agent are the agency fees. When agreement is reached, DTM uses the DA-Desk system to
notify on the appointment of the specific agent. Then, the DTM operator forwards the PDA to
the captain. Once the PDA is finalised, DTM notifies its accounting department for settlement of
the fees. The process continues with communication between the captain and the port agent for
execution of the discharge and turn-around procedures. Upon completion of the process, the port
agent sends the final disbursement account to DTM. Thus, DTM closes the voyage in Da-Desk.
4.2.3.2 Objectives
The objectives of this work are to validate, test and establish the efficiency and effectiveness of
the COIN platform by reducing the time and simplifying the execution of the processes in the
maritime shipping domain. In particular, through the selected use cases, the aim is to simplify
and expedite the establishment and management of a voyage, which involves highly interactive
processes executed by several parties of a highly distributed team. The weaknesses identified are
related to the current communication methods used in tasks such as voyage terms negotiations,
information and documents trusted sharing, chat and voice communication, etc. In particular,
these tasks are accomplished mainly by exchanging emails and phone calls. This is a major
weakness not only because the task of exchanging emails is time consuming but also because it
becomes difficult for the mediator party (i.e. DTM operator) to coordinate and organize correctly
the communication between the involved parties. Therefore, it was deemed essential to perform
the necessary technological developments, in order to drive the required business processes and
allow executing efficiently these complex processes.
4.2.3.3 Supporting the Maritime Sector using the COIN platform
On the basis of the use cases described in Section 1, the necessary COIN services provided by
the COIN platform were identified. Moreover, additional extensions/services were developed in
order to achieve smooth integration with COIN services and support as a result the specificities
of the maritime shipping domain. Thus, specific services were selected that can aid and simplify
tasks of the processes that are namely: negotiations of voyage terms, information and documents
trusted sharing and management of relations of the human collaboration team. From the pool of
services [4] provided by the platform a number of COIN Enterprise Interoperability (EI) services
were chosen. These services are: Interoperability Space Service (ISS) [3], Trusted Information
Sharing (TIS) [1] and the Collaboration Visualisation Tool (CVT) [2]. Furthermore, the COIN
Baseline Communication Services were used to support efficiently the necessary communication
tasks.
Foremost, the ISS service provides the capability to exchange and negotiate details and terms of
various documents in Universal Business Language (UBL) format. Also, the TIS service offers
flexible sharing of business-related information and documents based on the strength of relations


117
established from previous business interactions [7]. In specific, the TIS service allows sharing
parts of documents by defining different sharing rules for diverse partners, on the basis of
relations. The CVT service is highly-related to the TIS service since it provides a tool that
visualises the human collaboration network; COIN users and their discovered relations. Relations
may rely on prior joint activities and interactions (e.g. voyage management). Finally, the COIN
Baseline Services allow direct communication amongst partner using different communication
formats such as email, group chat, Skype instant messaging and Skype voice call. Direct
communication is crucial during the execution of the maritime processes and thus is provided in
tasks such as informing partners that a new task has been assigned to them or discussing with the
vessel captain that requires some clarifications on the voyage.
118

Figure 59 - Use Case 1 Formulation of the Recap Voyage Document using ProcessMaker

Figure 59 illustrates part of the formulated workflow process for the first business use-case that
refers to the Formulation of the recap voyage document. As aforesaid, the business process is
defined using the ProcessMaker application [5] of the COIN platform, which allows creating,
assigning and executing business tasks. These tasks (e.g. Voyage Selection) can be associated
with forms, users and web service triggers (i.e. invoking COIN services), so as to carry out
successfully business processes. For instance, the primary task shown in Figure 59 (i.e. Voyage
Selection) is assigned to a DTM employee and is associated to the form shown in Figure 60. This
enables a DTM employee to start a new business use-case (see Figure 60), as soon as a new
voyage fixture arises and needs to be negotiated and decided. Figure 60 showcases actually that


119
the assigned DTM employee acts a business use-case partner, rather than a developer, using
though the same COIN service platform portal.

Figure 60 - Initialisation of the recap document business use-case
4.2.3.4 Business Benefits
The benefits provided by the COIN platform, in terms of collaboration and interoperability, can
be measured by identifying relevant business indicators. This allows measuring the changes and
improvements in business process parameters, on the basis of the business indicators. Using the
Value Reference Model (VRM) [9] and on the basis of the developed pilots, the proper business
indicators have been identified and selected that aid the quantification of results.
Table 5 - Preliminary Results using the VRM model processes and metrics
VRM Process Meaning Metric Value Before
Using COIN
Expected
Benefit
[%]
Expected
Value After
Using COIN
BUC1 GS03 Govern
Supply Chain
Information
Time to complete
process plan
Velocity 24 72 hours 30 17 50 hours
A5 Place Order Negotiating/distri
buting/reviewing/
confirming recap
Velocity 16 48 hours 30 11 34 hours
BUC2 GS03 Govern
Supply Chain
Information
Time to complete
process plan
Velocity 24 72 hours 30 17 50 hours
A5 Place Order Negotiating/distri
buting/reviewing/
confirming PDA
Velocity 16 48 hours 30 11 34 hours

VRM supports key issues and gears together processes within and between individual units of
networks for the benefit of: (i) Planning, (ii) Governing and (iii) Execution (information -
financial - physical flows). The models objective is to increase the total chain performance and
support evolution [9]. In particular, VRM employs a common, process-based language of syntax
and semantics and enables the successful application of SOA-enabled practices. On the basis of
the VRM model the following business benefits have been identified: (i) reduction of lead time
in decision making and reaction to arising problems, (ii) improve the efficiency of processes and
(iii) reduce barriers of a geographically distributed team. These benefits drive the selection and
measurement the velocity metric defined in the VRM model [9]. At this point the initial pilots
have been implemented and tested with the following preliminary results shown in Table 5.
120
4.2.3.5 Conclusions and Lessons Learned
One of the most important objectives in the maritime sector (or any other logistics sector for that
matter) is fast decision making and reaction in arising problems. Reducing communication time
between partners using COIN Baseline Communication services, will lead to the successful
management of multiple voyages through timely completion of individual tasks. Furthermore,
the use of the COIN platforms EI Services can improve in overall the efficiency of collaboration
and interoperability processes executed by these partners. Thus, negotiation (ISS), information
and document sharing (TIS) and collaboration (CVT) services as part of the COIN EI services
can contribute to the overall efficiency of processes. The management of shipping voyages
overlaps geographical barriers. This means that vessels managed by DTM can be in different
locations. Also the charterers and the agents can be in any country in the world. Hence, DTM has
to be in continuous communication with the vessel as well as the charterers and the agents. Also,
DTM may need to monitor negotiations between other parties, which are not located at the same
place. Consequently, the use of the common COIN portal and the provided (selected) services
can reduce the barriers faced by such a geographically distributed team.

References
[1] COllaboration and INteroperability (COIN) EU IP 2010a, Deliverable D4.5.2b Annex III Trusted
Information Sharing Service (TIS) Final Factsheet.
[2] COllaboration and INteroperability (COIN) EU IP 2010b, Deliverable D4.5.2b Annex I Collaboration
Network and Visualization Tool Service (CVT) Final Factsheet.
[3] COllaboration and INteroperability (COIN) EU IP 2010c, Deliverable D4.5.2b Annex I
Interoperability Spaces Service (ISS) Final Factsheet.
[4] COllaboration and INteroperability (COIN) EU IP 2011, Service Terminology COIN Services
Repository, Available Online: http://www.coin-ip.eu/intranet/wiki/cross-wps/service-
terminology?searchterm=service+termino.
[5] Colossa, Inc. 2000, ProcessMaker Workflow Simplified, Available Online: http://www.processmaker.com.
[6] Cyprus Shipping Chamber (CSC) 2010, Cyprus: A Leading Maritime Center, Available online:
http://www.csc-cy.org/tmp/28433223.pdf.
[7] Skopik, F., Schall, D., Dustdar, S., 2010, Trust-based Adaptation in Complex Service-oriented Systems,
IEEE International Conference on Engineering of Complex Computer Systems (ICECCS).
[8] PriceWaterhouseCoopers (PWC) Cyprus 2010, Cyprus shipping: A sea of opportunities, Available
online: http://www.pwc.com/cy/en/publications/assets/pwc-cy_shipping_sep10.pdf.
[9] Value Chain Group (VCG) 2004, Introduction to the Value Reference Model (VRM), Available Online:
http://www.value-chain.org/en/cms/1960/.


121
4.2.4 An EI/EC Pilot in a Logistics Network (LODER)
Gulcin Buyukozkan, Leyla Arsan, Aslihan Kagnici, Mehmet Tanyas
1

1

LODER - Turkish Logistics Association (www.loder.org.tr) - e-mail: gulcin.buyukozkan@gmail.com
Abstract
Turkish Logistics Association, LODER, is the COIN project partner for industrial implementation of COIN
Enterprise Collaboration (EC) and Enterprise Interoperability (EI) services in logistics industry. The business case
scenario of LODER is defined in the Chemical/Paint sector and it addresses the subject of the collaborative
transportation of paints from paint manufacturer to its customers. The objective of this scenario is to increase the
customer services to the highest level by decreasing the logistics costs. After identifying logistics requirements for
COIN EI and EC services for the defined scenario, the general development process and the expected business
benefits are summarized and concluding remarks are underlined.

4.2.4.1 Introduction
The logistics industry is one of the several domains addressed by the COIN European Project.
Within the scope of the COIN project, Turkish Logistics Association, LODER
(www.loder.org.tr), is responsible to test the applicability of COIN Collaboration (EC) and
Enterprise Interoperability (EI) services [1] [4] [2] to identified logistics business processes.
LODER was founded in 2001, representing 450 individual members including academicians,
professionals (working both in logistics services providers and logistics service recipients
companies), information technology experts and armed forces members. The mission of LODER
is to contribute on the logistics operations to be efficient and effectively under the concept of
supply chain management. Following this mission, LODER expectations from COIN project are
determined as improving the use and the adoption of interoperability services, especially in
Turkish logistics SME companies, and improving the cooperation activities between logistics
stakeholders.
In Turkey, total logistics sector business volume is 70 Billion and total logistics and
transportation companies business value is 40 Billion [3]. Logistics expenses have been
increased by 3 times in the last 5 years in Turkey and the share of outsourcing logistics services
has been increased by 5%. According to the GDP (Gross Domestic Product) values in 2009,
transport, storage and communication sub-sectors constitute 13% of total GDP value. There are
approximately 280,000 companies under the sub-sector of road transport in Turkey and 95% of
all of these companies is considered to be SMEs. The use of information and communication
technologies (ICTs) in the logistics sector, especially in the category of SMEs, is in extremely
low level. The processes are generally carried out by the office programs, fax and e-mail. When
the company begins to grow, the accounting and payroll programs, the track and trace systems,
hand terminal systems, transport management, warehouse management and optimization
software start to be used. As a result, the companies have to use different software for each
logistics business process which is very costly especially for SMEs. Since the SMEs in logistics
sector in Turkey have not adequate facilities for doing R&D, LODER will lead the R&D on
behalf of SMEs by developing new services on COIN services according to the SMEs needs. In
this study, we present the initial findings of the LODER as the pilot implementation of COIN
project services for logistics domain.
4.2.4.2 Short description of LODER business cases
The scenario is defined in the Chemical/Paint sector and addresses the subject of the
collaborative transportation of paints from paint manufacturer to its customers. The objective of
this scenario is to increase the customer services to the highest level by decreasing the logistics
costs. The case was selected regarding the availability with high level of knowledge of the
122
SMEs. In this scope, Dincer Lojistik, which is an SME and a member of LODER, was selected.
Dincer Lojistik is located in stanbul and provides logistics services in all over Turkey. The case
contains the relation between Dincer Lojistik and its clients, clients of clients and the carriers (cf.
Figure 61). The clients of the Dincer Lojistik have strong legacy systems such as SAP, LOGO
MS, AXAPTA, AS/400 and Dincer Lojistik uses LATMS software. The integration between
LATMS and the other legacy systems is provided by the interfaces and the web services in the
business processes during data transferring.

Figure 61 - Dincer Lojistik business network for collaborative transportation

The business processes of the case include 13 steps within the constraints of logistics as domestic
transport, packaged goods (IBS) and a process without storage. In the scope of the business
processes of the case, first of all, Dincer Lojistik makes an agreement with its clients and during
this agreement it carries out the each project management. Before the order-delivery processes,
contract management between Dincer Lojistik and its clients is realized. In this scope Dincer
Lojistik prepares a work plan in MS project and generates the address list of the clients of the
clients. Then contract management between Dincer Lojistik & Vehicle Owners and the clients of
clients is made by the contract documents. After the order-delivery processes, the clients make
the performance measurement controls and reports according to the performance indicators.
After the contract managements, the order-delivery processes begin: Dincer Lojistik receives the
orders from its clients (Polisan in our case) and groups the orders by date and by location. Then
Dincer Lojistik plans the freight and routing according to its own properties and rental vehicles
and sends the vehicles to the Clients loading place. The vehicles depart from the client by
receiving the deliveries. In the meanwhile Dincer Lojistik tracks and traces the vehicles. When
the vehicles arrive to clients of clients (such as distributors, construction market chains, hard
ware dealers and construction yards) delivery place, they are unloaded. If there are any returned
and empty containers, they are separated. In the next step, Dincer Lojistik reports to its clients
about the delivery and then prepares and sends the invoice. The business processes end when the
clients send the payment to Dincer Lojistik. (cf. Figure 62).
From the whole case, six use cases which have the strong requirements for interoperability and
cooperation were separately defined. These use cases address the business network between
Dincer Lojistiks client, namely Polisan with Dincer Lojistik. The selected use cases (UCs) are:
UC1. Project Management, UC2: Receive the order of Polisan, UC3. Plan the freight and
routing and send the vehicles to the Polisans loading place, UC4. Load the vehicles and receive
the deliveries and vehicles depart from Polisan, UC5. Track and trace the vehicle, and UC6.
Unloading the vehicles in the delivery place and reporting to Polisan.


123

Figure 62 - The general business processes of Dincer Lojistik for use cases

4.2.4.3 COIN solutions identified and used
LODER selected six UCs, where the problems are mostly seen and time consuming and high
logistics cost occur, from the general business process of the scenario (cf. Table 6)
Table 6 - LODER Use Cases and COIN Services Requirements
UCs COIN Services Requirements COIN EI-EC Services
UC1 A collaborative management tool
requirement.
EC Services: Collaborative Project Management
(Coll4PM)
UC2 Time consuming and data loss because of
two different formats of the orders.
Wrong infromation matches because of
using Turkish characters and different
typing.
EI Baseline Services: Massive Data - MDIS for format
transformation
EI Innovative Services : Data Interoperability Services -
ISS / Semantic Reconciliation Suite
+ LODER Dincer Lojistik Ad-hoc Web Service, LODER
Polisan Ad-hoc Web Service, LODER UBL Converter
UC3 More reliable and verifiable
communication tools requirement.
EC Baseline Services: CS-ES/IMS/NS/CP/SWS.
UC4 Different interfaces for automatic
information receiving for each client / The
clients matching problem because of using
different tax numbers.
EI Baseline Services: MDIS
+ LODER Dincer Lojistik Ad-hoc Web Service, LODER
Polisan Ad-hoc Web Service, LODER Dispatch Converter
UC5 More reliable and verifiable
communication tools requirement.
EC Baseline Services: CS-ES/IMS/NS/CP/SWS.
UC6 Time consuming and data loss because of
two different formats of the orders.
Wrong infromation matches because of
using Turkish characters and different
typing.
EI Baseline Services: MDIS
+ LODER Dincer Lojistik Ad-hoc Web Service, LODER
Polisan Ad-hoc Web Service, LODER Report Converter

Three of the UCs, UC2 (Order Process), UC4 (Dispatch List Process) and UC6 (Delivery Report
Process) have the strong requirements for interoperability. Therefore existing COIN EI services
are selected to be tested and extended. LODER defined four main requirements and carried out
the development activities for these requirements which are; Integration of the MDIS (Massive
124
Data Transfer Information Service) [1] for format transformation and ISS to provide negotiation
on top of an UBL (Universal Business Language) order to the existing legacy systems, Turkish
Characters Management, Creation of the interfaces between SAP and LATMS and Realization
of automatic transformation of the formats for reports. The common most important problem for
all these three UCs is that since Dincer Lojistik and its clients use different services, there are
two different formats of the formats and they need to be converted twice while transferring the
orders. This file converting process obviously causes time losses. To solve this problem, LODER
carried out the development activities and created the web services in order to provide the
automatic transformation between the formats by using the COIN Services. More precisely,
LODER created web services to deal with both Polisan and Dincer Lojistik legacy databases
importing and exporting three business documents (order, dispatch list and delivery report)
from/to legacies systems. By usage of the semantic suite the generated transformations convert
the XML format of the buyer company to UBL format which will be used on negotiation stage in
ISS. This last service will be used to convert back the UBL format to the seller company's XML
format after negotiation which will be passed again to the ad-hoc web service of the seller
company to be saved in the legacy system. These ad-hoc services are also used to convert the
dispatch list and delivery report from one company's XML format to the other's (cf. Figure 63).

Figure 63 General development process for order transformation
4.2.4.4 Measured Business Benefits
To measure the expected business effects of COIN project, based on the UCs, firstly, the
processes are selected according to the Value Reference Model (VRM) (www.value-chain.org).
VRM priority dimensions and KPIs are then determined and the measurement of the as-is
situations before using COIN services is realized. Table 7 summarizes briefly the LODER UCs
business benefits.
Table 7 - Expected business benefits related to LODER UCs
UCs VRM Process Dimension Metric Unit Expected
Benefit
Value before


125
(%) using COIN
UC1 GS03 (Govern Supply
Chain-SC, Information)
Cost Cost, Govern
Information SC
10%-15% 80000 - 100000

A04 (Acquire,
Negotiate Contract)
Cost Cost, Negotiate
Contract
10% 3000

Reliability Ratio, Successfully
Negotiated Contracts
% 5% 20%
UC2 A06 (Acquire, Receive
Order)
Cost Cost, Receive Order
20%-25% 45000 - 50000
Reliability Orders, Receipts Error
Free
% 5%-10% 80% - 85%
UC3 PS4 (Create Plan, SC) Velocity Cycle Time, Create
Plan SC
Hours %20 3-6
UC4 F05 (Fulfill, Fill Order) Cost Cost, Fill Order 20%-25% 45000 50000
UC5 GS03 (Govern SC,
Information
Cost Cost, Govern
Information SC
3%-5% 40000
UC6 F07 (Fulfill, Deliver
Order)
Cost Cost, Deliver Order %20-25 45000 50000

4.2.4.5 Lessons learned and concluding remarks
Within the selected six businesses UCs of LODER, the both selected COIN EI and EC services
are tested and the required development is realized according to the defined logistics
requirements. In this context, MDIS, ISS and Semantic Reconciliation Suite of the EI services
and Coll4-PM and Communication Services of the EC services are tested and evaluated in order
to be able to use them in the test-bed demonstrations. Regarding to the result of the LODER
evaluations of the COIN services, in general, the effectiveness, efficiency and understandability
of the services are at high level and satisfaction, attractiveness, learnability, memorability and
use preparation and maintenance of the services are at medium level. ISS is very useful and easy
to understand; the concepts and terminology are understandable for our organization and in line
with other COIN services. Most of the functions of the service such as building a new
negotiation, creation, deletion and application of personal rules are very beneficial for the
companies in the logistics network. The outcome of the service will save time and cost by
accelerating the process of negotiation on the orders. MDIS is a very useful supporting tool for
the XML legacy format transformations. The usage of the MDIS accelerates the process of the
creation of the ad-hoc transformations from the legacy database systems. One of the most
attractive features of the service is that it is very easy to take up also for SME. Since the most
important problem is the order format transformations between the legacy systems of the
companies, Semantic Suite Reconciliation service, which allows exchanging of the documents
automatically by generating a specific web-service in the run-time translation of the documents,
is the most beneficial service for the order receiving process.

References
[1] [Elvesaeter et al, 2008] B. Elvesaeter, G. Benguria, A. Capellini, E. D. Grosso, and F. Taglino. State-of-the-
Art and Baseline EI Services Specifications. Technical report, COIN Project Deliverable, 2008.
[2] [Facca et al, 2009] F.M. Facca, S. Komazec, C. Guglielmina, S. Gusmeroli, COIN: Platform and Services
for SaaS in Enterprise Interoperability and Enterprise Collaboration, Semantic Computing, 2009. ICSC '09.
IEEE International Conference, .543-550.
[3] [MTC 2011]. Ministry of Transportation and Communications, Republic of Turkiye,
http://www.ubak.gov.tr/.
[4] [Sitek et al, 2008] P. Sitek, J. Eschenbaecher, M. Sesana, H.-L. Truong, and C. Aguilera. D4.1.1 State of the
Art and Baseline EC Services Specifications. Technical report, COIN Project Deliverable, 2008.

126
4.3 The COIN EI/EC Services in Business-Innovation Ecosystems
The main novelties for todays innovation ecosystems compared with earlier times can be found
in ICT systems and the internet [4]. Across a wide range of industries today any entrepreneur
with a good idea can, despite of geographical location, launch a successful business application
[1]. On the other hand small and medium sized enterprises (SMEs) are nowadays faced with an
overwhelming complexity when it comes to weave together systems in real-time manner as a
means to offer superior products to consumers [4] and subsequently grow their business in a
dynamic knowledge-based global economy [3].
The demand for an infrastructure that supports the collaboration of several players in this field
and the interoperability of heterogeneous environments opens opportunities for service solutions
that allow cost efficient, fast and reliable systemic results without major integration efforts. The
COIN system offers such a public, distributed pervasive environment a utility-like capability
that enterprises can invoke on the fly in support of their business activities [2].
Featuring four initial strategies of COIN pilot partners for positioning within their specific target
industry sector this chapter aims at demonstrating the COIN EI/EC Services approach in
different Business-Innovation Ecosystems.

References
[1] Andersen, Jrn Bang. What Are Innovation Ecosystems and How To Build and Use Them. 05 16, 2011.
http://www.innovationmanagement.se/2011/05/16/what-are-innovation-ecosystems-and-how-to-build-and-
use-them (accessed 10 04, 2011).
[2] European Commission. "Enterprise Interoperability Research Roadmap Update Version 5.0 FINAL." 03
05, 2008. ftp://ftp.cordis.europa.eu/pub/fp7/ict/docs/enet/ei-research-roadmap-v5-final_en.pdf (accessed 10
04, 2011).
[3] Nachira, Francesco. "Innovation Ecosystems: Una strategia europea per linnovazione e lo sviluppo
economico." 05 30, 2005. http://www.gencat.cat/economia/ur/doc/doc_30272549_1.pdf (accessed 10 04,
2011).
[4] Tuck Communications. Innovation Ecosystems: Is there a Cost to Collaboration? 03 2011.
http://www.tuck.dartmouth.edu/news/articles/innovation-ecosystems-is-there-a-cost-to-collaboration
(accessed 10 04, 2011).


127
4.3.1 An EI/EC Pilot in a Healthcare Ecosystem (VEN)
Andrew Faughy
1

1VEN Process Ltd, VEN
Abstract
Wellbeing and healthcare is a global business providing worldwide trading opportunities for regional businesses and
international competition. However, competition can be difficult as, for example, with manufacturers and service
providers in the fields of medical technology equipment and devices, a small number of multinational players
dominate. The opportunity can be taken to integrate different customers, consumers, providers, partners and their
solutions in the developing healthcare ecosystem. Networked enterprises with a focus on Enterprise Interoperability
and Enterprise Collaboration can supply directly or collaborate, being more enabled by access and interoperability as
a capability. The wellbeing and healthcare sector is potentially a major engine of wealth creation especially the NHS
(National Health Service) in the UK with its primary and secondary care infrastructure. This is increasingly
expanding to include encouragement of preventative actions by the NHS, Governmental and other bodies. Healthcare
is in essence a utility service, providing both local and national services to widespread and diverse customer base
with a growing provision of solutions (part or total) and prevention activity by the private sector.VEN wishes to
assist in enhancing the provision of local services and the achievement of a health dividend through enhancing the
ability to tackle continuing wellbeing and ill-health at source, and thereby limiting demand for health services would
help the NHS transform the balance of its role and improve effectiveness.

Keywords: Collaboration, Interoperability, Healthcare, SaaS, VEN, Innovation.
4.3.1.1 Introduction and Background
4.3.1.1.1 Introduction to VEN a services and application intermediary
VEN operates in the Healthcare, Engineering, Digital, Environmental and Chemical sectors.
A specific focus for COIN exploitation is placed upon the healthcare sector; with a focus upon
primary care, which includes the growing personalised care arena.

Our customers are of two kinds:
End users (or final customers): Ecosystem, Virtual Organisation (VO), Professional Virtual
Communities (PVC), Virtual Breeding Environment (VBE), and their members including
low tech and mobile users.
Providers of the services, for example the healthcare commissioners, suppliers, doctors etc.

Role in the COIN
VENs role in COIN is a minority partner defining the business requirements for a healthcare
scenario, supporting the development of appropriate applications and testing these applications
with real end users. This document is summation to date; of the thinking, high level service
design, testing and interaction with its own end user community and work with colleagues in the
COIN Project.
4.3.1.1.2 Introduction to UK Healthcare Eco-System
The Healthcare eco-system under test with VEN; is based upon the engagement of Citizens in
the provision of their local social and healthcare services; it attempts to address community
engagement, consultation, service design and creation, service improvement and delivery of
social and healthcare services by ecosystem service providers.
It is considered that the available COIN services with some modification and customization can
support a beta type of eco-system. The selected services are intended to present a low risk to the
128
eco-system members and to COIN by avoiding complex Clinical and NHS centralized services
such as national patient records systems, whilst demonstrating COIN services with real
community and identify business benefits [3].
The ecosystem consists of: Enterprise networks (SMEs & Large Enterprises) + public
organizations (government bodies, regional development agencies, hospitals, charities) +
Research Centres (Academia, others) + Individuals (brokers, consultants) + Customers (citizens,
patients, cross-age, cross-IT literacy).
The COIN project goal of addressing Innovation; in particular Open (to All) Innovation, is
attempted in the service design business use case [3]. The focus is to develop innovative support
services in a participative way, with a citizen-centric approach, akin to a Living Lab-like ethos.
The Ecosystem is considered to be a real breeding environment for all the participants, giving
them voice to express their ideas and to see them implemented by COIN supported services.
4.3.1.2 Context
4.3.1.2.1 Healthcare Market Context
The UK Healthcare market is considered by incumbent practitioners as not a commodity that can
be produced by means of the investment and deployment of capital and labour resources. They
argue; if it was then the United States, which devotes immense resources to health, would be the
healthiest place in the world. Health can only be produced by engaging people and encouraging
them to take active control of their own health.
Of course the production of health care can be seen as a business. A business in which capital is
invested and from which people earn their living. At the level of the individual concern there
must be skills and approaches which would improve efficiency. The incumbents continue that
the discipline of the market is not going to work in the NHS; the fundamental reason is that
market discipline is centred on growth and failure. Selling more goods and services more
profitably than your competitors is the only criteria for success in the market. But in public
services success is more complicated. A successful health system would produce less health care,
not more. [1]
4.3.1.2.2 COIN - Relevant market factors
The mobilisation and incubation of target Citizens, community groups, SMEs, universities to
develop local healthcare work plans which address the design, creation and improvement of
existing services require the following goals to be observed by COIN.
Gain the input of large numbers of local people, business and community groups to
developing local healthcare work plans.
Improve the quality of health and social care delivery
Improve the competency of carers
Improve the training of community and care workers

Potential benefits to SMEs are low cost access to COIN services, provision of easy start-up for
SMEs in the area of collaboration. VEN can benefit as a Service and Application Intermediary
attracting prospective members from additional channels and acquisition of business and market
intelligence from the data sharing consortia, forming model for other SMEs to follow.

Primary Healthcare Care market trends & requirements:
Move to patient centred view of the world


129
Eliminate fragmented and un-integrated care services
Commission by output, if not outcome
Relate to local planning
Reflect local circumstances
o Existing investments
o Geographical locations
o Other related developments e.g. Local Investment programme / Private + Public
schemes
Address issues re pace of change / commitment to full change
o Acute & Primary Care agendas
o Role of Clinicians / GPs / Nurses
o Financial - payment frameworks
4.3.1.2.3 Healthcare Market Challenges
Three long-term trends have been identified by McKinsey & Co; which is reaching a tipping
point that will fundamentally transform the UK: an aging population, societal shifts altering what
households look like, and economic factors slowing the expansion of wealth. As these trends
sweep across Europe, to varying degrees they will impose pressure on consumption growth and
dramatically change economic effect parameters.

What are the fundamental questions for COIN to address in healthcare?

1. How to provide high-quality and affordable in dispersed healthcare networks.
2. Cater for patients at the heart of healthcare service procurement and delivery.
3. Crowdcommissioning commissioning of healthcare services by the community
4. Introduce the COIN healthcare services whilst reducing costs and improving efficiencies
of services.
4.3.1.3 COIN Business Use Case requirements
4.3.1.3.1 Supporting social care networks in the ecosystem
Final end users (patients, professionals, suppliers, citizens) members of regional associations
called Links are utilised for testing of COIN Services. These associations were originally
formed in April 2008 and total 150 representing the English region of approximately 56m
people. Their task is to communicate and represent their local communities in primary healthcare
and social care delivery. Their operational concerns are primarily the ability of the Links to
communicate with each other and the large scale public audience effectively and with an added
barrier; that a large percentage of the community are unwilling or unable to access a computer
(25 to 60% of the population).

Additional operational concerns: management and maintenance of records between the Links
organisation and its communities, recording incidents, management of complaints and
monitoring activity outcomes.
1. Every link is designed to suit its locality Rural/Suburban
130
2. Establish close working relationships with central healthcare commissioners for both
service and policy delivery.
3. Co-ordinate logistics of visiting services including inspection visits to people in their
home mobile workers with little IT support
4. Design and implement Service improvement work plans, usually targeting key themes.
5. Manage Public enquiries including complaints about health and social care services
delivery.

Community ICT Maturity Issues:
1. Effective communication between Links and communities
2. Use of emails as primary system poor record retention
3. Access to & selling the network to the community member
4. Need to assess competency of carers broad vocational skill base
5. Mobile workforce 25-60% do not use a computer but have a mobile phone
6. Managing and monitoring treatment event management Quality of care and its
effectiveness
7. Developing Election and Governance processes for members
8. Managing event and awareness management to attract the wider community
9. Managing funding received from local authorities and dept of health.
10. Delivery of Personalisation of health care spend for each individual patient

Other activity for the Links is to collect and manage feedback from their local communities,
assemble this feedback into a local work plan which defines the desired range of services for the
community; this work plan is then managed by the Links core groups. This activity is expected
to create a large volume of records which need to be effectively managed; in addition
performance management of the work plan needs to be catered for including incident reporting
with a performance dashboard.
4.3.1.3.2 Requirements for Personal healthcare services
Smart Health [2] described the overall COIN value propositions to the stakeholders involved in a
regional Healthcare Ecosystem. In essence the COIN Smart Health is a SaaS-U Service. The
value proposition moves away from traditional price and supply sourcing chain models and
introduces on-demand Enterprise Collaboration and Innovation value adding networks as
the primary driver for increasing SME and local community market opportunities. It leverages
SaaS models with advances in internet commerce, cloud computing and broadband adoption and
linking into regional/national social, innovation and technology programmes. Through its
activities it creates social capital and addresses long term regional, national and community
social and economic benefits.
Table 8 - Example of COIN Smart Health Services developed for low intensity ICT ecosystems (greater
detail available in COIN Business Use Case public deliverable [3])
Business Use Case Functionality Current Services
Existing Solutions
New Services
COIN Utility and
Value Add
Ecosystem Operation
(Horizontal Services):
Managing information
and events.
Web site
Blog
Social
Generic
Service Platform
-security, search


131
1.Market Links &
Recruit Members
2.Manage Events &
communication
3.Form Interest Grp
4.Improve Service
Levels
5.Deliver Training
Sign up community
members,
Formation of interest
groups,
Improvement planning
and performance
management
Networking
Excel/Word
Email
Bulk
Emailer
and discovery.
Legacy data
services - CRM
Human
Interaction (HI)
services: trust,
visualisation, user
taxonomy
Knowledge
I/O services
web analytics and
HI integration
Open
Innovation
service creative
data analytics
Competency
Development


Personal Care
(Vertical Services):
Service User manages
budget and sources care
products and services
Manage budgets,
Define funding sources
and develop support
plan. Purchase
products and services.
Web
application
Personal Care
In addition to
horizontal services:
Semantic
Support Services
Semantic
search,
reconciliation and
supplier
negotiation
Collaborativ
e Product
Development
Service
Quality of
Service and
Dispute
Management
Personal Care
(Vertical Services):
Service Provider
manages a catalogue of
products and services
Manage product
catalogues, multiple
price lists, private
catalogues
Web
application
Personal Care
In addition to
horizontal services:
Semantic
Support Services
Semantic
search,
reconciliation and
supplier
negotiation
Collaborativ
e Product
Development
132
Service
Quality of Service
and Dispute
Management

4.3.1.4 Discussion: past and present challenges, concerns and solutions
4.3.1.4.1 Preliminary results - Consolidated view of Services tested by VEN
Typically the COIN services tested are at a development stage, future work would enable these
services to fully operate in a production environment. The COIN services would benefit from an
interchangeability statement for each service relative to each other and to aid selection and
combination with other services.
A number of services require a degree of expertise and prior knowledge, which may limit the
take up rate of these services. Logic flow of some services is suitable for developers; however
testing with non-specialists requires more information in help guides and installation and set-up
phases.
COIN services should fully exploit a corporate identity; in addition some services should be
released in advance of full implementation of the COIN system to provide process improvements
and opportunities for market adoption. Access to COIN Service(s) installation and maintenance
aspects and secondary services architecture is needed; as a function of customer support activity.
Ongoing work for the usability will aid take up and adoption and address a number of bugs and
usability issues. Preset templates would improve usage, with the use of bulk data updates since
current lab versions rely upon manual setups this is not suitable for production environments.
The degree of data input and transaction complexity varies from service to service.
Company own data formats are not typically considered as is the lack of multi language versions
of the COIN services. However the COIN Services show potential if a strong co-ordination of
current and future development is maintained. Greater detail in relation to user testing results can
be found COIN public deliverable [4].

COIN Challenges
COIN services development into a production environment
Completion of integration phase and ongoing maintenance of interoperability
Management of 3rd party applications with coherent development roadmap
Maintaining concurrency of COIN services to market developments
Definition of COIN service costs and ongoing management costs
Identification of initial COIN operator
Mitigate the risk that COIN is trying to serve too many markets and applications
Addressing the increasing legacy spectrum, by such a wide array of service offerings
Implement Help and Support for COIN Services
There is no direct competing package of Services at present, however due to the broad nature of
COIN, its component services compete with a wide range of open source and commercial
software packages. COIN will need to differentiate upon its collective value proposition; rather
than compete head to head on pricing, the goal being to demonstrate:
Go-it-alone investment costs reduced


133
Easier to establish new venture start-up
Broader offer than standard software, including collective intelligence/experience in its initial
design
Provide EU wide network access
Lower infrastructure cost of ownership using a SaaS-U business model
4.3.1.5 Conclusions
First, initial indications suggest that it is possible to describe the SaaS business model for service
and application intermediary in a Healthcare ecosystem. It is also concluded that incubating the
business model within the ecosystem with little relationship between members is possible, but
will require the intervention of facilitated process by SaaS-U and COIN Health specialists.
Secondary the review of market context has indicated that the timing for SaaS Healthcare
business models is co-incident with a number of developing trends in healthcare and the wider
economic climate; in that:
EU ICT and e-Health policy positions require a pan European solution.
UK Government Policy requires a fundamental growth strategy to offset the economic
recession in the UK, driving open local, national and cross border market creation.
UK growth can be driven by UK public procurement directed to SMEs, with Healthcare the
greatest multiplier of all the public spending bodies.
The nature of the current recession; is the poor become poorer and exposed to greater
hardship. The Healthcare policy shift to the Health Dividend can potentially reduce the
overall Healthcare bill and offset the need for greater levels of taxation.
Growing use of Personalised Care Budgets for long term and end of life conditions within
the healthcare arena presents a market opportunity for local SMEs and Social Enterprises, as
increased outsourcing to local providers by the NHS and Local Authorities.
The general trend of Customer demand for aggregation of spends fewer 1st tier suppliers
Increased market for on-demand services where the initial start-up infrastructure is low or
non-existent.
Global sourcing and the need for harmonized structures and contracting
On-demand innovation processes and systems.
On-demand management processes and systems.
Increasing need to manage complexity by integration of many to many relationships both
supplier and customer.

Continuous review of the service design business model process is mandatory, since this action
research combined with the use of mental modal allows unrestricted forward or backward
movement through the modelling process; in this case the methodology is seen as a landscape
rather than a linear sequence of steps.
The level of time and effort invested into the research; especially creation of service and business
model frameworks, strongly effects the outcome and acceptance of the business model. Secondly
creation of the business model framework is greatly improved by the review of the As-Is
condition and the To-Be condition of the selected business/sector context with actors from the
context selected. The definition of the benefits is essential at the outset to retain input from
ecosystem actors and develop the business model with greater usability.
134
The initial service & business model process; required a level detail from the use of context(s) to
establish scenarios. The COIN project has a vision and exploitation plan; however such a
complex ecosystem requires the input of end users, policy makers and economic reality each
with their own perspective and interpretation. This counters the tendency to create either a
system without a market (technology led) and enable end user involvement in the service design
and hence at least one major variable of the business model. Additionally correlation is needed
between the stakeholders, market influencing factors and influencing variables within the
process. This step allowed the refinement of the business model to reflect more closely the
overall vision, in this case COIN, producing a as-is and to-be condition.
The use of face to face dialogue with ecosystem actors was essential since the low technology
maturity of the sector dictated this approach, it is concluded that future approaches would be
more productive if a maturity assessment is conducted prior to engagement, but this should not
be used to select convenient sectors or ecosystems, but as guide to the engagement process.

References
[1] Socialist Health Association www.sochealth.co.uk
[2] COIN project (FP7 IP 216256). Smart Health COIN Deliverable D6.2.1a, 2008
[3] COIN project (FP7 IP 216256). Business Use Case COIN Deliverable D6.1
[4] COIN project (FP7 IP 216256). Final End User Testing, Demonstration and Take-up COIN Deliverable
D6.6x



135
4.3.2 An EI/EC Pilot in Pyry business eco-system
Timo Syrjnen, Mikko Hynlnmaa
1

1{timo.syrjanen, mikko.hoynalanmaa}@poyry.com
Abstract
This chapter describes the pulp & paper case of COIN represented by Pyry. The context is engineering of large
capital products, like pulp & paper mills in a multi-partner, multi-location environment. The main focus is on
supporting collaborative project management.

4.3.2.1 Short description, as-is situation
Pyry is a global consulting and engineering company, dedicated to balanced sustainability.
Pyry offers its clients integrated management and consulting, total solutions for complex
projects and efficient design and supervision.
Pyry has 7000 experts operating in about 50 countries, locally and globally. Pyry's net sales in
2009 were EUR 674 million. Pyry has project experience in more than 100 countries and
conducts 17 000 projects annually.
Typically a pulp and paper mill project costs are 100 - 1000 million including engineering
work about 1 10 million . Project duration is normally 6 36 months, involving 10 150
engineers (100-1500 person months) and 10 30 different actors such as owner, suppliers,
engineering consultants, authorities etc. Project work is typically globally distributed.
4.3.2.1.1 Pyry Business Ecosystem
Figure 64 illustrates a typical cluster or Business Eco-System with actors in facility engineering
projects. Collaboration between the actors is essential and needed in every project. The project
structure and organization can be different in each project.

Figure 64 - Business Eco-System with actors in facility engineering projects

Currently a transition process to global operation is taking place. Projects and organizations are
geographically distributed. The objective is to be close to the customer and to move work not
people. The ultimate target is a system of global shift work with work moving around the globe
136
on a daily pace through Asia, Europe and the Americas. Time schedules will be substantially
shorter and cost can be reduced as a result of significantly competitive labour rates. At the same
time information and knowledge sharing will result in a maximization of expertise.
The challenges in global collaboration and interoperability comes from a distributed organisation
involving different languages & ontologies, cultural differences, different time zones and
latitudes, work ethics and different legal systems. Communication is the key to overcome these
differences. In addition to engineering offices which partly belong to Pyry company, the
ecosystem involves also other actors, like customers, suppliers and authorities.
4.3.2.2 Objectives and Expectations from COIN
The Pyry case in COIN addresses Knowledge Interoperability in Pulp & Paper Ecosystems
aiming to experiment, trial and demonstrate COIN innovative project management services
focusing on multidisciplinary project management and continuous project alignment in industrial
projects.
In the Pulp & Paper case the developed COIN project services can help and improve challenges
in global collaboration and interoperability such as aligning different practices, identification of
training needs, creating common understanding of project objectives and requirements,
monitoring the project status, identification of deviations as early as possible, pro-acting to
prevent delays and other risks.
Figure 65 illustrates the main areas where COIN project services can be an important factor
supporting the new Pyry vision and strategy. COIN services can accelerate the transition to
global operation and networked engineering. The three key areas are:
Maturity of the network
Collaboration and communication
Project management services

Figure 65 - Accelerate transition to global operation and networked engineering

Pyry's vision for 2020 is to be the global thought leader in engineering balanced sustainability
for a complex world. Engineering has always been at the core of Pyry and for decades the
company has been involved in projects with sustainable dimensions. The key difference with the
new company vision is that sustainability is placed at the heart of everything Pyry does. Pyry
sees a balanced approach to sustainability as the best way forward for the company, its clients
and society.


137
The COIN project directly supports the Pyry future vision and strategy. And the developed
services and assets can be utilised to achieve this new vision.
4.3.2.3 COIN solutions identified and used
As a starting point Poyry was most interested in the development and take-up of Collaborative
Project Management services. The main services in this area taken by Pyry were Collaborative
Project Alignment, composed of several subservices, and Meeting Process Management
Services. For these areas Poyry had some preliminary requirements and expectations for the
services. However, during the project additionally some new services were identified useful
(services, which were not in the requirements in the beginning). These were for example social
ontology building service (SOBE) and the collaboration maturity model (ECMM). As a whole,
the coverage of the services was one of the strengths of COIN.
4.3.2.4 Business Benefits
The main services used by Pyry in COIN are the Collaborative Project Management (c-PM)
services. The c-PM services can make the project management more efficient, but the main
benefit is coming from the better project execution. Thus even if the project management can be
performed with lower resources using the COIN services, this is not the main benefit. The main
benefit is coming from that the engineering project can be carried out with improvements in
costs, time, quality and decrease of risks.

Consequently, in the benefit identification also the processes affected by the supported processes
should be viewed to see the total benefits.
The comparison of as-is and to-be proved to be challenging for some processes. This is
because the take up of the COIN services not only changes the existing processes but they may
create totally new processes, which may include parts of some previous processes, but are not
identifiable in the previous processes as such.
Even if the focus area of COIN was Collaborative Project Management and therefore the
viewpoint of project management was strong, we see that all the partners in the business
ecosystem can benefit of the services. The collaborative approach for the management allows the
partners to participate more in the management and thus utilize better their knowledge and
resources. The more aligned execution of projects makes the whole ecosystem more competitive
in the engineering market.
4.3.2.5 Lessons learned
4.3.2.5.1 Legacy System Integration
Some of the COIN services are so innovative that there is not yet sufficient information for them
in the legacy systems. Examples are the alignment data required by the alignment booster and the
trust data required by the human-interaction services. The data required for the testing and
demonstration was collected manually in this phase. In the future some of this information may
be available in legacies.
4.3.2.5.2 Future expectations
Pyry prefers in the future to consume services from a cloud and also having data in a cloud.
However, there are some exceptions, like projects for high security customers. All customers will
not accept the data in a cloud.
138
As a business model SaaS is preferred. Pyry would also like to have engineering tools as SaaS,
using them from the cloud, and also supporting the engineering process. There is a need for new
developments and new services in this field.
The main challenges for the rollout in the business ecosystem come from the heterogeneity of the
partners. The capabilities are not at the same level in the business ecosystem. In some locations,
like China, also the physical network is a challenge so far.




139
4.3.3 An EI/EC Pilot in an Agro-Food Living Lab (WirelessInfo)
Karel Charvt1, Otakar erba1, Pavel Gnip1, Karel Charvt jr
1

1

Wirelessinfo,Litovel, Czech republic
charvat@wirelessinfo.cz
Abstract
In this chapter factors influencing farm management and profitability of agriculture are described. There are
introduced two services, which are being developed with aim to increase profitability of farmers. The services are
Tactical production planning and Search for providers of machinery. Part of these services is using solutions
developed in COIN project.
4.3.3.1 Introduction
The agriculture sector is a unique sector due to its strategic importance for both European
citizens (consumers) and European economy (regional and global) which ideally should make
the whole sector a network of interacting organisations. There is an increasing tension, which is
not experienced in any other sector, between the requirements to assure full safety and keep costs
under control. Food safety and food security is now a strategic interest not only of Europe but
worldwide. The balance between food safety and food security will be an important task for
future farming worldwide, but also for farming decision making. There exist a number of
external drivers, which will have potential influence on the farming sector in the future. We can
consider the following groups of drivers, which will have an influence on farm management and
which eventually will stimulate new demands on knowledge management:
Climate changes
Demographics (growing population, urbanisation and land abandonment)
Energy costs
New demands on quality of food (Food quality and safety)
Aging population and health problems (ethnical and cultural changes)
Innovative drivers (knowledge based bio economy, research and development, information
and communication, education, investment)
Policies (subsidies, standardisation and regulation, national strategies for rural development)
Economy (economical instruments, partnerships, cooperation and integration and voluntary
agreements)
Sustainability and environmental issues (valuation of ecological performances, development
of sustainable agriculture)
Public opinion (press, international organisations, politicians)

In accordance with FutureFarm we can consider three levels of farm knowledge management:
Macro level, which includes management of external information (for example about market,
subsidies system, weather prediction, global market and traceability systems),
Farm level, which includes for example economical systems, crop rotation, decision
supporting system,
Field (micro) level including precision farming, collection of information about traceability
and in the future also robotics.
The basic principles of interrelation can be expressed by Figure 66.
140

Figure 66 - Interrelation of different knowledge levels

4.3.3.2 Open agriculture services
The practical experience demonstrates that main research is currently focused on precision
farming methods, which are mainly related to operative decision on micro level. On the other
side it was documented, that the right decision on the base of macro level information has a main
influence on the profitability of a farm.

The goal of COIN OAS in the agrifood sector is to develop a collaborative adaptable and
interoperable solution, where the users will be able to share interoperable data and information
using trusted methods for information sharing, which will protect information against potential
competitors (important for agriculture). OAS, which are being developed, introduce a new model
for effective agricultural e-collaborative knowledge management. Some parts of Open
Agriculture Services are being developed as a part of other projects, or outside projects. In OAS
two services have been identified as the most suitable use cases for the COIN projects:
Tactical planning for next seasons
Search for provider of machinery

Tactical production planning
The COIN tactical planning module is focused on introducing new methods oriented on tactical
planning for the next seasons. The main goal of tactical planning is to recommend optimal
production and land use for the next seasons to maximize expected profits. The goal for tactical
planning is to recommend production for the next season, eventually also some vision for the
next (two till five) seasons. The decision problem could be described in this way:

A farmer has a number of parcels with different properties available for his production. It is
possible to grow different kinds of products on these lands.
On each of these lands it is possible to grow at maximum one product using one of two methods:
Production without using variable fertilizer application.
Production with variable fertilizer application.


141
Due to many reasons, for example crop rotation and field localization, it is not possible to grow
each of the products on each of the lands in the next season. In this approach optimal production
plan and profit for each scenario has to be computed. The key problem for the decision is the
existence of data. In case of farmers, who were using precision agriculture in the past, it is
possible to estimate many data values with quite high accuracy. Obviously most of the
information does not exist in farm information systems in the form requested by the model. The
interoperability of data is missing; we need tools transforming data into the required form. To get
values of some data it is necessary to create procedures, which will calculate the values from
available data. However some of the data values have probabilistic character. Selling prices of
each product kind is very difficult to predict. The yields per hectare of some products and costs
also bring some uncertainty into the decision problem. The approach which is used in case of
parameters, which are difficult to predict, is creating several scenarios for factors, which are
affecting values of these parameters. For generating scenarios a lot of external information is
needed. Mainly in case of prices, we probably are not able to do without services of agricultural
analysts. We will consider two approaches to scenarios.
In the first approach the optimal production plan and profit for each scenario has to be computed.
For each of these production plans, the value of profit in case of all other scenarios is expressed.
Then a suitable method of choosing one of the production plans is used. The second approach is
based on multiple criteria mathematical programming. In multiple criteria mathematical
programming problems, there is more than one objective function. In case of our problem, the
individual objective function represents profits in different scenarios. Solutions found by solving
multiple criteria mathematical programming are called compromise solutions, because most of
the problems dont have a solution providing the best values for all objective functions in the
same time. For these purposes, it is necessary to use some of the available modelling systems and
optimization solvers. These tools have to be integrated with the current Prefarm SaaS
information system using COIN MDIS. Purchasing commercial software belonging to these
categories is usually very costly. In this moment we are using the modelling system PuLP with a
modelling library created in Python.
The basic system architecture is divided into three layers

Figure 67 Three Layers Architecture

Liferay interface guarantee communication with end users, but also authorisation and
authentication. Layers of portlets or iFrames guarantee communication with single components
or databases. Database and service layers is layer, where single components really interact. From
component point of view architecture could be characterised by next components:
142

Figure 68 System overview

Architecture allows discovering and selecting information sources from existing services -
precision farming database, sensors and other existing databases and combining selected
information into form of Web Feature Services (GML format version of XML for Geographic
Data. The geographical data are shared using services defined by Open Geospatial Consortium.
For optimisation processes it is not necessary to use directly spatial representation of objects
(areas, etc). For optimisations it is necessary to transform data into tabular form protecting only
identifier of graphical object. This identifier is later used for merging optimisation results with
graphical object for visualisation. In MDIS there is defined transformation model for
transformation data into interoperable form. Own development is focused on Optimization
module which is generating variants of production plan. This information is transferred into
graphical form and visualised using visualisation client.

Search for machinery providers
The main purpose of the use case Search for provider of machineries is to enable a farmer to
search for machinery providers in his region. The farmer will be able to search providers, who
registered their offer of machinery and services in the catalogue connected with an advisory
system. The machinery provider will have to fill in data, which are necessary for a farmer to
choose the most suitable offer. The machinery can be offered in two ways:
Pure machinery
All inclusive (with operating staff)

Main target is to support using geo-information technologies to enable building communities and
efficient cooperation making for cost reductions in agriculture sector. The main functionality
based on COIN SCMS is semantic searching of producers, owners, products (agriculture
machines and tools) based on specification of the weights of importance of different parts of


143
query. Other functionality is on-line updating of knowledge base (ontology) describing the
products and tools.
The system is composed of three main parts (except external communication modules): ontology
(knowledge base, described in OWL 2.0 format), semantic searching system (SCMS), editor tool
(making possible to modify or add source data stored in ontology) and semantic searching tools.
The system should cooperate with Maplog system used to cars (or machines) control.

Figure 69 - Architecture of Machine searching

4.3.3.3 Conclusion
Now lets try to evaluate the impact of the new services, which are being developed. Existing
farm management systems were mainly focused on operational decision about fertilizers, amount
of pesticides, etc. Long-time analysis demonstrates, that this operational decision could increase
farm profitability around 15%. On the other side last years market development demonstrates,
that the changes in price of agriculture productions from one year to next could change about 200
or 300 percent. So from this fact it is clear, that right production planning could significantly
influence farm profit and that the incensement of profit from tactical planning could be bigger,
than from operational planning.
The new system generates new possibilities for advisory services related to market data analysis
and recommendation preparation for farmers. These types of services have not been used until
now, because current systems dont allow sharing data and dont offer instruments for such a
type of services.
Open agriculture services (OAS) will improve cooperation in production, consultancy and
supply chain, because they will support better collaboration and information exchange. Sharing
of data and services will increase quality of collaboration, common workspace will give
possibility for better communication among farmers, farmers and services and farmers and
consultants. OAS will give chance for better utilization of machinery like harvesters, spreading
machinery and others, which are used only for a small part of the season. The system will help
farmers having such machinery to sell parts of their machinery capacity as services.
144
The pilot experiments demonstrated, that interoperability of agriculture information is one from
key problems for future knowledge systems. Transforming available information into unified
data model for taking tactical decision provided by MDIS module helps to use information for
effective decision. The development and population of ontology focused on agricultural sector
based on the ontology published in COIN project helps to search more effectively for
information and will help to more effective utilisation of investment and machinery.

References
[1] Cerba, O., Charvat, K., Charvat, K. jr., 2011. D7.1.4 COIN - EEU EC services Annex III -Wirelessinfo
services, Report from COIN project
[2] Charvat, K., Charvat, K. jr., 2011. D7.1.3 COIN - EEU EI services Annex I -Wirelessinfo services, Report
from COIN project
[3] Charvat, K at all D1.2.3 Visions and recommendations for knowledge management, Report from
FUTUREFARM project.
[4] Charvat, K., Gnip, P. and Mayer, W., 2009. FutureFarm vision, IPCA congress 2009, Wageningen.
[5] Charvat, K., Gnip P.,Vohnout, P., Charvat, K. jr. VISION FOR A FARM OF TOMORROW, IST Africa
2011, Gaborone, Botswana
[6] Gnip, P., Charvat, K. and Krocan, M., 2008. Analysis of External Drivers for Agriculture, IALD WCCA
INFITA congress 2008 Tokyo.
[7] Jensen, P. A., Bard J. F. 2003. Operations Research - Models and Methods. John Wiley & Sons.


145
4.3.4 An EI/EC Pilot in a Digital Media Living Lab (FAVIT)
Konstantin Hristov
Abstract
In near future every SME in Europe will realize the need to adopt suitable digital media tools for the purpose of their
digital content marketing and act as a media in order to engage target communities around selected topics. On the
other hand the media companies will have to change drastically in response to the challenges posed by the
decentralized, social web. The line between the media company and the SME will merge to large extent as only the
nature of the distributed content would make the difference, but not the technology and tools used. This will create
the need for both company types to use collaboration and interoperability services and work patterns engaging
efficiently with external consumer communities as well as partners and experts outside the business entity.

FAVIT is conducting real situation trials, using the business cases of one Bulgarian SME and
one classic media company to test the usage of collaboration and interoperability tools created by
COIN in connection with the favit platform that is a powerful real-time content distribution tool.
In the process of the live trials the test team measures critical feedback against a set of
specifically developed indicators. The results will contribute to the validation of functionality
set, implementation patterns and exploitation strategies of the tools allowing business entities to
easily and efficiently collaborate and interoperate.
4.3.4.1 Collaboration and interoperability tools used within a digital media environment
FAVIT, an innovative web technology development company and a founding member of the
Digital Spaces Living Lab (DSLL) located in Sofia, Bulgaria is conducting a live trial,
combining selected COIN baseline services with FAVITs cloud based platform for real-time
content distribution with the aim to deploy and test collaborative business processes on top of an
interoperating platform that shall improve the efficiency of digital media ecosystems built in and
around SMEs. With the selection of the actual business use cases as test beds for the live trials,
FAVIT is aiming to address the challenges that SMEs from the EEU are currently facing and
would face in mid-term perspective within the digital media space.

Although massively adopting the social media channels (predominantly blogs, social networks
such as Facebook and Myspace, micro blogging platforms such as Twitter and networking
platforms such as Linkedin), SMEs are the frank losers in the social media revolution. SMEs of
all industries are still unable to successfully establish a social media presence, nor utilize social
media technology and web 2.0 tools and technologies and are largely unable to use various social
media channels to engage and communicate efficiently with the online communities. The self-
stated reasons are:
1. Size: too small (insufficient resources to create content and traction)
2. Capability: lacking resources outside the core business activity to manage online
communities
With the help of our partners within the DSLL we have analyzed the situation/trends related to
the implication that the ever expanding digital media/technology domain causes on the SMEs
from all sectors and decided to conduct live trials involving two SMEs of different types:
1. A media company that faces the challenge to adapt to the new real-time content
distribution, optimizing internal structures and drastically reducing cost in the process
2. A hospitality company that offers touristic services and infrastructure that aims to make
the transition from conventional marketing towards digital marketing relying heavily on
new digital media technologies and compensating lacking in-house skills through
collaboration with external partners
146
In its first use case, with the help of selected collaborative COIN tools in a useful bundle with the
functionality provided by the FAVIT platform we are effectively addressing the challenges faced
by the media companies not only from Bulgaria, but globally:
1. Providing up-to date content on specialized editorial topics (time relevance)
2. Providing trustworthy content in real time (credibility)
3. Providing quality content in real time (enthralling, accurate and exhaustive)
4. Ensuring broad geographical coverage at a minimum cost
5. Ensuring the desired skill set within the editorial team (talent recruitment and
management)
6. Reducing costs
The following indicators are used in order to measure the effect of the live trial:
Reaction times
News delivery time
Cost per news piece
Time relevancy of news content
Content reach
Channel relevance
Media competitiveness

The second live trial tests an innovative concept in the digital media domain: the collaborative
crowd sourced curation as main part of the corporate content marketing. It is about collaborative
curation of business related digital content and multi-channel distribution of that content as part
of the organization's content marketing and advertising strategy. The trial partner is creating and
distributing content like live feeds from slopes and events, news pieces, movies and images as
part of its content marketing. The corporate goal is to:
1. Channel more relevant proprietary and non-proprietary content
2. Achieve a bigger reach of/for that content
3. Perform very efficient campaigns promoting its services

The indicators that shall measure the success/failure of the second live trial are:
Volume of relevant content
Content reach. Number of channels and depth of penetration
Volume and quality of Interaction (likes, comments and re-shares)
Number of subscribers
4.3.4.2 COIN solutions identified and used
The Bulgarian digital media use cases support the COIN vision that its most efficient
exploitation form is as a federated platform rather than a walled garden solution. In this vision
COIN is developing towards an ecosystem consisting of many collaborative platforms
interoperating in sync and accessed through a unified search and distribution interface.
Furthermore, every one of these collaborative platforms acts as an access point to the baseline
services hosted on the central COIN cloud.


147
FAVIT is conducting live trials not only to test several parameters of the already prototyped
collaborative COIN tools but is also fore-playing the interconnection between the COIN
platform with external collaborative platforms. In the process of business analysis we have
identified the following baseline services to be used for the purposes of the Bulgarian digital
media case:
Trusted Online Help and Support (TOHS) helps employers, project managers and others to
dynamically find the right person based on situational awareness; e.g., discovery of and
interaction with an expert who can assist to solve particular problems, requiring specific skill
set.
Interoperability Space Service (ISS) is a negotiation tool for exchanging and negotiating
business documents in UBL format.
Collaboration Virtualisation Tool (CVT) visualizes relations and trust levels within a given
human collaboration network. The tool serves as a complementary tool to TOHS and support
decision making prior to expert engagement and forming of virtual teams. CVT determines
the quality of relations based on previous joint activities, interactions such as communication,
coordination, execution etc.
Creating seamless bridges between the COIN and FAVIT platforms is essential for our
scenarios.
In the process of trial preparation several gaps have been identified. Their rectification would
increase the future exploitation potential of the COIN platform and will make it better suitable
for commercial use.
COIN search interface misses the specific digital media ontology
Interface for dynamically exchanging data between COIN and FAVIT through a standard
COIN API
4.3.4.3 Measured Business Benefits
The following metrics measure the success/failure of every business use case that we conduct:


The business level targets were jointly defined with the trial partners. For the media company use
case they are as follows:
Decrease time to market for news pieces - factor of 8 decrease
148
Decrease cost per news piece - factor of 11 decrease
Increase in daily traffic - 45%
For the touristic use case they are as follows:
Increased community membership - Factor of 5 increase
Increase of communication reach - Factor of 4 increase
Increase in accommodations - 3%
4.3.4.4 Lessons learned
During the preparation of the use cases, the integration, the actual prototype testing and test bed
execution the FAVIT team has acquired considerable feedback that could be categorized as
follows:
1. Collaboration requires a huge shift in mentality: as EEU companies enter into
collaborative groups driven by the fear of being wiped out by someone bigger, or enter
with the expectation to abuse the collaboration for their own benefit.
2. Interoperability is handicapped by fear of being exposed and vulnerable through the data
sharing and the usage and storing sensitive company-related information in the cloud.
3. The User Interface of all COIN tools shall follow strict guidelines. Building bridges of
familiarity between well-known Microsoft Office derived interfaces and the COIN tools
will ease up adoption.
4. Unified help section structure.
4.3.4.5 Exploitation
One account for all the COIN tools and platforms within the COIN ecosystem is a must.
Trade-off between case/tool usage simplicity and company commitment to adopt collaborative
tools
Future COIN marketing/dissemination
1. We have identified a huge marketing potential in the eventual collaboration between
COIN and established (though declining) SME specialized software publishers like
SAGE/DATEV/DAVILEX/AVANQUEST in Europe or INTUIT in the US.
General lessons
1. Living Labs - a great platform to mix academia and the tech industry with the real
business. Very suitable as a multiplier platform.
2. The bigger player not always a good entry point for research projects, but always good
as a multiplier (dissemination and exploitation hub)

References
[1] Social times http://socialtimes.com
[2] The COIN portal http://www.coin-ip.eu
[3] Software shortlist http://www.softwareshortlist.com




149
5 COIN in the Business
The Enterprise Interoperability (EI) concepts and paradigms are being widely accepted as a mean
to improve European Industry competitiveness with respect of the globalized world and markets.
The research activity in this domain, especially the one supported by the European Commission,
has led to significant results and the main technological gaps have been removed or at least
addressed. The COIN EI / EC services are devoted to support the life-cycle of business-oriented
collaborations, from their preparation in proper long-term environments, to their formation
matching business opportunities with possessed competencies, to their operations and
management by measuring and governing proper performance indicators, till to their dissolution
and the re-use of the experience gained.

In this chapter the experience and the scientific activity of the COIN Project is reported in view
of future market applications from adoption of EI / EC Services at supply chains, collaborative
networks and business ecosystems level to new form of business models addressing such
challenging novel technologies. The development of enterprise software as Service-Utility can
offer viable commercial business propositions addressing enterprise interoperability and
collaboration as well as new methodologies (inspired to maturity model) to assess organizations
in their readiness for adopting EI / EC Service in networked environments.
In this chapter: "Supporting EC&EI Services usability and take-up", "SaaS-U Value Proposition
and Business Model", "Bringing COIN to the Market", "Enterprise Collaboration Maturity
Model".

150
5.1 Supporting EC&EI service usability and take-up
Iris Karvonen, VTT
Abstract
The paper focuses on supporting the take-up of Enterprise Interoperability and Collaboration Solutions in supply
chains, collaborative networks and business ecosystems. Software service usability, organization maturity and
participatory development and take-up process are seen as requirements for end user success. To achieve the
expected business benefits, technical development and implementation is not sufficient, but also organizational
implementation and end user involvement is needed. This has been performed in COIN through cross teams of
research, development and end user organizations. The process has been supported by usability assessment,
collaboration maturity analysis and guidelines for the implementation process.

5.1.1 Introduction
Information technology is today not only a support function to make intra- or inter-organizational
processes more efficient but also an enabler for many business and non-commercial activities.
IT, developing towards Future Internet systems, enables also SMEs to participate in global
activities as part of supply chains (SC), collaborative networks (CN) or business ecosystems
(BE).
In COIN project, solutions to support Enterprise Collaboration (EC) and Enterprise
Interoperability (EI) were developed, as described in chapter 3. Achieving the benefits by taking
up IT services, is, however, not automatic even in one organization. In an inter-organizational
environment the challenges are even higher because of heterogeneity and mutual dependencies.
The development of IT towards Future Internet Enterprise Systems (FInES) with software
offered as services and utilities, is expected to remove some difficulties of IT utilization. FInES
are expected to offer more flexible configuration, scalability and openness and decrease technical
barriers [6]. On the other hand, Future Internet does not remove the need to take into account
organizational aspects, especially in cases where several users, functions or organizations are
affected by the system.
The main prerequisites affecting the success of the solution implementation in an organization /
network have been identified as:
adequate usability of the EC & EI service / solution
appropriate inter-organizational implementation process (also affecting the solution fit)
sufficient maturity for collaboration and IT usage in the network.
The factors are dependent on each other and about the scope of the IT implementation. For
example, the maturity of the enterprise affects both on what is usable for each case and how the
implementation should be carried out. The usability requirements are higher for a company with
low experience about collaboration and usage of IT tools (low maturity). Also the inter-
organizational implementation process is dependent, in addition to the service scope also about
the level of collaboration in the network or business ecosystem. If the collaboration maturity is
low, additional actions are needed to create the base for successful implementation.
COIN has supported these three aspects by reviewing and assessing usability, taking a user-
involved approach in the development, developing take-up process guidelines and methods to
analyze and support EC & EI maturity. This paper discusses the first items, analysis of
collaboration maturity is described in chapter 5.4.
5.1.2 Barriers and Challenges for IT take up
Information technology providers claim remarkable gains when using their services. However,
for companies, especially SMEs, it is challenging to achieve the expected benefits by IT take-up.
It may be difficult to understand how to use the technology and how the processes should be


151
changed. The high resources, knowledge and capabilities required for the take up seem to
restrain the adoption of IT in SMEs: Often small and medium-sized companies will not have the
knowledge or resources available to carry out the configuration, adaptation, or integration work
by themselves [5]. The actual implementation of use of ICT in business processes, especially
those involving customers and suppliers, remains limited. [6]. Especially SMEs suffer of
unfinished IT projects, unrealized savings, delays and exceeding the take-up costs. Experiences
gained in earlier implementation projects affect the future users attitudes for a new
implementation project [12] and may hinder the will to start new implementations.
Lack of awareness of the possibilities and benefits that ICT could offer is also considered as one
barrier for ICT adoption by SMEs [6]. The technology and vendors with approaches from onsite
to cloud-based solutions make many SMEs confused and willing to wait until the market settles
down [19]. On the other hand, when always following others the enterprises cannot be in the
lead, gaining the potential competitive advantages [14]. Recently, supporting business
innovation has been seen to become an important objective for future enterprise systems [7].
In collaboration networks, in an inter-enterprise environment the challenges of IT take-up are
higher than in single organizations:
The partners are independent enterprises, they have greater autonomy [15] and the decision-
making is distributed. It may be difficult to reach a common decision about the IT take-up
and understanding about the new processes. Take-up of systems or services supporting
collaboration is not fully successful if all partners are not interested and capable of using
them.
The systems or services are not always as beneficial for each enterprise for some they may
create benefit, while for some others the system may mean only additional work.
Inter-enterprise environment has additional complexity because of more units, functions, and
locations.
There are differences in concepts, cultures, processes, practices, skills and management
styles between network partners.
Openness is not always accepted between organizations. Thus more careful specification of
access rights is needed than inside one organization.
Companies may collaborate within several networks. They are not willing to take up and use
many parallel systems, processes and practises.
Thus, the organizational implementation process needs to be extended to an inter-organizational
process. Inter-organizational ICT implementation may be defined as the process and actions
required to adopt the ICT tools & services into operational use in the network, including the
necessary process changes and end user participation.
On the other hand, the emergence of new IT technologies, like Future Internet Enterprise
Services, is assumed to facilitate the IT utilization. The visions in Future Internet Enterprise
Systems and cloud computing foresee services to be available on-fly, with low cost and with
more flexible configuration, scalability and openness [6]. The services will be available through
generic service platforms and the need for local technical software set-ups will decrease. Thus,
the technical barriers for IT utilization are envisaged to decrease. The availability of low cost
services should also remove some economic constraints, at least for mass-services.

Still, understanding how to use the on-fly services in the organization and between
organizations, is needed. This should be built in the take-up process in collaboration and
interaction of the actors. Showing the full benefit of the ICT thus requires that not only
technology but organizational aspects are taken into account in the take-up process. One method
is the involvement of different stakeholders in multi-disciplinary teams (cross-teams). It is
152
foreseen that the power in the development of future enterprise systems will progressively move
from IT specialists to business experts [7]. As the technology is expected to evolve into easier
and more usable systems and services, the significance of the organizational take-up process will
increase.
5.1.3 Development approach: Cross-teams
The development of services in COIN was performed with two main cycles, from end user
requirements through development and testing to take-up and demonstration. Six end users,
representing Collaborative networks (CN), supply chains (SC) and Business Ecosystems (BE)
were involved in the development. At a later phase of the project, 6 additional test cases were
taken to the project. These are described in chapter 4 of this book.
To ensure the interaction of research and development and end users, cross-teams were
organized around each end user scenario. The end users acted as the cross team leaders. In
addition to informal interaction the development process was supported by usability assessment
of the developed services, performed by end users. The assessment was built on existing
approaches for usability, adapted for the context of Enterprise Collaboration & Interoperability
and taking into account the requirements of end users. The consolidated feedback as
recommendations for development were shared and discussed with the developers, to make
improvements in the next development cycle.
To support also future users, not only the partners involved in the development phase, guidelines
for the take-up of COIN services were developed. The development was based on the
identification of implementation challenges, both from the previous research and from the
experience of COIN end users, reviewing the existing models for software lifecycle and
implementation process and development of success criteria for COIN context [11].
5.1.4 Contributing to usability in EC &EI context
5.1.4.1 Usability definition
As discussed before, usability of a service or a system is seen as an important condition to
achieve end user acceptance which is needed for realization of benefits. There are different
definitions for usability. Abran, et al. [1] and Seffah et al. [17] present collections of usability
definitions from different standards. ISO9241-11, 1998 defines usability as the extent to which
a product can be used by specified users to achieve specified goals with effectiveness, efficiency
and satisfaction in a specified context of use. Software is usable when it allows the user to
execute his task effectively and with satisfaction in the specified context of use.
In addition to different standards, there are also other usability frameworks or metrics, like
MUSiC (Metrics for Usability Standards in Computing), DRUM (Diagnostic Recorder for
Usability Measurement), QUIM (Quality in Use Integrated Measurement) consolidated model
[17], Enhanced Usability Model [1], Hornbaek [8], Shaw et al. [18], Leung (2001) and iSURF-
project approach [20]. The usability attributes of the different frameworks are quite similar.
Effectiveness, efficiency and satisfaction are present in most frameworks, some attributes, like
understandability, learnability or memorability are not as common. Different attributes for take-
up and maintenance are presented (portability, adptability, flexibility, customisability). Some
approaches identify safety, security or reliability as part of usability, for some it is not included.
Definition and contents of usability is dependent on the context. To support the usability
assessment of COIN services, a COIN specific definition of usability contents was created. The
definition of usability in COIN had 7 dimensions:
Effectiveness the benefit / value to the company/ network .
Efficiency- the performance of the service.
Understandability - how understandable the service is for the user.


153
Satisfaction & Attractiveness do the users feel satisfied with the service?
Learnability, memorability - How easy it is to learn to use the system and return back after a
break in usage.
Use preparation & maintenance How easy the service is to take into use and maintain.
Suitability to network/collaborative environment How well the service fits to network
environment.
The dimensions and the the background information is presented in more detail in [3].
5.1.4.2 Usability assessment in COIN
The seven dimensions were developed further into a usability assessment excel-tool to support
COIN service development. In this way user feedback on usability was received during the
development phases, to support going towards simplification and usability of the solutions. In the
test phase, end users gave also recommendations for the service development. To support the
interaction in the cross-teams, and to ensure, that the developers are aware about the end user
views, the recommendations were consolidated and circulated among the developers and the
developers were asked to give their response for each recommendation: what they plan to do
with it.
Most of the services were tested by more than one end user and similar recommendations
appeared in the feedback of different users. The most repeated recommendations related to:
more guidance and training; 18 recommendations dealt with this
understandability, learnability, user interface, visualisation; 10 recommendations
usage of local language: 5 recommendations
supporting data input/ creation: 4 recommendations
addressing legacy systems: 3 recommendations
security and safety: 2 recommendations
Additionally service-specific proposals were given. The recommendations were used for further
development.
5.1.5 Development of COIN take-up guidelines
5.1.5.1 COIN end users experience before COIN
COIN end users represent different industrial fields and collaboration forms. To review the
challenges and practices of IT take-up in their collaboration environment a collection of the end
users experience before COIN was performed about:
barriers hindering the take-up: which factors decrease the interest of enterprises to start the
implementation process?
challenges in the take-up process: what kind of experience do the end users have about
implementing IT services in their environment?
The barriers and challenges are of course interlinked, as many of the barriers come from
challenges experienced in earlier projects.
The main barriers identified were:
The benefits of IT take-up are not seen clearly enough, the potential is not known or the
benefits go to someone else.
There is a resistance to change and the take-up is considered too complex.
The take-up is expected to have high costs and cause too much additional work.
154
There is a risk of failure, delays and even dropping out of the business.
The enterprises need to believe in the security of the solution and to be convinced about the
sustainability of the solution and the solution provider.
To overcome these barriers the end users expressed a need for success stories, visibility, strategic
approach and demonstration of benefits. Demanding customers may act as an important driver
for the end users to take steps towards IT utilization.
Experienced challenges included:
lack of information or understanding of the tool and lack of training,
slow progress of implementation, excessive functions, tool structure, volume of data
communication problems, problems with multi-disciplinary teams
user attitudes, too low readiness for the take-up, and end users unwillingness to use the new
tool, cultural behaviour and aspects
Based on the experience, requirements for success involved sufficient communication,
management commitment, end user acceptance, user support, customised training, roll-out
project planning and management etc. It was essential to ensure the business continued operating
whilst implementing a new system. The following recommendations for IT roll-out were
identified:
Agree IT strategy and benefits, assess complexity of implementation, calculate costs based
on worse case scenario, assess skills and resources to implement, engage core team for
implementation, and formal training in place.
Management support is needed; 100 % top management commitment which is also visible, is
essential.
Define responsibilities, clear business case, ensure programme delivery personal and
structures are in place, maintain a global common approach, and allow for local practice.
Large scale deployments require dedicated teams to deliver.
Technological issues have to be in order, language problems have to be taken in account,
definition of super users and key users. Testing data and interoperability of systems, ensure
larger portion time is taken for testing and de-bugging.
For distributed systems engage local champions as part of the design process, check the
compatibility to the local culture. Check the status of the infrastructure.
Capture the tacit knowledge of the end user but dont allow the old system to be designed
into the new system, due to local job protection.
These end users recommendations have been used to develop the critical success factors
presented in chapter 5.1.5.3.
5.1.5.2 COIN end users lessons learnt of COIN process
During the second piloting phase and while starting the demonstrations a collection of
preliminary lessons learnt from COIN end users was organized. One of the topics was COIN
process from requirements to testing. The lessons learnt are described more in [4].
COIN started with the identification of requirements of end users. In COIN, a novel approach of
serious gaming was used. All the end users regarded the approach very interesting, supporting
the innovative thinking and bringing together people from different industrial fields. There were
some suggestions to improve the approach, for example by specifying the available services and
integrating them into the gaming scenario or focusing more on covering the real aspects of the
business.


155
The two cycles of COIN (requirements, development and testing) were considered necessary by
the end users to affect the service development. It was proposed that, instead of following the
same approach for both cycles, the first one should be more focused on the conceptual testing:
how the tools should be used and how well the tools support, how they change the processes, not
so much about technical testing. The technical testing should be done in the second phase.
The cross-team approach of COIN, where the research partners, developers and end users
collaborated in different COIN phases, received many comments from the end users. All end
users considered it as a good and necessary approach. The cross-team approach was not defined
and started in the beginning of the project, but only after the first requirements phase. This was
partly because in the beginning of the project it was left open for the users which services they
are interested to test and demonstrate. Several end users, however, proposed that the cross teams
should start immediately in the beginning of the project. They also suggested that the work
packages could be organized around the cross teams, that the cross team structure should be
more simple and that the cross teams could have a double-lead of end users and R&D partners.
Also some proposals aiming for higher innovation, not limiting the cross teams by predefined
rules were given. The cross-team approach was also seen beneficial to be used at a larger scope,
for example in regional development (e-technologies based regions).
There were some comments about training: The training activities are considered a must for
the end users. Training should be more focused on end users or there should be specific training
events and material for users. Now the first training event was considered to be too much IT
technology. Also the approach of lectures on the training site is not sufficient for users. There
was a suggestion that the end users could themselves be involved in the creation of the training
material, supported by cross teams. This would also support the learning process.
5.1.5.3 Critical success factors OF EC & EI take up
To support successful implementation, IT research has identified best practices as critical success
factors, guiding the activities of organizations in the implementation process. Critical success
factors (CSF) are defined as the limited number of areas in which results if they are satisfactory,
will ensure successful competitive performance of the organization [16] or key areas of
performance that are essential for the accomplishment of a mission or project, i.e. the fields in
which satisfactory results ensure the attainment of goals [2]. Thus CSFs describe the activities
and conditions for success, not only being in time and budget but also achieving the expected
benefits.
As part of COIN guidelines, critical success factors for EC & EI context were defined. The
definition was based on enrichment and adaptation of CSFs from previous research, and using
the experience of COIN end users received in COIN workshops (see chapters 5.1.5.1-2). The
resulting list of 23 factors was grouped to 6 categories:
1. Management and vision
2. Solution selection
3. Organization of take-up
4. System and process adaptation
5. User involvement into the take-up process
6. Take-up phases
The factors were validated with a questionnaire to the end users. The questionnaire asked the end
users to assess for each factor the importance of the factor in the context of IT supporting
collaboration and interoperability and the current level of practice in the end users organization:
Is the factor currently considered and put into practice in the network/ ecosystem of the end user
organization when taking up IT solutions? The results of the questionnaire showed that all the
156
success factors proposed were assessed important in this group of collaborating enterprises and
that for many factors the level of practise was quite low even if the importance was recognized.
The critical success factors are described more in [11] and in [4].
5.1.5.4 COIN take-up process and guidelines
There are different descriptions of the software lifecycle presenting the main phases and tasks to
be performed in each phase. European Commission has recently published an e-Business guide
for SMEs [5]. The guide focuses on the selection of e-Business solution and the solution
provider; additionally software introduction phase is described. The introduction phase includes
activities like configuring the product, training, carrying out organisational changes etc.
One of the most used description of best practices covering the whole software product lifecycle
is ITIL IT Infrastructure Library, [9]. The viewpoint is that of the end user IT management.
The system is quite heavy even for large enterprises and would need simplification for SMEs.
Both ITIL- SW service management description and the e-Business guide [5] describe the
situation from the viewpoint of one single company. The IT selection or management is the
decision of a single company. However, in a collaborative environment there may be a need to
make common decisions or harmonize the decisions, even if the companies are autonomous.
This means that the take-up process includes also collaborative activities.
To support guideline creation, a reference implementation scenario, with end user requirements,
was first defined in COIN. Further this scenario was developed into a COIN take up process,
describing the different phases of the take up. The aim was to slightly simplify the scenario and
utilize the terminology and the experience gained during COIN. The resulting take-up process is
described in Figure 70.
COIN guidelines are built on this take-up process [4]. The guidelines are directed to potential
users of EC & EI services, both for COIN end users and potential newcomers. For each phase of
Figure 70 guidance was developed, giving for each phase a description of:
prerequisites or needed inputs,
actions needed in this phase, methodologies which can be used
output of the phase
information about COIN tools and material which could support the phase
influence of collaboration environment (COIN context)
success criteria relevant in the phase.
As the starting point and reasons for taking up EC & EI services may be different in different
cases, also the scope and scale of the take-up may vary. The need and extent for each phase
depends on the scope. If the objective is just to solve a single, well defined collaboration or
interoperability problem, the take up process may be quite concise. The larger the scope and
scale, the more analysis, planning, designing, training and communication resources are required.
Also, the borders between the different phases are not clear; what is performed in which phase
also depends on the context and situation (for example if the services to be taken up are known
already in the beginning or not).


157

Start of process:
-Problems/gaps in collaboration identified
-Changes of business (products, partners, globalization)
Decision and pre-planning:
- decision about EC/EI service take-up in CN/SC/BE
- Preliminary planning and process set-up
Baseline analysis & requirements & goals:
- as-is business process modeling,
-Requirement identification
- set up of objectives /collaborative vision
To-be processes, service selection and data:
-EC &EI service search and identification
- to-be processes, workflow set-up
EC &EI service set-up and rollout through the
CN/SC/BE
- creation of ontology, identification of data, legacies
Further improvement and maintenance
- follow-up and modification of processes

Figure 70 - COIN take-up process

5.1.6 Conclusion
This paper describes experience and guidelines to support the utilization of IT solutions and
services in the COIN context, with the end user viewpoint. The COIN context is the development
and take-up of Enterprise Collaboration (EC) and Enterprise Interoperability (EI) services in the
Future Internet environment. The vision is that the EC & EI tools and services are developing
towards commodity, service utilities, which can be called easily and with low cost from the
Internet.
While the cost of software is expected to decrease in the Future Internet environment, the cost of
the implementation and maintenance is coming crucial for the enterprises. Even now in many
cases the costs of take-up process are higher than the cost of the software. In future, this will be
further stressed. The FInES Position Paper 2011 [7] includes a vision about user-generated
business applications and puts even more weight to the users in the take-up process: The power
and control in the development of future enterprise systems will progressively move from IT
specialists to business experts.
In this paper the following prerequisites for successful IT implementation in a network have been
identified:
adequate usability of the EC & EI service / solution
appropriate inter-organizational implementation process (also affecting the solution fit) ; a
cross-team approach is recommended.
sufficient maturity for collaboration and IT usage in the network.
This paper discusses the challenges in the first two themes and develops approaches to overcome
them.
158

References
[1] Abran, A., Khelifi, A., Suryn, W. (2003) Usability meanings and Interpretations in ISO standards. Software
Quality Journal, 11, 325-338.
[2] Araujo, I. (2006), Critical Success Factors for ERP Deployments in International Federation for Information
Processing, Volume 205, Research and Practical Issues of Enterprise Information Systems, eds. Tjoa, A.M.,
Xu, L., Chaudhry, S., (Boston:Springer), pp.319-324.
[3] COIN 2009. COIN (EU-FP7-216256) Deliverable D64.1a EC &EI inter-organizational implementation
methods. November 2009. www.coin-ip-eu.
[4] COIN 2011. COIN (EU-FP7-216256) Deliverable D64.1b EC &EI inter-organizational implementation
methods. June 2011. www.coin-ip-eu.
[5] EC (2008) eBusiness Guide for SMEs. eBusiness Software and Services in the European Market, European
Communities 2008. http://ec.europa.eu/enterprise/e-bsn/ebusiness-solutions-
guide/docs/eBusiness_Guide_for_SMEs.pdf, accessed November 2009.
[6] FInES (2009) Position Paper. Final version 1.9.2009. Future Internet Enterprise Systems (FInES) Cluster.
European Communities 2009.
[7] FInES (2011) Position Paper on Orientations for FP8. A European Innovation Partnership for European
Enterprises. Version 3.0 21.1.2011. Future Internet Enterprise Systems (FInES) Cluster. European
Communities 2011.
[8] Hornbaek, K. (2006) Current practices in measuring usability: Challenges to usability studies and research.
Int. J. Human-Computer Studies 64 (2006) 79102.
[9] ITIL 2007. An Introductory Overview of ITIL V3. Best Management Practice. itSMF; The IT Service
Management Forum.
[10] http://www.itsmfi.org/files/itSMF_ITILV3_Intro_Overview_0.pdf. accessed March 2009
[11] Karvonen, I. (2011). Towards Achieving Benefits of IT Utilization in Collaboration Networks, Proceedings
of Pro-VE 2011, Sao Paulo, Brazil, October 2011.
[12] Koskinen,M. (2006). On the Role of Interpretation Schemes in Organizational IS Implementation. In
Proceedings of the 39th Hawaii International Conference on System Sciences.
[13] Leung, H. K.N. (2001) Quality metrics for intranet applications. Information & Management 38 (2001)
137-152.
[14] Li, M-S.: Enterprise activity in the Future Internet Assembly. 2010. FInES cluster meeting 2.6.2010.
http://cordis.europa.eu/fp7/ict/enet/fines-meeting-20100602_en.html 2.7.2010
[15] Munkvold, BE. (1999). Challenges in IT implementation for supporting collaboration in distributed
organizations. European Journal of Information Systems (1999) 8, p. 260-272.
[16] Remus, U. (2007). Critical success factors for enterprise portals. A comparison with ERP implementations.
Business Process Management Journal. Vol 13, No 4, pp538--552.
[17] Seffah, A.., Donyaee, M.,Kline, R.B. (2006) Usability measurement and metrics: A consolidated model.
Software Quality Journal 14(2006): 159-178.
[18] Shaw, N., Farhi, N., Taylor, P., Sambasivan, N. (2009) Initial usability criteria. The Bijou Crew.
http://www.cc.gatech.edu/~nithya/initial.html, accessed 11.5.2009.
[19] silicon.com: The practicalities of unified communications and collaboration. 2009.
http://www.silicon.com/special-features/unified-communications/2009/11/17/unified-comms-what-it-
needs-to-succeed-39653038/ .
[20] Vieira, H. M., Ferreira, F.L., Kennedy , J., Jardim-Goncalves, R. (2008) Evaluation and Testing as support
for a consistent Architecture development. eChallenges 2008. Paper For Workshop Session " Isurf: An
Interoperability Service Utility For Collaborative Supply Chain Planning "


159
5.2 Saas-U Value Proposition and Business Models
Man-Sze Li
1

1 to complete
Abstract
This paper presents the COIN research into interoperability as a utility-like capability as articulated by the
Interoperability Service Utility (ISU) concept of the Enterprise Interoperability Research Roadmap, and instantiated
in COIN as SaaS-U. The paper explores the following key research questions: What is the value proposition for
Enterprise Interoperability / Enterprise Collaboration in the forthcoming decade? Are utility services in principle
economically viable in ICT? What is an Integrated Value Proposition of Enterprise Interoperability? What are the
conclusions of applying the notion of Open Innovation in the field of Enterprise Interoperability? Does the utility-
based business model support enterprise innovation? The paper concludes that the value proposition for Enterprise
Interoperability and Enterprise Collaboration will become increasingly distinct and different in the coming years.
Experimentation of the SaaS-U business models is needed and should be encouraged..

Keywords: Interoperability Service Utility, utility services, value added services, value proposition, business models,
ICT, Future Internet
5.2.1 Introduction
The scope of the COIN research on SaaS-U Business Models, as for COIN as a whole, is that of
networked enterprises with a focus on Enterprise Interoperability (EI) and Enterprise
Collaboration (EC) as established in the Enterprise Interoperability Research Roadmap, the
original version of which was published in 2006. The specific areas include: why enterprises
need to interoperate, how enterprises interoperate, as well as what constitutes interoperability as
a capability. Enterprises need to collaborate in order to compete, and there will be many different
forms of collaboration. Collaboration will be key to enterprise innovation, enabled by
interoperability as a capability. Increasingly, the only comparative advantage that an enterprise
will enjoy will be its process of innovation. The standpoint is that enterprises must be the
primary beneficiaries of Enterprise Interoperability solutions. This scope has been further
affirmed in the report on Value Proposition for Enterprise Interoperability published by the
European Commission in 2008. In particular, that report demonstrates that interoperability as a
utility-like capability is essential for enabling business innovation and value creation. Moreover,
Future Internet technologies will re-shape interoperability as a capability, leading to the need to
reappraise interoperability between enterprises. The report introduces Future Internet Enterprise
Systems (FInES), which are very much part of the Future Internet paradigm.
The notion of interoperability as a utility-like capability is described by the concept of the
Interoperability Service Utility (ISU), as published in the Enterprise Interoperability Research
Roadmap and summarised in the following table.
160
FInES Cluster meeting, Brussels, 12 November 2009
5
Interoperability Service Utility - ISU
Source: Enterprise Interoperability Research Roadmap
Delivery of IT as services
Interoperability as a
utility-like capability for enterprises
a public good
ISU as a basic infrastructure that supports
information exchange between knowledge
sources, software applications and Web
services
a new generation of self-* services and e-
business services
connection between islands of
interoperability
especially SMEs and start-up companies
ISU is independent of, rather than an
extension to, EI solutions on the market
Internet
Web
ISU
Value-added and proprietary IT services
Collaborating Innovation Ecosystems
Collaborating Enterprises
Telecommunications
Conceptual View of the ISU

Figure 71 ISU Summary

The ISU is a Utility Infrastructure. It comprises Utility Services, with the following key
properties:
Cheap and near universal access
Seamless Quality of Service across multiple providers
Well understood, regulated and monitored service properties
Potentially high internal complexity, but limited external configurability/heterogeneity
Well-defined and standardised interfaces for utility usage and control
Ease of use.
Utility services are to be contrasted with value added services, provided by a third party over an
ISU inspired infrastructure and makes use of one or more utility services of the infrastructure. A
Value Added Service provides added value to specific user(s) of this service.
In COIN, SaaS-U is an instantiation of the ISU, from the perspective of business models.
Specifically, within the context of COIN, SaaS-U is a business model which postulates an
evolutionary path from software as a service (SaaS) to the provision of such services as utilities,
with a focus on EI and EC Services.
The key research questions are:
What is the value proposition for Enterprise Interoperability / Enterprise Collaboration in the
forthcoming decade?
Are utility services in principle economically viable in ICT?
What is an Integrated Value Proposition of Enterprise Interoperability?


161
What are the Conclusions of applying the notion of Open Innovation in the field of
Enterprise Interoperability? Does the utility-based business model support enterprise
innovation?
To answer these questions, the research has explored a number of business scenarios and models
for the implementation of the SaaS-U concept, in the following application domains, to
complement the research into implementing the ISU as a business proposition:
SaaS-U @ Energy
SaaS-U @ Health
SaaS-U @ ESA Enterprise Software and Applications.
5.2.2 Assumptions and Hypotheses
Our basic assumptions for the research, as for COIN in general, are as follows:
ICT as a whole is a critical infrastructure for all enterprises
14

Enterprise processes will be subject to increasing commoditisation
IT capabilities will be subject to increasing contextualisation in order to better serve business
needs
EI and EC services in the 2020 vision of the COIN project are key services to be provided in
the Future Internet Enterprise Systems (FInES), which could be variously applied in and
across specific application domains using a combination of ICT technologies. The
developments of such technologies are increasingly aligned with developments of the future
of the Internet.
Our overall hypotheses for all business-related outputs of COIN are:
SaaS will undergo further transformation as existing service paradigms evolve and
potentially disruptive new service paradigms emerge
All IT applications may be delivered as services and available via SaaS as a business model
Interoperability (in particular Enterprise Interoperability and Enterprise Collaboration as
defined within the COIN Project as in the two sides of the same coin) realised as a
commoditised technical functionality, delivered as services, and independent of particular IT
deployment is key to the infrastructure of a new generation of software-based services and
applications
That infrastructure potentially constitutes a new level of functionality that forms part of the
Future Internet architecture
That infrastructure enables new forms and mechanisms of innovation
New relationships between supply and demand in the application domain will emerge.
5.2.3 ISU Value Proposition and Business Model
The ISU Opportunity
Our research indicates that the ISU opportunity could be summarised by three arguments:
The economic argument: ICT trends towards commoditisation, continuously eroding the cost
base of providing services

14
On the basis that the Future Internet represents the future of ICT, this could be elaborated as the Future Internet
will provide a critical infrastructure for all enterprises, which is itself an articulation of the FInES Cluster vision of
the Internet being a universal business system.
162
The public interest argument: some services offered over the Internet are part of the fabric of
the economy and society, essential for all businesses or for minimum quality of life
The competition argument: a level playing field in basic (utility) service provisioning for
advancing open competition, greater transparency and unfettered innovation through new,
value added services.
Why the ISU is Important
The original main motivation of the ISU was to increase the capability of SMEs to join new
markets, based on the observation of low ICT adoption by European enterprises in general, and
SMEs in particular, beyond basic Internet connection and a footprint on the Web.
Since then, the ISU motivation has been further extended by linking a universal service utility
infrastructure with the development of the Internet, and specifically the need for such an
infrastructure to catalyse the development of new types of value added services and new models
for the provisioning of such services.
Thirdly, software and service enabled value creation has been linked to enterprise business
model experimentation to deliver innovation at the business level. In other words, the ISU is
potentially enabling a new set of relationships between the ICT industry and enterprises.
Fourthly and most importantly, the main argument for the ISU, just like the Internet, is
innovation purposive or serendipitous. In particular, the ISU enables a positive feedback loop
for innovation by providing unbounded and potentially unlimited opportunities of value creation
that benefit the end users.
The ISU and the Future Internet
With reference to the development of the Future Internet, the ISU potentially constitutes a
fundamental shift in terms of:
The way in which the Internet will operate and serve its users, particularly the enterprises
which is the focus our research
15

The business models for the provisioning of services, including service infrastructures and
services enabled by those infrastructures
The Internets technical structure.
Ultimately, the ISU must have a positive impact on the capabilities of enterprises as end-users.
This has several major implications in respect of the role of the ISU, the paradigm of the ISU, the
openness of the ISU and the positioning of the ISU in the Future Internet, as follows:
The ISU is an enabler both for service provision and service consumption, as well as
interaction between provision and consumption including pro-sumption. The technologies
and services that comprise the ISU are means to serve the needs of users; they are not ends.
At the service infrastructure level, the paradigm of the ISU must be any-to-any. The services
at this level must be commonly shared, transparently discoverable, and capable of living in
an open and dynamic environment. Accordingly, they must have properties that comply with
those characteristics and consistent levels of performance that can be guaranteed to the user
(see Section 2).
The ISU infrastructure itself must be open, in the sense that: (1) it is not locked into any
technology paradigm or service platform; (2) it is not owned or controlled by any entity; (3)
its development and growth is based on participatory input, as opposed to being channelled

15
It should be borne in mind that enterprises are one category of users of the Internet. Users of the Internet may be
categorised in different ways critically, this depends on the definition of the Internet Market. However, as of to
date, no authoritative and definitive definition of the Internet Market exists. The European Commission is launching
a study to develop such a definition.


163
through makers of the infrastructure; and (4) it has no bias towards business models or
service ecosystems, existing or emerging.
The ISU infrastructure is part of the Internet of the future. It should enable and allow for
seamlessness of information, applications, services, networks, provisioning and usage to the
edge of the network. The ISU should not make a priori assumptions about function
placement which restrict business model experimentations by providers or users.
Just like the current Internet, the serendipitous and disruptive innovation predicted in a
variety of Future Internet visions will not be borne out of chaos, but instead rest on a
combination of emerging common and standard infrastructures and the opportunity of
creativity this enables.
For whom the ISU is Important
The value of the ISU lies in the value it offers to enterprises as end-users - it stems from the
ISUs positive impact on the capabilities of enterprises. In other words, the demand and supply
value creation equation of the ISU must have a positive balance in favour of the demand side.
But the full ecosystem of the ISU is vast and still nebulous. However, for the purpose of value
attribution and accretion, we may broadly identify six categories of stakeholders, subject to the
following caveats:
A particular entity could be present in one or more categories
A particular entity could be simultaneously both a utility service provider and a value added
service provider
The demarcation between supply and demand, while important for the accounting of value
accretion, could be blurred from the point of view of a stakeholder. In particular, service
pro-sumption blurs the distinction between providers and consumers of particular services
Given the scope of this document, we have considered only enterprises as end users; there
are of course other groups of end users including notably public sector organisations
Public authorities as potential investors and regulators and more are presently not included in
the stakeholder categories. We will be addressing the role of public authorities in the next
phase of the research.

The stakeholder categories are presented in the following figure.
164
Enterprises
Collaboration
Networks
Service &
Application
Intermediaries
Service
Providers
Platform
Providers
Infrastructure
Providers
Enterprises
Collaboration
Networks
Service &
Application
Intermediaries
Service
Providers
Service &
Application
Intermediaries
Service
Providers
Enterprises
Collaboration
Networks
Platform
Providers
Infrastructure
Providers
Service
Providers
Platform
Providers
Infrastructure
Providers
Service
Providers
Platform
Providers
Infrastructure
Providers
Service &
Application
Intermediaries
Enterprises
Collaboration
Networks
Infrastructure
Providers
Service
Providers
Platform
Providers
Supply Demand
Infrastructure
Providers
Platform
Providers
Infrastructure
Providers
Service
Providers
Platform
Providers
Infrastructure
Providers
Service &
Application
Intermediaries
Service
Providers
Platform
Providers
Infrastructure
Providers
Collaboration
Networks
Service &
Application
Intermediaries
Service
Providers
Platform
Providers
Infrastructure
Providers
Enterprises
Collaboration
Networks
Enterprises
Collaboration
Networks
Service &
Application
Intermediaries
Enterprises
Collaboration
Networks
Service
Providers
Service &
Application
Intermediaries
Enterprises
Collaboration
Networks
Platform
Providers
Infrastructure
Providers
Service
Providers
Platform
Providers
Infrastructure
Providers
Added Value
U
T
I
L
I
T
I
E
S
Platform
Providers
Infrastructure
Providers
Service
Providers
Platform
Providers
Infrastructure
Providers
Service &
Application
Intermediaries
Service
Providers
Platform
Providers
Infrastructure
Providers
Collaboration
Networks
Service &
Application
Intermediaries
Service
Providers
Platform
Providers
Infrastructure
Providers
Enterprises
Collaboration
Networks
Service &
Application
Intermediaries
Service
Providers
Platform
Providers
Infrastructure
Providers
I
N
D
U
S
T
R
Y

D
O
M
A
I
N
APPLICATION DOMAIN
TECHNOLOGY DOMAIN

Figure 72 ISU Stakeholder Categories

As already mentioned, the ISU enables a new set of relationships between stakeholders,
including those within the ICT industry. Recognising that the structure of the ICT industry is
already changing, most recently triggered by so-called Cloud Computing, it should nevertheless
be emphasised that the incumbents, under existing classifications, could become key providers of
both utility and value added services. The ISU is not premised upon a re-invention of the ICT
landscape; rather, it enhances that landscape by opening up new possibilities and value
proposition.
The following table provides an illustration of example ISU providers and their classification.
Table 9 - Example ISU Providers and their Classification
Utility Service Providers Value Added Service Providers
(Aggregators)
Value Added Service Providers
(Integrators)
Specialised software companies
Large companies with
specialised service capabilities
Web 2.0 companies
Telcos, ISPs and other current
web infrastructure providers
Hardware companies
Focused startups
First generation B2B companies
Industry hubs
Large companies with
specialised service capabilities
Web service hosting and
management companies
EAI vendors
System integrators
Focused startups

Software vendors
System integrators
Hardware companies
Web 2.0 type (user)
communities

As the utility services are defined as being provided at very low or even nil cost, defining the
cost of utility services is key to building the investment profile. Using conventional economics of
supply-demand, two cost models have been identified, as illustrated in the following table.



165
Table 10 - Cost Models for ISU
Profitability cost: the loss in profits incurred by the operator due to the utility services
Measurement Compare the profit levels of the operator under the alternative market equilibria: with and
without utility services
Problem Based on pure accounting argument
Comparison only meaningful where prices and market structure are assumed to be
constant with or without utility services
Assumption that the operator accrues no direct benefits from serving non-profitable
consumers
Assumption that the operator accrues no direct benefits from leveraging the utility
services (e.g. some form of bundling with value added services)
Assumption that the operator faces no profit constraint or the profit constraint is constant
Welfare cost the loss of total surplus (consumer plus producer) implied by the Utility Services
Measurement Compare the total surplus achieved at a hypothetical equilibrium without the Utility Services
with the total surplus realised with the Utility Services
Problem How to determine the hypothetical equilibrium
Result dependent on technique used to maximise total surplus (e.g. the efficiency
argument, where the market price equals marginal utility)
Have no means to take account of price and benefit differentials along the long tail
Have no means to balance the efficiency-based cost against redistributive benefits which
depend on the weights of the different groups in the public authoritys social welfare
functions (e.g. SMEs, ICT start-ups)
Comparison only meaningful where prices and market structure are assumed to be
constant with or without utility services

However, neither of the above is ultimately appropriate in that neither takes into account:
The cost of creating the ISU
The pressure on price due to commoditization
The possibility of subsidies, tax and other direct or indirect economic incentives
The characteristics of the economics of information goods (intangibles)
Co-creation, pro-sumption, open source models, and other new phenomena
In conclusion, building the investment profile for the ISU is a highly non-trivial exercise and is
fraught with problems even at the theoretical level. Specifically:
The model cannot rely on pricing based on traditional supply-demand and Pareto Optima
The model cannot rely on efficiency equity trade-offs
The market is not competitive-neutral, whether it can become so in future is an open question
(and some would consider this as a circular argument because open market competition for
service-based applications is itself dependent on the availability of the ISU)
The market structure cannot be assumed to be static (our first hypothesis of the ISU).
Therefore, in order to develop a meaningful investment profile for the ISU, there is a strong
argument for a new economic model to define the cost and price schemes of utility services. This
economic model/argument needs to be aligned with a public interest model/argument and a
competition model/argument (the three arguments which comprise The ISU Opportunity as
defined above).
We have moreover identified a large number of input variables for building a business model for
the ISU, as indicated in the following table.

1
6
6
T
a
b
l
e

1
1

-

I
S
U

B
u
s
i
n
e
s
s

M
o
d
e
l
s

I
n
p
u
t

V
a
r
i
a
b
l
e
s

B
u
s
i
n
e
s
s
-
E
c
o
n
o
m
i
c
s

T
e
c
h
n
o
l
o
g
y

P
o
l
i
c
y

O
t
h
e
r
s

G
r
o
w
t
h

o
f

t
h
e

s
e
r
v
i
c
e

s
e
c
t
o
r

o
f

e
c
o
n
o
m
y

P
u
b
l
i
c

w
e
b

s
e
r
v
i
c
e
s

A
c
t
i
v
e

c
o
m
e

b
a
c
k

o
f

t
h
e

s
t
a
t
e

D
i
g
i
t
a
l

N
a
t
i
v
e
s
,



G
e
n
e
r
a
t
i
o
n

Y

/

Z


I
T

s
p
e
n
d
i
n
g

b
y

e
n
t
e
r
p
r
i
s
e
s

D
e
v
e
l
o
p
m
e
n
t

o
f

W
e
b

2
.
0

t
o
o
l
s

a
n
d

E
n
t
e
r
p
r
i
s
e

2
.
0

C
o
m
p
l
e
t
i
o
n

o
f

D
i
g
i
t
a
l

S
i
n
g
l
e

M
a
r
k
e
t

E
n
t
e
r
p
r
i
s
e

a
t
t
i
t
u
d
e

t
o
w
a
r
d
s

I
T

d
o
e
s
n

t

m
a
t
t
e
r

I
T

s
p
e
n
d
i
n
g

b
y

S
M
E
s

D
e
v
e
l
o
p
m
e
n
t

i
n

p
r
o
-
s
u
m
p
t
i
o
n

o
f

s
o
f
t
w
a
r
e

b
a
s
e
d

s
e
r
v
i
c
e
s

P
o
l
i
c
y

f
o
c
u
s

o
n

I
n
n
o
v
a
t
i
o
n

D
e
v
e
l
o
p
m
e
n
t

o
f

a
d
v
a
n
c
e
d

I
C
T

i
n
f
r
a
s
t
r
u
c
t
u
r
e
s

i
n

u
r
b
a
n

a
r
e
a
s

B
r
o
a
d
b
a
n
d

r
o
l
l
o
u
t

D
e
v
e
l
o
p
m
e
n
t

o
f

C
l
o
u
d

C
o
m
p
u
t
i
n
g

(
e
s
p

m
i
g
r
a
t
i
o
n

o
f

f
u
n
c
t
i
o
n
a
l
i
t
y
)


C
o
m
p
e
t
i
t
i
o
n

P
o
l
i
c
y

t
o
w
a
r
d
s

M
o
n
o
p
o
l
y
,

O
l
i
g
a
r
c
h
y

e
t
c


P
u
b
l
i
c

a
t
t
i
t
u
d
e

t
o
w
a
r
d
s

s
o
c
i
a
l

m
a
r
k
e
t

e
c
o
n
o
m
y

G
r
o
w
t
h

o
f

S
a
a
S

T
e
c
h
n
o
l
o
g
i
e
s

t
o

e
n
a
b
l
e

n
e
a
r
-
u
n
i
v
e
r
s
a
l

Q
o
S

&

a
v
a
i
l
a
b
i
l
i
t
y

o
f

Q
o
S

m
e
t
r
i
c
s

a
t

t
h
e

s
e
r
v
i
c
e

l
e
v
e
l

E
n
t
e
r
p
r
i
s
e

P
o
l
i
c
y

o
n

S
M
E
s

P
u
b
l
i
c

a
t
t
i
t
u
d
e

t
o
w
a
r
d
s

r
e
d
u
c
t
i
o
n

i
n

e
n
v
i
r
o
n
m
e
n
t
a
l

f
o
o
t
p
r
i
n
t

M
a
r
k
e
t

s
t
r
a
t
e
g
y

o
f

i
n
c
u
m
b
e
n
t

I
C
T

v
e
n
d
o
r
s

D
e
v
e
l
o
p
m
e
n
t

o
f

t
h
e

F
I

T
e
c
h
n
o
l
o
g
y

F
o
u
n
d
a
t
i
o
n

(
C
o
r
e

P
l
a
t
f
o
r
m

a
n
d

G
e
n
e
r
i
c

E
n
a
b
l
e
r
s

t
h
e
r
e
i
n
)

E
n
t
e
r
p
r
i
s
e

P
o
l
i
c
y

o
n

v
e
n
t
u
r
e

f
u
n
d
s

&

s
t
a
r
t
-
u
p
s


G
r
o
w
t
h

o
f

e
n
t
e
r
p
r
i
s
e

c
o
l
l
a
b
o
r
a
t
i
o
n

(
e
c
o
s
y
s
t
e
m
s

/

n
e
t
w
o
r
k
s
)

D
e
v
e
l
o
p
m
e
n
t

o
f

F
I

U
s
e

C
a
s
e
s

P
u
b
l
i
c

p
r
o
c
u
r
e
m
e
n
t

p
o
l
i
c
y

o
n

O
S
S


G
r
o
w
t
h

o
f

u
s
e
r

d
r
i
v
e
n

i
n
n
o
v
a
t
i
o
n

D
e
v
e
l
o
p
m
e
n
t

o
f

a
d
v
a
n
c
e
d

(
P
a
n
-
E
u
r
o
p
e
a
n
)

t
e
s
t
i
n
g

i
n
f
r
a
s
t
r
u
c
t
u
r
e
s

P
o
l
i
c
y

o
n

I
C
T

s
t
a
n
d
a
r
d
s

&

s
t
a
n
d
a
r
d
i
s
a
t
i
o
n


G
r
o
w
t
h

o
f

b
u
s
i
n
e
s
s

m
o
d
e
l
s

b
a
s
e
d

o
n

t
h
e

o
p
e
n

s
o
u
r
c
e

c
o
n
c
e
p
t

A

n
e
w

I
n
t
e
r
n
e
t

a
r
c
h
i
t
e
c
t
u
r
e

P
o
l
i
c
y

o
n

i
n
t
e
l
l
e
c
t
u
a
l

p
r
o
p
e
r
t
y

i
n

I
C
T


C
o
s
t

o
f

s
o
f
t
w
a
r
e

d
e
v
e
l
o
p
m
e
n
t

M
o
b
i
l
e

I
n
t
e
r
n
e
t

I
C
T

p
o
l
i
c
y

o
n

N
e
t

N
e
u
t
r
a
l
i
t
y

/

U
S
O


C
o
s
t

o
f

t
e
l
e
c
o
m
m
u
n
i
c
a
t
i
o
n
s

M
u
l
t
i
p
l
e

I
n
t
e
r
n
e
t
s

T
a
x

i
n
c
e
n
t
i
v
e
s

o
n

I
C
T

i
n
f
r
a
s
t
r
u
c
t
u
r
e

d
e
v
e
l
o
p
m
e
n
t
s


C
o
s
t

o
f

c
o
m
m
u
n
i
c
a
t
i
o
n

n
e
t
w
o
r
k
s

N
e
w

k
i
l
l
e
r

a
p
p
s

A
v
a
i
l
a
b
i
l
i
t
y

a
n
d

c
h
o
i
c
e

o
f

P
P
P

m
o
d
e
l
s


C
o
s
t

o
f

f
a
u
l
t

t
o
l
e
r
a
n
t

a
n
d

s
c
a
l
a
b
l
e

s
e
r
v
e
r
s







167
Our research further indicates that while there are different competitive models, each would
create issues and concerns for utility services, as summarised as follows:
Promising, but

Structural Sensitive to local

circumstances, difficult to
implement in practice
Facilitates incentives to
interconnect, competition
in horizontal part across
vertical segments,
economies of scope are
preserved
Separation into
essential parts
Essential
Behavioural
And/or structural
Possible lack of profit motive
reduces incentive to innovate
Facilitates control of
discrimination & anti-
competitive behaviour
Operational
separation
Has potential
Structural Club may seek to exclude
outsider, may led to collusion
Eliminates incentives for
discrimination
Club ownership
Yes, but
Structural Potential loss of economies
of scope, may require costly
& arbitrary separation
Eliminates incentives for
discrimination
Ownership
separation
No
Behavioural Requires active regulatory
intervention, need to monitor
& control capacity
Certain economies of
scope is preserved
Access
regulation
Applicability to
service utility
Approach Disadvantage Advantage Policy

Figure 73 - Applying Competitive Models to the Supply of Utility Services
(adapted from OECD 2001)

5.2.4 Conclusions
The research that we have carried out shows that the value proposition for Enterprise
Interoperability and Enterprise Collaboration will evolve quite considerably in the
forthcoming decade.
EI / EC are at present both at the bottom end of innovation curve. The development paths for EI
and EC will diverge rather than converge. EI will be subject to further, continuous
commoditisation. EC will instead develop along the path for increasingly value add and
especially value add to support enterprise innovation. There is however one exception for EC
services in this general trend: collaboration IT services are already a commodity and will almost
certainly remain so.
In other words, the value proposition for EC and EC will become increasingly distinct and
different. It would increasingly make little commercial sense to supply EI and EC as a single
solution. Instead, they will be very much part of more generic service and application offerings
that leverage Internet technologies.
For individual enterprises who would need to collaborate even more in order to compete, their
focus would be on the value add dimension of EC for dealing with the more pressing day-to-
day business operation - rather than on the utility aspects of EI.
168
Enterprise support and use of IT services for purely EI purposes will only attract strategic
attention and especially investment at the end of a long process of IT development and maturity.
EI generally will be absorber into the generic infrastructure for the Internet, which will be
increasingly service centric and service focused.
Our research strongly suggests that utility services are in principle economically viable in ICT
(the Mozilla web browser is a case in point). However, the development of a system of utility
services (such as the ISU) will take a long time, beyond the COIN 2020 horizon.
The key question is whether EI & EC services would become both utility services and
economically viable. The conclusion is that the utilitisation of EI and EC services as a
commercial proposition is highly unlikely to happen without a degree of public
intervention. A very relevant analogous example is the provision of the technology foundation
for the Future Internet (FI-WARE technology platform). The successful market rollout of this
platform in the planned 3 to 5 years timeframe will itself have a major impact on the prospect
for the development of application level utility services especially regarding EI services.
Our research confirms the validity of the FInES Clusters Enterprise Interoperability Value
Proposition framework. As we have seen, that framework includes multiple dimensions
covering both micro and macro business and economic aspects. Specifically, the application of
that framework in business model analyses, as carried out in our research (including in specific
business cases as fully described in D6.2.2b), demonstrates that it makes no commercial sense
to offer EI as standalone solutions.
We also conclude that innovation, and especially the much popularised Open Innovation, is
vital for enterprises to reap the full benefits of ICT including EI and EC. If our assumption that
the ISU leads to openness is correct, then open innovation is essential for the field of EI. Utility-
based business models support and enable many fundamental aspects of ICT development,
without which innovation would be much harder to thrive, as well as industrial enterprise
innovation.
However, market forces might foreclose the openness of the ISU (leading, for example, to
islands of ISU along the SaaS-U paradigm). Under these circumstances, the potential
benefits and effects of innovation for enterprises would be much harder to materialise, and
severely curtailed. In other words, the ISU as innovation may help prevent market integration
only if other conditions which guarantee the openness of the ISU apply. Such conditions should
be the starting point for considering the governance model for the ISU. They are explored in the
accompanying COIN Deliverable D6.2.2b, specifically in relation to business roadmapping for
realising the ISU.
The ISU has disruptive potential, particularly for the incumbents. The ISU paradigm shows
promise as a business proposition in support of new applications and services that add value to
particularly those sectors already in transition due to changing business climates, market re-
structuring and that are open to new players. New business models based on the utility paradigm
are in principle possible and should be guided by the quest for the interconnected dynamics of
innovation and value creation. However, the ISU on its own will not ensure the openness of
social or societal innovation.
Conversely, innovation is not an intrinsic business value. ICT-enabled innovation services do not
necessarily lead to business innovation. Moreover, for businesses, innovation is not an end in
itself. Innovation is a business strategy towards achieving a business goal in support of certain
business values. Business support for openness needs to be viewed through the lenses of that
strategy. The notion of business values is currently under major review worldwide. The outcome
of that review will ultimately determine the kind of ICT that is most needed to support future
enterprises. We believe that an ICT utility infrastructure such as the ISU will be very much part
of that vision and will help bring that vision one step closer. In that regard, it is important to


169
emphasise that the ISU is not premised upon a re-invention of the ICT landscape; rather, it
enhances that landscape by opening up new possibilities and value proposition.
At the end of our research, we strongly feel that there is a lack of innovative scholarship and
literature on the future of enterprises and how a new generation of business value and business
model analyses might impact on such a future. For example, comprehensive assessment is
needed to ascertain what might happen if the status quo of market development merely continues
(even though what the status quo might be now makes little sense in view of huge volatility
within and across markets locally and globally). What exactly is meant by market failure is not
entirely clear either. How to exit from the current business to jump to the ISU?
The ISU is not a pre-determined destination. Its economics are not proven. Indeed, its
economic foundations are at this stage uncertain. Established economic models and assumptions
are not particularly helpful in providing the conceptual basis for utility services. Specifically,
utility services lack an economic basis premised on conventional cost-based and price-driven
supply and demand. New technologies and business models allow greater discrimination and
differentiation in pricing, quality of service, content and other aspects of valued services.
Because different value propositions are needed for different target groups, some form of
discrimination is necessary for encouraging investments, and for possibly also efficiency and
equity.
There is no fixed economic formula for determining value or value proposition. There is no
standard value proposition or win-win business model for SaaS-U. Noting the preceding
points, SaaS-U on its own, no matter how attractive as a business model in theory, is highly
unlikely to sustain sufficient market traction or create payback that would satisfy most businesses
given the existing financial structures and conventional expectations for ROI. Experimentation
of the SaaS-U business models is needed and should be encouraged. It goes without saying
that the only valid testing of any business model is in the marketplace, not in research.


170
5.3 Bringing COIN to the Market
Daniel Field
1
, Francisco Javier Nieto
1

1ATOS
Abstract
Finding appropriate business models for novel technologies is ever a challenging task. In COIN this was no different.
This chapter presents how a method for describing business models through labelling value chain activities as
revenue-generating or cost-generating activities permitted easy contrast of business models suggested within the
consortium. Examples from COIN are given showing how alternative configurations of these types of activities give
way to the diverse business models for subsequent analysis. It is shown how experimenting with these assignations to
a generic value chain of a novel technology allows a structured approach to identifying possible business models.
The application of the technique to existing businesses may lead to the discovery of novel business models.

5.3.1 Challenges
The COIN project presented a complex problem to the team of business analysts tasked with
bringing COIN to the market. The project is large and complicated. It is based on a long term
vision encompassing many trends. In fact the full COIN solution is designed to be implemented
in a futuristic scenario where many of the current day practices of the industry will have changed
significantly. This vision is wholly part of the ISU and SaaS-U model [7] which foresees
software services becoming split along a spectrum between value-added services and utility
services. The concept is that ubiquity and commoditization will drive the price of many basic
software services towards zero. Companies providing these services must provide these services
at low, or no cost because they are widely used to enable an ecosystem on top of which value-
added services are provided. It is from these value-added services that such companies will
derive their profits and compete on differentiation. Of course such a world does not yet exist,
although signs are there that the trends and conclusions which underpin this model are
continuing as foreseen. This presents the challenge that the final COIN solution must understand
both the future destination of the solution, where value is maximized, as well as the situation at
present, for COIN must be commercialized now in order for the future value to be created. What
is more, the two visions; short term and long term, must be compatible in order for a pathway
between the two to be possible.
In addition to the challenge of the industry characteristics, the COIN business team has had to
confront a typical challenge in technology driven research projects: how does one move from an
architecture and system design, based on a implementation in a collaborative situation, where
organizations that may compete in the marketplace are co-providers, to a commercial offering?
The collaborative research atmosphere is isolated from the market forces such as profit
maximization, fluctuating costs, profit distribution and complex clients with multiple needs
requiring different solutions. As a consequence the business team first worked on the 2020 vision
of the project, elucidating the value chain for the technology solution built in the project. They
then proceeded to analyse the project for the more immediate applications the so-called low
hanging fruit which would allow the project to create a beachhead in the industry with a
reduced version of the solution according to the instant needs of the customers, from which
COIN could grow towards the 2020 vision.
5.3.2 Logic adapted
With a view to working around these challenges frequently found in projects, a methodology that
which has been developed within Atos research and innovation department was further refined
and applied. Full details of this are given in a whitepaper [5] and in the context of COIN, are
explained below. The method has been developed in for the exploitation of large technology-led
projects as typified by integrated projects funded by the European Commissions framework
programme programme, of which COIN is a prime example.


171
In essence the method is to formally recognise the value chain or system of the project based on
the assets or technical innovations which have been prepared and to develop scenarios for
commercial delivery based on activities which are aligned with the competences and business
model of each participating organisation
In practice this means recognising the supply chain leading to the delivery of each asset, the
value proposition of each component to the next in the chain and the number of different roles
which could feasibly be part of a business scenario to establish a generic system value chain.
Once this has done the different exploitation visions of the participants must be mapped on to the
generic value chain and the source of value, or overriding value proposition, of that vision
recognised.
From this it is possible to recognise when differing visions are indeed different perspectives of
the same vision, and when they are distinct scenarios. It is possible to distinguish between trivial
differences and those that change the definition of the value proposition or business model. It is
possible to identify the true client (he who provides revenues) from other actors that may use or
benefit from the system, and it is possible to make some assertions regarding critical success
factors, business models, long term strategy and potential risks and mitigation strategies.
5.3.2.1 Identification of assets
The identification of assets should start early in the project lifecycle for both for exploitation and
non-exploitation reasons. In terms of technical management it is necessary to have a global
picture of the projects components and how they work in order to build a holistic system. In
terms of project management it is necessary to know where resources are being spent and when
things will be developed so that the progression can be monitored. From the exploitation
perspective it is necessary to know not how they work but what they do and which components
they interact with. This is fundamental in order to derive the value chain and define the value
proposition for them. The team took detailed diagrams from COIN from across the different
workpackages in order to build up a picture of how the components interacted and created value.
In particular through this exercise and interviews with leading developers, we were able to build
up a detailed value chain of the system.
5.3.2.2 Identification of the value chain
Having identified the assets and the components of a project it is necessary to carry out value
chain analysis on the assets in order to derive a generic value chain from which our business
scenarios are constructed. It is assumed that the reader is familiar with general value chain
analysis and in this section we focus on the specific challenges within the context of large
collaborative ICT projects. This section is abridged from the above referenced whitepaper.
From the list of assets and components described above, these were reorganised into a flow
which represents the service that each component or provides.
First we needed to separate the components and assets into two categories the core technology
and the peripheral assets. In applying this method, in the core technology we typically find
elements of a core platform upon which peripheral assets operate. Among the list of peripheral
assets we also tend to find non technical elements alongside technical ones, these may include
such as business model research, consultancy models, additional services and other tools and
pieces of software that can be used in certain use cases but are not essential to the delivery of the
key project objectives.
172

Figure 74 - Core and peripheral assets

Next we analyse the core technologies for the value activities contained within them. In order to
do this we carry out value chain analysis as introduced to the literature by Michael Porter [8].
Porters work focused on a single business and the analysis of its activities according to the value
they create rather than their way they operate.
Essentially, for this exercise there are two types of value activity. The first are those which
perform a concrete function adding value to the input to provide an output with an added value.
This would be for example a transformation of the service or good which is the final output of
the core technology. For example in the case of a technology that allows intelligent objects such
as sensors and devices to be discovered, ranked against historical data and deployed, these three
value activities would be considered concrete value functions. We call these vertical value
activities. The second group of activities are those which do not have an explicit logical order but
which enable the vertical actions to be used or to function. These are horizontal value activities
and include such things as the interface (allowing the user to discover and select the devices, the
security features which ensure the user has the right to do so and the platform which manages the
retrieval of data from the database and execution of the ranking algorithms, for example.
These are then placed pictorially into the core technology value chain, with the vertical activities
in a logical order, forming the top portion of a horizontal chevron and the horizontal activities
placed in the bottom half of the chevron showing that they act throughout the entire core
technology. The chevron points to the right and the vertical activities logically proceed left-to-
right. In the case of the COIN project, the central technological value activity revolves around
the platform and the activities of service discovery and deployment that it provides. This is
shown below:

Figure 75 - Value Chain for the core COIN technology



173
Having reached this point it is necessary to then extend the value chain with all the roles and the
goods or services that are required in order for that component or asset to function, and the roles
or services that are enabled as a result. This is an extension of the rent chain concept espoused by
Baron [1], subsequently generally mixed with the original value chain concept of Porter and now
referred to simply as a value chain. It is very similar to the concept of a supply chain, but based
on value adding activities.
In situations where there are more than one input or output to a process it is possible to have
value chains in parallel. This is quite common. In the full value chain of COIN, shown below, we
see a complex array of value activities. Providing input to the core technologies shown above we
see the parallel chains of infrastructure and services, isolating the creators and the providers of
each. The output of the core is a chain encompassing IT providers who will install and maintain
the system on behalf of the user, if necessary, then the users, which use the system, and finally
their clients. In the vertical dimension the value chain expands to include non-technical
horizontal value activities including marketing and management, and the possibility of federating
the platform with third party platforms. There are ancillary roles including consulting, training
and reselling, and finally an occurrence of prosumers, where the same actor is potentially both a
provider and a consumer in the same value chain.

Figure 76 - The complete value chain for COIN

At this point we have the value chain from end to end, defining the end as beyond the sphere of
influence of the future provider of the project technology, as well as any ancillary roles.
5.3.3 Development of business scenarios
At this point we needed to start developing business scenarios for the exploitation of the system,
and this is where the work in deriving the value chain pays off. The value chain becomes the
basis of the formalisation of scenarios so that each can be discussed in detail without losing track
of the central business premise at the heart of the scenario.
Whilst many collaborative projects start exploitation assuming that they must control all
activities of their value chain and select the generic business model that is most familiar (often
open source or a cloud implementation), in COIN we wanted consider that as each activity of our
value chain is by definition an value-creating activity that adds value, a business scenario could
be based on any one of them. In theory each activity could be carried out by a separate
organisation with its own business model in a complex ecosystem. In practice of course it is
unlikely any innovative technology could get off the ground requiring such complexity of
174
business relationships to be engineered in advance. As always, the answer lies in finding the
happy medium.
This gives us our first question: What parts of the value chain could we deliver as an
organisation, leaving other activities to incumbents in the industry or to newcomers?
Already the answer to this question will give us some ideas for shaping possible business
scenarios. However, before doing so we also posed the second question:
Of the activities we provide, which is/are the one(s) we base our business model on, and which
ones do we provide because we have to?
It is this second question which will give us the greatest variety of business scenarios for our
system. There is no single answer to the question and workshop participants should be
encouraged to be bold and challenging as possible.
5.3.4 Type of Activity
In answering the second question posed above, our exploitation method considers various types
of activity. The first distinction of activity types is whether it is a revenue-generation activity
(which we term a Revenue Generation activity, or RA) or whether it is merely an obligatory
activity (which we term a Cost Activity, or CA). For example, in our method, in a typical
business the product or service that is being sold would be considered a RA activity and the
marketing activities used to drive the sales would be classified as a CA activity. However, not all
cases are so clear cut.
It is by playing with these activities controlled by the main exploiting organisation and the way
that they are carried out that we can discover new business models and more innovative ways of
providing the technology.
There is a third distinction of activities. Although we should assume that in all business scenarios
all value chain activities are potentially present, in some scenarios we may recognise that the
business model is driven by a third party actor or role upon whom the profitability of our
exploitation scenario is wholly dependent. We may wish to underline the nature of this role in
defining the business scenario. A common example of this is a marketplace. In the case of eBay,
the profitability of eBay itself is driven by the trading of goods by third parties outside the
control of the eBay company. If we were inventing the business scenario of eBay from scratch, it
would be valuable to acknowledge this formally in the model so that subsequent aspects of
business planning take this into account. In this example we would designate these third party
traders as a 3rd party RA value activity.
In order to show these different types of value activity pictorially on our value chain, we have
adopted the following convention as shown below.


175

Figure 77 - Legend for value chain activities

5.3.5 Scenarios in COIN
In COIN this method was applied and 8 distinct scenarios were developed, which could be
competing or complimentary.
The first scenario was based on making the core technology (the large chevron) the RA function,
in which users would pay to use the platform, for example through a subscription pricing model.
Once this subscription was paid for, subsequent use of services would not be charged, making
the service provision a cost activity. We likened this to a Facebook where users were charged a
monthly subscription for access but then had access to all services (messaging, games, etc.) for
free. This is shown below.

Figure 78 - Facebook Scenario 1

176
The next scenario turned this on its head a suggested providing access to the platform for free but
charging users for access to the services. Again we likened this to a Facebook, where instead of a
platform subscription, users were charged each time they used a service, as shown below:

Figure 79 Facebook Scenario 2

In both these scenarios we considered that the infrastructure could be outsourced to a third party
provide without changing the scenario, and that consultancy could be provided as an optional
extra. However it is exactly this consultancy which provided the third scenario: what if all of the
COIN system was provided for free, with the providers relying on consultancy and training to
generate revenues. This we likened to an open source model as increasingly seen in many
software products such as Ubuntu, provided by Canonical ltd under this model.

Figure 80 - Open Source Scenario



177
When we started exploring what would happen if COIN did not control the service provision,
leaving this entirely open to third parties, with COIN merely acting as the marketplace and
deployment platform, we came up with a new scenario which we likened to eBay. In this
scenario access to the platform is free but each time a service is deployed, the user is charged.
Therefore we considered the vertical activities of the core technology to be RA, whilst the
provision of horizontal activities were merely costs incurred by the provider. As the provision of
services by third parties, under their own business model is central to definition, this was also
indicated on the value chain, as shown below:

Figure 81 - Markeplace Scenario 1

The next scenario was the franchise model. Another innovative model, here it was conceived that
third parties could host sector-specific instances of the platform, for example in health,
automobile, finance. Services common to these sectors would be provided by third parties under
their own business model (mixture of free and SaaS). The COIN partners would receive
revenues for the management of the IPR, the marketing and the central management of sector-
independent development, similar to the way that franchises work in other sectors. A key and
interesting point here is that it makes the management and sales functions of the value chain into
the point of value capture. In nearly all chains these function are costs.
178

Figure 82 Franchise Scenario

In the course of this work, several other scenarios were also developed and analysed further. The
next step for the team of business analyst was to investigate the long term implications for each
scenario. Several scenarios were dismissed at this point, and at the time of writing, the
exploitation team is developing business plans for the remaining viable scenarios.
5.3.6 Conclusion
This chapter has described how faced with a complex situation and very unclear exploitation
path, based partially in the future, the application of a simple method focused on determining
first the value chain and subsequently exploring business scenarios based on, the exploitation
team of COIN have been able to explore creative and innovative routes for the future commercial
exploitation of the project.
At the time of writing the exploitation team is developing the franchise scenario, which we think
could be the optimum way for a COIN deployment in the future. As aspects of the COIN 2020
vision emerge, and the observations and trends that led to that vision strengthen and become
more relevant, we believe that COIN could indeed licence out the use of the IPR behind COIN
so that independent organisations, ideally agile SMEs and SME associations could run a
profitable business serving their sector. No doubt so of these would be self financing, perhaps
running their instance as a marketplace, whilst other s may be publically funded to potentiate
clusters of businesses. Irrespective of the business model of the franchisee, it is clear that as each
COIN instance creates value this can flow back into the COIN management, in return for
ongoing IPR updates, bug fixing, improvements, marketing, management and the growing
ecosystem of services available through the autonomous COIN instances.
In addition we find many of the pilots, described in [3] wishing to further develop commercial
scenarios around the COIN platform are looking into the various scenarios as the backdrop for
their pilot. For example some, such as FILAS and ICZ are looking at marketplace-based
scenarios for their sectors. [2]; [4].
In the process of developing this methodology is has been seen that just as in COIN, the process
of scenario elucidation can be applied to many technology-push projects. A forthcoming paper
[6] explores the application of this methodology in the commercial domain, for retrospective
applications. From the experiences in projects and the commercial examples, it is seen that
permuting the assignation of RA and CA in a generic value chain is a structured approach for


179
identifying potential business models. Consequently this method is recommended for the
identification of possible business models when exploiting new technologies.

References
[1] [Baron, 1995] Baron, D.P., The Nonmarket Strategy System, Sloan Management Review, Fall 1995
[2] [COIN, 2010] COIN Consortium, Field, D., and Gil, B., (eds): D2.2.1b Exploitation Report M24, Self-
published 2010.
[3] [COIN, 2011a] COIN Consortium: D6.5.x.a Test Bed Report series of deliverables from COIN. Self-
published 2011
[4] [COIN, 2011b] COIN Consortium, Field, D., and Ay, E., (eds): D2.2.1d Exploitation Report M48,
forthcoming, 2011.
[5] [Field, 2011] Field, D., Identification of business models through value chain analysis: A method for the
exploiting large technology projects, Self-published (Creative Commons), 2011
(http://www.scribd.com/doc/66408751/Identification-of-Business-Models-Through-Value-Chain-Analysis-
A-Method-for-Exploiting-Large-Technology-Projects-A-Whitepaper)
[6] [Field, 2011b] Field, D., Describing and Identifying Business Models from Generic Value Chains for
Technology Systems, eChallenges e-2011 Conference Proceedings Paul Cunningham and Miriam
Cunningham (Eds) IIMC International Information Management Corporation, 2011, ISBN: 978-1-905824-
27-4
[7] [Li, 2011] Li, MS., (ed.) Eschenbcher, J., Gusmeroli, S., Suttner, H., Weber, J., Faughy, A., Eley, M.,
D6.2.1b - Integrated EI Value Proposition M46 issue, Self-published 2011.
[8] [Porter, 1985] Porter, M.E., Competitive Advantage, ISBN 0684841460, Free Press, New York, 1985.


180
5.4 Enterprise Collaboration Maturity Model
Juncal Alonso
1
, Leire Orue-Echevarria
1
, Mikel Vergara
1

1 TECNALIA, Parque Tecnolgico 202 E-48170 Zamudio, Bizkaia, Spain
{Juncal.Alonso, Leire.Orue-Echevarria, Mikel.Vergara}@tecnalia.com
Abstract
The Internet is undoubtedly permeating and transforming all aspects of our economies and societies. It is a
remarkable catalyst for creativity, collaboration and innovation and more broadly for the development of our
economies and societies [7]. In this context, collaboration and interoperability are pervasive subjects today as
organizations strive to achieve competitive advantage in the global market fostered by the development of the new
economies of scale.
In the COIN IP project [IST-216256], a strategy based on readiness assessment to adopt best collaboration and
interoperability practices has been implemented following the maturity models approach.
The aim of this paper is to present a methodology inspired on maturity models. This methodology shows the
approach used to assess organizations on their readiness for collaboration and interoperability and to guide those
organizations to adopt best practices for collaboration and interoperability in networked environments.

5.4.1 The problem description
Collaboration and interoperability are key issues for todays organizations in the current
globalized and networked society. As professed in the introduction to the COIN IP project, both
concepts are different but they are so interconnected that can be considered two sides of the same
COIN [4].
In this new situation where enterprises have shifted towards networked enterprises, companies
need to adopt innovative forms of collaboration in order to compete and maintain their position
in the global market. These new ways of collaboration are mainly based on Information
Technologies and therefore interoperability capabilities at different levels have become crucial to
create value and success, combining technology and business approaches to catalyze and sustain
added value for enterprises and customers.
New economic activities have arisen alongside with new classes of networks and services, new
forms of enterprise collaboration, new business models and new value propositions. Business has
changed as well [8]. As stated by the European Commission in its published Enterprise
Interoperability Value Proposition, economies of scale can now reach world wide, allowing
firms to tap into the narrowest parts of the long tail of demand. In fact, collaboration is one of the
global trends in business nowadays and collaborative practices are gaining importance in firms.
These collaborative practices are being carried out in different forms, from cohesive and stable
networks like Collaborative Networked Organisations (CNO) to more ephemeral and occasional
cooperation like (VBE) Virtual Business Ecosystems.
Existing literature points out different definitions and analysis of new types of collaboration
forms [6], as well as numerous enterprise interoperability types and practices [2]. There are also
existing proposals on readiness for certain types of collaborations forms, like the Aricon
approach [1], where a methodology for Virtual Enterprises and Product development is
presented. However, for enterprises, it is still a hard task to identify best practices and
improvements to start implementing collaboration and interoperability practices inside different
types of networked environments.
Presuming that an organization is collaborating in any type of the networks aforementioned, the
question they face is: how is my company performing alone and in the network, that is, how
mature is my organization in terms of collaboration and interoperability and what can be
improved to perform better?


181
5.4.2 Objectives and Use of the ECMM
To answer the previous question, the Enterprise Collaboration Maturity Model (ECMM) [5] has
the main objective of assessing organizations that desire to know their collaboration and
interoperability maturity level with respect to a set of best practices. The result of these
assessments will present, among other issues, an improvement plan and a roadmap to increase
the enterprises collaboration and interoperability capabilities, instilling in organizations the
benefits of excellence models.
In order to reach this main objective, other secondary and more specific objectives have been
identified:
Diagnosis the state of an organizations current practices regarding collaboration and
interoperability issues.
Set improvement objectives and priorities.
Guide for improving projects and organizational processes.
Help ensure stable, capable, and mature processes.
Proposition of Enterprise Collaboration and Enterprise Interoperability technologies and
services that could be useful.
ECMM can be applied by external independent evaluators and also internally as a self
assessment tool. Regarding the special features for collaboration practices the ECMM should be
useful to:
Support the collaboration during the whole life cycle of a Collaborative Networked
Organisation (CNO): from its creation, operation, evolution, to its dissolution.
For an enterprise (that could be part of a CNO or not) in order to evaluate its preparedness for
collaboration (in a specific collaboration or in general) and provide best practices to correctly
position the enterprise inside its collaborative network.
5.4.3 ECMM Design Process and Background
5.4.3.1 Maturity Models
ECMM follows a CMMI [3] structure, as it is very clear, well understood and applied within
the industry (as a standard de facto).
A maturity model is a framework that describes, for a specific area of interest, a number of levels
of sophistication at which activities in this area can be carried out. Maturity models focus on
different disciplines that an organization can address to improve its business.
Applying the maturity model approach to assess networked organizations will provide:
A place to start. It is important to identify each organizations current state, this will help
setting the actions that are necessary to achieve the objectives defined.
The benefits of a community prior experiences, as a model is a collection of industry good
practices proven by experience to be effective.
A common language. Setting a model implies sharing a common dictionary that will assure
that every party involved is using a common language.
A shared vision and a framework for prioritizing actions: A model provides a shared vision
of the improvement path, what the goal is, what is being aimed for and, how it can be
achieved.
According to CMMI definitions Maturity models define a structured collection of elements:
Maturity Levels, Process Areas, Goals, Practices, Subpractices, etc. These elements describe
characteristics of processes that have been proven by experience to be effective.
182
5.4.3.2 ECMM Domains
ECMM is structured in a hierarchy of components to support different users and their needs: 23
Process Areas, clustered into 7 domains and 4 Maturity Levels.
In order to diagnose the current maturity level of organizations regarding collaboration and
interoperability, 7 domains to which the ECMM can be applied have been defined as follows:
Project and Product Management: Cross-project and product activities related to defining,
planning, developing, risks management and quality assurance.
Business Process and Strategy: Business process management and financial aspects.
Customer Management: Relationship with the customer and evaluation.
Collaboration, Legal Environment and Trust: Legal activities, terms of collaboration
relationships.
Organisation: Management of resources, development of competences, measurement.
ICT infrastructure and Interoperability: Technologies and Services for Interoperability
and Collaboration.
Innovation: All activities related to innovation processes.
5.4.3.3 ECMM Maturity Levels
The top-level components of ECMM are the maturity levels (four). According to the CMMI
definition: A maturity level is a well-defined evolutionary plateau toward achieving a mature
process. Each maturity level indicates a level of process capability. Since process capability
describes the range of expected results that can be achieved by following a process, the process
capability of an organization provides one means of predicting the most likely outcomes to be
expected from the next effort the organization undertakes.
The graphical representation of the ECMM Maturity Levels is the following one:

Figure 83 - ECMM Maturity Levels

Following are the details of what each Level means:
1. Performed: Collaboration with external entities is done, but in an ad-hoc and chaotic
manner. Collaborative tasks and processes usually exceed budget and schedule, their past
success cannot be repeated, and the potential of the technology is not used properly.
2. Managed: The objective is to create a management foundation for collaboration.
Network technologies are used to collaborate.
3. Standardized: The objective is to establish a common business strategy and business
process infrastructure for collaboration. Business collaboration is facilitated through
interoperability technologies and use of standards.
4. Innovating: The objective is to manage and exploit the capability of the CNO process
infrastructure to achieve predictable results with controlled variation. Additionally,
another objective is to continuously improve the CNO processes and the resulting


183
products and services through continuous capability, and planned innovative
improvements.
5.4.4 COIN ECMM Structure and Description
5.4.4.1 Process Areas, goals and practices
Maturity levels contain two or more Process Areas. Each process area identifies a cluster of
related practices. Each Process Area is structured and contains Specific Goals and Practices.
The Specific Goals of each process area summarize its practices and can be used to determine
whether an organization has effectively implemented the process area. Typically each Specific
Goal consists of a single sentence and a single concept.
Each Process Area is described in terms of Practices. The practices describe the activities and
infrastructure that contribute most to the effective implementation and institutionalization of the
Process Area.
For example the purpose of Collaborative Business Process (CBP) Process Area is: to establish
and maintain a usable set of collaborative business process assets and work environment
standards. This Process Area contains three Specific Goals:
SG 1: Analyse Internal Business Processes
SG 2: Establish Collaborative Business Processes
SG 3: Monitor and Optimise Collaborative Business Processes
Following with this example, the first Specific Goal (SG1) contains two practices through which
the SG1 can be achieved:
SP 1.1 Link internal Business Processes. Partners link their existing internal processes
and resources to achieve an agreed cross-organizational business process.
SP 1.2 Internal Processes Visibility. Each company selectively expose or hide
information about their internal processes, whilst still being able to act in a cross-
organizational business process. The level of exposure can vary, as the business relationship
develops.
5.4.4.2 ECMM Structure Overview
In the following table, the relationship among ECMM Domains, Maturity Levels and Process
Areas is depicted, where columns are the seven domains and rows are thee three maturity levels
(Level one doesnt have Process Areas). The intersections contain the 23 Process Areas
identified at the ECMM.

184
Table 12 - ECMM Domains, Maturity Levels and Process Areas

5.4.4.3 ECMM Development process
ECMM Development has followed an iterative approach in three phases:
Analysis and Requirements. In order to define the requirements an extended analysis has
been performed in the initial research phase, including different sources and approaches that
cover:
o Other existing Maturity Models and frameworks.
o Enterprise Collaboration and Enterprise Interoperability concepts (mainly coming
from two previous European projects ECOLEAD and ATHENA) have been
analysed.
o Not only previous knowledge, projects and frameworks have been taken into
account but also end-users vision and needs through online-questionnaires.
Design and Development. The next natural step within the development of the model is the
definition of the preliminary structure of the model and the corresponding building blocks:
Domains, Maturity Levels and Process Areas.
Application into End-Users. In order to follow an iterative approach for developing the
ECMM, this phase includes the application and validation of this first version of the maturity
model into real use-cases. These piloting activities will allow updating and improving the
ECMM based on the input received in the assessments following an iterative approach.


185
5.4.5 ECMM Application into End Users
ECMM Application into End Users includes three phases that are described more in detail in the
following sub-sections: First assessment, Improvement implementations and Re-assessment.
5.4.5.1 First Assessment
The goal of this phase is to analyse the practices of the collaborative network and provide
improvement recommendations that help the network to improve its maturity regarding
collaboration and interoperability.
This phase starts with collecting information about assessment scope and context making use of
a context questionnaire (in order to identify the companies of the collaborative network that will
be evaluated, the Process Areas, the people to be interviewed, etc.).
Assessments can be carried out in different ways, mainly on-site and remote (online). If
assessments are remote they make use of web-based questionnaires containing both open and
close questions. The Web-based questionnaires have been implemented with an Open Source
tool called Lime Survey.
16

The collected data is analysed by means of an evaluation tool that provides some graphics for
representing the Process Areas scores.
Recommendations related to
SG1-SG2-SG3
-CBP definition and
modelisation
-Internal processes visibility
definition
-CBP monitoting and
measurement
Recommendations related
to SG2-SG3
-CBP definition with
standard format
-Quantitative performance
metrics
Recommendations related to
SG1-SG2
-Internal processes visibility
definition
-CBP definition with standard
format
PA Goals
SP1.1 SP1.2
SP2.1 SP2.2
SP3.1 SP3.2
Practices
CBP
SG1
SG2
SG3
PA Goals
SP1.1 SP1.2
SP2.1 SP2.2
SP3.1 SP3.2
SG3
CBP
Practices
SG1
SG2
PA Goals
SP1.1 SP1.2
SP2.1 SP2.2
SP3.1 SP3.2
Practices
CBP
SG1
SG2
SG3
Company 1 Company 2
Company 3
Recommendations related to
SG1-SG2-SG3
-CBP definition and
modelisation
-Internal processes visibility
definition
-CBP monitoting and
measurement
Recommendations related to
SG1-SG2-SG3
-CBP definition and
modelisation
-Internal processes visibility
definition
-CBP monitoting and
measurement
Recommendations related
to SG2-SG3
-CBP definition with
standard format
-Quantitative performance
metrics
Recommendations related
to SG2-SG3
-CBP definition with
standard format
-Quantitative performance
metrics
Recommendations related to
SG1-SG2
-Internal processes visibility
definition
-CBP definition with standard
format
Recommendations related to
SG1-SG2
-Internal processes visibility
definition
-CBP definition with standard
format
PA Goals
SP1.1 SP1.2
SP2.1 SP2.2
SP3.1 SP3.2
Practices
CBP
SG1
SG2
SG3
PA Goals
SP1.1 SP1.2
SP2.1 SP2.2
SP3.1 SP3.2
SG3
CBP
Practices
SG1
SG2
PA Goals
SP1.1 SP1.2
SP2.1 SP2.2
SP3.1 SP3.2
Practices
CBP
SG1
SG2
SG3
Company 1 Company 2
Company 3

Figure 84 - ECMM Results: Comparison between the three companies

The graphic represents an example of the evaluation of a Process Area depending on the
fulfilment of each of the specific goals of the Process Area. In the first company
recommendations are provided for all three goals (SG1, SG2 and SG3), in the second company
for two goals (SG2 and SG3) and in the third company are related to SG1 and SG2 goals.

16
www.limesurvey.org
186
The following marks are used for representing Process Areas Scores:
Red: The purpose of the practice is judged as absent or poorly tackled in the set of
established practices. Deficiencies or problems have been identified and these issues will
prevent the performance of the goal in case the deployment might be done in this way along
the network.
Yellow: The purpose of the practice is judge as correctly tackled in the set of established
practices along the organisation but it has not been clarified the possible establishment in the
enterprise network. Deficiencies or problems have been identified and these issues could
prevent the performance of the goal in case the deployment might be done in this way along
the enterprise network.
Green: The purpose of the practice is judge as correctly tackled in the set of established
practices so it would allow the performance of the goal in case the deployment might be done
in this way along the enterprise network
Not yet: The practice has not still performed because the collaborative project has not
reached the appropriate point in the life cycle.
Empty: It has not been established a mark because the evaluation has not collected
information.
To close this phase the assessment reports are presented to the companies. They include both the
improvement recommendations and the Process Areas scores.
5.4.5.2 Improvement implementations
The main goal of this phase is the implementation of the new practices for collaboration and
interoperability in the collaborative network making use of COIN services . This phase includes:
Design, test, communication, training and dissemination of new practices in the collaborative
projects.
Remote support (via email, phone teleconference, etc.) of the implementation of new
practices for collaboration and interoperability.
In some cases improvement recommendations are supported by COIN services. In order to
support the implementation of improvements a mapping between the COIN services and the
ECMM Process Areas has been developed. An extract of this mapping is represented in the table.
It is based on the final specifications of the COIN services.


187
Table 13 - Mapping COIN Collaboration Services ECMM (extract)
COIN WP4.1 Baseline EC Services ECMM Process Area
Service for Maintaining Competencies
Ensure all the information related to membership
applicants of the cluster is appropriately
registered, storing their competences into a
database, supporting the publication and sharing
of information between cluster members.
Training and Competency Development
Develop the skills and knowledge of people in a
collaborative way so they can perform their roles in
the network effectively and efficiently.
Service for Matching Competencies with
Business Opportunity
These services support the VO formation phase,
with the characterization of the Collaboration
Opportunity, search for possible partners and
identification of the most suitable ones based on
their competences.
Collaboration Agreement
Set up the terms in which the collaboration takes
place as well as the management of the collaboration
activities throughout the whole life of the
collaborative enterprise.
IPR
Protect the works the members of the collaborative
enterprise create and exploit.
Service for Tracking VO Members Progress
These services support the VO management and
operation by providing a catalogue of pre-defined
indicators, estimating partner satisfaction, aiding
collaborative design or supporting human
interaction in the planning and scheduling
VO management & Operation. ICT support for
project management, human interaction, product
development, and production planning
Measurements and Analysis
Develop and sustain a measurement infrastructure
that is used to support business management
information needs in order to help making decisions
that affect collaborative business outcomes.
Interoperability and Collaboration Technologies
Establish tools, techniques and methods for
interoperability and collaboration
Service for Maintaining Knowledge and
Training
Maintain knowledge and training and fulfil an
inheritance function.
Training and Competency Development
Develop the skills and knowledge of people in a
collaborative way so they can perform their roles in
the network effectively and efficiently.

For example the following recommendation has been provided for the Collaborative Business
Process Process Area:
Recommendation. Model collaborative business processes following a standard format and
modelling notation. Model the exchange of information linking the internal processes among the
members of the network. The model of the collaborative business processes should cover: Work
processes, Management processes and Support processes.
This recommendation is linked to the COIN Service: PnP Collaborative Production Planning
Portal (C3P) that allows model the business process using a formal notation language.
Regarding the link between COIN services and ECMM Process Areas, different cases have been
found:
The link is very clear, i.e. Service for maintaining knowledge and training and Training
and Competency Development Process Area.
188
Different granularity. ECMM Process Areas have a broader scope and COIN Services
provide concrete solutions to specific Collaboration and Interoperability problems.
Sometimes 1 COIN service = 1 Specific Practice. For example Service for matching
competencies with Business opportunity links to the practice SP 1.2 Select Collaborators
of Collaboration Agreement Process Area.
The link is very light or requires some kind of interpretation. For example Service for
Maintaining Competencies links to Training and Competency Development Process
Area. In the service the term competencies refers to the information of the companies in
the cluster. By the contrary in the Process Are the term competency applies to knowledge
of people. It can indicate that Process Areas should be refined in order to better cover the
COIN services approach and/or that new COIN services should be developed to better cover
the Process Area.
5.4.5.3 Re-assessment
The goal is to measure the practices of the collaborative network for a second time in order to
check if the implementation of the improvement practices has achieved the expected results.
The (self)-assessment will make use of the online web-based questionnaires previously
developed or if the option selected is on-site assessments, the evaluator team will carry out the
reassessments by attending the customers premises.
The final assessment results and lessons learned will be reported, including wherever possible a
comparison between the previous situation and the current one.
Finally this phase aims to update and improve the ECMM with the input received making use of
a feedback questionnaire.
5.4.6 Conclusions
This chapter has presented the research, basis and structure of the Enterprise Collaboration
Maturity Model (ECMM) developed in the context of the COIN IP project during last years. The
maturity model showed in this chapter is based on other excellence frameworks and models that
are standardized in todays industry.
The work carried out has allowed us to establish the initial content, structure as well as a stable
definition of specific goals and practices of each of the identified process areas. Simultaneously,
the assessment method has been defined, as well as the initial set of questions needed to be asked
during these assessments.
Final work includes the validation of the model in enterprises belonging to a CNO, a supply
chain or a virtual business ecosystem. As the validation of the complete ECMM is not viable,
pilots have focused on a predefined set of process areas that the enterprises select as critical for
their business. These piloting activities allow us to update and improve our model based on the
input received in the assessments following an iterative approach.

References
[1] ARICON Project
http://cordis.europa.eu/data/PROJ_FP5/ACTIONeqDndSESSIONeq112242005919ndDOC
eq1905ndTBLeqEN_PROJ. htm, 2008.
[2] ATHENA Consortium (IP-507849). Guidelines and Best Practices for Applying the ATHENA
Interoperability
[3] Carnegie Mellon, Software Engineering Institute, CMMI Product Team, CMMI for Development,
Version 1.2, 2006.
[4] COIN Consortium (IP-216256). Collaboration and Interoperability for Networked Enterprises. Anex I-
Description of work, 2007.
[5] COIN Consortium (IP-216256). Maturity Model for SME collaboration. Deliverable D6.3.b, 2010.


189
[6] ECOLEAD Consortium (IP-506958). A reference Model for Collaborative Networks. Deliverable
D5.2.3,2007.
[7] ERCIM News: Future Internet Technology, ERCIM EEIG, 2009.
[8] Li, M., Crave S., Grilo, A., van den Berg, R Unleashing the Potential of the European Knowledge
Economy: Value proposition for Enterprise Interoperability. Version 4.0, European Communities, 2008.

190
Conclusions - The heritage of the COIN Integrated Project: how to move forward
in the Future Internet Enterprise Systems domain
Besides being a mere deliverable in the fourth year of project, the COIN Book was thought not
only as a dissemination tool in the FI research community
17
or a simple collection of unrelated
scientific papers, but it was also meant as a knowledge tool to understand the state of play of
research in the EI/EC domain, to identify on-going parallel domains relevant to the Future
Internet Services for Enterprises topic, to sketch possible future research streams originated by
it in the FInES domain and finally to indicate the roadmap towards a sustainable exploitation of
EI/EC services in networked enterprises.
This book is meant to pave the way for future research and implementation activities in the
Future Internet Enterprise Systems (FInES
18
) domain and brings together all the views of the
different stakeholders.
As a matter of fact, the COIN project contributes significantly to the progress of both scientific
research in the area and also to identify business and market elements which we all need to
address if we want to be competitive in such a dynamic context.
All the views of the different stakeholders were represented, from the IT industry to academia,
from the final users (industry, mainly SMEs) to policy makers interested in supporting and
facilitating the adoption of the developed applications and services infrastructure.
After four years of challenging and exciting work, it is always difficult to summarise the main
outcomes and lessons learnt, given the wealth of results produced and the number of issues
effectively tackled.
However, we may well say that the main effort in COIN was to produce an integrated value
proposition for EI/EC services, in which the excellence of the achievements in the IT service
concepts was always coupled with a deep and careful analysis of the business models to be
adopted, in the interest and for the benefits of potential users.
Just to mention the most important impact of COIN in the scientific and business domain, we
could cite: from the technical viewpoint:
a. EI/EC services commoditization to be extracted & separated from state-of-the-art
Enterprise Applications in order to constitute a Service Utility (ISU) available to all the
Enterprises. This COIN heritage outcome complements the servification of ESA (e.g.
under the Cloud Computing SaaS paradigm) by adding another enterprise-oriented layer
between the baseline FI services like storage, computation, communication and the
application layer of CRM, SCM, ERP value added services.
b. Interoperability Service Utility as an essential component of the European Future
Internet service infrastructure currently under development in the RTD Framework
Programme 7. This COIN heritage outcome anticipates the notion of a FI Core Platform
providing applications with basic, universal, available-to-all services, in this case EI/EC
services. The Core Platform Generic Enablers could be complemented by enterprise-
specific EI/EC commodities to fill the interoperability gaps during enterprise
collaboration processes. The ISU is the delivery platform for such services,
encompassing not just the usual fundamental semantically enabled service life cycle
management functions (search, discovery, compose, orchestrate, execute, monitor,
govern), but also advanced facilities for scalable federations of nodes, secure and trusted
cross-company collaboration, intelligent and adaptive reasoning and SLAs negotiation.

17
The COIN Final Conference is in fact co-located with the FIS2011 conference, Future Internet Symposium
18
http://www.fines-cluster.eu


191
c. FInES Arch, a new reference architecture for next generation Enterprise Applications,
integrating Public and Private Clouds & specific methods & tools for Business
Innovation Management. This COIN outcome anticipates the FINESArch task force of
the FINES cluster by depicting a new FI-oriented architecture for next generation
Enterprise Systems. This view projects the Enterprise Systems from the company
dimension to the cloud dimension, passing through the enterprise networks and business
ecosystems collaboration forms.
d. Open-Trusted Platform Federation, as the implementation paradigm for evolutionary
and scalable distributed architectures of Global Service Delivery Platforms. This COIN
outcome provides a solution both to a planned and to an emergent growth of the service
delivery nodes as well as an architecture for goals intelligent decomposition & service
composition, and for SLAs definition and monitoring based on non-functional properties.
In the planned scenario (like in Cloud Computing) , performance and scalability of the
solution call for an autonomous optimisation of the necessary number of nodes, of the
assignment of nodes to services and of the possible replication of service instances in
different distributed nodes. In the emergent scenario (like in the Service Web), new nodes
will be added to the federation in order to encompass new domains, industrial sectors or
technological solution (e.g. the interoperability service platform of the automotive Odette
standard, the collaboration service platform of IBM).
from the business viewpoint:
e. SaaS-U Business Models as the original and innovative blending of Utility models with
Software as a Service models, prototyped in energy, healthcare and ICT enterprise
systems. The applicability of blended SaaS-U business models outside the COIN
application domain shows the generality and validity of our speculations in the domain
of utility-based value propositions and business models.
f. Original Public-Private-Partnership Models for an earlier and pragmatic provision and
diffusion of Public Utility services in the industrial ecosystem by local/central Public
Authorities. COIN foresees an important role of Public Authorities in the adoption and
take up of interoperability solutions and standards by SMEs. The legislative and
normative field could in fact stimulate or slow down the appearance of utility services in
the open internet; as an example the Action 25 of the DAE foresee that IT company
should by law license the interoperability information they own.
g. New Business Values promoted and disseminated in the business arena beyond the mere
economical ones: e.g. Social Solidarity, Eco-Sustainable Manufacturing, e-Participation.
It is widely recognized that the presence of fundamental services given as a public good
could stimulate development and entrepreneurship. In some particular cases, the Public
Authority could also stimulate investments in open platforms of utility services or even
become a provider of them; as an example a Regional Development Agency in a
disadvantaged area could decide for social, inclusion, equal opportunity motivations to
invest in the development of an ICT infrastructure (e.g. connectivity, open platforms and
basic services) and to provide the enterprises of this region with EI/EC services for free
or by a political price.
h. Service Innovation, as one of the most promising strategic asset not just for tertiary
sector but mostly for Agriculture and Manufacturing Industry. Service Science,
Everything as a Service and Value co-Creation with customers founding it. The COIN
project addressed service innovation for IT industry in the FI era: assuming some
services (EI/EC in particular) to be available in the open Internet for free (or almost
free), IT industry is required to renovate architectures, functions and support to
innovation of its solutions: as often happens in industrial contexts, the commoditization
of some functions obliges stakeholders to innovate in order to stay competitive on the
192
market. Next move is to consider service innovation in other sectors: the MSEE FOF
project (Manufacturing SErvice Ecosystem) is aiming at Virtual Factories, while also in
the primary sector the service orientation could be very very beneficial.

Furthermore, the COIN project was a cornerstone for some outstanding work developed
within the FInES cluster and with its approach it was in a position to contribute to the
development of research roadmap for future research in the domain.
Also through this book, the COIN project has significantly contributed to the definition of the
landscape of the Enterprise Interoperability / Enterprise Collaboration domain and to the
identification of all the involved stakeholders and the various players active along the value
chain.
Finally, we can proudly say that the COIN project provided a significant step forward to
achieve more accessible IT service platform for all and to stimulate a wave of future internet-
based services using innovative internet technologies.

Bremer Schriften zu Betriebstechnik und Arbeitswissenschaft
Herausgegeben vom Bremer Institut fr Betriebstechnik und angewandte Arbeitswissenschaft
an der Universitt Bremen (BIBA)
Prof. Dr.-Ing. G. Goch Prof. Dr.-Ing. D. H. Mller
Prof. Dr.-Ing.K.-D. Thoben Prof. Dr. Ing. B. Scholz-Reiter

Band 1: Effiziente Angebotserstellung fr komplexe Produkte. Konferenzband zum gleich-
namigen Workshop in Bremen, Januar 1995.
Band 2: Berger, U.: Entwicklung eines sensorgesttzten Planungs- und Programmiersystems
fr den Industrierobotereinsatz in der Unikat-, Einzel- und Kleinserienfertigung.
Dissertation Universitt Bremen, 1995.
Band 3: Vge, M.: Entwicklung und Erprobung einer partizipativen Vorgehensweise zur Ein-
fhrung von rechneruntersttzten Werkzeugen fr die Fertigung und Montage. Disser-
tation Universitt Bremen, 1995.
Band 4: Effektiver EDV-Einsatz in der werkstattnahen Produktion. Konferenzband zum gleich-
namigen Workshop in Bremen, November 1995.
Band 5: Splanemann, R.: Teilautomatische Generierung von Simulationsmodellen aus sy-
stemneutral definierten Unternehmensdaten am Beispiel der Integration der Material-
flusimulation in die Planung von Fertigungsanlagen. Dissertation Universitt Bremen,
1995.
Band 6: Organisation, Technik, Qualifikation. Schwerpunkte der Aktivitten des BIBA in der
Entwicklung, Einfhrung und Bewertung von aufgaben- und nutzergerechter technisch-
organisatorischer und qualifikatorischer Innovationen. Bremen, Dezember 1995.
Band 7: Theorie- und erfahrungsgeleitete Organisationsgestaltung und Personalentwicklung.
Vorgehensweisen, Methoden und Werkzeuge zur integrativen Gestaltung von Organi-
sation und Qualifikation. Bremen, Januar 1996.
Band 8: Oehlmann, R.: Ein Informationssystem fr das Concurrent Engineering komplexer
Produkte. Dissertation Universitt Bremen, 1996.
Band 9: Gestaltung technischer, organisatorischer und qualifikatorischer Innovationen. Schwer-
punkte der Aktivitten des BIBA im Jahre 1995. Bremen, Juni 1996.
Band 10: PACE 96 - A Practical Approach to Concurrent Engineering. Proceedings of Euro-
pean Workshop in Bremen, Germany, 16. September 1996.
Band 11: Integrierte breitbandige Telekommunikation. Stand der Technik und Anwendungsfelder.
Konferenzband zum gleichnamigen Workshop in Bremen, Dezember 1995.
Band 12: Stumm, Thomas; Seidel, Karsten: The Role and Significance of Small and Medium-
Sized Enterprises in the Maritime Sector. Discussing a better integration of maritime
SMEs into the framework European policies. Study carried out for The Alliance of
Maritime Regional Interests in Europe - AMRIE. Bremen, April 1997.
Band 13: Gottschalch, H.: Mentale Modelle als Grundlage arbeitsorientierter Gestaltung am Bei-
spiel von Planungs- und Steuerungsprogrammen. Bremen, April 1997.
Band 14: Fhrung, Organisation und Qualitt in interdisziplinren, internationalen Projekten.
Bericht ber die Arbeiten des Bremer Instituts fr Betriebstechnik und angewandte
Arbeitswissenschaft im Jahre 1996. Bremen, April 1997.
Band 15: Marciniak, Z.: Konzept eines Koordinationssystems zur Integration der rechnerge-
sttzten Produktionsplanungs- und -steuerungsaktivitten in der verteilten Produktion.
Dissertation Universitt Bremen, 1996.
Band 16: Spatz, H.: Informationstechnische Untersttzung fr Gruppenarbeit im Bereich Planung
und Steuerung. Dissertation Universitt Bremen, 1996.

Band 17: Beins, G.: Konzeption eines modularen Steuerungssystems fr Puffer - untersucht am
Beispiel der Automobilfertigung. Dissertation Universitt Bremen, 1996.
Band 18: Heeg, F. J.; Hirsch, B. E.; Knackfu, P. (Hrsg.): Automatisierungstechnik fr Produk-
tionstechniker. Ausgewhlte Lehrinhalte fr Studenten und Anwender. Bremen, April
1997.
Band 19: Detken, K.-O.: GSM - Global System for Mobile Communication: Der Mobilfunk-
standard. (Standards, Protokolle, Techniken, Zukunftsaussichten). Bremen, Juli 1997.
Band 20: Kohstall, T.: Integriertes Managementsystem fr kleine und mittlere Unternehmen unter
besonderer Bercksichtigung eines Organisationssystems fr Sicherheit und Gesund-
heitsschutz der Mitarbeiter im Unternehmen. Dissertation Universitt Bremen, 1998.
Band 21: Eren, E.: Konzeption und Entwicklung eines mobilen Telekommunikationssystems zur
Projektabwicklung in Regionen mit schwacher Kommunikationsinfrastruktur am Beispiel
von Bauvorhaben. Dissertation Universitt Bremen, 1998.
Band 22: Kompetenzentwicklung, Organisation, Technik. Bericht ber die Arbeiten des Bremer
Instituts fr Betriebstechnik und angewandte Arbeitswissenschaft zur Entwicklung,
Einfhrung und Bewertung von aufgaben- und nutzergerechten, technisch-organisa-
torischen und kompetenzfrderlichen Innovationen. Bremen, August 1998.
Band 23: Heeg, F. J.; Kleine, G. (Hrsg.): Kommunikation und Kooperation. Arbeitswissenschaft-
liche Aspekte der Gestaltung von Kommunikations- und Kooperationsbeziehungen und
-systemen. Bremen, Januar 1999.
Band 24: Wisotzki, H.: Stand der Umsetzung und Merkmale von Qualittsmanagementsystemen
in der privatwirtschaftlichen bundesdeutschen Entsorgungswirtschaft. Dissertation Uni-
versitt Bremen, 1999.
Band 25: Frie, P. M.: Projektmanagement fr den tiefgreifenden organisatorischen Wandel mit-
telgroer Einheiten. Gestaltung eines PM-Modells unter Anwendung neuer system-
theoretischer Konzepte zur Verbesserung des Projekterfolges. Dissertation Universitt
Bremen, 1999.
Band 26: Weber, F. (Ed.): Efficient Bid Preparation in the Construction Industry. How to Win more
Bids with less Effort. Bremen, Mai 1999.
Band 27: Esser, M.: Entwicklung von Bausteinen zum Aufbau von modularen Betrieblichen Um-
weltinformationssystemen (BUIS) und deren Einfhrung bei Industrieunternehmen. Dis-
sertation Universitt Bremen, 1999.
Band 28: Krmker, M.: Werkzeug zur durchgngigen Systemuntersttzung der Angebotser-
stellung in der Unikat- und Kleinserienfertigung. Dissertation Universitt Bremen, 1999.
Band 29: Goch, G.; Heeg, F. J.; Hirsch, B. E.; Mller, D. H. (Hrsg.): Mensch und Technik.
Gestaltung von technisch-organisatorischen Innovationen. Bremen, Februar 2000.
Band 30: Ihlenfeldt, F.: Entwicklung eines Vorgehensmodells zur Gestaltung von Dienst-
leistungsprozessen im Qualittsmanagement. Dissertation Universitt Bremen, 2000.
Band 31: Bredehorst, B.; Weber, F. (Ed.): Communication and Decision Support in a Concur-
rent Engineering Environment. CODESCO The Final Report. Bremen, September
2000.
Band 32: Goch, G.; Heeg, F. J.; Hirsch, B. E.; Mller, D. H. (Hrsg.): Technik-, Organisations- und
Kompetenzentwicklung aus interdisziplinrer Sicht. Bremen, Oktober 2000.
Band 33: Beinhold, F.: Entwicklung und Validierung eines Modells zur systematischen Anfor-
derungsermittlung und zur Planung eines kompetenzorientierten Ressourcenmana-
gements in projektorientierten Strukturen. Dissertation Universitt Bremen, 2000.

Band 34: Koch, A.: Entwicklung und Erprobung eines Vorgehens zur kompetenzorientierten
Personaleinsatzplanung und zur Evaluation von Prozessen der Kompetenzentwicklung
in projektorientierten Strukturen. Dissertation Universitt Bremen, 2001.
Band 35: Windhoff, G.: Planspiele fr die verteilte Produktion. Entwicklung und Einsatz von
Trainingsmodulen fr das aktive Erleben charakteristischer Arbeitssituationen in
arbeitsteiligen, verteilten Produktionssystemen auf Basis der Planspielmethodik.
Dissertation Universitt Bremen, 2001.
Band 36: Heeg, F. J.; Binz, P.; Fafflock, H.; Kaebler, J.; Pracht, J.; Roth, C.; Sperga, M.:
Betriebliche Vernderungsprozesse selbstorganisationstheoretisch reflektiert. Bericht
ber die Begleitung von organisatorisch-qualifikatorischen Vernderungsvorhaben in
Unternehmen verschiedener Branchen. Bremen, Dezember 2001.
Band 37: Zabel, J.; Bnke, D.; Panse, C.: Open Network for Tourism. OnTour Final Report.
Bremen, Januar 2002.
Band 38: Wurst, S.: Konzept fr den bedarfsgerechten Austausch von Produktdaten unter
weitgehender Nutzung vorhandener Standards und Methoden. Dissertation Universitt
Bremen, 2001.
Band 39: Goch, G.; Heeg, F. J.; Hirsch, B. E.; Scholz-Reiter, B.; Thoben K. D.: Produktent-
wicklung - Von der Produktgestaltung bis zur Fertigungsplanung. Berichte aus Praxis
und Forschung. Festschrift zum 60. Geburtstag von Prof. Dr.-Ing. Dieter H. Mller.
Bremen, April 2002.
Band 40: Schweiger, S.: Untersuchung zur Qualitt von Qualittsmanagementsystemen in Pro-
duktionsunternehmen. Mglichkeiten der Bewertung der Qualitt ber einen dienst-
leistungsorientierten Ansatz. Dissertation Universitt Bremen, 2001.
Band 41: Schumacher, J.: Entwurf eines Simulationswerkzeuges fr die Planung multimodaler
Logistikkonzepte in der verteilten Produktion. Dissertation Universitt Bremen, 2001.
Band 42: Klumann, J.: Entwicklung eines Simulationssystems fr die Produktionsplanung von
kundenspezifischen Auftrgen unter besonderer Bercksichtigung von Akzidenz-
druckereien. Dissertation Universitt Bremen, 2001.
Band 43: Zabel, J.; Peters, O. (Ed.): Efficient Bidding and Procurement in the Tile Industry.
Practical Trading Tools and Broker Services for the Exchange of Product Charac-
teristics. E-bip A Best Practice Report. Bremen, August 2002.
Band 44: Goch, G.; Heeg, F. J.; Hirsch, B. E.; Mller, D. H.; Scholz-Reiter, B. (Hrsg.): Gestal-
tungsfelder der kooperativen Produktion. Bremen, September 2002.
Band 45: Sperga, M.: Kooperation im kleinbetrieblichen Arbeitsschutz. Zur Rollenerfahrung von
Sicherheitsfachkrften und Betriebsrzten. Dissertation Universitt Bremen, 2002.
Band 46: Thoben, K.-D.; Fritz, S.; Lnemann, M.: Fit fr die Mageschneiderte Massenfer-
tigung durch agile, rekonfigurierbare Fertigungssysteme. Proceedings of the National
Workshop within the ARMMS Project. (Stuttgart, Germany, 20 March, 2002). Bremen,
Mai 2003.
Band 47: Wunram, M. (Ed.): Practical Methods and Tools for Corporate Knowledge Manage-
ment. Sharing and Capitalising Engineering Know-How in the Concurrent Enterprise.
CORMA Assessing Inter-organisational Knowledge Management A Report on
Experiences and Insights. Bremen, Juni 2003.
Band 48: Kaebler, J.: Interventionen fr die Organisationsberatung in Flexibilisierungsprozes-
sen. Anstze unter Bercksichtigung der System- und Selbstorganisationstheorien.
Dissertation Universitt Bremen, 2003.
Band 49: Goch, G.; Heeg, F. J.; Hirsch, B. E.; Mller, D. H.; Scholz-Reiter, B. (Hrsg.): Metho-
den fr Organisation und Technik des digitalisierten Product-Life-Cycle. Bremen Sep-
tember, 2003.

Band 50: Fafflock, H.; Gttler, K.; Lehmann, A.; Bruns, T.; Wicha, I.: Pflegeprozess
Standardisierung und Qualitt in der Pflege. Bremen, November 2003.
Band 51: Aumund-Kopp, C. (Hg.): Arbeits- und Organisationsgestaltung in E-Business basier-
ten Prozessen am Beispiel der schnellen Produktentwicklung. agepro. Bremen,
Februar 2004.
Band 52: Zabel, J.: Referenzmodell der Interaktionsprozesse zwischen Angebotsbearbeitungs-/
Beschaffungsapplikationen und elektronischen Marktpltzen fr kleine und mittlere
Unternehmen. Dissertation Universitt Bremen, 2004.
Band 53: Selk, A.: Konstruktion von Gussformen mit einer rechnergesttzten Entscheidungs-
hilfe. Dissertation Universitt Bremen, 2005.
Band 54: Schwesig, M.: Development of a web based management simulation of knowledge
exchange in networked manufacturing organisations. Dissertation Universitt Bre-
men, 2005.
Band 55: Lemmel, M.: Verfahren zur anwenderoptimierten Auslegung elektrischer Energie-
speichersysteme fr emissionsfreie Fahrzeuge. Strategien zur Markteinfhrung. Dis-
sertation Universitt Bremen, 2006.
Band 56: Echelmeyer, W.: Entwicklung einer modularen prozessintegrierten Anpassungs-
qualifizierung in klein- und mittelstndischen Unternehmen. Dissertation Universitt
Bremen, 2006.
Band 57: Hoheisel, J.: Konzeption und Entwicklung eines computerbasierten Simulationsspiels
zum ben von Telekooperation im Anwendungsbereich der verteilten Produktent-
wicklung. Dissertation Universitt Bremen, 2006.
Band 58: Mller, D.-H.; Gsell, H.: Netzwerk Schiffstechnik 2010 NET-S: Struktur Organisation,
Kommunikation. Bremen 2007.
Band 59: Thoben, K.-D.; Baalsrud-Hauge, J.; Smeds, R.; Riis, J. O. (Hg.): Multidisciplinary
Research on New Methods for Learning and Innovation in Enterprise Networks:
Proceedings from the 11
th
Special Interest Group on Workshop on Experimental
Interactive Learning in Industrial Management. Bremen 2007.
Band 60: Seifert, M.: Untersttzung der Konsortialbildung in Virtuellen Organisationen durch
prospektives Performance Measurement. Dissertation Universitt Bremen, 2007.
Band 61: Weber, F.: Formale Interaktionsanalyse: Ein Beitrag zur systematischen Gestaltung
von Informations- und Kommunikationsstrukturen im Concurrent Enterprise durch die
Bercksichtigung von Informationseigenschaften. Dissertation Universitt Bremen,
2007.

Fortsetzung der Schriftenreihe unter:
Bremer Schriften zur integrierten Produkt- und Prozessentwicklung
Herausgeben vom BIBA (Bremer Institut fr Produktion und Logistik GmbH) Forschungsbereich
IKAP (Informations- und kommunikationstechnische Anwendungen in der Produktion)
und BIK (Bremer Institut fr Integrierte Produktentwicklung)
Prof. Dr.-Ing. K.-D. Thoben und Prof. Dr.-Ing. D. H. Mller

Band 62: Schnatmeyer, M.: RFID-basierte Nachverfolgung logistischer Einheiten in der Kreis-
laufwirtschaft. Dissertation Universitt Bremen, 2008.
Band 63: Seifert, M.: Collaboration Formation in Virtual Organisations by applyingprospective
Performance Measurement, 2009

Band 64: Eschenbcher, J.: Gestaltung von Innovationsprozessen in Virtuellen Organisationen
durch Kooperationsorientierte Netzwerkanalyse, 2009
Band 65: Ioannis, F.: An approach to Service Composition for Internet and mobile services
based on Knowledge-Based Model-Driven Variant Configuration, 2009
Band 66: Wunram, M. Entwicklung eines strungsorientierten Referenzmodells fr
Wissensmanagement zur Untersttzung kooperativer Produktentwicklung, 2009
Band 67: Bredehorst, B.: Wissensgemeinschaft-basiertes Vorgehensmodell zur Interaktion
zwischen Forschung und Industrie
Band 68: Bemeleit, B.: Risikomanagement fr selbststeuernde logistische Prozesse
Band 69: Hans, C.: Konzeption und prototypische Umsetzung eines simulationsbasierten
Werkzeuges zur Untersttzung der Konsortialbildung in Virtuellen Organisationen in
der Produktion
Band 70: Kirchheim, A.: Verfahren zur Erkennung von sackfrmigen Stckgtern fr die
automatische Entladung in logistischen Prozessen
Band 71: Sitek, P., Gusmeroli S., Conte, M., Jansson, K., Karvonen, I.: The COIN Book
Enterprise Collaboration and Interoperability