API Economy 101

Changes Your Business

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

• Publisher: Books on Demand
• Year: 2019
• Print ISBN: 9789528008491
• eBook ISBN: 9789528076407
• Edition: 1
• Topic: Politics & International Relations
• Subtopic: Politics
• Index: Politics & International Relations

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.

SECTION III: THE LEAN LEAP TO APIS

11 APIS CHANGE YOUR ORGANIZATION

Marjukka Niinioja

This chapter discusses the impact of APIs on an organization’s internal operations, offering new paths, a reconfigured division of labor, novel strategies, and optimized interactions. In short, the API economy is changing the way one procures, sells, and offers services, thus lending change to the nature of management and the types of people and skills needed.

Ecosystems have a significant impact on software development. This is especially the case if the development approach is changed from integration- or product-centric to service-oriented. APIs and API management are often perceived as either integration or a byproduct of the development of digital services and microservices. Integration experts working alongside traditional systems and integration platforms are under pressure to understand the API world. Software developers working on the edge of the microcomputer at the edge of the cloud do not understand how to work with the internal network and ERPs.

One challenge in the API economy includes the fact that management, sales and marketing, personnel development, and other support functions must understand what one needs in order to communicate, market, and sell to customers, as well as what kind of expertise one should recruit. Process, service, and project managers and architects, on the other hand, are struggling with whether to do things in an agile or traditional way, should they get on board with the much-hyped new methods of work.

It is essential to understand that in the API world, the services and their users are the talk of the town, whether internal or external, paying or not. API is the interface that provides resources to different parties as services. May the users do what best fits their needs–types of integrations are about “agreements,” which must be mutual and cover the following:

1. What does each party provide and in what format? (For example, a file with customer information or a more traditional web service, REST API, or other data source that can be used to query customer information.)
2. What will be done with the incoming information? (Will it be moved to the edge of a hard disk, will it be converted to another format, or will it be mapped to the interface of another system? Which field matches which, and how often should the data be transferred?)

Thus, there are always two parties in the integration, and the object is the data that is transferred to and converted for the parties.

The API, on the other hand, is like an electric socket: it transfers a specific amount of data or functions. However, the API wants to know what that data really is and to provide certain possibilities for processing said data. In addition, the data is merely a way for the API to communicate with the resources that use it, which can be very varied and multifaceted, as described in the previous chapters.

The API itself is not integration; it lacks the second party of the agreement (though the number of parties can be unlimited). However, the API does not know anything about the parties other than being registered as API consumers. APIs from different parties are unable to communicate directly with each other; for example, the software developer can call the API from the mobile application’s code. There may be a need for an integration tool (and possibly an expert) to make the APIs talk to each other.

During one API training, the integration expert summed up what he has learned as follows: “APIs have users just like user interfaces. And just as usability studies are performed for users of user interfaces, so must it be done for API users (consumers). That is the big difference between an API and an integration!”

Integration orientation may have some significant side-effects compared to service-centricity. Researchers Bosch and Bosch-Sijtsema (2010) emphasize in their reference framework the consideration of the interaction between architecture, processes, and organization.¹¹⁵ According to their research, the development of unified software products has spread across a wide range of areas, causing cultural, linguistic, and competence challenges. These will cause problems when scaling up local enterprise software development and interaction techniques for use by teams around the world.

In the current wave, software ecosystems are being provided alongside internal development teams and their software platforms, for which external developer teams are developing their own services. As stated in previous chapters and in the Bosch & Bosch-Sijtsema study, one can hear the emphatic voices of these external developers when discussing development plans, schedules, and other matters related to the whole platform and its services.

The globalization of operations, the growth of networked working methods, the development of technology, and the acceleration of development are also key factors in the development of digitalization. The power of the API to change the nature of an organization is thus two-sided: organization’s internal API development causes change from within while, on the other hand, the opportunity offered by APIs to integrate external parties to company’s innovation and service processes is increasing. Such change enables and forces organizations to open up and think about means and conditions for interacting with external developers, ecosystems, and interfaces with providers of their services.

APIs Do More Than Just Change IT

APIs do not just change information management or software development and product development; they also change how an organization acquires and oversees its services and how its budgeting, management, and outsourcing of services and resources operate.

Studies have investigated what happens in an organization when it starts to develop APIs and employ interfaces. The change and its magnitude depend in part on intent. Indeed, Lewis and Lewis have been examining the changes to open innovation – caused by public APIs and partner APIs – currently underway in the media sector.¹¹⁶ For example, an external developer had built a free iPhone application using National Public Radio’s (NPR) API, which quickly became popular. The developers of NPR heard about the application and hastened to make their own. This is just one possibility, however. NPR also could have built a revenue-sharing model for the content and allowed third parties to manage and own the applications, if such monetization had been possible (based on its financial and ownership structures).

Therefore, an organization no longer needs to invent and experiment with all the ideas itself but can learn from outside developers. Aitamurto and Lewis also emphasize APIs’ impact on accelerating internal product development, such as that of UK newspaper the Guardian. According to their research, APIs provide more structured tools for product development and more time for teams to focus on user experience. The study also revealed that APIs accelerate collaboration across organizational units.

In the organizations investigated by Aitamurto and Lewis, commercialization was done using APIs, especially in the Guardian’s case. There, the vision of the entire organization was built heavily on the idea that it is not enough for a company to be on the internet; it must be part of the internet. The company shared its content with an API, and developers were able to use it on their own sites. The shared content included the Guardian ads, and developers could also use it to share their own ads. The overall strategy was to transform the website into a news platform.

The above benefits and results from accelerating and commercializing product development do not arise without the participation of API consumers and community. In the study by Aitamurto and Lewis, it was found that APIs, especially when provided as self-service, more easily and quickly help establish a larger network and community. Indeed, the community has created partnerships and business opportunities for news organizations. Some organizations have begun to actively feed their community by organizing various events (e.g., hackathons) where developers and news providers meet and collaborate. Based on these encounters, an organization is also able to gain a better understanding of its own needs for expertise in producing new innovations.

However, the change from closed innovation to open is not straightforward. Conservative organizational culture in particular slows API utilization. There persists an assumption that one can do without any APIs when they have not been needed previously. In the study by Aitamurto and Lewis, other challenges raised were copyright of information and the mindset that content published through public API is always free, transferring the value creation outside the organization.

The developers highlighted favorable solutions in their research to convince management: they sold the “limited openness” perspective and the “Business 2.0” concept. Thus, it would be better to control what someone can already automatically “scrape” from the content of the web pages. Further, such a situation presents the opportunity to get to know who the users are, to identify the possibility to receive advertising revenue, and to form partnerships.

Introducing Your Organizational Change

An API expert is called to the scene when technical solutions and instructions are needed or at least assumed to be needed. Most API-planning organizations also require another element, as was seen from the previous Aitamurto and Lewis research: they need a partnership strategy that governs the transparency of networks and platforms rather than (or supplementary to) the API strategy. An alternative is to develop a business strategy that considers the digitalization and competitive situation that identifies one’s own or the partners’ APIs as one of the services and competition or production factors offered.

APIs can change an organization’s strategy, but then many other changes will often be needed in the organization’s culture, interaction, skills, and responsibilities. This sounds like years of change – a demanding management-involved and system-wide challenge, right? The truth, however, is that on the day the organization starts to set up the first APIs, organizational change is inevitable.

Let’s first look at how an API-free organization works. It may not be a worse example but clearly different. For example, with a startup consisting of one team with a few coders who develop their first product, the pace is fast, and the team is given ideas daily about new features customers have requested, ones competitors have invented, or what the organization itself has needed for similar products. Not much architecture exists or needs to be thought of when surfing the next wave of hype if something that works is delivered. Generally, then, outputs are obtained where all the code is the same: the user interface, action logic, and database code are entangled. Nothing can be done before the user interface is designed or the database exists.

It takes a long time to implement the changes, because they are done sequentially. The duration, risks, and impact of the changes are only seen at the end, when the previous layers are first implemented, and half of the project time and resources have already been used. This causes organizational “silos” to form, because experts from different disciplines (such as business application specialists, data scientists, API developers, and network specialists) don’t understand each other, even though they are all wor...

Table of contents

• Table of Contents
• Preface to the English Edition
• Preface
• Section I: Begin With Business
• Section II: Apis – The Limited Edition
• Section III: The Lean Leap to Apis
• Section IV: Managing Apis
• Epilogue
• Glossary
• References
• Copyright