{"API Evangelist"}

Some Advice For The Enterprise When Beginning Your API Journey

I'm seeing the enterprise wake up to the potential of an API centric approach to doing business, slowly evolving beyond a Service Oriented Architectural (SOA) approach, and trying to understand why APIs are superior for delivering resources to the web, mobile, and Internet of thing (Iot) apps they are delivering, and increasingly depending on. Even though we are clearly in an enterprise phase of the API evolution, I’m watching many leading enterprise entities struggle with their early API efforts, producing some pretty weak solutions, that developers are not finding useful, and hurting their efforts right out of the gate.

I know that many enterprise API architects will dismiss my advice, because they know better than I do, but I feel compelled to share my thoughts, in hopes that even a handful will be more successful with their API efforts, which I think will also help the overall space as well. When embarking on your API journey, you are going to be handicapped right out of the gate, because as a large enterprise organization, you do not have many of the essential characteristics necessary in your DNA to be successful with APIs, but this is why it will require an API journey, to reprogram your DNA, and better operate on the open Internet.

Before you start planning your APIs, and the supporting developer area, you need to play with other public APIs, to better understand what makes APIs different. I am always amazed at how many enterprise API architects that I engage with, when I ask them what public APIs they have used, admit that they have never used one. They just have heard of many of the common APIs out there, so to prime the API pump, let’s hack on a couple of the most popular API solutions out there:

Do not skip this section, you may think you understand how these APIs operate, by visiting their developer areas, and I know you come to the table with a wealth of experience, and this is your handicap. You have a serious amount of technical experience, way more than I do, but what you are missing is an understanding of many of the business and political building blocks that are making all of this work, ares that you have very little experience within the enterprise.

Technology is part of all of these suggestions, but ultimately APIs represent a new way of doing business that you just aren't used to, and you will have to learn it—something that will take time. Even once you launch your API, you won’t be ready, you will have to learn over time, and this is what the API journey is all about, in addition to the core proposition of making vital company resources available to the public, partners, and internally across the enterprise.

Your biggest challenge, beyond the ones listed above will be what you face internally. Getting developers to use your API resources is tough, getting them to deeply integrate them into applications is even harder, but changing culture at your company and getting the support and resources you will need will be a massive undertaking!

Bottom Up Change
Your senior leadership will most likely not be on board with an API way of operating, and will need a lot of convincing, and most likely ask you for more  evidence of why this will work, before they will give you any resources to embark on your journey. They will want the type of ROI that can kill any API effort before it even gets going, so you will have start small, produce results, and demonstrate the value an API delivers in small, bit-size chunks, week by week. This is not field of dreams, nobody will come once you build it, but this is why you start small, iterate, tell stories, showcase what has been done, and evangelize heavily internally to change senior leaderships view, and win hearts and minds with every integration.

Top Down Change
Even if you have the luxury of having the buy-in of senior leadership, which is extremely unusual, this doesn't mean that your API effort will be a gravy train. Chances are you will hit obstacles, and resistance all along the way. All the advice listed above is meant for your public, and partner audience, but also needs to target your senior, and mid-level management. If you don't have the buy in of the people in the trenches, your API efforts will stumble, and probably fail. The growing number of reasons API fail, are not technical. APIs fail because they do not deliver the value developers actually need, and fail to get the internal change needed to maintain the resources you will need to be successful.

The Enterprise In Age Of Internet
APIs are not just about the enterprise exposing technical endpoints that provide access to your vital resources, and giving you the control you need to govern the usage of these resources. APIs are about the enterprise learning to operate in the age of the Internet, a world that is much more open, global, and distributed, requiring a different approach to business that is about investing in innovation, and less about governance and control. The reason you are probably looking at APIs, is the desire to be more agile, nimble, and deliver web, mobile, and Iot applications faster, better, and cheaper than your competitor—something that takes a shift from your legacy approaches, and slowly shift your culture to reflect the Internet.

You will not be able to master plan your API strategy, and ensure success. You will need to open up a simple, useful API developer area, with a handful of valuable API resources that can be applied internal, bring value to your partners, and quite possibly the public, and get the wheels of change rolling forward. Only then will then will you start to understand the world of APIs, and if you neglect the simplicity, storytelling, showcasing, and other critical elements needed to develop the feedback loops that are necessary to keep the wheels rolling, you will doom your efforts. APIs don’t fail because they are public, or not what is relevant, they fail because you don't see the elements that make them successful, and lack the culture necessary to be an API driven company—get started making the change that will give your organization the tools it needs to not just be competitive, but lead in the Internet age.