Why Your API Strategy Requires Lifecycle Thinking

The social and mobile revolutions have created massive new channels for companies that publish their services as APIs. The idea is to enable developers to utilize your services to add value to their new applications. When they do, you gain access to vast new user communities for building brand, driving usage and transacting business through "in-app" features and offers.

When developers leverage your APIs, your services have the potential to go viral. When your services go viral, new channels are born—and your business can grow like a weed.

But executing an API strategy isn't as simple as hanging a shingle on the web.

The reality is that, too often, an API strategy is executed as a Field of Dreams:

"If we build it, they will come."

Truth is, developers won't necessarily show up—or stick around—unless you execute an API strategy with the rigor of a true product lifecycle.

The Universality of a Lifecycle

Imagine if your product and go-to-market strategy were a slapdash combination of half-measures. Imagine if product requirements were little more than hallucinations, your sales and marketing strategy was based on hope and prayer, and your service level assurances were anything but.

Of course, you wouldn't run a business that way. But many companies apply this level of attention to their API strategy. The truth is that an API is a product with a lifecycle that must be managed, not unlike the commercial products that ring the cash register for your company.

Anatomy of an API Lifecycle

Organizations looking to capitalize on the promise of the API Economy should implement strategies for managing the full life-cycle of APIs, from conception to retirement.

The four basic stages of your API lifecycle include:

Plan — like any good product, APIs must begin with validated requirements that dictate a solution to a real need. Your APIs should deliver substantial value to your target audience. In addition, you need to clearly understand how you capture value for your business once your APIs are adopted. How does the design of your APIs support your own business objectives?

Build — to ensure adoption, your APIs should be built as atomic elements designed for reuse in a variety of use cases. They must abstract the complexity of underlying code, providing interfaces that can be programmed by mortal developers and they should convey and enforce a clear service level agreement that ensures trust between provider and consumer.

Run — your APIs should be manageable, robust, secure and performant. They should support a wide range of use cases. After all, part of the value of an API strategy is allowing the community to discover powerful new applications for your services. Don't constrain that. Additionally, your APIs should support the sort of massive scale that comes with viral usage.

Share — simply creating whiz-bang APIs isn't enough. You need to attract and cultivate a community of developers to consume your APIs and become raving fans. In addition to all of the expected artifacts — documentation, use case examples, code samples, etc. — you need to provide community forums and other resources for troubleshooting, problem solving and collaborating on new ways to use your APIs. It's often said that, when it's executed correctly, customer support can be your best sales force. Of course, the inverse is also true.

When organizations recognize that APIs are products unto themselves—not marginal adjuncts to the core commercial offering—an API strategy can flourish. Without this sort of rigor, publishing APIs often becomes a wasted effort—an elusive field of dreams.

What's at stake? A brave new world of opportunity to engage and transact over the social and mobile web. Companies that get this right have the potential to put growth on overdrive.

Today, Salesforce.com generates more than half of its $2.3 billion in revenue through its APIs, not its user interfaces. Twitter processes some 13 billion transactions a day through its APIs. Google is around 5 billion transactions a day. Amazon is rapidly closing in on a cool trillion.

The "Other" API Economy

But an API strategy isn't only for the coolest kids on the block; it applies equally to traditional enterprises, from discrete manufacturing, transportation and logistics to insurance companies.

An API strategy is particularly important for traditional enterprises that face a new set of competitors and market innovations that threaten to disrupt their traditional business models.

For example, how do traditional financial services institutions participate in online commerce? How does the automotive industry deliver intelligent experiences within their vehicles? How does an airline tap into online travel sites and reservation systems? How does an old-line luxury brand sell surplus merchandise through "flash deal" websites?

The answer is through a rich set of APIs.

While the API opportunity is wide open to organizations of all stripes, these large enterprises have their own set of challenges. Security, compliance, integration with mainframes and other legacy systems, user and identity management and ensuring fault tolerance, performance and scalability in support of enterprise-class SLAs are just a few of the unique challenges the largest companies face.

But for all companies, the common attribute of a successful API strategy is deep lifecycle thinking, which handles programmatic interfaces with the same rigor as features in a UI, and treats developer communities with the same consideration paid to traditional customers.

The result is an API strategy that resembles a product strategy, where the goal is to drive business. You might say that APIs are really just products in geeks’ clothing.

We shouldn't treat them as anything less.

About the Author

Roberto Medrano is executive vice president of SOA Software. He’s a recognized executive in the information technology fields of SOA, Internet security, governance, and compliance, who has been selected as one of "The 100 most influential Hispanics in US," and "Top 100 most influential Hispanics in Information Technology." He holds an MBA from UCLA, a MSEE from MIT, BSEE from USC. For more information on APIs see Roberto's blog at http://blog.soa.com/.