Sustainability and Business Plan V1 - Eprints · 2020-01-31 · HORIZONS 2020 PROGRAMME Research...

PROPRIETARY RIGHTS STATEMENT

This document contains information, which is proprietary to the FIESTA-IoT Consortium. Neither this document nor the information contained herein shall be used, duplicated or communicated by any means to any

third party, in whole or in parts, except with prior written consent of the consortium.

HORIZONS 2020 PROGRAMME Research and Innovation Action – FIRE Initiative

Call Identifier: H2020–ICT–2014–1

Project Number: 643943

Project Acronym: FIESTA-IoT

Project Title: Federated Interoperable Semantic IoT/cloud Testbeds and Applications

Sustainability and Business Plan V1 Document Id: FIESTA-IoT-D78-20170315-Draft

File Name: FIESTA-IoT-D78-20170315-Draft.pdf

Document reference: Deliverable 7.8

Version: Draft

Editor: Paul Grace

Authors Paul Grace, Denis Rousset, Martin Serrano, Michael Boniface

Organisation: ITINNOV

Date: 15/03/2017

Document type: Deliverable

Dissemination level: PU Copyright © 2016 FIESTA-IoT Consortium: National University of Ireland Galway – NUIG-Insight / Coordinator (Ireland), University of Southampton IT Innovation – ITINNOV (United Kingdom), Institut National de Recherche en Informatique & Automatique – INRIA (France), University of Surrey – UNIS (United Kingdom), Unparallel Innovation, Lda – UNPARALLEL (Portugal), Easy Global Market – EGM (France), NEC Europe Ltd. – NEC (United Kingdom), University of Cantabria – UNICAN (Spain), Association Plateforme Telecom – Com4innov (France), Athens Information Technology – AIT (Greece), Sociedad para el desarrollo de Cantabria – SODERCAN (Spain), Ayuntamiento de Santander – SDR (Spain), Fraunhofer Institute for Open Communications Systems – FOKUS (Germany), Korea Electronics Technology Institute KETI (Korea). The European Commission within HORIZON 2020 Program funds the FIESTA-IoT project.

FIESTA-IoT Deliverable 7.8 – Sustainability and Business Plan V1

Copyright © 2017 FIESTA-IoT Consortium 1

DOCUMENT HISTORY

Rev. Author(s) Organisation(s) Date Comments V01 Paul Grace ITINNOV 03/01/2017 Initial document outline

V02 Paul Grace ITINNOV 05/01/2017 Document Introduction

V03 Paul Grace ITINNOV 29/01/2017 Value Proposition

V04 Paul Grace ITINNOV 15/02/2017 Business Models

V05 Denis Rousset Com4Innov 19/02/2017 Analysis of FIWARE business models

V05 Paul Grace ITINNOV 22/02/2017 Federation Models

V06 Paul Grace ITINNOV 04/03/2017 TCO Analysis

V07 Paul Grace ITINNOV 05/03/2017 Plans and conclusions

V08 Paul Grace ITINNOV 06/03/2017 Version for Internal Review

V09 Denis Rousset Com4innov 10/03/2017 Quality review

V10 Juan Echevarria Cuenca

SANTANDER 10/03/2017 Quality review

V11 Ignacio Abaitua Fernández-Escárzaga

SODERCAN 10/03/2017 Quality Review

V12 Paul Grace, Martin Serrano

ITINNOV NUIG

15/03/2017 Version ready for submission

V13 Martin Serrano NUIG 12/03/2017 Format Update and Final Checks

V14 Martin Serrano NUIG 13/03/2017 Circulated for Approval

Draft Martin Serrano NUIG 15/03/2017 EC Submitted



EXECUTIVE SUMMARY This documents describes the initial FIESTA-IoT sustainability plan. This follows a tried and tested approach towards sustainability, which is observed in our analysis of existing sustainability plans for experimental facilities and open source software. The approach is based on: firstly identifying what is the key FIESTA-IoT value offering; secondly, how it generates revenues and costs; thirdly, what is the value proposition for the future stakeholders; and fourthly how this can be put into place. The FIESTA-IoT Value Proposition to data consumers is: access to a unique data offering from heterogeneous domains with semantically aligned data, real-time data from real deployments. There is no comparable offering on the market. The FIESTA-IoT Value Proposition to data providers is: access to a community of potential data consumers who may be willing to pay for their specific type of data. A series of potential business scenarios has been generated for the FIESTA-IoT facility. These scenarios represent the fundamental options which the consortium has to select from in order to ensure the sustainability of the facility going forward. Initial analysis of the scenarios has identified the pros, cons, caveats and viability of each. An analysis of the FIESTA-IoT services and tools is presented with the goal of identifying a federation organisation that best matches the FIESTA-IoT offering. Further we consider the costs of operating such a facility providing initial evidence of the revenues required to sustain the facility in the long run. The next steps are to explore these plans with the consortium partners. The process will then re-evaluate open issues, discarding unviable scenarios and moving forward to develop and implement the business plan that will be put into action to sustain the facility at the end of the project.



TABLE OF CONTENTS 1 INTRODUCTION .............................................................................................................................. 6

1.1 FIESTA-IOT OVERVIEW ............................................................................................................... 61.2 SUSTAINABILITY ........................................................................................................................... 61.3 DOCUMENT OVERVIEW ................................................................................................................. 7

2 SUSTAINABILITY PLANNING METHODOLOGY ........................................................................... 82.1 RELATED SUSTAINABILITY PLANS .................................................................................................. 8

2.1.1 Experimental Testbed Federations ..................................................................................... 82.1.2 Open Source Software Sustainability ............................................................................... 14

2.2 FIESTA-IOT SUSTAINABILITY METHODOLOGY ............................................................................. 16

3 FIESTA-IOT VALUE PROPOSITION ............................................................................................. 183.1 WHAT DOES FIESTA-IOT OFFER? .............................................................................................. 193.2 THE VALUE PROPOSITION ........................................................................................................... 203.3 CUSTOMER SEGMENTS ............................................................................................................... 21

3.3.1 Initial Stakeholder Identification ........................................................................................ 213.3.2 Market Share .................................................................................................................... 22

3.4 DATA CONSUMER VALUE PROPOSITION ....................................................................................... 243.5 DATA PRODUCER VALUE PROPOSITION ....................................................................................... 27

4 BUSINESS MODELS ..................................................................................................................... 294.1 IOT DATA MARKETPLACE: P2P BROKER SERVICE ........................................................................ 294.2 IOT DATA MARKETPLACE: ADVERTISEMENT SERVICE ................................................................... 314.3 BAIT AND HOOK SUBSCRIPTION MARKETPLACE ............................................................................ 324.4 IOT DATA MARKETPLACE: P2P DATA SHARING SERVICE .............................................................. 334.5 CERTIFICATION AND INTEROPERABILITY TESTING SERVICE ............................................................ 344.6 INITIAL ANALYSIS ........................................................................................................................ 35

5 FIESTA-IOT FACILITY OPERATION AND ORGANISATION ....................................................... 355.1 FEDERATION SERVICES .............................................................................................................. 355.2 FEDERATION MODELS ................................................................................................................ 37

5.2.1 Federation Services .......................................................................................................... 375.2.2 Invisible Co-ordination ...................................................................................................... 385.2.3 Advisor .............................................................................................................................. 395.2.4 One Stop Shop ................................................................................................................. 405.2.5 Integrator ........................................................................................................................... 415.2.6 Analysis ............................................................................................................................. 42

6 TOTAL COST OF OWNERSHIP .................................................................................................... 426.1 OPERATIONAL COSTS ................................................................................................................. 436.2 MAINTENANCE COSTS ................................................................................................................ 43

7 SUMMARY & NEXT STEPS .......................................................................................................... 447.1 BUSINESS CANVAS MODEL ......................................................................................................... 447.2 NEXT STEPS .............................................................................................................................. 44

7.2.1 Value proposition and stakeholder feedback .................................................................... 447.2.2 Customer Relationship Strategy ....................................................................................... 45



LIST OF FIGURES

FIGURE 1: FED4FIRE VALUE PROPOSITION3 ............................................................................................... 8FIGURE 2. FIESTA-IOT LONG-TERM EVOLUTION. ..................................................................................... 16FIGURE 3: STEPS IN THE SUSTAINABILITY METHODOLOGY ........................................................................... 18FIGURE 4: THE FIESTA-IOT FACILITY OFFERING ...................................................................................... 19FIGURE 5: VALUE PROPOSITION CANVAS .................................................................................................. 20FIGURE 6: FIESTA-IOT GLOBAL MARKET CONFIDENCE PROGRAMME STAKEHOLDERS ............................... 22FIGURE 7: FIESTA-IOT STAKEHOLDERS ................................................................................................... 23FIGURE 8: DATA CONSUMER VALUE PROPOSITION .................................................................................... 25FIGURE 9: DATA PRODUCER VALUE PROPOSITION .................................................................................... 27FIGURE 10: FEDERATION MODELS ............................................................................................................ 37FIGURE 11: INVISIBLE CO-ORDINATION FEDERATION MODEL ...................................................................... 39FIGURE 12: ADVISOR FEDERATION MODEL ............................................................................................... 40FIGURE 13: ONE STOP SHOP FEDERATION MODEL .................................................................................... 41FIGURE 14: THE INTEGRATOR FEDERATION MODEL ................................................................................... 41FIGURE 15: FIESTA-IOT BUSINESS MODEL CANVAS ................................................................................ 44FIGURE 16: TRANSITIONS IN GOVERNANCE AND CUSTOMER RELATIONSHIPS ................................................ 45

LIST OF TABLES

TABLE 1: FIESTA-IOT SUSTAINABILITY METHODOLOGY ............................................................................ 17



TERMS AND ACRONYMS

IoT Internet of Things FIESTA-IoT Federated Interoperable Semantic IoT Testbeds and Applications

RTD Research and Technical (or Technological) Development

VM Virtual Machine

FTE Full Time Equivalent

TCO Total Cost of Ownership

ISP Internet Service Provider

EaaS Experiment as a Service

NREN National Research and Educational Network

ICT Information and Communication Technologies

KPI Key Performance Index



1 INTRODUCTION

1.1 FIESTA-IoT Overview

This deliverable describes the initial sustainability plan of the FIESTA-IoT project and the associated potential business models. In particular, it explores how the technical and research results of the FIESTA-IoT project can be exploited; and most importantly how the FIESTA facility can be sustained in the long-term (i.e. that the core facility, services and tools that make up the FIESTA-IoT offering will be utilised and valued beyond the conclusion of the project). Hence, the key FIESTA-IoT project objectives here are:

• To create a clear, simple and attractive offering for a key target stakeholder: SMEs, that is understandable in their terms;

• To exploit key results in order to create a sustainable experimental IoT facility. For the remainder of this document we refer to the FIESTA-IoT Facility as the entity to be sustained (to avoid confusion with sustaining the FIESTA-IoT project).

1.2 Sustainability

Sustainability can be considered, at its most basic definition, as the ability to continue. Such sustainability is largely driven by three important factors1; these can be applied to an experimental facility such as FIESTA-IoT:

• Sustainable need: FIESTA-IoT provides a service that is needed by someone—and by enough people that the ongoing need is a sufficient reason to continue.

• Sustainable capability: the continued provision of a service, i.e., generating the required resources (e.g. cash flow) to maintain operation. Therefore, sufficient need generates the revenue to ensure that ongoing operating costs are compensated. Long term sustainability plans typically focus on minimising direct costs and developing diverse and reliable revenue streams.

• Sustainable community: a set of people who are willing to donate their times and skills in order to add value to the software through software development and use. This can be in terms of developing new software services and tools that can enhance both the facility offering and the experiences of its users.

1 R. Metcalfe, “Sustainability Study: A case study review of open source sustainability models,” Joint Information Systems Committee (JISC), Oxford, 2007.



Sustainability plans generally focus on capability; however, Moran & Loy2 identify that in terms of sustainability the focus is not on revenue, but on value:

“It is not about the money; it’s not about getting by; it is about identifying value to a specific group or stakeholder”2.

This is similarly identified by Metcalfe1, “continuity of effort and requirement/need is fundamental”. Hence, sustainable need and capability are strongly coupled and hence value is the capability that answers a sustainable need. A clear value proposition offers something unique, identifies the need and continues to add value based on changing user demands2.

Therefore, this initial sustainability plan for FIESTA-IoT concentrates on identifying the stakeholders of FIESTA-IoT and documenting the clear value propositions to these stakeholders. The remaining business planning centres on these initial propositions.

1.3 Document Overview

In this document, we elaborate the initial plan for sustaining the FIESTA-IoT federation. For this purpose, we present the following material:

• Sustainability Plan Strategy and Methodology: After investigating alternative approaches taken by both experimental facilities and open source software platforms to sustain their operation and development—we outline the methodology that we will employ to put the sustainability plans in place.

• Value proposition. We identify the value proposition of the FIESTA-IoT project to the key stakeholders as a key element of the sustainability plan.

• Business models. We examine five potential business models and how they can be employed by FIESTA-IoT.

• Federation and organisation. We look at the potential federation models that define the optimal organisational structure of the FIESTA-IoT federation. We consider how it could be sustained to meet the value proposition offering to the stakeholders.

• Operating cost. An initial overview of the potential operating costs of the federation in front of what amount of revenues would be required to maintain the ongoing operation of the federation.

We finish the document with an action plan evaluating and extending the business plan based upon feedback from FIESTA-IoT users and stakeholders, with a special focus on the incoming testbeds, experimenters and SMEs selected in the Open Calls.

2 N. Moran and M. Loy, “Revenue, Recession, Reliance: Revisiting the SCA/Ithaka S+R Case Studies in Sustainability,” JISC Strategic Content Alliance, 2012.



2 SUSTAINABILITY PLANNING METHODOLOGY

In this section, we first examine sustainability approaches from various fields that are relevant to plan the FIESTA-IoT Facility sustained operation. We consider critically experimental facilities such as Fed4FIRE and open source software initiatives. Then we identify the methodology to be utilised to build the FIESTA-IoT Facility sustainability plan.

2.1 Related Sustainability Plans

2.1.1 Experimental Testbed Federations

Fed4FIRE Fed4FIRE is a federation of experimental testbed facilities; these testbeds cover a broad range of fields, e.g. wireless networks and cloud facilities offering virtualized access to computational and communication resources to support Future Internet experimenters. The Fed4FIRE sustainability plan3 follows the following methodology: i) identification of the value proposition to two stakeholder groups (testbeds and experimenters–shown in Figure 1).

Figure 1: Fed4FIRE Value Proposition3

3 J. Ooteghem et al., “D2.6 – Second Sustainability Plan”, Fed4FIRE D2.6 Deliverable, November 2014: https://www.fed4fire.eu/wp-content/uploads/2016/10/d2-6-second-sustainability-plan.pdf



Subsequently, ii) they define the services provided by the federation to meet this value and how the federation should be organised and managed to deliver these services. They use the FitSM IT service management approach4 for exploring sustainability. Finally, iii) they recommend potential business models to generate revenue to sustain the federation—these include a central funding model for sustaining the operation of testbeds within the federation, and then potential subscription models by experimenters to pay for the usage of the service. Analysis FIESTA-IoT differs from Fed4FIRE in two important ways: i) FIESTA-IoT is a federation of data providers, as opposed to computational resource providers; ii) Fed4FIRE is targeted to experimenters in the more niche Future Internet networking space e.g. scientific researchers, whereas FIESTA-IoT offers more general availability of data. Fed4FIRE seeks to provide enough value knowing that the limited need from the users requires that public funding be spend to sustain its operation.

GEANT Value proposition. GEANT is a pan European data network and testbed to support education and research activities. Its key value is in the services offered to researchers which cannot be got from commercial alternatives i.e. ISPs; hence creating unique value is critical to the furthering of R&D in Europe5:

• Connectivity services: for example, high-bandwidth IP connectivity; point-to-point connectivity across reserved, high-speed, guaranteed-bandwidth circuit; bandwidth on demand services.

• User access: building a set of interoperable systems that allow roaming access by verifying users’ identities and rights, and granting access to resources as appropriate.

• Network performance services: monitoring of network performance.

• Security services: maintain the integrity of the network; provide strategies for incident detection and handling.

Revenue Stream. Due to the unique value offering, GEANT has been sustained by public funding since the project began in November 2001. The current network and associated programme of activities is co-funded by the European Commission and the National Research and Education Networks, with total EC funding of €93 million and €88 million from NRENs over four years from April 2009.

Sustainability model. GEANT is sustained through a public funding model supported by the EC and NRENs as described above. As with any publicly funded service there are risks due to budget cuts. However, research trends (particularly the need experiment with big data and cloud computing) means that this is unlikely to be a risk

4 FITSM Consortium, “The FIT-SM standard for lightweight IT service management”, http://fitsm.itemo.org/fitsm-standard, September 2016. 5 http://www.geant.net/Services



in the near future (i.e. during the H2020 funding framework). However, GEANT constantly revisits its value offering with new services and initiatives that meet the requirements of their users (the European R&D community) e.g. Open Calls for use of the GEANT testbeds that will help provision future services.

European Grid Infrastructure The European Grid Infrastructure (EGI) is a federation of over 350 resource centers (computational and data resources for high-performance computing) coordinated by EGI.eu (which is the non-profit foundation managing the governance of the federation). EGI.eu consists of 35 participant countries and institutions.

Value proposition. Scientific researchers, particularly in Physics, Biology and e-Sciences place large demands for computational resources e.g. to process large-scale data and run computationally intensive models. Hence, EGI.eu manages a sustainable pan-European infrastructure of computational and data resource centers to support these European research communities and their international collaborators. The EGI federation has been successfully employed to support experiments with the LHC at CERN6.

Revenue. Like GEANT, EGI is sustained through continued public funding. Initially, 3 years funding of 12 million Euros beginning in 2001; followed by 46 million euros in Framework 6. Similar funding was maintained through to 2010. Currently, a 32 million Euros project named the EGI-Integrated Sustainable Pan-European Infrastructure for Research in Europe (EGI.INSPIRE) funds the initiative.

Sustainability model. Continued public funding of the federation and the management organization is driven by user demand. EGI integrates over 300,000 processors and more than 100 PB of storage space located at 350 sites in 50 countries. EGI currently supports over 13,000 researchers in their intensive data analysis needs7—hence there are significant demands from researchers (many publicly funded scientists) to maintain this infrastructure; this is also a cost-saving method; researchers do not need to be funded to build their own ICT infrastructures.

PlanetLab PlanetLab is a collection of connected machines distributed across the globe in order to provide an overlay testbed and deployment environment to support future networking research activities. The PlanetLab Consortium is a collection of academic, industrial, and government institutions cooperating to support and enhance the PlanetLab overlay network. The consortium is responsible for overseeing the long-term growth of PlanetLab's hardware infrastructure; designing and evolving its software architecture; providing day-to-day operational support; and defining policies that govern appropriate use.8 Institutions join the Consortium by

6 http://www.egi.eu/about/EGI.eu/history_of_EGI.html 7 EGI Position Paper on Common Strategic Framework for future EU Research and Innovation Funding 8 http://www.planet-lab.org/consortium



signing a membership agreement and connecting two or more nodes to the PlanetLab infrastructure. Individuals that want to use PlanetLab should arrange to do so through their home institution.

Value proposition. The key value proposition of PlanetLab is to perform networking experimentation using real world deployments and on a global scale. Hence, it provides the next step in validating results beyond simulation in tools such as NS-2. This is provided with a low entry barrier – institutions need only commit two machines to the testbed and then experimenters within that institute have access to the testbed.

The metrics used by PlanetLab to measure impact designate their view of the value that it provides9; that is, it is an essential tool for network and distributed systems research and that it offers a recognized experimental facility for performing academic research papers. Over 100 papers at top level conferences is a key KPI. Over 500 research projects executing in parallel.

Revenue and Sustainability. PlanetLab employs a number of methods to generate revenue, minimize costs and sustain. Funding comes from sponsorship: Charter ($300k annual dues) providing a permanent seat on steering committee, unlimited number of slices, access to PlanetLab events, research papers, and working groups. Full ($75k annual dues) provides a rotating seat on Steering Committee, 10 slices, etc. Additional funding is generated from US government research grant.

PlanetLab have sought to grow the customer base through alignments with other network testbed federations, e.g. OneLab.

FIWARE Federation / Foundation The FIWARE platform provides a rather simple yet powerful set of APIs (Application Programming Interfaces) that ease the development of Smart Applications in multiple vertical sectors. The specifications of these APIs are public and royalty-free. Besides, an open source reference implementation of each of the FIWARE components is publicly available so that multiple FIWARE providers can emerge faster in the market with a low-cost proposition.

Several initiatives that are currently active all around the world can be gathered under the same Future Internet (FI) “label” ; to list a few: the EC Future Internet ICT programme under FP7 in Europe (which spans from future networks to Future Internet Research and Experimentation Infrastructures1 – FIRE – to the Future Internet Public Private Partnership – FI-PPP – innovation programme).Because of these various initiatives, the “Future Internet” expression may mean different things to different researchers and innovators around the world and providing a unifying definition is as challenging as forecasting the future. Within the context of this document, we assume that the Future Internet is the evolution of the Internet as we know it today to enable and support future scenarios both in society and in the business world.

9 http://www.planet-lab.org/impact



Although it was born in Europe, FIWARE has been designed with a global ambition, so that benefits can spread to other regions. The FIWARE Mundus programme is designed to bring coverage to this effort engaging local ICT players and domain stakeholders, and eventually liaising with local governments in different parts of the world, including North America, Latin America, Africa and Asia.

FIWARE has put in place a process to select FIWARE regions and local innovation hubs. A study was performed over 180 regions with the objective to identify the most relevant regions, which can support and mobilize their innovation ecosystem to develop new applications and services with FIWARE. 23 of them have been contacted in order to understand their interest on the FIWARE Mundus initiative.

The selection criteria were:

• ICT as one of the top smart specialization topics • European ICT Pole of Excellence (EIPE) • Already involved with FIWARE • (experiments, nodes, accelerators) • Active ICT cluster(s)

The regional engagement is following 3 validation steps.

1 2 3

At this point it is necessary to prepare following steps to become a FIWARE Region. A list of items is scrutinized such as:

• Interaction with JRC / S3 for the Smart Specialization Strategy initiative at EU level

• Interaction with European Cluster Observatory, eDIGIREGION • Interaction set up with FIWARE and the innovation • hubs (I3H)

Identify the key regional policy and business organisations and check their interest in setting up a sustainable FIWARE ecosystem with potential regional funding

Validate the innovation ecosystem able to adopt

FIWARE to develop innovative applications, products and

solutions

Identify the structure/organisation able to

host and to operate the FIWARE platform i.e. to

becoming a FIWARE Lab node

The benefit of working with FIWARE Mundus:

Get support to mobilize regional and national

stakeholders using the taxonomy established by

FIWARE Mundus

Get support to mobilize all the relevant players i.e. ICT Clusters, accelerators, incubators, industry,

research…; get training and support from FIWARE

Get support to identify the relevant existing platforms / test beds through the XiFi

portal; get support for training and joining the FIWARE Lab

federation of nodes



• Interaction with Vanguard Initiative (Asturias, Baden-Wurttemberg, Catalonia, Basque, Lombardy, …)

• Interaction with the European Commission in order to analyse the possibility to use the structural funds

• Interaction with Open&Agile Smart City initiative (Defining city SDKs based on FIWARE plus standard data models defined using “driven by implementation approach”)

• Interaction with DG Region in order to check the usability of structural funds to maintain and operate the FIWARE nodes after the end of the

• Future Internet PPP. 4 5 6

The FIWARE Mundus initiative so far produced an introduction white paper focusing on the Future Internet challenges, and a collection of white papers focusing on the future roadmap of key future internet technologies developed within FIWARE programme. All white papers have been elaborated with the support of a small team of international experts from the academia and the industry, whose names are listed in the front page of the documents. “Map of technology and business challenges for the Future Internet”10 white paper describes the challenges that Future Internet should face in term of technology and business evolution. The white paper is the first step for the elaboration of the roadmap contented in the other white papers. “A Future Internet Roadmap for the FIWARE ecosystem”11 white paper provides a roadmap of the evolution of the Future Internet considering FIWARE as the platform to support that future. The white paper works as a general introduction to other five white papers providing a detailed view on the roadmap for the following technologies: 10https://www.fiware.org/wp-content/uploads/tabs-img/tab-mundus5/FutureInternetChallenges_web.pdf 11https://www.fiware.org/wp-content/uploads/tabs-img/tab-mundus5/FutureInternetRoadmap_gen https://www.fiware.org/wp-content/uploads/tabs-img/tab-mundus5/FutureInternetRoadmap_general_vFINAL.pdf eral_vFINAL.pdf

Define the sustainable business model of operating

the FIWARE platform and ecosystem (cost of the implementation, cost of

exploitation and maintenance)

Prepare an opportunity document and share it with all

parties involved)

Get the engagement/commitment of all

parties involved

The benefit of working with FIWARE Mundus:

Get support to mobilize regional

and national funding; get support to access European funding (smart specialization

strategy, structural funds, etc.)

Get support

to prepare

this document

Get support

to prepare

a contractual/political agreement)



Media Internet, Big Data, Internet of Things, Cloud Computing, and Communication Networks. Analysis

FIWARE Federation offers a good example for sustainability. The way the considered GE (Generic Enablers) can become a commercial product will drive a similar target from FIESTA-IoT Facility. The stakeholders are very close and FIWARE GEs are used by some partners embedded in their development.

2.1.2 Open Source Software Sustainability

Other examples of sustaining technology provision come from the Open Source community. The business models they employ offer potential avenues that could be followed by the FIESTA-IoT Facility. Examples of how these achieve long-term sustainability with the following business models are12:

• Subscription: users pay subscription costs to an external body in order to obtain central maintenance and support; an example is RedHat13 where users pay a fixed price for 24/7 access to support.

• Community: the costs of sustaining the product or service are covered by building a community of voluntary users and industry partners who agree to cooperate on development.

• Commercial: users pay for a commercialized version of software, normally to minimize risk and gain guaranteed support, maintenance and service models.

• Macro R&D Infrastructure: refers to a central body (typically publically funded) that provides robust releases and support for open source products that are of strategic importance to a community (e.g. scientific research and European Grid Infrastructure); much in the same spirit as the need for a Fed4FIRE like experimental infrastructure.

We now examine a set of key open source case studies and analyze the extent to which their success offers input to the sustainability plan of FIESTA-IoT. For this, we look at: i) the value proposition and whether this has changed to meet sustained need; ii) the revenue stream used to sustain capability; iii) the costs and overheads (to determine the extent this is comparable to Fed4FIRE).

Apache Software Foundation The Apache Software Foundation, is a non-profit corporation (registered charity) that provides organizational, legal, and financial support for a broad range of over 140 open source software projects. These are often industry leading implementations of software with examples such as Tomcat, Cassandra, and Hadoop. The Apache Foundation can be seen as equivalent to FIESTA-IoT with software equivalent to the data testbeds.

12 V. M. H. a. N. S. Chang, “From Open Source to long-term sustainability: Review of Business Models and Case studies,” in All Hands Meeting 2007, OMII-UK Workshop, 2007. 13 http://www.redhat.com/



Value Proposition. The foundation supports and distributes quality and reliable open source software. This is underpinned by the principle of governance of merit; the foundation ensures qualified developers work on projects—commit privileges must be earned by developers. Hence, the foundation meets the sustained need of developers with the continued provision of new projects that change over time. The foundation has sustained since 1999, has over 400 members, and is responsible for the distribution of software to millions of users.

Revenue Stream. Charitable donations and sponsorship packages: $100k/year Platinum (Google, Facebook, Yahoo, etc.) through to $5K/year Bronze. There is little receipts in return directly, but the value is obvious. These organizations rely on this software and the unpaid work of the developers. Hence it is in their interest to keep it running and progressing.

Costs. Overheads in terms of infrastructure, bandwidth costs, infrastructure staff, etc operated by the foundation. The foundation also organises community building events, i.e., the successful ApacheCon14 conferences.

Sustainability model. The Apache Software Foundation is an example of the community model. Development of individual projects is voluntary, and revenue is based upon donations. The open source projects get significant value from the foundation through increased exposure to a larger community. This in turn leads to wider community involvement i.e. more users and more developers. The users gain significant value from freely available, high-quality, and standard software.

OW2 OW215 is a non-profit organization committed to the development and distribution of open-source middleware software. OW2 provides tools and services to support the development of new software, and market the software to the OW2 community. The organisation consists of approximately 40 member institutions, over 80 active development projects, and thousands of end users.

Value proposition. OW2 provides end-users with a comprehensive set of reliable open source software that reduces technology and legal risks. OW2 offers tools to develop and debug software based upon the open source projects, and offers legal guidance for the free distribution of software.OW2 also provides a marketplace for the advertisement of software [ projects, increasing the visibility of the project to the thousands of OW2 end-users.

Revenue Stream. OW2 employs a membership model, where membership packages provide different levels of service16.

Sustainability model. OW2 is a hybrid community and subscription model. Membership allows participation in the market (i.e. proposal of new projects) and greater control of direction of the organisation. However, the community still relies on the altruistic commitment of developers to maintain and develop software.

14 http://www.apachecon.com/ 15 https://www.ow2.org 16 http://ow2.org/view/Membership_Joining/Membership_Categories



2.2 FIESTA-IoT Sustainability Methodology

FIESTA-IoT consortium has defined an evolutionary sustainability strategy accordingly with the IoT data market and ad-hoc with the service requirements for the Internet of Things. Figure 2 depicts the expected duration and post project lifetime of the FIESTA-IoT Platform accordingly to the proposed strategy. In the figure starting from left included the core areas that consolidate the FIESTA-IoT background, included the FIESTA-IoT portal that in combination with technological and scientific approach (i.e., Interoperability, Linked Data, system integration) provides the necessary support for the Internet of Things (IoT) FIESTA Ecosystem creation. Additionally and as part of the FIESTA-IoT project objectives, standards and users are closely involved in the community-development that is focused on IoT Testbed data and IoT Certification for the last part of the project implementation. There are Scientific and Industry communities that are targeted with Open Calls to demonstrate the Experimentations a Service Model (EaaS) prooted by FIESTA-IoT. Finally and beyond the culmination of the project, the core idea of maintaining FIESTA-IoT platform in the form of FIESTA-Lab’s is being studied and currently the most appealing path towards innovation by providing IoT Data and IoT market Place.

Figure 2. FIESTA-IoT Long-Term Evolution.



Sustainability in FIESTA-IoT follows well-established approaches as previously described in the related platforms and foundations. This methodology is outlined in

Table 1; and depicted in Figure 3 in particular, the methodology is built around the modelling approaches as recently identified in new Osterwalder business model canvas17.

Table 1: FIESTA-IoT Sustainability Methodology

Step Outcomes Consortium Activities

Step 1: Explore the project activities and derive a value proposition

Based upon the services, tools, and data testbeds being initially created for the FIESTA-IOT facility—we generate a value proposition (in Section 3 of this document) and then potential business scenarios (in Section 4).

M21: Discussed by all partners at Berlin GA Meeting (October 2016)

Step 2: Identify potential business scenarios and operational costs

Select business models based on analysis of available options relevant to the FIESTA-IoT facility (IoT data market place) Business model canvas defined for potential scenario (Section 3 and 5)

M23: Discussion and analysis of identified business scenarios by all partners at Heidelberg GA Meeting (January, 2017)

Step 3: Identify open issues.

Identification of potential clients and partners.

Identification of key business activities.

M27

Step 4: Seek partner buy-in

Definition of management structure of the FIESTA-IoT facility as agreed by partners wishing to step-up and continue its operation.

M30

Step 5: Explore open issues

Redefine the business models based upon the partners’ agreement.

Explore propensity to pay in satisfaction survey. The FIESTA-IoT Open Call users offer a group of users who can initially provide such feedback.

M33

17 Osterwalder, A, Pigneur,Y. , Smith, A., (2010), " Business Model Generation", self-published, 2010



Step 6: Business plan and launch

Creation of marketing material.

Management structure and operation organization defined and in place.

Launch of FIESTA-IoT Facility to customers.

M36

Figure 3: Steps in the sustainability methodology

3 FIESTA-IOT VALUE PROPOSITION

FIESTA-IoT has enormous potential to aid developers and researchers in the fields of IoT and data. In this section, we identify the key stakeholders who will utilise the platforms and services provided by FIESTA-IoT. We establish what benefits FIESTA-IoT gives to these stakeholders. Built upon this, we will document the clear and simple value proposition of FIESTA-IoT. We are leveraging the sustainability and business planning approach built upon the Ostewalder Canvas Method—this model contains methods to both identify and define the value proposition. We follow this methodology, employing the Ostewalder’s Value Proposition Canvas18 to model the value propositions.

18 A. Smith, A. Osterwalder, G. Bernarda, T. Papadakos, and Y. Pigneur, “Value Proposition Design: How to Create Products and Services Customers Want”, John Wiley & Sons, October 2014.



3.1 What does FIESTA-IoT offer? To clarify the following plans, we must first identify what FIESTA-IoT will potentially offer at a high level (illustrated in Figure 4). There are two key services in evidence:

• IoT Data Marketplace: Access to highly heterogeneous data sources that are semantically aligned and can be easily leveraged and integrated using the FIESTA-IoT tools. Essentially this is an IoT data marketplace for the provision and usage of data from real IoT technology deployments.

• Certification: A Global Market Confidence Certification Programme, that will help developers certify that their software and products conform with and interoperate with the latest IoT market specifications and standards. Thus, reducing their testing effort and costs.

There are three types of stakeholders for this offering:

• IoT Data Provider: a provider joins the FIESTA-IoT federation in order to make their data available to data consumers. This could be an IoT testbed or data set provider. They advertise their data in the data marketplace. They also use the Global Market Confidence programme to certify that their data and their APIs available to users to access their data meet standard specifications.

• IoT Data Consumer: a customer who is looking for IoT data to use for their technology or research purposes, e.g. IoT application developer, or scientific researcher such as a data scientist.

• IoT Software Developer: This is a subset of the above 2 types of stakeholders (they will typically also be a provider or a consumer). They are involved in IoT or data software development and wish to test interoperability and certification with current IoT market standards and specifications. They interact with the Global Market confidence programme to achieve these guarantees.

Figure 4: The FIESTA-IoT Facility Offering



3.2 The Value Proposition

The Value Proposition canvas, illustrated in Figure 5, extends the overall Ostewalder business model canvas to richer model values proposition of the business model and better target products and services which the customer wants. The canvas is in two parts:

• The customer segment. This part models three elements of the customer: i) what jobs they wish to carry out (what do they want to do?), ii) what pains they needs to addressed, and iii) what gains do they want (hope) to see.

• The value proposition. This models the value offered by the product/service; again in three parts: i) the services provided on which the value proposition is based, ii) the pain killers—how do these value services reduce pain, and iii) the gain creators—how do these services deliver the gain.

Therefore, we will now first analyse the potential FIESTA-IoT stakeholders and identify the customer segments to create a value proposition for. Subsequently, for each customer segment we create a Value Proposition Canvas.

Figure 5: Value Proposition Canvas



3.3 Customer Segments

3.3.1 Initial Stakeholder Identification

In FIESTA-IoT Deliverables D2.519 and D6.120 we outlined the potential stakeholders of the Global Market Confidence Programme. These are more specific persons in the categories of data provider, data consumer and IoT software developer. These stakeholders are illustrated in Figure 6. The stakeholders in this figure are:

• IoT Infrastructure Providers and Testbed Owners provide the test environment and are most interested in using the certification tools to improve their interoperability according to a reference in order to attract more experimenters to conduct their testing on the testbed. They are data providers.

• Experiments Developers and Integrators develop and perform experimentations, and are most interested in features such as easing the use of the testbeds, the performance of services and tools provided by the testbeds for development and deployment, and the effectiveness of collecting experimentation results. They are data consumers.

• Experimenters/Researchers use the experiments running on the test federation to obtain the results they want and are most interested in the variety and availability of resources provided by the federation to design the experiment they need. They are data shapers.

• IoT application developers. All successful ICT ecosystems have demonstrated the importance of activeness of application development based on a common platform. We believe that it is also true that various and numerous IoT applications will release the full potential of Fiesta-IoT technical results in the general IoT market during the project’s exploitation phase. Application developers are interested in tools and services provided by the federation to develop and deploy their applications easily and efficiently. Also, they care about provided mechanism that helps their applications to get more visibility. They are IoT software developers.

• Standardization bodies. Their main activities are developing, coordinating, promulgating, revising, amending, reissuing, interpreting, or otherwise producing technical standards that are intended to address the needs of some relatively wide base of affected adopters. They are not a direct user of the FIESTA-IoT facility—but may see it as a mechanism to increase usage of their standards.

19 Mengxuan Zhao et al., “Global Market Confidence and Certification Specifications”, Deliverable D2.5, December 2015. 20 Mengxuan Zhao et al., “Design of global market confidence programme on IoT interoperability”, D6.1, May 2016



Figure 6: FIESTA-IoT Global Market Confidence Programme Stakeholders

These are the initial stakeholders specified in D2.5 as the target beneficiaries of the Global Confidence Programme. However, as stated above—the FIESTA-IoT offering goes beyond the Global Confidence Programme (including an IoT data marketplace) to target a more general set of stakeholders in a broader set of communities. This generalisation is to more clearly identify potential stakeholders, and provide concrete set of value propositions for each stakeholder.

3.3.2 Market Share

Then we analyse where these types of stakeholders will come from, and we identify if there is a market share for these stakeholder types. Figure 7 first shows the two key communities that FIESTA-IoT Facility will target:

• IoT: SMEs, scientific researchers and industry building IoT applications and systems, standard bodies developing IoT specifications, and open source IoT developers. All of them can be either data consumers using the data and services provided by FIESTA-IoT, or they can be data providers (e.g. a testbed) wanting to join and federate their data within the FIESTA-IoT marketplace.

• Big data: the growing technology fields of big data, data analytics, etc. offer a potential set of customers given central data offering. FIESTA-IoT will target SMEs, scientific researchers, standards, and open source developers in the Big Data and Data Science communities. FIESTA-IoT offers a significant source of unique data that can provide significant benefits to this community. Again, data users and data providers will be targeted as with IoT.



Figure 7: FIESTA-IoT Stakeholders We now look in turn at the potential market share of each category:

1) Scientific Researchers Both academic and industrial researchers seek to publish results in high-ranking journals and conferences. This is driven by the goal of achieving impact (typically measured using citation metrics). This is not restricted to academics—indeed at a top levels systems conference (SOSP, Usenix, Eurosys, etc.) academic papers will be in the minority. One way we can assess the potential market of experimenters is to examine publication submission statistics21 —if we assume that a paper at an experimental venue requires experimentation to validate its hypothesis. While information is incomplete for recent years, even with a small portion of venues there is a large pool of researchers in the fields relevant to FIESTA-IoT. There is a consistent number of submissions to networking (~7000) and systems conferences (~3000). It is clear that research into big data as well as IoT specific research is generating increasing numbers of submissions. While not all researchers would need FIESTA-IoT facilities, it is clear there is a significant number of scientific researchers who could gain value from the experimental facility.

2) IoT Industry

The forecast growth of the IoT market underpins the market importance of IoT software engineering tools. Significant revenue will be spent on the development of IoT systems, and hence there is a significant market for IoT development tools. For example, Gartner states IoT will grow to 26 billion units installed in 2020, while generating incremental revenue exceeding $300 billion for IoT products and services suppliers22. There will also be significant growth across IoT application sectors: consumer electronics M2M connections will top 7 billion in 2023, generating $700 21 http://www.cs.ucsb.edu/~almeroth/conf/stats/ 22 Gartner Says Smart Cities Will Use 1.1 Billion Connected Things in 2015, http://www.gartner.com/newsroom/id/3008917



billion in annual revenue23. According to Nelson Hall, the overall software testing market size is going to be $34 bn by 2017. Gartner predicts that the worldwide discrete software testing market spending is to be increased by 14 % CAGR with product testing growing at the rate of 9.1 % and application testing at 15.3 %24. Finally, IoT developers identify interoperability as the second most important development challenge to overcome (2016 IoT developers’ survey25)—leading to a growing market for interoperability framework: the IoT middleware market is predicted to be worth 12,000 million USD by 202026.

3) Open Source Communities

The open source community offers a large community of potential users: GitHub has approximately 35 million software repositories and 14 million users27, with Sourceforge there are 325,000 projects, and Ohloh 550,000 projects28. There are also emerging and growing domain specific open source communities e.g. Eclipse IoT29 where FIESTA-IoT open source tools to access the FIESTA-IoT facility could grow a dedicated IoT semantic data alignment tools and testing software.

3.4 Data Consumer Value Proposition

Figure 8 shows the value proposition of FIESTA-IoT to the data consumer. For the customer segment model (to the right) we identify the elements: Customer Jobs: Why should a data consumer want FIESTA data – what do they want to get done using FIESTA-IoT:

• To build IoT or Big data applications using heterogeneous data sources that includes real-time data from real running data collection deployments.

• To scale-up their technology usage of data, to include geographically distributed and remote data sources. They want to increase the number of data sources, and they want to use real data that is heterogenous and crosses IoT silos. For example, evaluating if a smart city application operates effectively in multiple city deployments.

• To promote their IoT or big data software/product/technology to a community of users in the FIESTA-IoT data marketplace.

23 Consumer Electronics M2M connections will top 7 billion in 2023, generating USD700 billion in annual revenue, https://machinaresearch.com/news/press-release-consumer-electronics-m2m-connections-will-top-7-billion-in-2023-generating-usd700-billion-in-annual-revenue/ 24 HCL Technology news, “Changing trends of software testing market”, https://www.hcltech.com/blogs/changing-trends-software-testing-market 25 IEEE. IoT Developer Survey 2016. http://iot.ieee.org/images/files/pdf/iot-developer-survey-2016-report-final.pdf 26 Markets&Markets.com, “Internet of Things (IoT) Middleware Market worth 11,575.5 Million USD by 2020”, http://www.marketsandmarkets.com/PressReleases/iot-middleware.asp 27 https://en.wikipedia.org/wiki/GitHub 28 Open Source by numbers: https://www.slideshare.net/blackducksoftware/open-source-by-the-numbers 29 https://iot.eclipse.org/



Pains: What pains do they have?

• Finding available data sources to use, and having access to the types of data that they actually want.

• Finding cross-silo or real-time, real world data sources for testing and developing the product.

• Developing software that interoperates with multiple heterogeneous data sources.

• Testing and certification costs. Testing that software meets IoT and data specifications is expensive in terms of understanding the specification and then developing and testing against it.

Gains: What gains do they want to achieve?

• Access to a unique data offering.

• Increase user/customer base from the FIESTA-IoT community. Early release of their technology to users of the marketplace.

• Minimised software development and testing in terms of accessing and interoperating with heterogeneous data.

Figure 8: Data Consumer Value Proposition

For the value proposition to the left of the model in Figure 8, we identify the following elements: Products and Services:

• Experiment as a Service tools – to easily design and integrate an experiment to consume data from multiple sources.

• Single portal with single sign-on to directly access data source APIs and data sets programmatically—making it easier for developers to integrate their application with FIESTA-IoT data.



• Interoperability testing tools – to execute tests to determine if their software interoperates with FIESTA-IoT APIs and/or data standards and specifications from well-established standards bodies.

Gain creators:

• The services and tools provided (above) save the developer (data consumer) time and cost interacting with the data.

• The federation of data sources (providers) provides a unique data offering (in terms of variety and availability of IoT data types from real world deployments) that the consumer cannot have access to elsewhere.

• The FIESTA-IoT community provides a set of users in the marketplace (both consumers and providers) who can provide initial users (e.g. user testing)

• Interoperable software. The interoperability testing allows data consumers to create software that can utilise data

Pain relievers: • Common Interfaces and APIs that provide uniform access to multiple data

sources, saving development time to access data. • Interoperability testing provided by the FIESTA-IoT Global Market Confidence

Programme – again reducing development time to design and execute interoperability tests.

• Experiment as a Service tool allows non technology developer instant access to use data.

Value Proposition to Data Consumers The Value Proposition Canvas can be described with the simple and clear value offering to data consumers:

• Access to a Unique Data Offering o Heterogeneous domains, semantically aligned data, real-time

data from real deployments. o No comparable offering on the market

• Ease of access to data o No need to find, contact, and integrate data from multiple

sources o Reducing development costs (e.g. in pre-market testing)

• Promotion of technology (FIESTA-IoT Stamp) o Increase market confidence in their technology o Certified as tested with FIESTA-IoT quality data



3.5 Data Producer Value Proposition

Figure 9 shows the value proposition of the FIESTA-IoT Facility to the data producer, who will typically be the owner of an IoT facility or testbed that is producing data from its deployed sensors. For the customer segment, we identify the elements: Customer Jobs: Why should a data producer want to push their data into a data marketplace – what do they want to get done using the FIESTA-IoT facility:

• Marketing. They want to advertise their data to the specific community of users who see value in their data.

• Standards compliance. They want their data to be available conforming to data and API standards in the IoT space, such that the data is easily accessible by data consumers.

Pains: What pains do they have?

• Implementing the APIs and tools to make the data easily accessible to data consumers.

• Qualifying higher value in their data to data consumers; finding consumers paying for their data.

• Justifying test and certification costs. Testing that software meets IoT and data specifications is expensive in terms of understanding the specification;, then developing accordingly and testing against it.

Gains: What gains do they want to achieve?

• Accrue potential revenues from consumers using their IoT data.

• Increase user/customer base from the FIESTA-IoT community. Push early release of their technology to users of the marketplace.

• Minimise software development and testing cost by allowing consumers to easily access and interoperate with their data.

Figure 9: Data Producer Value Proposition



For the value proposition to the left of the model in Figure 9, we identify the following elements: Products and Services:

• EaaS (Experiment as a Service) tools – graphical tools to allow a consumer to use a provider’s data along with other providers’ data from the marketplace.

• Interoperability adaptors. Software able to semantically annotate and align data such that it can be easily integrated into the marketplace.

• Certification services. Data providers can certify their APIs and data compliance with current IoT standards.

Gain creators:

• Marketplace of data consumers who are potential consumers of their data.

• Get revenue from targeted community interested in the provider’s data.

• Minimised development costs from availability of interoperability adaptors and interoperability certification and testing.

• Reduce time to integrate time to the marketplace. Pain relievers:

• No need to develop and maintain GUIs, tools, APIs and documentation for a consumer.

• Helps find data consumers and transform them in paying consumers. • Reducing the cost and time of development, FIESTA-IoT tools guarantees

interoperability from different datasets.

Value Proposition to Data Providers The Value Proposition Canvas can be described with the simple and clear value offering to data providers:

• Access to a community of potential data consumers o Consumers who may be willing to pay for their specific type of

data, e.g. IoT and big data technology developers as described in the data consumer customer segment

o No comparable offering on the market

• Promotion of their data offering (FIESTA-IoT Stamp) o Increase market confidence in their technology o Certified and labelled with FIESTA-IoT quality data



4 BUSINESS MODELS

Currently, like all FIRE projects the FIESTA-IoT Facility receives direct funding from the EC and consortium partners provide in kind contributions. The revenues cover facility development and a small proportion of hardware costs in some cases but not all costs. FIRE exists to optimise the redistribution of public funding by providing a set of reusable facilities and reducing the replication of testbeds within individual RTD projects (i.e. paying for individual projects to create a testbed that already exists). The challenge for a FIRE-funded facility once the project ends (along with the income stopping) is how to generate funding to cover the operating costs of the facility. The obvious target is to move to a payment model with the revenue channels being the direct users of the facility. However, the users of FIRE facilities are not typically paying customers, rather they are either academic or industrial researchers participating in RTD projects. Given this environment, there are three revenue opportunities.

• Direct public funding, e.g. the EC directly funds the operating costs, based upon measurable KPIs (e.g. number of users, use by number of RTD projects, number of high-level publications) and importance of the research being carried out on the facility.

• Indirect public funding. Here a facility receives a significant proportion of revenue indirectly from RTD projects wanting to use the facility.

• Commercial revenues from any form of customer. The FIESTA-IoT projects offering access to unique types of interoperable data is of wider interest to IoT and Big Data technology, rather than simply RTD researchers. Hence, the business scenarios should consider income primarily from commercial sources, with some complement from indirect funding. Direct public funding cannot be justified based upon the targeted operations and services. FIESTA-IoT Facility does not have the same comparable need as something like GEANT. In the following scenarios, we offer potential business models based upon these two types of paying customers.

4.1 IoT Data Marketplace: P2P Broker Service

In this scenario, FIESTA-IoT is a broker platform joining data providers with data consumers:

• Data providers are free to advertise their services and data characteristics within the FIESTA—IoT marketplace.

• Data consumers can search, select and use the data from one or multiple providers available in the marketplace. Date are federated by FIESTA-IoT.

• A transaction is made directly between the provider and the consumer-but a fee is paid to FIESTA-IoT (the broker) for each individual transaction. This is typically a fixed percentage of the transaction, up to a capped amount, e.g. 25 Euros.



This model can be considered similar to Uber/AirBnB—where a resource is accessible to the user via the platform, and it is difficult for the user to get the resource without the platform being in place. Hence, it is more than an advertisement broker. In the case of FIESTA-IoT without the FIESTA-IoT facility there is scarce opportunity for the resource provider to reach the customer and then interact with the data source. Thanks to the interoperability services (semantically aligned data via adaptors) put in place, it is possible for them to share the data on the marketplace such in order to be utilised easily by the customers.

Name #1 IoT Data Marketplace: Pay-per-Use Broker

Description Data consumers pay for each consumption of data e.g. requested observations, or complete data sets. The price for the data is set by the data provider. FIESTA-IoT takes a % of this transaction to cover costs. For example 5%-- however, the percentage would be on a sliding scale to only cover operational costs, as opposed to increase profits.

Pros • Attractive for data providers to have access to paying consumers. • If data is frequently used, there is an accrued revenue potential for

FIESTA-IoT.

Cons • The relationship between consumer and provider may bypass FIESTA-IoT removing royalty fee expectation. Hence, there may be high-use of discovery services but the revenue generated by activities could be evaporated.

• If there are few users, and/or little consumers use, it has a one-off service to get the data they need, then potential revenue will be limited.

• Consumers may not be able to predict how much their experiment will actually cost. And costs may escalate in case of wrong prerequisites – damaging FIESTA-IoT reputation.

Caveats / questions

How to develop the cost models based on different types of data, and how to implement the transaction monitoring to enforce the payment of the fee? FIESTA-IoT value is the creation of a trusted broker (in order that users continue to use FIESTA-IoT). Therefore, the FIESTA-IoT Facility services must ensure the relationship between provider and consumer is strengthen via FIESTA-IoT.

Commercial / existing analogy

Uber. AirBNB. Brokers to available services. Several software licensing schemes.

Viability Low – based on required infrastructure and complexity of handling payments.



4.2 IoT Data Marketplace: Advertisement Service

This scenario is similar to the previous, however in this case FIESTA-IoT is a broker platform acting as an advertisement market paid for by the providers:

• Data providers pay to advertise their services and data within the FIESTA—IoT marketplace. The fees could be based on the duration of the advertisement or the channels used for promotion.

• Data consumers can search, select and use the data from one or multiple providers available in the marketplace through this marketing “PUSH”.

• A transaction is made directly between the provider and consumer. The amount of the transaction is set by the provider, and paid directly by the consumer to the provider.

This model is a traditional broker scenario. It alleviates many of the difficulties of brokering financial transactions. However, it requires a significant number of continuing data consumers to make it worthwhile for a provider to advertise their services.

Name #2 IoT Data Marketplace: Advertisement Service

Description Data providers pay FIESTA-IoT to advertise their data and services in the marketplace. Consumers are free to select and arrange transaction between themselves and the provider.

Pros • Simple model for FIESTA-IoT to manage. • Assuming there is a large consumer base and provider base, revenue

potential is high—as providers will be attracted to pay to advertise.

Cons • At present, the number of providers in FIESTA-IoT is low. If the provider base cannot grow, then revenue potential is remaining low.

• If there are few users, and/or little consumers use, it has a one-off service to get the data they need, then potential revenue will be limited.

Caveats / questions

How do providers pay to advertise? One off joining fee. A monthly/yearly subscription? A percentage based on their periodic revenue increase?


This scenario is analogous to traditional brokers, who help consumers to identify providers, based on their knowledge of the providers and their services description.

Viability Open – based on required infrastructure, and the unknown number of consumers and providers.



4.3 Bait and Hook Subscription Marketplace

The FIESTA-IoT offers a subset of services for free attracting data consumers to the marketplace (bait). Once the consumer has discovered the facility offering they can be hooked in to consume further paying services.

In the FIESTA-IoT facility the bait could be access to the marketplace with free view on the available data providers, and in addition a specified amount of free usage, e.g. 1 week access to a subset of available data sources.

Then the hooked consumer will pay for services via a subscription model. Different levels of subscription will suit different types of consumers:

• Bronze (e.g. 10 Euro a month): Full directory access, Register 10 experiments a month, Access 3 data providers a month.

• Silver (e.g. 30 Euro a month): Full directory access, Register 100 experiments a month, Access 10 data providers a month.

• Gold (e.g. 100 Euro a month): Full directory access, Register unlimited experiments a month, Access unlimited data providers a month.

This model means that FIESTA-IoT has to share revenue with the data providers (to attract them to the marketplace). In this case, it could be a profit-sharing model: each data-provider receives a percentage of the subscription fees based upon the usage of their data by consumers. FIESTA-IoT takes a fixed percentage of the subscription fees to cover operational costs.

Name #3 Bait and Hook Subscription Marketplace

Description Revenue comes from the data consumer only via a subscription model.

Pros • Attractive to data providers to join the facility. • With a strong data offering, data users may be more willing to subscribe

based on fixed and identifiable outgoings.

Cons • Difficult to assess the level of interest in data consumers paying to use the facility. If this level is low, this business scenario will fail.

Caveats / questions

How to fairly distribute revenue, and maintain FIESTA-IoT operating costs? How to set the subscription levels that meet the needs of different user types? Until FIESTA-IoT is in place and used by a large community?


This scenario is slightly analogous to the prevailing Internet business model of advertising, and more closely analogous to cross-selling websites.

Viability High – based on required infrastructure.



4.4 IoT Data Marketplace: P2P Data Sharing Service

This scenario is a variation on the first business scenario where FIESTA-IoT is a broker platform joining data providers with data consumers. In this case there is no currency exchanged between data providers and consumers. Instead, the marketplace is based upon the use of credits:

• If you provide your data to the marketplace you receive credits. Hence, this promotes the sharing of data (e.g. IoT results) from all stakeholders.

• The consumers spend the tokens they have earned to access data. Hence, the more they share the more they can access and use.

This is equivalent to Torrent P2P sharing of resources. However, there is a central hidden element—the FIESTA-IoT facility that must be utilised and paid for. Therefore, in order to generate revenue:

• Data providers are free to advertise their services and data within the FIESTA—IoT marketplace. However, they would pay to increase the visibility of their offering with premium advantages.

• Data consumers may not have data to share, so they could buy credits. FIESTA-IoT receives all payment for credits.

Name #4 IoT Data Marketplace: P2P Data Sharing Service

Description Data consumers and providers share data based upon a credit model.

Pros • Strong model to increase the availability of data provided from multiple sources.

• Model for payment or non-payment to suit different consumer types. For example, scientists could prefer data contribution to avoid costs. Commercial partners may prefer to pay for credits for what they need.

Cons • While a good model for low cost testbeds and data providers – a more expensive to maintain commercial data provider may not recover their costs or make a profit via the marketplace.

• If providers do not consume data afterwards, they may see no benefit in earning credits.

Caveats / questions

A mechanism to cash in credit will be required.

However, this may be very difficult to achieve – given that the amount of data provided may be worth more than any currency put into the marketplace.


P2P, BitTorrent

Viability Low – only really suited to the shared experiment model where each stakeholder consumes and provides data.



4.5 Certification and Interoperability testing service

This scenario describes the business model for the Global Market Confidence Programme, where IoT software developers, testbed providers, and experimenters use the FIESTA-IoT facility to support their interoperability testing against IoT specifications and data standards. They target to obtain certification that their technology complies with current market standards. There are two revenue opportunities in the model:

• Technology providers and application developers pay for the interoperability testing and certification services.

• Training and consulting services are provided (and paid for) in order to help technology developers to address interoperability issues and to achieve the certification that their technology comply with standards.

This scenario is close to the certification providers e.g. the British Standards Institute (BSI) group30 or ETSI (European Telecommunications Standards Institute). A user is willing to pay for a BSI certificate as it is consumer recognisable stamp of approval. FIESTA-IoT certification services must aim to achieve such a level of recognition to attract users of the service.

Name #5: Certification and Interoperability testing service

Description The Global Market Confidence Programme provides a testing and certification service for developers.

Pros This model offers a high value added service, which should imply high profit margins. The service is provided only by FIESTA-IoT facility (not data providers) and needs limited resources to provision and operate.

Cons Specifications/Standards change over time and there may be high costs in maintaining up to date certification services.

Caveats / questions

What are the optimal certificates amount that users will pay to achieve?


This scenario is analogous to BIS certification.

Viability High. The initial cost is covered by the development of the Global Market Confidence Programme as part of the project.

30 https://www.bsigroup.com/en-GB/our-services/certification/

http://www.etsi.org/standards



4.6 Initial Analysis

It is obvious that FIESTA-IoT should focus on providing business models for both the IoT Data marketplace and the Certification testing services. As the project develops, we will analyse which of the previously described revenue scenarios best fits the current FIESTA-IoT deployed services. We will identify the stakeholders who will utilise them. The business models should be shaped based upon success in the following directions:

• Target commercial customers willing to pay for both data services and certification services.

• Identify the optimum FIESTA-IoT Facility architecture that will offer strictly the required products and services with minimized overheads.

• Look into the integration of business scenarios, to create revenue channels (to FIESTA-IoT) from both data consumers and data providers sides.

5 FIESTA-IOT FACILITY OPERATION AND ORGANISATION

In this section, we investigate the operation models for a federation of data providers so that the previously mentioned business models (based upon the value proposition) can be realised. This is essentially looking at the services that the facility should provide and be in charge of. This feedback will inform the technical architecture of the project in order to be aligned with the business models. First, we look at typical federation services.

5.1 Federation Services

FIRE (Future Internet Research and Experimentation) has made significant advances in the development of Experiment as a Service (EaaS) and the underlying experiment lifecycle tools. Notably, these align with similar initiatives such as GENI31 in the USA and common globally deployed standards which are emerging. The experiment lifecycle is broken down into the following important stages.

1) Discovery: the experimenter searches for testbeds and resources that match their requirements. For FIESTA-IoT an IoT experimenter searches for data providers that have their data requirements.

2) Reservation: making the resources available to the experimenter at a required time. The data provider API is made available for the experimenter to use for a period of time.

3) Provisioning: ensuring that the resources are in place (‘started up’) and have the required configuration (e.g. a virtual machine has a specified OS and software installation). This is not particularly relevant for IoT because the data does not need to be provisioned per user.

31 https://www.geni.net/



4) Control: usage of resources during the experiment, allowing querying and modification of each resource’s state. In FIESTA-IoT this is the querying and usage of the data.

5) Measurement: Measurement is critical to achieve validation by experimentation; such measurements have the objective of showing an experiment’s results to be: reliable; repeatable (when run on the same testbed configuration); reproducible (in a different testbed under the same conditions); and verifiable (when compared against a reference model). To obtain and evaluate measurements it is necessary to monitor: i) the running experiment itself to capture the experiment measures (e.g. packet round-trip time), and ii) the underlying testbed infrastructure to capture the experimental conditions (e.g. the network properties such as packet loss). The two can be analysed in order to draw conclusions from the results of the experiment.

6) Reporting: The final result of the experiment prepared and returned to the experimenter in a formatted document.

Experimentation. FIRE has largely focused on networking research and virtualised resources, e.g. virtual machines, network routers, etc. There has been little consideration of how data-oriented experiments should be carried out across testbeds, and how the experiment lifecycle needs to be adjusted for this purpose. The objective of FIESTA-IoT is to advance the state of the art in data and IoT testbed experimentation; and hence, there is a need to analyse the fitness for purpose of the current state of the art, and what IoT EaaS should look like.

Technology testing. FIESTA also considers the need for standards-based interoperability testing of technologies as a method to attract users to the federations e.g. providing a useful service such as standards compliance; hence, FIESTA must also consider EaaS with real world standards.

Fed4FIRE offers robust experimentation tools and services, but is not suited to data or IoT resources. The alternatives are more lightweight and closer to market technologies—yet they are not suited to the experimental process. FIESTA must consider how the two can be realistically aligned without significant development of new federation tools and services. Hence the following are a set of initial recommendations:

• Lightweight federation focused on IoT resources utilized by experimenter. It must be quick and easy for a data provider to join; and an experimenter to create an experiment.

• Provide EaaS tools and lifecycle that follow a traditional approach – but is flexible to the heterogeneous demands on an IoT experimenter. Discovery: utilise IoT domain models to describe resources. Utilise IoT discovery technologies to find resources.

• Control and measurement: Use standard-based REST APIs e.g. NSGI and OneM2M technologies to interact with the resources (even those registered with SFA)

• Reporting: Align with linked data and IoT experimentation and visualization tools.



5.2 Federation Models

FedSM32 is investigating service management in federated e-Infrastructures and cloud computing facilities. They have defined a number of federation models that illustrate how the stakeholders interact with services, and how these services are managed. This is highly relevant for federation in FIESTA-IoT. Essentially, the stakeholders can be broken down into data consumer, data provider and federator (this would be the FIESTA-IoT facility). We can simply model their interactions. Hence, consumers can use certain services of the individual provider directly, or they can interact with the federator who then interacts with the provider on their behalf. Figure 10 illustrates the potential relationships:

• A data consumer only interacts with the data provider by an API that is certified by FIESTA-IoT. This is termed as a certification-only federation.

• A data consumer interacts with FIESTA-IoT for some services, and then directly with the data provider for further interactions. This is a loose federation model.

• A data consumer interacts with FIESTA-IoT only, and then FIESTA-IoT interacts wholly with the provider on their behalf. This is a fully integrated federation model.

Figure 10: Federation Models

5.2.1 Federation Services

The following is a list of typical services defined in the FedSM service operation standards. We analyse these with respect to the current FIESTA-IoT technical architecture to determine how they are delivered. We discuss only those services relevant to the delivery of IoT data (for example resource allocation is not a service in FIESTA-IoT).

32 http://fitsm.itemo.org/fedsm-project



• Authentication: FIESTA-IoT handles all authentication credentials and

decisions for data consumers and data providers.

• Authorisation: FIESTA-IoT handles all authorisation decisions for data consumers and data providers.

• Operations. FIESTA-IoT is responsible for maintaining the operation of the marketplace; the data providers are responsible for the operation of their data access APIs.

• Maintenance. FIESTA-IoT is responsible for maintaining central facility; the data providers are responsible for their own maintenance.

• Monitoring. FIESTA-IoT monitors usage of data APIs.

• Billing. To be determined by the selected business model.

• Execution. FIESTA-IoT is in charge of the execution of an experiment where a data consumer utilises data from the providers.

• Support. FIESTA-IoT provides front line support for the market place activities only. A consumer needs to contact a provider directly if there is an issue with their service.

FitSM define a set of models around these service provisions; these can be analysed to see which best fits the needs of the FIESTA-IoT federation model.

5.2.2 Invisible Co-ordination

Here, the role of the FIESTA-IoT is at a minimum and it exerts very little control over the federation’s behaviour. The federator enables federation but does not participate in the interactions between the consumer and the providers. This is highlighted in Figure 11 where the hollow arrow represents the interaction of a facility provider with



the federator to utilise federation services that enable its participation in the federation; for example:

• Certification that the data provider provides service endpoints that comply with predefined communication standards and protocols.

• Certification that common APIs are implemented to comply with interface specifications.

• Provision of common vocabularies that are employed at the service endpoints (typically in terms of a common semantic understanding of the data exchanged—hence the federation may provide ontologies and data schemas).

• Management of identity provision, e.g. the allocation of a set of IDs from a global space to an individual facility.

The major interaction is between the consumers and the individual data providers. This interaction is highlighted by the filled arrow and is facilitated because of the enabling actions of the federator e.g. determining standards and protocols to enable interoperation.

Figure 11: Invisible Co-ordination Federation Model

5.2.3 Advisor

The main purpose of the “Advisor” scenario (illustrated in Figure 12) is to help the consumer find the best data provider for his/her purposes. This is complementary to the “Invisible Coordination” scenario in terms of the technical certification to support interoperation remains. Experimenters interact directly with the providers to control experiments. The scenario is extended so that the consumer also interacts with FIESTA-IoT. They send their experiment requirements to FIESTA-IoT who analyses them against the information about the individual providers. The individual providers must exchange information about their service capabilities with FIESTA-IoT (these will typically follow a common vocabulary and data scheme).



FIESTA-IoT makes a recommendation for the most appropriate data providers that will meet the requirements. Armed with this information, the consumer is able to begin the deployment of his experiment. Crucially, runtime operation of FIESTA-IoT is only to support users searching for suitable providers. Hence, FIESTA-IoT behaves as a recommender (or an “Introduction agency”) only. Once the providers have been recommended, the consumers make choices and interact directly with the providers from that point forward.

Figure 12: Advisor Federation Model

5.2.4 One Stop Shop

“One Stop Shop” provides additional business services, for example reservation, SLAs, accounting, and billing. In general terms, this model provides more co-ordination of the contract agreements. This is illustrated in Figure 13. FIESTA-IoT again provides all the support to find and acquire the right to use the data, e.g. discovery and usage. However, this time there is added support through financial clearing. The pricing must be discussed by FIESTA-IoT in consultation with the different facilities. Again, as with previous scenarios, the experimenter invokes services directly on the infrastructures. The need for contracts or SLAs between FIESTA-IoT and data providers may be necessary. In addition to this scenario, FIESTA-IoT provides added value services to the data providers (e.g. handling payments and monitoring of SLAs). Thus, these need to be described in contracts or SLAs, as well as the information to be provided to the federator. Hence, an important relationship in this scenario is the provisioning of usage information to FIESTA-IoT that can be used to determine the bill for the consumers.



Figure 13: One Stop Shop Federation Model

5.2.5 Integrator

The final and most complex scenario is “Integrator”, which is shown in Figure 14. This scenario has all the aspects of the previous scenario (“One Stop Shop”), but in addition it deals with service invocation. FIESTA-IoT takes full control of performing an experiment. A consumer will provide a full experiment description. This description will contain details of the data they want to use, what they wish to measure and how they want to measure it. FIESTA-IoT will, then, control all aspects of executing the experiment by calling the providers on their behalf, collecting the monitored data and providing the results of experiments back to the consumer. Importantly, this model differs from the previous in that the consumer does not deal directly with the provider, but only with FIESTA-IoT.

Figure 14: The Integrator Federation Model



5.2.6 Analysis

The current service offering of the FIESTA-IoT facility is based upon a centralised model of services. The data access and certification services are all accessed through a single portal, using single credentials provided by FIESTA-IoT. This suggests that the integrator model will be the simplest model to transform the technical architecture into the federation model. Further, this choice of model also aligns with the investigated business scenarios: the IoT data marketplace models propose a centralised model to control access. However, variations in the scenarios about billing are necessary:

• In some models, billing is fully handled by FIESTA-IoT and the revenue is shared to providers.

• In some models, billing is direct between. Hence, the integrator model may need to be altered to add which ever billing relationship is chosen. This will then inform new technical requirements of the FIESTA-IoT platform:

At present no billing services are developed for the architecture. Billing, Transaction and Usage services should be investigated as to how they can be included technically in the architecture.

6 TOTAL COST OF OWNERSHIP

“TCO is a metric to define and analyse the overall cost of keeping a product or service up and running. This includes total cost of acquisition and operating costs.”

In this section, we provide an initial analysis of the running costs of the FIESTA-IoT facility. There are three main costs:

• The cost of running and maintaining the technology services that provision the data marketplace and certification services. This cost is essentially the cost of running the virtual machines that host the deployed services, the cost incurred by the datacentre hosting the servers and the cost of admin staff who maintain these machines and services.

• A Support Level Agreement is in place with the datacentre to guarantee 24/24 hours and 7/7 days availability of the machines and servers.

• The general support costs for helping users of the facility who may encounter. This may include first-line support for direct issues identified by consumers and producers, and support for developers using the services. For example, helping data providers integrate their platform with the marketplace.

• General marketing costs to promote and advertise the FIESTA-IoT facility.



6.1 Operational Costs

At present, the FIESTA-IoT facility is operated to run across three virtual machines with the following configurations:

1. 8Gb RAM, 4 CORES (vCPU), 80Gb Disk space 2. 16Gb RAM, 8 CORES (vCPU), 160Gb Disk space 3. 32Gb RAM, 12 CORES (vCPU), 2000Gb Disk space

We, then, estimate the data usage of the facility. At a low level this is 20000Gb of data transferred in and out of the services operating on the VMs. However, FIESTA-IoT is data intensive and therefore this could reach significantly higher levels e.g 99999Gb a month. To demonstrate these costs in a commercial facility e.g. Amazon Web Services, we use the AWS calculator to illustrate potential monthly operational costs of running the facility of 3VMs above with the data usage:

Data Profile Running Costs ($)

20000GB in/out a month 3280

99999GB in/out a month 9900

These costs illustrate the potential unsustainable overheads of maintaining a centralised facility for managing large quantities of data. As such, we recommend that the facilities consider federation models where the data consumer and provider interact directly to exchange the data, as opposed to it being filtered through the FIESTA-IoT facility.

6.2 Maintenance Costs

The costs of supporting and maintaining the operation of the FIESTA-IoT facility is based upon the staff costs required. Here we illustrate in terms of FTE (full time equivalent) staff needed to perform particular tasks.

• Support for data providers and users (joining) the federation. Help developers implement the required APIs and test that a data provider has integrated correctly.

o Estimate 1.5 FTE software developer

• Maintenance of tools and services by a system administrator. Provide day to day management of the Virtual Machines.

o Estimate 0.5 FTE system administrator

• Helpdesk operations providing first level support to help users with problems with the facility.



o Estimate 0.5FTE IT helpdesk

• Promotion and marketing of the FIESTA-IoT facility to attract new customers o Estimate 0.25 FTE marketing professional

The costs of these personnel will be dependent on the organisation taking the facility forward, and the countries that such management will operate within. Depending on the number of countries gathered together in the FIESTA-IoT Facility, some redundancy may be necessary for the system administrator and helpdesk. This would add 1 FTE acting as back-up.

7 SUMMARY & NEXT STEPS

7.1 Business Canvas Model In this subsection, we summarize the current position of the business model with the Ostewalder canvas seen in Figure 15. This summarizes all the elements discussed in this report and presents the findings in the canvas.

Figure 15: FIESTA-IoT Business Model Canvas

7.2 Next Steps

7.2.1 Value proposition and stakeholder feedback

In this deliverable, we have identified the key value propositions. The next step is to survey the project’s experimenters and testbeds to analyze, prioritize and better focus this delivered value. That is, concentrate exactly on what the value to be



delivered should be. For this purpose, we will utilize a set of surveys and questionnaires directed at the current users of the facility. Namely, the data consumers and providers who come from both the project and the ongoing open calls. The larger objective of these surveys is to refine the sustainability model behind the post-project federation and prioritize its tools and services offered on top of the underlying data provider. As a side-benefit, this feedback analysis of perceived value is also useful in influencing the stakeholder engagement, communication and marketing activities of the facility. Hence, we will develop questionnaires about the value derived from the facility; and then ask users from the various open calls to respond with their opinions.

7.2.2 Customer Relationship Strategy

It is also necessary to build the customer relationship strategy of FIESTA-IoT in order to build and sustain a community of users. We define this strategy as follows in Figure 16.

Figure 16: Transitions in governance and customer relationships

The phases are described below:

• Pre-project conceptualisation: concerned with defining the concept of an IoT data marketplace and getting all stakeholders to agree to this offering. The result of this phase is a public funded Project to implement the facility.

• Project driving experiments: concerned with implementing the facility in terms of technical and operational aspects. There are no Facility Users but driving experiments that define requirements and test cases to validate the facility offerings. The result of this phase is the 1st operational facility available for Facility users. In terms of FIESTA-IoT this is the platform made available to the winners of the 1st Open Call.

• Project open call experiments: concerned with selecting and executing a set of experiments funded by the facility. The Facility Users are paid to run



experiments. Facility Users help facility providers understand how to improve the service offering by testing software and operational policies. The result of this phase is an enhanced facility that has been tailored to meet the needs of users.

• Post-project sustainability: concerned primarily with continuing facility services. Exploitation agreements between partners must be established to define how FIESTA-IoT foreground can be used and post project governance structures implemented. Project partners must align themselves with operational roles and commit appropriate levels of resources to sustain activities.

To be successful, the project has to manage the transition between the different phases. Each place demands on governance in terms of technical and operational requirements for the facility. For example, transitioning from funded open call experimenters to customers requires the project to deal with access to the facility by third parties.

FIESTA-IoT 2017

Sustainability and Business Plan V1 - Eprints · 2020-01-31 · HORIZONS 2020 PROGRAMME Research...

Documents

Transcript of Sustainability and Business Plan V1 - Eprints · 2020-01-31 · HORIZONS 2020 PROGRAMME Research...