During the Interconnect conference I was often asked about the positioning of APIs and Services (and API Management and SOA). We’ve taken a few runs at this topic before on this site, but given the level of interest in the topic I said I would write another blog addressing it.
To start with here are the prior blog posts on the topic:
I would suggest re-reading these.
Let’s start off by admitting that there are some similarities that are causing the confusion. Both APIs and Services have:
- An interface that often use similar technologies (i.e. Web Services or REST)
- Consumers and Providers
- A run time platform that does some level of transformation (from the consumer to the provider and back)
To see where APIs and Services differ we need to look beyond the interface and technologies. What is the purpose? Why do we create Services or APIs? What were/are the goals we hope to achieve through SOA or API Management?
Services, SOA and SOA Governance:
SOA came about because of the realization that IT infrastructures had become a spaghetti bowl of point to point connections that had become unmanageable. Every time we needed to change a system or add a new capability we needed to untangle all the points of integration from the old application and refit them into the new application. To solve this Services were created to encapsulate the capabilities of each application and connect them to a layer called an Enterprise Service Bus (ESB). The purpose of the ESB was to act as an intermediary to shield each Service from whatever was calling it so that it can remain untouched as the consumers in the environment changed or to allow the Service itself to change without having to touch the consumers.
The hope was that Services would raise up to a business level, however because of the focus on connecting applications most Services mapped to an application or capability
subset of an application. Services are medium grained (i.e. can do several things, but not too many). Design time governance plays a key role in defining Services - walking through the proposal/approval of a Service, its development, deployment, versioning, and eventual retirement. A key point was that we should not keep duplicating capabilities that do almost the same thing. The SOA goal was to drive to a single Service definition to handle all the similar needs and stop the duplicate efforts that had been the normal mode in the past as each project or line of business built their own slightly different implementation.
Netting it out, Services are an interface to a business capability that is being provided for a System of Record (SoR) - key system that runs the business. Services have been created with a provider oriented perspective – i.e. this is what I can do, if you need this call my service interface and I will give you the answer. SOA (while having other purposes also) significantly focused on the connectivity and transformation of messages to/from Services. SOA Governance primarily focused on service identification and trying to drive projects to behave well and reuse the services that already exist. It is largely focused on design/development time governance with lower priority on run time aspects.
Two speed IT:
SOA’s focus was integrating Systems of Record. Problem solved? Not quite. Along comes a big drive to introduce new Systems of Engagement (SoE) – mobile, social, cloud, internet of things (IoT), etc. Businesses need to engage customers with these paradigms as the new norm. However, the rate of change for these SoE efforts is far faster than for traditional SoR. For example businesses are often creating and modifying mobile apps several times per month. Care needs to be taken in driving change into the SoR systems or we run the risk of outages. We need a new way to allow the SoE systems to evolve rapidly while protecting the SoR systems that run our business from constant change. Enter APIs and API Management…
APIs and API Management:APIs are Services. Not all Services are APIs. APIs are consumable Services. So, the first key distinction I will make is the focus on the consumer. In defining a good API we need to ask 3 questions:
- Who is the audience (consumer)?
- What do they want?
- Under what terms and conditions are you willing to share?
In contrasting this to the prior SOA efforts, there is not an emphasis on provider, connectivity, or even reuse. The priority is meeting the needs of the consumer in rapid fashion.
To foster success with API initiatives we manage APIs so that they can be created quickly with less emphasis on design time governance (although still required) and more emphasis on enabling consumption, creating a contract with the consumer and enforcing this contract. APIs are created and made available to an audience through a self-service portal. This allows rapid adoption of the API. The self-service nature encourages consumption rather than having a negotiation and lengthy on-boarding process.
Standard terms and conditions for consumption (potentially several options) are available for the consumer to choose. API Management is
primarily about enforcement of the terms and conditions (security, rate limiting, and subscriptions) at runtime. In a timescale, API management happens "later" then SOA, in fact it is often all about the activity after the first deployment of an API vs all the activity leading up to the deployment.
The initial driver for API initiatives is often to enable Systems of Engagement (and within that internal Mobile developers). Use cases such as this dictate additional characteristics that are also beneficial to most APIs. These include:
- Simplicity – mobile app developers want to quickly understand the APIs purpose and how to use it
- Fine grained – mobile developers do not want a huge amount of data returned to the app on the phone that they then need to parse through. They want just the results they are looking for returned.
Additional Use Cases:There are other reasons that APIs are used beyond the fast moving pace of SoE. Partner interaction and Public APIs are often discussed. In addition, businesses are looking at crossing Domain boundaries as a definition as to when an API should be used. This includes: Cloud to Cloud or Cloud to/from On-premise, or cross Line of Business access within a company and all inter-enterprise interactions. Any time assets are required to cross a boundary and we want to manage, secure, control and/or understand the usage characteristics we should consider APIs as the mechanism. Let me ask you a question, don’t you think these API Management benefits might also be useful inside the enterprise and not just on the edge? Perhaps another blog down the road on these additional topics.
Netting out APIs and API Management, it is all about the consumer. API Management primarily focuses on enabling the consumer to find and use APIs and enforce terms and conditions regarding their use of the APIs. It is largely focused on run time management with lower priority on design time and message routing and transformation. API Economy initiatives are being driven by the need for Speed and Reach (see
prior blog). These drivers are key business initiatives, not just IT.
One final note - if you look back through this blog, you will not see a product name. I intentionally did not relate a specific product to any capability described. I was not attempting to do product positioning or recommendations. Your specific needs moving forward will determine what products are required. You should not assume that historical product usage aligns to prescribed future needs.
So, we’re all clear on APIs and Services, correct? Do I think this is the last time I am going to hear this question – definitely not! However, I do plan to bookmark this page for easy referral.
As always, connect with me through comments here or via twitter
@Arglick to continue the discussion. You can also
read my earlier blogs.
#APIeconomy#APIEconomy#APImanagement#APIstrategy#apimgt#apis#BusinessStrategy#developer#experienceAPIs#ibmapimgt#Interconnect#Mobile#MobileApps#PrivateAPI#PublicAPI#rest#service#soa#think_apis