- Email: [email protected]
Adding value to the network: Mobile operators’ experiments with Software-as-a-Service and Platform-as-a-Service models
Telematics and Informatics 28 (2011) 12–21
Contents lists available at ScienceDirect
Telematics and Informatics journal homepage: www.elsevier.com/locate/tele
Adding value to the network: Mobile operators’ experiments with Software-as-a-Service and Platform-as-a-Service models Vânia Gonçalves *, Pieter Ballon IBBT-SMIT, Vrije Universiteit Brussel, Pleinlaan 2, 1050 Brussels, Belgium
a r t i c l e
i n f o
Article history: Received 9 July 2009 Received in revised form 27 November 2009 Accepted 18 May 2010
Keywords: Software-as-a-Service Platform-as-a-Service Business models Mobile operators Mobile platforms
a b s t r a c t The environments of software development and software provision are shifting to webbased platforms supported by Software-as-a-Service (SaaS) and Platform-as-a-Service (PaaS) models. This paper will make the case that there is equally an opportunity for mobile operators to identify additional sources of revenue by exposing network functionalities through web-based service platforms. By elaborating on the concepts, benefits and risks of SaaS and PaaS, mobile operators’ experiments are compared and similarities with these models are identified. Based on the analysis of various case studies, this paper argues that mobile operators mobile web services are decisively shifting from SaaS to PaaS models. However, these platforms incorporate fragmentation at several levels and are likely to face future challenges in order to thrive. Ó 2010 Elsevier Ltd. All rights reserved.
1. Introduction Mobile telecommunications networks and the internet have evolved as disjoint worlds with regard to software applications and application development technologies. Mobile operators are now at the crossroads of maintaining ‘dumb pipes’ on the one hand, and finding sources of additional revenue on the other hand. As large parts of the IT industry are moving to a web service delivery model, there seems to exist an opportunity for mobile operators to learn from these experiences and adopt similar models by exposing network capabilities and combining these with online content and applications. It has been argued that mobile operators should move from an integrated network-centric model to a more modular web-based model, in which network services are opened up to end-users and professional developers (Ballon, 2009; Constantinou, 2009; Quayle, 2008). Over the last decade, examples of such web-based models have abounded, as the web has evolved from a collection of informational websites to accommodate a new range of services and applications delivered to customers through a number of business models, most prominently Software-as-a-Service (SaaS) and Platform-as-a-Service (PaaS) models. Although both models offer a template to monetise data services over the web and while they are intertwined from a technological point of view (Armbrust et al., 2009; Chappell, 2008), a clear break exists between the two concepts from a business point of view. On the one hand, SaaS presents the embodiment of a one-sided market model for developing and delivering ICT services, wherein services flow in a linear fashion from ISVs to customers, with revenues flowing in the opposite direction. On the other hand, PaaS fits a two-sided market model wherein a platform mediates between the demand and supply side. In the case of ICT services, a platform owner facilitates an environment for application design, development and delivery through a platform that allows application developers to provide a service to the end-customer and get revenues from it. Thus the platform owner creates value for upstream developers and downstream customers and extracts revenues from both sides.
* Corresponding author. Tel.: +32 26291620. E-mail address: [email protected] (V. Gonçalves). 0736-5853/$ - see front matter Ó 2010 Elsevier Ltd. All rights reserved. doi:10.1016/j.tele.2010.05.005
V. Gonçalves, P. Ballon / Telematics and Informatics 28 (2011) 12–21
13
Over the past years, platform literature has started to explore a number of fundamental differences in the business logic between one-sided and two-sided markets (Armstrong, 2004; Bresnahan, 1999; Gawer, 2009; Gawer and Cusumano, 2002). It has been argued that the main elements of leading platform providers’ business logic are the following:
fostering a thriving ecosystem of internal and external complementary innovations and innovators; influencing architectural design through open interfaces combined with core intellectual property assets; balancing consensus and control strategies towards contributors of complementary innovations, and reflecting this in the internal organisation, e.g. by adopting a systemic and neutral mindset that extends to the whole industry.
While the literature on ICT platforms has suggested that ICT service providers often have the discretion to make active design choices and strategic choices to become a platform or not (Evans et al., 2005), platform literature also suggests that the necessary competencies to succeed in services and in platform services are not aligned, and that there are specific contextual conditions under which platforms can thrive. However, the question under which conditions platforms successfully arise has remained largely unexplored up until now. Mobile operators have been exhorted to branch out into web-like services, applications and platforms for several years. However, former attempts of service diversification through mobile data services such as WAP and walled-garden portals have failed or are experiencing slow take-off (Ballon, 2009). Despite the great build-up for these services, the main cause for this failure appears to be business models built on unfavourable revenue sharing models, resulting in poor incentives for application providers (Lindmark et al., 2004), proprietary standards, and the inability to attract a critical mass of users (Funk, 2007). In the most recent quest for new business models for mobile data services, mobile operators are revamping old platforms (e.g. Vodafone Live! (Green, 2008)), reconnecting with application developers through specific application development platforms (e.g. Betavine) and partnering among operators to offer mobile web services and mobile service platforms (e.g. Joint Innovation Lab, 2009). Such mobile web services entail new business models which are essentially SaaS and PaaS models. However, explicit references to experiences with these models in the IT and internet industries are only seldom made. By assessing different case studies of mobile operators’ experiments in offering mobile web services to several stakeholders we aim to frame them within the SaaS and PaaS frameworks, to explore some of the similarities and differences, and to derive a number of factors and challenges that should be taken into account by mobile operators. It will be argued that PaaS models are a logical evolution of SaaS models as mobile operators are faced with challenges of providing a variety of low-cost applications and of fencing off competition from large IT and internet companies. The structure of this paper is as follows. First, both SaaS and PaaS concepts are delineated from a business perspective, taking into consideration the current market trends. Secondly, the benefits and risks of both models are analysed in order to better understand the implications for suppliers as well as customers. Thirdly, a number of success factors for platform owners are identified. Finally, mobile operators’ case studies about mobile applications’ development platforms are analysed and several trends and challenges are highlighted. 2. Software-as-a-Service The Software-as-a-Service (SaaS) concept has been presented by ICT market analysts (Mizoras and Goepfert, 2003) and software industry associations (SIIA, 2001) as an improved version of the Application Service Provider (ASP) model, in which providers host and provide access to a software application over a network. This application service is managed centrally and offered in a one-to-many fashion. The SaaS model has evolved into a web-based application interface, incorporating other attributes such as multi-tenant efficiency, configurability and scalability (Chong and Carraro, 2006). ISVs were then able to shift from delivering on-premise software solutions to deliver a complete software application to end-users over the web, providing a much more flexible experience in terms of time and location of access. Although the current literature focuses primarily on business-oriented SaaS services, several market examples lead to a categorisation that also includes consumer-oriented service offerings. Business-oriented SaaS services are offered to enterprises and organisations of all sizes, but typically focused on SMEs (e.g. Salesforce.com, RightNow, Amazon S3). Consumer-oriented SaaS services are offered to the general public for a wide range of applications like hosting, news feeds, storage, presentations, and so on (e.g. Blogger, Dropbox). The following subsections describe SaaS revenue models as well as the benefits and risks for the main stakeholders. 2.1. Revenue models Shifting from offering on-premise software to SaaS obliged ISVs to change the way software was sold. In an on-premise scenario, the customer buys a license to use an application and installs it on his or her owned or controlled hardware. By acquiring the license the customer perceives unlimited usage of the software. In SaaS models, instead of buying a lifetime license, the customer pays a fee for software running on a third-party server and loses access when he ceases payment. This fee can either be charged as a pre-paid subscription or on a pay-as-you-go basis. Typically, in the first approach, players offer
14
V. Gonçalves, P. Ballon / Telematics and Informatics 28 (2011) 12–21
different subscription fees based on a combination of allocated resources, namely storage, data transfer, session-time, number of users, etc. In the second approach, pay-per-use fees are charged on the basis of actual usage of those resources. Consumer-oriented services are often provided to consumers at no cost, but are supported by advertising or are offered for strategic reasons such as customer lock-in. These free services are often used to up-sell advanced features (e.g. extra storage space) on a subscription or pay-per-use basis.
2.2. Benefits and risks The SaaS concept has changed the way software is developed and delivered to the customer. The shift from on-premises software to web applications and from one-to-one to one-to-many service provision has impacted on the relationships between ISVs, customers and developers. ISVs make and sell software to customers and normally deal with software distribution channels and licensing. In the shift to the SaaS model the most important benefits for ISVs include potential economies of scale in both production and distribution costs, more predictable revenues, the development of software with lighter operating systems and hardware requirements, and shorter sales cycles. The possibilities of spreading the costs of innovative solutions over many customers, lower license compliance management activities, and the lower need to deal with piracy and maintain expensive distribution channels potentially lead to economies of scale in the production and distribution processes. Additionally, software with lighter operating systems and hardware requirements enable ISVs to shorten the development life cycle, easily provide additional features, rapid updates and support, and potentially reduce maintenance costs. However, the SaaS model also entails several risks which ISVs are not used to deal with. Moving to the SaaS model requires ISVs to develop new skills when planning SaaS offerings, such as management of billing and customer data, usage metering, security, support services and service provisioning. ISVs should also take up investment in building, and later on, maintaining the IT infrastructure to support SaaS services, or partner with other companies to provide those parts of the system (e.g. DropBox uses Amazon S3 storage services). In this latter case, ISVs now need to manage a network of suppliers that did not exist in the on-premises model. Moreover, the risk of performance and scalability issues is higher, as many users utilize an application running in the same server. From a business perspective, the SaaS model also implies changes to the role of the ISV in the ecosystem – the ISV once pictured as a Supplier is now a Service Provider with direct and continuous relationship with end-customers. Therefore, the market is one-sided in view of the fact that there is one group of customers directly reached by the service provider, relieving intermediate old retail channels. The SaaS concept seems very attractive for business customers such as startups and SMEs which do not see IT-related activities as a core competence and do not have the expertise to develop and maintain applications inside the company. It may enable them to have access to expensive commercial software with little initial investment and low monthly costs, something they could not afford otherwise. Therefore, SaaS offers opportunities to reduce the total cost of ownership of IT resources, alleviating companies from running applications in-house and committing to set-up an IT department to administer software and all related activities involving hardware maintenance, backups, security and user support. For companies that have very specific software needs (very complex and expensive software is needed in particular phases of a product development cycle), SaaS can significantly alleviate software costs, as companies would be able to subscribe to services for short periods of time. SaaS providers may also offer customers the possibility to share data with other online or on-premises applications with little effort. Similarly, the retail customer benefits from access to a wider range of software applications, generally at affordable prices or for free and with little effort of configuration or customisation. For both types of customers, SaaS has the potential to provide a stable, reliable and flexible experience, with access to software regardless of time and location. On the other hand, customers may incur very important risks in exposing or losing business-critical data to SaaS providers and potentially losing control of data exchanges to third-parties. Likewise, SaaS providers may lock-in customers by not providing the tools to export (and import) data and therefore making it difficult to switch to other providers. Additionally, interruption of the service due to lack of payment, might also implicate failure to recover stored data.
3. Platform-as-a-Service The Platform-as-a-Service (PaaS) model is a novel approach for software suppliers that want to focus primarily on the development cycle and the monetisation of new applications, thus bypassing the investment in and the maintenance of the underlying infrastructure. PaaS platforms facilitate the entire software life cycle by offering the underlying services for application design, development, testing, deployment and hosting (Mitchell, 2008). These services enable both professional and non-professional developers to build on the functionalities of an existing SaaS (e.g. Force.com) or develop new web applications (e.g. Google App Engine). PaaS incorporates other attributes such as: built-in scalability, reliability and security; built-in integration with web services and databases; support for collaboration among developers and delivers a user experience without compromise; and support for deep application instrumentation of application and user activity
V. Gonçalves, P. Ballon / Telematics and Informatics 28 (2011) 12–21
15
(Mitchell, 2008). Although cloud computing services (e.g. Amazon Web Services) provide relevant components (e.g. storage) for particular stages of the software life cycle, they do not embrace the integral notion of PaaS. In a business context, this means a move to a Platform model wherein a platform mediates between the demand and supply side. PaaS instantiates the concept of ‘Level 3 platform’ (Andreessen, 2007), given the fact that it provides the ‘‘runtime environment” to run external applications inside the platform itself. Likely PaaS also encompasses Level 1 platform functionality – an access application programming interface (API) to access data and services running on the platform – and Level 2 platform functionality – a plug-in API to inject functionality into the platform. For instance, Google App Engine provides a set of APIs to access user-specific data stored in the platform, as well as Google services data. In the case of MySpace Developer Platform, applications can run inside or outside the platform, which in the latter case they do via a plug-in API. 3.1. Revenue models Since the software life cycle has different stages with different customer requirements at each stage, PaaS providers are building their revenue models based on the access to resources in those stages. In this context, pricing represents the costs producers incur to join a platform in order to develop and deploy applications. Some PaaS providers charge a subscription fee for access to the development and testing functionalities, while others only charge for the actual time end-users spend interacting with the application, i.e. after the application is deployed in the market. For instance, the cost for hosting an application with Bungee Connect is determined by the amount of time end-users spend interacting with each page of the application. Google App Engine offers a certain amount of computing resources for free and allows developers to buy additional resources when needed. By defining a maximum daily expenditure, developers can assign quotas for a set of adjustable resources, such as the amount of stored data or incoming and outgoing network bandwidth used. In addition, the platform owner may offer a marketplace for the commercialisation of applications and charge producers a percentage of sales. The portion of the application’s price producers will receive from the amount customers have paid is thus the revenue share rate. 3.2. Benefits and risks In the PaaS model, the most important value element for customers is quite straightforward: develop and run cloud solutions without having to maintain three environments as in the on-premises software development model, i.e. a development environment, a test environment and a production environment. Using a PaaS, a faster time-to-market may be expected since the platform offers hosting in the same environment for both test and production stages. Since these environments are provided by the platform owner, developers may considerably reduce provisioning and management of their own IT infrastructure (e.g. storage, databases, etc.). The main costs developers incur are runtime fees based on the actual computing resources used by the applications or the number of users using them. Some PaaS platforms foster a developers’ community, giving developers the means to communicate, share knowledge and reuse other developers’ code through case studies, blogs and fora. A strong community around a platform gives developers a feeling of control over the platform and might be crucial to guarantee platform adoption. There is a virtuous cycle involved, as the presence of a community attracts more developers, which means more applications, which presumably attracts more customers, and so on. Quayle (2008) studied forty application developer communities and identified several topics to be considered while building a developers’ community: (1) platform providers should know their audience and build a strong relationship with early adopters; (2) tools, examples and case studies should be provided and developers should be educated; (3) communication and marketing should be done through developers and their success stories; (4) metrics should be aligned with the platform provider’s overall business goals; (5) the business model must be baked into the API, as it will help developers make money and thus the platform provider as well; and finally (6) the developers’ community should be integrated in the platform provider’s marketing processes to allow innovation to reach the customer. PaaS platforms can be more or less open and to a greater or lesser degree lock-in customers. PaaS platforms may be based on standard programming languages like WyaWorks (based on Java), on a combination of standard programming languages and proprietary add-ons like Google App Engine (based on Python), or on proprietary programming languages like Force.com (based on Apex). One important issue that militates against entirely closed platforms is the fact that developers may be confronted with a long learning curve to master proprietary programming languages and APIs, thus requiring more effort in developing an application. A closed PaaS platform also raises risks as it creates lock-in, by preventing developers to port an application to another platform, which may only be circumvented by building the application from scratch in the new platform. Closed platforms may also prevent developers from integrating data from third-party platforms or services. The whole concept of PaaS creates risks in the sense that providing developers with all development tools is a fundamental departure from traditional development environments – the developer is limited to use the APIs available in the platform. Perry (2008) and Warfield (2007) analysed various PaaS examples and identified several advantages related to providing a common and open API. Such an API would stimulate innovation, reduce barriers to entry and increase portability between operators. Additionally, it would reach out to more developers, as they would easily identify the advantages of coding once and deploying and monetising in several platforms (Telecoms.com, 2009). Still, the platform owner could choose to differentiate its platform by offering proprietary APIs on top of the common access API. Similarly to SaaS models, PaaS providers have an incentive to make their services available with light operating systems and hardware requirements, both for the development phase and for runtime. Likewise, the platform owner would avoid
16
V. Gonçalves, P. Ballon / Telematics and Informatics 28 (2011) 12–21
dealing with license compliance and piracy issues. Still, the most important value element for platform owners is earning revenues from applications hosted in the platform. Nevertheless, the success of the platform will heavily depend on the platform owner’s strategy and the right balance between open and closed, proprietary and non-proprietary, free and paid elements, making the offering captivating enough for users on both sides of the platform. It is likely that developers are not keen of long learning curves when developing for a new platform, that they want to be able to try out how a platform works and responds before committing themselves to it, that they are typically eager to use tools to share ideas and knowledge, and ultimately want the option to put the application on the market with little effort. A marketplace that advertises developers’ applications would allow a win–win situation between platform owners that sell and host applications, developers that write them and customers that want to buy and use them. Once the platform is successfully adopted, the platform owner has to deal with a new set of issues, related to performance, scalability, storage and security. The platform owner cannot control the quality and security of the code that runs within the platform, but has to create the technical mechanisms to anticipate the consequences of such problems. One can argue that in this model the developer can devote more time to the creative process and therefore a whole new range of innovative applications will emerge. The end-user will benefit from a large quantity of applications that make use of integration and aggregation of data provided by other applications or systems. The large offer of such applications will likely decrease the price for consumers. However, the end-user might incur the risk of paying for a service that is periodically unavailable. For instance, App Engine returns an unavailable status and the end-user is not able to use the application once it exceeds the daily resources’ allocation (Google, 2009). In summary, although SaaS and PaaS might target different sets of customers, they appear to be based on the same types of revenue models of subscription or pay-per-use fee, and have some common benefits and risks. The diagram of Fig. 1 summarises the benefits and risks for the three aforementioned stakeholders – platform owner, end-user and developer. The left side of the diagram explores the SaaS concept and PaaS is examined on the right side. The upper part looks at the benefits of these concepts for each stakeholder and in the lower part are enumerated the risks. The overlapping benefits and risks of the two concepts are represented in the central section of the diagram. 4. Success factors for platform adoption Examples of web-based platforms that encompass the previously analysed concepts proliferate in the web and their success factors have also been considered in the literature. Success factors cited in the literature comprise the agility, efficiency
Fig. 1. Summary of benefits and risks for different stakeholders in Software-as-a-Service and Platform-as-a-Service models.
V. Gonçalves, P. Ballon / Telematics and Informatics 28 (2011) 12–21
17
and flexibility of inherited business processes (Lawler and Howell-Barber, 2007). The flexibility of these processes and interoperability between systems may give competitive advantage to customers among their competitors (Kittlaus and Clough, 2009). Time to market new services and being focused solely on customers’ needs may be considered as further success factors for platform owners (Blokdijk, 2008). Furthermore, other success factors that may induce customers to take the risk of losing control and be locked-in by the platform should also be considered. In the case of SaaS, these factors are mainly related with the balance between the uniqueness and quality of offering and involvement of customers. Firstly, distribution costs should be inexistent and provision costs to one customer or hundred customers should be barely the same. Secondly, investment costs for customers should be meaningless and the pricing rules to get access to the platform should be straightforward. Thirdly, customers should have the ability to participate in the improvement of the platform (e.g. by reporting bugs) and therefore benefit from a continuous customer care and frequent and easy software updates. Finally, services should be made available with minimum configuration requirements and with small further needs for customisation. By opening SaaS services to a large number of developers, the platform evolves to a PaaS model and in turn gives developers the opportunity to offer SaaS to end-customers. In this case, a new underlying business logic and architecture is implied in order to manage both the demand and supply sides. Hence, the main focus of control (i.e. ability to lock-in) moves from the application developer to the platform provider. In this case, the success factors for platform adoption are also associated with pricing. The costs developers have to support to access the platform should be meaningless and there should be no need for specific investments. In addition, the tools and programming languages made available to developers should not require additional effort in comparison with an open development environment and the advantages of a single development environment should be highlighted. Making available a channel that provides a clear way to market and a revenue share rate that fairly rewards developers can also be considered relevant factors that would drive platform adoption, as they would also provide the incentives to switch from traditional development environments. Overall, these factors should be rightly balanced in order to induce developers to join the platform while at the same time delivering added value that justifies closed, proprietary or paid elements.
5. From SaaS to PaaS: mobile operators’ approaches This section analyses several case studies that show the evolution from SaaS to PaaS models in several attempts made by mobile operators to offer mobile web services and mobile service platforms to various sets of customers. Table 1 presents an overview of several experiments considered by mobile operators. The data was collected through material publicly available on the internet (papers, presentations, reports, news, and so on) and by signing-up for a developer account in these platforms. This public data is the one stakeholders perceive and will constitute adoption drivers of the platform and services by developers and consumers. Further work will involve in-depth analysis of the cases by interviewing key actors in operators’ organisations in order to picture potential platform business models (Ballon et al., 2008) for operators. Among the success factors identified previously in the examples in the IT sector, the following factors were selected and considered for the comparison of mobile operators’ platforms: the availability of application programming interfaces, the presence of an actively supported developers’ community, the presence of a common marketplace, the cost of joining the platform, the revenue share rate employed, and the availability of hosting services. In addition, global access – the platform’s openness to different value chain producers and locations – is also considered. In a telecommunications context, the mobile operator would give the opportunity to any type of stakeholder, be it a content provider, an application service provider, a developer or an experienced end-user, to create and experiment with mobile applications. Even if mobile operators’ operations are normally focussed in one country or a group of countries, the internet is global and potential contributors can be based everywhere. The first examples of mobile operators’ experiments with mobile web applications in Europe were the Wireless Application Protocol (WAP) services. Original WAP services included news and sports headlines, weather forecasts and stock quote services. Even though most WAP services were offered by external content providers as a white brand, these were then mostly marketed by operators as a single service package, i.e. as a monolithic SaaS. However, by 2001 WAP was already predominantly referred to as an outright failure in terms of actual usage and revenue generation (Koster et al., 2001; Palomaki, 2004; Ramsay and Nielsen, 2000; Sigurdson, 2001). Although precise usage and revenue data were – and still are – very hard to come by, WAP usage was considered to be marginal and customer dissatisfaction to be high. Lindmark et al. (2004) argue that three reasons were underlying the WAP problems of poor usability, lack of attractive content, high costs, and badly managed user expectations about the ‘mobile internet’: (1) the fragmentation and the resulting lack of dynamism of European markets, when compared to the Japanese market; (2) the European lack of coordination of the availability and performance of complementary ‘mobile internet’ subsystems, resulting in diverging WAP implementations; (3) the unattractive revenue sharing models and cooperation agreements offered by European mobile operators to so-called ‘third-party content providers’. These lead to conclude that the failure of WAP is precisely due to its business model based on operators’ monopolistic strategic and managerial decisions, thus hindering a multitude of content providers’ participation and innovative experimentation. In this route from SaaS to PaaS, the following experiments are classified as hybrid models between SaaS and PaaS, as they present characteristics of the two models. The first examples consist of messaging (SMS and MMS) gateways offered to appli-
18
V. Gonçalves, P. Ballon / Telematics and Informatics 28 (2011) 12–21
Table 1 Comparison of mobile operators’ experiments. Global access SaaS WAP
API
Developer’s Marketplace community
Pricing
Revenue share rate
Hosting
N/A
Variable
U
U
Setup and monthly fee N/A
Variable between 45% and 80% Variable
Partial
Partial
U
Free
91%
Partial
U (for selected countries)
Free
Based on the application’s category
U (through a partner)
(mainly to content providers)
SaaS–PaaS hybrids Telenor CPA
(mainly to content providers) Vodafone Live! (mainly to Portal content providers) (mainly to NTT DoCoMo i-mode content providers) Portal
U
PaaS Orange Partner
U
Proprietary/ IMS
U
Vodafone Betavine
U
U
O2 Litmus T-Mobile Partner Network BT Web21C SDK Ribbit
U (USA based producers) U U (some services are USA based)
Proprietary/ GSMA OneAPI Proprietary N/A
U U
Proprietary Proprietary
U U
Telenor Playground
(to be approved by Telenor) (content in Spanish) U (content in Italian) U
Parlay
U
Propriety
U
IMS N/A
U
N/A
U
Telefonica Open Movilforum Telefonica WIMS 2.0 Telecom Italia Next Open Innovation Joint Innovation Lab
Free U U
(within Telenor operating companies)
N/A U
U
Free Free
70% 70%
U
Free Free/ monthly usage Free
N/A Based on usage
N/A
N/A
U
Free
N/A
N/A
N/A N/A
N/A N/A
N/A N/A
Free
N/A
N/A
N/A, no information available; U, available; , not available.
cation providers or content providers within the operator’s infrastructure for the delivery of business-oriented services mainly, serving several customers each with its configurations in a scalable manner. The successful Telenor Content Provider Access (CPA) system in place since 2000 is a profitable implementation of this paradigm (Nesse, 2008). In this case the mobile operator is in direct competition with application providers, e.g. (Clickatell, 2009; MX Telecom, 2009), that apart from providing gateway services, also offer APIs, code examples and user-friendly web management solutions for API connections or billing. Although successful among content providers due its open and market wide platform (Nielsen and Aanestad, 2005), CPA’s upfront costs, fixed revenue share rate and formal contract agreements creates barriers for mainstream developers’ adoption and makes it less attractive than those solutions delivered by application service providers that require little initial investment. As mobile operators began to recognize that a key contributor to mobile adoption was the provision of content and services to mainstream customers, following experiments with mobile content portals also demonstrate mobile operators’ attempts to open their networks to content providers. Vodafone and NTT DoCoMo were early pioneers in launching these content portals choosing as main strategy the partnership with content providers for the provision of quality content (Tseng et al., 2005). One may argue these portals are an instance of the SaaS model as they provide, among other services, games, ringtones, tools to backup contacts, internet and email access for an additional fee or for free. But at the same time, they already present characteristics of the PaaS model. Vodafone Live! was a rather closed service with contract based providers with variable revenue share rates, but i-mode was much more open and allowed both officially registered and unofficial content providers. The latter providers were able to offer their services directly to end-users, thus bypassing the 9% charge levied by the operator. In particular in Europe, these walled-garden portals experienced slow take-off due to the lack of attractive content, unsuccessful management of user’s requirements and expectations, and insufficient operators’ service creativity and innovation. More recently a slow evolution to platforms started to take place demonstrating operators intention to give other stakeholders the opportunity to fill in the gap of their lack of success and to slowly mature the importance of the information operators own about their customers and the intertwined opportunities for service innovation and additional revenue. This approach consists of exposing telecommunications network functionalities through APIs to third-parties that will take up service innovation, bring services to market more rapidly, increase customer intimacy through personalised services and realise the PaaS concept for telecommunications services to a large mobile operators’ customer base. This model, referred by
V. Gonçalves, P. Ballon / Telematics and Informatics 28 (2011) 12–21
19
(Aepona, 2009) as Network as a Service (NaaS), is being offered by some mobile operators mostly on an experimental basis allowing third-party developers to use a limited number of network capabilities (messaging, location, rich presence, charging and so forth) to develop new applications. As shown in Table 1, there are many initiatives currently being tested but they are still very much in their infancy as could be inferred during the course of this research by the changes occurred in websites’ layout, content and business models and the announcements of similar initiatives by the same mobile operator. All operators seem to have succeeded in building up the concept of community around the platform by providing code examples and case studies and making available spaces for discussion and sharing of experiences through a blog or forum. Most platforms allow any type of developer, startup or application provider to join in. Nevertheless, most of them require as mandatory information a mobile phone number to validate the registration. Some operators offer free premium subscriptions (e.g. Orange Partner) which include privileged access to development tools, support and commercialisation in the marketplace. Access to Ribbit’s platform is also free, but a subscription based on usage of communications features and services (e.g. SMS, voice mailboxes, international calls, etc.) incorporates the total costs of the application in production stage. Telenor Playground targets service and application providers mainly and the enrolment process seems to follow a long and custom procedure. On the other hand, the offer of APIs is very fragmented – proprietary (although in some cases open) APIs; GSMA OneAPI (GSMA, 2009); Parlay (Parlay, 2009); and OMA IP Multimedia Subsystem (IMS) (Alliance, 2005). In terms of geographic restrictions, T-Mobile Partner Network is only open to companies and is currently restricted to USA based ones. Open movilforum website’s content is mainly in Spanish, with only a short introduction of the platform in English. Although the description of most APIs is provided in English, most support and community pages are in Spanish. Some operators already gave a commercial component to the platform, enabling the developer to define a price and sell an application. Orange Partner, in place since 2005, finally launched an application shop by the end of 2008 in the operator’s online portal and WAP portal in some countries of the Orange group. Likewise, TMobile publishes applications in web2go, the operator’s marketplace portal. Vodafone (through betavine.mobi), O2 and Telecom Italia chose a different approach – the involvement of early adopters in the platform’s website. Hence, in an attempt to strengthen the feedback loop for developers, the end-user can download for free (Litmus also offers paid applications), test, rate, send feedback to the developer and share applications with other friends. Regarding the revenue share rate, O2 and TMobile adopted the same model of the Apple Store – a split of 70% for developers and 30% for the operator. Orange Partner splits the revenue between Orange, Cellmania and the developer. Overall, the analysis of these case studies enables us to conclude about the fragmentation of these platforms at several levels – multiple programming languages, multiple network APIs, multiple application shops, multiple markets and multiple platforms supported by the same operator. For instance, Telefonica is developing two distinct platforms, one promoting its open network APIs and another mainly based on IMS. O2, Telefonica’s subsidiary, is also a front-runner in involving the developers’ community in this new paradigm. On the other hand, Telenor is supporting two distinct platforms according to the target producers, one more oriented to service and application providers and another, Telenor iLabs, to let developers experiment with Telenor’s network capabilities and data assets. Vodafone, apart from supporting Betavine, is also leading the Joint Innovation Lab (JIL) which is oriented to the development of mobile widgets. Nevertheless, JIL is the first joint attempt of operators (Vodafone, Verizon, China Mobile and Softbank) to cut on the complexity of making applications suitable for multiple mobile operators. Moreover, most operators identify the platforms as beta environments, thus neither communicating a clear route to market with attractive revenue share rates for suppliers nor managing suppliers’ requirements and expectations. Therefore, in order to guarantee platform adoption, operators ought to avoid fragmentation, show a clear market strategy, choose a common API and deliver value for upstream and downstream customers by assimilating their requirements and expectations. In conclusion, in the context of mobile web applications, the risks faced by mobile operators in the implementation of the SaaS model – management of a network of suppliers, take the role of service provider implying new skills and direct relationship with end-users, deal with performance, scalability and security issues – were too great compared to the small value delivered to customers and content and application providers. As mobile operators now move towards a PaaS model, as demonstrated by the case studies analysed, they should take into account the changing mindset associated with platform leadership consisting of four main elements:
fostering a thriving ecosystem of internal and external complementary innovations and innovators; influencing architectural design through open interfaces combined with core intellectual property assets; balancing consensus and control strategies towards contributors of complementary innovations, and reflecting this in the internal organisation, e.g. by adopting a systemic and neutral mindset that extends to the whole industry.
Furthermore, the success factors derived from the IT sector concerning PaaS should also be considered. While a single development environment is a clear advantage for developers, locking-in developers by only making available proprietary programming languages and APIs or preventing interoperability with third-party services or platforms, might drive developers away. Common APIs between platforms and standard programming languages give developers the incentive to invest in the PaaS paradigm and see the potential to earn additional profits. In addition, code examples, fora for discussion and knowledge sharing would support the development phase and enable a faster time-to-market. The costs to join the platform and attractive revenue sharing models constitute further decisive factors to guarantee platform adoption. Altogether, the
20
V. Gonçalves, P. Ballon / Telematics and Informatics 28 (2011) 12–21
right balance between these factors and underlying technical characteristics would avoid diverging platform implementations and fragmentation. 6. Conclusion This paper analysed the SaaS and PaaS concepts from a business perspective and highlighted the benefits and risks for both suppliers and customers. It showed that from a business perspective, SaaS presents the embodiment of a one-sided market model whereas PaaS fits a two-sided market model. It then analysed several case studies that illustrate progressive attempts of mobile operators in delivering a wide range of attractive mobile applications to their customers. The first experiences show characteristics of the SaaS paradigm, while recent experiments incorporate a larger set of characteristics similar to the PaaS model. While slowly moving to this model, operators should adopt a platform mindset and incorporate the right balance of platform characteristics that guarantee platform adoption and avoid market and platform fragmentation. Based on the case studies, the biggest challenge to guarantee platform adoption seems to be posed by today’s fragmentation of mobile operators’ platforms. Acknowledgement This article is based on results from the WTEPlus project (IBBT project 10328), which is funded by the IBBT (Interdisciplinary Institute for BroadBand Technology) of Flanders, Belgium, as well as by the various partner companies. References Aepona, 2009. Making NaaS a Reality. (accessed 13.02.09). Armbrust, M., Fox, A., Griffith, R., et al, 2009. Above the Clouds: A Berkeley View of Cloud Computing. EECS Department, University of California, Berkeley. Armstrong, M., 2004. Competition in Two-Sided Markets. Mimeo, University College, London. Ballon, P., 2009. Control and Value in Mobile Communications: A Political Economy of the Reconfiguration of Business Models in the European Mobile Industry. SSRN. Ballon, P., Walravens, N., Spedalieri, A., Venezia, C., 2008. The reconfiguration of mobile service provision: towards platform business models. In: ITS European Regional Conference. Rome, Italy. Blokdijk, G., 2008. SaaS 100 Success Secrets – How Companies Successfully Buy, Manage, Host and Deliver Software as a Service (Saas). . Bresnahan, T., 1999. New modes of competition: implications for the future structure of the computer industry. In: Eisenach, J.A., Lenard, T.M. (Eds.), Competition, Innovation and the Microsoft Monopoly: Antitrust in the Digital Marketplace. Springer, Berlin, Germany. Chappell, D., 2008. A Short Introduction to Cloud Platforms. DavidChappell and Associates. Chong, F., Carraro, G., 2006. Building Distributed Applications: Architecture Strategies for Catching the Long Tail. (accessed 13.02.09) Microsoft. Clickatell, 2009. Clickatell Bulk SMS Gateway. (accessed 06.06.09). Green, T., 2008. Vodafone Live! set for April ’09 relaunch. (accessed 09.05.09). GSMA, 2009. 3rd Party Access Project. (accessed 23.02.09). Joint Innovation Lab, 2009. (accessed 10.06.09). Kittlaus, H.-B., Clough, P.N., 2009. Software Product Management and Pricing. Key Success Factors for Software Organizations, Springer. Koster, A., Lewis, K., Luo, T., Syedain, A., Ugeux, P., Wu, J., 2001. NTT DoCoMo’s Success in the Emerging Mobile Communication Services – Lessons Learnt for European WAP Providers. Lawler, J.P., Howell-Barber, H., 2007. Service-Oriented Architecture: SOA Strategy, Methodology, and Technology. CRC Press. Lindmark, S., Bohlin, E., Andersson, E., 2004. Japan’s mobile internet success story – facts, myths, lessons and implications. Info 6 (6), 348–358. Mitchell, D., 2008. Defining Platform-as-a-Service, or PaaS. (accessed 08.06.09). Nesse, P., 2008. Open service innovation in telecom industry – case study of partnership models enabling 3rd party development of novel mobile services ICIN conference. Bordeaux, France. Nielsen, P., Aanestad, M., 2005. Infrastructuralization as design strategy: a case study of a content service platform for mobile phones in Norway. IRIS, vol. 28. Palomaki, J., 2004. Case WAP: reasons for failure. In: Luukainen, S. (Ed.), Innovation Dynamics in Mobile Communications. Espoo: Helsinki University of Technology: Telecommunications Software and Multimedia Laboratory, Publications in Telecommunications Software and Multimedia, pp. 98–101. Parlay, 2009. (accessed 08.06.09). Perry, G., 2008. Thoughts on Platform-as-a-Service. (accessed 23.02.09). Quayle, A., 2008. Opening Up the Soft Service Provider. The Telco API. Ramsay, M., Nielsen, J., 2000. WAP usability deja vu: 1994 all over again. Sigurdson, J., 2001. WAP Off – Origin, Failure and Future. Working Paper N° 135, October 2001. The Stockholm School of Economics Working Paper. SIIA, 2001. Software as a Service: Strategic Backgrounder. SIIA, Washington.
V. Gonçalves, P. Ballon / Telematics and Informatics 28 (2011) 12–21
21
Telecoms.com, 2009. Orange Sees API Uptake, but Operator Cooperation Needed. (accessed 24.02.09). Tseng, A., Kallio, J., Tinnilä, M., 2005. Describing the critical factors for creating successful mobile data services. In: Saarinen, T., Tinnilä, M., Tseng, A. (Eds.), Managing Business in a Multi-channel World: Success Factors for E-Business. Idea Group Inc. Warfield, B., 2007. The Perils of Platform as a Service (It’s Not As Bad As All That!).
Contents lists available at ScienceDirect
Telematics and Informatics journal homepage: www.elsevier.com/locate/tele
Adding value to the network: Mobile operators’ experiments with Software-as-a-Service and Platform-as-a-Service models Vânia Gonçalves *, Pieter Ballon IBBT-SMIT, Vrije Universiteit Brussel, Pleinlaan 2, 1050 Brussels, Belgium
a r t i c l e
i n f o
Article history: Received 9 July 2009 Received in revised form 27 November 2009 Accepted 18 May 2010
Keywords: Software-as-a-Service Platform-as-a-Service Business models Mobile operators Mobile platforms
a b s t r a c t The environments of software development and software provision are shifting to webbased platforms supported by Software-as-a-Service (SaaS) and Platform-as-a-Service (PaaS) models. This paper will make the case that there is equally an opportunity for mobile operators to identify additional sources of revenue by exposing network functionalities through web-based service platforms. By elaborating on the concepts, benefits and risks of SaaS and PaaS, mobile operators’ experiments are compared and similarities with these models are identified. Based on the analysis of various case studies, this paper argues that mobile operators mobile web services are decisively shifting from SaaS to PaaS models. However, these platforms incorporate fragmentation at several levels and are likely to face future challenges in order to thrive. Ó 2010 Elsevier Ltd. All rights reserved.
1. Introduction Mobile telecommunications networks and the internet have evolved as disjoint worlds with regard to software applications and application development technologies. Mobile operators are now at the crossroads of maintaining ‘dumb pipes’ on the one hand, and finding sources of additional revenue on the other hand. As large parts of the IT industry are moving to a web service delivery model, there seems to exist an opportunity for mobile operators to learn from these experiences and adopt similar models by exposing network capabilities and combining these with online content and applications. It has been argued that mobile operators should move from an integrated network-centric model to a more modular web-based model, in which network services are opened up to end-users and professional developers (Ballon, 2009; Constantinou, 2009; Quayle, 2008). Over the last decade, examples of such web-based models have abounded, as the web has evolved from a collection of informational websites to accommodate a new range of services and applications delivered to customers through a number of business models, most prominently Software-as-a-Service (SaaS) and Platform-as-a-Service (PaaS) models. Although both models offer a template to monetise data services over the web and while they are intertwined from a technological point of view (Armbrust et al., 2009; Chappell, 2008), a clear break exists between the two concepts from a business point of view. On the one hand, SaaS presents the embodiment of a one-sided market model for developing and delivering ICT services, wherein services flow in a linear fashion from ISVs to customers, with revenues flowing in the opposite direction. On the other hand, PaaS fits a two-sided market model wherein a platform mediates between the demand and supply side. In the case of ICT services, a platform owner facilitates an environment for application design, development and delivery through a platform that allows application developers to provide a service to the end-customer and get revenues from it. Thus the platform owner creates value for upstream developers and downstream customers and extracts revenues from both sides.
* Corresponding author. Tel.: +32 26291620. E-mail address: [email protected] (V. Gonçalves). 0736-5853/$ - see front matter Ó 2010 Elsevier Ltd. All rights reserved. doi:10.1016/j.tele.2010.05.005
V. Gonçalves, P. Ballon / Telematics and Informatics 28 (2011) 12–21
13
Over the past years, platform literature has started to explore a number of fundamental differences in the business logic between one-sided and two-sided markets (Armstrong, 2004; Bresnahan, 1999; Gawer, 2009; Gawer and Cusumano, 2002). It has been argued that the main elements of leading platform providers’ business logic are the following:
fostering a thriving ecosystem of internal and external complementary innovations and innovators; influencing architectural design through open interfaces combined with core intellectual property assets; balancing consensus and control strategies towards contributors of complementary innovations, and reflecting this in the internal organisation, e.g. by adopting a systemic and neutral mindset that extends to the whole industry.
While the literature on ICT platforms has suggested that ICT service providers often have the discretion to make active design choices and strategic choices to become a platform or not (Evans et al., 2005), platform literature also suggests that the necessary competencies to succeed in services and in platform services are not aligned, and that there are specific contextual conditions under which platforms can thrive. However, the question under which conditions platforms successfully arise has remained largely unexplored up until now. Mobile operators have been exhorted to branch out into web-like services, applications and platforms for several years. However, former attempts of service diversification through mobile data services such as WAP and walled-garden portals have failed or are experiencing slow take-off (Ballon, 2009). Despite the great build-up for these services, the main cause for this failure appears to be business models built on unfavourable revenue sharing models, resulting in poor incentives for application providers (Lindmark et al., 2004), proprietary standards, and the inability to attract a critical mass of users (Funk, 2007). In the most recent quest for new business models for mobile data services, mobile operators are revamping old platforms (e.g. Vodafone Live! (Green, 2008)), reconnecting with application developers through specific application development platforms (e.g. Betavine) and partnering among operators to offer mobile web services and mobile service platforms (e.g. Joint Innovation Lab, 2009). Such mobile web services entail new business models which are essentially SaaS and PaaS models. However, explicit references to experiences with these models in the IT and internet industries are only seldom made. By assessing different case studies of mobile operators’ experiments in offering mobile web services to several stakeholders we aim to frame them within the SaaS and PaaS frameworks, to explore some of the similarities and differences, and to derive a number of factors and challenges that should be taken into account by mobile operators. It will be argued that PaaS models are a logical evolution of SaaS models as mobile operators are faced with challenges of providing a variety of low-cost applications and of fencing off competition from large IT and internet companies. The structure of this paper is as follows. First, both SaaS and PaaS concepts are delineated from a business perspective, taking into consideration the current market trends. Secondly, the benefits and risks of both models are analysed in order to better understand the implications for suppliers as well as customers. Thirdly, a number of success factors for platform owners are identified. Finally, mobile operators’ case studies about mobile applications’ development platforms are analysed and several trends and challenges are highlighted. 2. Software-as-a-Service The Software-as-a-Service (SaaS) concept has been presented by ICT market analysts (Mizoras and Goepfert, 2003) and software industry associations (SIIA, 2001) as an improved version of the Application Service Provider (ASP) model, in which providers host and provide access to a software application over a network. This application service is managed centrally and offered in a one-to-many fashion. The SaaS model has evolved into a web-based application interface, incorporating other attributes such as multi-tenant efficiency, configurability and scalability (Chong and Carraro, 2006). ISVs were then able to shift from delivering on-premise software solutions to deliver a complete software application to end-users over the web, providing a much more flexible experience in terms of time and location of access. Although the current literature focuses primarily on business-oriented SaaS services, several market examples lead to a categorisation that also includes consumer-oriented service offerings. Business-oriented SaaS services are offered to enterprises and organisations of all sizes, but typically focused on SMEs (e.g. Salesforce.com, RightNow, Amazon S3). Consumer-oriented SaaS services are offered to the general public for a wide range of applications like hosting, news feeds, storage, presentations, and so on (e.g. Blogger, Dropbox). The following subsections describe SaaS revenue models as well as the benefits and risks for the main stakeholders. 2.1. Revenue models Shifting from offering on-premise software to SaaS obliged ISVs to change the way software was sold. In an on-premise scenario, the customer buys a license to use an application and installs it on his or her owned or controlled hardware. By acquiring the license the customer perceives unlimited usage of the software. In SaaS models, instead of buying a lifetime license, the customer pays a fee for software running on a third-party server and loses access when he ceases payment. This fee can either be charged as a pre-paid subscription or on a pay-as-you-go basis. Typically, in the first approach, players offer
14
V. Gonçalves, P. Ballon / Telematics and Informatics 28 (2011) 12–21
different subscription fees based on a combination of allocated resources, namely storage, data transfer, session-time, number of users, etc. In the second approach, pay-per-use fees are charged on the basis of actual usage of those resources. Consumer-oriented services are often provided to consumers at no cost, but are supported by advertising or are offered for strategic reasons such as customer lock-in. These free services are often used to up-sell advanced features (e.g. extra storage space) on a subscription or pay-per-use basis.
2.2. Benefits and risks The SaaS concept has changed the way software is developed and delivered to the customer. The shift from on-premises software to web applications and from one-to-one to one-to-many service provision has impacted on the relationships between ISVs, customers and developers. ISVs make and sell software to customers and normally deal with software distribution channels and licensing. In the shift to the SaaS model the most important benefits for ISVs include potential economies of scale in both production and distribution costs, more predictable revenues, the development of software with lighter operating systems and hardware requirements, and shorter sales cycles. The possibilities of spreading the costs of innovative solutions over many customers, lower license compliance management activities, and the lower need to deal with piracy and maintain expensive distribution channels potentially lead to economies of scale in the production and distribution processes. Additionally, software with lighter operating systems and hardware requirements enable ISVs to shorten the development life cycle, easily provide additional features, rapid updates and support, and potentially reduce maintenance costs. However, the SaaS model also entails several risks which ISVs are not used to deal with. Moving to the SaaS model requires ISVs to develop new skills when planning SaaS offerings, such as management of billing and customer data, usage metering, security, support services and service provisioning. ISVs should also take up investment in building, and later on, maintaining the IT infrastructure to support SaaS services, or partner with other companies to provide those parts of the system (e.g. DropBox uses Amazon S3 storage services). In this latter case, ISVs now need to manage a network of suppliers that did not exist in the on-premises model. Moreover, the risk of performance and scalability issues is higher, as many users utilize an application running in the same server. From a business perspective, the SaaS model also implies changes to the role of the ISV in the ecosystem – the ISV once pictured as a Supplier is now a Service Provider with direct and continuous relationship with end-customers. Therefore, the market is one-sided in view of the fact that there is one group of customers directly reached by the service provider, relieving intermediate old retail channels. The SaaS concept seems very attractive for business customers such as startups and SMEs which do not see IT-related activities as a core competence and do not have the expertise to develop and maintain applications inside the company. It may enable them to have access to expensive commercial software with little initial investment and low monthly costs, something they could not afford otherwise. Therefore, SaaS offers opportunities to reduce the total cost of ownership of IT resources, alleviating companies from running applications in-house and committing to set-up an IT department to administer software and all related activities involving hardware maintenance, backups, security and user support. For companies that have very specific software needs (very complex and expensive software is needed in particular phases of a product development cycle), SaaS can significantly alleviate software costs, as companies would be able to subscribe to services for short periods of time. SaaS providers may also offer customers the possibility to share data with other online or on-premises applications with little effort. Similarly, the retail customer benefits from access to a wider range of software applications, generally at affordable prices or for free and with little effort of configuration or customisation. For both types of customers, SaaS has the potential to provide a stable, reliable and flexible experience, with access to software regardless of time and location. On the other hand, customers may incur very important risks in exposing or losing business-critical data to SaaS providers and potentially losing control of data exchanges to third-parties. Likewise, SaaS providers may lock-in customers by not providing the tools to export (and import) data and therefore making it difficult to switch to other providers. Additionally, interruption of the service due to lack of payment, might also implicate failure to recover stored data.
3. Platform-as-a-Service The Platform-as-a-Service (PaaS) model is a novel approach for software suppliers that want to focus primarily on the development cycle and the monetisation of new applications, thus bypassing the investment in and the maintenance of the underlying infrastructure. PaaS platforms facilitate the entire software life cycle by offering the underlying services for application design, development, testing, deployment and hosting (Mitchell, 2008). These services enable both professional and non-professional developers to build on the functionalities of an existing SaaS (e.g. Force.com) or develop new web applications (e.g. Google App Engine). PaaS incorporates other attributes such as: built-in scalability, reliability and security; built-in integration with web services and databases; support for collaboration among developers and delivers a user experience without compromise; and support for deep application instrumentation of application and user activity
V. Gonçalves, P. Ballon / Telematics and Informatics 28 (2011) 12–21
15
(Mitchell, 2008). Although cloud computing services (e.g. Amazon Web Services) provide relevant components (e.g. storage) for particular stages of the software life cycle, they do not embrace the integral notion of PaaS. In a business context, this means a move to a Platform model wherein a platform mediates between the demand and supply side. PaaS instantiates the concept of ‘Level 3 platform’ (Andreessen, 2007), given the fact that it provides the ‘‘runtime environment” to run external applications inside the platform itself. Likely PaaS also encompasses Level 1 platform functionality – an access application programming interface (API) to access data and services running on the platform – and Level 2 platform functionality – a plug-in API to inject functionality into the platform. For instance, Google App Engine provides a set of APIs to access user-specific data stored in the platform, as well as Google services data. In the case of MySpace Developer Platform, applications can run inside or outside the platform, which in the latter case they do via a plug-in API. 3.1. Revenue models Since the software life cycle has different stages with different customer requirements at each stage, PaaS providers are building their revenue models based on the access to resources in those stages. In this context, pricing represents the costs producers incur to join a platform in order to develop and deploy applications. Some PaaS providers charge a subscription fee for access to the development and testing functionalities, while others only charge for the actual time end-users spend interacting with the application, i.e. after the application is deployed in the market. For instance, the cost for hosting an application with Bungee Connect is determined by the amount of time end-users spend interacting with each page of the application. Google App Engine offers a certain amount of computing resources for free and allows developers to buy additional resources when needed. By defining a maximum daily expenditure, developers can assign quotas for a set of adjustable resources, such as the amount of stored data or incoming and outgoing network bandwidth used. In addition, the platform owner may offer a marketplace for the commercialisation of applications and charge producers a percentage of sales. The portion of the application’s price producers will receive from the amount customers have paid is thus the revenue share rate. 3.2. Benefits and risks In the PaaS model, the most important value element for customers is quite straightforward: develop and run cloud solutions without having to maintain three environments as in the on-premises software development model, i.e. a development environment, a test environment and a production environment. Using a PaaS, a faster time-to-market may be expected since the platform offers hosting in the same environment for both test and production stages. Since these environments are provided by the platform owner, developers may considerably reduce provisioning and management of their own IT infrastructure (e.g. storage, databases, etc.). The main costs developers incur are runtime fees based on the actual computing resources used by the applications or the number of users using them. Some PaaS platforms foster a developers’ community, giving developers the means to communicate, share knowledge and reuse other developers’ code through case studies, blogs and fora. A strong community around a platform gives developers a feeling of control over the platform and might be crucial to guarantee platform adoption. There is a virtuous cycle involved, as the presence of a community attracts more developers, which means more applications, which presumably attracts more customers, and so on. Quayle (2008) studied forty application developer communities and identified several topics to be considered while building a developers’ community: (1) platform providers should know their audience and build a strong relationship with early adopters; (2) tools, examples and case studies should be provided and developers should be educated; (3) communication and marketing should be done through developers and their success stories; (4) metrics should be aligned with the platform provider’s overall business goals; (5) the business model must be baked into the API, as it will help developers make money and thus the platform provider as well; and finally (6) the developers’ community should be integrated in the platform provider’s marketing processes to allow innovation to reach the customer. PaaS platforms can be more or less open and to a greater or lesser degree lock-in customers. PaaS platforms may be based on standard programming languages like WyaWorks (based on Java), on a combination of standard programming languages and proprietary add-ons like Google App Engine (based on Python), or on proprietary programming languages like Force.com (based on Apex). One important issue that militates against entirely closed platforms is the fact that developers may be confronted with a long learning curve to master proprietary programming languages and APIs, thus requiring more effort in developing an application. A closed PaaS platform also raises risks as it creates lock-in, by preventing developers to port an application to another platform, which may only be circumvented by building the application from scratch in the new platform. Closed platforms may also prevent developers from integrating data from third-party platforms or services. The whole concept of PaaS creates risks in the sense that providing developers with all development tools is a fundamental departure from traditional development environments – the developer is limited to use the APIs available in the platform. Perry (2008) and Warfield (2007) analysed various PaaS examples and identified several advantages related to providing a common and open API. Such an API would stimulate innovation, reduce barriers to entry and increase portability between operators. Additionally, it would reach out to more developers, as they would easily identify the advantages of coding once and deploying and monetising in several platforms (Telecoms.com, 2009). Still, the platform owner could choose to differentiate its platform by offering proprietary APIs on top of the common access API. Similarly to SaaS models, PaaS providers have an incentive to make their services available with light operating systems and hardware requirements, both for the development phase and for runtime. Likewise, the platform owner would avoid
16
V. Gonçalves, P. Ballon / Telematics and Informatics 28 (2011) 12–21
dealing with license compliance and piracy issues. Still, the most important value element for platform owners is earning revenues from applications hosted in the platform. Nevertheless, the success of the platform will heavily depend on the platform owner’s strategy and the right balance between open and closed, proprietary and non-proprietary, free and paid elements, making the offering captivating enough for users on both sides of the platform. It is likely that developers are not keen of long learning curves when developing for a new platform, that they want to be able to try out how a platform works and responds before committing themselves to it, that they are typically eager to use tools to share ideas and knowledge, and ultimately want the option to put the application on the market with little effort. A marketplace that advertises developers’ applications would allow a win–win situation between platform owners that sell and host applications, developers that write them and customers that want to buy and use them. Once the platform is successfully adopted, the platform owner has to deal with a new set of issues, related to performance, scalability, storage and security. The platform owner cannot control the quality and security of the code that runs within the platform, but has to create the technical mechanisms to anticipate the consequences of such problems. One can argue that in this model the developer can devote more time to the creative process and therefore a whole new range of innovative applications will emerge. The end-user will benefit from a large quantity of applications that make use of integration and aggregation of data provided by other applications or systems. The large offer of such applications will likely decrease the price for consumers. However, the end-user might incur the risk of paying for a service that is periodically unavailable. For instance, App Engine returns an unavailable status and the end-user is not able to use the application once it exceeds the daily resources’ allocation (Google, 2009). In summary, although SaaS and PaaS might target different sets of customers, they appear to be based on the same types of revenue models of subscription or pay-per-use fee, and have some common benefits and risks. The diagram of Fig. 1 summarises the benefits and risks for the three aforementioned stakeholders – platform owner, end-user and developer. The left side of the diagram explores the SaaS concept and PaaS is examined on the right side. The upper part looks at the benefits of these concepts for each stakeholder and in the lower part are enumerated the risks. The overlapping benefits and risks of the two concepts are represented in the central section of the diagram. 4. Success factors for platform adoption Examples of web-based platforms that encompass the previously analysed concepts proliferate in the web and their success factors have also been considered in the literature. Success factors cited in the literature comprise the agility, efficiency
Fig. 1. Summary of benefits and risks for different stakeholders in Software-as-a-Service and Platform-as-a-Service models.
V. Gonçalves, P. Ballon / Telematics and Informatics 28 (2011) 12–21
17
and flexibility of inherited business processes (Lawler and Howell-Barber, 2007). The flexibility of these processes and interoperability between systems may give competitive advantage to customers among their competitors (Kittlaus and Clough, 2009). Time to market new services and being focused solely on customers’ needs may be considered as further success factors for platform owners (Blokdijk, 2008). Furthermore, other success factors that may induce customers to take the risk of losing control and be locked-in by the platform should also be considered. In the case of SaaS, these factors are mainly related with the balance between the uniqueness and quality of offering and involvement of customers. Firstly, distribution costs should be inexistent and provision costs to one customer or hundred customers should be barely the same. Secondly, investment costs for customers should be meaningless and the pricing rules to get access to the platform should be straightforward. Thirdly, customers should have the ability to participate in the improvement of the platform (e.g. by reporting bugs) and therefore benefit from a continuous customer care and frequent and easy software updates. Finally, services should be made available with minimum configuration requirements and with small further needs for customisation. By opening SaaS services to a large number of developers, the platform evolves to a PaaS model and in turn gives developers the opportunity to offer SaaS to end-customers. In this case, a new underlying business logic and architecture is implied in order to manage both the demand and supply sides. Hence, the main focus of control (i.e. ability to lock-in) moves from the application developer to the platform provider. In this case, the success factors for platform adoption are also associated with pricing. The costs developers have to support to access the platform should be meaningless and there should be no need for specific investments. In addition, the tools and programming languages made available to developers should not require additional effort in comparison with an open development environment and the advantages of a single development environment should be highlighted. Making available a channel that provides a clear way to market and a revenue share rate that fairly rewards developers can also be considered relevant factors that would drive platform adoption, as they would also provide the incentives to switch from traditional development environments. Overall, these factors should be rightly balanced in order to induce developers to join the platform while at the same time delivering added value that justifies closed, proprietary or paid elements.
5. From SaaS to PaaS: mobile operators’ approaches This section analyses several case studies that show the evolution from SaaS to PaaS models in several attempts made by mobile operators to offer mobile web services and mobile service platforms to various sets of customers. Table 1 presents an overview of several experiments considered by mobile operators. The data was collected through material publicly available on the internet (papers, presentations, reports, news, and so on) and by signing-up for a developer account in these platforms. This public data is the one stakeholders perceive and will constitute adoption drivers of the platform and services by developers and consumers. Further work will involve in-depth analysis of the cases by interviewing key actors in operators’ organisations in order to picture potential platform business models (Ballon et al., 2008) for operators. Among the success factors identified previously in the examples in the IT sector, the following factors were selected and considered for the comparison of mobile operators’ platforms: the availability of application programming interfaces, the presence of an actively supported developers’ community, the presence of a common marketplace, the cost of joining the platform, the revenue share rate employed, and the availability of hosting services. In addition, global access – the platform’s openness to different value chain producers and locations – is also considered. In a telecommunications context, the mobile operator would give the opportunity to any type of stakeholder, be it a content provider, an application service provider, a developer or an experienced end-user, to create and experiment with mobile applications. Even if mobile operators’ operations are normally focussed in one country or a group of countries, the internet is global and potential contributors can be based everywhere. The first examples of mobile operators’ experiments with mobile web applications in Europe were the Wireless Application Protocol (WAP) services. Original WAP services included news and sports headlines, weather forecasts and stock quote services. Even though most WAP services were offered by external content providers as a white brand, these were then mostly marketed by operators as a single service package, i.e. as a monolithic SaaS. However, by 2001 WAP was already predominantly referred to as an outright failure in terms of actual usage and revenue generation (Koster et al., 2001; Palomaki, 2004; Ramsay and Nielsen, 2000; Sigurdson, 2001). Although precise usage and revenue data were – and still are – very hard to come by, WAP usage was considered to be marginal and customer dissatisfaction to be high. Lindmark et al. (2004) argue that three reasons were underlying the WAP problems of poor usability, lack of attractive content, high costs, and badly managed user expectations about the ‘mobile internet’: (1) the fragmentation and the resulting lack of dynamism of European markets, when compared to the Japanese market; (2) the European lack of coordination of the availability and performance of complementary ‘mobile internet’ subsystems, resulting in diverging WAP implementations; (3) the unattractive revenue sharing models and cooperation agreements offered by European mobile operators to so-called ‘third-party content providers’. These lead to conclude that the failure of WAP is precisely due to its business model based on operators’ monopolistic strategic and managerial decisions, thus hindering a multitude of content providers’ participation and innovative experimentation. In this route from SaaS to PaaS, the following experiments are classified as hybrid models between SaaS and PaaS, as they present characteristics of the two models. The first examples consist of messaging (SMS and MMS) gateways offered to appli-
18
V. Gonçalves, P. Ballon / Telematics and Informatics 28 (2011) 12–21
Table 1 Comparison of mobile operators’ experiments. Global access SaaS WAP
API
Developer’s Marketplace community
Pricing
Revenue share rate
Hosting
N/A
Variable
U
U
Setup and monthly fee N/A
Variable between 45% and 80% Variable
Partial
Partial
U
Free
91%
Partial
U (for selected countries)
Free
Based on the application’s category
U (through a partner)
(mainly to content providers)
SaaS–PaaS hybrids Telenor CPA
(mainly to content providers) Vodafone Live! (mainly to Portal content providers) (mainly to NTT DoCoMo i-mode content providers) Portal
U
PaaS Orange Partner
U
Proprietary/ IMS
U
Vodafone Betavine
U
U
O2 Litmus T-Mobile Partner Network BT Web21C SDK Ribbit
U (USA based producers) U U (some services are USA based)
Proprietary/ GSMA OneAPI Proprietary N/A
U U
Proprietary Proprietary
U U
Telenor Playground
(to be approved by Telenor) (content in Spanish) U (content in Italian) U
Parlay
U
Propriety
U
IMS N/A
U
N/A
U
Telefonica Open Movilforum Telefonica WIMS 2.0 Telecom Italia Next Open Innovation Joint Innovation Lab
Free U U
(within Telenor operating companies)
N/A U
U
Free Free
70% 70%
U
Free Free/ monthly usage Free
N/A Based on usage
N/A
N/A
U
Free
N/A
N/A
N/A N/A
N/A N/A
N/A N/A
Free
N/A
N/A
N/A, no information available; U, available; , not available.
cation providers or content providers within the operator’s infrastructure for the delivery of business-oriented services mainly, serving several customers each with its configurations in a scalable manner. The successful Telenor Content Provider Access (CPA) system in place since 2000 is a profitable implementation of this paradigm (Nesse, 2008). In this case the mobile operator is in direct competition with application providers, e.g. (Clickatell, 2009; MX Telecom, 2009), that apart from providing gateway services, also offer APIs, code examples and user-friendly web management solutions for API connections or billing. Although successful among content providers due its open and market wide platform (Nielsen and Aanestad, 2005), CPA’s upfront costs, fixed revenue share rate and formal contract agreements creates barriers for mainstream developers’ adoption and makes it less attractive than those solutions delivered by application service providers that require little initial investment. As mobile operators began to recognize that a key contributor to mobile adoption was the provision of content and services to mainstream customers, following experiments with mobile content portals also demonstrate mobile operators’ attempts to open their networks to content providers. Vodafone and NTT DoCoMo were early pioneers in launching these content portals choosing as main strategy the partnership with content providers for the provision of quality content (Tseng et al., 2005). One may argue these portals are an instance of the SaaS model as they provide, among other services, games, ringtones, tools to backup contacts, internet and email access for an additional fee or for free. But at the same time, they already present characteristics of the PaaS model. Vodafone Live! was a rather closed service with contract based providers with variable revenue share rates, but i-mode was much more open and allowed both officially registered and unofficial content providers. The latter providers were able to offer their services directly to end-users, thus bypassing the 9% charge levied by the operator. In particular in Europe, these walled-garden portals experienced slow take-off due to the lack of attractive content, unsuccessful management of user’s requirements and expectations, and insufficient operators’ service creativity and innovation. More recently a slow evolution to platforms started to take place demonstrating operators intention to give other stakeholders the opportunity to fill in the gap of their lack of success and to slowly mature the importance of the information operators own about their customers and the intertwined opportunities for service innovation and additional revenue. This approach consists of exposing telecommunications network functionalities through APIs to third-parties that will take up service innovation, bring services to market more rapidly, increase customer intimacy through personalised services and realise the PaaS concept for telecommunications services to a large mobile operators’ customer base. This model, referred by
V. Gonçalves, P. Ballon / Telematics and Informatics 28 (2011) 12–21
19
(Aepona, 2009) as Network as a Service (NaaS), is being offered by some mobile operators mostly on an experimental basis allowing third-party developers to use a limited number of network capabilities (messaging, location, rich presence, charging and so forth) to develop new applications. As shown in Table 1, there are many initiatives currently being tested but they are still very much in their infancy as could be inferred during the course of this research by the changes occurred in websites’ layout, content and business models and the announcements of similar initiatives by the same mobile operator. All operators seem to have succeeded in building up the concept of community around the platform by providing code examples and case studies and making available spaces for discussion and sharing of experiences through a blog or forum. Most platforms allow any type of developer, startup or application provider to join in. Nevertheless, most of them require as mandatory information a mobile phone number to validate the registration. Some operators offer free premium subscriptions (e.g. Orange Partner) which include privileged access to development tools, support and commercialisation in the marketplace. Access to Ribbit’s platform is also free, but a subscription based on usage of communications features and services (e.g. SMS, voice mailboxes, international calls, etc.) incorporates the total costs of the application in production stage. Telenor Playground targets service and application providers mainly and the enrolment process seems to follow a long and custom procedure. On the other hand, the offer of APIs is very fragmented – proprietary (although in some cases open) APIs; GSMA OneAPI (GSMA, 2009); Parlay (Parlay, 2009); and OMA IP Multimedia Subsystem (IMS) (Alliance, 2005). In terms of geographic restrictions, T-Mobile Partner Network is only open to companies and is currently restricted to USA based ones. Open movilforum website’s content is mainly in Spanish, with only a short introduction of the platform in English. Although the description of most APIs is provided in English, most support and community pages are in Spanish. Some operators already gave a commercial component to the platform, enabling the developer to define a price and sell an application. Orange Partner, in place since 2005, finally launched an application shop by the end of 2008 in the operator’s online portal and WAP portal in some countries of the Orange group. Likewise, TMobile publishes applications in web2go, the operator’s marketplace portal. Vodafone (through betavine.mobi), O2 and Telecom Italia chose a different approach – the involvement of early adopters in the platform’s website. Hence, in an attempt to strengthen the feedback loop for developers, the end-user can download for free (Litmus also offers paid applications), test, rate, send feedback to the developer and share applications with other friends. Regarding the revenue share rate, O2 and TMobile adopted the same model of the Apple Store – a split of 70% for developers and 30% for the operator. Orange Partner splits the revenue between Orange, Cellmania and the developer. Overall, the analysis of these case studies enables us to conclude about the fragmentation of these platforms at several levels – multiple programming languages, multiple network APIs, multiple application shops, multiple markets and multiple platforms supported by the same operator. For instance, Telefonica is developing two distinct platforms, one promoting its open network APIs and another mainly based on IMS. O2, Telefonica’s subsidiary, is also a front-runner in involving the developers’ community in this new paradigm. On the other hand, Telenor is supporting two distinct platforms according to the target producers, one more oriented to service and application providers and another, Telenor iLabs, to let developers experiment with Telenor’s network capabilities and data assets. Vodafone, apart from supporting Betavine, is also leading the Joint Innovation Lab (JIL) which is oriented to the development of mobile widgets. Nevertheless, JIL is the first joint attempt of operators (Vodafone, Verizon, China Mobile and Softbank) to cut on the complexity of making applications suitable for multiple mobile operators. Moreover, most operators identify the platforms as beta environments, thus neither communicating a clear route to market with attractive revenue share rates for suppliers nor managing suppliers’ requirements and expectations. Therefore, in order to guarantee platform adoption, operators ought to avoid fragmentation, show a clear market strategy, choose a common API and deliver value for upstream and downstream customers by assimilating their requirements and expectations. In conclusion, in the context of mobile web applications, the risks faced by mobile operators in the implementation of the SaaS model – management of a network of suppliers, take the role of service provider implying new skills and direct relationship with end-users, deal with performance, scalability and security issues – were too great compared to the small value delivered to customers and content and application providers. As mobile operators now move towards a PaaS model, as demonstrated by the case studies analysed, they should take into account the changing mindset associated with platform leadership consisting of four main elements:
fostering a thriving ecosystem of internal and external complementary innovations and innovators; influencing architectural design through open interfaces combined with core intellectual property assets; balancing consensus and control strategies towards contributors of complementary innovations, and reflecting this in the internal organisation, e.g. by adopting a systemic and neutral mindset that extends to the whole industry.
Furthermore, the success factors derived from the IT sector concerning PaaS should also be considered. While a single development environment is a clear advantage for developers, locking-in developers by only making available proprietary programming languages and APIs or preventing interoperability with third-party services or platforms, might drive developers away. Common APIs between platforms and standard programming languages give developers the incentive to invest in the PaaS paradigm and see the potential to earn additional profits. In addition, code examples, fora for discussion and knowledge sharing would support the development phase and enable a faster time-to-market. The costs to join the platform and attractive revenue sharing models constitute further decisive factors to guarantee platform adoption. Altogether, the
20
V. Gonçalves, P. Ballon / Telematics and Informatics 28 (2011) 12–21
right balance between these factors and underlying technical characteristics would avoid diverging platform implementations and fragmentation. 6. Conclusion This paper analysed the SaaS and PaaS concepts from a business perspective and highlighted the benefits and risks for both suppliers and customers. It showed that from a business perspective, SaaS presents the embodiment of a one-sided market model whereas PaaS fits a two-sided market model. It then analysed several case studies that illustrate progressive attempts of mobile operators in delivering a wide range of attractive mobile applications to their customers. The first experiences show characteristics of the SaaS paradigm, while recent experiments incorporate a larger set of characteristics similar to the PaaS model. While slowly moving to this model, operators should adopt a platform mindset and incorporate the right balance of platform characteristics that guarantee platform adoption and avoid market and platform fragmentation. Based on the case studies, the biggest challenge to guarantee platform adoption seems to be posed by today’s fragmentation of mobile operators’ platforms. Acknowledgement This article is based on results from the WTEPlus project (IBBT project 10328), which is funded by the IBBT (Interdisciplinary Institute for BroadBand Technology) of Flanders, Belgium, as well as by the various partner companies. References Aepona, 2009. Making NaaS a Reality.
V. Gonçalves, P. Ballon / Telematics and Informatics 28 (2011) 12–21
21
Telecoms.com, 2009. Orange Sees API Uptake, but Operator Cooperation Needed.