We use proprietary and third party's cookies to improve your experience and our services, identifying your Internet Browsing preferences on our website; develop analytic activities and display advertising based on your preferences. If you keep browsing, you accept its use. You can get more information on our Cookie Policy
Cookies Policy
FIWARE.OpenSpecification.Apps.BusinessModeler - FIWARE Forge Wiki


From FIWARE Forge Wiki

Jump to: navigation, search
Name FIWARE.OpenSpecification.Apps.BusinessModeler
Chapter Apps,
Catalogue-Link to Implementation [ N/A]
Owner iMinds, Camille Reynders



Within this document you find a self-contained open specification of a FIWARE generic enabler, please consult as well the FIWARE Product Vision, the website on http://www.fiware.org and similar pages in order to understand the complete context of the FIWARE platform.


Copyright © 2013 by iMinds. All Rights reserved.

Legal Notice

Please check the following Legal Notice (implicit patents license) to understand the rights to use these specifications.


The Business Modeler GE is a part of the Applications/Services ecosystem and provides a graphical tool to business experts for creating and evaluating high-level business models. It allows them to get an estimation of the profitability of a certain model and define value and money streams quickly and transparently.

This component will integrate tightly with the Business Calculator which allows for the calculation of costs and adds simulation capabilities.

The Business Modeler GE uses a superset of XMI and UML metadata languages to describe a business model and all its additional relevant metadata:

  • Document meta-data: Model description, authors, creation date, et cetera.
  • The business elements and their relations, with descriptive values
  • Comments and annotations, providing additional detailed information to document design decisions and clarify intent.
  • The values necessary for the graphic representation and layout of the business elements

Basic Concepts

Target Usage

Market place and store owners, service providers and application developers that will be active on the Future Internet will need to be able to work out new business models to calculate revenue and cost streams in a distributed, asynchronous manner. Due to the rapid progress of technology and heavily fluctuating global economies these models need to be easily adjustable and centrally accessible to all of the relevant actors of the business models. The Business Modeler GE, in conjunction with the Business Calculator, Repository and RSS GE's, will be part of FI-WARE's contribution towards presenting internet based business networks the modalities to easily and timely adapt to an ever-changing market on a strategic level.

Target Users

Business experts interested in creating business models to document and facilitate high-level strategical decisions.


In an initial phase the different actors sit together and draw out in a lively discussion one or several variants for a business model. In this phase, building a business model will consist of determining (i) the activity(ies) played by every actor and the relationships between these activities and (ii) the related costs and revenues. Key to this is the definition of the type of flows (money, knowledge, products, etc.) that will be exchanged between those actors. The main focus in this work is aligning the view of all parties around the table to proceed to a clear delimitation of the roles and responsibilities.

All actors in the business model constructed in the first step will have to perform some tasks and invest to make the service work. In the initial business model, this work and the associated costs have not been detailed yet. In the second phase, different more technical experts can construct an estimation model for the costs of their part in the business model. This can happen in an isolated manner, in which the technical experts each work on their own model and do not have to interact directly. The result of this step is a set of cost estimation models for each of the elements in the business model.

The Business Modeler GE supports the first step in the modeling process, allowing easy and intuitive creation of high-level business models. The Business Calculator is used for creating the estimation models and calculate the simulated results.


An explicit formal specification of the various business elements represented in the Business Modeler GE is described in the following ontology:

Business model value network ontology

The Business editor ontology has the following elements :

  • Actor: an organisation (commercial or non-commercial) or type of individual (e.g. a consumer)
  • Activity: a process that is performed by an actor in the context of the business model, e.g. share revenue.
  • Customer need: the business model can address a customer need.
  • Driver: a quantity that drives the outcome of the business model, e.g. number of customers.
  • Relationship: indicates an interaction between two activities and therefore between two actors. We discern the following types:
  • Payment: a monetary relationship.
  • Results: either a service or data or a physical good that result from the payment
  • Multiplicity: allows the modeller to indicate that a relationship is not executed just once, but more than once.

Business Modeler GE Architecture

The Business Modeler GE is part of the Business Framework within the FI-WARE platform and integrates with the Business Calculator, Repository and RSS GE's

Business Modeler GE in the context of the FI-WARE platform

The Business Modeler GE is a responsive single-page web application created in HTML5, CSS3 and JavaScript, accessible through a common web browser. All business model creation and rendering is executed client-side. It allows users to save business model documents (XML) to their hard drives and subsequently open them for further editing. They are also presented with the possibility to load, use and upload business model (templates) from and to the Repository GE.

Revenue sharing activities are an integral part of business models; users of the Business Modeler GE can download existing RSS models from the Repository GE to use them in their business models. All cost and revenue sharing calculations are performed by the Business Calculator GE (using an adapter to connect to the RSS GE) and are requested through standard asynchronous REST API calls with XML as a messaging format.

Business Modeler GE Architecture

Main Interactions

The Business Modeler GE mainly interacts with the Business Calculator and Repository GE's, through service request calls to their RESTful API's.

Business Modeler GE and Business Calculator sequence diagram

After the Business Expert finishes creating a business model and uploads it to the Repository, a Technical Expert is notified that (a) certain business element(s) require(s) more technical refinement and detailing. The Technical Expert then uses the business element calculation model editors to supply this information and provide detail on revenue or cost calculations inside the business model.

The Business Expert requests the business element calculator to calculate and simulate cost and revenue streams using the updated business model. When calculation results are avaible the business expert uses the Business Modeler GE to visualise the results.

Business model management

See above figure, the Business Modeler GE retrieves and stores business models from and to the Repository GE.

Cost calculations

See above figure, the Business Modeler GE communicates with the Business Calculator for the calculation and simulation of costs.

External calculator integration

The Business Modeler GE can connect to external calculators through the use of calculator adapters. An example of this is the RSS GE which is used to calculate revenue streams for a business model.

Business Modeler GE and RSS sequence diagram

The Business Expert is presented with a list of RSS models registered to the Repository, which she can use in her business model. If the RSS model needs input parameter refinement it is sent to a Technical Expert whom, using the RSS model editor (part of the RSS GE), details the RSS model and its parameters. To simulate the revenue sharing an adapter (part of the Business Calculator) connects to the RSS GE's RESTful API and feeds it with the necessary data to obtain a calculation. These results are translated to a business model compatible format and are visualised in the Business Modeler GE.

Basic Design Principles

The Business Modeler GE provides a webbased GUI with a focus on ease-of-use, possible extendability and future portability, using the latest technologies and paradigms to ensure a maximum reusability potential.

Special attention is being given to the encapsulation of 3 domains:

  1. user interaction mechanisms
  2. concrete model construction
  3. model visualisation

For the FI-WARE reference application a concrete implementation of these 3 domains is focused on a web-based asynchronous client-side single-page application to be viewed in a web browser and with typical desktop input devices. This separated approach however facilitates easy porting of the application to other contexts. E.g. a native mobile application, a server-side static multi-page application or a desktop application.

Detailed Open Specifications


Terms and definitions

This section comprises a summary of terms and definitions introduced during the previous sections. It intends to establish a vocabulary that will be help to carry out discussions internally and with third parties (e.g., Use Case projects in the EU FP7 Future Internet PPP). For a summary of terms and definitions managed at overall FI-WARE level, please refer to FIWARE Global Terms and Definitions

  • Aggregator (Role): A Role that supports domain specialists and third-parties in aggregating services and apps for new and unforeseen opportunities and needs. It does so by providing the dedicated tooling for aggregating services at different levels: UI, service operation, business process or business object levels.
  • Application: Applications in FIWARE are composite services that have a IT supported interaction interface (user interface). In most cases consumers do not buy the application, instead they buy the right to use the application (user license).
  • Broker (Role): The business network’s central point of service access, being used to expose services from providers that are delivered through the Broker’s service delivery functionality. The broker is the central instance for enabling monetization.
  • Business Element: Core element of a business model, such as pricing models, revenue sharing models, promotions, SLAs, etc.
  • Business Framework: Set of concepts and assets responsible for supporting the implementation of innovative business models in a flexible way.
  • Business Model: Strategy and approach that defines how a particular service/application is supposed to generate revenue and profit. Therefore, a Business Model can be implemented as a set of business elements which can be combined and customized in a flexible way and in accordance to business and market requirements and other characteristics.
  • Business Process: Set of related and structured activities producing a specific service or product, thereby achieving one or more business objectives. An operational business process clearly defines the roles and tasks of all involved parties inside an organization to achieve one specific goal.
  • Business Role: Set of responsibilities and tasks that can be assigned to concrete business role owners, such as a human being or a software component.
  • Channel: Resources through which services are accessed by end users. Examples for well-known channels are Web sites/portals, web-based brokers (like iTunes, eBay and Amazon), social networks (like Facebook, LinkedIn and MySpace), mobile channels (Android, iOS) and work centers. The access mode to these channels is governed by technical channels like the Web, mobile devices and voice response, where each of these channels requires its own specific workflow.
  • Channel Maker (Role): Supports parties in creating outlets (the Channels) through which services are consumed, i.e. Web sites, social networks or mobile platforms. The Channel Maker interacts with the Broker for discovery of services during the process of creating or updating channel specifications as well as for storing channel specifications and channeled service constraints in the Broker.
  • Composite Service (composition): Executable composition of business back-end MACs (see MAC definition later in this list). Common composite services are either orchestrated or choreographed. Orchestrated compositions are defined by a centralized control flow managed by a unique process that orchestrates all the interactions (according to the control flow) between the external services that participate in the composition. Choreographed compositions do not have a centralized process, thus the services participating in the composition autonomously coordinate each other according to some specified coordination rules. Backend compositions are executed in dedicated process execution engines. Target users of tools for creating Composites Services are technical users with algorithmic and process management skills.
  • Consumer (Role): Actor who searches for and consumes particular business functionality exposed on the Web as a service/application that satisfies her own needs.
  • Desktop Environment: Multi-channel client platform enabling users to access and use their applications and services.
  • Front-end/Back-end Composition: Front-end compositions define a front-end application as an aggregation of visual mashable application pieces (named as widgets, gadgets, portlets, etc.) and back-end services. Front-end compositions interact with end-users, in the sense that front-end compositions consume data provided by the end-users and provide data to them. Thus the front-end composition (or mashup) will have a direct influence on the application look and feel; every component will add a new user interaction feature. Back-end compositions define a back-end business service (also known as process) as an aggregation of backend services as defined for service composition term, the end-user being oblivious to the composition process. While back-end components represent atomization of business logic and information processing, front-end components represent atomization of information presentation and user interaction.
  • Gateway (Role): The Gateway role enables linking between separate systems and services, allowing them to exchange information in a controlled way despite different technologies and authoritative realms. A Gateway provides interoperability solutions for other applications, including data mapping as well as run-time data store-forward and message translation. Gateway services are advertised through the Broker, allowing providers and aggregators to search for candidate gateway services for interface adaptation to particular message standards. The Mediation is the central generic enabler. Other important functionalities are eventing, dispatching, security, connectors and integration adaptors, configuration, and change propagation.
  • Hoster (Role): Allows the various infrastructure services in cloud environments to be leveraged as part of provisioning an application in a business network. A service can be deployed onto a specific cloud using the Hoster’s interface. This enables service providers to re-host services and applications from their on-premise environments to cloud-based, on-demand environments to attract new users at much lower cost.
  • Marketplace: Part of the business framework providing means for service providers, to publish their service offerings, and means for service consumers, to compare and select a specific service implementation. A marketplace can offer services from different stores and thus different service providers. The actual buying of a specific service is handled by the related service store.
  • Mashup: Executable composition of front-end MACs. There are several kinds of mashups, depending on the technique of composition (spatial rearrangement, wiring, piping, etc.) and the MACs used. They are called application mashups when applications are composed to build new applications and services/data mash-ups if services are composed to generate new services. While composite service is a common term in backend services implementing business processes, the term ‘mashup’ is widely adopted when referring to Web resources (data, services and applications). Front-end compositions heavily depend on the available device environment (including the chosen presentation channels). Target users of mashup platforms are typically users without technical or programming expertise.
  • Mashable Application Component (MAC): Functional entity able to be consumed executed or combined. Usually this applies to components that will offer not only their main behaviour but also the necessary functionality to allow further compositions with other components. It is envisioned that MACs will offer access, through applications and/or services, to any available FIWARE resource or functionality, including gadgets, services, data sources, content, and things. Alternatively, it can be denoted as ‘service component’ or ‘application component’.
  • Monetization: Process or activity to provide a product (in this context: a service) in exchange for money. The Provider publishes certain functionality and makes it available through the Broker. The service access by the Consumer is being accounted, according to the underlying business model, and the resulting revenue is shared across the involved service providers.
  • Premise (Role): On-Premise operators provide in-house or on-site solutions, which are used within a company (such as ERP) or are offered to business partners under specific terms and conditions. These systems and services are to be regarded as external and legacy to the FIWARE platform, because they do not conform to the architecture and API specifications of FIWARE. They will only be accessible to FIWARE services and applications through the Gateway.
  • Prosumer: A user role able to produce, share and consume their own products and modify/adapt products made by others.
  • Provider (Role): Actor who publishes and offers (provides) certain business functionality on the Web through a service/application endpoint. This role also takes care of maintaining this business functionality.
  • Registry and Repository: Generic enablers that able to store models and configuration information along with all the necessary meta-information to enable searching, social search, recommendation and browsing, so end users as well as services are able to easily find what they need.
  • Revenue Settlement: Process of transferring the actual charges for specific service consumption from the consumer to the service provider.
  • Revenue Sharing: Process of splitting the charges of particular service consumption between the parties providing the specific service (composition) according to a specified revenue sharing model.
  • Service: We use the term service in a very general sense. A service is a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks. Services could be supported by IT. In this case we say that the interaction with the service provider is through a technical interface (for instance a mobile app user interface or a Web service). Applications could be seen as such IT supported Services that often are also composite services.
  • Service Composition: in SOA domain, a service composition is an added value service created by aggregation of existing third party services, according to some predefined work and data flow. Aggregated services provide specialized business functionality, on which the service composition functionality has been split down.
  • Service Delivery Framework: Service Delivery Framework (or Service Delivery Platform (SDP)) refers to a set of components that provide service delivery functionality (such as service creation, session control & protocols) for a type of service. In the context of FIWARE, it is defined as a set of functional building blocks and tools to (1) manage the lifecycle of software services, (2) creating new services by creating service compositions and mashups, (3) providing means for publishing services through different channels on different platforms, (4) offering marketplaces and stores for monetizing available services and (5) sharing the service revenues between the involved service providers.
  • Service Level Agreement (SLA): A service level agreement is a legally binding and formally defined service contract, between a service provider and a service consumer, specifying the contracted qualitative aspects of a specific service (e.g. performance, security, privacy, availability or redundancy). In other words, SLAs not only specify that the provider will just deliver some service, but that this service will also be delivered on time, at a given price, and with money back if the pledge is broken.
  • Store: Part of the Business Framework, offering a set of services that are published to a selected set of marketplaces. The store thereby holds the service portfolio of a specific service provider. In case a specific service is purchased on a service marketplace, the service store handles the actual buying of a specific service (as a financial business transaction).
  • Unified Service Description Language (USDL): USDL is a platform-neutral language for describing services, covering a variety of service types, such as purely human services, transactional services, informational services, software components, digital media, platform services and infrastructure services. The core set of language modules offers the specification of functional and technical service properties, legal and financial aspects, service levels, interaction information and corresponding participants. USDL is offering extension points for the derivation of domain-specific service description languages by extending or changing the available language modules.
Personal tools
Create a book