API Economy 101 E-Book

Jarkko Moilanen

• Herausgeber: Books on Demand
• Kategorie: Geisteswissenschaft
• Sprache: Englisch

Seitenzahl: 306

Veröffentlichungsjahr: 2019

Beschreibung

API is technology and digital product used for artificial intelligence, platform economy, and internet. It has the capability to change business models dramatically. APIs (application programming interfaces) are becoming a major competitive factor for companies. This book takes on the fundamental questions of API Economy and approaches the subject pragmatically and clearly without technical jargon. The book clarifies the birth and shape of the API Economy with numerous practical examples. This is the first API Economy book based on scientific references. Originally this popular book was written in Finnish. It is a great start for students and advanced professionals alike. After reading this book, you will understand what it is all about and how to move forward and grow your business with APIs. The authors are leading Finnish API-experts with an abundance of experience from API and platform economy as authors, researchers, and lecturers and consultants.

Leseprobe

CONTENTS

PREFACE TO THE ENGLISH EDITION

PREFACE

SECTION I: BEGIN WITH BUSINESS

1

WARNING: THE API ECONOMY MAY CHANGE YOUR BUSINESS MODEL

T

HINK OF A

B

OOK AS AN

API

AND A

P

UBLISHER AS

T

HE

P

LATFORM

“W

E

D

O

N

OT

B

OTHER

B

USINESS WITH

T

HIS

API S

TUFF

”

API

OR

P

LATFORM

E

CONOMY

?

S

UMMARY

2

WHAT VALUE DOES YOUR API ADD?

A

DDED

V

ALUE

I

S

E

XPERIENCE

P

IECES OF

A

DDED

V

ALUE

API

AS A

M

EANS TO

V

ALUE

S

UMMARY

3

APIS IN THE ECOSYSTEM

E

COSYSTEMS ARE A

N

EW

C

ORNERSTONE OF

D

IGITAL

B

USINESS

API

S AS

G

LOBAL

G

ATEWAYS

S

UMMARY

4

TRACTION IN THE PLATFORM ACTION

V

ALUE

C

OMES FROM

I

NTERACTION

W

HY DO BUSINESS MODELS CHANGE

?

API E

CONOMY

: A P

LATFORM

E

CONOMY

F

ORERUNNER

S

UMMARY

5

API – A PRODUCT, SERVICE, OR SOMETHING ELSE?

“API I

NCLUDED

”

R

ESOURCE

-

ORIENTED

API W

ORLDVIEW

S

UMMARY

6

BUSINESS MODELS FROM APIS TO PLATFORMS

O

THER

C

RITICAL

A

SPECTS OF THE

B

USINESS

M

ODEL

T

HE

B

EST

B

USINESS

M

ODEL FOR

M

E

?

W

HO

I

S

Y

OUR

C

USTOMER

, W

HAT

I

S

Y

OUR

O

FFER

,

AND

H

OW

D

O

Y

OU

P

RODUCE IT

?

S

UMMARY

SECTION II: APIS – THE LIMITED EDITION

7

CONSUME INTERNALLY – INTERNAL AND PRIVATE APIS

T

HE

D

ISTRESS

A

ROUND

D

ATA

M

ODELS

W

HERE IS THE

I

NTERNAL

API L

OCATED AND

W

HO

U

SES IT

?

D

OES THE

I

NTERNAL

API H

AVE A

F

UTURE

?

S

UMMARY

8

FOR THE SAKE OF PARTNERHOOD – PARTNER APIS

S

TEP INTO THE

API E

CONOMY

T

HROUGH

P

ARTNERSHIPS

C

HOOSING A

P

ARTNER

API

S

M

AKE IT

E

ASIER TO

E

XPAND

Y

OUR

P

ARTNER

N

ETWORK

O

THERS

D

O THE

S

ALES

S

ERVICE

B

USINESS

I

NSTEAD OF

P

ROJECT

B

USINESS

P

ARTNER

API

S

O

PEN

D

OORS TO

N

EW

M

ARKETS

S

OMEONE

H

AS

A

LREADY

S

OLVED

Y

OUR

P

ROBLEM

M

ORE

D

EVICE

S

ALES AND

B

ETTER

C

USTOMER

E

XPERIENCE

W

HAT TO DO WHEN THE

API

IS READY

?

I

S THERE LIFE AFTER PARTNER

API

DEVELOPMENT

?

S

UMMARY

9

APPLY EXTERNALLY – PUBLIC API

B

USINESS

O

PPORTUNITIES FOR

P

UBLIC

API

O

PEN

P

UBLIC

A

DMINISTRATION

O

PEN

D

ATA

API

O

PEN

B

USINESS

O

PPORTUNITIES WITH

O

PEN

D

ATA

API

S

S

UMMARY

10

THE DEVELOPER COMMUNITY AS CUSTOMER

I

GNITING

P

ASSION AND

C

REATIVITY

F

ROM

I

NNOVATORS TO

L

AGGARDS

E

MPATHIZE WITH

D

EVELOPERS

L

IKE

P

EELING

O

NIONS

D

EVELOPERS ARE

L

AZY

,

AND

T

IME IS

P

RECIOUS

T

HE

E

XPANDING

D

EVELOPER

C

OMMUNITY

S

UMMARY

SECTION III: THE LEAN LEAP TO APIS

11

APIS CHANGE YOUR ORGANIZATION

API

S

D

O

M

ORE

T

HAN

J

UST

C

HANGE

IT

I

NTRODUCING

Y

OUR

O

RGANIZATIONAL

C

HANGE

A R

EAL

-

WORLD

E

XAMPLE OF A

S

WEEPING

B

USINESS

C

HANGE

N

O

API

S

W

ITHOUT

A

GILE

M

ETHODS

S

UMMARY

12

ENCOUNTERS ON CANVAS

F

ROM A

V

ALUE

P

ROPOSITION TO THE

B

USINESS

M

ODEL

T

RIED AND

T

ESTED

S

UMMARY

13

START BY EXPERIMENTING LIGHTLY

F

IGURE

O

UT THE

B

IG

P

ICTURE

M

INIMUM

V

ALUE

-

ADDING

P

RODUCT

S

TABILIZE THE

F

ACADE

O

NCE

I

NTERFACE

E

XPERIMENTS ARE

C

OMPLETE

, I

NFRASTRUCTURE

E

XPERIMENTATION

B

EGINS

P

LAN THE

L

IFECYCLE

B

EFORE

P

UBLISHING

S

UMMARY

14

STYLE ABOVE CODE – API DESIGN GUIDE

S

TANDARD

I

NTERFACES

T

HE

R

OLE OF THE

API D

ESIGN

G

UIDE IN

API D

EVELOPMENT

E

VALUATE AND

V

ALIDATE

API D

ESIGN

F

ORMULATE

, T

EST

, E

VALUATE

U

SE

S

TANDARDS

A

FTER THE

API R

ELEASE

S

UMMARY

15

AUDIT YOUR APIS

S

ECURITY OR

C

OMPLIANCE

?

U

SABILITY

T

ESTING IS

A

LSO

P

ART OF THE

API

D

ID

Y

OU

B

UY OR

I

NHERIT

Y

OUR

API?

S

UMMARY

16

THE DEVELOPER EXPERIENCE IS THE NEW BLACK

I

NTERFACES TO

F

ALL IN

L

OVE

W

ITH

C

USTOMER

J

OURNEY AS A

C

OMMON

N

ARRATIVE

D

EVELOPER

E

XPERIENCE

I

S

N

OT

J

UST

T

ECHNOLOGY

A G

OOD

D

EVELOPER

E

XPERIENCE

I

S THE

S

UM OF ITS

P

ARTS

C

REATING

V

ALUE

L

OW

B

ARRIERS

U

PDATED AND

C

OMPREHENSIVE

D

OCUMENTATION

W

HEN

I C

AN

’

T

F

IND

W

HAT

I N

EED

C

ONTINUOUS

D

EVELOPMENT

S

UMMARY

17

PUBLISH QUICKLY, SUPPORT, MEASURE, AND LEARN

R

ELEASE THE

F

IRST

V

ERSION OF

Y

OUR

API Q

UICKLY

B

UILD AN

O

VERALL

V

IEW WITH

S

UITABLE

M

ETRICS

API

S AND

D

EV

O

PS

C

OMPLEMENT

E

ACH

O

THER

S

UMMARY

SECTION IV: MANAGING APIS

18

EXPOSED INTERFACES

C

AN AN

API E

XIST

W

ITHOUT

API M

ANAGEMENT

?

D

ECENTRALIZED

API M

ANAGEMENT IN A

L

ARGE

E

NTERPRISE

E

XCEPTIONS AND

O

THER

O

DDITIES

S

UMMARY

19

DISTRIBUTE AND MANAGE

D

OES AN

API

ALWAYS NEED MICROSERVICES

?

S

OURCE OF

E

TERNAL

Y

OUTH

S

UMMARY

20

IDENTITY CRISIS

R

IGHT

A

CCESS

C

ONTROL

M

ATTERS

I

S YOUR IDENTITY BASED ON EMAIL

?

S

UMMARY

EPILOGUE

GLOSSARY

REFERENCES

PREFACE TO THE ENGLISH EDITION

After the Finnish edition was published in August 2018, we received so much encouraging feedback from our readers and requests from the people who couldn’t read the book in Finnish to produce an English edition that we took the demand seriously. The task of translating the book from Finnish to English was quite difficult and costly because the languages are so different. We were grateful to get sponsors to help us use professional editing and allocate time from our busy schedules.

The companies and individuals who made this English edition possible:

Digia Finland Oy – leading digital software and service provider specializing in digital solutions, APIs, integrations and data services. Read more https://blog.digia.com/topic/api

Osaango Oy – API and platform economy educators, consultants and API developer experience reviewers. Osaango’s APItalista and co-author of this book, Marjukka Niinioja created a free course related to this book with Tampere University professor Marko Seppänen, also a co-author. Join hundreds of others in the course at https://www.apieconomy.info

Foccus Design s.r.o. – providers of APItalks.com instant API for your data, based in Czech Republic, read more https://www.apitalks.com/

Heeros Oyj – makers of cloud-based financial systems provided in Finland and the Netherlands, read more:

https://www.heeros.com/en/

HH Partners Oy – attorneys at law focusing on technology, intellectual property and transactions, read more:

https://www.hhpartners.fi/en/

We would also like to thank companies and individuals who encouraged us to make this English edition come true, but who prefer to stay anonym. You know who you are dear family members, colleagues and ex-colleagues, business partners and fellow API-enthusiasts.

For the English edition to be possible at all, we’d like to give special thank you to Ari Nyfors from Transfluent for helping us get started with the project, to Erkki Saastamoinen and Sanna Toivanen from Kesko Oyj for all the worm support, Suna Koljonen and the whole Digia team for continuous support, fellow authors Amancio Bouza and Antti Merilehto for encouraging us both with their amazing attitudes but also sharing the good word on our book and Alena Vejsadová from Foccus Design for staying with the project all autumn and making it possible to get our book to the Czech audiences with a bang.

Helsinki, February 10th, 2019

Marjukka Niinioja, Marko Seppänen, Jarkko Moilanen and Mika Honkanen

PREFACE

The idea to write this book arose as Finland celebrated the 100th anniversary of its declaration of independence. We asked ourselves: How will Finland succeed in the next hundred years? How can we continue to ensure its competitiveness in the future? From the government’s point of view, the platform economy and artificial intelligence play a crucial role; the intention is to be a pioneer in both.1 Whether it is artificial intelligence or platforms, the application programming interface – i.e., the API – plays a key part in all this.

So why did we now decide to write the book? In short, the time is ripe and, according to our experience, the need to build (better) APIs and employ novel technologies in companies is great. In the global economy, Application Programming Interfaces have become an increasingly important way to produce applications, build ecosystems, and participate in the platform economy. To meet this need, we felt it necessary to create a resource aimed at business decision-makers, solution architects, and IT managers.

Our paths around API and platform economy issues crossed at many events and projects. In November 2017, at the initiative of Jarkko Moilanen, we put together our team of authors. Writing alone, the perspective would have been more limited and one-sided; together, we complement each other with our expertise and are able to offer our readers more diverse content.

Our main concern was to examine the development of APIs (often still in their infancy) being used by Finnish companies, how little APIs are understood as part of business models, and the competitiveness of organizations. Ecosystems are created with government funding and by encouragement, and there were hardly any examples of platform economy to speak of.

In Finland, APIs have entered public debate over the past couple of years. In August 2017, Tivi magazine wrote a comprehensive cover story titled “API Brings Money.”2 But do APIs and platform economy bring money to Finland, and if so, how will that happen? According to a study commissioned by the Finnish government, this is at least questionable.3 A member of our author team, Marko Seppänen – together with a research team – has studied APIs and other platform economy boundary resources (explained in chapter 4) and their spread throughout the world. Finland is on the map in “good strokes,” to use a sports term, but is not at the center of development.4

With APIs, the “circular economy” of the IT world changed shape. Prior to the extensive use of interfaces in service development, services were produced by recycling code. Code recycling has become more common with open source, and some of the best-known open source victors are the Linux operating system created by Linus Torvalds, the Apache web server, the MySQL database, and the Android operating system.

Open source code changed the world, and that change was based on code recycling and reuse.5 The open source code is usually the basis for reference implementations6 and co-developed platforms.

Since then, the development of applications and services has become API-based. With APIs, new product development reuses and recycles code, allowing programming interfaces to be productized – both yours and others’. Therefore, the openness of source code is not so central to API-based service development.

Exploiting the APIs of external organizations – often those outside of typical partnerships – in the development of a service contributes to the transformation of companies into ecosystems, because interdependencies are created between organizations. Switching to API-based service development will radically reduce development time. At the same time, the time-to-market for solutions is shortened. Speed is an asset and, therefore, API-based development has risen to default status.

From a business point of view, API facilitates rapid growth of the market for a company’s products. Open APIs between companies, often referred to as partner APIs, open new digital routes for reaching end-users and provide consumers with new offerings. Instead of enduring a painful, months-long, traditional integration project, business collaboration can be done using APIs in weeks or even days.

Typically, partner interfaces are used to integrate a variety of services provided by several companies into ready-made packages. This, in turn, makes it easier for the end-customer to do business. The result is more service sales and a better customer experience; i.e., everyone wins.

Instead of a technical integration tool, APIs have started to become products in their own right or reusable tools for producing different applications.7 Companies have therefore started to offer or sell interfaces on their own sites (so-called “developer centers”) to their target groups. For these interfaces, the first forms of platform economy, such as common marketplaces, have been developed. One good example of this is Amazon Web Services (AWS).8

What happened to mobile applications has also happened to APIs, the only difference being the target group: mobile apps are sold to end-customers, and their installation and sales take place through consumer platforms (marketplaces) such as Google Play and Apple Store. “Platform” refers to a service and business model in which producers and consumers of a service or content meet and are partially overlapping. These appearances produce the desired network effect: the more consumers there are, the more service providers want to join the platform. This creates a loop that encourages both sides to produce more and more value for each other through the platform.

The APIs, in turn, are sold to the developers of these applications. However, the logic is the same: the product is introduced via the platform as a self-service product for either a fee or free of charge. Software developers became fascinated by the range of solutions available to speed up and facilitate the development of services. This interest gave birth to the API economy, where the API was no longer a byproduct or an additional feature accompanying the physical product, service, or information system. The API has increasingly become an independent, value-added product.

We hope this book will serve as a guide for your journey towards the API economy.

Tampere, April 30, 2018

Jarkko Moilanen, Marjukka Niinioja, Marko Seppänen, Mika Honkanen

SECTION I: BEGIN WITH BUSINESS

1 WARNING: THE API ECONOMY MAY CHANGE YOUR BUSINESS MODEL

Marjukka Niinioja

This chapter explains why business models are in transition and what is causing the change. We’ll use examples to shed some light on how Application Programming Interfaces, or a lack of them, influence business models. In addition, we justify why interfaces9 should also be on the agendas of businesses’ decision-makers, not just on the IT departments’.

Think of a Book as an API and a Publisher as The Platform

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 printing10 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.11

“We Do Not Bother Business with This API Stuff”

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).12 Technology is not the same as a business model, but technology has a significant impact on the feasibility of a business model.

Figure 1 The entire “village” is needed for the API economy (all the functions necessary to buy, sell, and develop business-friendly, relevant, and safe APIs).

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.13 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.14

API or Platform Economy?

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.15 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.16 So in 2016 the platform was sold to a US company.17 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.18 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.19 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,20 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 shortsighted 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.”21

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 experience22 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.23 Banks are concerned about the distortion of competition, because fintech startups can turn to private investment companies with their product development ideas, unlike banks.

Summary

API technology affects business models.

An entire company’s participation is needed to properly manage APIs.

APIs enable interaction with platform economy operators.

One’s business model may encounter a “forced opening” of APIs at any time – see it as an opportunity.

If one’s competitor offers (or is forced to provide) APIs, having the best developer experience is a significant competitive factor.

The API economy is not just part of platform economy, but APIs can be used for increasing internal productivity or for offering different business models.

2 WHAT VALUE DOES YOUR API ADD?

Marko Seppänen

This chapter discusses what is meant by an API’s “added value” and why one should consider diverse ways to create it. In addition, consideration is given to how the API should be designed from the point of view of adding value. An API can add value to the application developers using it and to consumers of applications and devices containing APIs.

One particular company that provides contact information of businesses, individuals, decision-makers, and company risk classification information originally developed their API based on file-based integrations; the API was created mainly to meet the needs of large companies. The company received a lot of questions from the customer and partner developers when they tried to deploy solutions using the API. The deployments took several weeks on average. The company felt that using the API should be easier. Often, the API contained a lot of special vocabulary and classifications and often much unnecessary and detailed data in relation to the user’s needs. The documentation was presented in PDF files and spread across several pages.

The company launched a project to improve the developer experience of the API. But what is easier and for whom, that is the problem. In the early stages of the project, Marjukka Niinioja asked if the project team knew for whom they were planning the upgraded API, as well as what customer journey the API should support. In other words, what added value and for whom should the API produce? This was not obvious at first, but with a short workshop employing appropriate methods, it became clear that the target group might even be the smaller companies. The most interesting target segment were those e-commerce entrepreneurs who needed to check their customers’ risk classification and contact information before delivering more expensive purchases.

But do e-commerce entrepreneurs understand the API and how it can help them? And are they able to program, or do they have programmers in-house? In most cases, the answer is “no.” They typically use a ready-made e-commerce platform or buy outsourced technical maintenance. So, are they the right target segment for the API? Would a simple API bring added value, even if it enabled an easier customer journey and less financial credit loss? Marketing the API to individual online merchants would probably be time-consuming and expensive. In addition, there will always be the issue of who integrates API into the e-commerce implementation. In addition to implementing their API, the real added value would only come from either implementing productized integration plugins into various e-commerce platforms or, even better, by designing and marketing the API to meet the needs of e-commerce platform vendors.

Added Value Is Experience

What, then, is the added value? There are different definitions of added value in economics, depending on whether we look at productivity or, for example, a company’s profitability from the owner’s (or investor’s) perspective. In layman’s terms, added value means the value experienced by the customer.

What, then, is the benefit? Traditionally, we are used to thinking about the benefits very concretely: I get more stuff, service, money, or anything else I want. The added value and the basis for the selection is that I carry out an intuitive comparison between the various options and select the service that I expect to offer the biggest benefits. Luckily, many other things that are not measurable in terms of money have also recently been understood as important factors in the selection process. We likewise – or even more so – appreciate the ease, speed, and even the image that the choice brings about. Such value factors have been highlighted in recent years, and companies are striving to improve their distinction by developing apt slogans and interesting brands.

On the other hand, the value experienced by the customer is structured in time before the acquisition, at the time of the acquisition, after the purchase, and at the time of withdrawal. This is described in more detail in the accompanying figure.

Figure 2 Value experienced in the acquisition process24

What are the components of the value at the various stages? We can divide it into five sections:

1. The difference between benefits and sacrifices (the “net value”) 2. The sum of usage and experience 3. The value measured in monetary terms 4. The benchmark against others and 5. The value of discernible product properties

All these areas are always innately present, whether we are aware of them or not. From the customer’s point of view, the interpretation of the perceived value may be different from that of the supplier of the product or service: if the value perceived and offered does not adequately satisfy, the trade does not occur. On the other hand, too high a price means that the customer perceives the product’s or service’s value – as compared to other similar products or services – to be disproportionate. Simultaneously, the same product or service may be more user-friendly and perhaps requires less learning and time. In this case, the benefits are more comprehensively balanced.

Figure 3 The value a customer experiences offers many different perspectives of interpretation. These service providers should be identified and approved25

Pieces of Added Value

The benefits and sacrifices described above can be broken into even smaller parts. Benefits can be viewed as features related to the product or service (for example, quality or customization). On the other hand, the use of a product or service results in different types of benefits for the customer, such as strategic benefit (e.g., an API gives a brand an image as a pioneer) or practical benefit (e.g., an API handles the standardization problem of a specific communication need).

Sacrifices can also be divided into monetary and non-monetary sacrifices. As a financial sacrifice, everyone easily recognizes the price, but the cumbersome tasks of acquiring the API product are costly. A well-designed and documented API reduces many of these expected costs. In addition, non-monetary costs are often overestimated; for example, using one’s own time and the stress caused by difficulties in usage. These are all their own kinds of sacrifices that should not be overlooked. Often, only immediate and monetary costs will be considered, while many more depicted in the figure will be overshadowed. Making these factors visible can be crucial to securing a deal.

Figure 4 Value consists of balance of benefits and sacrifices (modified from Woodall, 2003) 26