API Connect

I recently had a conversation with an IBM architect regarding the topic “How to get to two Speed IT”. The first thing I did was point him to my blog where 
I thought I covered this – Positioning APIs and Services. While useful, this did not quite answer the question on how to get there, just what two speed IT is and why it is needed (please click the link if you need a refresher). My next attempt was to discuss what good APIs might be which I covered almost a year ago in “Identifying Good Candidates for APIs”. I also mentioned the many industry specific blogs that I have written using this approach. While again useful, it didn’t quite get the architect all the way to what he was looking for.

 

So, what was missing? Both blogs covered the question “what?” but neither one covered the question “how?”. What is two speed IT? – covered! What are good candidate APIs? – Also covered! “How do I get there?” – The topic for today.

 



In the “Positioning APIs and Services” blog I discussed the drivers for “Two speed IT”.  Traditional Systems of Record (SoR) move forward at a controlled pace, while Systems of Engagement (SoE) need to move forward at a more rapid pace. We introduce APIs and API management to control the boundary between these environments exposing assets from the SoR for use by SoE (as one primary use case). I also introduced the three key questions to ask to identify a good API:

1. Who is the audience (consumer)?


2. What do they want?


3. Under what terms and conditions are you willing to share?

These questions are the answer to “how do I get to two speed IT?” But today we will dive more deeply into each of these.

Who is the audience (consumer)?

In earlier blogs I have stated that APIs are consumer focused (as opposed to provider). So, a key criteria to decide how to move forward is to determine who the audience is. What audience is driving the need for two speed IT? Is this for internal mobile development or internal integrations between two Lines of Business? Or are you focusing on increasing your partner interactions? Or are you trying to gain market share through public use of your assets? The answer to this question may be different for different APIs and may also be more than one audience. In 2014 More than 80% of API use cases were internal. And it is often the case that companies start with internal initiatives and then move forward to partners and public offerings. APIs are the currency of Cloud and Mobile these are often good places to start.

 

What do they (the audience) want?

Exposing “what you have” as an API isn’t particularly useful. This is a provider view and not what we are trying for with APIs. An anti-pattern is taking all your SOA services and making APIs on top of every method. Don’t do this!!!

Once you have a target audience, work with them to determine what they want. Don’t try to bias the results with existing service boundaries. If an API needs to call more than one service to obtain a result that the audience requires, this is okay. Don’t make the audience call multiple APIs and create the answer they want themselves. Good APIs are simple to understand and use. Behind the API interface we can be as complex as we need to be, but don’t let the complexity show through to the interface or push the work to the App developer. There is an art to a “delightful API experience” and this is something that you will improve upon over time.

Note that you might have similar but not identical APIs for different audiences where internal audiences may have access to assets not available to the public. It is okay to have different APIs. Reuse is good for APIs, but not as critical as it was in SOA. Some APIs may not last very long or may be unique for certain uses, this is an opportunity not a problem.

Under what terms and conditions are you willing to share?

Un-managed APIs quickly lead to chaos. Think about what security context is required. What to you need to know about who is accessing the API? Do you need to know that the App is authorized to use the API or the user of the App or both?

Business terms and conditions are important too. How much usage is allowed per consumer? Are different levels of consumption supported and under what criteria? How much usage can be handled by the back end systems? Is data privacy a concern? Are you monetizing the use of the API?

Make sharing easy. Once you decide the answers to these questions, set up business offerings (Plans) for your APIs that can be selected by the App developer that implement these terms and conditions. Don’t make each developer interaction require negotiations or manual intervention. But, it is not a one-way street, discuss the proposed plans with the intended audience and obtain their input. They are your customer.

Notice that none of these questions deal with the internal structure of the back end systems, transactions, and data sources. Yes, we do need to deal with these too. But these are handled in the implementation of the API and should not drive the API interface definition that the consumer sees.

Here is the tricky part – we need to think about all three questions at the same time. Who is the audience, what do they want, and under what terms and conditions do we make this available? The answer to one of these questions may affect the others. Privacy issues may affect what audience you can support. What audience is targeted may affect the type of data you can supply. What do they want will drive the granularity and response format. Using these questions as the drivers will help with how to do two speed IT successfully.

 

Connect with me through comments here or via twitter @Arglick to continue the discussion.   You can also read my earlier blogs.