Principles on evaluating FIWARE relevance for Phase 3 proposals

Key Assumption Phase 3 Accelerators sub-granted projects ARE part of FIWARE  FIWARE relevance of submitted proposals must be assessed! Non FIWARE relevant proposals to be rejected

FIWARE value proposition Integration of different Generic Enablers – Using 1 GEI is of limited interest: similar functionality can be obtained from other OS projects – Value emerge from several GEIs integration Rapid deployment: Final applications and GEIs to be deployed in the FIWARE Cloud – Allow developers to focus on their core business – Exceptions are possible (e.g. Privacy concerns), but should be well justified – The only deployment of an application in the FIWARE Cloud brings to rejection

FIWARE Relevance evaluation Step 1: FIWARE screening – Used as 1 st step in funnel processes – Based on simple metrics – Still require FIWARE knowledge from evaluators Step 2: in-depth analysis – Per enabler analysis points (based on FIWARE detailed questionnaire as already posted in Basecamp)

FIWARE Screening evaluation principles (1/4) 1. No enablers used > disqualified (see point 5 below for exceptions) 2. One enabler used > acceptable but this must be strongly documented as in the following: 2.1 The GE must be tightly integrated with the solution of the organisation, i.e. should implement a new functionality which is a clearly value add for the organisation business. An adoption for a minor or irrelevant functionality for the sake, disqualifies the proposal 2.2 The usage of just one GEI such as IdM or Access Control, disqualifies the proposal 2.3 Justification of why adding this GE rather than 3^rd party solutions should be provided

Rapid screening overview (2/4) 3. Several GEIs used > acceptable and recommended 3.1 The proposers shall provide a draft architecture of the intended solution showing clearly interactions between the various GEIs and eventually third party or owned software. 3.2 Use of several disconnected enablers is possible. Then each should be justified as for case 2 above 3.3 Preferred solution is the use of several integrated enablers.

Rapid screening overview (3/4) 4. Application hosted by the FIWARE Cloud -> acceptable and recommended 4.1 The proposers should make use of the FIWARE Cloud at its maximum potential, i.e. their application is deployed in the FIWARE Cloud while at the same time using a number of GEs which are instantiated in the FIWARE Cloud too. 4.2 It is possible to use an hybrid approach, i.e. part of the application running on the FIWARE Cloud and part locally. A part of the obvious cases of GEIs running on the browser (e.g. 3D GEIs), and on sensors (e.g. IoT), this might be due for particular reasons (e.g. data privacy) which must be justified 4.3 The only deployment of the application in the FIWARE Cloud disqualifies the proposal (see point 5 below for exceptions)

Rapid screening overview (4/4) 5. Proposal hides FIWARE value -> acceptable 5.1 the proposal might have some not well expressed FIWARE added values which the FIWARE evaluator can asses through, for instance, the architecture provided. These can be: - GEIs used but not integrated among them when this is clearly possible - GEIs not used but clearly usable If the above applies, the Accelerator shall recommend to the proposers the adoption of the needed GEI(s) and then clearly monitor this in the evolution of the project. If for whatever reasons the project is not able to take on board such recommendations the project shall be terminated (this according to the Accelerator model). This point 5 if very much clear and accompanied by an application which has also high business impact potential supersedes points 1 and 4.3 above.

In-depth analysis (Step 2) To be based on FIWARE usage questionnaire: ware.org/fiware-usage- questionnaire/ ware.org/fiware-usage- questionnaire/

Thanks!