Books have been printed since the 15th century, and since then, the publishing business has operated under the following simplified model: writers write, publishers publish and distribute, and both book publishers and bookstores sell.
Digitalization, the platform economy, and APIs have changed the business models and value streams associated with books. The change started with e-books and e-book reading devices. For example, book platforms such as lulu.com and BoD.fi, are built on their own APIs and those provided by other companies.
The “platform author” publishes his work for free as a self-published book. Through the platform, the book is distributed to domestic and international web and brick-and-mortar bookstores as an e-book or printed book. Books are printed automatically and only on request. Platform charges a commission per sold amount.
The platform offers added value: writers reap a larger share of the revenue and can decide on content and pricing, while readers enjoy a wider range of offerings and lower prices. Partners can publish series of books in a fully automated way. In general, the marketing of self-published books is largely based on search engines and the “long-tail phenomenon,” wherein a niche-market product can be found online and acquire buyers even if it might be lost among traditional channels under bigger brands. The author’s choice to self-publish a book or work with a publishing company does, of course, affect more than revenue. A prestigious publisher brings credibility to the book, as well as a skilled team and a well-tuned marketing machine. Self-publishing platforms work well if an interested publisher is not found, if the book is to serve as more of a marketing publication, or if the author has a readership that will find the book in any case.
The changes in the business model are significant – and enabled by APIs. The publishing platform typically utilizes other APIs, such as to create an ISBN and an EAN code for digital printing[ii] and for publishing books on e-commerce platforms. In its most advanced form, it will be possible to offer the entire book via the API, predicts Hugh McGuire, founder of Pressbooks.[iii]
API-related meetings in corporations are mostly private discussions on IT architecture and usually take place in the IT department. An API is the organization’s own digital and sellable service product. On the other hand, it is also a commodity that can be bought. It can be a way to save money and time or improve the competence of the IT environment. It can also be a mandatory part of building a digital customer experience. All of these are related to a company’s business model, which will define how value is created, shared, and combined using functions, resources, and competencies. There still exist numerous companies where the issue is briefly dismissed with, “We don’t bother business with this API stuff.” A visiting API consultant should be affixed with the label: “Warning – may change your business model.”
For non-IT professionals, the API is initially a difficult technical issue to grasp, and it is surprisingly easy to confuse it with the “app,” i.e., an application with a user interface installed (for example, on a mobile phone).[iv] Technology is not the same as a business model, but technology has a significant impact on the feasibility of a business model.
In addition to the publishing industry example presented earlier, this book introduces examples from the retail sector and its relation to APIs and the platform economy. We get to know Kesko (K Group), look at its competitor the S Group, and end up with a platform that offers Alibaba’s interfaces, which is in fact so attractive that even Kesko has decided to join it.
With the help of Nordea and the Ministry of Transport, we are considering the impact of APIs on the banking and traffic sectors. We delve deep into the impact on business models and the operating conditions of companies within public sector-driven ecosystems and legislation requiring APIs. Will forced interaction produce new platform innovations and customer-orientation?
Currently, many companies are starting to resemble a technology enterprise. At the end of 2016, while working as Kesko’s API Development Manager, Marjukka joked with a colleague, “When will Kesko management understand that it is leading a technology company instead of a retail and wholesale one?” (Then, a couple months later at the Paris retail fair, President and CEO Mikko Helander was asked the same question: whether he knows he’s in charge of one of Europe’s biggest technology companies.)
In late 2016, API development was just getting wind under its sails, partly supported by the fact that more digital services were being created than anyone could keep track of.[v] In the digital services for grocery trade, APIs had already been put into use. The business model and customer experience improvements for the building and technical trade’s online stores were also being sped up by API development. The customer experience for homebuilders and renovators was greatly improved by not having to visit the stores’ websites one-by-one when first trying to find a new sauna stove in stock, for example. APIs are used to calculate the distance from the customer’s home to the store with the most stoves in stock or the particular model they are hoping to buy. The API even calculates the shipping costs using the data from the shipping agreements. The same APIs could also be used in the price signage and marketing displays of offline stores, digital marketing, and different digital channels, as well as via partners.[vi]
The API can be part of the company’s business model in many ways. It can be part of the company’s offerings, or the company can exclusively sell APIs. An API can be a way of communicating with customers and partners or a way to improve the quality of information and reduce costs for a company’s various internal services and systems. At its best, API can be a key element that attracts actors to the ecosystem and related platforms. In most cases of retailers and wholesalers, product manufacturers and other potential partners, especially large customers, are most interested in purchasing history and analysis.
What about order APIs? Whom should you provide access to orders via APIs? Is the channel and brand so valuable that it is not worth relying on others? Kesko and other Finnish retailers have thus far answered this question with a strong “maybe.”
For example, in the autumn of 2017, the S Group announced that it would build an API layer.[vii] The reasons for this were both the robustness of the current technical infrastructure (technical debt) and the construction of digital services, not so much to provide interfaces directly to partners or customers. However, in 2010, the S Group outsourced part of its platform and interface development to Digital Goodie (previously Digital Foodie), with whom it was collaborating.[viii] So in 2016 the platform was sold to a US company.[ix] Digital Goodie offers APIs, but information is only available to their partners (so there’s no use looking for API documentation on the internet).
The market was caught by surprise for a moment in September 2017 when Kesko became a channel partner for Chinese Alibaba.[x] In this case, the Alibaba platform business model and its relatively well-marketed, publicly documented (compared to Digital Goodie) APIs were used. These APIs allow companies to place their products on the Alibaba online store platform.[xi] Along with Amazon (operating a similar business model), Alibaba has grown into one of the largest online stores.
At the same time Finnish stores were facing challenges, especially online stores,[xii] many foreign players have been able to create a comprehensive, fast-growing, and dynamic e-commerce, often thanks to the development of APIs and other user experiences that affect features for traders and suppliers. Of course, customizing the customer experience and simplifying the ordering process cannot be forgotten.
In a competitive situation, it is not always clear in which manner the business model should be changed or why. Often, companies have limited possibilities to influence their own models. The business is subject to restrictions or requirements that reduce the freedom of choice. Continuous price competition between all parties is short-sighted and drives companies into impossible situations. What if an operator from a completely different industry, with their particular platforms and a very different value proposal, were to suddenly appear and upset the market? What if the law changed so that a distinctive factor became mandatory for everyone? That is what happened, for example, in the banking sector with the PSD2 directive, when banks were forced to open their APIs to other players, and in Finland’s transport sector, when the Finnish Ministry of Transport and Communications required the opening of ticketing APIs.
The Finnish Transport Agency presents the objectives of a project involving the opening of traffic-related APIs as follows: “With digitalization, mobility also changes to service (MaaS, Mobility as a Service). Mobility as a service is a very large ecosystem in which the travel chains handled as part of the ‘interoperability of ticket and payment systems project (“LIPPU”)’ is one small but crucial part. From the customer point of view, the travel chain model helps journey planning and saves time. In the future, even more services, including ones other than mobility services, will be collected as service packages for customers. These packages will increase the appeal of services and will eventually bring more customers to all operators in the ecosystem.”[xiii]
At this very moment, while writing this book, we will soon learn whether the transportation operators will really start selling each other’s tickets or whether there will mostly be operators reselling tickets for different operators. What about customer experience and prices? In the Helsinki region, Whim – which connects different modes of transport to public taxis – has started operating at a fixed monthly price. Thus, operators in the transport sector must compete with applications that support their own brand and customer experience and deal with these intermediary services both as partners and competitors.
For example, Finland had a great app, Valopilkku (“BrightSpot”), for taxi services throughout the country. For a moment, however, the app was almost lost to competition because of new laws liberating the domestic taxi business. This change forced Finnish taxi providers to think about which ecosystems they wanted to operate within. At the time (November 2017), one of the biggest taxi operators, Taksi Helsinki, stopped using the Valopilkku app and developed their own. However, as Valopilkku offered a solution and an extensive nationwide network, Taksi Helsinki decided in May 2018 to buy the Valopilkku app for itself and continue its development. Obviously, where there are mobile applications, there are usually also APIs, and one might be able to also use them for other purposes, such as offering them to partners.
The common feature of “forced openings” for both the banking sector and the mobility interfaces is that the public sector decides to open the APIs but does not set clear guidelines for implementation. There are considerably more recommendations in the Finnish Transport Agency project than in the banking sector. Are these “free hands for developers” a good or a bad thing in the end?
Most of the interfaces of the banks operating in the Nordic countries are not particularly user-friendly. In other words, the developer experience[xiv] is poor and thus reduces the use of API and the attractiveness of the company in the partner network. Will the spirit of the PSD2 Directive be fulfilled if other companies are hesitant or unable to implement their own applications against poorly designed or documented interfaces?
As well, what is the significance of public-sector-defined API openings for businesses and their business models? For example, Nordea Bank has publicly stated that it views opening the APIs as a business opportunity, seeks to do it as well as possible, and as a result has contacted developer communities. We were thus interested in hearing more about how the Nordea API journey has progressed. Jarkko Turunen from Nordea answered us, saying, “Nordea’s approach to PSD2 has been very proactive. Nordea opened its Open Banking portal for developers in spring 2017, after which over 1,600 developers have registered to test programming interfaces in the test environment. In the pilot phase, selected external service providers build applications on the interfaces and, together with the pilot customers, confirm that the Open Banking solution works in every respect reliably and as expected. The pilot will initially only use information from Finnish customers, after which customer information will also be included in other Nordic countries.”
Turunen continued: “At Nordea, PSD2 is believed to offer opportunities for new business models where the bank and its customers and partners can benefit from new innovations and offerings. We are talking about the future payment and application ecosystems. In the future, API platforms will function as a new distribution channel for banking services. In addition to the mandatory PSD2 interfaces, Nordea sees the possibility of revenue streams in the Open Banking solution, for example through monetized Premium APIs.”
In all the legislative and other changes widespread throughout the operating environment, there is usually a chance to turn the transformation into a competitive advantage for one’s company. However, it may require joining the movement early, exceeding minimum requirements, and having courage. Also, in the banking sector internationally, various key players have prepared for the opening of APIs. Open Banking is now on the lips of the international banking industry. It is not certain that the clients want Facebook, for example, to know the balance of their bank account, but this can be only a prelude. Legislation can also prevent the opening of interfaces or their use between different actors. An open dialogue between the public and private sectors is a necessity to secure business opportunities.
The most recent examples at the time of writing were the Canadian banks’ demand not to cause unnecessary security threats amidst the PSD2 hype by requiring open interfaces and, on the other hand, the fact that due to legislation, banks cannot cooperate with fintech companies.[xv] Banks are concerned about the distortion of competition, because fintech startups can turn to private investment companies with their product development ideas, unlike banks.
[i] Hereafter, interface is used as a synonym for application programming interface (API)
[iv] Apps (that is, mobile or web applications) use APIs to share information with backend system and data storages or to conduct e.g. calculations or text analyses as requested.
[xi] More on platform-based business and interfaces in Chapter 4.
[xiv] More on developer experience in Chapters 10 and 16.