D26.2 Innovation Ecosystem platform specifications and ... · Project ID 284860 MSEE – Manufacturing SErvices Ecosystem Date: 31/03/2013 D26.2 Innovation Ecosystem platform specifications

Project ID 284860 MSEE – Manufacturing SErvices Ecosystem

Date: 31/03/2013 D26.2 Innovation Ecosystem platform specifications and architecture – M18

D26.2 –

Innovation Ecosystem platform specifications

and architecture –

M18 issue

Document Owner: Martino Maggio (ENG), Davide Storelli (ENG), Mauro Isaja (ENG)

Contributors: Miguel Loitxate Cid (Tecnalia Izaskun Jiménez Iturriza,(Tecnalia)

Dissemination: Public

Contributing to: WP 26

Date: 05 04 2013

Revision: Version 1.0



MSEE Consortium Dissemination: Public 2/108

VERSION HISTORY

VERSION DATE NOTES AND COMMENTS

0.1 01/02/2013 REVISION ON TABLE OF CONTENT OF D26.1

0.2 15/02/2013 NEW CONTENTS AND REVISION OF SECTION 2

0.3 06/03/2013 ARCHITECTURE AND MODULES CHANGES, EXTENDED

TECHNOLOGICAL COMPONENTS SECTION

0.4 25/03/2013 INTEGRATION OF TECNALIA CONTRIBUTION IN SECTION 2

0.5 29/03/2013 VERSION READY FOR PEER REVIEW

1.0 05/04/2013 REVISION FOLLOWING PEER REVIEW COMMENTS

DELIVERABLE PEER REVIEW SUMMARY

ID Comments Addressed ()

Answered (A)

1 Reconsider the structure of the document to highlight

IEP specifications & architecture. W

Chapter 2 title revised and clarified to

IEP specifications

2 Revise Executive Summary to include improvements

to previous issue.

Added an explanation that better

underlines the differences between the

two deliverables and the new

achievements.

3 Revise Section 1.1. to explain the improvements from

previous issue.

Added specific objectives. The specific

improvements are listed in executive

summary and section 1.2, so we avoid

to repeat them here.

4 Page 13, “Block A” paragraph. Clarify the text.

Same for “Block B” paragraph the same confusion is

stated.

Added minor changes in the section.

Clarification about the connection

between D26.1 and D26.2 has been

added in executive summary and next

sections

5 Section 1.3. clarify the sequence and contributions of

WPs to the present document.

The section lists the WP and

deliverables that contributes to the

D26.2. There are no particular sequence

relations that can be expressed using

PERT. The picture that will detail the

relations is Figure 11

6

Table 1. Another column should be included,

indicating what are the deliverables from the “WP”

indicated in column 1 that provide the output/input for

WP26.

Added new column.

7 Section 1.4.2. “… (FInES cluster)”. The respective

http link should be included, for easy acces to the

indicated information.

Added reference

8

Section 1.4.3. The project ECOLEAD is described as

it was an ongoing project. The text should be revised,

as ECOLEAD already finished, and do not deliver

further direct results anymore.

Section modified specifying that

ECOLEAD is already finished

9 The message of Figure 2 should reflect the

complexity of complete explanation of the subsequent

text concerning the MSEE Service System life cycle.

This picture has been used in other

deliverable: we want to maintain it

simple and generic because we are

talking of a generic scenario. In other

deliverables such as D52.2 has been

enriched with specific pilot case details.




10 Section 2.1. “…transforming the AS-IS to the most

appropriate TO-BE…” to be better explained Added new picture and revised sections

11

Page 19. “Figure 2 shows…..”. There is not a clear

matching between this text in this paragraph and what

Figure 2 depicts. The Figure needs to be revised and

completed accordingly.

see comment 9

12 Page 19. “The use cases…. are intended to guide

the…”. Reference to the methodology/explanation

how the platform will be used should be indicated.

Changed sentence to clarified the

concept.

14 Page 21. “The services package described…”. It

should indicate which deliverables SP1 and SP4 will

provide it.

The deliverables have been listed in

table 1. Added reference in the section

16

Page 23. The methodology that resulted in the

enumerated processes (in the bullets) should be

clearly explained.

The last paragraph of this page is not clear.

Added explanation in the section

17

Page 25. Some Processes were removed, from the

previous version. It should be justified these updates.

Why the list of processes is different, ratinal for those

removed/added, etc.

Added explanation in the section

18

Section 2.1.3. The processes are not listed. The bullets

do not indicate clearly the processes. The same

structure of contents and reasoning should be used for

all sections describing the processes.

For the innovation we consider one

innovation process composed by the

listed phase. This view come from the

D21.1 that we included as reference in

the section.

21 Page 31. Clarify selection of requirements

We clarified in the section that are

included only the requirements to be

covered by IEP and not the complete

list presented in D52.2

22 Page 34. Table. Clarify the referenced MSEE cycles Clarified the two cycles meaning

23 Chapter 3. Revise all section to all of them have

exactly the same structure and contets when

describing the modules/services.

Revised section, in particular 3.1 to be

adapted to maintain the same table

structure

24 Page 46. “… other MSEE workpackages…”.

Enumerate exactly which WPs are.

The WP are listed in Table 1, and

Figure 11, we added reference.

25 Figure 9. All the dashed arrows should have

appropriate text, describing the contents of the

conceptual flow it illustrates.

Done.

26

Page 49. Last paragraph, The text is not clear.

“relative” should be “related”. All text of the

document should be revised by a native English

speaker, if possible.

Fixed

27 Figure 12 seems better placed after “document

manager”.

The picture is related to a CMS module

functionality, so we prefer to maintain it

in that position

28 Chapter 4. Explain the integration process rationale in

the project

Added paragraph to clarify integration

approach

29

Chapter 5. The conclusions should be more

elaborated, and clearly justify in synthesis all the

options taken, and the rational for the improvements

presented in this document with reference to the

previous one.

Conclusions updated




TABLE OF CONTENTS

EXECUTIVE SUMMARY 8

1 INTRODUCTION 10

1.1 OBJECTIVE OF THE DELIVERABLE 10 1.2 STRUCTURE OF THE DELIVERABLE 10 1.3 RELATIONS WITH OTHER WORK PACKAGES 12 1.4 REFERENCE PROJECTS 13

1.4.1 COIN 13 1.4.2 FI-WARE 14 1.4.3 ECOLEAD 15

2 INNOVATION ECOSYSTEM PLATFORM SPECIFICATIONS 16

2.1 THE ROLE OF THE IEP IN THE MSEE SERVICE SYSTEM LIFECYCLE 16 2.1.1 VME Operations 18 2.1.2 MSE Governance 20

2.1.2.1 Tangible and intangible assets management process 22 2.1.2.2 Membership management process 22 2.1.2.3 Innovation management process 22 2.1.2.4 VME creation process 23 2.1.2.5 Ecosystem performance management process 23

2.1.3 MSE Innovation 23 2.1.4 Actors and roles 25

2.2 USER REQUIREMENTS AND USE CASES SPECIFICATIONS 27 2.2.1 Operational Processes 29 2.2.2 Ecosystem Governance Processes 32 2.2.3 Innovation Processes 36

3 FUNCTIONAL ARCHITECTURE 39

3.1 ECOSYSTEM FRONT-END AND COLLABORATION & COMMUNICATION SERVICES 41 3.1.1 Frontend Basic Service Modules 41 3.1.2 MSEE baseline modules 44 3.1.3 External app module 44 3.1.4 Communication & collaboration services 45

3.2 MATURITY ASSESSMENT AND CHANGE MANAGEMENT WIZARD 47 3.3 IDEATION PROCESS MANAGEMENT SYSTEM 51 3.4 OPERATIONAL/ECOSYSTEM-GOVERNANCE PROCESS MANAGEMENT SYSTEM 57 3.5 ASSETS MARKETPLACE AND TANGIBLE/INTANGIBLE ASSETS REPOSITORY 65

4 TECHNOLOGICAL COMPONENTS 71

4.1 ECOSYSTEM FRONT-END 71 4.1.1 Liferay 71 4.1.2 Drupal 72

4.2 IDEATION PROCESS MANAGEMENT SYSTEM 73 4.2.1 G2MO Idea Management 73 4.2.2 Open ideaL 74

4.3 OPERATIONAL/ECOSYSTEM-GOVERNANCE PROCESS MANAGEMENT SYSTEM 77 4.3.1 Process Maker 77 4.3.2 Activiti 79 4.3.3 Aperte Workflow 81 4.3.4 Bonita Open Solution 83 4.3.5 Spagic 85 4.3.6 Petals ESB 89




4.3.7 Mule ESB 91 4.4 MARKETPLACE AND TANGIBLE/INTANGIBLE ASSETS REPOSITORY 92

4.4.1 Sesame 94 4.4.2 Linked USDL Editor 95 4.4.3 FI-WARE Marketplace 96

4.5 MATCHING OF THE TECHNOLOGICAL COMPONENTS WITH THE FUNCTIONAL COMPONENTS 98 4.5.1 Functionalities coverage by technological products 103

5 CONCLUSION 106

REFERENCES 107

INDEX OF FIGURES

Figure 1 - Structure of the deliverable ...................................................................................... 11

Figure 2 - MSEE Service System Life Cycle ........................................................................... 16

Figure 3- The phases of the Service System Life Cycle .......................................................... 17

Figure 4 - MSE key business process identification method.................................................... 21

Figure 5- Manufacturing Service Ecosystem processes ........................................................... 22

Figure 6 - Phases of innovation process ................................................................................... 25

Figure 7 - Roles in the MSEE Innovation Ecosystem Platform ............................................... 26

Figure 8 - Operational processes use cases .............................................................................. 30

Figure 9 - Ecosystem Governance Process use cases ............................................................... 32

Figure 10 - Innovation Processes use cases .............................................................................. 36

Figure 11 - Innovation Ecosystem Platform ............................................................................. 39

Figure 12 - Ecosystem Front-end ............................................................................................. 41

Figure 13 - Authentication phase ............................................................................................. 42

Figure 14 - Example of document approval process ................................................................ 44

Figure 15 - Communication and collaboration services modules ............................................ 45

Figure 16- Maturity assessment and Change Management Wizard modules .......................... 48

Figure 17 - Example of Maturity Map...................................................................................... 49

Figure 18 - Ideation Process Management System modules .................................................... 52

Figure 19 - Idea Management Process Activity Diagram ........................................................ 56

Figure 20- Operational/ecosystem-governance process management system modules ........... 58

Figure 21 - Process Engine interaction with external components .......................................... 59

Figure 22 – Assets Marketplace and tangible/intangible assets repository modules ............... 65

Figure 23 - G2MO Idea Management ...................................................................................... 73

Figure 24 - Process Maker Cases Inbox ................................................................................... 78

Figure 25 - Process Maker Dashlets ......................................................................................... 79

Figure 26 - Activiti Explorer .................................................................................................... 80

Figure 27 - Activiti Designer .................................................................................................... 81

Figure 28 - Aperte Modeler ...................................................................................................... 83

Figure 29 - Aperte process map ................................................................................................ 83

Figure 30 - Bonita open solution .............................................................................................. 84

Figure 31 - Spagic configurable and activable modules........................................................... 86

Figure 32 - Spagic components ................................................................................................ 86

Figure 33 - Spagic Studio based on Eclipse IDE ..................................................................... 87




Figure 34 - Spagic web-based monitor ..................................................................................... 88

Figure 35 - Petals ESB ............................................................................................................. 90

Figure 36 - Mule ESB ............................................................................................................... 91

Figure 37 - USDL roadmap ...................................................................................................... 93

Figure 38 – Linked USDL Editor UI ........................................................................................ 95

Figure 39 – Example domain-specific extension ..................................................................... 95

Figure 40 - FI-WARE Marketplace Registration Interface ...................................................... 97

INDEX OF TABLES

Table 1 - Relations between WP26 and other MSEE work packages ...................................... 13

Table 2 - UC-OP-01 ................................................................................................................. 30

Table 3 - UC-OP-02 ................................................................................................................. 31

Table 4 - UC-OP-03 ................................................................................................................. 31

Table 5 - UC-OP-04 ................................................................................................................. 31

Table 6 - UC-GP-01 ................................................................................................................. 33

Table 7 - UC-GP-02 ................................................................................................................. 33

Table 8 - UC-GP-03 ................................................................................................................. 33

Table 9 - UC-GP-04 ................................................................................................................. 34

Table 10 - UC-GP-05 ............................................................................................................... 34

Table 11 - UC-GP-06 ............................................................................................................... 34

Table 12 - UC-GP-08 ............................................................................................................... 35

Table 13 - UC-GP-09 ............................................................................................................... 35

Table 14 - UC-GP-10 ............................................................................................................... 35

Table 15 - UC-GP-11 ............................................................................................................... 35

Table 16 - UC-IP-01 ................................................................................................................ 37

Table 17 - UC-IP-02 ................................................................................................................. 37

Table 18 - UC-IP-03 ................................................................................................................. 37

Table 19 - UC-IP-04 ................................................................................................................. 38

Table 20 – Communication module ......................................................................................... 46

Table 21 - Collaboration module .............................................................................................. 46

Table 22 - Online Questionnaire .............................................................................................. 48

Table 23 - Maturity level assessment ....................................................................................... 49

Table 24 - Roadmap definition ................................................................................................. 50

Table 25 - Ideation Process Repository .................................................................................... 52

Table 26 - Ideation Process Collaboration ............................................................................... 54

Table 27 - Ideation Process Analysis ....................................................................................... 55

Table 28 - Process Engine API ................................................................................................. 60

Table 29 - Process Engine ........................................................................................................ 60

Table 30 - Process Editor.......................................................................................................... 61

Table 31 - Process Monitor ...................................................................................................... 62

Table 32 - Process Log Repository........................................................................................... 62

Table 33 - Human-oriented tasks GUI ..................................................................................... 63

Table 34 - Enterprise Service Bus ............................................................................................ 64




Table 35 - Business Intelligence Tools .................................................................................... 64

Table 36 – Assets Marketplace ................................................................................................. 66

Table 37 - Assets Repository .................................................................................................... 68

Table 38 - Assets Editor ........................................................................................................... 68

Table 39 - Access Restriction Service ...................................................................................... 69

Table 40 - IEP modules in the MSEE cycles ........................................................................... 70

Table 41 - Ideation Process Management System .................................................................. 103

Table 42 - Operational/ecosystem-governance process management system ........................ 104

Table 43 - Tangible/Intangible assets management ............................................................... 104

Table 44 - Ecosystem frontend ............................................................................................... 104

ACRONYMS

API: Application Programming Interface

BPM: Business Process Modelling

IEP: Innovation Ecosystem Platform

KPI: Key Performance Indicators

MSE: Manufacturing Service Ecosystem

SLM: Service Lifecycle Management

SPx: MSEE Sub Project x

GUI: Graphical User Interface

USDL: Unified Service Description Language

VME: Virtual Manufacturing Enterprise

WM: Washing Machine

WPx: MSEE Work Package x




Executive Summary

The D26.2 “Innovation Ecosystem platform specifications and architecture” represents an

updated version of the D26.1 released in M9: the Innovation Ecosystem Platform is a web

based platform that supports the ecosystem in different typologies of processes that have

been categorized as: MSE Governance, for the management of the ecosystem and of its

members, MSE Innovation, for fostering and stimulating open innovation actions among the

ecosystem actors, and VME Operations, for allowing VMEs in the delivering of the new

value proposition (defined in the servitization process, see [1]) to the customer through

collaborative processes.

The scope of this deliverable is defining a generic and modular functional architecture:

generic because it has the aim to support a wide range of use case in the manufacturing

ecosystem domain being compliant with the requirements coming from different pilot

scenarios. It is modular and functionality oriented to better support the specific concrete

implementation of the Innovation Ecosystem Platform in each ecosystem.

As stated above the D26.2 contains an evolution of the first version of the architecture: the

D26.1 in fact, released in M9, represented an initial version of the architecture of the IEP that

was not complete and not totally stable due to the relative short time of the project. In

particular the user requirements analysis was incomplete, some of the technological issues

(e.g. integration problems, compatibility) have not be studied in deep, and several related WP

had produced partial results. The IEP, indeed, represents the main entry point of the MSEE

tools and platforms and for this reason is strictly connected with the most of the technical

work packages: in particular IEP is related to SP1 and SP2 because it will provide the

concrete tools to support theoretical concept and methodologies developed in these two sub

projects. The work performed in the MSEE project between M9 and M18 clarified several

aspects related to the user requirements but also the connection among the other MSEE

platforms and these new inputs have been fully integrated in this deliverable. D26.1 has

defined the basic role of the IEP in the whole MSEE IT system, that has been validated in the

following months also through a first concrete implementation of the platform while D26.2

covers some new topics and completes some aspects: reading the document it is possible to

see that the generic structure of the architecture is not changed, remaining valid, but a lot of

improvements and changes as been performed inside the components and modules about

functionalities and relationship with other work packages and outcomes of MSEE.

The main topics that have been included or upgraded in the D26.2 can be resumed in the

following points:

FI-WARE project outcomes: it has been explored and detailed the possible interaction

with FI-WARE project. In particular the FI-WARE marketplace and the Linked USDL

editor have been identified as two outcomes to be reused in terms of specifications and

reference implementations.

IEP use cases and user requirements: with the second version of user requirements

reported in D52.2 [9] it was be possible to refine the use cases of the platform creating

a mapping with the needs expressed by the pilot users that have been generalized

becoming basic specifications for the generic IEP.




MSEE processes in the service lifecycle: following the results achieved by the WP25

the Ecosystem Governance definition has been updated as the relative IEP

components (process management system).

Innovation and ideation: the ideation phase that starts, but that also iteratively

regenerates, the servitization cycle, has been extended to include the contribution of

social networking, outside of the MSEE ecosystem, in fostering ideas assessment and

feedbacks.

Maturity models and change management: D24.1 results allow to better define the

module in the IEP that is devoted to manage the maturity assessment and the change

process.

Components structure: the D26.2 contains several modification in the internal

definitions of components, modules and functionalities: some of this changes are due

to the feedbacks of the first release of IEP (M12) [2], others are related to new

requirements or new external functionalities (e.g. SSO integration) that were not

known or available at M9.

Technologies: the technology survey has been enlarged to include some new products

or services that were not available in M9 (e.g. Linked USDL editor) or that cover new

needs not identified before

The document structure (see more details in section 1.2) is composed by three main parts: the

first one defines the role of the IEP in the overall MSEE IT System and outlines the use cases

that the Platform has to support to overcome user requirements and MSE processes. The

second part presents the design of the functional architecture of the IEP, in terms of

component and modules. The last section is a survey of software, platforms and technological

components already available as Open Source that can be reused as base for the

implementation of the aforementioned modules.




1 Introduction

1.1 Objective of the deliverable

According to the Description of Work (DoW), the main objectives of WP26 are:

To design the specific architecture of the Innovation Ecosystem collaborative platform

To develop ecosystem-oriented distributed collaboration services

To develop/integrate specific services for Tangible and Intangible Manufacturing

Assets Mgmt

This deliverable is the final result of Task T2.6.1: Innovation Ecosystem Platform

specification and Design and its objective is to provide the second version of the IEP

specification and functional architecture. The deliverable being un updated version of the

previous D26.1 presents a revised version of the IEP architecture proposing also an upgraded

review of existing technological products and services, that can be taken in account for the

implementation of the final IEP prototype to be released in M24.

Therefore, the following objectives have been identified for the deliverable:

to define the role of IEP in the whole MSEE IT System and the relationship with the

other platforms and tools

to design and implement at technical level innovation methodologies and processes

defined in SP1 and SP2

to define final requirements and use cases of the Innovation Ecosystem Platform

based on the final version of the user requirements [9] ;

to design the final version of the functional architecture of the IEP based on use cases

descriptions;

to evaluate a set of software and technologies to be used to implement the functional

architecture.

1.2 Structure of the deliverable

The D26.2 is an updated version of D26.1 and it maintains the same general structure

organized into three major blocks, according to the objectives described in section 1.1:




Figure 1 - Structure of the deliverable

Block A defines the role of the IEP in the overall MSEE IT System and outlines the use cases

that the Platform has to support to enable its core processes. It contains the introduction

chapter that gives an overview of the structure of the deliverable the relation with the other

work packages and some information about background projects that have been studied as

baseline for several aspects in MSEE. Chapter 2 that contains the IEP specification presents

some basic concept of MSEE such as the servitization cycle and the three typologies of

business processes that the IEP will support. The second part of the chapter describes the use

cases of the IEP in conjunction with the user requirements presented in [9]. The chapter 2

reflects the most of changes respect to the one present in deliverable D26.1, in particular the

sections related to the MSE Governance process, redefined in WP25 and the final user

requirements table not available at M9.

Block B presents the design of the functional architecture of the IEP, providing specific

details of the single components and on their dependencies. This block contains the core

chapter of the D26.2, the design of the IEP architecture: in this chapter it is presented an

overview of the architecture and then the detailed description of each component and

respective modules. Respect to the D26.1 the architecture all the components has been revised

in terms of new interactions with other MSEE outcomes (e.g. the utility services developed in

WP33) or additional functionalities/services (e.g. Maturity assessment and Change

Management Wizard)

Block C provides a first evaluation of software platforms and components already available

as Open Source and that can be leveraged to develop the specific components of the

functional architecture. In comparison with the one presented in D26.1, this section has been

extended including some new products evaluated after M9: in some cases they were not

available before.




1.3 Relations with other work packages

Work Package 26 has the role of developing an integrated software platform that allows

ecosystem members to run collaboration and innovation processes according to the

conceptual and concrete outcomes of the rest of SP2 using services and tools that are released

by SP3 and SP4; moreover the SP5 that is in charge of requirements elicitation influenced the

design of the IEP. These means that D26.2 received inputs or it is connected with several WPs

and specific deliverables: the following table shows these relations.

WP name Relation Deliverables

WP15 - Service Life Cycle Mgmt

Tools

The main result of this WP is the

SLMToolbox, a software for

process modeling in the

servitization lifecycle. The IEP

will be able to import the

operational process modeled with

SLMToolbox in order to be

executed.

D15.2 Specification and

Design of SLM Toolbox

(M9)

WP21 - Reference Framework for

Innovation Ecosystems

WP21 provides the conceptual

basis for the implementation of a

tool for the management of

innovation processes in the

ecosystem.

D21.1 “State of the Art

report for requirements and

innovation principles”

(M6)

WP22 – Intangible Assets

Management

WP22 provides conceptual models

and basic prototypes to model

intangible assets aaS (as a

Service). Those assets will be

managed through dedicated tools

in the IEP.

D22.5 Intangible Assets in

Manufacturing

Service framework (M12)

WP23 – Tangible Assets

Management

WP23 provides conceptual models

and basic prototypes to model

tangible assets aaS (as a Service).

Those assets will be managed

through dedicated tools in the IEP.

D23.5 “OMSE

Instantiations to MSEE Use

Cases” (M15)

WP24 - Maturity Models and

Change Mgmt

WP24 provides models and

processes to (i) assess the maturity

level of an enterprise with respect

to the servitization-level and the

level of involvement of the

ecosystem; (ii) define a roadmap

that guides the enterprise in the

change process toward the desired

to be. Such models and processes

have to be integrated in the IEP,

through a dedicated tool, in order

to facilitate their enactment in real-

world scenarios.

D24.1 State of the Art of

maturity models and

change management in

European manufacturing

industry - v3 (M10)

WP25 - Service based Innovation

Ecosystems

WP25 will provide processes and

metrics to be implemented for

ecosystem governance in the IEP.

In particular this WP has the aim to

define the specific Ecosystem

Governance Processes.

D25.4 “Business Processes

for Distributed real time

Decision Making in Service

Ecosystems (M15)




WP32 - FI Platforms Federation WP32 has the aim to identify and

develop federated core platforms

components. One of these will be

the “Consumer Marketplace”, a

specific instance of the FI-WARE

Marketplace that interacts with the

IEP Assets Marketplace.

D32.1 “FI Platform

Federation specifications

and architecture” (M12)

WP33 - Future Internet Utility

Services

Federated Single Sign On and the

Feedback Management are two of

the services developed by WP33

that will be used by IEP modules.

D33.1 “FI Utility Services

specification and

architecture” (M12)

WP43 – “MSEE Generic Service

Delivery Platform”

The main outcome of this WP is

the development of the “MSEE

Generic Service Delivery

Platform” in which will be

registered all the services present

in the Ecosystem. The IEP will use

Delivery Platform in order to call

services during the execution of

the business processes.

D43.1 “Service Delivery

Infrastructure

specifications and

architecture” (M12)

WP52 – “Virtual Factories &

Enterprise requirements collection

& specification”

In the WP52 are collected the user

requirements for the 4 pilots of

MSEE. The IEP functionalities has

been designed to be compliant with

the needs identified by the 4 pilots,

but, at the same time, generic to be

valid for other cases in the MSEE

domain.

D52.2 “User Requirements

Analysis for Virtual

Factories & Enterprises in

MSEE” (M15)

Table 1 - Relations between WP26 and other MSEE work packages

1.4 Reference projects

Beyond dependencies and relations with internal MSEE work packages, the IEP will get

inspiration and baseline resources from other projects that represent the reference point with

respect to specific subjects, namely the COIN [3] Integrated Project, the FI-WARE [5] Project

and ECOLEAD Integrated Project [7]. On the one hand the IEP will be defined looking back

at the results of COIN, taken as a synthesis of the achievements of the Enterprise

Interoperability research stream; on the other hand FI-WARE will provide the necessary

connection with the vision of the Future Internet and with the related current developments in

terms of service models and related supporting technological environments.

1.4.1 COIN

COIN [3] is an integrated project in the European Commission Seventh Framework

Programme . 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), which 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)[4]. The philosophy of




COIN about Collaboration Platforms is adopted by the MSEE IEP, which will leverage the

results of COIN from the conceptual and technological perspectives. The functional

architecture of the COIN CP has indeed inspired the one of the MSEE IEP in terms of

strategies for integrating distributed resources, applications and services. Moreover

collaboration and interoperability services developed in COIN and published on the COIN CP

will represent a good foundation for further developments of services for the Manufacturing

Service Ecosystems. Enrichment and evolutions of those services will, for example, provide

specific means to fully leverage the value of enterprise assets through their publication as

services on a dedicated marketplace.

1.4.2 FI-WARE

The FI-WARE[5] project is part of the Future Internet Public Private Partnership (FI-PPP)

program of the European Commission. Its main result will be the FI Core Platform, which

comprises a set of technological “Generic Enablers” that are considered general purpose and

common to almost any industry domain. Among the various technical aspects addressed by

FI-WARE, MSEE is mostly interested in adopting and getting inspired by the infrastructure to

create, publish, manage and consume FI services, addressing all technical and business

aspects. In particular the use of USDL and of USDL-related Generic Enablers will allow the

description of services and their management across their life cycle. The adoption and

adaptation of those Generic Enablers to the necessities of MSEE (with the provision to FI-

WARE of relevant feedback and, possibly, requirements) represent one important result of

SP2 since usage areas formally related to FI-WARE (eHealth and Wellbeing, Content, Smart

Energy Grids, Utilities and Environment, Transport, Mobility and Logistics) do not include

the manufacturing industry and Future Internet Enterprise Systems (see FInES Cluster [6]),

which are the focus of MSEE. . During the first year of MSEE it has been performed an

analysis regarding the possible use of specific FI-WARE results. Among the full set of

Generic Enablers and FI-WARE outcomes some of them has been selected in order to be

customized for the MSEE needs in different work packages. In particular for the Innovation

Ecosystem Platform we selected the following component

Linked USDL [36]: the Innovation Ecosystem Platform will take advantage from the

reuse of FI-WARE Linked USDL, which is an RDF translation of USDL (Uniform

Service Description Language). Linked USDL will be extended and adapted to allow

the modeling of tangible and intangible assets, as defined by specific taxonomies

defined in WP22 and WP23specific. The Linked USDL language is supported by a

dedicated web-based editor (developed by the same subjects that are specifying

Linked USDL).This editor will be modified according to the modeling necessities of

the MSEE Project and will be integrated with the T/I assets repository allowing to

perform CRUD operation and model search.

FI-WARE marketplace: one of the most added value components of the Innovation

Ecosystem Platform is the marketplace: the FI-WARE marketplace reference

implementation will be used as basic implementation for the IEP marketplace

considering that the Consumer marketplace (WP 32) will be based on the same FI-

WARE implementation.




In the following sections will be presented some functional and technical details about the

here introduced FI-WARE components but during the second implementation phase of IEP

the investigation about the possible reuse of FI-WARE component will continue and new

available outcomes could be reused or extended in the IEP.

1.4.3 ECOLEAD

ECOLEAD was a 4 years “Integrated Project”, co-funded by the European Commission

under the Sixth Framework Programme (FP6-IST), that ended in 2008.

The main objective of ECOLEAD was to establish a solid mechanism to create an advanced

collaborative and network-based industry society in Europe. ECOLEAD achieved some

interesting results that have been taken in account during the conception of the IEP and that

may be reused for its implementation or for its extension in a second stage. The most

important results are:

Dynamic VO creation assistance: it supports the rapid creation of virtual

organizations;

VO collaboration and performance measurement: it records the collaboration

performances of all organization members, so everyone can select always the right

organization needed in new VO;

Contract negotiation wizard: it allows to quickly define the rights of the new

members when they decide to join together in a new VO;

VO management e-service: it manages an operating VO in ASP modality with low

impact to the single organization ICT structure;

Such results are taken into account as reference conceptualizations and implementations for

possible ecosystem management processes to be included in the IEP.




2 Innovation Ecosystem Platform Specifications

2.1 The role of the IEP in the MSEE service system lifecycle

The role of the Innovation Ecosystem Platform (IEP) in MSEE is to enable the execution and

the enactment of the business processes that characterize a Manufacturing Service Ecosystem

(MSE). The scope of those processes must be defined in the context of the overall Service

System Life Cycle (see Figure 2) that MSEE aims at supporting and guiding in the

manufacturing industry.

Figure 2 - MSEE Service System Life Cycle

Such a cycle is composed of two main phases:

The design-time phase, which corresponds to the servitization process, on the basis of

precise new business opportunities and after the set-up of a Virtual Manufacturing

Enterprise (VME)1 aims at grasping such opportunities, transforming the service

system from its As-is situation to the most appropriated To-be in terms of operative

processes, value-added services and through the leveraging of key assets of the VME.

This process is responsible for the design of the VME’s human, physical and IT

1 a Virtual Manufacturing Enterprise is an autonomous and self-contained enterprise that uses capabilities and

key assets of organizations ”extracted” from a MSE and of organizations that are not part of that MSE, in order

to exploit a specific business opportunity through ad-hoc processes and services that are designed and developed

in the servitizaion process.




resources2, leading to a new business model that switches the value offered from

physical products to product-service “bundles”.

The run-time phase , that on the one hand allows the management of an MSE (MSE

Governance), fostering and stimulating open innovation actions among the ecosystem

actors (MSE Innovation), and on the other hand exploits the new techno-

organizational configuration of VMEs (previously designed and developed in the

design-time phase) in order to deliver the new value proposition to the customer

through operational processes (VME Operations).

Figure 2 shows the two phases as separated and consequential: this can be considered only a

logic view because in the real world they are performed at the same time influencing each

other. Indeed the design-time phase is triggered by the MSE Innovation processes, which feed

the servitization process with new potential business opportunities and new innovative ideas.

When the servitization process starts, the Governance, Operative and Innovation processes

continue to address their objectives (see following paragraphs) independently from the status

of the design-time phase. At the end of the servitization process, the newly defined operative

processes are deployed and executed by the owner VME until they are dismissed.

Figure 3- The phases of the Service System Life Cycle

2 A human resource can be an operator, a manager or any people performing an activity in the service; Machine

type resource are devices and equipments that are needed to provide and deliver services. These components

may include: robots, specialized machines and devices for producing, delivering, maintaining services,

movers/transport means, as well as any kind of physical facilities used for the creation and consumption of

servicee; IT type resources include mainly software used to perform activities in the service to be delivered




In Figure 3 it is possible to see in details the phases that are present in the Service System

Lifecycle:

Service System Identification: identify domain and existing components, objectives,

challenges for a transition from product to service (or product + service);

Service System Concept: identify and define the main concepts (models, functions,

values,..) to create services around a product;

Service System Requirement: identify, describe and model end-users requirements

for the service system

Service System Design: design, specify and simulate the system that will provide that

service

Service System Implementation: describe how the designed service system will be

realized, deliver and implement physically all the needed components,

Service System Operation: service system is operational for use by customers and by

all the stakeholders. This includes service consumption and interaction with

customers, monitoring, evaluation and maintenance.

Service System Decommission: end of the service system. The service system is

removed and dismissed, whereas its components are reused.

This deliverable, while taking into account the different technological Platforms and modules

that support the Service System Life Cycle , has a specific focus on the functional architecture

of the IEP, which is the technological platform that will give support in the different phases

presented above. Further information about the servitization concepts and methodology, and

the role of MSEE IT system in it can be found in [1] and [16]

The actual value-added of the IEP is given by its integration in the overall conceptual and

technological framework that MSEE will provide to support the Service System Life Cycle.

Taken alone, indeed, the three kind of processes addressed by the IEP, are already managed in

the four MSEE pilots, but they all lack in terms of an end-to-end vision and enactment of the

Service System Life Cycle. The use cases and functional components described in this

deliverable provides requirements and guidelines to be followed during the development of

the IEP in order to allow a better integration of the three kind of processes and to make them

compliant with the conceptual frameworks and methodologies conceived in the rest of the

MSEE project.

The following sections describe more in detail the MSE Governance, MSE Innovation and

VME Operations processes in order to highlight their goals and facilitate the reading of the

formal analysis of the use cases that the IEP should satisfy to support their execution and

management (section 0).

2.1.1 VME Operations

VME Operations represent the set of business processes (operational processes from now on)

that allow a VME to deliver the product-service bundle to the final user. More precisely,

operational processes address the provision of value-added services that are bound to a




physical product. Such processes typically involve both the VME and the final user (intended

as a prosumer: indeed he/she contributes to the value creation), with the possibility to include

the product itself as part of the process. The source for actually define the scope and

collecting requirements of operational processes is WP52, in particular deliverable D52.2 [9]

that specifies the second version of the analysis of requirements and needs from the four

MSEE Use Cases.

According to the studies already conducted in WP52 on the MSEE use cases, activities of

operational processes span from human-to-human collaboration mediated by an ICT platform,

to product-to-human/human-to-product interaction, in which the physical product is an active

actor of the process (e.g. by triggering the start of a maintenance task or by feeding decisional

processes with real-time information about their status). In order to better understand a

concrete example of operational processes that will be supported by Innovation Ecosystem

Platform, in terms of IT tools, modelling and execution, following is briefly reported, the

Indesit Use case, the scenario identified in D52.2 that shows the specific operational

processes to be implemented in the two cycles of MSEE project. For the sake of brevity only

this case is presented in this deliverable but it is important to underline that the IEP will

support all the operational processes for the 4 pilot scenarios that are described in details in

D52.2

“The scenario is defined as a “Carefree Washing Service”, where the WM integrates a

set of features able to support the customer in traditional washing activities and to

realize a “carefree” use of the same product by providing additional services (e.g.

machine remote monitoring, soap control, feedback on usage, personalized best

practices, tailored marketing offers, personalized soap offer and furniture). Indesit’s

actual servitization level is rather low, as it is limited to selling the physical product

and few basic services, which are offered in a traditional way (e.g. warranty,

technical support, service call center, on-line registration and documentation download

etc.) (servitization level 2)...

...In particular, the Indesit scenario is focused on the provision of the following

macro functionalities:

1. WM Monitoring: control of the WM status, global WM data, last cycle

data, user habits, by web or mobile applications;

2. Best Practice Proposals: provision of personalized feedback and useful

advices elaborated on the basis of real user actions and

“errors/inefficiencies”;

3. Marketing Offers: provision of interesting marketing offers elaborated on the

basis of the specific user profile and his/her washing habits;

4. Detergent supply: provision of personalized detergent offers on the basis of

the specific user profile and his/her washing habits, suggestions of ad-hoc

WM-related products, and on-line order.”

The services package described above must be properly designed and developed in the




servitization process through dedicated methodologies and IT tools provided by MSEE (see

Table 1). The overall design and implementation of the service and of the service system (the

to-be of Figure 2) will include the specification of the operational processes for the service

provision.

The IEP has to allow the deployment, execution and monitoring of operational processes

through appropriate workflow, BPM and decision support systems. The analysis of the four

MSEE use cases leads to the definition of the use cases listed in section 2.2.1 for a system that

supports the runtime of operational processes. It is important to specify that the operational

processes, in general, as they are been identified during refinement of requirements, involve

heterogeneous entities in terms of actors and ICT systems. The IEP will offer support to

orchestrate and monitor the activities of these processes but the specific tasks could be

performed through IT systems external to the IEP (e.g. enterprise legacy systems).

2.1.2 MSE Governance

This section analyses the type of processes that a Manufacturing Service Ecosystem should

follow to implement its activities. These processes will be one of the major outputs of Task

25.3, which objective is to define and model the main governance and decision making

processes inside manufacturing service ecosystems.

Task 25.3 is an on-going task that will finalise in month 24 (September 2013), thus, in this

section a draft approach and list of processes is presented. This approach is to be improved,

enhanced and further developed in the months ahead and will be implemented in the

Innovation Ecosystem Platform.

Deliverable 25.4 [10] provided the description of the processes and interactions that will

enable to run the MSE governance within the Innovation Ecosystem Platform. When defining

which are the main business processes regarding a MSE, the definition of a MSE and its

mission had to be considered. This was defined in Deliverable 25.1 and MSE’s main features

were identified. According to the results of Deliverable 25.1, innovation, servitisation and

manufacturing are the pillars or features that shall pervade all the aspects of the ecosystem.

Based on these characteristics a MSE Conceptual Model has been proposed and governance

and decision making guidelines defined. These have been the grounds for the identification of

the key activities and, ultimately, key processes of a MSE.

The MSE processes have changed in comparison to Deliverable 26.1. This is due to the fact

that the MSEE project has progressed and evolved. The processes presented in Deliverable

26.1 were a preliminary version of the MSE processes that were further developed in the

corresponding deliverable (Deliverable 25.4, due in month 15), based in the MSE Conceptual

Model developed in Deliverable 25.1.

Consequently, the work conducted in WP25 has had as a result that a different methodology

was used in order to define the MSE processes and has caused that some processes that were

included in Deliverable 26.1 have been removed and other process have been added.




Figure 4 - MSE key business process identification method

The figure above shows the method followed in order to define the key business processes of

a MSE. Based on the components that a MSE should be composed of, several activities have

been derived. These are considered to be the main activities a MSE should conduct in order to

reach its objectives. Finally, taking into account these main activities, MSE’s key business

activities have been identified:

tangible and intangible assets management process

membership management process

innovation management process

Virtual Manufacturing Enterprise (VME) creation process

performance management process

It is important to point out that the primary or key activities of the ecosystem are related to

service innovation management, resources and participants management and VME creation.

Meanwhile, other administrative processes are considered as support processes of the

ecosystem. The following figure is merely illustrative and represents the ecosystem processes:

in the upper part of the image the key processes are indicated (described in this section).

These reflect the primary activities performed in the ecosystem and implemented through the

Innovation Ecosystem Platform. On the bottom, ecosystem support processes are mentioned.




These processes will not be implemented in the Innovation Ecosystem Platform and will not

be analysed in the framework of the MSEE project.

1. Tangible and intangible assets management process

3. Innovation management process

Administrative processesSupport processes

5. Performance management process

Key activities2. Membership management process

4. VME creation process

Figure 5- Manufacturing Service Ecosystem processes

2.1.2.1 Tangible and intangible assets management process

This process addresses the organisation and management assets within the MSE. Its aim is to

facilitate putting at disposal of the MSE the tangible and intangible (T/I) assets of the MSE

members. This process shall include the following sub-processes:

T/I assets collection and assessment

T/I assets planning and management

T/I assets evaluation

T/I assets modification and removal

2.1.2.2 Membership management process

It involves the administration of the entrance and exit of members into a MSE, as well as

managing their profiles. It includes the submission, storage, access, deleting and modifying

members’ company and contact information. This process shall include the following sub-

processes:

Application for MSE membership

Expelling of a MSE member

Leaving the MSE

Updating MSE member profile

Recruitment of new MSE member

2.1.2.3 Innovation management process

It comprises the activities that are carried out to facilitate the development of new ideas

within a MSE. This process is further detailed in section 2.1.3.




2.1.2.4 VME creation process

It involves the setting the grounds for the creation of VMEs within a Manufacturing Service

Ecosystem, by guiding the MSE members through the mechanisms and activities that will

enable to reach that goal. This process may include the following sub-processes:

Preparatory planning

Consortia formation

VME launching

VME set up

2.1.2.5 Ecosystem performance management process

This process includes the controlling tasks that are required to maintain the quality and to

improve the performance of the ecosystem. Therefore, it involves tasks as the definition of

key performance indicators, assessment and improvement of processes and systems, partners’

performance evaluation, etc. It may include the following sub-processes:

Members’ performance management

T/I assets performance management

VME monitoring

The general requirements that can be currently extracted for ecosystem-governance processes

lead to the definition of the use cases listed in section 2.2.2.

2.1.3 MSE Innovation

The VME operations and MSE governance processes are strictly related: a VME cannot exist

without the ecosystem and the related processes: also the operative process aimed to deliver

product-service bundles are executed in the ecosystem. For this reason the VME operations

and MSE governance process have to be considered two parallel processes groups.

Besides these, a key role it is also played by the innovation process, that includes all the

activities aimed to promote new ideas to restart and continuously renovate the MSEE Service

System Life Cycle. The innovation process involves different parties of the ecosystem with

roles that must be well-defined in advance. Indeed, although innovation frequently stems from

individual and informal initiatives/activities, its management has to follow a structured and

commonly agreed procedure, in which ideas are discussed, merged, elaborated, evaluated,

filtered, through different stages, and in which people are in charge of decisions at specific

stages. Deliverable 21.1[11], part of WP21 (“Reference Framework for Innovation

Ecosystems”), defines a formal innovation framework that should be adopted in

Manufacturing Service Ecosystems, with the support of tools and platforms of the MSEE IT

System.

The framework defines the innovation process with the following phases:

Idea Generation: during this phase employees and customers submit ideas both

responding to a campaign created by a campaign organizer or to an on-going theme




for which companies of the ecosystem always require proposals. Ideas can be

associated with some existing categories, tags and multimedia files.

Concept Development: ideas created in the Idea Generation Phase are improved with

votes, comments, more tags and attachments submitted by others employees and

customers. Votes and comments contribute to the calculation of rating of the ideas.

Ideas can be interlinked and merged in order to elaborate new concepts. At the end of

this phase the best ideas are selected to feed the following phase.

Prototyping: during this phase accepted ideas are transformed into prototypes in order

to have an early evaluation of their business potential.

Manufacturing: during this phase accepted prototypes are transformed to final

product-service bundles

Marketing & Sales / Launch: the product-service bundle is launched on the market

and operational processes are enacted in the ecosystem in order to deliver it to the

final users.

From D21.1: “The considered process starts with the early idea generation (sometimes before

a specific innovation project has even started) and result in product launch, marketing and

sales. Therefore the following PIs can be regarded as an option to assess the “innovation

capability” of an organisation. The performance of the innovation process has to be

monitored and controlled to ensure that the activities make best use of the provided input and

that the objectives regarding the output are achieved. To enable general conclusions the

indicators have to regard the sum of on-going and finished projects.”

The same deliverable proposes an initial set of PIs to be measured:

“Number of ideas submitted by employees in a defined period of time. Or number of

ideas/builds collected.

Number of ongoing experiments and ventures.

Number of employees / “Authors” who submitted ideas. Alternatively: Ratio of these

employees in relation to the overall number of employees.

Number of ideas reviewed and concluded.

Number of Ideas passed through to concept development

Number of Event Visitors / Contributors

Average time required from idea conceptualization to go-forward decision.

Number of examined customer groups.

Number of ideas collected.

% of suppliers engaged in the collaborative design.




% of ideas from outside.

Number of Voice of Customer specifications.”

The aim of the Innovation Ecosystem Platform is to support the initial phases of Idea

Generation and Concept Development (which constitute the Ideation Process) in order to feed

the servitization process with innovation opportunities to be transformed into actual value.

Figure 6 - Phases of innovation process

The ideation process must leverage collaboration tools to foster the generation of new ideas,

collect and elaborate them and finally select those ideas that represent a viable opportunity for

the ecosystem. In particular,

ideas should be generated through ecosystem-wide idea contests

ideas collected should be rated and commented by any members of the ecosystem

members should discuss improvements to the ideas through collaboration tools

ideas should be reviewed, ranked and finally selected by appropriate actors in order

to feed the servitization process.

The general requirements extracted from D21.1 and from the MSEE scenarios lead to the

definition of the use cases listed in section 2.2.3 for a system that supports the enactment of

the ideation process.

2.1.4 Actors and roles

The Innovation Ecosystem Platform will provide functionalities for the different members of

an ecosystem involved in the Innovation, Governance and Operational processes. This section

introduces at a high level the roles that are played by the actors in the different processes.

Further refinements (specializations) and details about such roles and their use cases are

provided in the next sections. The set of roles should not be considered as definitive, but

subject to further refinements in the following phases of the project.




Figure 7 - Roles in the MSEE Innovation Ecosystem Platform

Any actor that is formally part of the ecosystem is an Ecosystem Member: an Ecosystem

Member can be an organization (e.g individual enterprise, individual research center, etc), a

person belonging to an organization that is part of the ecosystem, but also a Virtual

Manufacturing Enterprise that is a composition of the previous ones. According to the

specific characteristics and policies of the ecosystem, this role can be detailed in many other

specialized sub-roles. One of those sub-roles is the Ecosystem Manager, who is responsible

for the definition and enactment of the processes related to the MSE Governance. Such

processes involve both Ecosystem Members and the Virtual Manufacturing Enterprises. The

former take part to processes such as the above introduced members management, legal

processes and intellectual property management, whereas the latter must be monitored during

their lifecycle by the Ecosystem Manager in order to check for their compliance to the

ecosystem’s policies and rules.

During its lifecycle a VME delivers its product-service bundles to the customer through

operational processes (VME Operations). The specific roles of the VME’s members cannot be

exploded here since such level of detail has to be defined case-by-case (in the servitization

process), for each particular operational process. It is to be noticed that the customer (which is

the final user/consumer of the VME’s value proposition) is involved in the VME Operations

too. Finally the ideation process (i.e. the initial part of the Innovation Process) is concurrently

participated by any member of the ecosystem (including VMEs, although not represented in

the figure) and by customers, depending on the policies defined by the issuer of the idea

campaign.




2.2 User requirements and use cases specifications

This section specifies the most important use cases that the IEP has to support with respect to

the three types of processes: operational processes, governance processes and innovation

processes. The use cases have been specified by analysing the functionalities required in the

MSEE Description of Work in conjunction with the user requirements gathered in SP5 and

the outcomes of the technical meetings, which involved the partners in charge of the other

work packages related to the IEP. In particular in this second version of the document the

specification of the use cases has been revised creating a mapping with the final version of the

user requirements available in D52.2. The following table is an extract of the final

requirements tables contained in D52.2: for each use case have been selected from the

complete list of requirements only the requirements to be covered by IEP. The complete set of

user requirements contained in D25.2, includes also the requirements to be satisfied by other

MSEE outcomes.

In the table, for each requirement and expected outcomes, we included the use cases,

described in the next sections, that cover the specific requirement.

ID Requirement Expected MSEE outcome

Innovation Ecosystem

Platform UCs covering

requirement

TPVision

U1

Tools to share ideas and

support the approval

process

Innovation Ecosystem Platform (IEP)

A collaborative system for fostering and

managing the creation of new and

innovative ideas, through cross-

organizational and user-inclusive initiatives.

This component can provide a continuous

and unstructured stream of suggestions,

hints, ideas and potential opportunities to

innovate the product-service value

proposition that the Ecosystem offers to its

customers

UC-IP-01 Generate Ideas

UC-IP-02 Improve Ideas

UC-IP-03 Select Ideas

UC-IP-04 Search ideas

U2 Platform to share data

between ecosystem partners

Innovation Ecosystem Platform (IEP):

Allows Ecosystem members to manage

virtualized Tangible and Intangible Assets,

and to offer their capabilities as services to

the market – internal to the Ecosystem or on

the public Internet. The marketplace will

provide the functionalities to search assets

and to request them (e.g. machinery,

competences, etc).

UC-GP-01 Model T/I assets

UC-GP-02 Manage

tangible/intangible assets

UC-GP-03 Search T/I assets

U3

Tool/Guidelines to manage

the ecosystem and the

information flow in the

ecosystem

Governance tools of information flow in

the ecosystem

UC-GP-04 Model process

UC-GP-05 Develop process

UC-GP-06 Monitor process

instances

UC-GP-09 Execute tasks




U6

Estimate the

impact/adoption of a

introduction of a service in

the future

A method to define and implement KPIs in

service system and business intelligence on

ecosystem Intangible assets

UC-GP-07 Define KPIs

UC-GP-08 Analyze and

monitor KPIs

Indesit

U9

Platform to manage the

ecosystem and defining the

current ecosystem in terms

of TA & IA

Innovation Ecosystem Platform


UC-GP-02 Manage



U10 Tools to support service

idea generation

Innovation Ecosystem Platform: Business

Intelligence, Statistics, Idea Generation

UC-IP-01 Generate Ideas

UC-IP-02 Improve Ideas

UC-IP-03 Select Ideas

UC-IP-04 Search ideas

U14

Assessment of the

ecosystem maturity and

change management

Maturity models and change management

UC-GP-10 Assess maturity

level

UC-GP-11 Define change

actions

U15

Ecosystem governance

(level of activity,

interactions, roles, flow of

information)

Methodology for management and

governance of MSEs (“MSE Compass”)




instances


Bivolino

U27

platform to support the

ecosystem partners

modelling in terms of their

assets and partner statistics

(partners level of activity,

interactions, roles, flow of

information)

IEP Innovation Ecosystem Platform


UC-GP-02 Manage



U28

tool for governing external

partners to the ecosystem

and involve them

Governance Processes in Innovation

Ecosystem Platform




instances


Ibarmia

U29

Defining the current

ecosystem in terms of TA

& IA

Tangible/Intangible assets implemented in

the Innovation Ecosystem platform


UC-GP-02 Manage



U36

Tools to understand weak

or less mature points of the

ecosystem and guidance on

how to improve them or

start training

Maturity Models And Change

Management

UC-GP-10 Assess maturity

level

UC-GP-11 Define change

actions

U39 Platform to support the

ecosystem Innovation Ecosystem Platform




instances





U40 Guidelines and tools for

ecosystem governance Innovation Ecosystem Platform




instances


In the following sections for each use case it is provided a table with a general description and

the actors involved. In the use case table is also stated the MSEE project cycle in which the

use case should be implemented: the first cycle corresponds to the first release of IEP

prototype (M12), the second to the final release (M24). For the first cycle have been selected

the most priority functionalities in order to support the first release of pilots implementation

(M18).

2.2.1 Operational Processes

Operational processes are directly derived from the servitization process and involve the

following specific roles:

IT Service Manager: the actor in charge of the management of the IT infrastructures

of the ecosystem and of the management of the lifecycle of the processes-instances in

the operative and runtime environment.

VME Manager: once a VME has been created, the role of VME Manager is

responsible for its management from a strategic and tactical point of view.

VME Operator: once a VME has been created, the role of VME Operator is

responsible for its management from an operative point of view.

Ecosystem Manager and Customer are defined in section 2.1.4.




Import executable process

IT Service ManagerCustomer

VME Operator

Execute tasks

Monitor process instances

Analyze and monitor KPIs and SLAs

Ecosystem Manager

VME Manager

Figure 8 - Operational processes use cases

The following tables list and describe the main use cases identified for the management and

execution of the operational processes.

Use Case ID UC-OP-01

Name Import executable process

Description The executable model of an operational process is issued by the

Generic Service Development Platform. This model is an extension of

the BPMN 2.0 [12] XML serialization: such extension (TSM level)

must be supported by runtime environment of the IEP.

Users IT Service Manager

MSEE Project

Cycle

Second

Table 2 - UC-OP-01


Name Execute tasks

Description The executable model of the operational process (UC-OP-01) must be

deployed in a run-time environment which is able to manage the state

of different instances of the process.

The actual execution of an end-to-end process requires the

orchestration, in the proper order, of the defined human and automatic




tasks. The runtime environment of the IEP has to support in a

seamless way both the type of tasks.

In particular human-oriented tasks of the process must provide a GUI

to the proper user in order to collect his/her input. Each user who has

a role in the operational process must be notified of the tasks that

he/she is authorized/requested to accomplish.

Automatic tasks of the process (e.g. web-services) must be invoked

from any source of a private enterprise, of the ecosystem or of the

Open Internet. Invocation of web-services from the different levels

(private enterprise, ecosystem, Open Internet), must be subject to

proper security and authorization rules.

Users Customer, VME Operator

MSEE Project

Cycle

First

Table 3 - UC-OP-02


Name Monitor process instances

Description Each instance of the operational processes (and each task that it is

composed of) has a specific status (started, idle, running, completed,

…). Processes and tasks need to be monitored both technical (e.g.

technical problem of IT services) and business sides (e.g tasks to be

completed by specific users) to prevent and handle unforeseen

exceptions and/or bottlenecks. The monitoring of process instances

includes the possibility to pause, stop, re-start and cancel any

instance.

Users VME Manager, IT Service Manager

MSEE Project

Cycle

First

Table 4 - UC-OP-03

Use case ID UC-OP-04

Name Analyze and monitor KPIs and SLAs

Description The analysis of process logs and of any other data source through

Business Intelligence techniques allows the managers of the VME

and of the MSE to check for the compliancy of the operational

processes to the KPIs and SLAs defined in the servitization process.

Users VME Manager, Ecosystem Manager

MSEE Project

Cycle

Second

Table 5 - UC-OP-04




2.2.2 Ecosystem Governance Processes

Ecosystem Governance Processes enable the management of every aspect of an ecosystem

and involve the following specific roles: Ecosystem Member, Ecosystem Manager, VME and

IT Service Manager. Those roles have been already briefly introduced in the previous

sections. Beside this actor is also present the Business Expert mainly involved in the T/In

asset modelling:

Business expert: he is an expert of the business sector of a specific company. He

knows the business process, the company skills and assets, the business strategy, the

opportunities, weak and strong points.

Model process

develop process

IT Service Manager

Execute tasks

Ecosystem Manager

Virtual Manufacturing EnterpriseEcosystem Member

Monitor process instances

Analyze and monitor KPIs

Manage T/I assets

Assess maturity levelDefine change actions Model T/I assets

Search T/I assets

Business Expert

Define KPIs

Figure 9 - Ecosystem Governance Process use cases


execution of the ecosystem governance processes:

Use Case ID UC-GP-01




Name Model tangible/intangible assets

Description The participation of ecosystem members to VME is based on the

tangible and intangible assets they can expose and leverage to deliver

the product-service bundle to the customer. Tangibles and intangibles

assets have to be,represented in a digital format (virtualized) using

specific models and ontologies and then represented in a service-

oriented interoperable language (e.g. USDL).

Users Business Expert

MSEE Project

Cycle

Second

Table 6 - UC-GP-01


Name Manage tangible/intangible assets

Description The T/I assets virtualized have to be stored in a repository/registry

that can be accessed by the authorized human and automatic agents

through specific GUIs and APIs. This use case include all the CRUD

operations that can be performed on the repository.

Users Ecosystem Member

MSEE Project

Cycle

First

Table 7 - UC-GP-02


Name Search tangible/intangible assets

Description The ecosystem users have to be able to search in the T/I asset

repository to find competencies and capacities in order to perform

specific business activities or to create a new VME.

Users Ecosystem Member

MSEE Project

Cycle

First

Table 8 - UC-GP-03

Use case ID UC-GP-04

Name Model process

Description The creation of new workflows that are needed to support the

governance of the ecosystem has to be guided by the high-level

description of the Ecosystem Manager. He/she must be enabled to

model the activities of the workflow.

The modelling language has to be compliant to those defined by SP1

in the SLMToolbox




Users Ecosystem Manager

MSEE Project

Cycle

First

Table 9 - UC-GP-04


Name Develop process

Description After the Ecosystem Manager has defined the high-level model of a

workflow for supporting the management of the ecosystem, the IT

Service Manager acts as a developer and completes the model in

order to make it executable in the runtime environment of the IEP.

Users IT Service Manager

MSEE Project

Cycle

First

Table 10 - UC-GP-05


Name Monitor process instances

Description Each instance of the ecosystem governance processes (and each task

that is composed of) has a specific status (started, idle, running,

completed, …). Processes and tasks need to be monitored both

technical (e.g. technical problem of IT services) and business sides

(e.g tasks to be completed by specific users) to prevent and handle

unforeseen exceptions and/or bottlenecks. The monitoring of process

instances includes the possibility to pause, stop, re-start and cancel

any instance.

Users Ecosystem Manager, IT Service Manager

MSEE Project

Cycle

First

Table 11 - UC-GP-06


Name Define KPIs

Description The Ecosystem Manager is supported by the IEP in the technical

implementation of the ecosystem-level KPIs defined in WP25.


MSEE Project

Cycle

Second





Name Analyze and monitor KPIs

Description The analysis of process logs and of any other data source through

Business Intelligence techniques has to allow the manager of the

MSE to check for the compliancy of the governance processes to the

ecosystem-level KPIs defined.


MSEE Project

Cycle

Second

Table 12 - UC-GP-08


Name Execute tasks

Description The execution of the process is the orchestration, in the proper order,

of the defined human and automatic tasks. The runtime environment

of the IEP has to support in a seamless way both the type of tasks.

This use case has the same functional and non-functional

requirements of UC-OP-02

Users Ecosystem member, VME

MSEE Project

Cycle

First

Table 13 - UC-GP-09


Name Assess maturity level

Description Assess the maturity level of an enterprise with respect to the

servitization-level and the degree of involvement of the ecosystem.

Users Ecosystem member

MSEE Project

Cycle

Second

Table 14 - UC-GP-10


Name Define change actions

Description Define a roadmap that, after the assessment (as is) of the maturity

level of an enterprise, guides the enterprise in the change process

toward the desired to be (in terms of servitization level and level of

involvement of the ecosystem)


MSEE Project

Cycle

Second

Table 15 - UC-GP-11




2.2.3 Innovation Processes

Innovation Processes allow ecosystems to elaborate new ideas and create new value. The

focus of the IEP is on the initial part of the Innovation Process (Idea Generation and Concept

Development), that is the Ideation Process, which is participated by the following roles:

Customer: customers of an organization are involved in the idea management

process. They participate by submitting new ideas and by commenting and voting

existing ideas;

Ecosystem Member: employees of an organization that is part of the ecosystem

contribute to idea generation and improvement by submitting new ideas and by

commenting or voting existing ideas;

Reviewer – the reviewer can make some review about submitted ideas, like financial

review or technical review.

Decision Maker: this is the actor that looks at the rating, comments, reviews and

statistics related to ideas and selects ideas that are valuable for a business initiative.

Campaign Organizer: he sets up ideas campaign using simple on-line form or he

promotes it via other means (e.g. e-mail)

Moderator: a person given special powers to control the submissions and comments

of other participants.

Generate Ideas

Customer

Campaign Organizer

Ecosystem Member

Improve Ideas

Moderator

Select Ideas

Reviewer Decision Maker

Search Ideas

Figure 10 - Innovation Processes use cases





execution of the innovation process.

Use Case ID UC-IP-01

Name Generate Ideas

Description Ecosystem Members and Customers submits ideas both responding to

a campaign created and managed by a Campaign Organizer or to an

on-going theme for which the ecosystem always requires ideas. They

can associate ideas with some existing categories or tags to help the

overall management of the ideas.

Users Campaign Organizer, Ecosystem Member, Customer

MSEE Project

Cycle

First

Table 16 - UC-IP-01


Name Improve Ideas

Description Ideas generated by Customers and Ecosystem members are improved

with votes, comments, more tags and attachments submitted by other

users. Votes and Comments contribute to the calculation of rating of

the ideas. The ideas can be also merged if they are referred to

identical topics. This phase is monitored by a Moderator, who

enforces the compliancy of the community to specific policies and

rules.

Users Customer, Ecosystem member, Moderator

MSEE Project

Cycle

First

Table 17 - UC-IP-02


Name Select Ideas

Description Ideas are processed by Reviewers (e.g. Domain Experts), that can

create reviews of ideas for better analyze some aspects like financial

or technical ones. They can do some studies of ideas like SWOT

analysis and attach results to ideas. They can also create interlinks

between ideas to identify similar ideas, opposite ideas or extending

ideas. The Decision Maker has access to ideas reviews and ratings

and decides which ideas are accepted and which are refused.

Users Reviewer, Decision Maker

MSEE Project

Cycle

First

Table 18 - UC-IP-03





Name Search Ideas

Description Ideas can be searched by several attributes, such as content, author

and tags / metadata, The ideas can be aggregated using specific filter

in order to simplify improvement and selection activities.


MSEE Project

Cycle

First

Table 19 - UC-IP-04




3 Functional architecture

In order to support the variety of use cases presented in the previous section, the functional

architecture of the IEP (Figure 11) is here introduced showing the main interaction of its

functional blocks with the rest of the MSEE IT System and with the outputs of the other work

packages. The architecture, which will be described in the following section, implements

through a set of components, the functionalities defined in chapter 2. Every component

supports one o more use cases, and it is based on (or related to) the contribution coming from

other MSEE work packages (see Table 1 and Figure 11): the IEP, as depicted in the previous

sections, supporting different phases of the MSEE Service System Life Cycle, can be

considered the main entry point of the MSEE service system. The IEP integrates a set of SP2

tools, has to communicate with the SP4 platforms in order to support the operational

processes developed by the Development Platform and published in the Delivery Platform

(see [16]), and also it uses some services coming from SP3 (e.g. the SSO utility service).

Figure 11 - Innovation Ecosystem Platform

Following the IEP main component are introduced, in the next section their structure and

functionalities will be detailed: the Ecosystem Front-end is the single point of access to the




Ecosystem for ecosystem members and it integrates in a single graphical environment all the

other components.It consists in an enterprise web portal in which it is possible to manage the

information related to the ecosystem such as enterprise and users information, documents,

news etc. Such information are stored in the Ecosystem Repository that represents the

general database that contains all the the ecosystem data.

The Maturity assessment and Change Management Wizard, represents a concrete tool to

guide the enterprises through change management processes and toward a higher level of

maturity with respect to their servitization level and their involvement in the ecosystem. This

component can be considered a concrete implementation of the results coming from WP24

[17] and is considered a tool to support the MSE Governance.

Ideation Process Management System, is a system for fostering and managing the creation

of new and innovative ideas through cross-organizational and user-inclusive initiatives. The

component provides to the SLMToolbox (which is part of the Generic Service Development

Platform) a continuous and unstructured stream of suggestions, hints, ideas and potential

opportunities to innovate the product-service value-proposition that the ecosystem offers to its

customers. The component is related to the outcomes of WP21.

The, Communication & Collaboration Services component, supports the ecosystem

through a coherent set of communication and collaboration services that allow members to

share contents and collaborate on their evolution, discuss and interact through web 2.0 tools.

Assets Marketplace and Tangible/Intangible Assets Repository, provides the means to

ecosystem members to manage virtualized tangible and intangible assets and to offer their

capabilities as services to the market (internal to the ecosystem or open to the Internet).

Operational/Ecosystem-governance Management System, component represents the front-

end applications for the enactment and monitoring of operational and ecosystem-governance

processes. It provides a graphical interface that on one side allows members of the ecosystem

to participate to those processes in specific human-oriented activities through ad-hoc defined

web-forms, and on the other side presents the quantitative measures of Performance

Indicators evaluated on the executed processes. The run-time engine in which both

operational and ecosystem-management processes are executed allows the orchestration of

automatic (e.g. web services) and human-oriented (i.e. web-form enabled) activities. It has to

be noticed that operational processes are modelled in the SLM Toolbox and engineered by the

Development Platform, whereas ecosystem-governance processes are fully managed in the

IEP. Moreover in the case of operational processes, automatic activities are retrieved and

invoked through the Generic Service Delivery Platform; in the case of ecosystem-

management processes, activities will mostly rely on services based on the virtualization of

tangible/intangible assets of the ecosystem’s members.

In the following chapters will be described in details the IEP components and the related

modules: for each of them are provided information about the functionalities they will support

and about the MSEE project cycle in which the functionalities will be implemented: the first

cycle corresponds to the first release of IEP prototype (M12), the second to the final release

(M24).




3.1 Ecosystem Front-end and Collaboration & Communication Services

The Innovation Ecosystem Platforms integrates several tools and services aimed to support

the whole MSEE Service System Life Cycle: in order to achieve this objective the IEP has to

provide to final users (i.e. any actor that is involved in the ecosystem) a consistent and simple

front-end. The IEP frontend will consist in a web portal where actors can access the tools and

functionalities that are granted to their role and can interact with others stakeholders through

communication and collaboration services.

The IEP will integrate the different functional components and make them available to the

final users through this single point of access.

Figure 12 - Ecosystem Front-end

For the purpose of integrating different components, the Ecosystem Front-end will provide

three groups of modules: Frontend Basic Service Modules, MSSE Baseline Service Modules

and External App modules.

3.1.1 Frontend Basic Service Modules

In this set of modules we include the generic functionalities and utilities related to the web

portal application.

Name Authentication

Description It interacts with the Federated Single-Sign-On functionality, a

Utility Service provided by WP33 allowing the authentication of the

users . In particular it consists in a client component that receives

information about the identity of the user provided by Federated

SSO services and then profiles the user with the specific application




roles of the IEP.

Functionalities /

services

Support for SSO authentication

Dependencies The Authentication module uses the SSO functionalities provided by

Federated Single-Sign-On utility service (WP33)

User All the Ecosystem Members will use the Authentication Module

MSEE Project Cycle First

Figure 13 - Authentication phase

The Figure 13 shows the authentication process that can be explained in the following steps:

1. Unauthenticated Client requests access to IEP

2. IEP redirects Client to SSO

A. sends Service ID

3. Client does login with SSO

A. sends Service ID + credentials

4. SSO redirects client to IEP

A. sends Service Ticket

B. sets cookie on Client with Ticket Granting Ticket

5. Authentication Module verifies Service Ticket with SSO

A. sends Service ID + Service Ticket

B. gets user identity & info

6. Authentication Module binds user identity & info to user session

7. Authenticated Client is granted access to IEP




Further details about federated SSO service and its functionalities can be found in [18] and

[19]

Name Portal Administrator

Description Dedicated to the portal administrator, provides the functionalities

related to the portal configuration: for example the portal

administrator will be able to manage the user application roles, the

graphical templates, security policy etc. The monitor of technical

performance and problems related to the portal it is also included in

this module.

Functionalities /

services

User role management

User group management

Portal technical configuration and logs

Backup and recovery

Dependencies

User The IT Service Manager and the Ecosystem Manager will use this

module

MSEE Project Cycle first

Name Content management system (CMS)

Description This module allows to create, upload and publish different types of

contents on the portal such as textual news, and multimedia files.

The contents can be restricted to specific users or groups. This

module can be used, not only by the system administrator but also

by single enterprises in order to publish specific contents (e.g,

promotions, event, advertisement, profiles etc) and it provides also a

WYSIWYG editor in order to facilitate the content creation. The

CMS has a content approval process based on a workflow with

specific roles and tasks.

Functionalities /

services

Content creation (web articles, document with mixed content

etc.)

Document workflow approval process

WYSIWYG editor

Multimedia content support

Dependencies This component uses the document manager modules to store and

retrieve documents




User An Ecosystem Member can use this module (e.g. an enterprise

responsible)


Figure 14 - Example of document approval process

Name Document Manager

Description Through this component the users can upload/download, organize

and find any type of files. The access to the files can be restricted to

specific users or groups.

Functionalities /

services

Store, search, retrieve documents

Document versioning

Categorization and tag support

Support for external protocol (e.g. WEBDAV)

Dependencies The Document Manager uses the Ecosystem Repository as

document repository.

User A generic Ecosystem Member can use this module


3.1.2 MSEE baseline modules

These modules represent the integration modules of the services/applications specific for the

MSEE context related to the objectives to be achieved by the Innovation Ecosystem Platform.

These modules will provide access to the functional components described in the next

sections.

3.1.3 External app module




the frontend will be able to integrate the external applications, using API, if provided, or

maintaining the same UI embedded in the portal (e.g. iframe approach).

3.1.4 Communication & collaboration services

The ecosystem Front-end component integrates also the communication & collaboration

services: one of the most important values of an ecosystem is related to the degree on

relationship and interactions among the entities taking part in it. The Innovation Ecosystem

Platform will foster and support these interactions through a set of services that will allows

companies and customer to communicate, collaborate and make business. These services, that

will be integrated in the Ecosystem Front-end will be provided by two modules:

Communication Collaboration

Figure 15 - Communication and collaboration services modules

Name Communication

Description The aim of this module is to give to the ecosystem entities a wide

range of tools to communicate using different medias and devices,

but also to take advantage from the social networking. The

communication could be private or public in the ecosystem or also

published outside of the ecosystem. This type of services would be

used for example to promote products, to provide support to

customers etc.

Functionalities /

services

messaging services (e.g. chat, instant messaging, mailing

list),

forum, wikis

social network integration (facebook, twitter etc)

support for mobile communication

Dependencies

User This module will be used by any ecosystem member and other




external actors (e.g. Customers)


Table 20 – Communication module

Name Collaboration

Description Collaboration module provides a set of services and tools aimed to

foster cooperation among the ecosystem members in order to create

new business opportunity and facilitate the creation of VME. The

knowledge sharing will be one of the important targets of this

module: it will be achieved providing shared document

environments. Also some collaboration tools will be based on

collaborative software developed in COIN project (e.g. collaborative

project management, collaborative production plan).

Functionalities /

services

Knowledge sharing environment

Tools for collaborative tasks execution

Dependencies The collaboration module uses the functionalities provided by

communication module

User This module will be used by any ecosystem member


Table 21 - Collaboration module




3.2 Maturity assessment and Change Management Wizard

Enterprises that are part of a Manufacturing Service Ecosystem and that want to fully leverage

the potential opportunities that the ecosystem could provide in the mid-long term, should be

supported in finding their way toward an effective servitization of their value-delivery model

and toward a fruitful collaboration with other members of the ecosystem. Enterprises should

thus be helped in assessing their maturity level with respect to such two objectives and should

be guided through a concrete roadmap toward the desired to-be with the support of the right

technological and methodological tools (i.e. tools developed in MSEE or other).

The Innovation Ecosystem Platform, in the second cycle of the project, will integrate a set of

components to support such requirements. The technological components will reflect the

methodologies and the models defined in WP24 in order to provide concrete means to guide

the enterprises through change management processes that may vary from simple and short-

term modifications of the technological infrastructures, to complex and long-term switch of

the business model. In particular these methodology defines the specific questionnaire,

indicators and indexes to evaluate the maturity of the enterprise and in order to guide them in

the change management process.

The change management approach, as stated in [17] is based on four activities:

1) map the processes that a company and its ecosystem are currently running, with

specific concern to innovation processes and capability to manage correctly services

along their lifecycle.

2) identify the target objective of the organization.

3) guide along the path (direction identified by the definition of the target objective),

identifying weak processes to be improved and

4) guide along the path selecting appropriate tools and methods to be applied to improve

the identified weak processes.

In order to support this activities the Maturity assessment and Change Management Wizard

provides some functionalies contained in the following modules




Figure 16- Maturity assessment and Change Management Wizard modules

Name Online Questionnaire

Description This component supports the initial phase of the assessment process

collecting the information from the ecosystem members about their

level of involvement in the ecosystem and about their servitization

level. The online questionnaire based on the one defined in [17] will

be composed by different sections with multiple choice questions.

Functionalities /

services

creation and management of online surveys with open and

closed questions

answering questionnaires

save answers to complete questionnaire a in different session

Dependencies

User The Ecosystem Manager defines, creates and manages online

questionnaires to be used by ecosystem members.

MSEE Project Cycle Second

Table 22 - Online Questionnaire

Name Maturity Level Assessment

Description This component takes as input the data produced by the online

questionnaire calculating specific indicators and showing results in a

graphical way: in order to better understand the meaning of the

maturity assessment indexes they will be presented as graphs called

“Maturity Maps” (see Figure 17)




Functionalities /

services

definition of the maturity level of the enterprise through

“maturity indexes” calculated on the questionnaire result

generation of graphical representation, (e.g maturity maps)

of the maturity indexes

Dependencies This component depends on the data provided by the Online

Questionnaire component

User The Maturity Level Assessment component is used by any

ecosystem member to evaluate its maturity level in the ecosystem

and in the servitization process.


Table 23 - Maturity level assessment

Figure 17 - Example of Maturity Map

The Figure 17 is an example of Maturity Map defined in D24.1[17]:

“Arrow A highlights that the company will need an improvement in Service Lifecycle

Management. This will later allow to understand the right change direction to adopt, e.g.

following suggestions provided by MSEE Frameworks and Tools, e.g. some useful tools come

from WP14 of MSEE project. Arrow C highlights that the company will need an improvement

in the processes related with the capability of collaborating in a network, thus enabling its

entering in an ecosystem. Arrow B represents a direction that need improvement on processes

of both the type previously mentioned. This will then point to a more articulate change.”

More details about the different Maturity Maps and Indicators can be find in [17].




Name Roadmap Definition

Description On the basis of the maturity level (as is) and of the desired to be, this

component creates a roadmap for the enterprise in order to be guided

through the change management process. A wizard will be able to

guide the user to identify the critical Process Areas that are presently

the weakest and could be improved. PAs with lower maturity level

will be highlighted. The user then decide which processed she/he is

willing to improve. This component will provide actions to be

enacted, decisions to be taken, methodologies to be adopted and

tools to be used. In particular the it will suggest which MSEE tools

should be used to perform the changes she/he needs to reach the

situation declared through the position on the maturity maps.

Functionalities /

services

definition of the desired to-be status, in terms of servitization

level and level of involvement in the ecosystem

creation of a roadmap to guide the enterprise from the

current maturity level to the target one

identification of actions, tools and means to support the

change management process

Dependencies This component depends on the Maturity Level Assessment

component which provides the initial status of the enterprise.

User The Roadmap Definition component is used by any ecosystem

member who needs guidelines to improve its maturity level in the

MSE.


Table 24 - Roadmap definition




3.3 Ideation Process Management System

The Ideation Process Management System is a component devoted to identify, select and

improve, in an iterative manner, the ideas that stimulate the servitization cycle. For this reason

the Ideation Process Management System can be used by different ecosystem actors in every

phase of the servitization process: at the beginning, to produce ideas for new product/services,

during their development, contributing to refine needs and requirements, but also at the

operative phase in the evaluation of the results achieved. The Ideation Process Management

System is based on the concept of “ideas”: an idea can be a solution, request or proposal about

a product, service or process innovation. An idea can be described by a title and a textual or

graphical description. Therefore an idea can be classified and associate with the following

concepts:

Campaign – an idea can be triggered by idea campaign or context and incentives that

come with;

Comment – users can comment ideas proposed by others. An idea can have one or

more comments;

Vote – users can vote ideas;

Rating – votes and comments of an idea contributes to the calculation of the rate of an

idea. Ideas with best rating are candidates for acceptance and realization;

Revision – ideas can be reviewed by a specific review team or group of experts with

knowledge in the field;

Idea State – an idea can be related to a state that represents the position of the idea in

the workflow of the idea management process. The state of an idea can be managed by

a decision maker or changed by an event or trigger. Some possible states of an idea

can be: DRAFT for a new end incomplete idea, UNDER REVIEW for an idea well

defined that has to be reviewed by reviewers under some aspects like financial or

technical aspects, and ACCEPTED or REFUSED.

Tag and Category – an idea can be associate with some tags or categories that helps

users to classify and search ideas,

Attachment – an idea can be related to some attachments that contain details for

better idea description. An attachment can be a document, an image or a link related to

an idea.

Interlinking – some ideas can be interlinked because of some relationship like

opposite ideas, similar ideas or extending ideas.

The Ideation Process Management System is composed by three modules: the Ideation

Process Collaboration that provides the web GUI to access the functionalities of the ideation

process; the Ideation Process Analysis that provides a series of reports, supports the Decision

Maker in the final selection of the more valuable proposals. These two modules are related

with the Ideation Process repository that contains all the information produced during the

ideation process.




Ideation Process Repository

Ideation Process Collaboration SystemIdeation Process Analysis System

Ideation Process Sharing

Feedback Management Service WP33

Figure 18 - Ideation Process Management System modules

Name Ideation Process Repository

Description The Ideation Process Repository contains the data produced by

Ideation Process Management System and it provides the

functionalities to access them exposing a set of API to the other

modules.

Functionalities /

services

Store, get, delete and modify data in the Ideation Process

Repository

Dependencies The Ideation Process Analysis and Ideation Process Collaboration

System modules access to the Ideation Process Repository.

User Ideation Process Repository is not used directly by users but by the

above-mentioned modules through specific API.


Table 25 - Ideation Process Repository

Name Ideation Process Collaboration




Description The Ideation Process Collaboration is the core module of the whole

system: it provides to the users, through a web UI, all the

functionalities needed in the ideation process, such as creation and

managing of ideas and campaign, comment, review and voting.

Functionalities /

services Create and Manage Campaign – campaign are created by

an Idea Campaign Organizer to stimulate employees or

clients to submit ideas about a theme.

Create and Manage Idea – Customers and Ecosystem

Members can create ideas in response of a campaign or to an

on-going theme for which the company always requires

ideas.

Search Ideas – with this function it is possible to search

ideas by its name, description or other properties and to view

ideas filtered by some aspects, like state or category.

Vote Idea – this function allows to vote ideas. Users can

vote ideas during the Idea Improvement phase. Votes and

comments of ideas contribute to the calculation of the idea

ranking. Ideas with highest ranking are candidates for

acceptance and production.

Comment Idea – this function allows to comment ideas

during the Idea Improvement process.

Attach file to Idea – an idea can be better explained with the

help of an image or a file related to some specific domain

application. This function permits to attach files to ideas, like

image files, spreadsheets or presentations.

Assign State to Idea – assigning a state to the idea it is

possible to trace the current position of the idea in the idea

management process. The first state of an idea can be Draft,

then Under Review, Accepted, Rejected or Implemented.

Tag Idea - this function permits to tag ideas to better

describe it and allows it to be found again by browsing or

searching.

Review Idea -. This function enables reviewers and domain

experts to refine ideas adding more authoritative and

structured information like financial reviews or technical




review.

Interlink Ideas - this function allows users to add links

between ideas during the selection phase to point out aspects

among ideas relationships like similarity, opposite and

extension. It is then possible to link two ideas as Similar

Ideas, Opposite Ideas or Extending Ideas.

Dependencies This module accesses to Ideation Process Repository to store and

retrieve the information related to the ideation process.

User All the Ecosystem Members can use the Ideation Process

Collaboration System: in particular Customer, Campaign Organizer,

Moderator, Reviewer and Decision Maker.


Table 26 - Ideation Process Collaboration

Name Ideation Process Sharing

Description This module allows to share and publish the ideas, created in the

Idea Management System, outside the ecosystem in the public

internet. In particular the module, using the functionalities provided

by the utility service “Feedback management” [18] will be able to

publish the ideas in different social networks, monitoring the

comments and feedbacks from the users. The information collected

will be presented by the Ideation Process Analysis module

Functionalities /

services

Publish ideas in social networks

Gather information about number of visitors, feedbacks and

comments about published ideas

Dependencies This module communicates with Ideation Process Collaboration,

that provides the ideas to be shared, and with the Ideation Process

Analysis module that shows the feedback coming from the social

network. It also uses the primitives exposed by Feedback

management service.

User The functionalities of this module will be used by the Campaign

Organizer and Decision Maker.





Name Ideation Process Analysis

Description All the campaigns and the ideas produced and the relative

information and attributes can be visualised using a set of predefined

reports (e.g. statistics, charts etc.) provided by the Ideation Process

Analysis module. This module will help the Decision Maker to

select the more valuable ideas taking in account different parameters

(e.g. number of votes, typology of the proposers etc.)

Functionalities /

services

Generation of statistics overview about the information

produced in the Ideation Process Management System, such

as average amounts of ideas and comments, number of users

involved, time statistics etc.

Generation of charts and graphical reports about ideas,

contests, reviews and comments;

Dependencies This module accesses to Ideation Process Repository to retrieve the

information related to ideation process for the statistics and report

generation.

User This module will support the Decision Maker in the analysis and

selection of ideas.


Table 27 - Ideation Process Analysis




The following figure shows an activity diagram of a typical ideation process that involves, in

the different tasks, the actors mentioned in the previous section. In particular it is shown that

the ideation process can start from a new campaign created by a Campaign Organizer or

directly from an idea proposed by an Ecosystem Member or a Customer that can enrich its

description in different ways (tagging, voting commenting the idea etc). After that the

Reviewer or Moderator can refine the ideas collected making a selection or adding new

information. Finally the Decision Maker, with support of Reviewer can rank and select the

more interesting ideas that satisfy specific requirements.

Cam

paig

n O

rganiz

er

Cust

om

er/

Eco

syst

em

mem

ber

Revie

wer/

Modera

tor

Deci

sion M

aker/

Revie

wer

Create Idea

Create Campaign

Vote Idea Comment IdeaTag IdeaAttach File

Review Idea Interlink Ideas Assign Category Attach File

Rank Ideas Analyze Ideas

Assign Idea State

Accepted or Rejected

Figure 19 - Idea Management Process Activity Diagram




3.4 Operational/ecosystem-governance process management system

The use cases outlined in the previous sections for the management and execution of

operational and ecosystem-governance processes highlighted some relevant overlapping and

similarities. In particular, all the requirements related to the orchestration, monitoring and

analysis of human-oriented and automatic tasks can be fulfilled by a common set of functional

components. One important difference among business-process related requirements for

operative and ecosystem-governance use cases is related to the source of the process models

that have to be executed. In the case of operational processes, the executable model is the

result of the servitization process and is thus provided by the Generic Service Development

Platform. Such model (that is at TSM-level) is the customization (for the process-engine

specific needs) of a BPMN representation (at BSM-TIM level) originally developed through

the SLMToolbox (definitions about BSM-TIM-TSM can be found in [1]). In the case of

ecosystem-governance processes, the modelling and the development of the

processes/workflows is done directly by means of tools (Process Editor) that are part of the

Innovation Ecosystem Platform. Another characteristic that distinguishes the operational

processes from the ecosystem governance ones is that the first ones are more related with

activities that involves external components and systems (e.g. enterprise systems or

applications) the second ones involved essentially the users, the processes and the information

inside the IEP (e.g. asset management).

Figure 20- Operational/ecosystem-governance process management system modulesFigure 20

shows an overview of the modules composing the Operational/ecosystem-governance process

management system that will be described in the following tables.




Operational/ecosystem-governance process management system

Human-oriented tasks GUI

Process Engine

Process Log Repository

Process Editor

SLM Toolbox

Enterprise Service Bus

Process Monitor

Business Intelligence tools

Open Internet services Individual Enterprise services

Delivery Platform

Ecosystem services

Ecosystem Front-end

Figure 20- Operational/ecosystem-governance process management system modules

As stated above the operational/ecosystem-governance process management system has to be

able to interact with external services, to perform automatic activities, through web or rest

services, but also external applications that are involved in the process should have the

possibility to communicate with it (e.g. to notify the completion of manual task). The

following picture shows this type of interaction:




Process Engine Delivery Platform (WP43)

WEB / mobile Application

Web/rest Service

response:=execute()

Generic service call related to the

execution of an automatic task

External application calls process engine API

to perform an activity (.e.g task completion notification)

response:=execute(action, process, task)

Call of the specific service instance

response:=invoke(taskService)

Figure 21 - Process Engine interaction with external components

On one side the process engine, a core module described below, is able to invoke automatic

services through the Delivery Platform that then calls the concrete instance of the service

(rest or web service); on the other side the process engine exposed a set of API that allow

external application to interact with the business process. The basic set of these interfaces will

include the following functionalities:

API functionality Description

getProcessDefinitions() Returns all the available process

definitions

createProcessInstance(processDefinition) Creates and registers, "a new process

instance" on the basis of available

definitions.

deleteProcessInstance(processID)

Process deletion

getProcessInstance(processID)

Return the process Instance based on ID.

getAllTasks(usedID)

Return all tasks assigned to a user

getTaskDataType(taskID) Return the data type required for the task

completion (e.g. set of attributes)

performTask(taskId, taskData) Performs an operation (e.g. claim,

unclaim, assign or complete) on a task.

http://bluesoft-rnd.github.com/aperte-workflow-core/webservice-doc/org/aperteworkflow/service/AperteWorkflowProcessService.html#createProcessInstance%28pl.net.bluesoft.rnd.processtool.model.config.ProcessDefinitionConfig,%20java.lang.String,%20pl.net.bluesoft.rnd.processtool.model.UserData,%20java.lang.String,%20java.lang.String,%20java.lang.String,%20java.lang.String%29

http://bluesoft-rnd.github.com/aperte-workflow-core/webservice-doc/org/aperteworkflow/service/AperteWorkflowDataService.html#deleteProcessInstance%28java.lang.String%29

http://bluesoft-rnd.github.com/aperte-workflow-core/webservice-doc/org/aperteworkflow/service/AperteWorkflowDataService.html#getProcessInstance%28long%29




For the "complete" operation additional

variables (taskData) may be necessary.

Table 28 - Process Engine API

Name Process Engine

Description The process engine is responsible for instantiating and executing

process models. Some activities are automatic (e.g. sending an email

or invoking a web service), other activities are manual and they

needs human actors to be executed (e.g forms to be completed with

specific information). The process engine manages and persists the

state of the process instances and of its tasks during their entire

lifecycle.

Functionalities /

services

Importing and deploy of executable process models

Orchestration of human-oriented and automatic tasks

Management of multiple process instances

Exposing of API to interact with the process workflow

Dependencies The process engine is the runtime environment for both operational

and ecosystem-governance processes/workflows. Their execution

requires the previous import of the executable model from the

Generic Service Development Platform (for operational processes)

or from the Process Editor (for ecosystem-governance processes)

User The process engine is not directly used by users but offers its

functionalities through API to the other process management system

modules and external applications.


Table 29 - Process Engine




Name Process Editor

Description Ecosystem-governance processes, unlike operational ones, are not

specified and implemented in the servitization process. They need a

dedicated and light-weight set of tools in order to be rapidly

described and implemented respectively by Ecosystem Managers

and IT Service Managers. The Process Editor module is responsible

for supporting such actors in any activity required to transform an

high-level definition of a business model to the correspondent

executable version for the chosen Process Engine module.

Functionalities /

services

Modelling of business processes through BPMN 2.0

graphical notation

Detailed design of the process in terms of low-level

properties of the activities in order to make it executable in

the Process Engine module

Graphical design of web-forms for human tasks to be

performed inside IEP

Dependencies The generation of the executable process model (i.e. the specific

format of the output of this module) must be compliant to the

formats accepted by the Process Engine module.

The language used for the high-level description of the ecosystem-

governance process model must be aligned to the ones adopted in

SP1 and used in the SLMToolbox (i.e. BPMN 2.0).

User The Ecosystem Manager uses this module to describe at a high-level

the process to be implemented

The IT Service Manager defines the technical details of each activity

in order to make the process executable.


Table 30 - Process Editor

Name Process Monitor

Description Both operational and ecosystem-governance processes have to be

monitored in their execution to verify the different tasks performed

assuring a correct error management. The Process Monitor module

provides functionalities to directly monitor the different instances of

processes through a dedicated graphical console that allows the




users to analyse the whole execution of them. The user will be able

to view the status of the processes (started, idle, running, completed

etc.), of the single tasks, information about the users involved in the

manual tasks and to manage exceptions and errors that can occur.

Functionalities /

services

Status Monitoring for process instances and tasks

Monitoring of task assignments and responsible users

Error and exception handling

Dependencies The information reported by the Process Monitor is based on the

data produced by the Process Engine and stored in the Process log

Repository

User The Ecosystem Manager and VME Managers use this module to

monitor the status of processes (respectively for ecosystem-

governance and operational processes) and tasks and to manage

error and exception. The IT Service Manager can also use this

module in order to manage the possible technical problems reported

by the web console.


Table 31 - Process Monitor

Name Process Log Repository

Description The Process Log Repository provides the functionalities to access to

the logging data produced by the Process Engine during the

operational and ecosystem-governance processes execution. The

logs are information at different levels: status of tasks, process

instances, IT services called in the process executions, users

involved in the task, error reports etc.

Functionalities /

services

Store, get, delete and modify data in the Process Log

Repository

Dependencies The information managed by the Process Log Repository are

produced by the Process Engine and used by the Process Monitor

User The Process Log Repository is not used directly by users but by the

above-mentioned modules through specific API.


Table 32 - Process Log Repository




Name Human-oriented tasks GUI

Description Ecosystem-governance processes can be composed by automatic or

human-oriented tasks. In order to perform these manual activities

the users will use a specific graphical interface (e.g forms)

integrated in the Innovation Ecosystem Platform frontend

component. The Human-oriented task GUI consists in a dynamic

web user interface to be filled by the user with the information

needed to complete the specific tasks.

Functionalities /

services

Worklist: list of tasks that the user is allowed or required to

perform.

Web forms and graphical elements to support users in

manual tasks

Dependencies The Process Engine activates this module for the tasks that require

direct actions by the users to be completed. Moreover this module

generates UI integrated with the Ecosystem Frontend.

User This module can be used by a generic Ecosystem Member involved

in a manual task of operational or ecosystem-governance processes


Table 33 - Human-oriented tasks GUI

Name Enterprise Service Bus

Description The Enterprise Service Bus is the module that allows the

communication and interaction among services and application

involved in the operational or ecosystem-governance processes

orchestrated by the Process Engine. It will able to integrate

ecosystem services, published in the Delivery Platform with

enterprise services and open internet services external to MSEE.

Services based on different technologies and communication

protocols can interact through the Enterprise Service Bus that

translates messages from the consumer to the provider of the

service: in order to perform this translation the Enterprise Service

Bus uses some adapters for the different languages/technologies to

be supported (Java, SOAP, BPEL etc).

Functionalities /

services

Message-processing transformation and routing

Validation against schemas for sending and receiving

messages




Support for synchronous and asynchronous transport

protocols, service mapping

Adapters for supporting integration with different

technologies and legacy systems,

Dependencies This module depends directly from the Process Engine that

orchestrates the whole process demanding the invocation of the

services to the ESB

User The Enterprise Service Bus is not used directly by users but by the

Process Engine through specific API.


Table 34 - Enterprise Service Bus

Name Business Intelligence Tools

Description The Business Intelligence Tools perform advanced analysis on the

process log data and on other data sources that may be of interest:

while the Process Monitor reports information about processes and

tasks status and errors, the Business Intelligence Tools allow to

define and monitor high level Key Performance Indicators and SLA

based on specific business objectives related to the ecosystem and

the operational processes

Functionalities /

services

Define and monitor Key Performance Indicators and SLA

Graphical reports of the analysis

Dependencies The Business Intelligence tools perform their analysis on the data

provided by Process Log Repository

User The Ecosystem Manager uses this module to define and monitor

Key Performance Indicators

The IT Service Manager uses this module to define and monitor

technical SLA


Table 35 - Business Intelligence Tools




3.5 Assets Marketplace and tangible/intangible assets repository

This section describes in detail the two functional blocks the Assets Marketplace and

Tangible/Intangible assets repository introduced at the beginning of this chapter. They are

described together because their coupling allows the complete support of the complex use

cases UC-GP-XX in the context of the Manufacturing Service Ecosystem. It is to be noticed

that tangible/intangible assets will be managed by the IEP as services published through the

USDL [13] [14] format (or an “extended” version of USDL, customized for the needs of the

manufacturing industry). Such services are published by ecosystem members after that the

proper pre-processing procedures (defined in WP22 and WP23) have been performed (e.g.

identification and prioritization of the assets, extraction of their relevant information from the

proper data-sources, transformation of the information into the USDL format, integration of

the missing data into the USDL description of the service, …): some of these activities will be

supported by some modules of this component (such as the USDL modelling that will be

performed by the Assets Editor).

The following figure represents the main functional components (and their dependencies) that

are part of the process which leads to the publication of tangible/intangible assets as a service

through the Marketplace, starting from the output of the aforementioned pre-processing

procedures.

Asset Marketplace

USDL Repository Access Restriction ServiceUSDL Editor

Consumer Marketplace

FIWARE Marketplace

Figure 22 – Assets Marketplace and tangible/intangible assets repository modules




Name Assets Marketplace

Description The Assets Marketplace component has the aim of providing a point

of contact among offers and demands of services built upon

tangible/intangible assets. Functionalities provided by the Assets

Marketplace are meant to allow the dynamic and flexible creation of

ad-hoc VMEs to respond to business opportunities through the

search and identification of the right capabilities (i.e. tangible and

intangible assets aaS) available in the MSE. The Assets Marketplace

is related with the Consumer Marketplace developed in WP32 [20]:

the first one is based on the assets available in the ecosystem, the

second one can search for offering and assets, in a federated way, on

different ecosystems. These two components will be based both on

the FI-WARE marketplace specifications [21].It is to be noticed that

the functionalities of the Assets Marketplace have to be accessible

both to human users and to automatic systems through web

applications and through APIs respectively.

Functionalities /

services

management of marketplace participants (providers,

consumers, …)

management of offerings (creation, modification, deletion)

searching & listing of services that match specific criteria

(e.g. price range, service level, technical characteristics,

functionality, …)

compare services along multiple attributes (e.g. price, service

level, …)

management of feedback and ratings about services

Dependencies The Assets Marketplace component depends primarily on the Assets

Repository, which is the logical place where the concrete

descriptions of the published services are maintained.

User On one hand ecosystem members, acting as providers, can publish

their services and manage offers by specifying supplementary

information like their price model and their category; on the other

hand, acting as consumers, they can search, compare and rate

services according to their necessities and to the requirements

coming from the market.


Table 36 – Assets Marketplace




Name Assets Repository

Description The Assets Repository component is responsible for maintaining the

USDL description of services that are based on tangible and

intangible assets.

The repository will contain the tangible and intangible asset “as a

service”: the Linked USDL [36] files stored in the repository

represent the service descriptions of the specific assets connected to

them, following the approach of “linked data”. The specific models

and ontologies developed to represent t/i assets “as a service” have

been developed in WP22 and WP33.

It is to be noticed that this component will support distributed

architectures by allowing service descriptions maintained in a

specific repository to refer to descriptions maintained by other

repositories.

Its functionalities consist of simple operations that allow the

creation, update, retrieval and deletion of service descriptions.

Additional functionalities are related to the listing of descriptions

accessible to the user and the searching/querying of the descriptions

with respect to their properties.

Functionalities /

services

Support for RDF format

Create new service description instances

Read service descriptions or parts of service descriptions.

Update parts of service descriptions

Delete service descriptions

List all the service descriptions accessible to the user

Filter specific attributes of the service description with

respect to the access-level (individual enterprise, ecosystem,

open internet)

Query/Search service descriptions

Dependencies This component depends on the Access Restriction Service

component for the management of the rules for filtering the service

description attributes with respect to the access-level.

User The Assets Repository is indirectly used by ecosystem members,

acting as service consumers, through the Assets Marketplace to

search for competencies and capabilities inside the ecosystem.

Ecosystem members act also as service providers when they create

new service descriptions to be managed on the Assets Repository.





Table 37 - Assets Repository

Name Assets Editor

Description This component has the aim of allowing service providers to

describe their t/a assets aaS through rdf format and the linked USDL

formalism.

Functionalities /

services

searching and retrieval of service descriptions from in the

Assets Repository

editing of service descriptions in RDF format using linked

vocabulary

storing of service descriptions in the Assets Repository

Dependencies This component depends on the Assets Repository for storing and

retrieving USDL descriptions.


Table 38 - Assets Editor

Name Access Restriction Service

Description Information about tangible and intangible assets and about their

characteristics may have different degrees of privacy requirements

and constraints. For example the rate of malfunctions of a certain

machine tool and the real cost of a specific employee (whose

capabilities are to be published as services) are important

information for the enterprise that actually owns such assets, but

they should never be accessed by external actors (e.g. potential

consumers of the service). MSEE defines three architectural levels

for the publication of services: Individual Enterprise, Manufacturing

Service Ecosystem, Open Internet. At the Individual Enterprise level

all the information are available for the members of the single

enterprise. At the Ecosystem level, members of the ecosystem can

access a sub-set of the information available at Individual Enterprise

level (i.e. sensible and privacy-constrained data are filtered). Finally

at the Open Internet level (public level) further information are

obscured to actors that are not formally part of the MSE.

The Access Restriction Service component has to provide the means

to manage and enforce the rules for accessing the asset-related




information in the USDL description.

Functionalities /

services

fine-grained management of access rules to attributes

reported in the USDL description

enforcement of the access restriction rules

Dependencies No dependency is currently considered

User This component is used by the ecosystem member that, acting as a

service provider, wants to restrict the access to certain information

related to the tangible/intangible assets.


Table 39 - Access Restriction Service

The following table resumes the list of the Innovation Ecosystem Platform modules showing

the expected deadline for their implementation: as said in the previous sections some modules

will be provided for the first MSEE cycle (M12), others will be implemented in the second

cycle (M24) after requirements refinement and new contribution from relative work packages.

Innovation Ecosystem Platform Modules First

Cycle

(M12)

Second

Cycle

(M24)

Ecosystem Frontend X

Maturity assessment and Change Management Wizard

Online Questionnaire X

Maturity Level Assessment X

Roadmap Definition X

Ideation Process Management System

Ideation Process Collaboration X

Ideation Process Analysis X

Ideation Process Repository X


Process Engine X

Process Editor X

Process Monitor X

Process Log Repository X

Human-oriented tasks GUI X

Enterprise Service Bus X




Business Intelligence tools X

Assets Marketplace and tangible/intangible assets repository

Assets Marketplace X

Assets Repository X

Assets Editor X

Access Restriction Service X

Communication and Collaboration services

Communication X

Collaboration X

Table 40 - IEP modules in the MSEE cycles




4 Technological components

In this section we will describe some technological products that could be used to cover part

of the functional requirements presented in the previous chapters. The list includes both

products considered in the first cycle and products evaluated/identified for the second cycle of

the project.

4.1 Ecosystem Front-end

4.1.1 Liferay

The Liferay Portal [22] contains a rich list of features, many of which are made available

through the use of AJAX. This technology allows user to setup a customized homepage by

dragging and dropping the available functionalities (portlets and gadgets). This task can be

easily carried out by any internet user without the need of any specific technical skill. In the

same way, users can customize the Portal look and feel by choosing one the different themes

made available by administrators.

Liferay offers a complete range of functionalities to manage each aspect of the portal, from

simple changes to more complex operations such the addition of a new portlet. Administrative

tasks are managed through an AJAX developed interface which allows to drag and drop the

necessary objects.

The list below shows a summary of the main features offered by Liferay.

Support to the major J2EE Application Server, database and operating systems (about

700 combinations of deployment).

Customization layout through themes.

Services Content Management System (CMS) and Documental based repository

standard JSR 170 (Apache Jackrabbit).

Collaborative Services .

Availability of over 100 portlets.

Availability of AJAX interface.

Multilingual (over 34 languages already available).

Support for SSO by CAS.

Availability development of tools for the main IDE (Eclipse).

Among the available features, DAWLATI will publish the following basic services

offered by Liferay:

Content management (CMS)

Collaboration services: This component provides:

Messaging: through a portlet similar to a mail client, users can manage and exchange

messages with other registered users.

o Address Book: support service to user information to which users can send a

message. The information will be managed through LDAP.

o Forum: system for managing on-line forums. Each discussion group (Forum)

consists of "arguments" (Topic) and each topic from a set of messages

(Thread).




o Shared calendar: tool for managing a shared calendar appointments between a

working group.

o Wiki: portlets for managing content so shared.

Documents sharing

Security: Authentication and Authorization System integrated with LDAP.

4.1.2 Drupal

Drupal [23] is an open source content management system. It is a modular application written

in PHP. It is compatible with different SO like Linux, Windows and Mac OS X and web

servers like Apache or IIS. For data storing it can work with MySql or PostgreSQL database

management systems.

Drupal has a modular design, composed by a core module that provides some basic

functionalities, and others optional models and template that are in continuous development

and provided new functionalities and customization.

The functionalities provided by the core module are:

Creating, modifying and categorization of generic contents,

Content searching,

Inserting comments to content,

Forum capabilities,

Creating and participating to a survey,

Collaborative writing projects,

User and profile management, user accounting and registration,

Communication among users and between users and administrators,

Changing the site template using existing templates or creating new templates,

Creating menus with a multi layer structure,

Internationalization,

RSS feeds,

Granular access control management, configuring detailed permission rules related to

single users or groups,

Site usage statistics.

Drupal extension is done using Modules and Themes.

Modules extends Drupal providing new functionalities, like image galleries, WYSIWYG

editors, mailing list, e-commerce. In the Drupal website it is possible to access to almost

16500 free modules.

Templates can change the default Drupal look-and-feel. They can be created using common

design tools like PHPTemplate and XTemplate. The concept of template allows to separate

user interface programming (HTML and CSS) from logic (PHP). Like in the case of modules

also many themes are provided freely.




4.2 Ideation Process Management System

4.2.1 G2MO Idea Management

Gi2MO IdeaStream [24] is an Open Source web application developed during the research on

Idea Management Systems in the GI2MO project, an initiative of GSI group of the

Universidad Politecnica de Madrid. Ideastream is an Idea Management System build through

a set of modules that customizes the popular CMS Drupal. Ideastream delivers the basic

functionalities of an Idea Management System that are:

Create, rate and comment ideas,

Track idea’s workflow status, like draft, under review, accepted etc,

Organize idea with Idea Contests, Categories, Tags,

Submit Idea Reviews that can be categorized by different criteria and supplied with

rating,

Browse and analyze review statistics,

Customize access permissions to functionalities using different roles like

administrator, manager, moderator, reviewer, inventor.

Figure 23 - G2MO Idea Management

As we can see in Figure# the IdeaStream frontend is composed of some sections:

Main section: where an user can see ideas present in the system, filtered by idea

workflow status, with some details: title, description, author, tags, categories, votes

and comments. A generic user can also vote an idea and add a comment.

Create new Idea Link: this link leads to a page where the user can submit a new idea.

Idea Categories: this section shows idea categories. For each category the user can

see the number of ideas, and, clicking on the category name, the ideas of the selected

category. In this section categories are ranked according to the number of ideas or to

the number of comments.




Top Ideas: this section shows the top ideas ranked according to the number of ideas

or to the number of comments.

Top Inventors: in this sections inventors are ranked. Also here ranking is done

according to the number of ideas created by the inventor, or to the number of

comments if inventor’s ideas.

As mentioned before IdeaStream extends Drupal CMS. In particular the extension is made by

two modules and a theme:

The IdeaStream Module, that is the core part of the application, reconfigures Drupal

creating data necessary for Idea Management,

The IdeaStream Elements Module, that is a supplement module that delivers custom

functionality that extends Drupal basic ones,

IdeaStream Theme, that is a custom theme that reorganize the look & feel of Drupal,

on order to present to the user some custom pages for idea management.

During the GI2MO project the GSI group developed other interesting modules that work

together with the IdeaStream module, acting ad an axtension. These modules are:

IdeaStream Analytics: that delivers a number of analyses and data views that

improve the workflow of a manager or system administrator during their idea

management processes. These views are:

o Summary Statistics: that presents a general overview of all data in the Idea

Management System, like count of posts per each content type: maximal,

minimal and average amounts of comments or reviews per idea; time statistics,

o Charts: that shows timeline statistics for ideas, contests, reviews and

comments; and bar charts with breakdown of posts per each category type.

o Idea, Contest and Review Management: that presents table views allowing to

browse the content submitted by users, view basic statistics and filter this data

based on various criteria

IdeaStream Similarity: that delivers the ability to create and manage idea

relationships in an Idea Management System. This module add functionalities that

help users in duplicate detection, and in defining relationship between ideas, like

opposite ideas, extending ideas or similar ideas. In detail it permits to:

o Select relationship for newly created idea: during the idea creation phase this

module can detect and suggest similar ideas,

o Manage relationship: this functionality allows moderators to browse, add,

delete and change all relationships of an idea, and approve or reject requests

for idea similarity made by users

o Create new ideas that extend existing ones: this functionality allows users to

create ideas that extends an existing idea

o Submit reports of idea similarity: this functionality allows users to submit

reports for existing ideas to link them with other, and these requests can be

approved automatically or by a moderator.

4.2.2 Open ideaL

Open IdeaL [25] is an open source Idea Management System consisting of a web application

based on Drupal.




The system offers the clients community a tool for expressing their views on various issues

and for running conversations around these issues. The tool also allows social change

organizations to collect ideas from a large public, and develop a vivid and engaged

conversation.

The heart of the conversation is usually an idea which the clients wish to see fulfilled by the

organization. These ideas may be, for example, the development of a new product,

enhancements of existing products, changing size or shape of packages, handling of

customers with special needs.

Open ideaL includes tools for community managers which allow them to identify successful

ideas (those with high chance of becoming a popular product), and to transmit them to

professional treatment within the organization. Community members gain points for activity

on the website, and their overall score grows particularly if their ideas become popular, or if

the discussions in which they participate are “hot”. This allows to reward good community

members, and to use them to lead more discussions.

Open IdeaL basic components are:

Idea Creation: for creating an idea with title, description and tagging

Idea Presentation: for presenting an idea

Idea Editing: this function allows idea’s owner to change idea’s information and

administrator to manage ideas for example changing it’s state.

Comments presentation: for showing idea comments made by other users

Idea tagging: for tagging an idea in order to find ideas according to tags

In-Process projects: to take trace of the ideas workflow

Trends and popularity identification

Mail notifications

Voting

Friend scores

Abuse flags: for ideas, comments and users

Bookmarks

Social network sharing

RSS

Blog

Anti-spam protection

The pages for interacting with the Idea Management System are:

Home Page

Registration and login page

Idea creation

Idea presentation , that shows idea details including comments

Category and Tag page

Popular ideas

Recent ideas

In-Process Ideas

Profile page




Search for ideas

Search for members

Project page

Analytics page

Other optional components are:

Selected Ideas: this function allows administrator to select an idea and publish it in the

home page

Community Leaders: this function present, in the home page, the community members

with the highest score

“1 on 1”: this function allows choosing two competing ideas and letting members vote

for them, in a dedicate section in the home page,

Challenge: this function allows the creation of a special page related to a challenge,

for a certain category or tag. In this page community members are called to propose

ideas for that specific category




4.3 Operational/ecosystem-governance process management system

4.3.1 Process Maker

ProcessMaker [26] is an open source business process management (BPM) and workflow

software web application. This application allows organizations to design, automate and

deploy their processes and workflows. ProcessMaker is completely web based and accessed

via any web browser, making it simple to manage and coordinate workflows throughout an

entire organization, including user groups and departments. It can also interact with other

applications and systems such as ERP, business intelligence, CRM and document

management.

This application allows business users and process experts, with no programming experience,

to design and run workflows, automating processes across the systems, including human

resources, finance and operations. With ProcessMaker it is possible to:

Design processes: through a process designer that allows business analysts to design

processes using an intuitive drag-and-drop interface easy to use,

Run processes: through a web based application with profiling rules that allows users

to interact with form-driven processes,

Extract reports from processes and Optimize processes: through a dashboard that

shows to managers KPI reports.

For the design phase ProcessMaker presents these functionalities:

Process Map Designer: that is a graphical tool (depicted in FIGURE) allowing

business analysts to create workflow maps. It is possible to define tasks, to connect

tasks and define routing rules, to edit task properties. This tools offers also version

control and debugging functions.

Dynaform Builder: this functionality allows business analysts to design custom

forms for human tasks. It is possible to add fields, whit a drag-and-drop interface, like

text boxes, check boxes, drop downs, grids, date picker or file upload fields. Forms

can be enhanced by technical users adding css or javascript improving form

appearance and behavior.

Business Rules Engines: this functionality allow business analysts to describe the

logic to determine how a process should flow down one particular path instead of

another in a decision gateway of the business process.

Output Document Builder: this functionality is provided by a document editor that

allows business managers to create electronic receipts, letters, confirmations, invoices,

contracts or any other type of printable document, that can be added to tasks that

automatically generate printable output with auto-filled information.




Figure 24 - Process Maker Cases Inbox

For the process execution phase ProcessMaker offers these functionalities:

Cases Inbox: that is the main interface (depicted in Figure 24) for the end user

interacting with processes. This is an area where users can create new process

instances, track the progress of requests they have initiated or requests that require

their input through. This interface presents an inbox similar to E-Mail inbox, where

users can show new task handling requests. It also allows supervisors to review and

reassign cases.

User management: this functionality allows administrators to create roles, groups and

departments to customize the solution to the organization structure. In this way users

have different privileges according to their roles or groups or departments.

Document Management: this functionality allows users to store and retrieve files that

have been uploaded to ProcessMaker or automatically created by a process. These

files are stored by a complete document management system included in

ProcessMaker that allows to store files but also to manage custom tag clouds, custom

folder paths and version control.

Process Monitoring: this functionality is realized by a dashboard that provides real

time monitoring efficiency and productivity of processes and users executing those

processes. The dashboard is composed of some graphical indicators, called dashlet

(depicted in Figure 25), that can be created by the administrator. Dashlets measure

indicators over a predefined period, that can be Today, Yesterday, ThisWeek,

Previous Week, Previous Month, This Month, This Year, and Previous Year.




Figure 25 - Process Maker Dashlets

4.3.2 Activiti

Activiti [27] is an open-source light-weight workflow and Business Process Management

(BPM) Platform targeted at business people, developers and system admins. It has a java

based BPMN 2 process engine Activiti runs in any Java application, on a server, on a cluster

or in the cloud. Activity started from jBPM engine adding on top of it a set of tools.

Some interesting functionalities related to the BPMN 2 activiti engine are:

Custom activities and event listeners: in activiti it is possible to develop and execute a

piece of custom Java code or a script upon certain events in the diagram. This is useful

when it is necessary to create some custom activities not supported by BPMN

standard. In this way the developers can include technical details to the process

without affecting the diagrams that remains fully readable by a business user.

BPMN shortcuts: for those specific areas where BPMN 2.0 is too verbose, it is

possible to use shortcuts. For example a simple activiti attribute might be introduced

that is equivalent for a more verbose BPMN 2.0 XML section. These extensions can

be translated to valid BPMN XML.

Rest API: activiti provides rest API to access the process engine functionalities. For

example some actions thay can be performed are:

o Get information about process

o Get information about tasks

o Perform task actions (claim, unclaim, assign or complete)

o Identity and user management

Other Activiti main components are described below:

Activiti Explorer

Activiti Explorer is a web application that provides access to the Activiti Engine runtime for

all users of the system. It includes task management, process instance inspection,




management features and viewing reports based on statistical history data. Some

functionalities provided by this modules are:

View task list

Create a new task (unrelated to a process)

Complete a task by submitting data in a task form

Reassign a task to a different user

See which other people are involved in the process related to this task

Create subtasks and assign them to people

Management of the deployments

View deployment resources

Management of the process definitions

Inspect the database tables

View the activiti logs

Reports and statistics for business people

Figure 26 - Activiti Explorer

Activiti Modeler

The Activiti Modeler is an open source version of the KIS BPM [28] process solution. It can

be used to design BPMN 2.0 compliant processes diagram. The process files are stored by the

server in a database model repository. KIS BPM provides a solution to manage Activiti

projects in a web-only environment. You can manage your different Activiti servers and

deployments. In addition, the web modeler palette can be fully customized using a palette

editor. The KIS BPM solution also includes a web form editor.




Activiti Designer

The Activiti Designer is an Eclipse plugin which allows you to model BPMN 2.0 in the IDE-

environment. It also has built-in support for the activiti-specific extentions to allow to use the

full potential of both the processes and the engine. There are various plugability-points to

allow for additional building-blocks to be added to the process on top of the regular BPMN

2.0, tailored for your specific use-cases and business-domain.

Figure 27 - Activiti Designer

4.3.3 Aperte Workflow

Aperte Workflow [29] is an Open Source (GNU LGPL) BPM solution realized putting

together some stable and mature frameworks. The frontend is a web application where users

can design, deploy, run and monitor processes.

Aperte Workflow is composed of these modules:

Integration Module: supporting persistence in accordance to JPA standard and using

OSGi framework for plugin managements,

Basic GUI: that is implemented using Vaadin framework,

BPMN Engine: supporting some BPM implementations like jBPM and Activiti,

Liferay Portlets: that form the user interface for interacting with the processes.

Aperte Modeler: that is a BPMN2.0 editor, for process design and deploy.

The key featurs of this sytem are:

It runs on Liferay, taking advantage of it’s powerful functions,




It supports various BPM process engines implementations like JBPM and Activiti,

It is based on OSGi service platform, taking advantage of its modularity,

It has a relational data model easily extendable,

It presents a rich user interface,

It contains a visual web based process editor,

Supports enterprise integration with an embedded ESB like Mule ESB.

Technologies used from Aperte Workflow are:

Liferay and Vaadin: for the implementation of the user interface,

OSGi framework: for the plugin support,

Hibernate: for data persistence,

JTA: for distribute transaction support,

jBPM and Activiti: as BPM engine implementation.

Signavio Core Components: open source library for business process modeling

The tree principal phases in BPM process systems are modeling, running and monitoring.

In Aperte Workflow modeling is done using the web application Aperte Modeler, shown in

FIGURE. Using the modeler it is possible to draw BPMN2.0 process diagrams, define human

or automatic activities, create user interfaces for human activities, associate services to

automatic activities and then deploy service bundles to the OSGi framework.

Process running is performed by the BPM implementation engine, and human tasks of

running processes are accessed through liferay portlets.

These portlets are:

New Processes: that allows users to start new process that are compatible with their

profile,

Task Queues: that shows to users their new tasks, recent tasks and other custom

queues like subscriptions requests,

Search: that allows users to search for processes instances,

Task main portlet: that shows human tasks forms that users have to fill.

Process Monitoring is performed by tree functions in the liferay control panel that are:

Aperte Workflow plugin manager: that shows installed plugins in the OSGi

framework,

Aperte Workflow Process Definitions: that show all deployed processes, and

enable/disable processes,

Aperte Workflow Process Instances: that allows administrators to track running and

terminated process instances and their status. For each process instance it is also

possible to show a process map that represents the process end tracks the current

status, like in Figure 29.




Figure 28 - Aperte Modeler

Figure 29 - Aperte process map

4.3.4 Bonita Open Solution

Bonita Open Solution [30] is an open source BPM and workflow suite. The application is

composed of three major components:

Bonita Studio: that allows users to graphically design business processes in BPMN2.0

standard notation. The studio is an Eclipse RCP application, that contains the core of

Eclipse, some other Eclipse projects and Bonita specific plugins. It exports process to

the Bonita Execution Engine. With this tool it is possible also to connect processes to

external information systems like ERP, ECO anda databases. The studio includes a




graphical form designer in order to create forms for human tasks. These forms are

showed to users in a web context via the Bonita User Experience application. The

studio makes Bonita Open Solution very integrable because it provides some import

and exprort functionalities to the principal BPM formats. Indeed it provide import

from BAR (Bonita Archive), but also from BPMN2.0, XPDL and jBPM3, and export

to BAR and BPMN2.0

Bonita User Experience: that is a web portal that provides user interface for

interaction with process. It has an interface similar to a webmail, with a area in which

the user can see new tasks to handle (inbox), favorite tasks, my tasks. This application

therefore allows administrator to manage the process, handling processes, cases,

categories, users. It includes a report area that shows KPI information. The web

application is based on GWT, and is very modular. It supports some reporting systems

like BIRT and JasperReports. Human task forms are created in the Bonita Studio and

exported as xml file, these files are rendered in the Bonita User Experience using

GWT.

Bonita Execution Engine: is a Java API that allows to interact programmatically

with processes.

Figure 30 - Bonita open solution

As a BPM framework, the Bonita Open Solution presents three major functionalities,

modeling, execution and monitoring, and for each of them presents some features:

Modeling: this functionality is provided by the Bonita Studio, that allows user to model

processed in a standard BPMN2.0 notation. The modeling can be done in a collaborative

way, sharing model between business analysts, stakeholders and developers. The tool

supports the versioning of processes, that allows to save and manage different versions of

a process. It supports also user profiling, in order to expose to users only those features

related to their profile’s role. As mentioned before users can import model from external

tools describer in some languages, and export models. It is also available a function that

allows to simulate process execution, tracking parameters like cost, duration and resource

consumption. After a process I modeled, developers can create forms for human tasks and




link automatic tasks to many built-in connectors provided by the studio they also can

create custom connectors helped by a connector development wizard. Finally processes

are deployed to the Bonita Execution Engine.

Execution: the execution functionality is handled by the Execution Engine and provided

to the users through the Bonita User Experience web application. Like mentioned before

this application offers an intuitive user experience with “inbox” interface. Users log in

applications and see in the in box new tasks they have to handle according to their profile.

The application provides also a function that allows to delegate tasks to other users when

the task actor is unavailable. The User Experience has a multilingual support that includes

some default languages, that can be increased through the Babili community translation

tool.

Monitoring: this functionality is provided to the administrators by the Bonito User

Experience application, in order to track process instances and monitor some indicators. It

is available an advanced dashboard that can be customized, showing statistics and

reporting. It is also possible to define and monitor some KPIs. Administrators can also

manage the process lifecycle, enabling, disabling or archiving processes. they also can

manage users, roles and groups. They also can manage active tasks suspending or

resuming it.

4.3.5 Spagic

Spagic open source solution [31] is the solution used to meet both ESB/BPM middleware

requirements and governance needs such as monitoring services and tools for development

and deploy.

Spagic offers a Universal Middleware with an innovative approach to governance and to

highly modular and configurable SOA solutions around a kernel that is based on OSGi (Open

Service Gateway initiative) model. Spagic, thanks to OSGi modality, enables to produce

solutions that are extensible and truly adaptable to different application domains, providing

the following features:

platform independence

code reusability for different purposes and in different containers (e.g. J2EE, TP, ESB,

BPM)

optimum management of heterogeneous components life-cycle, both of business and

infrastructure nature

configuration and activation of single modules in order to get the most suitable

solution for the specific project context.




Figure 31 - Spagic configurable and activable modules

Spagic provides full support to the governance of SOA projects: tools for modeling, service

definition, form creation for user activities, deploy control, connectors, BPM (Business

Process Management) engines, infrastructure services and containers and monitoring

environment.

The following figure depicts the different Spagic components.

Figure 32 - Spagic components

Spagic Service Manager is a dynamic and adaptable Universal Middleware solution. The

OSGi model modularity features of such solution assure a wide adaptability in different




contexts, such as: Enterprise Middleware, Lite Middleware, installation of OSGi container in

previously existent applications or in specific systems (mobile, custom hardware etc). The

OSGi R4 framework, upon which Spagic is based, is Eclipse Equinox

(http://www.eclipse.org/equinox/).

Spagic Service Manager components are:

Connector: for cooperating with external services through HTTP, SOAP, REST,

TCP/IP, JDBC, SAP, JMS, Mail. During the preliminary analysis activity before the

beginning of the project, the necessary connectors will be individuated and in case

new special connectors will be defined to be developed from scratch for the peculiar

context.

Middleware bundles: it includes infrastructure services such as

o MQ, for asynchronously managing of messaging through queues. Apache

ActiveMQ is set by default, but it is still possible to use other JMS provides

such as the ones in Jboss Application Server.

o BPM, for implementing a workflow process (JBoss JBPM) or BPEL (Apache

ODE) with both manual and automatic tasks. Interaction with processes can

happen both through a web service like a work-list and through calls from

already existing applications (API or shared form execution)

o Role Engine BRMS, through Jboss Drools open source solution

o Registry, for registering services. Spagic relies on the Eclipse Equinox registry

inside the OSGi framework. However it is possible to rely on other standard

solution such as UDDI (Apache JUDDI)

Service Bundles: for managing infrastructure services such as:

o XSL/XSLT transcoding,

o Scripting, through Groovy open source solution,

o Batch scheduler, through Quartz open source solution.

Spagic Studio, based on Eclipse IDE, provides tools for design, development and deploy.

Figure 33 - Spagic Studio based on Eclipse IDE

The Spagic Studio main functions are:

Service Designer for visual definition of services and publication through connectors

BPMN process designer as an extension of open source Eclipse plugin for BPMN.

http://www.eclipse.org/equinox/




XML/XSLT support

XML Schema support

WSDL Editor

XML Message Editor with the possibility to generate file for Scribus: one open source

editor for PDF Forms.

Deploy management

Support to Java development and Groovy script.

Integration with SVN for version control

Figure 34 - Spagic web-based monitor

Spagic Monitor provides services for monitoring and managing the life-cycle of single

module described in the application architecture.

In particular, through Spagic Monitor, it is possible to stop, pause and re-start a middleware

service or process. In short, main functions are:

• monitoring of single services

• monitoring by processes

• monitoring of OSGi platform

• search by messages

• search by variable or relevant values

• managing of life-cycle

• logging.

All information is stored into Spagic MetaDB, that defines the data schemas described in the

application architecture, complying with Eclipse EMF standard and implemented by Eclipse

STP IM project, which Engineering is contributor of.




4.3.6 Petals ESB

Petals ESB [32] is an open source Enterprise Service Bus develop by the OW2 Consortium. It

is implemented in java language and based on JBI (JSR 208) specification. It supports some

standards like BPEL and SCA, and supports EDA capabilities. As an enterprise service bus it

offers many connectors and processing components or services. Some connectors are File

system connectors, FTP or SFPT, JMS, HTTP, mailing (SMTP/POP/IMAP) database

connectors (JDBC or SQL). Some services are BPEL engine, XSLT transformation, RMI,

Java scripting, CSV transformation and KPI notification. A key feature of Petals is its

distributed, in the sense that a single bus can be constituted by several Petals servers.

Key features of Petals ESB are:

it is distributed: as said before an ESB build with Petals can be composed of some

server instances that communicate with each other over the network;

it grantee the message delivery: if a message is sent to a server that in not available,

for example is off-line, the message is stored pr sent to an equivalent service;

it allows message routing: message routes are decided runtime according to some

rules;

it is robust: in case of incident the platform can restore its state and resend not

delivered messages;

it allows monitoring: it is possible to take trace of content and properties of messages

that transit in the bus;

it is extensible: because of it is component based, therefore it is possible to create new

components to extend or modify the platform

it is completed by several tools, for development, governance and monitoring of the

processes.

the major tools that complete Petals ESB and that enhances its potentiality, are:

Petals Studio: it is a graphical editor based on Eclipse IDE, that allows to create

processes like BPEL and SCA improving productivity and accelerating Petals ESB

configuration through automation wizards.

Petals Master: that extends the capabilities of the Petals ESB allowing the

governance of services, like indexing and documenting services.

Petals View: that is a web application allowing to monitor data exchanges between

services deployed by Petals ESB. Petals View is able to generate pertinent meta-data

(KPIs) to drive management reporting that can be interpreted easily by business

stakeholders.




Figure 35 - Petals ESB




4.3.7 Mule ESB

Mule ESB [33] is an open source Enterprise Service Bus framework. As a ESB it provides

interactions between heterogeneous systems and services enabling developers to easily build

high-performance, multi-protocol interactions between these systems. It presents a flexible

and architecture, because it can be used as a stand-alone application, like an operating system

daemon, or within an application server. It provides many functionalities for connecting

different systems:

It provides many transport connectors: like Email, FTP, HTTP, TCP, SOAP and

others,

data transformation services: XSLT, XQuery

it handles many data formats, like Atom, CSV, HTML, XML, JSON and Java Objects,

it provides cloud connectors to interact with Amazon, Twitter, Google, Facebook

Whois,

it is compatible to soma application servers like Tomcat, Jboss, Geronimo, Jetty and

Websphere,

it is compatible to many OS like Linux, Windows, Solaris,Mac OS,

it can interact with many services types and standards like REST, WSDL, WS-

Security

it can manage processes like Bpel or jBPM.

Figure 36 - Mule ESB

As represented in FIGURE Mule ESB allows system integrators to easily interconnect many

information systems, like proprietary applications, web services, cloud and social media




platforms, but also databases and files. It is possible to configure a message flow between

these different systems in order to obtain a unique big integrated system.

The framework includes an editor, based on Eclipse, that allows users to graphically define

flows between blocks and to deploy this flow that can be executed by the system. These

blocks falls into these categories:

Endpoints: that exchange messages to and from external applications. Endpoints can

be inbound, like an http or FTP listener, or outbound such as SMTP endpoint to send

email, or JDBC to insert some date to a database.

Scopes: that combines block of different nature like components or messages so that

they can be processed as a single unit by other Message Processors in the flow.

Components: that are blocks that provide business logic services and functionalities,

like logging, scripting components, web service components. For example the

scripting Java component allows to select a java class and invoke it in the application

flow.

Transformers: that transform information data that goes through the flow in order to

allows communication among different block. An example is transformer that receives

a payload in an HTTP request and convert it into a JDBC format to store it in a

database.

Filters: that uses various criteria to select messages for further processing. For

example a filter can ignore incomplete or invalid credential data submitted by an user

before sending it to the authentication module of an application.

Flow Controls: that allows to define criteria to route messages in the flow.

Error Handling: that add exception strategies to normal flows.

Cloud Connectors: that allows to communicate with some cloud platforms like CMS

(CMIS), e-commerce applications (Magento), CRM and social networks (Twitter).

4.4 Marketplace and tangible/intangible assets repository

As stated in the description of the Assets Repository functional component, the repository has

to support the management of service descriptions based on the USDL formalism or on an

extension of its metamodel that allows the description of specific characteristics of

tangible/intangible assets.

USDL went through several iterations since its conception in 2007. It was initially defined in

an informal way and then formalized through an XML Schema. The current version of the

complete USDL metamodel is USDL version 3.0 milestone M5 [34] which has been

developed in the Eclipse Modeling Framework (EMF) [35]. The EMF representation has been

discontinued and currently the FI-WARE project (together with the USDL community) is

introducing Linked USDL[36], a new representation (based on the RDF data model), which

keeps the original semantics and content of USDL version 3.0.




Figure 37 - USDL roadmap

As to the resources available for further development by the MSEE project, two options are

under evaluation:

reuse and customize the USDL models and tools (editor, marketplace) available as

Open Source which are based on the EMF formulation. This option has the drawback

that those resources are no longer maintained by the USDL community, which is now

fully committed to the new Linked USDL version.

adopt the new Linked USDL models and, if possible, reuse and customize tools from

the FI-WARE project. The choice of Linked USDL would foster simplification and

reuse of existing schemas on the basis of Linked Data principles and technologies.

Although Linked USDL is sponsored by FI-WARE, the Linked USDL community has

been established in order to foster an open development as well as a broad and world-

wide adoption.

In the first case (EMF-based USDL) the following resources are available:

USDL Editor for Experts: the editor is based on Eclipse development environment

and realized as a Rich Client Platform project;

USDL Editor light for Novices: web-based editor that is intended to be used by non-

technical people. Right now this editor is work in progress. Not every USDL element

is shown and only a few new elements can be created.

USDL Marketplace: web-based application, still to be tested for its compliance with

functionalities required for the second cycle of MSEE

USDL Model and XML Schema: data model for the USDL editor. It can be used to

manipulate USDL files, i.e., CRUD features of properties within the USDL document.

In the second case (Linked USDL), the Linked USDL community currently provides the

following RDF vocabularies:

Linked USDL Core: “This vocabulary provides the core module of Linked USDL. It

therefore covers the main concepts and relationships characterising services, leaving

more specific aspects regarding some particular dimensions such as technical

interfaces, licensing or security aside. These aspects will be covered in additional

modules, or in some cases, like the technical interfaces, by existing vocabularies. This

first draft includes most of the original USDL specification with some useful

simplifications. The vocabulary is, however, likely to be reorganised and better

modularised as we progress.”




USDL Service Level Agreements: “Simple vocabulary for describing service level

agreements. This vocabulary is based on the work on USDL in the TEXO project.

Service level module of USDL. Service Level Agreements (SLAs) are a common way

to formally specify such functional and non-functional conditions under which

services are or are to be delivered. However, SLAs in practice are specified at the top-

level interface between a service provider and a service customer only. Customers and

providers can use top-level SLAs to monitor whether the actual service delivery

complies with the agreed SLA terms. In case of SLA violations, penalties or

compensations can be directly derived. The USDL Service Level Module allows

modeling such information. The module is derived from our research as part of a

multilevel SLA management platform. This vocabulary defines a simple subset of the

original USDL Service Level Module.”

USDL Pricing Vocabulary: Simple pricing model vocabulary for USDL

USDL-SEC Vocabulary: very simple security model vocabulary for USDL

Moreover the FI-WARE is currently developing specifications and reference implementations

for Generic Enablers (Repository, Marketplace, Editor, …) for the management of USDL

service descriptions. Implementations are not open but the specifications are available to the

public, thus we will consider the possibility of realizing ad-hoc and bare-bone implementation

of such Generic Enablers.

4.4.1 Sesame

Sesame is an open source Java framework for storage and querying of RDF data. The

framework is fully extensible and configurable with respect to storage mechanisms,

inferencers, RDF file formats, query result formats and query languages.

In addition to offering ready to use native and database-backed quadstores, it also offers an

extensible a JBDC-like user API, streamlined system APIs and a RESTful HTTP interface

supporting the SPARQL Protocol for RDF.

There are many third-party stores that can be used through the Sesame Sail API. Examples are

4store, Bigdata, and OWLIM (which offers optional support for OWL reasoning).

The Sesame SAIL API can also be used to extend the functionality of such stores. Geospatial

and free-text indexing and search can be added to Sesame compatible quadstores with the

IndexingSail extension.

Another component of Sesame is Alibaba, an API that allows for mapping Java classes onto

ontologies and for generating Java source files from ontologies. This makes it possible to use

specific ontologies like RSS, FOAF and the Dublin Core directly from Java.

Some functionalities covered by the last release of SESAME are:

Sesame 2 is completely targeted at Java 5. All APIs use Java 5 features such as typed

collections and iterators.

Support for context/provenance, allowing you to keep track of individual RDF data

units (like files, for instance).

Proper transaction/rollback support.

http://www.w3.org/2001/sw/wiki/4store

http://www.w3.org/2001/sw/wiki/Bigdata

http://www.w3.org/2001/sw/wiki/OWLIM

http://www.w3.org/2001/sw/wiki/IndexingSail

http://en.wikipedia.org/wiki/API

http://en.wikipedia.org/wiki/RSS

http://en.wikipedia.org/wiki/FOAF_%28software%29

http://en.wikipedia.org/wiki/Dublin_Core




A REST-ful HTTP protocol that includes support for the SPARQL protocol and

SPARQL Query Results XML Format, which are currently both Proposed

Recommendations from the W3C.

Support for the SPARQL Query Language.

4.4.2 Linked USDL Editor

The Linked USDL Editor [37] is a Single Page Application (SPA) in HTML5 given to the

Linked USDL community as Open Source by SAP. The application has snippets for different

aspects of Linked USDL and a template mechanism to synchronize UI and model. The

conceptual foundation of the editor can be extended to include domain-specific aspects by

loading external vocabularies.

Figure 38 – Linked USDL Editor UI

Using external vocabularies it is possible to provide domain specific subtypes for qualitative

or quantitative properties of the service and to use the vocabulary for auto suggestions.

Figure 39 – Example domain-specific extension

http://www.w3.org/TR/rdf-sparql-protocol/

http://www.w3.org/TR/rdf-sparql-XMLres/

http://www.w3.org/TR/rdf-sparql-query/




The editor can extended for domain-specific needs by defining new snippets, thanks to a

direct mapping among HTML UI and RDF model. The editor is capable of exporting the

models in RDF, TURTLE and JSON.

4.4.3 FI-WARE Marketplace

The FI-WARE marketplace is tool that facilitates commerce by bringing together vendors and

buyers, or offers and demand, or producers and consumers. The core functionality of the

Marketplace is to provide a uniform service interface to discover and match application and

service offerings from providers and sources with demand of consumers. This core

functionality provides a basis for extended services depending on the domain and nature of

the target markets.

The FI-WARE marketplace component is based on linked data approach where every

resource to be directly resolvable given their URL

The FI-WARE marketplace doesn’t provide a UI but a set of RESTful API that support the

following functionalities:

Search: this service supports primarily customers finding offerings and stores

matching their needs. In both cases the Marketplace Search API supports freetext

search as well as attributed search.

Offerings: the Marketplace Offerings Component is responsible for exchanging

service offerings with stores and making them public to potential customers.

Registration: The Marketplace Registration Component takes care of registering,

updating, and deleting information about market relevant entities such as stores and

marketplace participants.

For further details see [21]




Figure 40 - FI-WARE Marketplace Registration Interface




4.5 Matching of the technological components with the functional

components

Functional

component

Technological

component

Description

Ideation Process Management System

Ideation Process

Collaboration

System

Gi2MO IdeaStream;

Gi2MO IdeaStream

Similarity

The combination of this two technological

components cover all the functionalities required.

Open ideaL This technological component provides the basic

functionalities required for the Ideation Process

Collaboration System

Ideation Process

Analysis

System

Gi2MO IdeaStream

Analytics

This technological component, in conjunction to

Gi2MO Idea Stream, provides all the required

functionalities

Open ideaL Open Ideal has a report page that contains report

charts for ideation analysis.

Ideation Process

Repository

Gi2MO IdeaStream Gi2MO IdeaStream integrates the Drupal

Knowledge Base in order to create a complete

repository for the management of ideas,

campaigns and of all the entities related to the

ideation process

Open ideaL Open Ideal stores data in the Drupal Knowledge

Base.


Process Engine ProcessMaker Full support of the required features through a

proprietary engine

Activiti Full support of the required features through a

BPMN 2.0 engine

Aperte Workflow Full support of the required functionalities

through the inclusion of some well-known BPM

implementations like jBPM and Activiti

Bonita Open Solution The Bonita Execution Engine fully supports the

required features through a Java API that allows

to interact programmatically with processes

Spagic Spagic includes execution engines such as jBPM

and Apache ODE (BPEL Engine) for supporting

both manual and automatic tasks

Petals ESB Petals ESB includes a BPEL service engine

component (Petals-SE-BPEL).

Mule ESB Mule ESB contains an integrated JBPM engine




that can interact with a Mule Flow.

Process Editor ProcessMaker The Process Map Designer is a web-based editor

that allows the modelling of BPMN2.0 diagrams.

Dynaform Builder allows business analysts to

design custom forms for human tasks

Activiti The Activiti Designer is an Eclipse plugin which

allows you to model BPMN 2.0 in the IDE-

environment

Aperte Workflow The Aperte Modeler is a web-application that

supports BPMN2.0. Liferay and Vaadin are used

for the implementation of the user interfaces.

Bonita Open Solution Bonita Studio, an Eclipse RCP application,

allows users to graphically design business

processes in BPMN2.0 standard notation. The

studio includes a graphical form designer in

order to create forms for human tasks.

Spagic Spagic Studio, based on Eclipse IDE, provides

tools for design, development and deploy of

BPMN-based processes and of simple web-forms

for human-oriented tasks

Petals ESB Petals Studio is a tool based on the Eclipse IDE

that embed the BPEL Designer, a modified

version of the official Eclipse BPEL Designer.

No support for human tasks

Mule ESB Mule Studio offers a graphical designer that

allows to edit process called Mule Flows.

However these flows are not business processes,

but mostly a way to orchestrate services.

Process Monitor ProcessMaker Process Maker has a dashboard that provides real

time monitoring efficiency and productivity of

processes and users executing those processes.

But advanced dashboard functionalities are

commercial.

Activiti Activiti Explorer is a web application that

provides process instance inspection, task

management and reports based on statistical

history data

Aperte Workflow Aperte Workflows provides a Liferay control

panel function, called Aperte Workflow Process

Instances, that allows administrators to track

running and terminated process instances and

their status. For each process instance it is also

possible to show a process map that represents




the process end tracks the current status.

Bonita Open Solution Bonita User Experience application allows to

track process instances and monitor some

indicators. It is available an advanced dashboard

that can be customized, showing statistics and

reporting.

Spagic Spagic Monitor is a web application for

monitoring and managing the life-cycle of single

services or processes. It is possible to track the

state of a process instance, and also to show

messages exchanged between services.

Petals ESB Petals View is a web application allowing to

monitor business process instances and data

exchanged between services. It is also able to

generate KPIs to drive management reporting.

Mule ESB Mule ESB Management Console is a web-based

interface to centrally monitor, manage, and

administer the runtime aspects of the enterprise

service bus. But this functionality is only

available in the commercial Enterprise version.

Process Log

Repository

ProcessMaker ProcessMaker stores service instances

information in its database and exposes web

services for interacting with processes. One of

these services, called CaseList(), allows to

retrieve the list of process instances, with

information about them.

Activiti Activiti allows to inspect the database tables

view the activiti logs

Aperte Workflow AperteWorkflow is released in two versions, one

using jBPM engine and one using Activiti

Engine. Both engines log process data in a

database table that can be accessed directly or

using some APIs. Aperte Workflow doesn’t

provides a custom log repository manager.

Bonita Open Solution Bonita Open Solutions REST APIs allows to

query process logging information present in its

database.

Spagic Spagic runs business processes using the jBPM

engine implementation. Logging information are

available accessing jBPM database tables or

using jBPM APIs.

Petals ESB No Process Log Repository

Mule ESB No Process Log Repository




Human-oriented

tasks GUI

ProcessMaker In ProcessMaker users can interact with

processes using the Cases Inbox web page frame.

This frame is similar to a mail inbox, where users

can see new, draft or participated cases. Cases

can be also filtered, sorted or searched. In the

main page frame users can see a list of cases, and

select one of them for handling the active task

filling a form.

Activiti Activiti Modeler is an open source version of the

KIS BPM that includes a web form editor

Aperte Workflow Aperte Workflow user front-end is integrated in

Liferay. User interact with processes using four

portlets: New Processes portlet that allows to

start new processes, Task Queues portlet that

allows to trace active tasks, Search portlet for

searching tasks, and a task main portlet thet

shows task forms that users have to fill.

Bonita Open Solution Bonita User Experience is a web module of

Bonita Open Solution suite that provides user

interface for interaction with processes. It has an

interface similar to a webmail, with a area in

which the user can see new tasks to handle.

Spagic Spagic TaskList is a web application provided by

Spagic suite where users can manipulate forms

defined for manual tasks.

Petals ESB No Human-oriented tasks GUI

Mule ESB No Human-oriented tasks GUI

Enterprise

Service Bus

ProcessMaker ProcessMaker doesn’t provide ESB

functionalities

Aperte Workflow Aperte Workflow doesn’t provides ESB

functionalities, but it is integrated with the Mule

ESB.

Bonita Open Solution BES provides more than 100 connectors that

provides ESB functionalities.

Spagic Spagic contains Connectors and Services.

Connectors provide cooperation functions with

external services, Services provide some

functionalities like data transformation, role

engine and scripting.

Petals ESB Petals ESB is an Enterprise Service Bus that

supports several communication protocols like

SOAP, Mail, FTP and standards like Web

Services and XSLT.




Mule ESB Mule ESB is an Enterprise Service Bus that

provides many transport connectors like email,

FTP, SOAP; data transformation services like

XSLT or XQuery; cloud connectors like Amazon

or Google ones; and services interaction

functionalities for interact with REST or WSDL

services.

Business

Intelligence

tools

ProcessMaker ProcessMaker Advanced Dashboards allows

users or administrators to monitor KPIs, but this

is a commercial functionality.

Aperte Workflow No Business Intelligence Tools.

Bonita Open Solution Bonita Open Solution provides functionalities for

defining KPIs and populating them with easy to

use graphical tools, but these functionalities are

also in commercial Subscription Packs.

Spagic No Business Intelligence Tools

Petals ESB In Petals ESB it is possible to define KPI

configurations with the Petals Studio, that acts as

probes that collect and filter information from the

bus and its services.

The collected data are stored in a database and

displayed by Petals View.

Mule ESB Mule ESB provides a module called Business

Event Analyzer that provides a place to monitor

business transactions and KPIs, but this module

is only available in commercial version.

Tangible/intangible assets management

Assets

Repository

EMF-based USDL There is no ready-to use repository for USDL

models that are defined through the EMF data

model. However EMF provides a set of tools that

would help the development of the repository.

Among those tools: CDO and Teneo

Linked USDL Linked USDL is supported with a reference

implementation of a repository developed in FI-

WARE. Also Sesame and RDF stores could be

adapted to provide the required functionalities.

Assets Editor EMF-based USDL The EMF-based USDL version is supported by

two editors:

USDL Editor for Experts: the editor is

based on Eclipse development

environment and realized as a Rich Client

Platform project;

USDL Editor light for Novices: web-




based editor that is intended to be used by

non-technical people. Right now this

editor is work in progress. Not every

USDL element is shown and only a few

new elements can be created.

Linked USDL Linked USDL has a dedicated HTML5 editor

that supports USDL core vocabularies but that

can be also extended with external vocabularies.

Assets

Marketplace

FI-WARE

Marketplace

This marketplace provides that support Linked

USDL and provise rest API for search, offering

and registration functionalities.

Ecosystem front-end

Web portal Liferay Liferay provides authentication, document

management, content management and portal

administration functionalities. MSEE Baseline

modules can be realized as custom portlets and

external applications can be integrated using

iframe portlet.

Drupal Drupal provides authentication, document

management, content management and portal

administration functionalities. Web modules can

be integrated in Drupal creating new Drupal

Modules and Themes.

4.5.1 Functionalities coverage by technological products

The following tables aggregates tools by the categories corresponding to the IEP components:

the tables map functionalities to technological products, indicating for each one the degree of

coverage of the requirements using different colors.

Green colour indicates that requirements are almost fully covered,

Yellow colour indicates that requirements are only partially covered (functions are not

present, they have commercial license etc),

Red colour indicates that requirements are not covered.

Ideation Process

Collaboration

System

Ideation Process

Analysis System

Ideation Process

Repository

G2MO Idea

Management

Open ideaL

Table 41 - Ideation Process Management System




Process

Engine

Process

Editor

Process

Monitor

Process Log

Repository

Human-

oriented

tasks GUI

Enterprise

Service Bus

Business

Intelligence

tools

Process

Maker

Activiti

Aperte

Workflow

Bonita Open

Solution

Spagic

Petals ESB

Mule ESB

Table 42 - Operational/ecosystem-governance process management system

Assets

Repository

Assets Editor Assets

Marketplace

EMF-based

USDL

Linked USDL

Table 43 - Tangible/Intangible assets management

Ecosystem Front-end

Liferay

Drupal

Table 44 - Ecosystem frontend

It is easy to see that several functionalities are not (or partially) covered by any analysed

product: for this reason in the next development phase, in order to deliver a complete version

of the Innovation Ecosystem Platform it will be necessary both integration of different

existing products (among the previous listed or new) and custom implementation of new

components from scratch.




The challenge due to technological heterogeneity of the components presented in this chapter

has been tackled during the implementation phase of the first IEP prototype and the

integration strategy of the modules, that has been already adopted focuses on two

complementary aspects. The first is related to front-end integration of the tools. In this case

Liferay Portal has been chosen as the aggregation point for accessing any functionality of the

platform. Different modules, also developed through technologies different from the ones

used in Liferay, are integrated in the user interface of the portal by leveraging the iFrame

approach and standard portlet implementations. Moreover the authentication is kept unique by

using a Single Sign On mechanism that allows users to provide once their credential and

access the different modules, even if they rely on their specific authentication/authorization

system.

The second integration aspect is related to back-end communication and interaction among

the different modules. This is achieved by choosing always modules that expose public APIs.

For example both the asset repository (Sesame) and the process engine (Activiti) provide

simple and easy to use RESTful APIs. Further details about the technical integration and the

solution provided are included in [2].




5 Conclusion

The D26.2 reports on the second version of the functional architecture and specification of the

Innovation Ecosystem Platform. This new release keeps the same approach used in the

previous version (D26.1) but taking in account the new results achieved from M9 to M18

months in several WPs, but also the evaluation of the first prototype of IEP released in M12.

In particular the main action taken in this new release are related to the specification of

modules that where just mentioned in the first release and to other specific aspects, namely:

the adoption of some Generic Enablers and of other indirect outcomes of FI-WARE

project (i.e. the service marketplace and the LinkedUSDL Editor),

the consolidation of the mapping among the user requirements and the platform’s

functionalities,

the refined specification of the maturity models and change management module

Moreover several improvements and evolutions have been applied to many modules due to

the first cycle feedback and to the availability of unforeseen components provided by other

WPs.

The IEP is presented as the main entry point to the Manufacturing Service Ecosystem

providing support for the management and the execution of key processes that have been

categorized as MSE Governance processes (for managing the ecosystem and its members),

MSE Innovation (for fostering innovation actions among the members of the MSE) and VME

Operations (for enacting and monitoring value-delivering processes that are conceived,

designed and developed in the servitization process).

The IEP represents the core platform of the whole servitization cycle being involved in the

ideation phase (Idea Management System), the execution of business process (Process

Management System) and the management of the Ecosystem and its members: the IEP is

therefore strictly connected with theoretical and technical outcomes of different WP in

MSEE.

This second version of IEP architecture has more adherence with the user requirements that

have been detailed after M9; also several integration points with other MSEE tools and

components have been clarified. The D26.2 not only presented the generic functional

components of the IEP architecture but proposed a more specific mapping between them and

concrete existing products or technologies to be reused in the second prototype development

phase.

Feedbacks and evaluation of the second version of the IEP prototype (M24), and in particular

of the piloting phase with the implementation of the IEP in the 4 MSEE user domains (M18),

will allow to further refine the architecture in order to fit better user requirements and

overcome possible technological inconsistencies with other platforms on MSEE IT system.




References

[1] MSEE Deliverable D11.1 “Service concepts, models and method: Model Driven

Service Engineering”

[2] MSEE Deliverable D26.3 “Innovation Ecosystem Platform first prototype”

[3] http://www.coin-ip.eu/

[4] Sitek P, Gusmeroli S, Conte M, Jansson K, Karvonen I, The COIN Book - Enterprise

Collaboration and Interoperability. Verlagsgruppe Mainz GmbH Aachen, 2011

[5] http://www.fi-ware.eu/

[6] http://www.fines-cluster.eu

[7] http://ecolead.vtt.fi/

[8] http://ec.europa.eu/information_society/activities/foi/lead/fippp/index_en.htm

[9] MSEE Deliverable D52.2 “User Requirements Analysis for Virtual Factories &

Enterprises in MSEE”

[10] MSEE Deliverable D25.4 “Business Processes for Distributed real time Decision

Making in Service Ecosystems”

[11] MSEE Deliverable D21.1 “State of the Art report for requirements and innovation

principles”

[12] http://www.bpmn.org/

[13] Cardoso, J., Barros, A., May, N., Kylau, U., “Towards a Unified Service Description

Language for the Internet of Services: Requirements and First Developments” in IEEE

International Conference on Services Computing 2010.

[14] Cardoso, J., Winkler, M., Voigt, K., “A Service Description Language for the Internet

of Service”” in Published in: Alt, R., Fähnrich, K.-P., Franczyk, B. (Eds.), Proceedings

First International Symposium on Services Science ISSS’09, Logos, Berlin, 2009.

[15] http://forge.fi-ware.eu/plugins/mediawiki/wiki/FI-WARE/index.php/FI-

WARE.ArchitectureDescription.Apps.Marketplace

[16] MSEE Deliverable D41.1 “MSEE Service-System Functional and Modular

Architecture”

[17] MSEE Deliverable D24.1 “State of the Art of maturity models and change

management in European manufacturing industry - v3.0”

[18] MSEE Deliverable D33.1 “FI Utility Services specification and architecture”

[19] MSEE Deliverable D33.3 “FI Utility Services first prototype”

[20] MSEE Deliverable D32.1 “FI Platform Federation specifications and architecture”

[21] FI-WARE Marketplace: http://catalogue.fi-ware.eu/enablers/marketplace-sap-ri

[22] http://www.liferay.com/

[23] http://drupal.org/

[24] http://www.gi2mo.org/apps/ideastream

[25] http://www.linnovate.net/ideal

[26] http://www.processmaker.com

[27] http://www.activiti.org

[28] http://kisbpm.com/

[29] http://www.aperteworkflow.org

[30] http://www.bonitasoft.com

[31] http://www.spagic.org/

[32] http://petals.ow2.org

[33] http://www.mulesoft.org

[34] http://www.internet-of-services.com/fileadmin/IOS/user_upload/pdf/USDL-3.0-M5-

Archive.zip

http://www.coin-ip.eu/

http://www.fi-ware.eu/

http://ecolead.vtt.fi/

http://ec.europa.eu/information_society/activities/foi/lead/fippp/index_en.htm

http://www.bpmn.org/

http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.Apps.Marketplace

http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.Apps.Marketplace

http://catalogue.fi-ware.eu/enablers/marketplace-sap-ri

http://www.liferay.com/

http://drupal.org/

http://www.gi2mo.org/apps/ideastream

http://www.linnovate.net/ideal

http://www.processmaker.com/

http://www.activiti.org/

http://www.aperteworkflow.org/

http://www.bonitasoft.com/

http://www.spagic.org/

http://petals.ow2.org/

http://www.mulesoft.org/

http://www.internet-of-services.com/fileadmin/IOS/user_upload/pdf/USDL-3.0-M5-Archive.zip

http://www.internet-of-services.com/fileadmin/IOS/user_upload/pdf/USDL-3.0-M5-Archive.zip




[35] http://www.eclipse.org/modeling/emf/

[36] http://www.linked-usdl.org/

[37] https://github.com/linked-usdl/usdl-editor

[38] http://www.openrdf.org

[39] FI-WARE Repository http://catalogue.fi-ware.eu/enablers/repository-sap-ri

http://www.eclipse.org/modeling/emf/

http://www.linked-usdl.org/

http://www.openrdf.org/