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.BusinessCalculator - FIWARE Forge Wiki

FIWARE.OpenSpecification.Apps.BusinessCalculator

From FIWARE Forge Wiki

Jump to: navigation, search
Name FIWARE.OpenSpecification.Apps.BusinessCalculator
Chapter Apps,
Catalogue-Link to Implementation [ N/A]
Owner iMinds, Koen Casier

Contents

Preface

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

  • Copyright © 2013-2014 by iMinds, all rights reserved

Legal Notice

Please check the following Legal Notice to understand the rights to use these specifications. iMinds strives to make the specifications of this Generic Enabler available under IPR rules that allow for an exploitation and sustainable usage, both in Open Source and proprietary closed source products, to maximize adoption.

Overview

The business calculator is the component which will be closely interacting with the Business modeler in order to add the simulation capabilities. The business calculator will be not a single implementation, but rather an open specification of the interface for the interaction between the business modeler and the business calculator. In the implementation phase several approaches to modeling and simulating costs are investigated and extended in open specifications, and are developed up to a plugin to the generic enabler.

The core functionality of each of these plugins is to provide the user with a means to estimate the evolution of costs in one consisting element of the business model according to a structured calculation model.

Typically users will make use of this business calculator GE and the different possible implementations it has within the FiWare project, through the Business Modeler GE. This allows the users to add a simulation layer to a business model, making it more predictive of economic background. In order to allow the user to draw and integrate their models in the business calculator GE, an additional limited web-based editor front-end will be provided in case this is needed. Finally the models generated in the editor, as well as any models created in another editor can be saved in a repository for later binding in the business modeler GE (by means of their identification-name). Integrating the business calculator GE in a larger tool-chain is of course possible and the business calculator GE will provide one REST interface (with asynchronous call-back) to accomplish this. This same interface will also be used in the limited editor in order to test-run a new detailed model, as well as in the business modeler in order to link all detailed models to the different elements and integrate all simulation results.

Basic Concepts

Target usage

When the different business actors come together to work out a new business model in the Future Internet, their first hub will be the Business Modeler. This highly interactive editor allows them to quickly draw out a business model, instigate the discussions and add descriptions and documentation in order to make it a more solid proposal. Of course as a final outcome of this process, the actors would like to go a step beyond this documentation and try to simulate the impact this new model could have in terms of revenues, costs, profitability. In order to achieve this, the technical experts of the different actors should be able to quickly and accurately sketch out their cost and revenue structure. This will be the case for all actors, whether they are providing equipment (e.g. routers, software instances, linecards, servers, sensors, etc.) , operational tasks (maintenance, installation, etc.), write software or have a more complex business propositions. The Business Calculators complement flexible modeling languages with an accurate and tunable calculation approach. To make the modeling languages and approaches extensible and scalable, we use a plugin architecture in which the REST interface will be the same for each plugin calculator and only the model selector will be differing. The results of the calculation will of course in the follow-up steps be fed into the business modeler and visualized in there. The structure of the business model in combination with the simulation results will give the business experts of the different actors an intuitive view on both the interactivity in the model as its validation.

Plug-in architecture

As mentioned before the business calculator is constructed with a plugin extensibility in mind. Even more, we consider the use of one expert model encompassing all possible costs and revenues as infeasible and will lead to an overly complex and no longer intuitive modeling approach. From our background research we found that extensible models should be kept small and dedicated to one task. In this sense they will also perfectly map with the smallest consisting element of a business model. We make an initial distinction between equipment coupling (tree or graph structure linking equipment to each other by dependencies), operational processes, software development and network structure. We will work out an open specification modeling approach for all these models, and provide a calculator GE which is capable of estimating the costs of a given model when given the required inputs (e.g. estimated number of customers). As such each of the aforementioned modeling approaches will have a dedicated open specification (when this is not yet existing) and a calculator. These will be added gradually as research, open specs and implementation for these evolves. When a new GE implementation for a new modeling approach is available, this GE will be linked into the overall business calculator GE.

Equipment Coupling Modeling Notation (ECMN)

The Equipment Coupling Modeling Notation is a novel approach to drawing out the essential structure of equipment and its coupling constraints to each other and to the context of a business model (by means of so called drivers). The ECMN consists of a hierarchical structure documenting how equipment is linked to each other and what the constraints on later calculations will be. The hierarchical model will be represented in a graph structure. The inputs for these models will come from context specific parameters from the business model such as number of customers, number of sites,etc., from default parameters detailed in the model itself or from already calculated parameters from other models within the business model. The calculator is able to calculate for each type of equipment in the model, the amount to be installed at each point in time, when given the required input for the drivers. As such the ECMN allows to model the equipment to be installed in order to fulfill an activity in a business model, for instance installation of racks, storage, servers, communication equipment, etc. for providing a data-center capability. As such the ECMN also allows a model to be reused in different business models or different contexts of the same business model, and at the same time allows to quickly insert an alternative technology stack for the same business model. The details of the ECMN will be added in the open specifications and pushed towards standardization. A GE implementation will enable the user to estimate the amounts and costs for installing equipment given the context of the business model in which it is to be used.

Business Process Modeling Notation (BPMN)

Business Process Modeling Notation will be used as the backing model for all estimations of process related costs. It is important to make the distinction between operational expenditures and process related costs here, as even capital expenditures could well caused and modeled in a process based approach. For details on the BPMN we refer to the existing standard [1] and we will be using a very limited subset of this for the calculator. The reason for this subset lies in the balance between modeling effort and estimation detail. In the case of a new business model the details the BPMN offers are too expensive in terms of modeling effort and especially considering the fact that there are many unknown (or variable) parameters, the modeling should be fast and as such cut in the details. Details on this subset will be added to the open specification document

Business Calculator Architecture

The Business Calculator is a plugin architecture which will be providing one identical interface for all different calculator approaches which are plugged in at runtime. All these calculators will be provided as separate GE implementation and might be directly called from the business modeler, or dispatched by detection of the modeling language by one overarching Business Calculator GE (TBD). The main building blocks and its interactions of the Business Calculator Architecture are shown in the figure underneath.

Business calculator architecture

Typical Implementation Architecture

For any implementation within the Business Calculator we make an explicit split between the model, editor and calculator components. Both the calculator as the editor have a REST interface by which the communication is handled. The editor also has a front-end communicating with the back-end and storing the models, properties and calculations data remotely in normal operation. We make the front-end also available in a stand-alone version in which no connection to the server is required. In this case new models will have to be uploaded to the repository prior to calculations in the business modeler. A view on this architecture is shown in the figure below.

Business Calculator Typical Implementation

With this architecture it is fairly straightforward to implement an additional editor working on the same core and with additional functionality, or implement a new calculator providing an alternative means of estimating the costs for a given model. This will be for instance the case for the business process modeling notation for which plenty of editors are available all equipped with an export to XPDL (XML process description language) functionality. This standardized model can then be used in the BPMN calculator. This is shown in the figure underneath.

Business Calculator Implementation with existing model

Finally as mentioned before we will make a link of the business modeler with the revenue sharing system and in order to accomplish this, we make an adapter which will call the RSS calculator and load in there the model as selected by the user and execute this with the necessary input and translate the calculated output. In this scheme both the calculator as the editor are proprietary and the adapter will translate to an internal mapping model. This is shown in the figure underneath.

Business Calculator Implementation with existing calculator

Business Calculator Input/Output Ontology

The business modeler will shift all simulation to the business calculators. In order to accomplish this, the business modeler and business calculator agree to the interface between them. The ontology of the data for the input as well as for the output of the business calculator, we are working towards the following:

Business calculator Input Output Ontology

As the integration of the business modeler and the business calculator is scheduled to take place after the first release of both business modeler GE and business calculator GE, this interface is still a subject of discussion and there might be changes in this format during implementation phase.

Main Interactions

The Business Calculators will be used in close cooperation with the business modeler. The sequence diagram shown below depicts the most typical interaction of the business modeler with the business calculator. When the business modeler is fully defined, in which case each business element has a more detailed technical model associated, it can be simulated. To accomplish this, the business modeler will call for each element the business calculator corresponding to the model internally associated and give the overall context as input to work with. For instance when the task of providing (installing) network, IaaS, PaaS equipment or software packages is concerned, the detailed model could be an ECMN model in which the equipment to be installed is modeled in terms of customers, area, etc. When such model is combined with information on the predictions for amount of customers, coverage, etc, this leads to an estimation of the amount of equipment of the different types to be installed. This will directly lead to a prediction of future costs for fulfilling this task in the business model. All information from this role will be added to the context of the business model and handed as input in the follow-up steps in the calculation where iteratively all elements in the business model are calculated. In this way the profitability of the full business model and for each separate role and actor in it can be estimated prior to the real implementation.

Business Modeler and Business Calculator sequence diagram

Any tool chain incorporating the whole or parts of these calculators will work in the same way. All interaction between the business modeler and the different business calculators will happen through the same REST-interface. In this way several business calculators can be linked to other tools in a transparent manner. Extending the Business Calculator with additional implementations is as such also only a question of implementing the common REST interface and linking it in the tool chain or in the overall Business Calculator GE. When a calculator is already existing using another way of interaction, the best way to integrate this into the tool chain of the Business Calculator is by adding an adapter translating the input and output from the proprietary calculator to the input and output of the Business Calculator. This is also the workflow that will be used for integrating the Revenue Sharing System into the Business Modeler tool chain as shown in the sequence diagram below. In this way the user of the Business Modeler can integrate revenue sharing models into the business modeler to add specific estimations to the overall business modeling tool chain.

Business Modeler and RSS sequence diagram

Basic Design Principles

As has been mentioned above, the business calculator GE is actually a plug-in aggregation of several dedicated modeling and calculation approaches. We have chosen to work with one web-based REST interface which allows to present a calculator with a model and input and return the outcome. We extend this interface with an identification approach for checking whether the presented model can be calculated with the business calculator send to. This in order to provide the following properties:

  • easily extend the business calculator GE with additional calculator plug-ins
  • instantiation and linking could be done at run-time
  • easy to obtain parallelism by plugging in redundant calculators of the same kind
  • easy linking within Fi-Ware by means of adapters translating input and output to/from the business modeler GE
  • easy linking within Fi-Ware and outside of the business modeler GE

Detailed Open Specifications

Open Model Specifications and existing model specification adjustments

As mentioned, the business calculator is a plugin approach which will be providing a calculator for multiple modeling approaches. Some of the modeling approaches might already have a standardized format (e.g. BPMN) and will be adjusted or reduced to fit the cost estimation purposes, other modeling approaches might already have an implementation within the FiWare consortium (RSS) and a simple adapter will be added to interact with this component. For all cases the specification, novel or with adjustments and possible reductions, will be described in detail and conforming to the calculator. It is important to note that failing to apply these specs with their adjustments and reductions might lead in non-functioning of the calculator.

The open specifications for the following modeling languages have been included in this architecture:

  • Equipment Coupling Modeling Notation
  • Business Process Modeling Notation (of which we use a subset)
  • Revenue Modeling Wizard
  • Hierarchical Network Modeling Wizard

The full open specs for each of those languages can be found in a separate section for each language.

Business Calculator Open API Specifications

  • XML storage format
    all XML data formats are described in detail in the [Programmer Guide]
  • REST interfaces
    all REST interfaces are described in detail in the [Programmer Guide]


Open Specification for Equipment Coupling Modeling Notation

When tackling the problem of how to dimension a central office, a street cabinet, a server room, etc., one is repetitively having the same discussions and making very comparable calculations. For instance a street cabinet of a telecom operator contains one small rack and one or two power blocks in there. It contains at max 3 (sometimes 4) shelves and each of those shelves can be equipped with a predefined amount of line cards. Finally this amount of line cards will be directly correlated to the amount of customers to serve via this street cabinet. Calculations of the dimensioning are as such clearly hierarchical in nature. For instance the amount of shelves will depend on the amount of line cards which is in turn dependent on the amount of customers to connect. Definitely the modeling and calculation are two separate steps in the process of dimensioning the equipment. The first subsection will detail the visual equipment coupling modeling notation. In the section following, this visual language is coupled to an XML format for which an XSD description will be added to make this more rigid and standardized. The third subsection is detailing how the calculation of the dimensioning (amount of needed equipment for each type) can be performed based on this visual ECMN. Finally, the last subsection will add examples to make things more concrete and at the same time provide cases that can be used both in testing as in the construction of templates.

Visual Notation

As mentioned, the equipment model consists of a hierarchical structure documenting how equipment is linked to each other and what the constraints on later calculations will be. The hierarchical model will be represented in a graph structure for which an example, on which we will extend, is shown below:

Equipment Modeling Notation Example

The basic building blocks of the equipment model are:

Driver
ECMN Driver
A driver with the name indicated in the arrow. The direction of the arrow is inside the equipment model and can be placed at any side of the model. Typically the drivers are placed at the left hand side or at the bottom (at the ‘leaves’ of the tree). Additional information is to be coupled to this driver and some modeling specific information, e.g. recurrence, can be added directly attached to the driver block in the model.


The following information can be coupled to the driver:

  • Name: Unique (model) String value
  • ID: String – for identification in a broader context

The driver is an input block and as such no other block can connect before this block. The driver can connect to multiple other equipment, aggregator and/or separator blocks.


Intermediate Driver
ECMN Intermediate Driver
An intermediate driver is the same as a driver with the difference that it is used for making the link between two points in the model. It can connect at the one side to one incoming child and on the other side it can connect to multiple equipment, aggregator and/or separator blocks.


It is to be used in the following two cases:

  1. Clarity of the model: In this case the intermediate driver will make the link from one point in the model to another point to allow having less connectors crossing other connectors or blocks.
  2. Sub model: In the case of the sub model it is used in the expanded view to indicate clearly the end of the sub model and where it connects to the higher level model.

The following information can be coupled to the intermediate driver:

  • Name: String value which can be used twice in the same model
  • ID: String – for identification in a broader context

In the editor, clicking on the one intermediate driver should also indicate the other intermediate driver (when existing) it is linking to.


Equipment
ECMN Equipment
Identifies a type of equipment based on its name.
Additional information is to be coupled to this equipment and some modeling specific characteristics, e.g. reinstallation period, power usage, etc., can be added directly attached to the equipment block in the model.


The following information can be coupled to the equipment:

  • Name: Unique (model) String value
  • ID: For identification
  • Cost: Double or time dependent
  • Capacity: Double
  • Size: Double + possibility to give its unit (e.g. gigabyte)
  • Maintenance: Fixed percentage (Double) or time dependent
  • Energy Consumption: Double (possibly later time dependent)
  • Installation: Fixed percentage (double) or fixed cost per unit (double) or time depenent
  • Floor space: Double
  • Reinstallation time: Integer value

Equipment can be coupled directly after one other equipment, one driver, one aggregator or one separator by means of a connector (shown below). An equipment block itself can couple to multiple other equipment, aggregators and/or separators.


Sub-model
ECMN Sub-Model
Equipment models are inherently hierarchical and can be stacked in a hierarchical manner with more intuitive visualization and modeling by means of a sub model.

The editor should intuitively allow seeing the expanded view of this sub-model (e.g. through double click). The content of the sub-model is similar to a regular ECMN using all blocks mentioned here. To start with we fix the constraints so that a sub-model should connect to one input (child) indicated in the expanded view as a driver and one output (parent) indicated by an intermediate driver in the expanded view. In the future we might relax this constraint and open up the possibility to have multiple input drivers and multiple intermediate drivers. At that point we will have to make the link between the higher level model and its sub-models clear (e.g. by ID or name).


Aggregator
ECMN Aggregator

An aggregator will combine constraints into one new constraint to link to blocks further in the calculations (called down flow parent), thereby linking multiple children to one parent. Additionally, aggregators can define how the combination of constraints should be performed by means of a flexible rule set (RA) indicated directly into the symbol. By default, the summating aggregator is assumed: then, the aggregator can be removed from the figure in this case. An aggregator can be linked from multiple drivers, equipment, aggregators and/or separators (called children) up to several other equipment, aggregators and/or separators.
The following information can be coupled to the aggregator:

  • Name: String value
  • ID: String – for identification in a broader context

The example below should be read as the amount of servers is depending on the total number of sites which is the multiplication of the number of customers and average sites/customer.


Separator
ECMN Separator

A separator will separate constraints into multiple - not necessarily different - constraints to link to equipment further in the calculations, thereby linking one child to multiple parents. Additionally separators can define how the split of constraints should be performed by means of a flexible rule set (RS) indicated directly into the symbol. By default the parallel separator is assumed in which case the separator can be removed from the figure. If wished or required, a separator can have an identification or name. The separator can be linked from one driver, equipment, aggregator or separator up to several other equipment, aggregators and/or separator.
The following information can be coupled to the separator:

  • Name: String value
  • ID: String – for identification in a broader context


Connector
ECMN Connector

The connector is represented by a simple line and connects drivers, equipment, aggregators or separators to each other. The granularity factor links the different levels of equipment types, by indicating the maximum number of equipment of the lower type (children - N) that is needed before a new equipment of the higher type (down flow parent - M) is to be installed. By default, a connector without any granularity indicated refers to a 1:1 connector. The following example should read as follows: For every 1000 customers a new hard disk should be installed. It is not required that the parent side of the connector be equal to one or be smaller than the child side. The following example requires hard disks to be installed per 2 for every 1000 customers, for instance for the sake of redundancy. When a size is set for the parent of this connector link, a simple granularity relation to this size can be used as well. For instance the following example indicates that 1GB per user is reserved on the disk. When the size of the disk is set to 1000GB or 1TB, this means that a new hard disk has to be installed per 1000 new customers.


Recurrent Driver
ECMN Recurrence

In case equipment needs to be installed on a yearly base (or with a predefined recurrence) in correspondence to its input (e.g. driver), this is indicated with the repetitive symbol on top of the connector. An example can include the yearly increase of the available disk space for each user. Extending the previous example, the example shown below reads as "every year an extra 1GB hard disk space must be installed per existing customer". As mentioned before the 1 in the recurrence symbol can be omitted.


Batched Installation
ECMN Batched Installation

Certain types of equipment can only be installed in batches. The basis for the batch can be either the parent or the child. In case the child side has been selected, this refers to a minimal installation batch per installation of the parent (taking into account the granularity). This has been used in the example below and means: A RAID controller can contain 8 hard disks and for every new RAID controller at least 2 new hard disks should be installed.

In case the parent side has been selected, this refers to a minimal installation batch first time – so only for the first installation of the parent. This has been used in the example below and means: for every 1000 customers, a new hard disk should be installed, but the first time installation requires two hard disks to be installed.

A batch can also be the default way of installation, or a requirement for a every new installation. This is made clear by means of an averaging indicator. The example below uses this, which means: every addition of hard disks to the RAID should always happen in batches of 2.
As mentioned before, the links between drivers and equipment and from equipment to other equipment higher in the hierarchy can be tuned with calculation rules. The following calculation rules are defined in the equipment modeling language:


Summation Aggregator
ECMN Summation

Calculates the amount of all down flow parent types based on the sum of the amount of all children.


Multiplication Aggregator
ECMN Multiplication

Calculates the amount of all down flow parent types based on the multiplication of the amount of all children.


Difference Aggregator
ECMN Difference

Difference aggregator: Calculates the amount of all down flow parent types based on the difference between two children (limited to two children).


Maximum, Minimum and Average Aggregator
ECMN Maximum, Minimum and Average

Max, min and average aggregator: Calculates the amount of parent type equipment based on the highest, lowest or average amount of children type equipment

As mentioned before, additional annotations can be added to both the drivers and equipment to indicate additional aspects to take into account in discussions and in the calculations. The following annotations are defined in the equipment modeling language:

Recurrent Installation
ECMN Recurrency on Equipment

Any equipment annotated with this symbol will have to be reinstalled with a reinstallation period as indicated (t) in the loop.


Time Dependent Installation
ECMN Time Dependent

This equipment has to be included for a certain period in time. Applying this to different types of equipment allows substituting equipment for newer equipment at a later point in time.


Maintenance
ECMN Maintenance

The maintenance of this type of equipment entails an extra cost, which is recurring periodically.


Upfront Maintenance
ECMN Maintenance Upfront

The maintenance of this type of equipment entails an extra cost, which needs to be paid to the supplier upfront (fixed maintenance contract).


Floor space
ECMN Floorspace

The equipment consumes a reasonable amount of floor space inside the central office, cabinet, server room. A leasing cost for this floor space should be taken into account.


Active Equipment
ECMN Active Equipment

This symbol indicates that the equipment under study contains active components, and will therefore consume electricity.


Finally the different building blocks of an ECMN can be grouped in swim lanes and pools as an indication of the responsibilities for the different equipment. Swim lanes are indicated by large bars indicating the grouping in which the different equipment blocks are assigned. This can be based on different types of groupings, such as which business unit is going to pay or maintain them, etc. More in general all blocks in the model should be assignable to different groups and it should be possible to make this grouping visible by means of swim lanes or coloring.

Open Specification of the subset from BPMN to be used for process based cost modelling

When tackling the problem of how to dimension and estimate of the costs of executing operational processes for instance physical repair tasks, installation, etc. One is repetitively performing the same tasks. Although many approaches exist for visualizing the flow of a process, typically by means of some flowchart based modeling language, the link of this flowchart towards estimation of future new costs is not straightforward. There are several tools which allow the user to perform such operational modeling for their current organization with the focus on allocation of the costs to the different departments and predict the effect of small changes in these models. The business process modeling notation (BPMN) is an existing modeling language which is mature and has an XML based storage and exchange format (XPDL). For the sake of modeling the costs of future installations and with a focus on the estimation and not on the hyper realistic mapping of costs, we will adapt this format, but leave out several of the more detailed aspects. In what follows we describe in short the visual notation, the interpretation of this format in the case of business modeling and future cost estimations. The second subsection will detail how the XPDL format is accustomed to contain new information required for the calculation and/or resulting from the calculations. The third subsection details how the operational process calculation can be performed in two possible ways when given the operational process and the necessary information in this model. Finally the last subsection will add examples to make things more concrete and at the same time provide cases that can be used both in testing as in the construction of templates.

Visual Notation

As mentioned before, the business process modeling notation is a standardized visual modeling language which can be used for drawing out operational processes and link cost calculation to this. The visual format is based on a flowchart structure and two examples are shown below:

Business Process Modeling Notation
Business Process Modeling Notation

A process model in BPMN is built around three basic building blocks: events, activities and gateways, indicated by circles, rectangles and diamonds respectively. Additional graphical notations give intuitive information on the type, occurrences, causes, etc. of the elements. A complete detailed description of all elements can be found in the full reference.


Events
BPMN Event
From the start event, an incoming request for execution of the process is fired. When reaching the end event, all activities (if any) still running in the process are stopped, the request is consumed and control is handed back to the encompassing process.

Intermediate events indicate situations in which a given part of the process is triggered during the running of the process. The following more specific events will be used in the calculation models. (all other events will be handled in the following manner: Start events will be considered message start events, Intermediate events will be removed from the model (or calculation), and end events will be considered end or cancelling events)

Message start event
BPMN Start Event
Contains some information within the event that can be used in the running of the process (e.g. cause of the execution). For the estimation purposes of the costs of running an operational process, the message start event will contain information on the amount of events for each year are expected and possibly also of the spread of these events.


The following information can be coupled to the message start event:
  • Name: Unique (model) String value
  • ID: String – for identification in a broader context
  • Interval or events per year Double: The interval between two events of this type or the amount of events encountered per year of this type
  • Variation on the interval or events per year: The standard deviation expected in the interval or events per year of this type of event
Timer intermediate event
BPMN Intermediate Event
Will trigger an intermediate event once a predetermined time has elapsed. The timer starts counting from the moment this intermediate event is reached in the process. In the description of an operational process with the aim of estimating the costs, this will contain data on the timing over which the events are running. This can contain data on the time when the first events will start, the time they will end or both start and end indicating the interval over which the events are triggered. This is an interesting tool for splitting the process in time-dependent execution paths.


The following information can be coupled to the link timer intermediate event:
  • Name: Unique (model) String value
  • ID: String – for identification in a broader context
  • Interval or events per year Double: The interval between two events of this type or the amount of events encountered per year of this type
  • Variation on the interval or events per year: The standard deviation expected in the interval or events per year of this type of event
Link intermediate and end event
BPMN Link Intermediate Event
BPMN Link Intermediate Event
Will trigger the execution of the corresponding link end event. All link intermediate events with the same name will link to the same (unique) link end event in the process. It is often used to link two situations to the same execution path and for graphically structuring the process.


The following information can be coupled to the link intermediate events:
  • Name: Unique (model) String value
  • ID: String – for identification in a broader context
End or cancelling event
BPMN End or Cancelling Event
An ending event which will cancel all process steps up to this point and leave the overall process.


The following information can be coupled to the end event:
  • Name: Unique (model) String value
  • ID: String – for identification in a broader context


Activities
Activities indicate the actions taking place in the execution of the process. They will contain a descriptive name and can contain parameters for the calculation of the costs.
Simple activity
BPMN Simple Activity
This can have additional indications for repetitive execution and multiple parallelized instances indicated at the bottom border. For the case of estimating future costs, the following information should be available in the activity: (1) an average time required for the execution and the amount and type of people executing this. (2) the number of parallelized instances possible (3) the amount of repetitions to be executed (4) any information on variations of this data.


In the calculations currently the following information of the activity is used:
  • Name: Unique (model) String value
  • ID: String – for identification in a broader context
  • extendedAttributes: Mapping of name to double value. The name indicates the type of personnel, and the double value indicates the amount of time required for this personnel on average to perform this activity.


For the future the following information should be coupled to the activity:
  • Name: Unique (model) String value
  • ID: String – for identification in a broader context
  • Average working time: the average working time for a team of people to accomplish the task
  • Size of team: team size
  • Personnel-type: ID based name for the personnel type
  • Amount of parallel instances
  • Amount of repetitions
Collapsed sub process
BPMN Collapsed Sub Process
An activity linking to a sub process which is indicated by its (unique) name and will have a start and end event linking to entrance and exit of this activity. The link from the main process to the sub process will happen in the case of the cost

estimation calculator by means of the events – start: input, end: output.


Gateways
Gateways indicate splits or joins in the process. Those splits can either be conditional or unconditional and can have multiple incoming and outgoing execution paths of which more than one can be chosen at the same time. The incoming and outgoing paths are distinguished by their names.
Exclusive gateway
BPMN Exclusive Gateway
Only one of the outgoing paths is taken. The default path can be indicated by a small strike through. Additional information can be added on the probabilities of the different outgoing paths. An exclusive join is typically not used in the model. Paths are just aggregated, often at the next mutual activity, without the use of this symbol.


The following information can be coupled to the exclusive gateway:
  • Name: Unique (model) String value
  • ID: String – for identification in a broader context
Additional calculation information is typically linked to the paths coming out of the exclusive gateway.


The following information can be coupled to the path (transition) coming out of the gateway:
  • Name: Unique (model) String value
  • ID: String – for identification in a broader context
  • probability: value between 0 and 1. In an exclusive gateway the summation of all probabilities will be one. If probabilities are not defined for one or more paths coming out of the gateway, the remaining probability is evenly distributed over these paths.
Fork or Join gateway
BPMN Fork Or Join Gateway
A fork will trigger execution along all outgoing paths in parallel. A join will wait for all incoming paths to end and trigger execution on the outgoing path in this case. Sometimes a fork is not explicated and paths are split at the last mutual activity, without the use of this symbol.


The following information can be coupled to the fork or join gateway:
  • Name: Unique (model) String value
  • ID: String – for identification in a broader context


The following information can be coupled to the path (transition) coming out of the gateway:
  • Name: Unique (model) String value
  • ID: String – for identification in a broader context
  • probability: value between 0 and 1. In a fork gateway the summation of all probabilities is not required to be limited to one. A probability of 1 is used for each path for which this probability is not delicately set.
Complex gateway
BPMN Complex Gateway
Where the calculation and selection of the follow-up steps is calculated according to an additional rule.


The following information can be coupled to the fork or join gateway:
  • Name: Unique (model) String value
  • ID: String – for identification in a broader context


The following information can be coupled to the path (transition) coming out of the gateway:
  • Name: Unique (model) String value
  • ID: String – for identification in a broader context
  • probability: value between 0 and 1. Missing probability information leads to an error in the calculation.


Finally all kinds of data objects can be used to hold crucial information on one of those elements, or give more verbose explanation in some parts of the model. Very important in this are all types of aggregation through different structural groups (e.g. administration, technical personnel, etc.). Such aggregation is most often indicated by means of horizontal bars called pools and swim lanes.

Open Specification of the flexible and modular approach for estimating revenues

In a business model, the interaction between two actors (by means of activities) will often be based on an exchange of value, product or service in return for money. The figure below shows this interaction in an example business model in the most simplified form. In more general business models, such value-to-money exchange will be present in many more instances. In what follows we use the terminology (customer and provider) as indicated in the figure.

Making a profit on top of the costs is of course the main aim of the provider. Getting the right amount of products, services, or other value is the main aim of the customer. As such generic value exchange is essential to the business model and to its quantification; Within the business calculator, there is a dedicated and novel modeling approach defined to cover this.

Structure

The revenue modeling details the relation between the provider and the customer and will link information from both sides to each other. For instance in order to know which price to ask for a product in order to have a margin of 10% each year, the calculation will need the costs of the provider and the amount of customers. Additional information will be taken into account in this calculation as well.

The revenue modeling has no dedicated visual language and will be fully specified in an XML format and/or by means of a wizard. It consists of two different levels of detail at which a processing step can be added:

  1. The pricing scheme itself which will calculate a price for a given amount of customers, the different costs, intended profit margin, etc. The pricing schemes here allow to define the calculation and parameters to use in the price calculation.
  2. A hierarchical selection model that decides which pricing scheme to use for a given situation, depending on the amount of customers reached, timing, coverage, etc. The selection model allows differentiating the price for instance allowing a lower or higher price in the initial years or for the first customers and a different price at a later stage.

Finally, the processing step allows discussing the impact of discounting in the context of the pricing schemes and hierarchical selection models.

Pricing Schemes

Fixed Price

In a fixed pricing scheme the user directly indicates the price for the customers to pay. There are no additional parameters and calculations. Clearly the fixed pricing scheme can also make use of a timed predefined price.

Cost Based Pricing (=Cost Plus Pricing)

In cost based pricing the price the provider will charge will be based on an intended profit margin over the time horizon. This profit margin can be fixed or changing over the time horizon.

  1. For a fixed profit margin
As a consequence the price will be fixed over the time horizon as well.
  • The parameters in this pricing scheme are
  • Profit margin (%) a value in 0-1
  • The inputs of this pricing scheme are
  • The costs per year
  • The customers per year
The figure underneath gives an overview of this pricing scheme for a given decreasing cost for a profit of 10%.
Cost Based Pricing With Fixed Profit Margin


  1. For a changing profit margin
As a consequence the price will no longer be fixed over the time horizon
  • The parameters in this pricing scheme are
  • Profit margin (%) a time dependent function with values in each year in 0-1
  • The inputs of this pricing scheme are
  • The costs per year
  • The customers per year
The figure underneath gives an overview of this pricing scheme for a given decreasing cost for a profit of 10% over the first year, decreasing till 0% on the last year. The figure underneath gives the comparison of the pricing in this timed scheme to the untimed scheme:
Cost Based Pricing With Variable Profit Margin
Outcome Price for Cost Based Pricing With Variable Profit Margin


Limit Pricing

In limit pricing the price the provider will charge will be aimed at breaking even on an intended time span (which can be shorter than the total time horizon). Again in our specification we consider the price to be fixed over the total time horizon.

  • The parameters in this pricing scheme are
  • Time Span for Break-even is set shorter than the time horizon for the analysis
  • The inputs of this pricing scheme are
  • The costs per year
  • The customers per year
The figure underneath gives an overview of this pricing scheme for a given decreasing cost for a time span for break-even of 10 years:
Limit Pricing Scheme


Integrated Cost Based Pricing

The integrated cost based pricing is actually an integration of both aforementioned pricing schemes. It is clear that a limit pricing scheme with a time span equal to the total time horizon can be mimicked by a cost based pricing with no intended profit margin. Taking together the two parameters – (1) intended profit margin and (2) intended time span – both cost based pricing and limit pricing can be covered by this new integrated cost based pricing. Again the integrated cost based pricing can be calculated using a fixed or a changing profit margin.

  1. For a fixed profit margin
As a consequence the price will be fixed over the time horizon as well.
  • The parameters in this pricing scheme are
  • Profit margin (%) a value in 0-1
  • Time Span for Break-even is set shorter than the time horizon for the analysis
  • The inputs of this pricing scheme are
  • The costs per year
  • The customers per year
The figure underneath gives an overview of this pricing scheme for a given decreasing cost for a time span for profit point of 10 years with a profit of 10% compared to both a limit pricing and a cost based pricing scheme with the same parameters:
Integrated Cost Based Pricing Scheme


  1. For a changing profit margin
As a consequence the price will no longer be fixed over the time horizon
  • The parameters in this pricing scheme are
  • Profit margin (%) a time dependent function with values in each year in 0-1
  • Time Span for Break-even is set shorter than the time horizon for the analysis
  • The inputs of this pricing scheme are
  • The costs per year
  • The customers per year
The figure underneath gives an overview of this pricing scheme for a given decreasing cost for a time span for profit point of 10 years and a profit decreasing from 20% to 10% compared to a fixed profit of 10%:
Integrated Cost Based Pricing Scheme with Variable Profit Margin


Running Cost Plus Pricing

In running cost plus pricing the price will be based on a short term part of the total costs. It can be mimicked by a repetitive cost based pricing over the short term and with the repetition ending at the total time horizon. Typically the provider would want to have its costs of this year repaid by the customers of the same year taking into account an intended profit margin. This means that in the running cost plus pricing

  • The parameters in this pricing scheme are
  • Profit margin (%) a time dependent function with values in each year in 0-1
  • Running Time Span: on which time basis the running cost should aim to get the desired profit
  • The inputs of this pricing scheme are
  • The costs per year
  • The customers per year
The figure underneath gives an overview of this pricing scheme for a given decreasing cost and for a yearly and a 4 yearly running profit of 10%, and a yearly running with a profit of 20% decreasing to 0%.
Running Cost Based Pricing Scheme



Hierarchical Selection Model

It is clear that pricing is not required to be the same for the full horizon of a business case. The revenue modeling provides an additional hierarchical selection model on which basis the pricing will vary. This selection model allows specifying on which basis the pricing scheme will be calculated in a different manner. This enables the user for instance to detail that first 5 years pricing will be aiming at running break even and afterwards profits are expected to grow to 10%.

Threshold Selection Model

The selection model will in essence be a check for a predefined parameter against threshold values. Currently the following parameters have been defined to be used in the revenue modeling:

  1. Time: The pricing scheme can be different for different periods in time
  2. Customers: The pricing scheme can change when reaching a predefined amount of customers
  3. Coverage: The pricing scheme can change when deployment, or customer count reaches a predefined coverage.

The selection model can be used in a hierarchical manner, where different selections are applied one after the other. For instance the following hierarchical structure (figure) indicates that the first 5 years and for a customer count smaller than 5000 customers a cost based pricing is used with 20% profit, whereas in these same years but for a larger customer base only 15% is used and after the first 5 years, the profits are even decreased to 10%.

 Selection Model:

	Time  	y0 - y5
		Customer 	<5000		 	cost based pricing 	20% profit
				>5000			cost based pricing	15% profit
	Time 	y6 - …				 	cost based pricing 	10% profit 

The calculation of the hierarchical selection model will be using the originally defined pricing schemes over the considered periods, coverage and/or customer ranges. For the integrated cost based pricing and in general all pricing schemes which take into account a predefined calculation horizon, the calculation will have to take into account in how far the accumulated revenues cover the accumulated costs. Two approaches have been taken into account during the development of the revenue model:

  1. Disregard all accumulated costs and revenues. A limit pricing in this scheme will try to break even over all costs over the considered time frame (or range) and will not take into account all deficit or profit over the previous period.
  2. Take fully into account all accumulated costs and revenues. A limit pricing in this scheme will aim to break even over all costs over the considered time frame (or range) increased or decreased with all potentially remaining accumulated costs respectively revenues over the previous periods.

In the calculations we chose to make a distinction between the cases of accumulated profit and deficit. In the case of accumulated profit, the first approach is preferred in order not to have the pricing compensate for these gains by underpricing. In the case of accumulated deficit, the second approach is preferred in order to finally end up with price leading at some point to a viable business case – or reflecting what price should be set in order to have a positive business case. In the following two figures we show the resulting accumulated revenues for a hierarchical model which has a fixed pricing for the first 5 years and a cost based pricing (10% profit) for the remaining 15 years. Both figures give a view on both approaches, with the preferred approach indicated with a fatter line. The top figure shows the case for an accumulated profit, while the bottom figure shows the case for an accumulated deficit.

Hierarchical Selection Model with Accumulated Profits
Hierarchical Selection Model with Accumulated Losses


Anchoring to the cost structure

The main aim in the pricing and the structure of the pricing should not always be the same for all elements of the cost. A clear example of this is the often made distinction between CapEx and OpEx, more or less in line with infrastructure costs respectively running operational costs. A valid pricing scheme could well take this distinction into account and demand a 20% profit with a time-span for break-even of 5 years for all infrastructure, and on top of that a yearly running 10% profit over all remaining costs. In the revenue model this is achieved by anchoring a cost element to a pricing scheme, in which this cost element is typically identified by means of a name. Additionally it is allowed to have multiple simultaneous time frames or customer/coverage ranges in the selection model. The calculations will then be triggered with the right cost input (by name linking) and sum all simultaneous revenues to the final revenue.

Following example shows a revenue model in which the first 5 years infrastructure is taken into account cost based (and depending on customer count) and operations are taken into account in a yearly running cost (with 10% profit) and afterwards all costs are taken into account:

Selection Model:

	Time  	y0 - y5
		Anchored to infrastructure
		Customer 	<5000		 	cost based pricing 	20% profit
				>5000			cost based pricing	15% profit
	Time  	y0 - y5
		Anchored to operations			running yearly cost	10% profit
	Time 	y6 - …				 	cost based pricing 	10% profit 

The Impact of Discounting

Discounting, or the fact that money spent at different points in time has not the same value, will be important in the revenue modeling and especially in the pricing schemes as well. Any revenue model can be retrofitted with this information and this can be added to the final outcome.

It should be noted that the price calculated in this way is not discounted yet (as would be expected) and the revenues calculated by multiplying the price to the customers is also not discounted. The discounted revenues can be calculated by multiplying the price to the discounted customers or by discounting the revenues after calculation.
FIWARE.OpenSpecification.Apps.BusinessCalculator.PNMN

References

[1] http://www.omg.org/spec/BPMN/2.0/

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