Keywords

6.1 Introduction

The advent of Internet-of-Things (IoT) cloud-based solutions has represented a relevant technological breakthrough, whose benefits will be fully revealed and realized in the next future. IoT is expected to generate a strong impact on the firms’ activities and operations, on the relationships among various agents (both firms and public institutions), and eventually on the way in which citizens (customers) interact among them within the society. Therefore, an increasing number of firms and governments have started to invest heavily in the development of such technologies, in order to obtain a leading position that might guarantee in the future the exploitation of a sustainable competitive advantage.

To fully exploit the technology and benefit from it, firms need to pursue a business model (that is, to organize all the activities, from value proposition to value delivery) (Teece 2010; Zott and Amit 2010) that perfectly fits its inner characteristics and totally exploits its specific features. Indeed, similarly to past technological breakthroughs (e.g., the advent of electricity or, more recently, that of biotechnologies), which have been studied by historicists of technology (Rosenberg 1976), new technological paradigms often impose firms to think at a different organization of labor and at a diverse way of designing and creating value propositions (Amit and Zott 2001). In the case of IoT cloud-based computing, a similar process is, therefore, to be expected.

Accordingly, this study addresses the following research question: which business models might be pursued by firms to benefit from the advantages offered by IoT cloud-computing?

To answer this research question, it analyzes the practical case of FIWARE, a recently funded EU initiative, which has seen the involvement of different actors (from large IT operators to small software developers) with the objective of developing an IT-based platform for potential business purposes. By examining the case of FIWARE, it thus explores the features that IoT cloud-based open business models should have. In doing so, while it also considers the perspective of large firms involved in the development of the IT platform, it mainly focuses on small software operators involved in the development of subsequent applications.

In the next section, it starts by providing a theoretical framework needed to address the empirical analysis. In Sect. 6.3, it explains the methodological approach it has followed to perform the analysis, whose results are shown in Sect. 6.4. Finally, Sect. 6.5 concludes the paper by discussing the managerial and theoretical implications of this study.

6.2 Theoretical Framework

6.2.1 General Purpose Technologies and Open Innovation

During the last decades, prior research on Open Innovation (Chesbrough 2003) has shown that firms may benefit from collaborations with external partners by allowing the in-flow of external technologies and technological competences. In fact, external technologies may be integrated with the internal technological base in order to generate new products/services and enhance the firm’s ability to create value. This process of technology in-flow may be undertaken along the entire process of innovation development, since the initial stages of basic research, to the latter stages of product and service design.

Apart from internal strategic consideration, two main conditions may limit the firms’ possibility to exploit an Open Innovation approach: (1) the lack of adequate absorptive capacities (Cohen and Levinthal 1990; Zahra and George 2002); and, (2) the difficulty to set-up strong appropriability mechanisms that protect partners’ intellectual property from uncontrolled deployment by third parties (Cohen et al. 2000). As for the former, firms need to invest in both scientific and technological research that allow them to monitor the external technological environment, identify the owners of complementary technological skills and competences, integrate external technological knowledge with the internal knowledge base, and eventually convert the potentialities offered by external technologies into actual products and services capable of generating a competitive advantage. As for the latter, firms both need to protect their technologies with patents and other forms of intellectual property rights, and to negotiate with potential partners the allocation of property rights on exchanged technologies.

Only once these two conditions are met and difficulties associated to their implementation overcome, firms may take full advantage of collaborations with external technology suppliers. Traditionally, firms that have undertaken such an approach have pursued an open business model (Teece 2010; Zott and Amit 2010; Chesbrough 2006) characterized by a strict control over the core elements of the technology to be embedded into innovative products and services, while external technology acquisitions have been limited to marginal and complementary technological components, often customized by the external supplier for the benefits of the potential technology user. In other words, technologies and technological knowledge exchanged in innovative collaboration processes are often specialized and (co-)developed ad-hoc to solve contextual problems.

However, when technologies object of exchange are General Purpose Technologies (GPTs), as in the case of IT platforms analyzed in this study, different forms of open business model may be pursued by partners, with advantages for both technology suppliers and technology users. Indeed, as prior research has shown (Helpman 1998; Gambardella and McGahan 2010), GPTs allow a different configuration of division of labor at the industry level and a different organization of the innovative process. A simple comparison between the business models based on Specialized Technologies (STs) with respect to business models focused on GPTs allows to fully get the sense of the advantages provided by GPTs. As shown in Fig.6.1a), in the case of an ST setting, the external technology is developed to fully respond to the potential user’s application needs and to be fully integrated into its internal knowledge base. In this situation, the development costs of the specialized (that is, customized) external technology are totally incurred in by the technology supplier, while the technology user only incurs in the indirect costs of developing an absorptive capacity and of securing internal intellectual assets. Adaptations costs of external technology to internal needs, albeit not absent, can be supposed to be limited, given the fact that it is the technology supplier mainly in charge of providing a technological solution that fits context-dependent conditions.

Fig. 6.1
figure 1

(a, b) ST vs. GPT user-supplier interaction

By contrast, in the case of a GPT setting (Fig. 6.1b), the technological solution developed by the technology supplier does not respond to any specific (context-dependent) application condition, but is intended to satisfy a large number of possible application needs, not necessarily closely related one to the other. Indeed, the more general the technology is, the larger the number of application domains that can be served by the same GPT. In this case, albeit a ST solution implies a customization effort, the cost to develop a GPT is likely to be higher than that of a ST, provided that it requires to overcome the limited context-dependent conditions of a narrow application domain. Furthermore, the development of GPTs is often associated to the development of ad-hoc toolkits (Von Hippel and Katz 2002), which the technology supplier provides to users in order to facilitate the adaptation of the GPT to their local conditions.

Provided that such toolkits avoid adaptation costs to be excessively high for the users, both technology suppliers and technology users may benefit from a GPT setting: with respect to a ST setting, technology suppliers may more than compensate the extra costs of generalization of the technology by selling it to a larger number of customers (application domains); and technology users may benefit from a more stable technology, which has been already applied to other technological domains, without incurring in excessive adaptation costs.

6.2.2 General Purpose Technologies, Technical Platforms and Ecosystem Innovation

Since they are usually depicted as an interface between different groups of suppliers and users that facilitate value-creation exchanges (Evans 2003; Gawer 2010; Rochet and Tirole 2006), IT platforms are meant here as a perfect example of GPTs. In particular, they build on the modularizations of complex systems in which certain components (the platform itself) remain stable, while others (the complements) are encouraged to vary in cross-section or over time (Baldwin and Woodard 2009). In any platform system, there are three types of components: (1) the “complements”, which exhibit high variety and high rates of change over time; (2) the “core components”, which remain stable as the complements change; and (3) the “interfaces”, which are the design rules that allow the core and the complements to operate as one system. Both the core components and the interfaces are relatively long-lived, hence part of “the platform.”

Long-established research (Gawer and Cusumano 2013) has defined two predominant types of platforms: “internal” or “company-specific” platforms, and “external” or “industry-wide” platforms (i.e., the main subject of this paper). Whereas internal (company or product) platforms are conceived as a set of assets organized in a common structure from which a company can efficiently develop and produce a stream of derivative products, external (industry) platforms are conceived as products, services, or technologies that act as a foundation upon which external innovators, organized as an innovative business ecosystem, can develop their own complementary products, technologies, or services. Additionally, while internal platforms allow their owner to achieve economic gains by re-using or re-deploying assets across families of products developed by either the firm or its close suppliers, industry platforms facilitate the generation of a potentially very large number of complementary innovations by tapping into the innovative capabilities of many external actors, and function as a technological foundation at the heart of innovative business ecosystems.

To perform this industry-wide role and convince other firms to adopt the platform as their own, the external platform must (1) perform a function that is essential to a broader technological system, and (2) solve a business problem for many firms and users in the industry. While necessary, these conditions alone are not sufficient to help firms transform their products, technologies or services into industry platforms, nor indicate how platform leaders can stimulate complementary innovations by other firms, including some competitors, while simultaneously taking advantage of owning the platform (Gawer and Cusumano 2002).

The most critical distinguishing feature of an industry platform is the potential creation of network effects (Iyer et al. 2006). These are positive feedback loops that can grow at exponentially increasing rates as adoption of the platform and the complements rise. The network effects can be very powerful, especially when they are “direct” between the platform and the user of the complementary innovation and reinforced by a technical compatibility or interface standard that makes using multiple platforms (“multi-homing”) difficult or costly (McIntyre and Subramaniam 2009). For example, Windows applications or Apple iPhone applications only work on compatible devices. The network effects can also be “indirect” or “cross-side,” and sometimes these are very powerful as well (Clements and Ohashi 2005). These occur when, for example, advertisers become attracted to the Google search engine because of the large number of users.

Industry platforms guide technological innovation trajectories and stimulate innovation on complements. In order to do so they need to address two different sets of strategic issues (Gawer 2008): (1) developing a core function to encourage other companies to develop complementary applications that grow the platform ecosystem (coring); and (2) shaping market dynamics by gaining control over an installed base to win platform competition (tipping). Recently authors has started to considering that multiple platform strategies can coexist (Cennamo and Santalo 2013, 2015) because of: (1) asymmetric or local network effects (Eocman et al. 2006); (2) modest costs of adopting multiple platforms (Eisenmann 2006); or (3) differentiated consumer preferences (Armstrong and Wright 2007).

We build on the above streams of research to theoretically demonstrate that multiple business models can coexist within technical platforms and empirically examine this phenomenon among the developers and the users of the same IT platforms. IT platforms are an excellent laboratory for empirically analyzing the business models adopted by solvers and users for several reasons. First, other studies have documented that IT platform has become a strategic option for software vendors who expect to benefit from value co-creation with partners by developing complementary components and applications (Giessmann and Legner 2016; Hartmann and Bosch 2016). Second, because multiple actors coexist in the industry, we can exploit heterogeneity in the way those distinct actors manage their activities and the relationships with third-parties. Finally, IT platform usually change over time (even the core components can evolve, only the interfaces need to be stable), allowing us to analyze the strategies pursued by the different involved actors.

6.3 Research Design

The objective of this research is that of analyzing which business models can be effectively pursued by firms to benefit from the advantages offered by IoT. To achieve this objective we performed a descriptive-interpretative qualitative research (Denzin and Lincoln 2000), aiming to provide a useful description, explanation and interpretation of the phenomenon under investigation. We have chosen this research method because its purpose is to examine a phenomenon that is occurring at a specific place and time, including the conditions, practices and relationships that exist, processes that are going on, or trends that are evident (Strauss and Corbin 1998). Therefore, we carried out an Internet search to select a successful project, focused on IoT cloud-computing and characterized by the involvement of multiple actors with different roles, competences and objectives. To identify a potential case study, we referred to the European cloud platform oriented “to advance Europe's competitiveness in Future Internet technologies and to support the emergence of Future Internet-enhanced applications of public and social relevance” (www.ec.europa.eu). In turn, we selected the FIWARE platform for different reasons: (1) it is an EC project that is included in the Future Internet Private Public Partnership (FI-PPP) program, oriented to improve the effectiveness of business processes and infrastructures supporting applications; (2) it can be used by a range actors – large firms, small-medium enterprises, public administrations, software houses, etc. – to validate innovative technologies in the context of smart applications and to prove their ability to support user driven innovation schemes; and, (3) finally, it facilitates the collaborations between business and academics.

Then, we proceeded to an accurate data gathering about FIWARE by using different types of materials, methods and investigators (Denzin 1978). Firstly, we conducted desk research to identify and acquire information that already existed in documents, internal reports, dossiers, and articles in order to obtain a good understanding of the FIWARE. We also examined the descriptive material and other documents available on the European website. Second, we performed field research through different rounds of in-depth interviews with developers of FIWARE (Deshpande and Farley 2004) in order to explore aspects related to this platform, such as its characteristics, reference architectures, functionalities, applications and services offered, potential development and etc. The interviews were conducted in March 2016, and each interview lasted approximately 2 h, following the methodological prescriptions on data collection through personal interviews (Lee 1999).

The information obtained by interviews was transcribed, codified and analyzed using text mining and lexical analysis. For validating our qualitative analysis, we presented the results to the respondents in order to obtain their feedback and corrections (Elliott 1999). The results of this case analysis are reported in the next section.

6.4 FIWARE Architecture and Philosophy

In a context in which cloud computing, big data, and IoT are enabling key technologies for the Internet of the Future, the European Commission (EC) envisioned the possibility to foster the wide adoption of such systems, in total openness, avoiding vendor lock-in and simplifying the composition of new services. The EC understood the need to find the right compromise between academic and industrial fields. To this end, the EC has started the Future Internet Private Public Partnership (FI-PPP) program that has brought to the delivery of a new complex European cloud platform, named FIWARE. The aim of FIWARE is to yield an open standard platform and an open, sustainable, global ecosystem. The FIWARE Reference Architecture includes a set of general-purpose platform functions (Building Blocks), available through APIs, called Generic Enablers (GEs). GEs gather advanced and middleware interfaces to networks and devices, advanced web-based user interfaces, application/services ecosystems and delivery networks, cloud hosting, data/context management, IoT service enablement, and security. FIWARE considers GE Open Specifications (that are public and royalty-free) and their implementations (GEi). There might be multiple compliant GEi(s) of each GE open specification. At least, there is one open source reference implementation of FIWARE GEs (FIWARE GEri(s)) with a well-known open source license.

FIWARE can thus be considered a de Facto Standard of future complex systems, at least in Europe, where clouds and IoT might be applied in various scenarios such as eHealth, Smart Cities and so on. By adopting such a standard, private companies (Specific Enablers) can make their businesses developing customized solutions able to satisfy needs of individuals and SMEs by connecting new IoTs and devices.

6.4.1 The FIWARE EcoSystem

The FIWARE Ecosystem is shown in Fig. 6.2 (see Fazio et al. 2015). Starting from the left part of the picture, in FIWARE, a common and well-known GEs repository is defined (that is the static part of FIWARE). The different geometric shapes of each GE remark the possibility offered by FIWARE of hosting and executing (see the RunTime Environment – RT of it, which is the dynamic part) any type of GE. Below the repository there is the platform itself that is a composition of more federated platforms that can easily interact each other thanks to the XIFI agreement (FIWARE). In the picture each RT shaped cradle shows how more platforms are able to host GEs in different contexts/companies. Indeed, GEs can be seamless moved from RT shaped cradle to another and vice versa (see the dashed-lines). FIWARE allows this, thanks to the openness of its platform and APIs. Here Users, SMEs (Small and Medium-sized Enterprises, named also Local Players), SPs (Service Providers) and IoTs can interact through the Internet with the same kind of platforms and protocols, for different purposes but in a same way. FI-LAB Front-End in the picture depicts this common abstraction for interacting with FIWARE. To this FIWARE is representing a Standard de Facto of future complex systems, at least in Europe, where clouds and IoTs need to be used in any scenario as eHealth, Smart Cities and so on. Figure 6.2, inside the shaped cradle also shows a few rectangular small elements labeled SE. They represent the Specific Enabler developed by each company. Companies can make their businesses developing customized SPs able to satisfy needs of Users and SMEs and for connecting new IoTs and devices.

Fig. 6.2
figure 2

FIWARE EcoSystem

Figure 6.3 shows four different shaped cradle systems identifying four business IT companies (Big Players), named: (A), (B), (C) and (D). Each RunTime Environment (RT) is able to execute any Generic Enabler of FIWARE (see triangle, pentagon, exagon, etc.., shapes), however the portfolio of Specific Enablers (see rectangular shapes) for each companies is different each other. The portfolio of SPs along with their users’ customizations represents the compelling offerings of each company. Hence, business scenarios might be differentiated in terms of number of GEs, SEs and customizations.

Fig. 6.3
figure 3

FIWARE business domains

6.4.2 Identifying Business Models of Participants to the FIWARE Initiative

The FIWARE ecosystem depicted so far reveals that different agents participate in the co-development of the initiative, playing different roles, contributing with specific resources and competences, pursuing different goals, and being subject to different motivations. Within this complexity of roles and resources, we could however identify at least two common patterns that we characterized in terms of different business models adopted by the different categories of actors.

A first typology of business model is adopted by those Big Players (that is, large IT operators) that play a key role in the development of the system and in the definition of its inner characteristics. To such actors (that are responsible for the different GEs) it is demanded the relevant task of providing and developing the technological knowledge, skills and competences that are needed to make the system work. This task implies a relevant effort, both in terms of financial and human resources and technological capabilities. In principle, these actors do not participate in the development of downstream applications, and therefore the returns for their effort mainly arise from the licensing of the (usage of the) open platform to downstream operators. In this sense, such large firms mainly act as external technology suppliers, which indirectly benefit of the returns that technology users will generate through specific applications in different business domains. Provided that the FIWARE platform is expected to be applied in a broad variety of business domains (and, therefore, it can be considered a GPT), the total returns for the platform developers will correspond to the sum of the marginal returns of the application of the platform to each domain. In turn, in order to maximize the expected total returns, the platform developers have incentives to make the FIWARE technology as general as possible and its usage as simple as possible (that is, with limited adaptation costs) for the downstream users.

By contrast, an alternative typology of business model is adopted by those actors of the FIWARE ecosystem represented by downstream application developers (which are responsible of SEs, according to the terminology of FIWARE). In most cases, such actors are small and local software developers that are expected to design and develop applications to solve the contextual needs of specific groups of customers. These smaller, downstream software developers are therefore adopting an open business model. On the one side, the business model is open upward, to let the inflow of technology (the FIWARE platform) from large technology developers. On the other side, the business model is open downward, to let final customers participate in the co-development of the specialized application. In turn, the amount of value created through this business model results from the difference between the (high) value offered to final customers for the specialized and customized solutions, and the (low) cost of technology acquisition from upstream suppliers.

To better explore the way by which downstream application developers leverage the possibilities offered by the FIWARE platform, we analyzed more in details those SMEs that applied to the sub-unit of FIWARE focusing on smart cities (Frontier Cities project). The list of analyzed firms is shown in Table 6.1.

Table 6.1 SMEs participating to FIWARE-frontier cities

All companies listed in Table 6.1 are small firms (often start-ups) aiming at deploying IoT cloud-computing technology made available through FIWARE. They are software developers specialized in one or few application fields, which develop applications to solve needs and problems related to the field. Albeit the service they offer is strongly technology-based, their main aim is to satisfy their specific customers’ needs. Therefore, they need to have a strong linkage with downstream market, being able to properly assess potential customers’ characteristics and to translate often latent needs in explicit applications. Their vision is, therefore, customer oriented, as Table 6.2 seems to reveal.

Table 6.2 Elements of SMEs’ business models

In performing their task, however, they largely benefit of technological solutions (and standards) offered by the FIWARE platform. In this sense, they consider FIWARE as a repository of available general purpose component technologies, that they combine together in a creative manner to develop a (set of) device(s)/service(s) that satisfies customers’ specific needs. Since components offered by FIWARE are standardized, their combination and recombination can be obtained at relatively reduced cost, that is, without the need to develop specific interfaces that allow the different components to interact among them.

An example may help clarify how the system works. The Italian company Ecogriddy has developed a solution, named Cortex, that allow manufacturing companies to manage their production sites and maintain energy costs under control. Cortex makes use of different FIWARE technological components. Specifically, it is built on three layers interconnected in a classical IoT architecture fully integrated and available to customers without extra efforts from them (end-to-end solution): (1) a physical layer that consists in monitoring hardware/sensors (industrial grade); (2) a cloud layer, which collects, analyzes and elaborates further the data received by the gateways and by other contextual sources; (3) an interface layer that allows the users to interact with the energy data and to learn from them. All these components are offered by FIWARE, and the only (and main) effort made by Ecogriddy has been that of thinking at an original and creative way to combine them to solve a specific practical problem. In doing so, they have developed an organizational design that potentially offers scalability, modularity, resiliency, and compliance to open standards and edge computing capabilities that an IoT approach can offer.

Furthermore, for most SMEs participating to the initiative, absent the FIWARE platform, the planned business model could not be implemented. In the words of managers of Everimpact, a France SME developing air quality solutions for cities, “As a newly created startup, the financial support was of course really a great help to take a giant leap in our development. But where FIWARE is making a difference compared to other accelerators is on the support. Instead of starting to develop our application from the ground up, we could rapidly use the FIWARE enablers. I just can't help thinking about all the money that has been saved by the EU by providing this huge ‘app store’ to startups and SMEs. (…) Practically the technical experts and support we received saved us months of development. It is difficult to compete with such value proposition in my opinion. And it is reassuring for investors to see that your company has a solid platform to lean on.”

6.5 Discussion and Conclusions

Received literature on platforms have usually associated technological platforms with a positive impact on innovation (Thomas et al. 2014). The positive effect stems from the fact that, by offering unified and easy ways to connect to common components and foundational technologies, platform leaders help reduce the cost of entry in complementary markets, and provide demand for complements, often fuelled by network effects. Platforms offer therefore a setting where it is in the interest of both private firms to elicit and encourage innovation by others. Despite these arguments the existing literature on platforms does not address the different strategies and or business models that actors involved in the platforms can pursue. This study addresses this issue and contributed contextual evidence of the strategies adopted by actors involved in a successful case, namely the FIWARE platform.

The analysis of the FIWARE case has clearly shown how the development of an IT platform that exploits the possibilities offered by IoT cloud computing can provide advantages to different types of organizations and public institutions. Our analysis revealed that the various actors that contribute to the development and usage of the platform adopt GPT-based business models that confer to them a potential competitive advantage. Therefore, it results important to discuss under which conditions such business models may offer a benefit with respect to more traditional (non GPT-based) business models.

As far as the first typology of cloud-based business models adopted by the Big Players is concerned, we saw that the more general the upstream technology (i.e., the GEs embedded into the FIWARE platform) is, and the simpler is its usage for downstream application developers, the higher the incentives for the Big Players are, since they may distribute their technological developments to a larger share of potential users. As such, this situation is quite different from traditional approaches adopted by firms in the IT sector, which were used to develop specialized technologies for each application domain and gain returns from the proprietary exploitation of the same technologies. By contrast, the division of innovative labor among the various actors involved in the FIWARE ecosystem and implied by the technology represents a new model of industry organization. Within this new model, the large firms acting as technology developers are therefore required to pursue a business model in which the value proposition is mainly defined by the offering of a general purpose technology to a diversified plethora of downstream users that may adopt the technology in contexts that are unknown ex-ante to the original developers.

As for the second typology of business model (adopted by downstream operators responsible of specific SEs), what makes it more or less advantageous with respect to traditional business models is the existence of two independent conditions: (1) the upstream platform (the GEs) has to be general enough to be easily and cheaply applied to differentiated business domains, which mainly depends on how the upstream system developers have designed it; and, (2) the amount of absorptive capacities (Cohen and Levinthal 1990; Zahra and George 2002) possessed by the downstream software developer, and therefore its experience, know-how and technological competences, along with its ability to understand and respond to the (latent) needs of final customers. If both conditions are satisfied, that is, if upstream operators have made the platform general enough and if downstream operators are in possess of adequate absorptive capacities, then the cost of technology adaptation that downstream software developer have to incur in to apply the GPT to the specific application need is expected to be lower than the cost that the same software developer should incur to totally develop the application in-house, if the GPT platform (FIWARE) were not present. As such, in the presence of an industry structure organized around a IoT cloud-based GPT, also downstream operators have incentives to adopt an open business model.

Finally, it is worth noticing that also governments may benefit from the development of IoT cloud-based platforms such as FIWARE. The advantage to them is not obviously economical in nature. Rather, as in the case of the European Commission that has partly funded FIWARE, governments are often required to spend public financial resources under the form of research grants to promote the development costs of the platform. The grant may also cover the whole amount of financial resources needed to the full development of the platform, thus leaving it open and freely available to downstream operators. Nevertheless, the social benefits of similar technologies are expected to overcome the share of public funds devoted to their development, mainly because the existence of the technology and the possibility for downstream users to benefit from it should favor its application to various business domains thus boosting the economy. In this respect, platforms such as FIWARE represent physical infrastructures available to many actors. And, as other general purpose technologies, such infrastructures are expected to become engines for economic growth (Helpman 1998).

The richness of our data set has allowed for the use of a fine-grained qualitative analysis. Nevertheless, our work is not free of limitations. The empirical evidence we provide in favor of our theoretical framework may be industry-specific. A second limitation is that in developing our analysis of the business models actors adopt in IT platform we are aware that multiple levels of analysis come into play. This paper does not explore the theory and practice of platform concepts beyond the level of the firm, although we have alluded to industry and sectorial level analysis. Limitations aside, this paper has the merit to focus scholar’s attention on the heterogeneous, even successful, behaviors actors involved in a IT platform can adopt.