Creating value for predictive application management in the Fog

Computer Science & Networking

MSc Thesis

C R E AT I N G VA L U E F O R P R E D I C T I V E A P P L I C AT I O N

M A N A G E M E N T I N T H E F O G

Candidate: Giuseppe Astuti

Academic Year 2017/2018

Supervisors: Prof. Antonio Brogi

Stefano Forti

October 2018

Devices at the edge, such as smartphones, smartwatches and sensors are becoming more intelligent and cheaper. Equipped with tiny yet powerful processors, they can now tackle computing problems that a few years ago needed an entire framework. Most of the data until now has been crunched into the Cloud, but the increasing of the num-ber of devices is leading to the need for new infrastructures. That shift that will permit the emergence of mission- or life-critical applications, but to enable them systems to predict the application requirements and manage the life cycle are needed.

This thesis proposes a business assessment of the current technolog-ical scenario equipped with new tools to allow the rise of new QoS-aware deployment of multi-component applications in the Fog infras-tructure exploiting business tools that are used to model potential strategies of insurgency in the market. Indeed, the final results are re-lated to the design of three business models that could allow to take place in an already saturated market.

1 i n t r o d u c t i o n 1

1.1 The IoT and the Fog . . . 1

1.2 Predictive Application Management . . . 3

1.3 The Considered Problem . . . 3

1.4 Thesis outline . . . 4

2 b a c k g r o u n d 6 2.1 Fog Computing . . . 6

2.1.1 Fog Motivations . . . 8

2.1.2 Application Management in the Fog . . . 12

2.2 Business Modelling Tools . . . 15

2.2.1 The Business Model Environment . . . 15

2.2.2 The Business Model Canvas . . . 19

2.2.3 Business Model Patterns . . . 29

2.2.4 The Value Proposition Canvas . . . 32

3 b u s i n e s s m o d e l e n v i r o n m e n t 38 3.1 Market Forces . . . 39

3.2 Industry Forces . . . 48

3.3 Key Trends . . . 53

3.4 Macro-Economic Forces . . . 58

4 b u s i n e s s m o d e l s & value propositions 63 4.1 Business Model 1: Licensing to Asset Manufacturers . 63 4.2 Business Model 2: licensing to Infrastructure Provider 70 4.3 Business Model 3: FogTorchΠ freemium . . . 77

5 d i s c u s s i o n & conclusions 90 5.1 Business Models Discussion . . . 90

5.2 Summary . . . 91

5.3 Future Directions . . . 92

1

I N T R O D U C T I O N

1.1 t h e i o t a n d t h e f o g

The Interof-Things (IoT) is a self-configuring and adaptive net-work which connects real-world objects to the Internet enabling them to communicate with other connected objects leading to the realisa-tion of a new range of ubiquitous services [1]. The concept of con-necting devices to the Internet to remotely monitor their status was introduced in 1982 by a group of students at Carnegie Mellon Uni-versity when they managed to connect a coke machine to the Internet and remotely check its status [2]. However, the term IoT has been chosen by Kevin Ashton in 1999 [3]. Advancements in science and technology enabled making smaller, cheaper, and faster computing devices capable of sensing the environment, communicating and ac-tuating remotely, which resulted to the increased interest of applying the IoT to vast aspects of life, such as smart cities [4], healthcare [5], and smart home [6].

It is expected that more than 50 billion devices will be connected to the Internet by 2020 [7]. The introduction of such a massive number of connected devices requires a scalable architecture to accommodate them without any degradation of the quality of service demanded by applications. Besides, the majority of the devices that make up the Internet-of-Things are resource-constrained, i.e., such as comput-ing power, energy, bandwidth, and storage, are limited in IoT devices [8]. These constraints limit the deployment scenarios of applications using such IoT devices. For instance, it is infeasible to use a battery-powered sensor to connect to the Internet directly and publish infor-mation regarding its surrounding for a long time or store readings

of a longer time in local memory. These constraints present a design challenge that is shaping the architecture of the IoT in many ways. Fog computing has been proposed as an intermediate layer that brings computing, network, and storage services closer to the end-nodes in IoT [9]. Compared to Cloud computing, this computing layer is highly distributed and introduces additional services to end-devices located in the perception layer [10].

As an intermediate computing layer, the characteristics of the Fog layer are in contrast with the Cloud layer ones. Indeed, the Fog layer is closer to the perception layer and this proximity provides a range of advantages that characterise the layer. One of the immediate benefits over the Cloud is its location-awareness. Such awareness comes due to the large-scale geographical distribution of the devices that make up the Fog layer [11]. Each gateway in the Fog layer manages a subset of nodes in the perception or sensor layer. This subset of resource-constrained devices are located close to each other and the managing gateway can quickly locate each device. The location-awareness of the Fog layer can be utilised to address multiple functional and nonfunc-tional requirements of IoT applications, such as mobility and security. Another closely related characteristic of the Fog layer is its large-scale distribution in contrast to the centralised Cloud layer [12]. The Cloud layer is centralised as seen from the client side. Looking from the or-ganisation of the servers in the Cloud, however, it is geographically distributed but not at the scale expected from the Fog layer. For in-stance, Cloud service providers such as Amazon have multiple data centres in different regions. The case of the geographical distribution in the Fog layer is different due to the small separation distance of the gateways and its massive deployment. Moreover, the proximity of the Fog layer to the nodes provides real-time interaction mode with the sensors and actuators in the perception layer. The geographical distribution of the Fog layer and subsequently the offered low com-munication latency are among the critical features of the fog layer.

Some IoT application domains, such as healthcare or automotive, are highly dependent on such feature.

1.2 p r e d i c t i v e a p p l i c at i o n m a na g e m e n t

The scale and heterogeneity of the Fog infrastructure raise the prob-lem of how to deal with the complexity of deploying and managing application over the Fog. Different solutions have been proposed to address this problem in the Cloud (such as [13, 14,15,16,17, 18, 19, 20, 21, 22, 23, 24, 25]) and they seem to be already established tech-nologies. Whilst for the Fog computing, new techniques to respect QoS specifications are rising. For instance, CISCO [26] is already pro-ducing framework such as CISCO FogDirector [27], that is used to manage the life cycle of the application deployed in CISCO Fog nodes and FogDirMime [28] is a simulation prototype over the Cisco FogDi-rector framework. iFogSim is a toolkit used to model and simulate resource management technique in the IoT and Fog computing envi-ronments. FogTorchΠ [29] is a probabilistic prototype for deployment of Fog application.

Predictive application management tools will be used to predict and estimate QoS metrics before the deployment and to manage the ap-plication deployment in an adaptive way during its life-cycle.

1.3 t h e c o n s i d e r e d p r o b l e m

The objective of this thesis is to analyse and detail the business en-vironment of the current technological era, focusing on the Fog com-puting paradigm and its outgrowths.

Utilising models for business design and strategy, that will be de-scribed later in Chapter2, we want to address the problem associated to the diffusion in the market of a new tool performing predictive management of multi-component applications in the Fog, creating

the business value for it. During the analysis of the market, we high-light which are the advantages and the disadvantages of an entrance in such an empty market, detailing how to attract stakeholders and value chain actors that will avail and contribute to the product. This tool allows Application Operators to specify which are the require-ments of the deployment in such a complex infrastructure having back potential deployment solutions for their applications that re-spect the given specifications.

The models utilised, give us the means to continue the work by propos-ing few possible scenarios in the real world exploitpropos-ing the analysis conducted formerly. Indeed, at the end of the Business Model Envi-ronment analysis, we propose three different business models. Two of them are designed for the acquisition of the predictive application management company by a big tech enterprise, while a freemium business model characterises the third and it is sustainable also by an autonomous company.

1.4 t h e s i s o u t l i n e

The rest of this thesis is organised as follows:

c h a p t e r 2 offers an overview about Fog computing and introduces the tools used to analyse the market environment and design the business strategy.

c h a p t e r 3 describes the environment utilising the Business Model Environment tool, highlighting Market Forces, Industry Forces, Key Trends and Macro-economic Forces that are affecting the current technological scenario.

c h a p t e r 4 proposes three different business model, one for each Customer Segment recognised in the previous Chapter.

c h a p t e r 5 discusses the previously detailed business models and summarises the contributions of this thesis and proposes possi-ble extensions and future work based on it.

2

B A C K G R O U N D

Outline

This chapter defines and details the major shifts in the current techno-logical era, e.g., the Fog computing (in Section2.1) and then describes the most important models that are used to analyse a business envi-ronment and to create new value propositions (in Section2.2).

2.1 f o g c o m p u t i n g

The concept of Fog computing [9] is the latest descendant in the line of physical separation of functional units [8]. It is a computing layer closer to the perception layer, where the sensors and actuators reside and provide computing, networking, and storage services. To accom-modate these services, and address the requirements of IoT systems, the Fog layer offers different characteristics.

The attributes of Fog computing can be leveraged to provide services that assist the perception layer, such that the overall system require-ments are met. This layer takes advantage of its proximity to the sen-sor layer and provides services that are extensions of the Cloud layer and also unique ones that are feasible only at this layer. The subset of possible services at the Fog layer is presented as follows:

- Computing Services since the devices at the edge do not always have the computing resources to compute. Processing at the Fog layer is not only motivated by the constraint of process-ing power at sensor nodes but also by the desired location of computing to better meet system requirements and maintain en-ergy efficiency. Earlier Cloud-based processing can be brought

down to the Fog layer for localised processing and immediate response [30]. In this regard, there can be multiple configura-tions of sharing the computing load among the different layers in the IoT-based system, and the processing requirements may vary based on the actual work. For instance, consider a system which performs data processing to learn a specific pattern, the workload can be distributed in such a way that localised pat-terns can be identified in the Fog layer while the generalised patterns are only available at the Cloud. Besides data manage-ment, events can be handled at the Fog layer. The proximity of this layer makes it an ideal candidate to handle events to react in real-time and enhance the reliability of the system,

- Storage Services since a large amount of IoT devices will generate a massive amount of data. The storage available in the devices at the perception layer is not often sufficient to store even a 1-day data considering the rate of data generation. Pushing all the data directly to the Cloud is not necessary, in particular when there is irrelevance or redundancy in data. Combined with the computing service, the stored data can be filtered, analysed, and compressed for efficient transmission or for learning local in-formation regarding the system behaviour. In cases where the communication may not be robust, the storage services help to enhance the reliability of the system by maintaining proper sys-tem behaviour for client nodes,

- Communication Services that in IoT is mainly based on wireless. Due to the resource constraints in the perception layer, these wireless protocols are optimised for low-power operations, narrow-band transmissions or a more extended range of coverage. The Fog layer is located in a strategic place to organise this multi-tude of wireless protocols and unify their communication to the Cloud layer. This helps in managing sub-networks of sensors

and actuators providing security, channelling messages among devices, and enhancing the reliability of the system.

2.1.1 Fog Motivations

Fog computing is already influencing how edge networks are being built [31]. Routers, switches, wireless access points, application and storage servers at the edge are already converging into unified Fog nodes. These often feature a unified networking platform that sup-ports heterogeneous networking technologies and a common com-puting platform that supports applications from multiple suppliers. This ongoing convergence of computing, networking, and storage at the edge will significantly reduce complexity and cost, increases sys-tem and application manageability, and make it easier for applica-tions to interact with each other [32].

It is not an either/or with Fog and the Cloud [33]. On the contrary, Fog empowers the Cloud by connecting a vast range of devices to the Cloud. Connecting all potential IoT devices directly to the Cloud will often prove impractical due to limited abilities on many IoT de-vices, excessive complexity and cost to add Cloud connectivity man-agement to all IoT devices, and scalability limitations imposed by con-necting every device directly to the Cloud. Fog can use more straight-forward local procedures and protocols to interact with the devices and shield the devices from the complexity of direct interactions with the Cloud [34].

Furthermore, Fog can act as a proxy of the Cloud to deliver Cloud services to IoT devices and systems [35]. For example, a Fog node on a connected car can act as the proxy for the tens of microcomputers on the vehicle. Instead of requiring every onboard microcomputer to connect to the Cloud for software updates directly, the Fog node can retrieve the software update package from the Cloud and then install the updates on the microcomputers at the right times [31].

Fog-as-a-Service (FaaS) [35] will allow users to access private and public Fog systems deployed close to them. Customers can store their data and host their applications in these nearby Fog systems. A man-ufacturer, for example, can store its sensitive data in a private Fog system deployed close to its factories. It can also have its manufac-turing control applications hosted by local Fog systems. Customers may merely rent storage spaces or computing servers from these Fog systems and manage their data and applications by themselves [31]. Fog will allow players of all sizes to deploy and operate Fog sys-tems and services. Many new, local and regional Fog operators will emerge, in a way similar to the rise of local and regional Wi-Fi service operators.

In the recent years, a consortium of high tech industry companies and academic institutions has been founded and named as OpenFog Consortium [36] that aims at the standardisation and promotion of Fog computing in various capacities and fields. Essential names as CISCO [26], Intel [37], Dell [38], Microsoft [39], and others are the founders of this movement that tries to drive reference architectures to serve as a foundation for Fog computing standards. The consortium fellows explain that the work is driven to solve the complex interoperability requirements that will lead to these standards. The OpenFog Consor-tium defines Fog computing as "a distributed architecture which spans the continuum between the Cloud and everything else, in essence, nodes, sensors, and other IoT-enabled devices and compute platforms" [36]. The benefits of Fog for enterprise amount to faster processing as devices are close to data generation sites, as well as cost savings from lower use of bandwidth.

These necessities take to the change of the architecture since Cloud computing seems to be no longer sufficient. Moving computing near to the devices that generate the traffic would decrease the network congestion, as well as accelerate analysis and the resulting decision-making [10]. However, edge devices cannot handle multiple IoT ap-plications competing for their limited resources, which results in

source contention and increases processing latency. Even if the re-sources were enough, the immediate consequence would be a mas-sive battery drain of the user’s devices [40] - smartphones, smart-watches, fitness sensors, laptops, and tablets have already a limited battery capacity that can’t be wasted.

Fog computing helps overcome these limitations. It avoids resource contention at the edge by leveraging the Cloud resources and coor-dinating the use of geographically distributed edge devices [41]. It involves the components of data-processing or analytics applications running in distributed Cloud and edge devices. It also facilitates the management and programming of computing, networking, and stor-age services between data centres and end devices. Besides, it sup-ports user mobility, resource, and interface heterogeneity [42].

Various application could benefit from Fog computing, namely:

- Healthcare and activity tracking in which real-time processing and event response is critical. One proposed system utilises Fog computing to detect, predict, and prevent falls by stroke pa-tients. The fall-detection learning algorithms are dynamically deployed across edge devices and Cloud resources. Experiments concluded that this system had a lower response time and con-sumed less energy than Cloud-only approaches [41],

- Smart utility services whose focus is on improving energy gen-eration, delivery, and billing. In such environments, edge de-vices can report more fine-grained energy-consumption details to users’ mobile devices that traditional smart utility services [9]. These edge devices can also calculate the cost of power con-sumption throughout the day and suggest which energy source is most economical at any given time or when home appliances should be turned on to minimise utility use [43].

- Augmented reality and cognitive systems which are latency sensi-tive. A wearable cognitive-assistance system that uses Google Glass [44] devices help people with reduced mental acuity

per-form various tasks, including telling them the names of people they meet but don’t remember. In this application, the device communicates with the Cloud for delay-tolerant jobs such as error reporting and logging. For time-sensitive tasks, the sys-tem streams video from the Glass camera to the for the device for processing. The system demonstrates how using nearby Fog devices dramatically decreases end-to-end latency [45].

Realising Fog computing’s full potential presents several challenges including balancing load distribution between edge and Cloud re-sources, API and service management and sharing, and SDN com-munications [41]. There are several other important examples, such as:

- Enabling real-time analytics since, in Fog environments, resource management systems should be able to dynamically determine which analytics task are being pushed to which Cloud or edge-based resource to minimise latency and maximise throughput. These systems also must consider other criteria such as vari-ous countries’ data privacy laws involving, for example, medi-cal and financial information [33].

- Security, reliability and fault tolerance are pressing challenges. De-signing and implementing authentication and authorisation tech-niques that can work with multiple Fog nodes that have differ-ent computing capacities is difficult. Public-key infrastructures and trusted execution environments are potential solutions [46]. Users of Fog deployments also must plan for the failure of in-dividual sensors, networks, service platforms, and applications [47].

- Power consumption since Fog environments consist of many nodes. Thus, the computation is distributed and can be less efficient than in the centralised Cloud systems. Using efficient commu-nication protocols can heavily minimise energy consumption in Fog environments [48].

2.1.2 Application Management in the Fog

As said, Fog computing aims at selectively pushing computation closer to where data is generated. This process will exploit a multitude of heterogeneous and geographically distributed devices (e.g., gateways, micro-datacentres, personal devices) enabling low latency responses to sensed events. It will alleviate the need for high bandwidth avail-ability from/to the Cloud [34].

In general, modern applications consists of several deployable com-ponents - each with its hardware and software requirements - that in-teract with each other. Latency and bandwidth are the most stringent QoS requirements that have to be addressed to obtain the expected be-haviour from the deployed application [17]. This kind of application is made by modules that naturally fit the Cloud and others that are suited to edge devices. Other modules, instead, need to be positioned in the middle: into the Fog [49]. It is not an immediate process: the heterogeneity of the infrastructure leads to a high number of prob-lems that the Application Operator have to solve before correctly de-ploy the application. The modules that have to be dede-ployed in the Fog have to be dynamically assigned to different nodes depending on QoS attributes of the infrastructure. The Application Operator mentioned above should be free from this kind of decisions that are not in his job description. The challenge is to decide how many and which Fog nodes the application requires for a successful deployment, find so-lutions that are fault-tolerant by fulfilling the requirements and save money [50].

Early approaches were manually considering the network topology and few characteristics of the nodes. Fog computing will support adaptive deployment to the infrastructure taking into account both application requirements and current state of the infrastructure making life easier to Application Operators.

prob-lems: algorithms and methodologies are used to help to decide how to map each application component to a substrate of heterogeneously capable and available node. They also include node mobility man-agement and take into account possible variation in the QoS of com-munication links (fluctuating bandwidth, latency, and jitter over time) supporting component-component interactions as well as the possibil-ity for deployed components to remotely interact with the IoT with proper interfaces. Also, the operational costs target and administra-tion or security policies are considered when selecting candidate de-ployments [25].

iFogSim

iFogSim [51] is a tool that enables the simulation of resource man-agement and application scheduling policies across edge and Cloud resources under different scenarios and conditions. The framework is designed in a way that makes it capable of evaluation of resource management policies applicable to Fog environments with respect to their impact on latency (timeliness), energy consumption, network congestion, and operational costs. iFogSim also allows application de-signers to test the design of their application against metrics like cost, network use, and perceived latency. It simulates edge devices, Cloud data centres, and network links to measure performance metrics [52].

FogTorchΠ

FogTorchΠ [29] is a prototype based on a model of the IoT+Fog+Cloud scenario to support application deployment in the Fog. It permits to express processing capabilities, QoS attributes and operational costs (i.e., costs of virtual instances, sensed data) of a Fog infrastructure, along with processing and QoS requirements of an application. In short, FogTorchΠ:

- determines the deployments of an application over a Fog in-frastructure that meet all application (processing, IoT and QoS) requirements

- predicts the QoS-assurance of such deployments against varia-tions in the latency and bandwidth of the communicavaria-tions link

- returns an estimate of the Fog resource consumption and a monthly cost of each deployment.

To handle input probability distributions and to estimate the QoS-assurance of different deployments, FogTorchΠ exploits the Monte Carlo method and a novel cost model that extends the existing pric-ing schemes for the Cloud to Fog computpric-ing scenarios, introducpric-ing the possibility of integrating such schemes with financial costs that originate from the exploitation of IoT devices in the deployment of applications.

Based on an input description of the requirements, FogTorchΠ deter-mines all the eligible deployments of the components of an applica-tion to Cloud and Fog nodes in a certain infrastructure. The idea of FogTorchΠ is to leave the final choice to the System Operators, per-mitting them to select the best trade-off freely among QoS assurance, resource consumption, and costs [21].

Few approaches have been proposed so far to specifically model Fog infrastructures and applications, as well as to compare eligible de-ployments for an application to a Fog infrastructure under different metrics. Then, the adoption of this kind of tool in a future well-established Fog infrastructure is crucial: it will allow a continuous adaptation of the modules deployed in the Fog keeping the infras-tructure efficient and ready to respond.

FogDirMime

FogDirMime [28] is a prototype based on an environment simulation for CISCO FogDirector [27]. It simulates the probabilistic (hardware and software) variations of the infrastructure. Indeed, those variations

happen independently of the type of management system used and, in general, they are unexpected.

FogDirMime can be exploited to experiment and compare different application management policies, so to predict the effectiveness of the deployment in a complex, yet simulated, environment, according to the specification of the Application Operator [23].

2.2 b u s i n e s s m o d e l l i n g t o o l s

In this era, countless innovative business models are emerging. En-tirely new industries are forming as old ones fall apart. New entries are challenging the old guard, some of whom are struggling to rein-vent themselves [53]. In the next paragraphs we will give deep insight into the nature of the business models introducing important tools like The Business Model Canvas and The Value Proposition Canvas. We also detail the Business Model Environment to identify the strategy de-velopment. Other tooling exist, like the one proposed by Paul Grefen in [54], but we will exploit the one by Ottenwalder et al. because it offers an intuitive overview on many topics analysed in this thesis.

2.2.1 The Business Model Environment

The Business Model Environment contains all the phenomena that the business cannot control by itself. Such modelling of the envi-ronment represents a way of structuring the strategy development process and design business model strategies. Develop a good un-derstanding of the organisation environment helps conceive stronger and more competitive business models. Continuous environment scan-ning is essential because of the growing complexity of the economic landscape, greater uncertainty and severe market disruptions. Under-standing changes in the environment help adapt the model more ef-fectively to shift external forces.

It is useful to imagine the external environment as a sort of design space. It is possible to think about it as a context in which to conceive or adapt the business model, taking into account a number of design drivers such as new customer needs, new technologies, new trends, and design constraints, e.g., regulatory trends and dominant competi-tors. The environment should influence the design choices helping make more informed decisions. To map the business model environ-ment and reflect on what trends mean for the future of the enterprise is a good way to understand it. As a result, it will allow evaluating bet-ter the different directions in which the business model might evolve. The next sections highlight the most important concepts needed in the definition of a Business Model Environment.

Market Forces

The Market Forces section is composed by:

- Market Issues identifies key issues are driving and transforming the market from Customer to Offer perspectives. It highlights the crucial issues that are affecting the customer, focuses on the shifts and the market direction,

- Market Segments identifies the major market segments describ-ing their attractiveness and seek to spot new entrants. Indeed, it reports which are the most important Customer Segments, identifying the potential growth and decline of customers. It also details about peripheral customers that deserve attention,

- Needs and Demands outlines market needs and analyses how well they are served. Reveal the customer needs, what they want to get done. Details about increasing or declining demand,

- Switching Costs describes elements related to customer switch-ing business to competitors. It reports what bind a customer to a certain company identifying the reasons why a customer could decide to switch. It also highlights how important is the

brands and how easy is for the customer to have similar offers in the market,

- Revenue Attractiveness identifies elements related to revenue at-tractiveness. Essentially it details where the largest margins can be achieved and the possibility of the customers to find and purchase a cheaper product or service.

Industry Forces

The Industry Forces section involves:

- Competitors (incumbents) identifies incumbent competitors and their relative strengths, defining the particular sector dominance and the various variable of dominance,

- New Entrants (insurgents) identifies new, insurgent players deter-mining whether they can compete with the business model of the value proposed. It details the competitive advantage and dis-advantages, the barriers and the Value Propositions of the new entrants, i.e., analysing the business models of the insurgents,

- Substitute Products and Services describes potential substitute for the offer including those that are for other market and indus-tries. Essentially, the product that can substitute the treated one and how easy could be for the customer to switch,

- Suppliers and other value chain actors that are the key value incum-bents in the market. This sector is also used to identify emerging players that can be peripheral,

- Stakeholders class specifies which actors may influence the or-ganisation and the business model, highlighting the influence of themselves.

Key Trends

The Key Trend section involves:

- Technology Trends is what identifies technology trends that could threaten the business model or enable it to evolve and improve. What is needed to consider are the major technology trends both inside and outside of the preferred market. It is impor-tant to identify the technologies that represent opportunities or disruptive threats. Also, deal with emerging technologies that peripheral customer is adopting,

- Regulatory Trends describe regulation and regulatory trends that may influence the business model. It is essential to study the reg-ulatory trends that influence the market understanding which are the rules that may affect the business model. Also, the regu-lation and taxes that may affect the customer demand must be checked,

- Societal and Cultural Trends identify the major societal trend that may influence the business model. Investigating key societal trends and the shifts in cultural or societal values that can af-fect the business model can be a crucial check. Also, there can be trends that influence the buyer behaviour,

- Socioeconomic Trends outlines major socioeconomic trends rele-vant to the business model. In this case, the attention goes to the characterisation of the income and wealth distribution in the preferred market. An important parameter can be the por-tion of the populapor-tion that lives in the urban area with respect to the rural settings.

Macro-Economic Forces

The Macro-Economic Forces section comprehend:

- Global Market Conditions outlines current overall conditions from a macroeconomic perspective. It defines whether the economy is in a boom or bust phase, describe the general market senti-ment and the unemploysenti-ment rate,

- Capital Markets describes current capital market conditions as they relate to the capital needs. It details about the state of the capital markets and studies the possibility to receive funds,

- Commodities and other resources subsection highlights current prices and price trends for resource required for the business model. It describes the current status of markets for commodities and other resources essential to the business. Also, easiness to obtain the resources needed to operate the business model,

- Economic Infrastructure that describes the economic infrastruc-ture of the market in which the business model operates. It is essential to understand how good is the infrastructure in the market, also detailing the costs and the quality of the access to suppliers and customers.

2.2.2 The Business Model Canvas

The starting point of any good discussion, meeting or workshop on business model innovation should be a shared understanding of what a business model is. What is needed is a concept that everybody understands, e.g. one that facilitates the description and discussion. The challenge is that the concept must be simple, relevant, and in-tuitively understandable without oversimplifying the complexity of crucial functions. The idea is to have a shared language that allows business people to describe or manipulate business models to cre-ate strcre-ategies easily. Without such a shared language it is difficult

to systematically challenge assumptions about one’s business model and innovate successfully. A business model can best be described through nine basic building blocks the show the logic of how a com-pany intends to make money. The nine blocks cover the four main areas of a business, that are:

- customers, i.e. a person who buys goods or services from the treated company,

- offer, i.e. a proposal to sell or buy a specific product or service under specific conditions,

- infrastructure, i.e., the fundamental facilities of the company,

- financial viability that is the ability of an entity to continue to achieve its operating objectives and fulfil its mission over the long term.

The business model is like a blueprint for a strategy to be implemented through organisational structures, processes and systems. Figure 2.1 depicts an empty Business Model Canvas that is the starting point of any business.

Figure 2.1: Empty Business Model Canvas

To generate new business models, a crucial part is understand which is the epicentre [53]. Indeed, ideas for business models can come

from each of the nine building blocks that can be a starting point. Each of the epicentres can serve as a starting point for a business model change, and each can have a powerful impact on the other eight building blocks. We can distinguish four epicentres of business model innovation, namely:

- Resource-Driven that originates from an organisation’s existing infrastructure of partnership to expand or transform the busi-ness model, e.g., the epicentre is the Key Partnerships building block,

- Offer-Driven that creates new value propositions that affect other business model building blocks, indeed here the epicentre is exactly the Value Propositions one,

- Customer-Driven that is based on customer need, facilitated ac-cess, or increased convenience. Like all innovations emerging from a single epicentre, they affect other business model build-ing blocks. The epicentre is the Customer Segment buildbuild-ing block, and

- Finance-Driven that is driven by Revenue Streams, pricing mecha-nisms, or reduced Cost Structures that affect other business mod-els building blocks. This is a case of a double epicentres, e.g., Revenue Streams and Cost Structures.

In the following sections we detail each one of the Building Blocks that compose the Business Model Canvas, as Figure2.1suggests.

Customer Segments

The Customer Segment Building Block defines the different groups of people or organisations an enterprise aims to reach and serve. Cus-tomers comprise the heart of business models. Without profitable customers, no company can survive. To better satisfy the customers, the enterprise may group them in different segments with common

needs, attributes or behaviour. A business model may define different large or small Customer Segments and the organisation must take a conscious decision about which segment serve better or even ig-nore. After the decision is made, the business model can be designed around the understanding of the customer needs.

There are different types of Customer Segments. Here some exam-ples:

- Mass Market - business models focused on the mass market do not distinguish between different Customer Segments. The Value Propositions, Distribution Channels, and Customer Rela-tionships all focus on one large group of customers with similar need and problems,

- Niche Market - business models targeting niche markets cater to specific, specialised Customer Segments. Everything is ori-ented to the specific requirements of the customers. Such busi-ness models are often found in supplier-buyer relationships,

- Segmented - some business models distinguish between market segments with slightly different needs and problems. Consider Micro Precision Systems, which specialises in providing out-sourced micro-mechanical design and manufacturing solutions. It serves three different Customer Segments â the watch indus-try, the medical indusindus-try, and the industrial automation sector â and offers each slightly different Value Propositions [55],

- Diversified - an organisation with a diversified customer busi-ness model serves two unrelated Customer Segments with very different needs and problems. For example, in 2006 Amazon.com [56] decided to diversify its retail business by selling Cloud com-puting services, e.g., online storage space and on-demand server usage [57]. Thus it started catering to a different Customer Seg-ment with a totally different Value Proposition,

- Multi-sided platforms (or multi-sided markets) - some organisation serve two or more interdependent Customer Segments. A credit card company, for example, needs a large base of credit card holders and a large base of merchants who accept those credit cards.

Value Propositions

The Value Proposition Building Block describes the bundle of products and services that create value for a specific Customer Segment. It is the reason why customers turn to one company over another. It solves a customer problem or satisfies a customer need. Each Value Proposition consists of a selected bundle of products and services that caters to the requirements of a specific Customer Segment. Some Value Proposition may be innovative and represent a new or disrup-tive offer. Others may be similar to existing market offers, but with added features and attributes.

The value can be created by simply helping a customer get certain jobs done. Another important but difficult element is the design. A product may stand out because of superior design. In the fashion and con-sumer electronics industries, design can be a particularly important part of the Value Proposition. Customers may find value in the sim-ple act of using and displaying a specific brand. On the other hand, offering similar value at a lower price is a common way to satisfy the needs of a price-sensitive Customer Segments. Helping customers re-duce costs is a meaningful way to create value. The value can also be done by reducing the risk when purchasing product or services, e.g., for a used car buyer, a one-year service guarantee reduces the risk of post-purchase breakdowns and repairs. Making product and ser-vices available to customers who previously lacked access to them is another way to create value. This can result from business model in-novation, new technologies or a combination of both. Also making things more convenient or easier to use can create substantial value. With iPod and iTunes, Apple [58] offered customers unprecedented

convenience, buying, downloading and listening to digital music. It now dominates the market [59].

Channels

The Channels Building Block describes how a company communicates with and reaches its Customer Segments to deliver the Value Propo-sition. Communication, distribution, and sales Channels comprise a company’s interface with customers. Channels are customer touch points that play an important role in the customer experience. Chan-nels are useful for many reasons, e.g., to raise awareness among cus-tomers about a company’s products and services, to help cuscus-tomers evaluate a certain Value Proposition, to allow customers to purchase specific product and services, to deliver a Value Proposition to cus-tomers and to provide post-purchase customer support.

Channels have five distinct phases. Each channel can cover some or all of these phases. It is possible to distinguish between direct and indirect ones, as well as between owned Channels and partner Chan-nels. Finding the right mix of Channels to satisfy how customer want to be reached is crucial. Owned Channels can be direct, such as an in-house sales force or a Website, or they can be indirect such as retail stores owned or operated by the organisation.

Partner Channels lead to lower margins, but they allow an organisa-tion to expand its reach and benefit exploiting the partner strengths. Owned Channels are characterised by higher margins, in particular, the direct ones, but they can be costly. The idea is to find the right trade-off and balance between all of this factors to maximise the rev-enues creating a good customer experience.

Customer Relationships

The Customer Relationships Building Block describes the types of rela-tionships a company establishes with specific Customer Segments. A company should clarify the type of relationship it wants to establish with each Customer Segments. Relationships can range from personal

to automated. Customer relationships can be driven by customer ac-quisition or retention, or by upselling. It is possible to distinguish between several categories of Customer Relationships, which may co-exist in a company’s relationship with a particular Customer Seg-ment.

The personal assistance is based on human interaction. The customer communicates directly to a representative or employee to get help during the sales process or to get assistance after the purchase. This may take place in point of sales or through call centres, via email or through other means.

The dedicated personal assistance involves dedicating a customer repre-sentative specifically to an individual client. It represents the deepest and most intimate type of relationship and normally develops over a long period.

In the self-service relationship, a company maintains no direct rela-tionship with customers. It provides all the necessary means for cus-tomers to help themselves.

The automated services relationships mix a more sophisticated form of customer self-service with automated processes. Automated services can recognise individual customers and their characteristics, and of-fer information related to orders and transactions. Customers have access to customised services through their online profile. At their best, automated services can simulate a personal relationship, e.g., of-fer a book or recommend a movie.

The co-creation relationship consist in the co-creation of the value. For instance, Amazon.com [56] has developed a system in which is the user that reviews the product, leaving a sort of feedback for future buyers. YouTube.com [60] present another co-creation relationship in which the customer is solicited to create content for public consump-tion.

Companies are utilising communities to become more involved with customers and to facilitate a connection between community mem-bers. Many companies maintain forums that allow users to exchange

knowledge and solve each other’s problems.

Revenue Streams

The Revenue Streams Building Block represents the income a company generates from each Customer Segments. A company must perform a market investigation to understand for what the customer is willing to pay. Each Revenue Stream may have different pricing mechanism. In general, a business model can have two kinds of Revenue Stream, namely:

(a) Transaction Revenues resulting from one-time payments,

(b) Recurring Revenues resulting from an ongoing payments, e.g., post-purchase customer support or subscriptions.

There are several ways to generate Revenue Streams, e.g., the as-set sale in which the company sells its physical product, the usage fee where the revenue is generated by the use of a particular service. Oth-ers format like subscription fee and licensing are those more related to the ICT market, in which the user pays a periodic fee to use a certain service or pay one time (per year) for a license of a tool. Close enough to this world are also the brokerage fee and the advertising formats. The former is used by companies that gather all service together to allow the customer to choose the more appropriate solution.

The difference in pricing mechanisms can make a big difference in the business model. There are two kinds of pricing mechanisms, e.g., fixed and dynamic. The Fixed Menu Pricing is characterised by fixed prices based on static variables that can be product feature dependent, customer segment dependent or volume dependent, i.e., the price is a function of the quantity purchased. Instead, the Dynamic Pricing is based on market conditions, e.g., negotiation, yield management, real-time market and auctions.

Key Resources

The Key Resources Building Block describes the most important assets required to make a business model work. All the business models require resources that allow an enterprise to create a certain Value Proposition, reach a market and maintain relationships with Cus-tomer Segments, to the end of earn revenues. Key resources can be categorised as:

- Physical - assets such as manufacturing facilities, building, ve-hicles, systems, point-of-sales and distribution networks,

- Intellectual - such as brands, proprietary knowledge, patents and copyrights, partnerships and customer databases,

- Human - scientists, sales force, human-resource, and

- Financial - cash, lines of credits, stock option pool for hiring key employees.

Key Activities

The Key Activities Building Block describes the most important things a company must do to make its business model work. The key activ-ities are significant actions a company must take to operate success-fully. They are required to create and offer a Value Proposition, reach markets and maintain Customer Relationships. Also, they can be dif-ferent depending on the business model type. The most valuable key activities may be:

- Production - activities related to designing, making and deliv-ering the product. Production activities dominate the business models of manufacturing firms,

- Problem Solving - activities related to coming up with new so-lutions to individual customers problems. Problem-solving ac-tivities typically dominate operations like consulting, hospitals and other service organisations,

- Platform/Network - business models designed with a platform as a Key Resource. Networks, matchmaking platform, software, and even brands can function as a platform. eBay [61] business models require that the company continually develop and main-tain its platform [62].

Key Partnerships

The Key Partnerships Building Block describes the network of suppliers and partners that make the business model work. Companies make al-liances for many reasons and those are the cornerstone of many busi-ness models. It is done to optimise the busibusi-ness models, reduce risks, or acquire resources. There are four types of partnerships, namely:

(a) Strategic Alliances between non-competitors,

(b) Coopetition: strategic partnerships between competitors,

(c) Joint ventures to develop new businesses,

(d) Buyer-supplier relationships to assure reliable supplies.

There are many reasons to forge key partnerships, three of the most important:

- Optimisation and economy of scale - the most basic form of part-nership or buyer-supplier relationship. It is designed to opti-mise the allocation of resources and activities. Optimisation and economy of scale are formed to reduce costs, outsource or share infrastructure,

- Reduction of risk and uncertainty - partnerships can help reduce risk in a competitive environment that is characterised by un-certainty,

- Acquisition of particular resources and activities - it is possible to extend the capabilities of a company relying on other firms to furnish particular resource or address certain problems. It is

the case in which partners share knowledge, licenses or access to customers.

Cost Structure

The Cost Structure describes all costs incurred to operate a business model. This building block explains the costs related to the delivery of the value, maintenance Customer Relationships and generation of the revenues. Some business models are more cost-driver than oth-ers. Naturally, costs should be minimised in any case, but low Cost Structures may be more important to some business models that to others. Therefore it can be useful to distinguish between two classed of Cost Structures, e.g., cost-driven and value-driven. The former re-lated business model focuses on minimises costs wherever is possible while the latter is less concerned with the cost implication of a partic-ular design and instead focus on value creation. The best known and common characteristics of the Cost structure may be:

- Fixed costs - they remain the same despite the volume of goods or services produced, e.g., salaries, rents, physical manufactur-ing facilities,

- Variable costs - they vary proportionally with the volume of goods or services produced,

- Economies of scale - they are characterised by advantages that a business enjoys as its outputs expand, e.g., larger companies benefit from lower bulk purchase rates,

- Economies of scope - business enjoys advantages due to a larger scope of operations, e.g., supporting multiple products.

2.2.3 Business Model Patterns

Very often business models, even if disruptive or groundbreaking, present similar characteristics and arrangements of business model

Building Blocks, resulting in similar behaviours. These similarities are called business model patterns. In the next sections, we detail the most important Business Model Patterns that are characterising the current market and that will be used in defining the strategies for predictive application management in Chapter4highlighting advan-tages and properties.

Multi-Sided Platforms

The Multi-Sided Platforms pattern bring together two or more dis-tinct but interdependent groups of customers. Such platforms are of value to one group of customers only if the other groups of customers are also present [63]. The platform creates value by facilitating inter-actions between different groups. A multi-sided platform grows in value to the extent that it attracts more user, a phenomenon know as the network effect [64].

Multi-sided platforms, known by economists as multi-sided markets, are an important business phenomenon that got its major prolifera-tion with the rise of informaprolifera-tion technology. The Visa credit card [65], the Microsoft Windows operating system [66], Google [67] and the Wii game console [68] are just a few examples of successful multi-sided platforms.

This pattern brings together two or more distinct but interdepen-dent groups of customers creating value as intermediaries connecting them. The key is that the platform must attract and serve all groups simultaneously in order to create value. The platform’s value for a particular user group depends substantially on the number of users on the platform’s other sides. Hence, multi-sided platforms often face a chicken and egg dilemma.

One way multi-sided platforms solve this problem by subsidising a Customer Segment. A company often decides to lure one segment to the platform with an inexpensive or free Value Proposition to subse-quently attract users of the platform’s other side. One difficulty that multi-sided operators face is understanding which side to subsidise

and how to price correctly to attract customers.

FREE as a Business Model

In the FREE business model, at least one substantial Customer Seg-ment is able to benefit from a free-of-charge offer continuously. Dif-ferent patterns make the free offer possible. Non-paying customer are financed by another part of the business model or by another Customer Segment [69,70].

Receiving something for free has always been an attractive Value Proposition. It has been confirmed that the demand generated at a price of zero is many times higher than the demand generated at one cent or any other price point. In the recent years, free offers have exploded, particularly over the Internet. The companies that adopt this kind of business model have to face the problem of revenues. In general, traditional free patterns provide basic services free of charge and premium services for a fee. They have become popular in step with the increasing of digitisation of goods and services offered via the Web.

Anderson in [70] shows that the rise of new free-of-charge offers is closely related to the fundamentally different economics of digital products and services. For example, creating and recording a song costs an artist time and money, but the cost of digitally replicating and distributing the work over the Internet is close to zero.

The FREE business model pattern is a specialisation of other patterns, i.e., it is possible to utilise the free-of-charge strategy with other pat-terns. Indeed, the most important cases are related to three patters, namely:

- Free offer based on multi-sided platforms (advertising-based). It is essentially the example of Google [67] in which one side of the platform is designed to attract users with free content, products, or services while the other side generates revenue by selling space to advertisers.,

- Free basic services with optional premium services (freemium-model). It stands for business models, mainly Web-based, that blend free basic services with paid premium services. It is characterised by a large user base benefiting from a free, no-strings-attached offer. Although most of these never become paying customers, there is a small portion that subscribes to premium services. One example is Skype [71], a freemium pattern that disrupted the telecommunications sector by enabling free calling services via the Internet.

- The bait & hook model is characterised by an attractive, inexpen-sive, or free initial offer that encourages continuing future pur-chases of related products or services. It refers to a subsidised, even money-losing initial offer with the intention of generating profits from subsequent purchases. The term bait&hook pattern is used to describe the idea of luring customers with an ini-tial offer while earning from follow-up sales. One example is related to Gillette [72] that in 1904 starts to sell first disposable razor blade systems and decided to give away the razor handles to create demand from disposable blades.

2.2.4 The Value Proposition Canvas

The Value Proposition Design is about applying Tools to disorderly search for value propositions that customers want and then keep them aligned with post searches. The Value Proposition Canvas is the tools that make value propositions visible and tangible and thus easier to discuss and manage [73].

Value Proposition Canvas perfectly integrates with the Business Model Canvas (Section 2.2.2) and the Business Model Environment (Section 2.2.1). Together they shape the business creation in every detail. Ottelwalder in [73] claims that the value proposition canvas zooms into the details of two of the building blocks of the business

model canvas, e.g., the Customer Segments and the Value Proposition building blocks, as depicted in Figure2.2.

Figure 2.2: Zoom on the suite of Business tools as in [73]

The Value Proposition Canvas is composed of two sides, e.g., the Value Map that is used to create value for that customer and the Cus-tomer Profile that clarifies the cusCus-tomer understanding. The former describes the features of a specific value proposition in the business model in a more structured and detailed way. It breaks the value proposition down into product and services, pain relieves and gain creators. The latter, instead, describes a specific customer segment in the business model in a more detailed way. It breaks the customer down into its jobs, pain and gains. The categories mentioned above are the content of the Value Proposition Canvas shown in Figure 2.3 and they will be detailed in the following sections.

Figure 2.3: Empty Value Proposition Canvas

Customer Jobs

This part of the Value Proposition Canvas is used to list what the customers want to get done in their work. A customer job could be the task that they are trying to perform or the problems that they are trying to solve. In defining this section, it is important to take the customer’s perspective considering three types of customer jobs, namely:

- Functional Jobs in which the customer try to perform or complete a specific task or solve a specific problem,

- Social Jobs in which the customer want to look good or gain power or status. These jobs describe how customers want to be perceived by others,

- Personal/Emotional Jobs in which the customer seeks a specific emotional state, such as feeling good or secure.

Customers also perform supporting jobs in the context of purchasing and consuming value either as a consumer or as professionals. These jobs arise from three different roles, such as:

- Buyer of value that is the job related to buying value deciding which product to buy,

- Co-creator of value that is the job related to the co-creation of value with the company,

- Transferrer of value that is the job related to the end of a value proposition’s life cycle.

Consumer jobs often depend on the specific context in which they are performed. Indeed, the context may impose certain constraints or lim-itations. It is also important to acknowledge that not all the jobs have the same importance for the customers. Some are more important than others that may be insignificant since the customer cares about other things.

Customer Pains

The Pain section describes anything that annoys the customer before, during, and after trying to get the job done or prevent from getting the job done. It is used to list the risks that lead to potential bad out-comes or failures of the job. The customer pains are of three types, namely:

- Undesired outcomes, problems and characteristics in which pains are functional, emotional, social, or ancillary. This part may also involve undesired characteristics that customers do not like,

- Obstacles that are the things that prevent the customers from even getting started with a job or that slow them down, and

- Risks that are essentially what can go wrong heading to impor-tant consequences.

A customer pain can be extreme or moderate similar to how jobs can be important or insignificant as detailed in the previous section.

Customer Gains

The Gains section describe the outcomes and benefits that the cus-tomer wants. Gains include functional utility, social gains, positive emotions and costs savings. In general, there are four types of gains regarding outcomes and benefits, namely:

- Required gains that are gains without which a solution would not work,

- Expected gains that are relatively basic gains that anyone expects,

- Desired gains that go beyond the expectation of a solution,

- Unexpected gains that not only go beyond the expectation but also bring unanticipated benefits.

As the previous blocks, also gains block presents a level of relevance, e.g., they can be essential to have them, or nice to have.

Products and Services

This section details a list of what the business model offer. The bundle of products and services helps the customers complete either func-tional, social, or emotional jobs, or helps them satisfying basic needs. It is important to understand that the product does not create the value, it must be thought concerning a specific customer segment and their jobs, pains and gains.

The list of products may also include supporting ones that help the customer perform the role of buyer, co-creator, and transferrer. There could be different types of product and services, such as:

- Physical/tangible such as goods and manufactured products,

- Intangible, a product such as copyright or services like after-sales assistance,

- Digital, a product such as music downloads or services like on-line recommendations,

- Financial, a product such as investment funds and insurances, or services like financing of a purchase.

As before, this section is characterised by a level of relevance, e.g., it is essential to have a certain product or nice to have.

Pain Relievers

The pain relievers section detail how products and services proposed in the business model alleviate specific customer pains. They outline how the value intents to eliminate or reduce some of the things that annoy the customers before, during or after they are trying to com-plete a job. In general, value propositions focus on pains that matter to customers. Indeed, it is not necessary to come up with a pain re-liever for every pain identified in this building block.

A pain reliever can be more or less valuable to the customer. It is im-portant to differentiate between essential pain reliever and ones that are nice to have. The former relieve extreme issues, while the latter merely relieve moderate pains.

Gain Creators

The gain creators section describe how the product and service create customer gains. It is used to explicitly outline how the value intends to produce outcomes and benefits that the customer may expect, de-sire or would be surprised by. This section includes functional utility, social gains, positive emotions and costs savings. As with pain reliev-ers, gain creators do not need to address every gain identified in the customer profile. It is essential to focus on what is relevant for the customer and where the product or service can make a difference. As the previous building blocks, a gain creator may be essential or nice to have.

3

B U S I N E S S M O D E L E N V I R O N M E N T

Outline

This chapter describes the Business Model Environment (Section 2.2.1) related to predictive application management in Fog computing scenarios. The description of the Business Model Environment helps us in setting the design space [53] that we considered when defining possible business models that will be presented later on, in Chapter 4.

Particularly, the Business Model Environment, is made from [53]:

(a) the Market Forces (Sect. 3.1), which comprise market segments, needs and demands, market issues, switching costs and revenue attractiveness, that are currently shaping the market for predic-tive application management in Fog computing,

(b) the Industry Forces (Sect. 3.2), which cover stakeholders, com-petitors, new entrants, suppliers and other value chain actors as well as substitute products and services that can affect the business strategies of the considered service,

(c) the Key Trends (Sect.3.3), which include regulatory, technology, socio-economic, societal and cultural trends that are currently characterising the business environment, and

(d) the Macro-Economic Forces 3.4), which comprehend global mar-ket conditions, capital marmar-kets, economic infrastructure and com-modities, that might influence the successful adoption of predic-tive management of Fog applications.

In what follows, we will consider and describe three different stake-holders which characterise the business environment, namely:

- Asset Manufacturers (AM) that are producing components and systems for the infrastructure, e.g., CISCO [74] and Dell [75] that are key actors in this market,

- Infrastructure Providers (IP) that (i) already own and manage part of a potential Fog infrastructure (e.g., Telco or Cloud providers), (ii) that are planning to invest in building a new one (e.g., new Fog providers [76]), or (iii) that are willing to share their comput-ing capabilities in Fog networks (e.g., private users/businesses [77]),

- Application Operators (AO) that deploy applications to the Cloud and to the Fog, e.g., private users, business employee or who-ever manages the life cycle of one or more applications. They are responsible for the definition of the QoS specification that the application requires, the effectiveness of the deployment and the proper management of the software system landed.

3.1 m a r k e t f o r c e s

Table3.1provides an overview of the Market Forces influencing the business environment for predictive application management in the Fog. Each of them will be retaken and detailed in the following sec-tions.

Market Issues is a continuum Cloud-IoT -need to filter data befor e the Cloud F og is lar ge, heter ogeneous and highly distributed infrastr ucture requir es pr oper resour ce and w orkload management M odern ha v e har dw ar e, softw ar e, QoS requir ements to be met softw are systems featur e lar ge and complex topologies Market S egments Asset Manufactur ers (AM) Infrastructur e Pr o viders (IP) Application Operators (AO) Needs and Demands AMs w ant to enrich their Fog platfor m and the y w ant to sell their Fog-enabling de vices IPs w ant to of fer appr opriate ser vices to the customers optimising the ser vice av ailability AOs w ant their application requir ements (hw , sw , QoS) fulfilled, av oiding manual tw eaking Switching Costs Not kno wn established competitors at the moment Bind customers to the ser vice, of fering high quality results Impose on the market starting a branding pr ocess collaborating with IPs Re v enue Attractiv eness AMs could integrate the pr edictiv e application management in their pr oduct suite IPs could impr o v e the attractiv eness to their customers b y of fering pr edictiv e application management AOs could pr edict befor ehand perfor mance and cost of their management/deplo yment A pr edictiv e application management company should exploit the first mover adv antage T able 3. 1: Market For ces

Market issues

In this section, we are going to describe the major issues that the main stakeholders, detailed at the beginning of this chapter, are fac-ing, highlighting the shifts and directions of the current market. Com-puting resources are moving more and more from the Cloud to the edge of the network. This movement is expected to ease the life of the end user, facilitate industries, improve production and even save lives [78]. Indeed, many of the applications that have been envisioned for Edge/Fog computing scenarios, relating to different verticals such as smart buildings [24], Industry 4.0 [79], e-health [80] and self-driving cars [81], are considered mission- or life-critical.

The IT market is naturally moving towards this direction. For in-stance, Google is already producing smart building devices such as the Google Home, empowering inhabitants or visitors of intelligent environments with support to their daily activities [82].

Industrial manufacturers are also facing a shift that comes from the combination of computing resources at the edge and IoT, resulting in a paradigm change in the industrial production, e.g., physical items that are enriched with embedded electronics (e.g., RFID tags) and connected to the Internet [83], and automated production chains [84]. Furthermore, the number of smartwatches sold only in 2018 reaches 141million units and it has been more than doubled every year since 2014[85]. Finally, in the transportation field, vehicles are now being enriched with sensor platforms that collect information from the en-vironment and process it to assist in safe navigation, pollution control and traffic management [86]. Overall, CISCO envisions 500 billion de-vices are expected to be connected to the Internet by 2030 [87]. In this context of continuous growth of IoT systems and of the data they produce, there is a clear need of processing/filtering informa-tion before it reaches the Cloud so to meet prompter decision making and reactions [21]. Considering as potential customers the stakehold-ers we described at the beginning of this chapter, the key issues they are facing relate to taming the scale and complexity of both the

archi-tecture of modern software systems and the infrastructure support-ing them. Indeed, simultaneously and optimally managsupport-ing a complex system (the application) on top of another (the infrastructure) is in-trinsically challenging and it requires suitable tooling [17].

On one hand, different paradigms have been proposed (e.g., Mist Computing [88], micro-clouds [89], Edge Computing [40]) that will give rise to large and complex Fog infrastructures deployed over the continuum from the IoT to the Cloud and characterised by high geo-distribution, node heterogeneity, seamless connectivity and mobility of nodes and devices [36]. All these together, constitute important is-sues related to the infrastructure management.

Particularly, Infrastructure Providers have to face:

- (optimal) resource management and allocation [90] and

- (optimal) workload allocation [91]

to properly manage their systems and systematically provide service level guarantees to their customers.

On the other hand, the architectural evolution of software systems (from Software Oriented Architectures [92] to multi-component [93] to micro-services [94]) has made more and more complex the struc-ture of the applications that have to be deployed and managed. In-deed, modern software systems are characterised by hardware, soft-ware and QoS requirements. For instance, a certain application could need:

- a certain amount of RAM, CPUs and hard-disk,

- availability of a certain OS and of the needed libraries and soft-ware frameworks, and

- latency-, bandwidth-, security-, deployment cost-, or scalability-related constraints to be met.

In the Fog environment, Application Operators will face the burden of large and complex infrastructures. She needs guarantees that the