46,44 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
A strategy and implementation guide for building, deploying, and managing APIs
Key Features
- Comprehensive, end-to-end guide to business-driven enterprise APIs
- Distills years of experience with API and microservice strategies
- Provides detailed guidance on implementing API-led architectures in any business
Book Description
APIs are the cornerstone of modern, agile enterprise systems. They enable access to enterprise services from a wide variety of devices, act as a platform for innovation, and open completely new revenue streams.
Enterprise API Management shows how to define the right architecture, implement the right patterns, and define the right organization model for business-driven APIs.
Drawing on his experience of developing API and microservice strategies for some of the world's largest companies, Luis Weir explains how APIs deliver value across an enterprise. The book explores the architectural decisions, implementation patterns, and management practices for successful enterprise APIs, as well as providing clear, actionable advice on choosing and executing the right API strategy in your enterprise.
With a relentless focus on creating business value, Luis Weir reveals an effective method for planning, building, and running business products and services with APIs.
What you will learn
- Create API strategies to deliver business value
- Monetize APIs, promoting them through public marketplaces and directories
- Develop API-led architectures, applying best practice architecture patterns
- Choose between REST, GraphQL, and gRPC-style API architectures
- Manage APIs and microservices through the complete life cycle
- Deploy APIs and business products, as well as Target Operating Models
- Lead product-based organizations to embrace DevOps and focus on delivering business capabilities
Who this book is for
Architects, developers, and technology executives who want to deliver successful API strategies that bring business value.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 349
Veröffentlichungsjahr: 2019
Ähnliche
Enterprise API Management
Copyright © 2019 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
Acquisition Editor:Dominic ShakeshaftAcquisition Editor – Peer Reviews: Suresh JainProject Editor: Kishor RitDevelopment Editor:Joanne LovellTechnical Editor:Aniket ShettyProofreader: Safis EditingIndexer:Pratik ShirodkarProduction Designer:Sandip Tadge
First published: July 2019
Production reference: 3091019
Published by Packt Publishing Ltd. Livery Place 35 Livery Street Birmingham B3 2PB, UK.
ISBN 978-1-78728-443-2
www.packtpub.com
Packt.com
Subscribe to our online digital library for full access to over 7,000 books and videos, as well as industry leading tools to help you plan your personal development and advance your career. For more information, please visit our website.
Why subscribe?
Spend less time learning and more time coding with practical eBooks and Videos from over 4,000 industry professionals
Improve your learning with Skill Plans built especially for you
Get a free eBook or video every month
Fully searchable for easy access to vital information
Copy and paste, print, and bookmark content
Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.packt.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at [email protected] for more details.
At www.packt.com, you can also read a collection of free technical articles, sign up for a range of free newsletters, and receive exclusive discounts and offers on Packt books and eBooks.
Foreword
Do you remember the days when businesses were considering whether they should invest in a website? Would building an online presence have any impact on their bottom line?
Getting on the web merely involved moving from the Yellow Pages and printed advertisements to a new channel. But this still left the potential of offering every business capability digitally untapped.
The web revolution was a kick-start for the next era for businesses – digital transformation. And APIs are the connective fabric of this much-debated digital transformation. Under API transformation, you deliver your organizational capabilities – your products – via APIs. Your communication, information exchange, innovation, and adaptation to ever-changing market conditions happens through well-laid-out APIs. The APIs become the backbone of your company. You can even leverage your partner sales channels with the right APIs!
API transformation does not start with building APIs, which were previously the technical creations of engineers. It begins with changing the mindset of the entire organization. It means embracing the culture of API first.
API first implies that everything produced and consumed in the organization is, and has, an API. Companies such as Adidas, DHL, or Volkswagen have already embarked on the API-first journey. Do you ever wonder whether there is an API for Adidas Stan Smith Sneakers? There is, and not just one! Adidas product, order, inventory, and other APIs are all about physical products. Every product has an API!
And we are still only scratching the surface. APIs no longer live isolated in silos; they are forming landscapes on every level: team, organization, domain, and even cross-domain. In the coming years, autonomous APIs will completely change how we discover, close, and implement deals. How do you find the best logistics service to ship a container from Wakkanai Port every month? What if you can perform this search and make the order in a fraction of a second? What if you can look for and close better deals a thousand times a day? Do you still think that, in 10 years' time, businesses will be asking whether they should invest in APIs?
Of course, embarking on an API journey requires preparation, learning new skills, and avoiding roadblocks. Many organizations naively start with the purchase of an expensive API solution in the hope of getting on the right track, only to later find themselves in a vendor lock-in trap, with a lack of product ownership and the infamous pitfall of "build it (an API), and they will come."
Executing a successful API transformation is a matter of building upon the three pillars: business, organization, and technology. Ignore one of them, and the project will fail. Each pillar has to understand the role and importance of APIs, rally under the API-first flag and carefully plan the API strategy. Only when all three elements are acting together can you hope for a prosperous API landscape.
This book will take you on an API journey that avoids common traps. It is the handbook for every API program owner, enterprise architect, and forward-thinking business person. Wherever you are, I am sure this book will prove to be an excellent companion.
The author (Luis) does an incredible job of explaining the business aspects of APIs in chapters one, three, and eight, while providing a great deal of technical background in chapter two, and then building on these foundations with architectural and technological concepts in the subsequent sections. The learning process then culminates in chapter seven, which presents the framework for the API life cycle process before closing with the grand finale on API products, business, and organizational impacts.
This book is the missing API manual for everybody interested in executing API transformation. It provides a holistic, concise look at the business, organization, and technical aspects of APIs like no other book before it.
API styles, tools, and vendors come and go. However, the concepts as presented in this book will help you to create a culture and values that last.
Good luck on your API journey!
Zdenek "Z" Nemec
Founder of Good API Consulting, and the author of API Blueprint and supermodel.io
Contributors
About the author
Luis Augusto Weir is a director of software development at Oracle and a former chief architect at Capgemini, Oracle Ace Director, and Oracle Groundbreaker Ambassador. An API management and microservices evangelist, Luis has over 17 years' experience in implementing complex distributed systems around the world.
Having always had a natural talent for software, computers, and engineering in general, Luis' career in software began from an early age. Even before starting university, Luis' entrepreneurial spirit led him to start several ventures, including one of the very first social media websites in his country of origin (Venezuela), as well as a small software development firm. Although none of these ventures turned into multi-million dollar corporations, the experience and knowledge gained during this period led him to develop a passion for distributed software computing that inevitably led to service-oriented architectures (SOA).
In recent years, Luis has been helping some of the largest Fortune 500 companies in industries such as retail, the supply chain, and agriculture to define and implement their API and microservice strategies, his experience of which served as a foundation for this book.
A co-author of three other books as well as numerous articles and white papers, Luis has been a frequent speaker at events such as CodeOne, Devoxx, Gartner AAD&I, Oracle OpenWorld, Java2Days, and many user groups and meetups.
Luis holds an MS in corporate networks and systems integration from the Universitat Politecnica de Valencia (UPV) and a BS in electronics engineering from the Universidad Nueva Esparta.
About the reviewers
Phil Wilkinshas spent over 30 years in the software industry, acquiring a wealth of experience in different businesses and environments, from multinationals to software start-ups, and from customer organizations to specialist consulting. He started out as a developer on real-time, mission-critical solutions, and has worked his way up through technical and development leadership roles, primarily in Java-based environments.
He now works for Capgemini's multi-award-winning team specializing in cloud integration and API technologies and, more generally, with Oracle technologies.
Phil has contributed his knowledge and experience by providing input and support to the development of technical books (particularly with Packt Publishing), including co-authoring Implementing Oracle Integration Cloud Service, and Implementing Oracle API Platform, as well as online training on API best practices.
In addition to this, he has also had articles published in technical journals and is an active blogger. He has presented at a broad range of industry events, from large conferences around the world to user group and developer meetups. Phil’s expertise and contributions to the Oracle community have been acknowledged by Oracle by accrediting him as an Oracle Ace.
Kshitij Mehrotra is an expert and thought leader in "digital transformation" with extensive experience in APIs, cloud applications, SOA, analytics, security, business activity monitoring (BAM), and business process management (BPM). He has helped several customers and employers to define and execute transformation and growth strategies by recommending the right architecture and validating strategic investment in a variety of technologies most relevant to customers' requirements.
Kshitij shares his experience with customers, helping them to shape digital initiatives and highlighting pitfalls that could affect implementation, as well as identifying the digital tools and technologies designed to ensure that the program is aligned with the businesses' strategy.
A blogger and speaker, he is Axway’s chief architect for platforms and products. He has more than 19 years' experience of implementing solutions across the world and has successfully delivered large and complex digital and SOA solutions to Fortune 500 companies.
He has led middleware programs for renowned organizations, including Oracle Consulting, Wipro, and HCL Axon.
Rolando Carrasco is an Oracle Groundbreaker and Oracle ACE specializing in API management, service orientation, digital transformation, and microservices. He has over 19 years' experience and has worked for companies including HP and Oracle. Currently, he is the CTO of a Mexican consulting firm by the name of S&P Solutions, which has a very solid foothold in the Latin-American market.
He has been a constant Oracle Open World speaker and ongoing contributor within the community with blogs, videos, webinars, podcasts, presentations, and event coordination.
Rolando is a certified instructor for Arcitura, in particular providing content around service orientation and microservices. He is both a certified SOA architect and a microservices architect.
Rolando specializes in modern architecture, as well as high-demand and mission-critical applications.
He is a co-author of the book Oracle API Management 12c Implementation, published by Packt in 2015, and has contributed as a technical reviewer for at least three books during the last three years.
Table of Contents
Title Page
Copyright and Credits
Enterprise API Management
About Packt
Why subscribe?
Foreword
Contributors
About the author
About the reviewers
Preface
Who this book is for
What this book covers
Download the color images
Conventions used
Get in touch
Reviews
The Business Value of APIs
Change or die
What does this hyperconnectivity tell us?
The digital dilemma
Access to enterprise information and functionality is king
What are APIs and why should a business care?
APIs as an enabler for innovation and bimodal IT
APIs to monetize on information assets
APIs for regulatory compliance
GDPR
PSD2
Fast Healthcare Interoperability Resources (FHIR)
APIs for the reuse of business capabilities
Avoiding a hyperconnectivity mess
The API value chain
APIs as a driving force for many large acquisitions in the software industry
Summary
The Evolution of API Platforms
The journey of API platforms - from proxies to microgateways
Generation zero
First generation
Second generation
Application Services Governance
Third generation
Cloud adoption
Digital transformation
Customer-centricity
Common denominators
Summary
Business-Led API Strategy
Kick-starting a business-led API initiative
Defining the business drivers
Defining the goals and objectives
Defining the API strategy
Summary
API-Led Architectures
What is API-led?
Architecting API-led
Conceptual architecture view
Technical capability view
Management and operations
API life cycle
API design and mocking
Policy definition and implementation
API pages, developer portal, and marketplaces
API runtime operations and analytics
API monetization and billing
API exposure
Authentication (AuthN) and authorization (AuthZ)
Access control
API key validation
CORS
OWASP Top 10 protection
API composition
Redaction
Format conversion
Header handling
Fault handling
Routing
Rate limits
Throttling
Caching
Push notification
API load balancing
Quotas and plans
Versioning and deprecation
Custom policies
Business capability services
Semi-decoupled services
Orchestration
Data validation
Data transformation
Connectivity
Protocol conversion
Shared runtime
Fully decoupled services
Choreography
Data validation
Processing logic
Polyglot programming
Independent runtime
Service mesh
Event Hub
Service registry
Non-shared storage
Identity and access
Users and roles management
Identity federation
Access management
Summary
API-Led Architecture Patterns
Patterns in the context of APIs
API-led architecture patterns described
API resource routing
API content-based routing
Payload pagination
CRUD API service
CQRS API service
API aggregator
API orchestration service
API microgateway
Sidecar API gateway
Webhook
API geo-routing
API firewall
API basic authentication
API bearer of token
API bearer of obscure token
Summary
Modern API Architectural Styles
A brief history of interfaces
The rise of RPC
RPC and object-oriented programming
XML to the rescue
Latest trends
What does this trend analysis really tell us?
REST
Architecture
Interface definition
OAS
API Blueprint
RAML
Transport and payloads
Usage flow
GraphQL
Architecture
Architectural principles
Interface definition
Types that define operations
Types that define data
Transport and payloads
Usage flow
gRPC
Architecture
Interface definition, transport, and payload
Usage flow
Comparing the options
Summary
API Life Cycle
The full API development life cycle
API life cycle
API ideation and planning
Design
Mock and try
Create/configure
Deploy
Promote, deprecate, and retire
Observe
The API design-first life cycle
Service life cycle
Scaffold/refactor
Build and unit test
Contract test
Customer life cycle
Implementation and use
Feedback
Summary
API Products' Target Operating Model
Products in the real world
APIs as products
The implications of treating APIs as products
What is a TOM?
Defining the model
Organization
Central organization
Federated organization
A platform-based approach
Roles and responsibilities
API product teams
API platform team
Communication and collaboration model
Transition approach
Summary
Preface
Application Programming Interfaces (APIs) can be compared to doors: their main purpose is to provide access to something. Doors come in different shapes, sizes, colors, and materials, and offer different levels of security to protect whatever is behind them.
In the case of APIs, however, that something is digital assets such as raw and cleansed data, images, videos, documents, and even functionality that performs complex calculations or data processing based on inputs.
Sometimes, doors are wrongly designed or built:
The same is also true with APIs. API management is a discipline that has evolved to deliver the processes and tools required to discover, design, implement, use, or operate enterprise-grade APIs. Most importantly, the discipline is responsible for managing the communities around APIs. Such communities may consist of developers building and/or using APIs in their apps, but there are also communities of business and IT executives looking to speed up innovation at a lower cost.
We can conclude that API management's true objective is to deliver value. This could be valuable to the business in the form of reducing development effort by using existing APIs (internally developed ones or external ones developed by third parties). Value could also come from monetizing APIs that offer intangible products (digital assets) that developers and/or executives alike would be willing to pay for.
Value can only be truly delivered when the full cycle of delivering something, in this case APIs, is fully understood, optimized, and overseen. The creation of an API strategy with a clear purpose and objectives is followed by the inception of an API through innovation workshops. Next is planning, design, implementation, deployment, operations, and monitoring, until the eventual retirement of the API.
API management is no longer just about implementing APIs. Thousands of public APIs (with more being added by the day) are listed in API marketplaces, such as programmableweb.com, and RapidAPI.com, each representing a digital door to an organization's digital product offerings. Thinking that all APIs need to be internally developed is a huge fallacy.
To summarize, API management must be as much about providing the means to discover and use public APIs as it is about implementing new ones. At the epicenter of any API management initiative must be the creation of value for the business but also for the users of an API.
APIs at the center of digital ecosystems
As organizations embrace the adoption of public APIs and/or create new API products, there is an interesting effect. The creation of new ecosystems, all enabled through APIs, starts to happen as value comes from adopting and combining someone else's digital assets in the creation of new products.
In fact, a study conducted by Mckinsey predicts that by 2025, digital ecosystems will account for 30% of global revenues, which according to the firm is about 60 trillion US dollars.
The study is referenced in the following link:
https://www.mckinsey.com/industries/financial-services/our-insights/insurance-beyond-digital-the-rise-of-ecosystems-and-platforms
Not only this is huge, but it shows that being part of this digital ecosystem will be a matter of survival for some organizations.
APIs as an evolving paradigm
APIs are not new. In fact, they are far from it. The use of the term API can be traced back to 1968 to a publication titled Data Structures and Techniques for Remote Computer Graphics by I. W. Cotton and F. S. Greatorex, Jr. Since then, we've seen the term being born and re-born in proprietary protocols such as Sun Microsystems' Remote Procedure Call (RPC), Common Object Request Broker Architecture (CORBA), and Distributed Component Object Model (DCOM). We've also seen it in public standards, such as XML-RPC, which then evolved to become Simple Object Access Protocol (SOAP), which then, along with the Web Services Description Language (WSDL), became the foundation for Web Services and service-oriented architecture (SOA).
There was then a shift of paradigm into resource-centric and more lightweight APIs based on the REST architectural style. We are now back to RPC with emerging technologies such as GraphQL and gRPC, both of which are rapidly increasing in popularity.
However, what we see today is not just a technological shift of API technologies. The emergence of APIs as the means to enable digital ecosystems has created an economy of its own, an API economy, which has a more fundamental impact on how businesses organize their teams.
As businesses realize that APIs can truly be business products in their own right, the teams that deliver these products will no longer be simply considered IT teams or, to put it bluntly, cost centers. For businesses to succeed in the API economy, they need to shift away from traditional ways of delivering IT to a product-centric approach whereby the main goal is to make an API product successful and profitable.
Technical capabilities, especially with cloud computing now being the new normal, must too evolve in order to give these teams all of the tools they need to produce products that are innovative and competitive in the marketplace.
Who this book is for
This book will be of great benefit to developers, architects, and even IT/Digital executives looking for sources of inspiration when defining and implementing:
Business-led API strategies
API-led architectures and patterns
API architectural styles to use (for example, REST, GraphQL, or gRPC)
The full API life cycle, including related cycles such as the service and API consumer cycles
Target operating models suitable for API products.
Lastly, as the book is technology-agnostic and doesn't offer strong views on tools, it can also be used as a reference to compare different products, whether they are commercial or open-sourced.
What this book covers
Chapter 1, The Business Value of APIs – this chapter gives context to the rest of the book by elaborating on what APIs mean to a business and why they should be embraced. It also talks about business drivers for APIs and how to determine their value based on an API value chain.
Chapter 2, The Evolution of API Platforms – this chapter takes a step back to look in detail at how technologies and platforms have evolved from traditional middleware and enterprise service bus-centric SOA architectures to fully federated, multi-cloud, and microservices-based architectures that enable APIs to exist and be managed wherever information resides.
Chapter 3, Business-Led API Strategy – the main focus of this chapter is to deliver a comprehensive approach to defining API strategies that have clear, concise, and business-centric goals and objectives.
Chapter 4, API-Led Architectures – this chapter walks through a reference architecture and all of the capabilities required to implement modern APIs and fully decouple (micro)services. The chapter is a great reference for what modern stacks should look like.
Chapter 5, API-Led Architecture Patterns – this chapter extends Chapter 4 by walking through how the different capabilities described in the reference architecture can be combined in order to deliver sound solutions to common problems.
Chapter 6, Modern API Architectural Styles – this chapter gives a detailed overview of the trendiest API architectural styles (at the time this book was written). The chapter is a great source of inspiration for anyone looking for a point of view on different API styles and their pros and cons.
Chapter 7, API Life Cycle – this chapter walks through the full API life cycle and also related ones, such as the service and API consumer life cycles. The chapter is a great reference for those wishing to implement end-to-end API processes and tools from scratch or anyone looking for inspiration on how to enhance existing ones.
Chapter 8, API Products' Target Operating Model – as the name suggests, the chapter walks through what it really means to treat APIs as products and the implications this has for organizations. From core concepts to different operating models with their pros and cons, this chapter elaborates on a topic that is rarely discussed in the world of APIs.
Download the color images
We also provide a PDF file that has color images of the screenshots/diagrams used in this book. You can download it here: https://static.packt-cdn.com/downloads/9781787284432_ColorImages.pdf.
Conventions used
There are a number of text conventions used throughout this book.
Bold: Indicates a new term, an important word, or words that you see on the screen, for example, in menus or dialog boxes. For example: "Modern APIs are broadly considered to be an evolution of the Remote Procedure Call (RPC) protocol."
Get in touch
Feedback from our readers is always welcome.
General feedback: If you have questions about any aspect of this book, mention the book title in the subject of your message and email us at [email protected].
Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit http://www.packt.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details.
Piracy: If you come across any illegal copies of our works in any form on the Internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.
If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.
Reviews
Please leave a review. Once you have read and used this book, why not leave a review on the site that you purchased it from? Potential readers can then see and use your unbiased opinion to make purchase decisions, we at Packt can understand what you think about our products, and our authors can see your feedback on their book. Thank you!
For more information about Packt, please visit packt.com.
The Business Value of APIs
This chapter focuses on the value that Application Programming Interfaces (APIs) bring to the business. It begins by describing how digital disruption is forcing organizations to change in order to innovate and therefore avoid being disrupted. To this end, I explain how APIs enable digital strategies and digital transformation by unlocking key enterprise information assets and functionality, which are typically locked in systems of record, many of which are legacy. The chapter continues by elaborating on the value chain of APIs and how each level of maturity delivers new capabilities to the business.
Change or die
The world has changed. Information technology has changed every aspect of our lives: from fundamental things, such as how we purchase goods, interact with brands, and even do our jobs, to how we communicate with each other. In fact, a study by British psychologists suggests that around two billion people use smartphones across the globe, with over half the population in developed countries relying on them on a daily basis. That's over half a billion people worldwide using their phones to do all sorts of things, 85 times on average each day, according to the same study.
However, the aforementioned study only focuses on smartphone usage. If you factor in interactions with other devices, such as tablets, personal computers, wearables, and even machines (that is, smart cars and voice assistants such as Alexa), the number of interactions is huge.
What does this hyperconnectivity tell us?
For a start, it is pushing the boundaries of what we thought was possible and making science fiction seem real. Most importantly, it has opened up new avenues for businesses to innovate and disrupt the market, which is exactly what the so-called "digital disruptors," such as Google, Apple, Facebook, Amazon, and Netflix, in fact did, and continue to do. Established businesses, such as Blockbuster and Kodak, couldn't cope with the (digital) innovation introduced by Netflix and Apple, and ended up filing for bankruptcy. Traditional industries, such as the taxi industry and hospitality, are also being severely disrupted by Uber and Airbnb.
These companies are just the obvious examples that everyone talks about. With over 100 million new start up businesses launched every year, even if only 10% (as analysts predict) are successful, we are talking about 10 million new companies with the potential to become the new Netflix or Uber, but for different industries.
Now, because of this, it's no wonder that most organizations globally have embarked on digital transformation initiatives in order to avoid being (further) disrupted. As Harvard Business Review (HBR) nicely put it:
According to the same article by HBR, the most disrupted industries are those that relate to Business to Consumer (B2C), with media and telecom at the top of the list, closely followed by financial services and retail:
However, these figures should not come as a surprise. A closer look shows that there is a direct correlation between the disrupted B2C organizations and the fact that 2 billion individuals are using their smartphones and other devices frequently. Put simply, B2C organizations that haven't been able to innovate and engage customers in different ways, and through digital channels, are more susceptible to being disrupted by newer and more agile businesses:
The digital dilemma
These organizations that are more exposed to digital disruption are therefore faced with a dilemma. In order to remain relevant and stay in business, they must create a digital strategy that allows the business to innovate and be more agile. However, in order to do so, they can't simply get rid of old systems of record, most of which are legacy and contain critical information assets that support day-to day-operations.
Bearing in mind that most of these organizations can't afford to start from a white sheet of paper, the digital strategy must therefore cater to the transformation of hundreds (if not thousands) of existing systems, many of which are considered legacy.
Such an undertaking can be huge, not only in terms of costs to the business, but also in terms of the risks. This is exactly where the dilemma lies: do nothing and save costs/avoid risks, and most likely end up being disrupted, or become a disruptor by taking the business on a digital transformation journey, which could be risky and costly.
Access to enterprise information and functionality is king
Is it really that risky and costly to take the business on a digital transformation journey? Well, as with everything, it depends. Organizations that perceive digital transformation as merely an exercise to adopt omnichannel strategies, without first understanding "why" they are doing it, or "what" they are trying to accomplish, will most likely fail to realize any business benefits. For these organizations, such an undertaking will have plenty of unknowns and will therefore be perceived as risky and costly.
Organizations that start off with the creation of a digital strategy to articulate the targeted business goals, and also identify what business and technical capabilities are required in order to achieve this, will most likely perceive the digital journey as a key enabler for the business strategy, rather than just another expensive IT project. For such organizations, digital transformation represents a justifiable and calculated risk.
It's no wonder that Forbes listed digital transformation as the #1 priority for Chief Information Officer's (CIO) in 2017:
However, in order to achieve this, the devil is in the detail. The "how" question should not be forgotten and must be thoroughly addressed while defining the strategy. For example, one of the biggest challenges faced by organizations undertaking digital transformation is around how to get access to core enterprise information assets, most of which are typically locked in hundreds of systems of record. Therefore, without unrestricted, secured, and reliable access to such systems, introducing any sort of innovation will be nothing more than a prototyping exercise.
What are APIs and why should a business care?
APIs are like doors that provide access to information and functionality to other systems and/or applications. APIs share many of the same characteristics as doors:
Most of them have locks and, without the key, they can't be opened.
They come in different types (size, color, material, type of lock, and so on).
They can serve different purposes. For example, they can be public-facing or just internally accessed.
They are located in a specific location: an address.
They can be as secure and closely monitored as required.
If they don't work, it will affect the experience of their users.
APIs, however, are not new. In fact, the concept goes back a long time and has been present since the early days of distributed computing (some argue even before then). However, the term as we know it today refers to a much more modern type of API, known as REST or Web APIs.
Modern APIs started to gain real popularity when, in the same year of their inception, eBay launched its first public API as part of its eBay Developers Program. eBay's view was that by making the most of its website functionality and information also accessible via a public API, it would not only attract, but also encourage communities of developers worldwide to innovate, by creating solutions using the API. From a business perspective, this meant that eBay became a platform for developers to innovate on and, in turn, eBay would benefit from having new users that perhaps it couldn't have reached before.
eBay was not wrong. In the years that followed, thousands of organizations worldwide, including known brands, such as Salesforce.com, Google, Twitter, Facebook, Amazon, Netflix, and many others, adopted similar strategies. In fact, according to programmableweb.com (a well-known public API catalogue), the number of publicly available APIs has been growing exponentially, reaching over 20k as of August 2018:
It may not sound like much, but considering that each of the listed APIs represents a door to an organization's digital offerings, then we're talking about thousands of organizations worldwide that have already opened their doors to new digital ecosystems, where APIs have become the products these organizations sell and developers have become the buyers of them.
In such digital ecosystems, communities of internal, partner, or external developers can rapidly innovate by simply consuming these APIs to do all sorts of things: from offering hotel/flight booking services by using the Expedia API, to providing educational solutions that make sense of the space data available through the NASA API.
There are ecosystems where business partners can easily engage in business-to-business transactions, either to resell goods or purchase them, electronically and without having to spend on Electronic Data Interchange (EDI) infrastructure. Ecosystems where an organization's internal digital teams can easily innovate as key enterprise information assets are already accessible.
So, why should businesses care about all this? There is, in fact, not one answer, but multiple answers, as described in the subsequent sections.
APIs as an enabler for innovation and bimodal IT
What is innovation? According to a common definition, innovation is the process of translating an idea or invention into a good or service that creates value, or for which customers will pay. In the context of businesses, according to an article by HBR, innovation manifests itself in two ways:
Disruptive innovation
: Described as the process whereby a smaller company with fewer resources is able to successfully challenge established incumbent businesses.
Sustaining innovation
: When established businesses (incumbents) improve their goods and services in the eyes of existing customers. These improvements can be incremental advances or major breakthroughs, but they all enable firms to sell more products to their most profitable customers.
Why is this relevant? It is well known that established businesses struggle with disruptive innovation. The Netflix versus Blockbuster example reminds us of this fact. By the time disruptors are able to catch up with an incumbent's portfolio of goods and services, they are able to do so with lower prices, better business models, lower operating costs, and far more agility and speed to introduce new or enhanced features. At this point, sustaining innovation is not good enough to respond to the challenge.
With all the recent advances in technology and the internet, the rate at which disruptive innovation is challenging incumbents has only grown exponentially. Therefore, in order for established businesses to endure the challenge put upon them, they most somehow also become disruptors. The same HBR article describes a point of view on how to achieve this from a business standpoint. From a technology standpoint, however, unless the several systems that underpin a business are "enabled" to deliver such disruption, no matter what is done from a business standpoint, this exercise will likely fail.
Perhaps by mere coincidence, or by true acknowledgment of the aforesaid, Gartner introduced the concept of bimodal IT in December 2013, and this concept is now mainstream.
Gartner defined bimodal IT as the following:
According to Gartner, Mode 1 (or slow) IT organizations focus on delivering core IT services on top of more traditional and hard-to-change systems of record, which, in principle, are changed and improved in longer cycles, and are usually managed with long-term waterfall project mechanisms. Whereas, for Mode 2 (or fast) IT organizations, the main focus is to deliver agility and speed, and therefore they act more like a start-up (or digital disruptor in HBR terms) inside the same enterprise.
However, what is often misunderstood is how fast IT organizations can disruptively innovate, when most of the information assets, which are critical to bringing context to any innovation, reside in backend systems, and any sort of access has to be delivered by the slowest IT sibling. This dilemma means that the speed of innovation is constrained to the speed by which the relevant access to core information assets can be delivered.
As the saying goes, "Where there's a will, there's a way." APIs could be implemented as a means for the fast IT to access core information assets and functionality, without the intervention of the slow IT. By using APIs to decouple the fast IT from the slow IT, innovation can occur more easily.
