APIs: Why You Need A Strategy Now

Download the entire November 2013 special issue of InformationWeek, distributed in an all-digital format (registration required).

APIs aren't used by just mobile application developers, though mobility is one reason we're suddenly waking up to the possibilities of the once-lowly application programming interface. They're also critical for connecting your business with partners, suppliers, and cloud providers, particularly if you use a lot of software-as-a-service.

Is software-defined networking in your future? Arista, Cisco, Enterasys, Juniper, and other networking vendors expose rich APIs to automate network operations. Amazon.com built its business on exposing data and functionality through interfaces that it could, on a dime, extend outside the company.

There must be a business case for developing APIs, and we'll discuss what they can do for you. But IT organizations also need a back-end plan: How will you expose your data? Which protocols and middleware should you support? How can you share APIs with outside parties securely, and how will you guarantee performance? The first thing your organization needs to do is formalize API management and think about security. Some shops are already making headway; we'll discuss programs by AT&T and Bechtel. Cloud providers and standards bodies are in the thick of planning -- Randy Bias, CEO of Cloudscaling, and Boris Renski, CMO and co-founder of Mirantis, recently debated the wisdom, or lack thereof, of focusing on those Amazon APIs for the OpenStack project. We'll dig into how APIs got to be the center of the software universe.

On the rise
Like most IT movements, necessity was the mother of API invention. Development pioneer Edsger Dijkstra dubbed it the "software crisis" -- as hardware gets more powerful and technology more intrinsic to business, development complexity increases in lockstep. The result: late, over-budget, unmanageable software of questionable quality. In response, programmers started breaking massive blocks of code into component-based chunks, from Unix's pipes to Corba (Common Object Request Broker Architecture) to service-oriented architectures. Across each era, the goal was the same: to keep units of code small so that developers could find errors and do updates more quickly and easily. Despite some pain -- Corba and the strict SOAP standard, for example, are complex and costly to implement -- enterprises generally came to agree that component-based coding is an improvement over monolithic software development.

Then something unexpected happened: Consumer-facing web companies saw the potential to scale their businesses to tens of millions and then hundreds of millions of users, but they needed ways to ramp up quickly. One popular method was to declare yourself a platform and provide a way for third-party developers to interact with your site. In doing so, they used a term, "API," that had to that point been used mostly to describe a portion of the large and complicated software development kits that hardware and software vendors made available to select developers. But web companies such as Twitter, Facebook, and Netflix weren't interested in being gatekeepers. Instead, they created and freely released simple, straightforward web APIs; this helped them gain traction quickly via strong developer support.

However, these web companies soon found that their APIs were useful to a fairly small set of developers, not to some "long tail" community that would continually drive new value. So they started shifting their focus, shutting down public access to pieces of their APIs. Netflix no longer issues public developer API keys, and Twitter is placing greater limits on its public API. The API focus has shifted to favored partners and internal and contract developers. It's a simple cost-benefit calculation: They had a bunch of people who weren't adding much revenue or other value but who required support. More important, those developers were hitting their public APIs, chewing up lots of bandwidth, and sometimes exposing valuable data. Time to tap the brakes.

Meanwhile, enterprises started wondering how they would manage to connect their web services environments (mostly SOAP and XML-RPC) to increasingly popular Internet-based SaaS products such as Salesforce.com, says Dimitri Sirota, senior VP of business unit strategy for CA Technologies and co-founder of API management firm Layer 7. In particular, integrations using SOAP were excruciatingly painful and expensive to build, yet not particularly reusable, making the development pipeline long and organizations much less agile than they wanted to be. The APIs pioneered by consumer-facing web companies seemed to be excellent, flexible models for enterprises to build abstraction layers among their various internal and external systems. Certainly, that's the lesson big-enterprise CIOs (those with foresight, at least) were drawing from nimble startups building their businesses on APIs and displacing component-based development techniques.

To read the rest of this story,
download the November 2013 Special Issue of InformationWeek.