CXO

SOA vs. APIs to deliver IT services: Is there a difference, and does it matter?

Two schools of thought about how to offer enterprise IT as a service have emerged: SOA or APIs. Here's what you need to know about each, and why one key nuance may be vitally important.

greenquestions.png

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.

About

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 ...

4 comments
cww1975
cww1975

Horses for courses; both architectural styles fit specific requirements well. 


However, in my view the debate needs to address the issue of how to governance services regardless of the implementation; as APIs become more prevalent and more existing services are exposed as APIs how do we make sure we have a good view of who is accesses what service regardless of whether they are hitting a Web API, SOAP-based Web Service, queue, etc? 


Appropriate service governance practices need to couple a well-chosen architectural solution.

amos.anthony
amos.anthony

SOA and APIs have more similarities than differences, but a good architect will evaluate both for best fit. SOA business process oriented, where API is business function/feature oriented. Both have to be managed, secured, and monitored -- in other words: governed. SOA may use one or many APIs, but it's not so common for an API to use an SOA. 


I am biased toward SOA because because it represents a complete solution to a business problem instead of function. API functions can be used by applications in any number of ways, including inappropriately. The same is less likely with SOA because of its process orientation. 


Both SOA and API are valid design options. Both will be around for the foreseeable future. The fact that there is an ongoing debate is a testament to the value of both, but I do lean toward SOA.

thomas.harris
thomas.harris

It depends on the goal.  If I am earning money with or want/need very controlled and structured view and interaction with my data then I'm in the SOA crowd.  Otherwise, if giving free access (like an open government database) then I'm in the API crowd.  Both have a place.

Ralph95
Ralph95

As a user of corporate data over the years, I have always had to fight for access to the information I needed.  I have to side with the API view of data.  When users are asked what types of services they need, they frequently can't predict what will be useful in even the near future.  The less rigid the structures, the more diverse purposes the data can fill going forward.  Protect the data integrity, but allow flexible access to it.  I can't count the number of spreadsheets, graphs, separate databases that I have seen created "off the books".  If they can be made part of the shared enterprise assets it would add much more value to the corporate conversation about the meaning of things.

Editor's Picks