How to build a good Enterprise API strategy

Taking the decision to put in motion an API strategy in your organisation is not trivial and many considerations and decisions need to be methodically unpacked, thoroughly understood and well supported from within the enterprise if there is any hope that the strategy will succeed.

API strategy is not just a concern for IT

What often occurs is that organisations view APIs and API strategy as a purely IT concern that doesn’t have an impact on the core business and its growth trajectory. A good API strategy has the potential to measurably affect the growth and prospects of an organisation from being able to create new products quickly, provide integrations between internal systems in the business, utilise datasets that were buried in the organisation in creative ways, engage with customers and enable third parties to easily integrate and leverage your services.

App developers are increasingly requiring access to enterprise data, products and services. This is driving enterprise API strategies in order to stay ahead on the playing field. You will find that you will face difficulties from within the organisation. People don’t like change and may question the value of investing in a good API strategy. These need to be overcome and may require an executive champion driving the process forward.

You will read everywhere that any API implementation must be treated as a product. This is important because all product undertakings in your organisation exist because they provide a business need, and as such require input and considerations at many levels within the business.

Typical organisational touch points

This process must start with effective leadership to drive the business need and get the right people from the organisation together to unpack and understand the various business and technical touchpoints that will be called upon. IT will then build the technical platform that will be the actual API service(s) that will physically support the business need and then the business will need to drive adoption and leverage the API(s) in a way that drives the business forward.

Mark Boyd API Evangelist at five by five wrote a fantastic series of articles regarding API strategy development and in that series, he illustrates the questions that you will need to answer on your

API strategy journey:

A big movement at the moment speaks to the concept of the modular enterprise, this topic is very far outside of the scope of this post but in a nutshell it specifies that an enterprise should organise itself into a series of strategic “building blocks” that can be configured in many ways and change easily as the organisation grows, allowing for agility in new, rapidly changing markets. If an organisation is arranged in a modular manner, it will lend itself easily to an API strategy as each “building block” will require an interface to get access to data and services.

Build the API Strategy Team

Before you can have an API, you will need internal support to pull it off. There needs to be a team of people that work with the business to understand their needs and processes.

An API strategy team can include the following roles:

• Product manager

Responsible for ensuring the product meets the needs of the business in order to deliver value to the organisation. This role will steer the development efforts to ensure only valuable APIs are built. They are the interface for the API team and the business initiatives, typically they understand the business very well and have a good grasp of technical feasibility.

• Product Engineer / API Architect

Responsible for technically designing the API with developers as end users in mind that translates the product requirements into an implementation that the API developers can extend and maintain. This individual should be the advocate for the end user which in the case of an API is always other developers.

• API Development team

Depending on the size of the organisation this could be 1 or more individual developers that will take the design and architecture laid out by the product engineer and implement the requirements as laid out by the product manager. They take lead and direction from the product engineer to ensure that his/her vision is adhered to.

• Operations

These team members are responsible for ensuring the day to day operations of the APIs in the business are running smoothly by maintaining technical infrastructure and hosting environments as well as telemetry analytics, usage and performance monitoring and reporting.

• Champion / Evangelist

Typically, an executive sponsor, an influential organisational head that can drive adoption and provide funding to the team to function optimally.

Define the API Governance Body and its responsibilities

The API team will be responsible for API inception, planning, implementation and bringing it to fruition. From a business perspective you will need to provide some level of oversight and governance to this process.

The governance body will be responsible for defining all the guidelines and procedures that need to be followed by the API strategy team, the strategy team will need to provide reporting capabilities to this body to ensure that guidelines are being followed. Important API governance functions in an enterprise can include the following:

• Tracking where in the organisation APIs exist and are hosted
• Tracking API consumers and the resources they are using
• Tracking API security
• Defining style guidelines and standards
• Versioning guidelines
• Schema versioning guidelines
• Tracking policies
• Change management
• IT Auditing
• Quality Assurance

Choose your first API

There are three types of APIs that you choose from, Partner, Private and Public APIs. All of them are useful at various stages in a good API strategy. First let’s quickly define these types and look at the possible reasons to choose each one.

Partner API

Enables your organisation to integrate easily with your external business partners. An example of this is a wholesale materials manufacturer sharing their pricing and shipping information with their distribution partners

Private API

Available only to internal products and services within the organisation. For example, you may have a Customer Relations Management system that is manual labour intensive and you’d like the CRM to be kept up to date with little human involvement, one way to do this is to put a private API in your organisation that enables other internal systems to integrate with your CRM platform.

Public API

A Public API is available externally to third-parties that want to use your data and services. You may decide to build a Public API if for instance the business need calls for external app developers to leverage your data and services to create new products and increase opportunities for growth.

Most organisations start with Private or Partner APIs to reduce their exposure and risk in the beginning of their API strategy, Partner APIs are great to start with as you can share the cost of implementation with the partners as the arrangement is often mutually beneficial.

Drive home an MVP

Identify the first API you’d like to build and drive an MVP (minimum viable product). This is the quickest and easiest path to delivering measurable value to the organisation. Think of this as an iterative approach to the full featured API. Take the following analogy, you need to build a Ferrari, the MVP product on the way to that Ferrari may be a skateboard. Not quite the Ferrari, but it has 4 wheels and is a mode of transportation, so it is a step on the way to becoming the Ferrari. The next step might be adding a seat or two, then a small engine and so on. Each step on the way is a vertical slice of value that is usable and iterates on the solution.

In order to deliver the MVP to your API users(developers) there are a couple of very important technical decisions that need to be made. These involve the Architectural decisions both in terms of technology and infrastructure.

Technology Decisions

Technology decisions relate to the physical implementation of the API, the nuts and bolts code implementation as well as parts of the infrastructure and tooling. They revolve around stack choice, and third-party providers for certain aspects of the API

Questions include:

• What API specification are we going to use?
• What language are we going use to build our API?
• Are we going to build the administration, support and reporting aspects of the API alongside the API development or implement them once we have a running API?
• Do we build a RESTful API or go with a SOAP service? Do we need to cater for both?
• Do we need an ESB (Enterprise Service Bus)?
• What are our targets in terms of scale and performance?
• How are we going to test the API?
• Are we going to use an off the shelf API management Platform or build our own gateway?
• How are we going to gather telemetry and monitor usage and health of our API?
• How are we going to deploy, manage versioning and sunset of the API?
• Are we building clients to consume the API?

Key to answering these questions is understanding your capabilities in the organisation. It makes no sense for example to commit to building an API in the MEAN stack if your development teams are predominantly specialised in the JAVA space.

These decisions are taken within the API strategy team, specifically the project engineer and developers are best positioned to identify the right questions and answer them for your organisation.

Infrastructural Decisions

The APIs need to be hosted somewhere and supported. These decisions will be driven by your internal organisation policies and often mandated through government compliance demands. Some questions may be:

• How is authentication and authorisation going to work?
• Do we go into the cloud or keep it on-premise or maybe we keep some of it on-premise and other parts in the cloud? E.g. We may host the API in the cloud, but we keep the data safely on premise behind our firewall.
• If we go with a cloud offering, which provider?
• How do we mitigate vendor lock-in?
• Do we have compliance issues regarding cloud hosting?
• What is the SLA and support agreements with the cloud provider?

Securing your API

Creating an API is like adding a door to your house. It is convenient but if left open it can invite all manner of unwanted problems into your home.

Your API strategy must treat API security with the utmost importance. API security warrants a post all on its own but Yuri Subach offers his take on security principles from his book “API Security”:

Key Factors of Information Security – CIA

Confidentiality, integrity and availability also known as CIA triad (or AIC triad to avoid confusion with the Central Intelligence Agency) are three key factors used for high level security design. These factors are not directly related to the computer security, they are known from other security related domains (like military) and been used thousands of years ago.

Confidentiality

Confidentiality is a set of rules that limit access to the information. It means data must be available for authorized users only, and protected from unintended recipients during transit, processing or at rest.

Integrity

Integrity is the assurance that the information is trustworthy and accurate. It ensures that data is protected from intentional and unintentional alterations, modifications, or deletions. Important feature is reliable detection of those unwanted changes, if they happen at any stage of data lifecycle.

Availability

Availability is a guarantee of reliable access to the information by authorized people. This factor involves not only security aspect of the system, which still is very important. It also imposes availability requirements to the infrastructure and application levels, combined with appropriate engineering processes in the organization. You can read more about this on his Blog listed in the citation below.

Security of the API does not end at the access point of your API. Adopt an End-to-Endpoint approach to security, this involves, transport and transaction security, validation and authorisation at all layers in the chain from data to consumer of the API.

If you are diligent and follow OWASP guidelines you can minimise your attack vector and keep your data safe.

Driving adoption of your API

Depending on the type of API there are a few ways you can drive adoption. In the context of a Private API you can force adoption through corporate policy. Doing this will get your API used, but you can do more to make the developers’ experience a pleasant one. I’ll talk about ways to do that in a bit, first let’s cover the other 2 main types of API.

In the case of a Partner API you will need to focus on your business partners as they will need to adopt your API. Focus on the benefits that will be seen by your partners by adopting your API. E.g. by adopting the API, they no longer must send an invoice via email to the procurement office, they can now submit directly through the API. If the API makes the partners’ job easier, focus on those points.

When trying to drive adoption of a Public API, the strategy is to get out and tell external developers about your API. This could be a marketing effort or targeted directly at 3^rd parties you wish to work with. This can be achieved by hosting hackathons using your API and going to developer conferences, getting exposure for you API’s offering wherever It makes sense for your business.

These approaches may engage developers initially but there is work that can be done to make using your API as easy for developers as possible. Offer self service registration platforms for developers to start using your API. Ensure you have great documentation detailing how to use it effectively. Many API management platforms offer self-service developer portals as part of the platform. Offer development support using your API strategy team to partner with and guide developers to use the API.

Measuring the success of your API

Simply keeping track and counting how many calls are made to your API is not enough to accurately measure its success. Keep in mind that the reason the API exists is because it is a product that was built to solve a business need. If, for example, you have built an API for your manufacturing services and that API is used for ordering and distribution, if that API registers thousands of requests a day to get pricing information but very little when it comes to ordering those products can you call it successful?

In this scenario I would say no. Even though the API is used a lot it is not resulting in increased orders through the API.

Understand the goals of the API,

Using the previous example, a good KPI for this API may be number of pricing requests that were converted to orders through the API. If there were 100 000 pricing requests that result in 80 000 product orders you could see that as successful as the API directly influenced revenue. Seen differently, an API may not need to be called millions of times to be successful if the times it was called resulted in its stated goal.

If you understand the clear business reasons for your APIs existing, then you can apply well thought out KPIs for them that are not exclusively based on the number of times it was called.

Closing

Defining your API strategy should not be a task for your IT team, they are one link in the chain to having a good API strategy for your organisation. All APIs in your organisation must exist to solve a need in the business and as such need to be treated as products that need as much attention as any other. Invest in a strong multi-disciplinary API team from business to technical that can make your strategy a reality and offer them support in the form of executive influence. Define valuable KPIs for your APIs and only focus on the ones that support the need that they were designed to solve.