Should the developers still spend time and money building the applications from the scratch when there are so many ready-to-use capabilities available in the market? There are many new ones getting released every day, is it not possible to identify the available capabilities (APIs) and stitch them together to get the desired outcome?
An API (application programming interface), allows one piece of software to talk to another. Today, APIs are responsible for connecting people, systems, things, and algorithms, enabling the creation of new user experiences by simplifying access to information and functionality.
In the case of Uber, it connects you with a driver when you need to go from location to another. The driver is given your coordinates on Google Maps, allowing them to easily navigate to the required locations. But how does Uber communicate with Google Maps to facilitate this? How does the data transfer happen between Google Maps and Uber? The answer is an API. Uber communicates with Google Maps through the Maps API. As APIs become ubiquitous, the need for standardization of their design and consumption became eminent. The OpenAPI Specification (OAS) has emerged as the key to doing this. Essentially, the Open API Specification is a set of rules that defines the API’s contract, detailing its resources, and the corresponding response-request cycles.
APIs, by connecting different software applications together, they also allow 3rd party developers to build on top of your existing products and services. This creates an extensible platform ecosystem that enhances your offering for your customers at minimal cost.
Just like how Google Maps’ data is useful for Uber, any organization’s data can be useful for others to build or enhance their own offering. Using APIs, your company can share important data that can benefit others. Various business models around APIs based on the importance of the data exposed have since evolved, thus helping the companies grow their business through the APIs.
When a single organization unlocks its proprietary systems, processes and/or data by publishing an API, it creates value and potentially a revenue stream, for both itself and its business partners. Multiply this effect by many organizations and it creates an ecosystem known as an API economy whereby value is created from APIs that not only operate independently but also enable new and unique applications to be created from a mashup of several APIs.
Instead of publishing an application that solves a specific use case, in an API economy, a business can package the functionality as an API, and make it available for entirely new use cases that could not have been anticipated by the publisher of the API.
Having talked about APIs, brings us to the topic of developing applications by connecting APIs.
NPI which stands for New Product Introduction has never been such a crazy topic than now, the market is abuzz with new products every other day. This is great time for creativity and breakthrough innovation, agreed.
However, this is also making the life of the product buyer more confused.
Build vs. Buy has always been one of the toughest decisions every IT leader has to make. This decision making is getting tougher and tougher each passing year with the mushrooming of new niche products in the market.
The shelf life of products once implemented used to be decades in the past. However, the same has been reduced to 2-3 years now. Hence the dilemma - should one buy existing products or build it ground up. If it is a buy option, chances are that switching to another product might happen 2-3 years down the line that is if you are lucky. If one goes with building, it might take longer and the plan of launching that product to market will be missed.
With the shelf of products diminishing it is no more the simple of question of Build or Buy. Gone are the days of one product behemoth doing all the work. It is the age of niche products and integration. The long cycles of huge ERPs, CRMs that used to take years to implement and also take years to upgrade, replace are a thing of the past.
The right strategy is to identify the specific set of niche products with the flexibility of integrations. Applications teams need to develop some capabilities in-house that also stitch together these niche products and also the ability to be able to replace any product with a new offering will keep the organization afloat. If not, it will either lag with the old big products or drown missing the new capabilities.
To be able to do so, application teams need to have absolute clarity on the capabilities needed, existing products in the organization and north star vision where organization is headed 5 to 10 years down the line.
This brings up another pertinent question of integration - is it that simple to stitch together different products to deliver an outcome?
Integration is an expensive area for enterprise IT organizations. A survey estimated 63% of the $800 billion spent on integrations went toward keeping the lights on instead of innovation. What could you accomplish if you put that budget toward moving the needle for your business rather than treading water?
The traditional approach to systems integration calls for directly connecting one system to another, embedding all business and transformation logic within code that sits on one or both sides of the integration. These brittle point-to-point integrations are difficult to maintain and even more challenging to enhance or replace. Everything is mushed together and interconnected, and as investment in new integrations in the enterprise grows, so does the complexity of this legacy integrations.
The solution for this is to adapt to a middle path - have integrations hooked to a central repository but with the flexibility of replacing specific niche product as needed.
