APIs as Products in and of themselves has begun to cross the mind of more than one savvy business person. But how do you market something that isn’t… well… anything?
Let’s back up a bit and first define the meaning of API. What IS an API?
API means Application Programming Interface used in software development. It is defined as a set of subroutine definitions, communication protocols and tools used for building software. What an API is, in its most basic terms, is a set of protocols for communication between various components. These components can be in a single location, or they can be in any number of locations that could be connected by a system which is generally over a WAN/LAN (a network within the company) or also Internet.
At the beginning, APIs were designed as a technical solution to interface software components. They were thought of as a “door”, allowing external programs to access local functions. In 1999, as my team and I were working on the design of a new software product, an EAI (Enterprise Application Integration) solution for connecting our configuration engine with ERPs, I remember using the JNI (Java Native Interface) framework for interfacing this new product written in Java with the core component written in C. We extended the solution with CORBA (Common Object Request Broker Architecture – a standard defined by the Object Management Group (OMG) for allowing communication with different servers. Later, we introduced SOAP (Simple Object Access Protocol, a messaging protocol) to offer more extensibility/flexibility. Our EAI solution supported the XML format (compliant with OASIS) and used HTTPS & FTPS protocols. Without going to much into details, the critical parts of this were the definitions of:
- the API (granularity),
- the format of the data,
- and the security.
As systems within company became more and more complex, communication became progressively THE key of any information system.
The VALUE was/is on exchanging data. And today, this VALUE is so huge (with BigData, AI…) that APIs have become strategic in any business.
How can that be describing an actual product? Stay with me! Let’s define what a product is…
APIs as Products – just what IS a product?
A product, first of all, is something that is produced. Is an API produced? Duh, right? Of course it’s produced; they certainly can’t produce themselves. But by itself, that does not mean an API is a product, or something ….
Secondly, a product has value. This fits directly with the first point. Someone has put some time and effort into producing it, which has value. After all, a product, in the sense we traditionally think of it, is something that has value, commercial value, something that someone other than its creator wants, needs, and can benefit from.
Think about it: the person who creates an API is either paid directly for the work, or has created it for a purpose that will add value to something else. That means the API has value, by itself, because it’s a tool (and all software is a tool in some sense – don’t you agree?).
In fact, Smartbear’s State of API Survey Report 2016 found that almost 85 percent of those who responded believed that API quality is vital to their own organization. That’s real value! That’s a market opportunity!
Thirdly, a product has demand, a market. On the same 2016 survey Smartbear did, they discovered that there are some real challenges for organizations in delivering real quality in APIs. This means that any API that solves any or all of these problems for one organization could be of great value to another organization with similar needs. Remember that a single API can potentially be used for many different solutions other than the one it was first created for.
Fourthly, API portals such as Axway’s API Management Gateway have been birthed to cover the need to provide a safe and secure platform to build on. Just one of the critical services provided by an API portal is to keep the API keys and passwords, which, of course, should never be trusted to email. That practically screams value, and anything with value has real potential as a product.
But aren’t APIs just middleware?
Of course APIs are middleware. After all, they aren’t the finished product, are they? Are they?
In a strictly mechanical sense, they are middleware. They are the programming interface for the application, correct? They are what lets the software communicate with other software. They’re the “plumbing,” the “go-between,” connecting everything together, the necessary “pipes” that make it possible for all the “important” parts of the various applications to flow and work together to bring about the main application.
With some of the old legacy systems that still (shudder) exist, the APIs are often completely unique, designed solely for that system, of no value to any other.
But in today’s increasingly fast-changing world, APIs are designed, of necessity, to “talk” to many, commonly used apps. That means they have real potential as products, since if they are already able to communicate with apps that are available, other organizations can potentially save very valuable development time by purchasing existing APIs.
Wow! So why aren’t APIs a product all the time?
So why aren’t APIs always a product, then?
I like what Michael Endler wrote about how APIs become API Products. He said, “…an API becomes a product when it is managed like one.”
In legacy systems, integration was done with custom-designed APIs, created and designated for that job and that job alone. All of the effort, time and expense was focused solely on creating a proprietary API for a single organization.
This way of doing things worked, but a lot of money was being “left on the table.” It worked in the early days, because everybody did it that way, and that included all your competition. Today, however, the demand for innovation is moving at the speed of light. Keeping up is impossible without being innovative and cost effective.
By using APIs the way the majority of businesses have embraced them, today, it’s possible for collaboration both within and from outside the organization. APIs make it possible for ideas to be tried as they arise, quickly, efficiently and safely, by recombining existing core capabilities.
This is great, but it still presents a challenge when faced with a legacy mindset. How can the thought process go beyond simply creating an ordinary enterprise integration service? The answer is to treat APIs as a product. Suddenly the questions around APIs as a product disappear altogether. APIs are a product!
APIs as a product – mindset makes the difference
When the teams that build APIs begin to treat their APIs as a product, their approach changes from one of simply building a utilitarian piece of software to building something elegant that will attract other developers.
Rather than building something that will work for one company as ordered, when APIs as a product is the mindset, suddenly the product needs to be compelling for many organizations.
Henry Ford is famous for his quote about his Model T, when he said, “Any customer can have a car painted any colour that he wants so long as it’s black.” Of course, not even Ford followed that!
What Ford did follow, religiously, we might say, is keeping it as simple as possible, as cheap as possible, while keeping the quality as high as possible within the aforementioned parameters.
This means that the quality was not the very best you could find, but it was the best value for your money, while still being attractive. The Model T was not a Rolls Royce, but anyone with a decent job could afford it, and it looked pretty nice for the times.
He continually looked for ways to make his product as attractive as possible for as wide a range of customers as possible.
Ford also did something else that was really smart: he didn’t get the painters involved in assembling the cars, nor did he get the upholsterers to build engines. Everyone had their own job on the assembly line he created, and the outcome was an efficiently built, quality, attractive product.
This is a good analogy for APIs as a product. They need to first meet the needs of the consumer, whether internally within the organization or externally. Then they need to have a little bit of a “wow!” factor, being something the consumer will WANT to use.
APIs as a product – get the right people on the job
Continuing with the Ford analogy, it’s also critical that the creation of APIs is left to the software integration engineers. Focus brings efficiency and efficient focus brings elegance.
Integration engineers are not (or should not be) software developers. Instead, their product is used by the developers. These are the people who create the apps and services for their users. These users have traditionally been other employees in their organization, but why not customers, as well?
Indeed, this is what is happening. APIs are no longer locked inside legacy systems, but now connect and draw from many sources, allowing developers to agilely assemble an array of assets from many sources into brand new products and services. This greatly decreases the duration and cost of the development cycle. It also showcases the APIs as its capabilities are made visible.
Packaging the product
Bundling of APIs in reply to market signals is now common. In other words, a new API product can be created by understanding the needs of a particular market, then bundling a number of API resources to meet that market need.
APIs as a product are more than just another pretty face. They are critical, driving business results, and those who miss that fact will be left behind. The days of legacy software are gone for most organizations. API products give an organization’s partners and customers alike the opportunity to first leverage their assets and then to customize according to their own requirements.
APIs as a product take the money off the table that was once left there. They make it possible to actually monetize the data sources. Supply chain innovations are endlessly possible, almost at the speed of thought, now that everything and anything can be connected as needed.
The joke a couple of years ago went something like, “There’s an app for that!” Today, there’s an API bundle for that app, whatever it is, to bring it to reality quickly. APIs as a product makes sense now, and likely will into the future, providing a quickly accessible means for businesses to adapt and keep up to the modern world.
Jean-Christophe Huc (Jay C)
If you would like to read my regular posts then please click ‘Follow’ at the top of this article.