Question: What is better than learning from your mistakes?

Answer: Learning from other people’s mistakes.

 

I work with many clients trying to help their business achieve success with their API initiatives.  I share best practices, methodologies, industry examples, consultant reports, and ROI analysis to try to help them succeed.  But, sometimes the best way to learn is by understanding what not to do.  So, based on my experiences I’ve come up with the following list of unfortunately far too common mistakes with one big bonus mistake added at the end.  Read on and try to avoid these bad practices.



 

 1. Poor API Identification and Confusion between APIs vs Services

I put this one first because it is by far the most common problem and often surfaces before the others on this list.  I’ve already addressed this  issue multiple times in blogs and videos (here, here, here, and here).  To summarize, this tends to happen when the IT team (alone) is running the API initiative and they are very familiar with SOA (Service Oriented Architecture).  There are some similarities that drive the confusion and this results in either thinking APIs and Services are the same (they are not) or creating provider oriented APIs based on back end services.  APIs need to be consumer oriented and based on business requirements.  Read the linked content above for the best practices and differentiation.

 

 2. No Defined Project

Here is the conversation:

Customer: “We need API Management.”

Me: “Great, what do you plan to do?”

Customer: “Well… we don’t have a use case defined yet.”

I probably don’t need to elaborate too much as to why this is a problem, but it unfortunately occurs far too often.  Paraphrasing from Alice in Wonderland, “If you don’t know where you are going then any road will take you there.”

 

API Management is a very hot area now and many IT organizations are starting to look into solutions.  However, they have not taken the time to identify what they are trying to do.  This leads to generic technical product evaluations with no business context, defined use case, or defined value.  Without a real project goal there is no true criteria to determine which solution is best for you.  Also, since there is no project, the IT organization tries to justify the cost of the purchase on cost savings as it has typically done for other integration software purchases.  But, that is not the applicable metric for an API management purchase, so the evaluation goes on for an extremely long time with no value gained and often wasted resources.

 

Nearly as bad is defining the entire needs of the API initiative solely on the needs of the first project.  Sometimes the first project defined is internal to the trusted zone while subsequent projects will involve traffic coming into the enterprise from API solutions for mobile, social, and partners.  Defining the architecture to handle only the first project may lead to poor choices.  This should be an initiative with many projects and APIs become a way of going to market.  Look beyond project 1 to the bigger picture.  Which leads me to…

 

3. No Defined Strategy

“What do you hope to gain from your API Management initiative?”  This is often my first question when I am in a workshop with a client.  If you can’t immediately answer this question in business value terms, then there is a problem.  Over the next few weeks I will be elaborating on this area in several blogs on business drivers.  But to summarize, most successful customers are trying to attack one or more of the following business oriented drivers:

• Speed / Time to Market


• Reaching New Customers or Markets


• Business Innovation / Industry disruption


• Driving business efficiencies and interactions across Lines of Business

Some companies will have defined an IT integration project as their first project.  That is okay to get started and build some IT skills.  But a view as to what business values are to be obtained will help you achieve true success.

 

 4. Lack of Business Involvement

API initiatives are about becoming part of the API Economy.  This is about revenue generation for the company (i.e. Monetization – and no, I don’t only mean charging for APIs, but I digress).  Most IT initiatives are about cost reduction or avoidance.  Bringing the business into the initiative can be one of the most beneficial things you do.  In addition to funding, the guidance as to business alignment and strategy will help you avoid many of the pitfalls I’ve already described.  Business involvement helps drive business oriented APIs, defined projects, defined business goals, and more.

 

 5. Not Staffing Key Roles

The most successful API initiatives treat this as a business strategy.  There needs to be someone with the responsibility to drive the success of the initiative.  Your success will be extremely limited if you treat this as just the next IT project.  Even if you want to start small, there needs to be an API Product Manager role defined.  This role needs to understand the business requirements for the APIs you create and drive the success of the APIs.  Most companies do not have people in this role before they form the initiative.  So, this needs to be staffed.  Many of the other roles involved can be staffed with skills from existing IT job roles.  Please see my blogs on roles and responsibilities and organizational structure for more information.

 

 6. Shhh, it’s a secret!

You’ve done great.  You have avoided all the pitfalls I’ve described so far.  You have a strategy, the business is involved, you are defining great APIs, and roles have been filled.  But, the APIs are not being used! What’s wrong?

You missed what may be the most important thing of all - communication!  “If you build it they will come” – does not work.  You need to market your APIs like a product.  You may have the best APIs on the planet, but if you don’t tell prospects about them, how do they know?  This goes for internal APIs too.  Developers (your audience) tend to do what has worked for them before.  If you want to introduce something new, i.e. APIs, then you need to get in front of them and show them why you have a better way for them to be successful.

 

7. No Metrics

What is success?  If you haven’t defined what it means to be successful, then how do you know if you are meeting your goals?  Defining meaningful metrics and goals can be challenging, so put a stake in the ground and adjust accordingly.  Executives funding the initiative will certainly want to know how it is doing.  Most businesses should define both business and technical metrics for success.  In my white paper on Best practices and in the associated video I cover some examples.

 

Also, one last bit of advice and frequent mistake… Learning from your own mistakes is good too.  Don’t wait until you have all the answers to get started.  API initiatives are about fast execution.  Attempting to wait until you know everything may be the biggest mistake of them all.  I call this, “Analysis Paralysis”.  The market is moving fast and you will be left behind.

IBM has had many experiences with companies big and small in all industries and geographies.  Let us help you be successful and avoid these and other pitfalls that might get in your way!  Hopefully you knew all of this already and have had smooth sailing on your API initiative.  I tried to limit the list to what I think are the top 7.  What do you think?  What are other mistakes or bad practices that you’ve seen?  Comment below and add to the list.

 

To understand more about IBM’s thoughts on the API Economy visit the IBM API Economy website.  IBM API Connect is IBM’s complete foundation to Create, Run, Manage, and Secure APIs.  You can find more information about IBM API Connect at the API Connect website.  And you can also experience a trial version of API Connect.

 

If you have questions, please let me know.  Connect with me through comments here or via twitter @Arglick to continue the discussion.