To API or not to API?
In today’s rapidly developing enterprise landscape, it has become even more apparent that companies need to start thinking about their API strategy. When I talk about API strategy I don’t just mean that they need to hack together a loose interface without thinking about who needs to consume it but it needs to be thought about with a long-term vision in mind. As the Internet, and to that extent companies, has become far more loosely coupled, having a proprietary communication protocol is fast becoming a thing of the past. With the explosion of the mobile market, devices are quickly becoming the tools of the trade, replacing desktops at an unparalleled pace. Front-end technology is evolving, replacing the last outdated technology year after year. Devices are becoming more and more powerful every 6 months…. where does it all end? It doesn’t. To keep up with this rapid technological acceleration on the end device, we really need to rethink how we write our applications and how we allow developers to consume them. Having application screens built on backend servers and served to clients won’t give the end developers the flexibility that they need to create the beautiful allocations that we all want and need. This is where APIs come into play.
Let’s step back a little in time to when the first computers came about, APIs came along with these systems, allowing developers to build applications on top of the exposed system functionality to the platform. Windows is a great example of how rich sets of APIs were able to propel an operating system to the top of the market. Without these APIs the operating system would have been a closed ecosystem, preventing innovation to all but a select few developers who actually understood and had access to the core code. Windows offered the Win32 API, exposing virtually ALL of the functionality of the operating system, allowing ISVs to rapidly build applications that took full advantage of these exposed interfaces. The rest is history.
Come back into today’s world is it really any different? Let’s take a look at the way the Internet is evolving and how it is being consumed today. No longer do companies have the luxury of being a one-stop shop where they meet all the needs of their developers; developers want flexibility. They want to be able to pick and choose the components that they want to integrate into their applications and they want to be able to change at a moment’s notice if one company’s solution doesn’t fit their needs. Developers have the ability to choose and they will. Best of breed application will quickly dominate the niche markets, quickly adapting to backend component changes or pricing variations of service providers. In this new world of “As A Service” everything is up for grabs and no longer are we locked into any one vendor.
So how does this equate to an API strategy and why should big corporations even care about how they want to pursue this new API driven economy? Simple: relevancy. Without thinking about this new development era, where developers pick and choose what they do and how they do it, companies will quickly become irrelevant to them and customers are unlikely to choose a solution with a dwindling or non-existent development ecosystem. Customers’ needs are all about moving product and any new channel for their product is a one up that they have on their competition. Think of this simple scenario with two companies with similar solutions: one offering an API and the other not. That customer may take into account the fact that the one with the API is being used by tens of thousands of developers, which in turn is being used by tens of thousands of their customers. You get the picture, the potential is enormous for the customer evaluating the solutions and the result is almost always the same, the one with the API is far more attractive to future business and growth.
To wrap it all up, what does it mean to embrace this new API economy and embrace these new developers? It means looking for new and exciting ways to create applications, and exposure. With your application exposing itself to the outside development ecosystems via a simple to use API, developers will start to incorporate it into their applications and think of new ways to use your applications. Ways in which you could never imagine.
Nice post Steven. Fully with you here... I wrote down my own thoughts on this very topic a while back: The Rise of Enterprise APIs - Part I
Thanks for the post and the thought provoking topic. It's great. I am curious to know what your thoughts are on how SAP would position itself, and it's products for this opportunity and market ... with a new product? Re-purposing/adapting an old? (e.g. Gateway) and speaking of which, is Netweaver Gateway technically not an API provider already? If SAP shipped predefined services for GW to the backend data, would this not qualify?
We are definitely looking into how we can bring our cloud based applications into this new arena, actually we have to. I definitely see apps like JAM, Employee Central, Ariba all being part of this new API space. You are correct in saying that Gateway does provide the ability to expose API's from backend systems but I am looking at the higher level implementation (mgmnt platform), creating an API hub for developers to both discover and consume SAP applications, something that Gateway is looking to providing us with. This is something that we have to do to remain dominant in the API / Cloud areas.