Successful execution of an API strategy requires forming a solid link between business strategy, technology implementation and culture and process.
The rise of platforms such as Amazon, Google, Apple, Facebook and Alibaba, and their disruption of industries such as media, music, publishing and retailing have led many established enterprises to consider how to position themselves for growth (or even survival) in the digital era.
As described in my previous article about Open Banking, a combination of opportunities, changing market landscape and regulatory mandate has led financial institutions to embrace APIs.
Across industries, firms are trying to figure out how to:
- Build API capabilities that support their business strategy and core competence
- Better meet existing customer needs, while positioning themselves to address as-yet-unknown customer needs or emerging business models
Motivations for building and publishing API-enabled services include:
Internal collaboration and agility
- Omni-channel customer experience (a seamless experience across digital and physical channels)
- Drive cross-sell to customers across lines of business
- Promote re-use of technology assets
- Enable rapid prototyping and experimentation
- Increase speed of product and service development by enabling teams to use services from other teams quickly, and without requiring detailed knowledge of them
- Aid the upgrading or replacement of legacy technology by placing an intermediate layer between it and other systems
Accelerating Partnerships and Alliances
- Distribution channel partners (agents, affiliates)
- Supply chain integration
- Integrating industrial machinery (example: GE Predix)
- Sharing aggregated data from complementary sources (an example is the recent partnership announcement by OCBC bank and telecommunications carrier StarHub)
Joining or Becoming a Platform
- Gateway (pay-per-use) – charge 3rd party developers for access to APIs
- Subscription – selling information services using aggregated data
- Selling into an existing Marketplace. Examples include: E-Commerce (Amazon, Alibaba), Insurance (Health.gov), Cloud Computing (AWS, Azure, Google Cloud Platform)
- Become a Marketplace – connecting buyers and sellers (examples include Google, Amazon, Apple, Facebook, Uber, AirBnB, Alibaba)
The firm’s motivation determines whether to build Private (internal to the firm), Partner (shared only with trusted partners) or Public APIs.
While becoming a Platform (being at the centre of your own marketplace) can be attractive, getting there in one step is a tall order. The rich functionality, security and robustness required of a publicly available platform is achievable only by firms that have put their internal systems and processes in order.
A logical roadmap, therefore, is to start by publishing Private APIs, learn from the experience, then progress to Partner and Public APIs as their value is proved and the organisation learns how to sustain and manage them.
1. Define Your API Strategy
Getting on the Executive Radar
Show how APIs can support the business, innovation and information strategies.
Any initiative requiring change to technology, processes or culture requires support from the top. Pain is seen almost immediately, but benefits may take time before they are realised. Gaining sponsorship requires executives to believe in the vision and to stake their
A strong example is the directive by Amazon’s Jeff Bezos in 2002, mandating that all teams must expose their data and functionality through service interfaces, and must communicate with each other through these interfaces.
This top-level commitment needs to be reinforced across all levels and functions (not just technology) if it is to gain traction.
Prioritisation
Focus on capabilities that will move the needle on revenue, costs, agility or options for the future.
Prioritisation of API efforts needs to be based on the firm’s motivation, balancing prospects for short-term gains with building capabilities for subsequent extension.
Funding
Fund the building of a foundation capability in order to ease adoption, but structure it to become self-sustaining over time.
If an enterprise requires a lot of foundational investment before APIs can be used, this may need to be established centrally. This runs counter to the idea of fostering autonomy among dispersed, agile teams, so the size of this investment should be just enough to kickstart broader activities. Ideally, once the API foundation has been laid, the API ecosystem will become self-sustaining. Then a smaller centralised funding component could focus on fostering the API community rather than building out infrastructure.
Measures of Success
Define metrics that encourage applying to the things that matter: revenue, costs, agility (speed of deployment), adoption and re-use of assets.
Measures of success should be based not on the number of APIs published, but on how well they support the firm’s priorities. Good API measures resemble good measures of innovation:
- Financial returns (Cost Savings, Process efficiencies, Incremental revenues)
- Productivity Levels – priming the pump (Ideation volume, Engagement levels, Projects launched, HR-oriented measures, Functional metrics, Board-level consideration
- Portfolio Health – reaching a higher gear (Customers, Technologies, Ecosystem)
- Activities Mix – securing the future (Trend scouting, Incubation, Co-creation, Scale-up)
2. Internal Collaboration and Agility
Building a Community
Gather people from diverse backgrounds to address common challenges.
Successful execution of an API strategy requires building a community of supporters inside and outside the firm. This needs to happen at senior and junior levels, as well as among technical and non-technical disciplines.
For technology consumers in the lines of business, or specialist functions such as Marketing, Finance, Human Resources, appreciation must be made that contributing to an API ecosystem is a case of enlightened self-interest. Publishing APIs encourages others to use your services more, and to do it in a standardised way. This makes it easier to monitor and measure the value your business unit provides, and can also help support functions allocated costs among consuming departments. For profit centres such as product, segment or geographic business units, this can aid the cross-selling of their products or services by other departments, growing both their revenues and the group’s as a whole.
Developer Evangelism
Educate and inspire developers and API champions.
Technology vendors long ago established the role of developer evangelist: technical experts capable of guiding partners and customers in the design and deployment of new technologies. Increasingly, enterprises have seen the need for the role of API developer evangelist to inspire, coach and teach developers and other participants, and show them how APIs can form a key part of their solutions.
The Legacy Quagmire
Navigate through or bypass the complexity of older technologies by exposing services through APIs using adapters or wrappers.
APIs enable collaborators inside and outside the firm to use a service without needing to know how it works internally. While older generation monolithic systems may not lend themselves to this component-based way of operating, adapters or wrappers can be built to expose key functions as a service.
When a new need is identified, development teams should start with the presumption that “there’s an API for that”, and explore which existing APIs could be used to jumpstart their project. Where there is no existing API that performs the required functions, the team should be incentivised to build an API in such a way that it can be utilised by others. Over time, the portfolio of APIs will grow to encompass the majority of functions. This in turn enables the underlying legacy systems to be upgraded, replaced or retired without requiring wholesale changes across the firm’s technology landscape.
Bridging the Data Lake
Expose the firm’s information assets to enable evidence-driven decision making.
APIs simplify the way data can be provided to both internal and external consumers. By encapsulating data in a service, defining how it can be requested or changed, and by whom, consumers can access data using their tools of choice, without needing to know the underlying storage technology. Firms that have implemented an enterprise information strategy can realise its full potential by providing it in a way that can be accessed more universally.
Assembling the API Layers
Build a suite of re-usable services at different levels of granularity to serve the needs of developers across the technology stack.
APIs serve functionality across three layers:
- Experience APIs: Purpose-built APIs for apps
- Process APIs: Orchestration, composable APIs, Microservices
- System APIs: Legacy modernisation, connectivity to SaaS apps, web services and RESTful APIs
The technology industry has seen several generations of Service Oriented Architectures, so many firms have an established Process layer, albeit with a mix of technologies and protocols that may not be easily exposed to front-end applications or partner organisations.
One way is to place an API Gateway above this Process layer. This presents a standardised interface to consuming applications, while leveraging the firm’s investment in existing technologies.
Another way, particularly for firms in industry sectors with established communication standards, is to offer APIs using the particular conventions in use by that sector.
Saxo Bank, specialising in multi-asset trading, has published Open APIs in the most popular current technology, Representational State Transfer (REST). But many financial market participants have long-established technology systems and processes based on the Financial Information eXchange (FIX) protocol. For these partners, Saxo has published a FIX API, as well as APIs for event notification and end-of-day file transfers.
Tools
Build tools to make it easy for developers to produce and consume APIs.
A Developer Portal should include clear documentation, sample code and tutorials. This enables self-service, and the opportunity for developers to upgrade their skills to make full use of the API facilities. It also provides a focal point for the user community to help each other, or request assistance from developer evangelists and power users.
Sandbox
Provide a safe environment for developers to build and test applications using APIs, with working representations of APIs and data.
An API Sandbox is best described as “a platform that allows users and non-users to make and view the results of simple calls in a closed, walled-garden approach”. Developers learn by doing, and can test their code before building out all the functionality of their applications. This accelerates development by making the coding activity more interactive. It also enables the firm to provide test or dummy data initially, and only provide access to fully-functioning systems later in the development lifecycle.
Security
Protect sensitive functions and data, while providing appropriate access and separate areas for authorised participants.
Even within the firm, security controls are required to ensure that critical systems and data are protected. This become even more important when they are exposed outside the firm.
Industry standard security protocols enable security, and ensure that authorised external and internal users alike can access functionality in familiar ways.
Governance
Ensure technology assets are used effectively and efficiently, while providing teams with sufficient autonomy to produce their best.
A firm’s technology governance has a role to play in fostering and sustaining the API ecosystem.
While allowing teams the autonomy to produce APIs as they need them, the downside of this is the proliferation of APIs far beyond what is . There must also be oversight to ensure. Achieving the optimal balance between autonomy and control depends on individual circumstances, establishing governance principles and policies can provide appropriate guardrails for developer activity.
Lifecycle Management
Manage APIs from birth to retirement.
Like other technology assets, APIs need to be managed throughout their life. While an API’s purpose is to de-couple user’s needs from underlying system architecture, there will be times when new requirements necessitate the updating of APIs. Version control needs to be applied to ensure that API consumers are accessing the correct version, and that users are migrated off older versions so they can be retired. Measuring API usage can also identify APIs that have outlived their usefulness (or did not gain sufficient utilisation to justify maintaining).
Monitoring and Measuring
Monitor APIs usage to manage availability, performance and scalability. Measure API usage to understand which ones provide the most value, and who is using them.
The advantage of funneling activity through APIs is that their usage becomes easier to measure. An API gateway becomes more than just a traffic cop – it becomes a repository of activity tracking data. The firm can use this to measure and optimise operations, but also gains a better understanding of which assets are contributing the most to the firm’s profitability.
Analysis of this tracking data can provide insights on:
- Which systems are contributing the most to key business activities
- Which systems are suffering from performance bottlenecks
- Which systems are declining in usage, and should be either upgraded, migrated or retired
- Which teams or departments are using systems the most (can aid in apportioning costs across user departments)
- Which types of API to encourage or invest in
3. Build Partnerships
The firm can expose APIs to trusted partners to engage in projects, innovation challenges or hackathons to develop new product and service offerings.
Partner Business Models can include:
- Lead sharing
- Revenue sharing
- Affiliate commissions
- Data sharing
Co-Creation
Combining the capabilities and resources of the firm and its partners to deliver new solutions to customer needs.
All the elements that go into a robust Private API capability are required when co-creating with trusted partners. Appropriate security controls can ensure that only the functionality and data that is agreed can be accessed by the partner.
The LEGO Paradox is that a standardised system of building blocks, far from constraining creativity, actually encourages it. It gives creators a starting point. They don’t need to re-invent basic functions that have already been created, so can focus on recombining, extending or adding to them to create new solutions. Isaac Newton said it best: “If I have seen further, it is by standing on the shoulders of giants”.
4. Joining or Becoming a Platform
Going public opens up your firm to the world, with all the risks that entails. User and developer experience, platform stability and performance, and security of the firm’s IT infrastructure, critical systems and customer data are best addressed internally first.
Joining an Ecosystem
Be a “plug and play” service in someone else’s platform.
While the platform owner will enjoy the most benefits. As the hub, they will gather data enabling them to understand customers across the entire ecosystem.
But there is the risk that, if you don’t participate, someone else will provide that service instead of you, possibly even the platform owner themselves.
Examples of firms enabling “plug and play” include:
- Mapping information providers: Google Maps, Microsoft Bing Maps, HERE, Mapquest
- Payment processors: Visa, Mastercard, PayPal, Stripe, and Alipay
Become a Marketplace
Be the centre of your own ecosystem by connecting producers and consumers of products and services
The modern day shopping mall concept is successful because the mall operator takes care of all the physical needs for customers and sellers to meet:
- Customers know where they will find sellers
- Sellers know that there will be customers coming to view a variety of products with the intention to buy
- Customers can travel to the mall on either private or public transport (and park if necessary)
- Sellers can focus on their core capabilities while the mall owner provides the infrastructure of power, air conditioning, water, toilets and other facilities
In technology services, Amazon Web Services (AWS) provides a Marketplace that enables Independent Software Vendors (ISVs) to reach new customers easily through:
- Streamlined Product/Service Delivery
- Discovering New Customers
- Simplified Billing & Payments: metering, billing, payment collection and financial reporting
- Product Support
Before deciding to become a marketplace in their own right, firms should consider:
- Will customers come to you looking for solutions beyond what you can immediately provide?
- Are there others who can extend your core offering?
- Can you host their solution on your platform?
- How do you offer them the opportunity to reach more customers?
- What business model can you offer?
Where it goes from here
Open APIs are not a “one and done” story. The portfolio of APIs, Private, Partner and Public, across all layers (Experience, Process, System) need to be continuously reviewed and enhanced to meet the evolving needs of firms and their customers.
The true beauty of Open APIs is the options it creates for future uses of a firm’s services and data, internally and externally, that have not previously been imagined.Addressing both near-term challenges and opening up future possibilities make APIs an integral part of building an organization that is more agile and responsive to customer needs.
Source: jonscheele
