To API, or not to API?

I agree, “cheap shot to copy and alter the Bard’s work”. Specifically for something as simple as my blog entry, but I could not stop my self.

Hype

There is a lot of activity about APIs, API Management, Integrations, API monetization, analytics, and so on filling the various feeds I follow. Many times the discussion revolves around how the data in the organization is valuable and should be monetized by using analytics, or by providing the data for external consumption via APIs. Many times the monetization part becomes pretty vague when the question of who would be willing to pay and for what.

Low hanging fruit – internal APIs

Because of my background, I approach this from a little bit different angle. Specifically from the system implementation and organization’s architectural agility point of view. The “monetization” in this context comes initially from being able to change the organizations direction faster and from the plain old saving money and time.

How many technology projects has your organization started where the first questions are about where to obtain needed master data like sites, people, organization, cost centers and you-name-its? How much time is spent with questions like:
– “Where can we get good quality master data?”
– “What is the master source for X?”
– “Who knows how this works?”

How many times has your organization started a system replacement project wondering what other systems are using the data from the to-be-replaced system? How many emails were sent, and how many meetings called?

What if your organization had a library of interfaces for retrieving (or even modifying) various pieces of master data? What if your new system implementations would not need to know where the original master source is? What if, when one of the master sources changes, your organization would not need to make changes to the dozens of other systems? What if you instantly could see what other systems are utilizing the data?

To achieve that, and many other benefits, your organization will need to start thinking about setting up an internal API strategy. To over simplify the idea – If you think your organizational data object repositories as micro services and wrap the data objects into individual APIs using a domain specific (not product specific) data model you can already see the architecture in your head. To help your imagination, I am providing the following example diagram. Now, while in this diagram ServiceNow is “internal consumer”, it is usually the master source for many pieces of information, but I wanted to keep this diagram simple.

Once you have the organization’s Internal API Library in place, the architecture becomes more decoupled from the systems which are used to manage the data objects. This allows your organization to change one system to another on the background without changes to other systems. With proper API Management tool in place, you can also see which systems are utilizing which APIs and you can monitor the usage in real time.

For example if we now build on top of the first diagram a situation where your organization has decided to change your HR system from SAP HR to Workday, the Internal API Layer will mask the change from internal consumers. As far as ServiceNow is concerned, nothing changed as the APIs it uses stayed the same.

The next step – external APIs

Once you have the Internal API Library in place for your internal master data sources and internal services, you are also equipped to build on top of it, and to start providing APIs for your customers and to monetize those transactions. In the example I have been using, you could expose APIs to allow your customer to build integrations for fetching their configuration information from your system and to manage incident information. If you defined your APIs in a general enough way, you will be able to change the internal consumer layer without affecting your customers.

But it is not just your organization which stands to benefit. When you provide clearly defined, standardized, APIs for your customers, vendors, public(?), they will also be able to be more agile. They will have the ability to verify from your API Library how and where they can interact with the data you manage. They will also be able to change their systems without coordinating with you. You can think of it sort of honeycomb-like structure where first your internal departments expose their systems into the Internal API Layer (inner dashed red line) and then you as an organization publish the External API Layer (outer dashed red line) for customer, vendors and so on.

Conclusions

So that was my short short primer to why the answer to question of “to API or not to API” is “YES”. There are low hanging fruits available by first implementing your organization’s internal API Library and then using the same tools and experience for providing an external API Library. Your organization will achieve higher architectural agility due to decoupled architecture which in turn will fatten the bottom line via reduced costs and higher earnings. The C-level will love the increase on the bottom line and the DevOps people will love the agility. Your customers and vendors will love the clearly defined APIs your provide as they will also reap similar benefits.

Of course your organization will need a tool (or set of tools) for managing the API Libraries, and to actually implement the APIs and link them to the source systems. There are multiple different options on the market depending on your budget, vendor preference, current tools, and other requirements. I personally like the vision and capabilities of MuleSoft‘s Anypoint Platform and MuleESB, but depending on your requirements there are other options such as Apigee (now part of Google), CA’s API Management, Tibco’s Mashery, and many more.

Once you expose the APIs, specifically to the External API Layer, you will need to consider the APIs like products and services and you will need to be able to manage and monitor them like products and services. Keep that in mind when selecting the tools.

Hopefully this blog entry is of use to you and if you are interested in discussing APIs, Integrations or API Management or supporting tooling or architectural concerns do not hesitate to contact us via our pages or engaging with us via LinkedIn, Twitter or just plain old skype/phone call directly to us in person.

Julkaistu 11.11.2016