This article originally appeared on ProgrammableWeb.
There has been so much talk about APIs and how they add additional revenue channels, create brand new partnerships, allow business partners to integrate with ease, and how they help with promoting your brand. But an important and underlooked aspect, which happens to be a byproduct of this new paradigm shift, is the faster innovation channel they provide. Yes, Mobile First and the API economies are enabled by APIs.
One of the major issues of B2B integration and partner/community-based application development in the past was not only that we gave developers specific limited building blocks but also a set of very rigid interfaces. When combined with tight governance (GRC), security and unreasonable restrictions, essentially it gave the developer community a steel cage to build things inside. This used to allow no leeway, no room for imagination, and certainly thinking out of the box was verboten. The complex interfaces that were handed over to the partner developers and the fixed data exchange models required someone to understand technology deeply and demanded use of very sophisticated integration tools to build these B2B data exchanges. It took months, sometimes years, to build them. When the interface, data model, or the backend system changed, we had to do this all over again.
I’m reminded of an old pirate movie I saw decades ago. In it, someone loaded their gun with gun powder and shot, only to miss the target. That person followed up by trying to reload the gun with gun powder (after uttering an expletive, of course) before a pirate charged him with a sword. In a similar fashion, if we missed the target/goal with what we built, we had to reload the work with our “gun powder”. The problem with that model is that in most cases, we rebuilt from end to end which cost us too much money, too many resources, and took too much time while tying up our entire developer force.
Then came the revolution – the API revolution. This was specifically created to address the issues that were faced by businesses, or entities, when working with developer communities, both internal and external (B2D – Business2Developer, as it is called sometimes). In this model, we are opening up the proverbial steel cage (or shackles). We provide very standardized API interfaces that have well-defined contracts, are version-controlled and have carefully managed life cycles. Yes, the APIs most times are very simple – especially if they are REST-based. With that, we did not limit this to just our developer partners, but rather we opened this up to a society of capable developers who were hungry to make newer things happen. By providing a cleaner entry point into our assets (data, process, systems, platforms, etc.) we asked them to dream up and build something unique, by showing their differentiation and their value add to us and to our customers. This fueled the innovation from the bright minds who wanted to prove their half of the finished product was better than the thousands of other developers who were trying to build something similar using the same baseline. This is where innovation happened. I deal with major corporate customers who are rushing to expose their assets to these bright, out of the box thinkers, and surely enough, those brilliant minds rush to build something unique thereby adding value to each other in the process. Let those bright minds innovate, build, test, deploy, and bring you additional revenue while you enforce, control, and protect your assets in the right way. The key is not only to create APIs out of your existing systems but provide APIs that are enterprise-grade level. This includes security, governance, and scalability but still provides usability factors the users are looking for. Check out how Intel API management solutions can help you with creating, protecting, and providing enterprise grade APIs here.
As innovation and integration continues to improve, now the internal developers are demanding that they participate in the innovation spiral along with the external developers. The data and asset holders are excited about that because the internal developers can take this up a notch. They can create innovative internal solutions using the secret sauce that may not be sharable with external developers, or partners, due to sensitivity of the assets. Now I see that a lot of companies are creating two different channels, one for external developers and one for internal developers. With this there is a new need to have an external facing developer API portal and internal facing API catalog systems that will expose little more than the external portal. Though a lot of companies claim that they will cut off the external portal and developers, I don’t see that happening in the near future. On the contrary, they both need to work in tandem in a harmonized way to get the full potential out of the assets. We at Intel are the very first ones to realize that and have developed a solution that will offer both external and internal API developers a set of rich enablement functions. Check out Intel API Management solutions portal for more information.
One final point I want to discuss. People seem to often mix up open interface and flexible data access with open source. While it is possible to build one on top of other, care should be exercised when you build all of these on top of open stack and open yourself up for insecure or non-enterprise grade solutions.
As my dad used to tell me many times, “Tell them what to do, not how to do it. People will surprise you with their creation.” It is time to open up your locked assets and let the creative developer community put their magic dust to work to create multiple beautiful stories out of it.
I will be speaking on this very topic at Defrag in Broomfield on Nov 4-6. Please stop by my API speaking session if you are attending this event or anywhere in CO on those days. It is worth it.
- By Andy Thurai (Twitter: @AndyThurai)