The Business of API Design
Why smart companies coordinate the business and technical aspects of their API strategies.
Business is Technical These Days…
The term “application programming interface” sounds pretty unappealing—like something that might be going on in a server room somewhere, which is probably best left to the IT folks. But in an age when creating engaging Web and mobile experiences is ever-more important to organizations across all sectors, these technical details can’t be left to chance. That is to say, business success today can hinge on some apparently arcane technical details.
This is why people in line-of-business roles are showing more and more interest in APIs. They’re becoming increasingly knowledgeable about how an API makes it possible to leverage existing IT assets in order quickly and cheaply make new Web and mobile apps. Whether these stakeholders come from a technical or business background, they know they need APIs, right now!
…So the Business Strategy Impacts the Technical Details…
Spare a thought for the enterprise architects charged with actually delivering the interfaces themselves. Opening up backend systems via an API is not, in and of itself, a huge technical challenge. But making sure that API doesn’t impact the secure, efficient running of the systems exposed is another matter. There’s a lot at stake here and it’s vital that—in the rush to be quick-to-market with an API—little matters like security and reliability aren’t forgotten.
Of course, if you happen to be one of those poor-old architects, you yourself should spare a thought for the program managers charged with making sure the interfaces you build actually add value to the business. Your API could be wonderfully technically elegant, but if it doesn’t empower developers to create Web and mobile apps that generate real business value… well, who cares? Of course, this only adds to the architectural challenge.
…and You Can’t Separate the Two!
The point is it’s vital that all stakeholders understand that the business goals and technical challenges of an API program are intimately related. Program managers must clearly communicate the key goals of a proposed API to the architects who will actually build the interface. The architects, meanwhile, must take responsibility for ensuring that all their technical decisions are focused on making a real contribution to those business goals.
Typically, a technical project within an enterprise will be driven by IT and focused on improving organizational processes. API programs are different because they actually exist to increase business revenues. Therefore, API design decisions must focus clearly on the core strategic business aims of the company’s API program. Before initial API design decisions are made, all of the business and technical stakeholders must understand the goals of the program and how these may evolve over time.
There’s a lot at stake here and it’s vital that—in the rush to be quick-to-market with an API—little matters like security and reliability aren’t forgotten.
— Sam Macklin, marketing communications analyst, CA Technologies
Designing an API for Business Success
Stakeholders must agree on answers to broad technical questions: What systems will the API expose? How will it do so? They must also agree on fundamental business considerations: How can developers be motivated to build applications against the API and how will these apps add value to the business? The app is the point where business and tech considerations intersect. The central question is: What kind of apps do we want developers to build against our API?
Naturally, communication and collaboration are essential to answering these questions. Furthermore, open communication and close collaboration must continue throughout the process of designing, deploying and managing an interface. Program managers and API architects must work closely to ensure they agree on their core strategic goals, what they will do to achieve these goals and how they will evaluate the outcomes of their efforts.
More specifically, business and technical roles must be in agreement on the core objectives of the program, the initial tasks that will allow the organization to work towards these objectives, the key metrics that will be used to measure success and the ongoing day-to-day tasks that will allow the program to keep hitting its targets. At this point, you’re probably wondering if/how it’s possible to get business and technical types to consistently agree on this much stuff.
Enter the API Evangelist
To ensure business managers and architects stay on the same page, an API program should ideally have a “sponsor” able to span the divide between technical departments, business managers and app developers. Organizations often make the mistake of assigning this role to a non-technical marketing manager, but this “API evangelist”, must be able to understand the organization’s architectural constraints and share the enthusiasms of app developers.
The evangelist’s role is to establish communication with all stakeholders in order to “sell” the API program to senior decision makers, ensure API architects understand program managers’ business goals, help program managers understand architects’ technical considerations and gather information on target developers’ preferences. In this way, the evangelist facilitates the design of an API that will actually meet the company’s business needs.
API Strategy and Architecture: A Coordinated Approach
That still leaves the architect with a lot of technical decisions to make about API design. While people in line-of-business roles don’t necessarily need to know whether an architect has chosen to adopt a “pragmatic REST” or “event-driven” design style (or even what any of that actually means), it is important that fundamental decisions like this are made with the agreed-upon business goals in mind.
Take an example from a telco company. When the company’s architects heard they would be designing an API, they assumed this would involve exposing hard-to-reach legacy systems through RESTful Web APIs. Before they went too far, program leaders communicated that it would be more valuable for the company to design APIs that would streamline their partner onboarding process and open up core services like SMS and billing to these partners.
For a deeper dive into how API strategy drives good API design, including details of specific design styles, take a look at CA’s API Strategy & Architecture: A Coordinated Approach eBook. Even if you’re a purely line-of-business individual, this is a worthwhile read. You may not necessarily need to know what pragmatic REST is, but—given the amount of cross-departmental cooperation and understanding a successful API program requires—it couldn’t hurt.
Sponsored by the Council for Technical Excellence (CTE).