I have long advocated viewing enterprise IT as a series of business services that IT designs, builds, and maintains. Rather than the more traditional view of IT as a suite of hardware infrastructure and applications, an orientation toward services helps convey the business benefit delivered by IT, and directly correlates the company's strategy with what IT delivers.
Until fairly recently, advocates of this view would generally suggest IT implement Service-Oriented Architecture (SOA), a series of design principles that guided how an IT organization designed, built, and maintained applications. Rather than a focus on individual applications, SOA suggested that multiple discrete applications and data sources be combined into services centered around a business process. Instead of a CRM application initiative that begins with selecting software packages, a SOA-driven organization would identify what services and data were required to meet a business need and then design a combination of tools to meet that need, usually through a backend technical architecture built around a service bus like Microsoft BizTalk, Oracle Fusion, or IBM's WebSphere.
More recently, the concept of broadly deployed Application Programming Interfaces (APIs) has come into vogue, largely driven by the proliferation in internet and cloud applications that allow other applications to easily access data or services, usually though an HTTP-based interface.
Conceptually, SOA- and API-based IT infrastructures accomplish a similar end goal: creating an IT architecture that abstracts consumers of services from the applications and technology that deliver the service. In either case, IT subtly shifts from focusing on delivering technology and letting the business figure out how to use it, to working with the business to deliver a series of services that are then combined to accomplish an objective.
Angels dancing on a pin?
If you've been around IT long enough, you've seen organizations passionately debate nuances that seem irrelevant even to their own colleagues, much like the ancient spiritual debate about how many angels can dance on the head of a pin. To outsiders in particular, these debates seem inane and counterproductive. My initial feeling about the consternation around SOA vs. APIs was firmly in this camp. Both SOA and APIs purported to focus IT on delivering consumable services related to a business process, and each used largely the same technologies to make it happen. If SOA and APIs seek to accomplish the same strategic end, is there even a difference worth debating?
When discussing this with a colleague, he mentioned one area that intrigued me: SOA presumes that an IT department carefully manages and curates access to the services it delivers, striving to deliver limited and carefully-controlled services. This contrasts with APIs, which offer more of an "if you build it, they will come" philosophy of creating relatively open services, and allowing users and others within IT to figure out how to derive value from them. To some extent, SOA mirrors integration efforts of years past, where access was created on an as-needed basis, and generally only between trusted and well-known partners. APIs mirror the development that's occurred on the public internet, where everyone from payment processors to the postal service has provided open APIs, and allowed developers to access and use them, often with little more than a brief signup process.
The latter has been partially responsible for the internet renaissance that's fueled a fervent startup industry not seen since the dotcom boom of the late 1990s. In years past, a developer would have to buy access to various libraries and services and spend time carefully integrating their functionality into a new application. Now, public APIs can be incorporated in moments, and there is healthy competition in several areas like mapping and mobile payments.
While fundamentally and technically similar, the open nature of APIs is intriguing, precisely since IT relinquishes some control over how its services are used. It would be foolhardy to suggest every company release open APIs to all comers, but creating a suite of basic APIs internal to your company frees developers and savvy business users to concoct new and interesting applications using IT assets you already own. In some ways, this is an evolved and formalized version of what end users have been doing for years, dumping data from enterprise applications into spreadsheet "applications" that perform some niche function. Providing a more robust and potentially bidirectional flow to that process ultimately keeps data in a curated IT environment rather than "off the books" spreadsheets, all while taking the best of service-oriented IT strategy combined with end-user accessibility.
SOA and API purists may argue that I've missed some nuanced technical details that further differentiate these two approaches, but the noteworthy points remain the same. Building your IT infrastructure around a series of well-defined business-oriented services becomes even more powerful when those services are broadly and easily accessible, whether the audience is purely internal or more wide reaching.
Are you in the SOA or API camp? Weigh in on this debate in the discussion.
Patrick Gray works for a global Fortune 500 consulting and IT services company and is the author of Breakthrough IT: Supercharging Organizational Value through Technology as well as the companion e-book The Breakthrough CIO's Companion. He has spent over a decade providing strategy consulting services to Fortune 500 and 1000 companies. Patrick can be reached at email@example.com, and you can follow his blog at www.itbswatch.com. All opinions are his and may not represent those of his employer.