How to get the team and support in place for your API strategy

Our first decision was to make sure the business and technical leaders within an organization are collaborating and that they collectively understand the need for an API strategy. Together, these leads can start defining who the key users of your API will be and map the customer journeys they will follow from discovery to ongoing use.

Now you need to continue building internal support. This will involve creating a team that can liaise with various business units to document current processes and to map how the IT architecture enables line of business workflows, in order to better understand how to organize building internal APIs and how to identify external APIs that can help automate and enhance existing processes.

Kirsten Hunter, author of Irresistible APIs and API Evangelist at Akamai Technologies, says when building internal organizational support, "The most important thing, the very first piece is to figure out what your business value is. If you don't know why you have an API, it's not likely to succeed."

Hunter gives an example of using a social platform when "perhaps you want to increase the usage, or increase the number of places people can interact with your system." She says that "the biggest business value is often customer stickiness: when [developers] choose to integrate with your API, they are less likely to move to a competitor."

Once the goal for building APIs has been articulated, Hunter says the second thing to think about is metrics. "This is critical when speaking with executives," she says.

"With developer stickiness, you may be looking at number of clients making calls or at increased usage of your API; there are a number of ways to measure against the goals that you have set," says Hunter. "You can look at traffic, the number of unique clients consuming your API, writes versus reads to the system, or measurements of user behavior. For most APIs that are not the main product of the company, monetization will not be the right path," Hunter says. She suggests steering away from adding this as a metric to start. "It can stifle creativity and reduce the amount of integrations that are built consuming your API. It is often better to think of your first APIs as value-add," she says.

Once you know which metrics that matter, make sure not to lose sight of their role in your on going strategy and, more importantly, what technology must be in place to present those metrics in dashboard form.

Marc MacLeod is founder and CEO at API lifecycle tool Stoplight.io . He sees businesses first start using their API design tool when they want to move from having an individual API to "getting their API strategy under control."

"Usually what we see is that a business might have an API and are beginning to think more about an API strategy because they are experiencing some of the pain points in their API lifecycle: Problems with maintaining documentation or in monitoring their APIs," say MacLeod.

Stoplight is an API tool that allows engineering teams to maintain a single point of truth for their API, and it provides a number of interfaces so developers can use it more efficiently. They can work on the design and code in one display, while other business units like customer support can use a different interface that makes the most sense for supporting end customers using the company's APIs. Because of their market focus, MacLeod says StopLight usually first encounters API technical leads who may be evaluating various industry solutions. But from speaking to these leads, he sees that they often struggle with getting a broader understanding of APIs across the organization. "Typically it is forward thinking with the technical lead," says MacLeod. "It is not easy to have business people thinking, 'If we did this with our API then we could create these new partnerships,'" he says.

Instead, what he finds is that tech leads need to make the pitch to the business for investing in a wider API strategy. The argument for building internal investment and support usually follows two main arguments, says MacLeod: "For internal APIs, the pitch is about having less buggy code, having better quality, and being more efficient. For public-facing APIs, the pitch is about maintaining documentation and developer resources to make sure they are accurate and functional, so the business can increase partner adoption of their APIs," he says. MacLeod adds that often the starting point for architects championing an API strategy is during the building of internal support, but that as the discussion becomes more business-focused, the pitch starts to target "a much higher level of what the goals are and how can we describe the metrics."

As a business concern, when starting an API strategy journey, a number of key decisions that impact on the business overall surface. Not all of these will happen at once. For example, throughout this series we look at key issues such as:

• Which data and assets should you open up first and how do you decide who has access to what level of data and services via API?
• How will you use technologies like OAuth and other identity access management and authentication tools to manage API access?
• How do you introduce API management for limiting the number of calls that developers can make on your API?
• How do you price your API?

All of these issues are commonly referred to as API governance concerns. You will need to build internal support across the organization for your API strategy. And as discussed below, you will need to build an API strategy team who will help you steer your API through its initiation and implementation. However, at a high level you may also need to set up an API governance body. This will involve business and technology managers who have the oversight and authority to make key decisions and who should have access to the data and assets you are exposing via API (that is, authentication and authorization). This governing body will also help review your security decisions and your monetization strategy.

The roles and responsibilities of an API Governance body can be documented in a terms of reference. The governance team may only need to meet on an occasional basis to make high level decisions around the business direction of your API. Day to day management and implementation will be handled by your API Strategy team.

As far back as the late 1960s, computer programmer Mel Conway noticed that when architecting software solutions, the software ends up mimicking the organizational structure (and especially the team communication channels) surrounding those who built it. More specifically, he stated:

"Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations".

This is called "Conway's Law ."

How we present and organize ourselves speaks to what we are trying to achieve and is often both the key enabler and constraint.

Having the right team together to create an API strategy will impact on its success. Again, having both technical and business involvement in an API strategy is crucial if the API strategy is to be a cross-organizational concern and not just a technical implementation.

Hunter suggests that a typical API strategy team should include the following roles:

• "You need to have a Product Manager
• for the API who understands the business' main product, and how the API is going to support that main product and increase the value of that main product."
• "You need an engineering manager."
• "You need someone super-focused on developer experience. Someone needs to be a champion for the API internally".

Régis Martin, of the API consultancy Wildnode, has worked with a range of enterprises on their API strategies. He says that the team composition will depend on the business case, whether that be a focus on innovation, launching new products, or re-architecting the IT infrastructure. But regardless of the business case "you will need to bring together business people, marketing and IT," he says.

Martin also recommends that teams be encouraged to have a "startup mentality." He says this sort of environment helps retain talented programmers and encourages software development to think about the value they can bring to the overall business.

People are part of the system we build, not apart from it," says Mike Amundsen, director of API Architecture, for the API Academy at CA Technologies. He recommends that teams aim to introduce chaos into their system thinking to encourage innovation and create the sort of creative environment needed to reorient an entire organization towards a more digital transformative agenda.

Amundsen references Ori Brafman's five rules of chaos to suggest how an organization can encourage team innovation from the outset. This includes:

• Strong leadership that can allow team members to experiment within clear boundaries ("organized chaos")
• Allowing space for thinking beyond "the lure of data and measurements"
• Allowing team members to have time for "productive whitespace," which is time to reflect or daydream when working towards a deadline
• Encouraging participation "beyond the usual suspects" by actively seeking out team members or expertise that the group does not already have
• Creating an openness and flow of ideas that fosters serendipity and chance connections amongst team members.

As you embark on your API strategy, two key decisions need to be made: how will you build cross-organizational support and what will your team look like? Once you have selected your team members, you can then follow some of Martin and Amundsen's advice for fostering the right sort of innovative culture that will propel your team forward as they grapple with the next key decision in our chart (above): Which data and services to open up as APIs first?

Spotify and Buffer are both technology companies that are building their services using microservices and API-first structures. Both need to manage applications at scale, to be available 24/7 to their users, to have a constant feature-driven roadmap, and to be able to integrate with a wide range of external and partner services.

How these two organizations organize their teams is instrumental to their success with APIs.

Spotify works in small squads to maintain a lean startup mentality. Each squad is autonomous and responsible for a particular aspect of the overall Spotify product. Squads then work in a collective of teams called a tribe, which may be responsible for an overall component of the Spotify app; for example, the music player component. On a larger scale, tribes may have cross-cutting chapters and guilds that focus on skills that are similar across squads, so that regardless of the component-focus of the squad and tribe, standards and best practices are shared across the entire app. This helps with managing the application as it grows at scale.

Henrik Kniberg and Anders Ivarsson have written in detail about Spotify's team organization and two videos are available that detail their culture and team composition.

Inspired by this, social media app Buffer has looked at their own team composition and organizational arrangement, and it has sought to find the optimal approach to building a complex, highly distributed application in a global marketplace. Courtney Seiter writes that Buffer has reoriented their organizational structure at least four times in order to find the best way for teams to work together. Seiter says that part of the solution has been to organize into squads as well, but sees Buffer's journey as an evolution that has not yet finished into the perfect arrangement.

Resource List

• Irresistible APIs: Designing web APIs that developers will love
• Stoplight.io
• Ori Brafman and Judah Pollack on "The Five Rules of Chaos"
• Spotify engineering culture (part 1)