The API that stands for Application Programming Interface is one more of these abbreviations where the original expanded form is rarely used. Rightly so, since it suggests something technical, a piece of code that really cannot capture anyone’s imagination.
The reality is quite different. APIs have changed in recent years, and will continue to trigger major changes in the way businesses are run. Large and small, practically in every single industry. Another much used term, the digital economy, really refers to the changed economical model that emerges as a consequence of APIs being introduced into the mainstream. Unseen but felt every day, from the simplest of interactions such as online shopping, booking a hotel and airline tickets, googling for information or even hailing an Uber cab.
We all know the success stories. The e-commerce giants that have rewritten the rule books on how goods and services are distributed and consumed. The competition that stealthily emerged from completely unforeseen quarters, even other industries that toppled the established leaders in a few painful years. Blockbuster and Polaroid are some who never saw the digital threat coming. The Googles and the Facebooks of the world built incredibly large communities of fans and amassed fortunes by exposing what others created.
The age of the Platform has arrived. Businesses have to see themselves as platforms on which others can build. A web of interrelated services is woven. This is the crux of a digital strategy. The changes to processes of commerce as a result of technology, particularly Internet related, has been compared in terms of magnitude to the Industrial Revolution of the 1800’s. This book attempts to help you enter this world of opportunity. And if you are already on it, provide some checkpoints to keep you aligned. It’s a book that helps people understand what APIs really are, what they are expected to do and most importantly help determine the success parameters that could be expected from their use.
It speaks to technical agents of change, and to business agents of change. People who see the need to recast some or part of the way their organization interacts with its employees, customers or providers. It’s important that both technical and business agents are spoken to in the same language for the successful use of APIs. Required above all, is a close, intimate collaboration between both sides of the divide.
Building APIs is not easy. Choosing what APIs are to be built is perhaps the hardest part and one that is often overlooked in the rush for technical change. This book is written to save months, years of valuable effort in designing, publishing and putting out APIs that are hardly used and fall far short of the miracle that they are expected to perform in taking a company to the digital age.
APIs, like all technical assets are only as good as the benefit that is produced by their use. Who adopts them, when and why, will determine their success. Simply creating an API, even if it is perfectly constructed in accordance with best practices and a whole lot of governance, can result in what is called a web service. A piece of code that is exposed by the web, without prior purpose of use being established. This for practical purposes may be seen as the difference between a bunch of web services and a carefully constructed set of APIs that propel a company along new , exciting and usually highly beneficial customer journeys.
Finally it includes a set of tools that allow you to practice in your own sandboxes, in your back yard. Build castles in the sand or in the air. Models and pilots of what could be. Have fun. You are only bounded by your imagination and spirit, there are no other limitations in cyberspace and the Digital Economy.
Chapter 01 - Introduction
1.1 Who is this book for?
There is virtually no industry, no business - small or big, anywhere in the world that is immune or isolated from the threat and opportunity of the digital invasion, of which the API is the first touch point. We want to give you a road map, to meaningfully seize the opportunity that APIs offer you in your own context - whether you are a business professional running a multinational, a technology professional who is increasingly battling the demands of a wide range of known and unknown users, or somebody out there with a small business, a consumer or a provider of the simplest service. API’s are really for everybody; like Facebook, Google & Twitter. Except, they can even be consumed by Things in the Internet of Things (IOT), but more about that later.
APIs are here to stay. They are one of those rare items from the world of technology that serves all kinds of business. The term ubiquitous and diversity of user, usually exaggerations, are in this case, profound understatements. APIs are provided by and used, right across the world. Wherever the Internet reaches or even a local area network - which is just about anywhere !! This book is written by people who for a couple of decades, have been involved in the core elements, from which APIs emerged. It is based on actual experiences. Experiences of success and failure, of frustration and learning. By people who have worked with teams across the world as service providers integrating assets and exposing them to customer journeys that rapidly change. It addresses the difficulty of bridging technical and business constraints. Never before has the need for these two to work together been more marked and essential to the continuity of the enterprise. The Great Divide between Business and Technology must be crossed in a common raft.
The technology today is too important because it goes beyond being just another technical invention, it simply changes the way business is done. It’s like cell phones, you don’t need to know exactly how it works but you do need to know how to use it, and get your contacts using it too. Unlike other technology initiatives, here the technical professionals who create and manage the IT infrastructure to enter the new world, must understand the business drivers that compel this transition.
In short, this book is written to help foster a common shared sense of understanding and purpose between the following team members who will need to actively collaborate to pull the digital strategy together.
1.2 Why it was written
As alluded to earlier, digital disruption has been compared to the Industrial Revolution, on steroids. Manufacturing processes at the time underwent a core change and today we are seeing a change in the way goods and services are delivered to the market. While there will be changes in the way goods are manufactured, the biggest change is where, how and when goods and services are put together in response to a customer need, or in anticipation through cognitive data analysis.
Moore’s Law, working in the Cloud evens the playing field rapidly. Today computational resources are available to virtually anyone, anywhere. The smart phone shortens the last mile, all over the world; consumers are now accessible 24 x7 responding to the same application, regardless of geography. Quite simply, the rules have changed. Possession is replaced by access, and access is often free. Use, and use alone, commands payment. The opportunity and threat provided by this course of events that marches on, cannot but profoundly influence everything around us. Regimes have toppled, with tremors initiated by Tweets.
As in the Industrial revolution, we are in the early stages where those who own the assets that carry the passengers of the digital revolution at present have reaped the greatest benefits. The Googles, the Facebooks; the Ubers of the world, the Amazons and the Alibaba’s are all agents of connection of information that is not theirs. They provide the means to connect A with B, and have reaped much fortune in so doing. This formula is now passé.
Creating new highways that link consumer and provider with slightly different features will no longer create the immense wealth generated for the early builders who opened up new channels. The agents who provided the new bridge between user and provider reaped well-earned valuations but the question of sustainability now haunts them. Facebook, Google and Amazon face this challenge, they know it; and they are investing heavily to take them forward to a second act that is more enduring. They are using their digital power, backed with very real cash reserves, and industry savvy human capital to invade brick and mortar fortresses.
The next phase that drives value, logically, is the quality of what would be inevitably and freely connected. Influencing what is served up. Going down the line. Full circle, the native digital players, who toppled traditional brick and mortar with bits and bytes, are getting on the assembly line to build real tangible assets.
Traditional businesses that feel rightfully threatened by digital upstarts must recognize that they do have enviable assets. These might include extensive data about customer behavior, formal and informal partner relationships, supply chain and marketing networks. The first step is to connect, or better said, provide a means for automated connection with what you offer, accessible at will – by man or machine. Enter the concept of the “Application Programming Interface”, the API, which is simply a published key to what you or those within your ecosystem own, that is now made available 24 x7 subject to certain rules. This model of exposure has spawned the API Economy.
Digital disruption becomes a threat only when it’s not recognized. You too can use the new highways of commerce, to protect, enhance and better convey what you own. Brand names in industries can and should be leveraged, before they become the Kodak’s of yesterday. The private experience that is now offered to customers can be best enriched through harnessing the networking power and reach of a public medium. Thankfully it’s still about assembling a better mousetrap, and owning it, providing a very real and tangible experience, but working in a new digital marketplace. The book aims to help you connect the dots.
1.3 What this book does not cover
This book does not cover the detailed technical aspects of APIs, either regarding API development, API Exposure and management. This book does not describe products in the market nor provide comparative evaluations. It will however allow you to set in parameters that could help you choose meaningfully. The concept of beneficiaries, enablers and catalyst is introduced precisely with that objective.
1.4 How this book is organized
Each chapter has a narrative of a case study, highlighted separately as shown below, a fictitious company that you could identify with, which decides to take the journey to the API economy. While the characters are fictitious, the experiences and sentiments are not. They are all too real and painfully reminiscent of actual experience. The narrative is used to support the key concepts and highlight the pain areas in the real world. It is also used as a means to contextualize the recommended approaches within your organization. It is a bridge between theory and practice.
1.5 Case study
A Mobile Operator offering Voice Services, Mobile Internet – 2G, 3G and 4G, DSL Broadband, Landlines, Mobile Broadband – Dongles & Digital Television
Profile of the mobile operator:
The mobile operator has been successfully providing the services for more than 12 years. The quality of network has been great, which resulted in a lot of satisfied and loyal customers. The company has been quite profitable over the years. The operator has established several high-street stores in strategic locations to offer the best sales and support to customers. The operator also has setup pop-up stores in Malls and commercial establishments to increase the customer touch points. The strong distribution network enabled customers to top-up their mobile accounts in grocery stores, super markets and airports. In addition to these channels, the operator offered self-service capability within its online web portal and Smart Phone Apps.
In the last one and a half years, investors have observed declining profit margins over the quarters. Being a popular brand in the region with a loyal customer base, the investors were surprised. Considering the proliferation of Digital devices – i.e smartphones, tablets and other Internet-enabled devices, Investors expected better profit margins as they envisaged increased use of Internet data plans. The investors called for a board meeting and asked the management team to investigate the situation. The management team comprised of C-level executives – CEO, CIO, CFO and COO. The team had a very deep understanding of the core Telecom business, which reflected in the past successes. But, the management team acknowledged, it did not respond fast enough to the disruptive forces of the digital world. These forces are proliferation of Internet enabled devices like Smart Phones, Tablets, Netbooks, Smart Watches, which became a channel of revenue for new generation entrepreneurs. The barriers of entry for these startups disappeared. By leveraging Cloud Services and adopting the increasing trend of crowd funding, it was possible for startups to launch breakthrough digital services within a few months. Smart phone manufacturers rapidly built a strong developer community and nurtured an ecosystem. In many cases, these innovative startup companies built profitable digital businesses whose valuations could surpass even the giants. These businesses re-wrote the rules of traditional marketing by engaging directly with customers on Social Media. With the increased uptake of 4G and Mobile Internet, the Telco had predicted the threat of Over the Top players. Unfortunately, nothing could be done to stop these services, as they gained huge popularity among customers. Almost every innovative digital business in the Smart Phone Apps space was an OTT player. The wave of digital disruption was evident. The Telco had to undergo a transformation as they could sense the threat from completely un-expected players.
1.6 A little about the title
APIs, Application Programming Interfaces may be best understood by parsing each of the words in what has become an abbreviation that separated itself from its components. First it is about “Application”. The verb, as opposed to the noun form. It is about doing. There must be meaningful execution to make available, presumably to a wider audience. Execution, which serves a single finite process and definite purpose each time it is used. This purpose is “programmed” to be realized. Meaning that it is crafted to perform in a predictable repeatable manner. And finally the “interface” is created, the doorknob that turns the handle and tells the world outside what is in there, and how it is to be accessed.
When these three elements are put together, a powerful and scalable means of access to an underlying technical asset is created. These assets could be data, application code that performs a finite isolated function or trigger a pre-determined sequence of activities. What the API does is described, published in the documentation that accompanies it, and is usually self descriptive in the name of the API. Good APIs do one thing and do it right, and there is little or no room for confusion. Similarly, the API describes its conditions of use, in such a manner that there is little doubt of what needs to be done by whoever wishes to use it.
All of these characteristics serve to make the consumption of APIs highly automated. We see the APIs of Internet giants such as Facebook, Twitter and Google where there is no human intervention required by the API provider. An API’s use is enhanced as a developer registers with the provider’s developer portal through self-service. He/she requests access tokens and keys, studies the API documentation, and without any intervention by the provider, the developer invokes the APIs and quickly builds a product, service or a mobile App. It is not only automated, it is available to anyone, anywhere who satisfies the published criteria for access - without the need to obtain specific permission on a case to case basis. The human overhead and possibility of error is eliminated . Interestingly, it helps to address the reality that determine which particular API is to be evoked are determined by the result of a technical process and not a human one. Often a data driven process through a rules engine, where data sets from diverse sources are compared. This means APIs are a perfect means of being used by machines, things, besides people, provided the conditions that determine the use of a particular API are satisfied by the calling agent. Such liberty provides freedom to leverage the asset, in contexts that were hitherto not envisaged.
The use of APIs involves a variety of stakeholders. Remember APIs, the Application Programming Interface are simply means of access, like door knobs or better described as push button security door locks, that open access to what lies behind. Through use, the term is often used to include the underlying function that is accessed. Therefore the API is often the whole piece of functionality that serves a finite purpose faithfully. In this context, it is helpful to think about the players that are involved in the build and use of APIs in three categories. Those for whom the API is designed to serve, those who build them and those who help the builders and designers.
Beneficiaries are those who will actually receive the benefit of an artifact that wraps up these three elements – the underlying asset, the interface that is published, the context and scope that determines how and where it is used.Their role is to guide, support and fund emotionally and financially, those who make these changes happen, so they can carve a benefit for the organizations they serve.The beneficiaries are those that are ultimately accountable to deliver specific Return of Investment, ROI. In the classic RACI matrix, the Beneficiaries are Accountable, the Enablers are Catalysts are Responsible , Stakeholders are consulted and the rest of the business right across the board must be informed of the transformation. This activity of information dissemination is in itself a significant process that must be formally undertaken with people skilled in the process with all the necessary collaborative tools to encourage feedback and consequent iterative development.
The Enablers: These are the Doers, who create, who make the changes in what is here and now, for present and future, yet unseen beneficiaries. Why Enablers ? What is to be enabled and Why? Enablement deals with the changes to the back end systems that were created by design to function in a prior era where their use was determined by access control, on an individual and predictable basis. In the old world before a system resource was exposed through a Remote Procedure Call (RPC) or equivalent process, the load and use case was well understood and subjected to a test plan. The constraints of the environment and the back end systems regulated business need and imagination. Each new customer journey envisioned by the business would be examined to see if it “fits” with the existing environment and its embedded constraints. Today , we are by intent and design, exposing our assets for one and all to consume – the API economy is a synonym for the Open economy and only by so doing can leverage at will be facilitated. Therefore the back end systems that are incapable or otherwise designed to not work with free access, provide such access is through published standards, have to be now reworked or “enabled” proactively. This is the role of Enablers.
The Catalysts are that important group of unsung and often-invisible heroes, who set the stage, provide the backdrop and conditions for the elements of change and creation to spark meaningfully. A key distinction between Enablers and Catalysts is that Enablers primarily act to make changes in the assets they own and control, i.e. in themselves; while Catalysts primarily act to facilitate enablement of these changes. They do not change themselves.
Remember – all of the above set of actions, by Enablers and Catalysts, must be oriented to satisfy a set of targeted beneficiaries – who get something tangible that can be felt, seen and in someway measured. This logically , and not necessarily geographically , related set of people and assets are the Community. Identification of the Beneficiary and then the Community, is therefore the first step from which everything starts… everything must revolve around a visible, realizable benefit that is understood , articulated and committed upon. The KPIs for enablers and catalysts address the realization of this benefit and must be linked towards commercial success that the initiative assumes. As Clifford Stoll said, data is not information, information is not knowledge and knowledge is not wisdom. These are often islands, populated by something vaguely in common. Disconnected. These islands could be bridged. A bridge that could make it easier to go progressively upstream in the journey to apply what is out there, in such abundance, to everybody with access to an Internet connection.
These bridges are the APIs. They exist for people to cross from data pools to summoning meaningful actions that actually provide access to a journey that was not thought of before. A journey by the artificial intelligence of a ‘Thing’ as in the Internet of Things, or people who are automatically led to resources that they never knew existed.In order to be meaningful, and travel together towards a destination that allows fulfilment of objectives, it stands to reason that travellers need to be grouped by logical needs. Hence communities are formed, as in ancient times, they are simply those who have a common social fabric and could benefit from shared tools and process to realize them. Man is a social animal and the Internet simply expands social reach, it does not substitute it. The application or the interface by itself cannot serve; it is the craft of using it that serves a purpose. And considerable thought is to be given to the definition of such purpose.
API’s are an essential element of the new digital economy which is based on an unprecedented level of exposure of assets that forges partnerships at will , between consumer and provider, between different providers to recast and enrich the offering. 1+1 > 3 let alone 2. And open to an infinite number of consumers. All of this requires a couple of other dimensions to be addressed. The technical invocation of the artifact exposed by the API, which is after all only an “interface” is dependent on the architecture which facilitates or hampers the invocation of the asset . This is best done thru an architectural model which is designed for such combination of services as and when needed, which is precisely what Service Oriented Architecture , SOA, is meant to achieve. Remember SOA is designed to render the orchestration of services through the web to perform as needed by the consumer putting together what services he exactly wants at that moment, to work seamlessly and render a predictable result. SOA is therefore an integral part of the infrastructure to optimize the use of APIs.
There are several publications on SOA, and the purpose of this one is to address the use of APIs. It is worth noting that APIs are really about integration, putting together at the moment of truth different technical assets to render a new customer journey, something that was not available prior or at least at will. This integration has to be anticipated and prepared for, or simply connecting the assets may result in a less than perfect experience. This process of preparing the underlying assets to perform in a highly integrated mode, may require modification of the assets themselves, and this pre requisite of integration is referred to as “Enablement”.
To summarize, APIs do not work alone. To be efficient, they are part of an integrated whole, usually in a SOA model. Work may have to be done on the legacy elements that are exposed, often with data integration or transformation to perform predictably.
Chapter 02 - The why and what of APIs
2.1 Characteristics of a “digital enterprise?”
Before we talk about a digital future, what does a digital state really mean? What does “going digital” mean? Why is this term gaining so much traction today when it’s been around for a few centuries? While we all have visions and possibly expectations of what is meant by the use of the term “digital”, let’s try to establish a fairly simple understanding that we can relate to - of what digital is. A digital state could be seen from two perspectives. One is what lies within and the second is the way in which what lies inside can be put together to serve the needs of the user.
Let’s look at it, like a house with different rooms - a bedroom, a dining room, a living room and a kitchen. While each has a self-contained ability and serves a single purpose, the whole together creates a different picture - A home. A structure that is not just greater than the parts, but actually serves a different need, binds families and allows guests to be received and entertained. The elements that make up the house, i.e. the different rooms could be seen as the components that are exposed and accessed by the hallways and corridors that lead to them, and in order to perform a specific task or a logically connected series of tasks, one should be able to traverse at ease between them. We know how much of a hassle it is if the garage is outside the house or the closet with clothes that we need every day is down in the basement. This “connectedness”, where whatever is needed is visible, well labeled in terms of what it contains and accessible, could be seen as the other requirement of a digital state.
The ability to access and use the different resources of an enterprise, at will, is what defines a digital enterprise. To move between these resources, effortlessly and intuitively, stitch together parts that are separate. For the purpose of business, a digital state is simply an environment in which a technical asset is evoked with little or no human interaction. When we speak of technical assets, in this context, we are generally referring to applications or data that facilitate an automated customer journey.
Automation has been around for ages in various forms, and vaguely brings to mind the unpleased association of a mechanical voice telling us to push different numbers on our phones. “If you need to make a new reservation press 1, if you need to change an existing reservation, press 2” and so on. Finally you go through the loops until you ask for an operator, a real live human being to get you what you need. Here we are talking about automation as in the customer journey being managed by data, and purely data driven. Either data results from a set of conditions that were satisfied in a decision tree, or a sequence of activities that are started to fulfil a logical course of action through using resources owned and managed by unrelated entities.
An example of a data driven decision tree could be something as simple as a set of options being presented to you on Amazon based on your past browsing or buying history. The buying options could again be customised through a greater understanding of your financial profile, employment history. This is also called Personalization in current tech speak. The key distinction is that what is offered does not have to be “owned” in the classical sense. The implications are profound. What this means is that we can trigger a course of events using resources, that are made available 24x7, anywhere in the world, owned by whoever chooses to provide access, at will. Best of all, these resources can be accessed by machines, or by people. Anytime, anywhere and perform consistently towards a predictable result. Essentially we are opening up a channel to provide and consume services, or products that can be paid for and used on an ‘as needed basis’. Moreover we are allowing combinations of goods and services to be strung together, irrespective of who owns them or where they are located.
All of this has been accelerated and multiplied by the spread of the Internet, speed of access and the ubiquity of smart phones.
This is referred to as the digital economy.
Now to play in the digital economy, it stands to reason that each service or product that is offered needs to be wrapped up in a box that can be opened and consumed by a given set of instructions, permissions and compliance measures.This sets the ground for defining the purpose for which API’s are built and used. It is important to identify or at least broadly visualize the eventual use, the automation that when provided will allow an enriched customer journey.
2.2 Creating a business case for an API initiative
The transition from a general awareness of the need to “go digital” to actually demonstrating a working model is difficult. This is usually the point where initiatives fizzle and eventually die as no one can effectively convince those that hold the purse strings to actually put the money out. The greater problem is actually obtaining funding based on a plan that does not have tangible and accountable deliverables. This is often achieved because of high level sponsors who support the initiative because it is widely accepted as the “in” thing or a fear of being left behind in the race to market. The reason why such funding is actually dangerous is because it fosters the implementation of unaccountable digital transformation and integration. Without pre-determined purpose or owners who are accountable to deliver on the investment in financial terms or at least in improved customer options that are acknowledged and valued.
Ideally what we want is a derived business case, meaning the realization of revenue that is derived or realized from a preconceived plan that visualizes the steps and details the actual path– as a result and consequence of what is now being offered. As opposed to what was prior available.This brings us back to the title of the book – the concepts of “beneficiaries” and the specific benefit they bring themselves to commit to, once the envisioned changes in the technical assets are delivered upon. A business case begins with the intended benefit put up-front. Everything we outline is driven with that benefit as the focal point. This anchor is critical to avoid drifting into software that is nicely written, full of visuals that finally lead to someone asking – Now what “exactly” did this do for us ?
While this may seem obvious in terms of the classic cycle of Requirements Gathering to Design to Implementation and Test, in the case of digital transformation it takes a little twist. And here is the twist where we often loose sight of focus; the new path, the new customer journey that we carve involves touch points that are often not structured for use in the new world, where the rules are different. We therefore move to the “Enable” part of the process. Enablement simply means the changes that are required to pit stops or touch points where the customer is now taken and some of these touch points may well lie outside network boundaries.
Let us look at the continuation of our case study that illustrates this point:
The CEO organized a brainstorming session with heads of all departments. This included the Business Strategy Team, Products Innovation team, IT Leadership Team, Operations Team, Sales Team, Retail Team, Marketing and the Networks Team. The CEO articulated the nature of disruption and highlighted the importance of re-inventing the Telco to retain competitiveness. The CEO expressed concerns on the ability of the IT team to deal with such wide-reaching change. The IT environment grew in complexity over the years. The CEO was not happy with the speed of changes that IT delivered in the past. Due to these complexities, there were several instances of delayed product launches in the past. The CEO formed a digital leadership team (DLT) that was responsible for the transformation. The leadership comprised of the CIO, Business Strategy head, Products Innovation and Chief IT Architect. The CEO invited ideas from the leadership team to transform the Telco to align better to the digital disruption.
The Digital Leadership Team were convinced that SOA (Service Oriented Architecture) and APIs were the means to achieve the goals of digital transformation. By re-organizing the IT estate so that business capabilities are offered as Services that can be consumed internally or externally using APIs. The Digital Leadership team had a conceptual understanding, but lacked the knowledge of all its moving parts. The leadership team expressed their lack of confidence in leading and executing the digital transformation due to gaps in expertise and skills in defining and executing the digital strategy. As an organization, they felt they were not ready to strategize, plan and execute the transformation.
1. How will we, as a business, justify the investment for re-organizing the IT estate as APIs?
2. How will we prioritize the business domains to address first?
3. How do we demonstrate quick wins?
2.3 The CIO’s classic dilemma – Where to start ?
The CIO’s classic dilemma – who drives the bus? Where do I begin and what are my boundaries? These questions invariably come up in the most structured of organizations with well-written job profiles and published reporting responsibilities. We need to go down deeper to answer these questions – to the heart of the enterprise, what it seeks to be and the playground it operates in. The challenge is that the environment has changed so fundamentally and is changing by the day from the time the org chart was prepared, and people were brought in to fill the tidy boxes and roles.
The term environment refers to the opportunity, the threat, the consumers - all of whom are now exposed to stakeholders, resources from “outside”; i.e. from outside what was reasonably expected prior to the changes triggered by the digital revolution. What does this mean? It might be easier to understand by looking at the rear-view mirror. Blockbuster was taken out of business not by a better run video store chain but by a different delivery model. Netflix the challenger who toppled Blockbuster, is now reporting flat earnings and is under threat from a broader supply of options to the consumer’s desire, to satisfy the need they replaced through a different medium of access (the download and streaming as opposed to the physical act of going to the store to rent a movie). Now the options go beyond the download convenience that was the value offering that killed Blockbuster, to actually being able to partner and provide non-proprietary assets at will. Meaning, a consumer now sees his provider simply as a channel to whatever he wants. And is totally oblivious to who is the original supplier, or from where. All he wants is getting a constantly enriched set of options, here and now. With one payment gateway that is automated, safe and transparent.
Enter the CIO. The CIO now is looked at by stakeholders who run the business today, as the person who is going to put them on the digital highway that will enable them to compete more effectively.
This opens up a fundamental question that is to be first addressed head on, debated, and resolution arrived at. Is this a technical initiative or a business initiative?
While we talk about business and technology working together, we have seen that well meaning as this may be, in reality boundaries are blurry and roles are hard to define. This book attempts to clear the air here.
An analogy may be helpful. The digital road may be seen as a new railroad track to transport customers, goods and services.Like all railroad tracks, there are a series of stations where stops are made, people or goods get on or off. The actual location of these stations and the direction the track leads to, is determined by a set of people who are expected to visualize the direction to be taken and the way points. The tracks are then laid, built and engineered to accommodate the payload that is to be transported.There is one team that will build and design the track. They can only do this meaningfully after another team decides where the track must lead to , who it must carry, the load that is envisioned and the stops on the way where it makes sense to load and unload passengers.The two teams need to work closely together, in an iterative fashion, often as there could be mountains or molehills on the way and detours may have to be meaningfully crafted. Once the track is built and laid, the team that requisitioned the track is responsible to deliver the pay loads. The final destination is a shifting target, and constantly moves in an interconnected network. The direction the track is to take, the waypoints must be defined by the Business. The people who are eventually responsible for bringing the options to their customer that keeps the company at the top of his mind.
The white board now contains two entities.
1. The CIO (and his team) who describe the options and directions the digital highway could take.
2. The Business stakeholders who define the stops and choose the direction that is most relevant at the time, with a shared understanding that this will and must change and evolve
The business is simply that group of people who are responsible for taking the change to the user / consumer of what they provide. People who deliver the “business benefit”.
In this context it might be interesting and relevant to observe the definition of business as in the Merriam Webster dictionary
Full Definition of BUSINESS
Full Definition of BUSINESS
1:archaic: purposeful activity: busyness
2a: role, function <how the human mind went about its business of learning — H. A. Overstreet>
b: an immediate task or objective: mission <what is your business here>
c: a particular field of endeavor <the best in the business>
It is worth going back to basics to avoid getting lost in the myriad options that the digital world could offer.All investment in creating a digital path must evolve from an established purpose.
The first definition “purposeful activity” is what we will focus upon. The purpose of the activity must logically be agreed upon and precede engaging in the activity.
What we want to do is to avoid creating a solution that is looking for a problem. This is where the CIO can begin. Asking the people who currently see how their consumers, of whatever they provide – information, products or services presently access, consume and put together what they get and after internal brainstorming within their community of users, tell the CIO of possible scenarios that might be more attractive.This guidance must come from the “business provider”. The CIO can take this and lay the rails, the path towards realizing what is first a fuzzy objective that must be drilled down into a tangible though often incomplete and even unproductive “offering”. This offering can be evolved, during and after it is launched but definition it must have. An owner to take it to a determined market (the beneficiary), it must have.This sets the stage for what we will refer to as Business Driven Integration. The term integration is used because it refers to the connected pieces that together, irrespective of who owns them or where they reside or the shape and form they exist in, can be woven together to provide the new offering.
Let's visualize the Google Driverless Car.How does it work? We are seeing a self-contained version of an integrated box. Data, from whatever sources could impact the journey, are accessed. Much like the human, who has a destination in mind he wants to “drive” to and the ability to use the tools he has under the hood, it puts together the external influences (what he sees on the road in real time together with his “driving experience”) to take decisions how the pieces under the hood connect together – either turn the wheels, stop at a red light, maintain a safe distance from other stationary or moving objects.A framework is created, to integrate all necessary information, even “learn” from it, that can be used in the rendition of a “purposeful activity” which in this case is taking the car from a pre-determined Point A to Point B.
The API Initiative is to be considered a framework of IT + Business teams working together closely. In any such collaboration, there are bound to be pulls and pushes based on a different sense of priorities.
Every key decision may be put under the microscope with an acknowledgement of the following tenets:
The enhanced Integration Framework Team, which consists of Business + IT, will own the end-to-end experience.
A special note about data; this is where key changes may have to be made early. The integrated activity, the ability of the vehicle that processes the information is only as good as the data that flows in. Multiple data streams and formats that worked in individual contexts may now have to be recast into a common layer with industry-defined parameters of access.
Lets take a real life example.Any activity that is triggered depends on the quality, accessibility and consumable form of the data that is received. In the driving example, if a human being cannot “see” an obstacle or a red light, undesirable consequences follow.We take it for granted, that the eye is not color blind, that “red” will be recognized and translated to the foot to press the break pedal while seeing the traffic in front and behind. All data points that are identified as necessary for the required action to be performed with the required “purpose”.In our case, as we are creating a framework that mimics the human mind, or where possible improves upon the predictability of the result being what we seek, we can and must identify all relevant data sources, connect them in what is an acceptable time frame, and when needed introduce means of modifying the very sources that provide information. This may be called “enablement” while the other part of putting together the data sources may be called “Connecting”.
What is “enablement”?
An example may help. Lets continue with the analogy of the driverless car.It is possible the red light that is recognizable to the human eye as the signal to trigger a course of actions designed to stop the car, may need to be modified to present a different form of signal – maybe a beam of digital data bits and not just light beams that can be better received and processed by the intended receiver (the driver of the driverless car) who can now receive, translate this into choosing the necessary steps without “visual “ contact. Thereby becoming even more efficient than the human being who needed to “see “ and process the beam of light on his retina and then route it through his brain to the required action to press the break pedal. An intoxicated or otherwise brain, a faulty eye, any of these could impact the action, whereas the data point now engineered would theoretically produce a better result.
Therefore we see that side by side with “connecting” the required sources, i.e. the data points that will guide the action, we may need to recast them and reengineer the form by which they provide the data they process and transmit. In this case instead of the “red light” – a set of bits/bytes.
More on “Connect “+ “Enable” = Purposeful Action.
2.4 Elements of an API strategy
It might help to go back to the definition of strategy that we wish to adopt in the context we are discussing.
“A high level plan to achieve one or more goals under conditions of uncertainty”
"A pattern in a stream of decisions" (Henry Minzburg)
Significant conditions of uncertainty are introduced by the change in the laws of supply and demand that for years were based on geographical and physical access. In order to meet a need, something had to be made available usually from within a prior defined, self contained, network of access. This has gone out of the window, the “network” of access is pretty much wherever the Internet functions and hence the word itself – “inter-net”, takes on a more profound meaning. The ability to provide supply for a potential demand now factors in the concept of unlimited reach. Consequently, competition emerges from hitherto unseen and unrecognized sources.
Strategy, i.e. a pattern of decisions to be taken must therefore be woven within the fabric of this new, seemingly unlimited universe of choices, threats and opportunities. Focus therefore becomes paramount. The need to decide what one cannot be, or does not want to be, becomes a necessary part of the decision matrix. And consequently, illogical though it may seem, the need to consciously limit oneself within a sea of choices and consumers that are now accessible at will, to choosing and satisfying a particular community with logically similar needs.
The elements of our API strategy consists of two parts – Identification and Implementation.
Identification here involves more than a customary consideration of prioritization of what this meant to do and for whom, and elimination – given the sheer complexity introduced by the geometrically increased number of options for the supplier and the consumer. The role of the Beneficiary therefore is paramount, for, the person who commits to getting the bread on the table with this new toolset being forged, must step up to the plate and say what he wants this to do, and why. The “customer or user” journey must first be drafted, limited though it may be, to a defined and agreed set of waypoints. Iteratively this may expand, and it will by design or at random. But for starters, we need a straight linear set of objectives for a defined set of users (who the beneficiary has the obligation to introduce), satisfied through the introduction of the new means to “connect” the dots at will. That is automated as never before and often directed by mechanized analysis of events and data as opposed to conscious human choice. What is thrown up on Amazon based on prior searches, or the whole new industry of Ad-sense spawned by search engines is an example of this kind of directed offering.
Implementation of an API strategy is a bit different because it might involve reshaping assets that do not belong to us. Strategy by definition is a plan. Michael Porter defined strategy in 1980 as the "...broad formula for how a business is going to compete, what its goals should be, and what policies will be needed to carry out those goals" and the "...combination of the ends (goals) for which the firm is striving and the means (policies) by which it is seeking to get there."
From the above definition there are two aspects to be studied and articulated. One is the goal the strategy is required to realize , and the other being the policies of the process through which the strategy is executed.We are now commenting on the approach of execution , i.e. the policy that will determine how APIs are to be utilized in realizing specific business success that was agreed upon prior.This drill down, the focus on specific tangible results and consequent elimination of APIs as a feel good, generally open-ended tool is important. This may appear as a contradiction in thought because APIs are by definition meant to be open ended in the sense that they can be used by anyone who conforms to the published guidelines without prior named approval. It is important to recognize that simply creating APIs is not going to catapult an enterprise into the digital age. APIs are after all, simply an access mechanism to summon the underlying technical asset through a web service. All this means is that whatever exists is now exposed through the Internet for consumption at will, provided the published norms are complied with.The difference is subtle but critical. The API economy, and participation therein, is not created from entirely new software assets, but largely by exposing these assets in a different manner. The packaging, as it were, changes the way the package inside can be transported, deployed and consumed. Vastly, by several multiples, increasing its reach.
An example: 60-70’s scenario: A photographer who wishes to expose his work would do so by renting a small hall in a city, contacting individually people who he would think might be interested. Today Facebook, Instagram and other digital media allow unlimited instant access to his work and importantly allow anyone, anywhere to identify him, his work and the means to access it through published content freely available at the tap of the relevant keys.
Two issues arise:
a) A technical asset (code/data) in the old world that is accessed, is done so by a set of procedures that are initiated towards satisfying a prior determined requirement, and the operating context in which such a requirement is fulfilled. This is usually well contained. The data formats and the necessary permissions are all well defined when the call is made to invoke the asset. In this environment we are “opening up” the asset without user limitations. The “user” could be virtually anyone and the requirement, in order to be satisfied, may have multiple dependencies, outside of the scope of the API that is now published.
b) Finding the API and giving it purpose, is now left in the hands of the user. This involves a lot of work and skills required may exceed that of a conventional technical user. The business purpose that the API can satisfy has to be visualized, the part it could fulfil in the customer journey. In the “old world”, domain specific business analysts would be involved in capturing the business requirement and translating them to the technical team who then design and develop with a test plan that addresses the specific user-defined requirements.. Now all that is out of the window and the expectation might be that the API when published would be found, used and deployed in circumstances that would yield business benefits. Such an expectation would invariably lead to disappointment and gradually disinterest in the whole API initiative, as ROI is not evidenced.
The elements of creating an API strategy:
The following principles would underline the process of identifying what we will address, where and how.
1) APIs are not a technical initiative – they are to be seen as a business initiative
2) APIs are not self contained independent units that can render benefit – they are to be seen as moving parts that fit into one or more assembly lines for the creation of integrated wholes involving other APIs, legacy systems. Each orchestration to render specific individual purpose.
3) APIs are not the agent of execution. They are to be seen as the keys to the door behind which the executing agent lies. Therefore what lies underneath will have to be reviewed to determine if fit for purpose under the new expectations of use and interoperability that may be required.
One of the key elements of the strategy would be the need for a set of rules regarding process, under which the whole initiative will be created and managed. When dealing with APIs, this becomes more important since we are dealing with a number of different entities, inside and outside the enterprise that will have to work together. The introduction of APIs is an exercise of integration. This cohesive umbrella, the structure to secure compliance of published norms across diverse users and often business units, is often referred to as “API governance”. While governance in all of IT is important, it takes special importance in this initiative as many of the users, stakeholders would be spread out and often external to the enterprise. Therefore we have to create a structure that is transparent to anyone who seeks to contribute or consume the network of assets we are now linking.The Governance team must therefore include members of the consuming public i.e. the beneficiaries, designers and enablers. CXO level representation is necessary to exercise cross-border decisions involving different business units.
Another element of API strategy, linked with the concept of governance would be that of community.
Let us briefly look at the dictionary definition of Community.
1. A group of people living in the same place, especially one practicing common ownership." a body of nations or states unified by common interests. "The European Community".
Denoting a worker or resource designed to serve the people of a particular area.
2. A feeling of fellowship with others, as a result of sharing common attitudes, interests, and goals. "The sense of community that organized religion can provide"
A similarity or identity. "Writers who shared a community of interests"
Joint ownership or liability. "A commitment to the community of goods"
A group of interdependent organisms of different species growing or living together in a specified habitat. "Communities of insectivorous birds"
The feature of a “community” that stands out is the identification of a shared, “common” need that binds the different individuals.It may be said the identification of the community, though iterative in nature, is one of the most important and perhaps ignored elements of the API initiative. Though sometimes glorified to be, APIs are not uniformly beneficial to everyone, everywhere. They serve a need to individuals who collectively have something in common. To others, outside of this community, their existence or lack, is irrelevant. Consequently to them (people outside this community), the imposition of rules regarding behavior to comply with the norms of the API economy is not only irrelevant; but seen as purposeless and burdensome. For a vision of a community of users, that can be added, the kernel must be pictured. Who exactly will this serve, what are their common needs, process and terrain under which this structure can be practiced? Why should they voluntarily accept governance and how will they collectively be better off than in individual existence. The same questions that are asked and answered in every union, political or social communities.
Let us examine the API strategy and community in the context of our case study.
In the last part, the CIO of the Mobile Operator presented the idea of APIs and Service Oriented Architecture to the Business Strategy and CEO.
The CEO and Business Strategyasked the following questions to the CIO:
1. How will you justify the investment for re-organizing the IT estate as APIs?
2. How will you prioritize which business domains to address first
3. How can quick wins be demonstrated ?
The CIO, being fully aware of the right approach for the API Journey, responded to the questions as follows:
1. How will you justify the investment for re-organizing the IT estate as APIs?
The creation of APIs will be business-purpose driven. We have acknowledged the threats, so we have the responsibility of converting them to opportunities. We have witnessed loss of opportunities to Over the Top (OTT) players. Our ability to launch new offerings quickly to market is greatly dependent on our IT estate's ability to change fast. Our IT architecture has evolved over many years. We have built many point to point links between applications and these links are not re-usable. It is important for us to re-organize IT components as business capability APIs.
2. How will you prioritize which business domains to address first?
This cannot be prioritised by IT alone. We require active participation of Business teams, specifically products and customer experience teams. The starting point would be to analyse customer journeys. We have to ask ourselves - how have the trends in the digital world changed the way customers transact with our business. What are the new journeys and new touchpoints? This may require us to re-imagine the customer journeys for all our product streams - mobile, broadband, TV, etc. This should be the ownership of the product strategy team. They will be designated as the "Beneficiaries".
3. How can quick wins be demonstrated?
We will conduct a Pilot phase for 9 months. During the pilot, we will validate the prioritised customer journey touchpoints. Since the priorities and customer journeys were analysed in collaboration with business, we have a very high chance of having early users of APIs. A growing community of users will be an indication of a quick win.
The concept of the customer journey is a key pivot while addressing an API initiative. APIs are to be seen as keys to internal assets that we seek to expose for automated use by other internal or external agents who seek to apply what lies underneath.This suggests that the use of these assets realizes a hitherto unavailable orchestration, to realize a better process that in some shape or form improves the offering that the asset currently provides or participates as a part therein. Often the assets that render the new service, do not themselves change. They are simply strung together.
Uber – Born into the API Economy.
Let’s take the example of Uber cabs. The car itself, the driver, the passenger, the pick up point and the destination, the cost of operating the vehicle – all of this remains the same. What is different is now there is a highly efficient means of locating the car that is at this time closest to a given passenger who exposes his need. The location and this vehicle have now exposed themselves at the time as available. So the information that is relevant for a customer to consume the asset (the driver and the car) is simply put together, published and made available, which is the key. The customer journey i.e. the series of steps that the customer (user) takes, is now made much more efficient.The new customer journey, i.e. the efficiency improvements were created from an awareness of the shortcomings of the older process by which a cab is located and hailed.
A new customer journey was first envisioned, and the process to realize that was born. This required that available dynamic information, regarding the taxi, regarding the passenger be exposed in a public medium in real-time that can be accessed and consumed. The ubiquity of the Internet and Smart phones made this possible.
The realization of the initiative may be entrusted to a team that could be called the Integration Framework Team. This team will include Beneficiaries, Enablers and Catalysts.
As in any initiative, one can go forward faster, provided direction is established with the correct set of tools. Once again, it is important to understand and practice the discipline of sequence. Need follows purpose, purpose is drafted to fulfill the identified need. Tools that are acquired and implemented, be it product or process, must be chosen after anchor is cast, i.e. business purpose and direction be established and the technology to achieve it is then chosen.
In many initiatives there is an early foray to purchase a product, as it gives people the sense that something tangible has been done. Budget has been used, the initiative is seen to be on the way. A check box has been checked. This often results in the initiative now being confined to a roadmap that is defined by the product and its constraints, which really does not impart tangible business value to the API initiative. Hence the first step is the tedious definition of purpose, expressed in a tangible form of expression. This is the role of beneficiaries. They are the ones who see the customer journey, who commit to realizing it – and the product / tools/ process chosen with that objective and commitment firmly in mind.
Very often, ambitious and over reaching vendors hard-sell products and even process, that are claimed to catapult users into realizing the riches of the API economy. There is no compass, with any number of gimmicks that can steer you if you don’t know where you want to go, and is held in the hands of the person who is designated with express responsibility to get you there.
2.6 Legacy - the blessing in disguise
When starting a new initiative, it is often felt that the existing infrastructure is a shackle. Yes, in a way, the old world, the existing world in which the company functions was created to function in a time that is undergoing rapid change. However there are assets that have not only served well, but could well be the differentiating factor between new entrants born in the digital space, agile and quick as they may be, and the traditional enterprises that are seeking to transform themselves. It is possible to take advantage of the digital world, leveraging existing assets to catapult the enterprise beyond what a newborn digital can offer.
The choice of product (the stack), has to be after purpose is defined and an assessment of the surrounding artifacts is made, to work with the new world order and be a part of it. Legacy is all-important and often the differentiating factor between offerings. Conscious effort is required to benefit from the riches of legacy without succumbing to its constraints.
The term “Solution Accelerators” may therefore be more appropriate, as they represent a group of commonly applicable elements that were derived from the study and practice of addressing commonly seen problems in migrating to the API world.Remember, right from the beginning, we have stated that this whole initiative has to be a business initiative with IT being a solution provider in the purest sense of the word. This implies clearly that the onus of defining and prioritizing the problem, with as much precision as possible is a prerequisite. Otherwise we could easily be drawn into the lure of spending millions of dollars on products, process and thousands of senior level hours on people, some times years of lapsed time, in “failed initiatives". They often failed because success parameters were not discussed and agreed upon in the first case, as to what must be addressed, the dependencies therein. The Emperor’s New Clothes by Hans Christian Andersen is a fable that is unfortunately played over time and time again. The latest and best product is bought and no one really sees or feels the utilitarian value.
The problem may be seen in three parts.
Part 1 – Identification of the customer journey
First identification and definition of business purpose.This classification begins after the overarching goal of the initiative is prioritized into choosing which particular area of the business most urgently (not necessarily in order of importance) needs to demonstrate the benefits of placing it in a digitized landscape. This kind of quick reinforcement that the game is worth the candle, helps in two respects. It first of all draws attention across the enterprise that real benefit was demonstrated in an area that urgently needed it, and secondly it forces stakeholders to think in terms of specific problems and not just guiding principles or revised architecture across domains for the sake of a vaguely defined better world.
Once we know what it is we want to address, the revised customer journey must be charted. The term customer journey here does not refer only to a buyer of the company’s products or services, but any customer of the new system that will expose existing assets of the enterprise differently. This could be supply-chain management, HR processes, machine-to-machine communication that triggers human intervention (IOT), or even classical customer / sales interaction.
The “journey” that is to be visualized is the process through which an objective is accomplished. The use-cases that together may adopt such process as an improvement over existing procedure form the community of beneficiaries that we target. As such, we are trying to visualize a caravan, multiple logical users crossing the desert linked by the Internet. However a logical starting point and a logical (though iteratively moving) end point must be seen and articulated, or we will be going along a journey without purpose or destination. Direction alone is insufficient.
“Would you tell me, please, which way I ought to go from here?”
“That depends a good deal on where you want to get to,” said the Cat.
“I don’t much care where–” said Alice.
“Then it doesn’t matter which way you go,” said the Cat.
“–so long as I get SOMEWHERE,” Alice added as an explanation.
“Oh, you’re sure to do that,” said the Cat, “if you only walk long enough.”
- Alice in Wonderland, Lewis Carroll, 1951
Part 2 – Audit of the touch points in the envisioned journey
Second is the audit of the relevant participants that will be involved in the launch.The Pilot can be formed to work within the parameters of existing infrastructure that can accommodate the envisioned need and deliver upon it. This helps us prove success of the initiative and strengthen the business case. Later we will inevitably find that the organizational readiness of the greater enterprise will have to be conducted. There will probably be significant changes required to core assets, especially at the data level to integrate and provide a common view. All of this is addressed at the Enablement phase, post pilot. Once we have a community of beneficiaries who have committed to the initiative, we have audited their touch points with a view to participating in the common journey; we are ready to proceed to the implementation phase.
Part 3 – Implementation. Getting on the road
This is best done with a pilot. The Pilot would first identify one or more customer journeys that would render a specific, envisioned benefit. The pilot also has a defined community of participants who will ride together in the new journey using common process, tools, data and complying with governance that they participate and contribute towards.
The implementation then takes the following steps:
There are several products in the market to deal with the physical elements of API storage and exposure, API gateways and Cloud platforms to house, provide access and records of use, billing products to monitor consumption.While these products help us towards realizing the business purpose that we are addressing, it is not to be seen as a plug and play initiative. We cannot get on the road by purchasing these products, configuring them and hoping the APIs will be adopted.
DigitMarketTM API Manager, a complete package to manage your APIs, is available as a SaaS offering, for on-premise deployments and in a hybrid model. These products may be used to visualize how the rubber hits the road. Considerable work may be required to adapt and adopt them to your own enterprise. While this is the case with any product suite, these products here are built on libraries that allow change to meet the needs of legacy and are therefore more flexible than proprietary closed systems. This becomes especially important when we are considering integration of a variety of home grown diverse enterprises, brought together by acquisition or simply by the need to forge a partnership to withstand a common threat.
Success to be termed as success, must demonstrate not only access, through published APIs, but also sustained increasing use of a new customer journey. As in the Uber example where an objective is realized differently, and more efficiently, we need to show that customers are getting something that is seen as more effective besides being more efficient. Self-service and automated access to hitherto private and dynamic information that results in rapid voluntary adoption is characteristic of the new paradigm.
End of chapter. Next set of chapters: Coming soon... !!!