The one constant in information technology is change. With labor shortages and the volume of APIs growing exponentially, enterprises moving to the hybrid cloud and the system integrators that are helping them need to change again and avail themselves of the best API development and management technologies available. Let’s take a look at the history of how integration has changed and how we are moving into a second API Generation: API2.0.
Shortly after the appearance of the computer, businesses recognized the value of integrating individual computers into computer systems that could exchange information. The point-to-point integration era was born. This era quickly gave birth to the building systems of computers within the enterprise – creating a tremendous competitive advantage for organizations that integrated their systems properly. It wasn’t long before different companies needed to exchange information between partners, vendors, and customers. Over time, standards emerge to facilitate this exchange. Who remembers X12, EDIFACT, and ODETTE?
By the late 1980s, a robust ecosystem of standards bodies, integration standards, and systems integrators had emerged with the skills to integrate complex systems together, both at the technical and process level. In those times, integrating systems was reserved for the largest of corporations.
A second major paradigm shift and step forward came with the development of the Service Oriented Architecture (SOA) in the early 1990s, which promised the ability to create services that could be published once and consumed by many. Publish-Subscribe, or Pub-Sub, became popular within the information technology zeitgeist. Also during the 1990s, the internet became popular, but because bandwidth was expensive, SOA was primarily used within the enterprise.
Overnight, service oriented architectures gave birth to the Enterprise Service Bus (ESB) as the enterprise-grade infrastructure to exchange data within an enterprise. The service oriented architecture integration paradigm also gave birth to the Application Programming Interface (API), as a primary standardized fashion to expose application functionality and data.
Service oriented architectures had a secondary indirect impact on the data center, which in turn had a reflective impact on application development paradigms. Data centers had been around almost as long as stand-alone computers. Over time and in an effort to add value, data center providers converted many of their single tenant facilities into collocation facilities that housed multiple companies’s computer systems.
Taking advantage of flexible API architectures and cheap collocation space, a new generation of companies emerged. Software as a Service (SaaS) was born. By the early 2000s, the price of bandwidth was dropping, and these new companies offered their products as a service over a public internet that was quickly becoming ubiquitous. It wasn’t long before these companies started taking advantage of the low latency afforded by data centers to create composite cloud applications.
Almost overnight, new application vendors raced to expose their functionality in the form of APIs. The era of Cloud was emerging. But, what about the mainstream enterprises who had not been born as a service in the cloud? Unlike the largely-open architected cloud applications, these companies had robust broad-scale business models that relied on complex systems housed in private data centers protected by layers of firewalls and other security measures. The core mainframe computer systems of these enterprises held vast wealth in terms of information; information that was isolated from the new world of cloud applications.
Slowly, these established enterprises (banks, retailers, healthcare, transportation, and other vendors) started catching on to the need for them to modernize and play within the broader ecosystem of companies that were thriving in the cloud space. Some of these large enterprises squandered fortunes attempting to migrate away from their core systems to infrastructures and architectures that were being used to build SaaS and Cloud services, using languages that new generations of programmers favored.
After the short-era of failed migration attempts, established companies started to produce purpose-built, expensive, hard-coded APIs that could integrate with the new generations of web and mobile applications that were quickly emerging.
These first generation of APIs were expensive to produce and inflexible. Much like point-to-point interfaces of previous generations, any change to the APIs required a dedicated project to update API requirements. Often, by the time that the API was built, a new set of requirements had already been aggregated for the next API rewrite.
Worse, these established companies were forced with the need to write and rewrite APIs during a massive upheaval in the labor markets, as new developers flocked to the cloud space. This new generation of programmers shunned COBOL, PL1, and assembly language in favor of new programming languages like C#, Javascript, Swift, & Python. This labor shortage for mainframe systems created a backlog of skilled resources to write and maintain APIs, leading to a severe backlog in API creation within the modern enterprise, albeit a shortage that is often unrecognized by developers working in those fields.
A threefold solution is already emerging. First, the hybrid cloud architectures are needed to provide a quick channel to expose enterprise functionality to the outside cloud ecosystem. Second, new ways of quickly developing and modifying API’s in a labor constrained market are emerging. These tools accelerate, standardize, and orchestrate the creation of APIs into core mainframe systems (products like GT Software’s Ivory). Third, as APIs were becoming so numerous and commonplace, API ecosystem products are emerging to manage all of the APIs of a company (products like Mulesoft).
Instead of the code and effort intensive methods used for the first generation of API development, these new graphical and code-free tools are making API development 5-8 times faster than via the code intensive methods of first generation API development. API management suites can manage the creation and automate the deployment of hundreds or thousands of APIs. In a labor constrained market, these new technologies will be vital not only to the the modern IT department but to the business as a whole. Tools offering significant advantages become a competitive differentiator to enterprises who adopt those technologies.
Often, the challenge organizations face is overcoming the inertia of accomplishing work, recognizing that there are better tools out there, and making the decision to adopt new technology.
So important is the play into hybrid cloud and its ancillary technologies that it is a popular rationale given for the recent purchase of Red Hat by IBM – it’s a play to keep the mainframe at the center of the hybrid cloud and to move traditional businesses natively into the cloud. Similarly important are these second generation tools that can quickly and flexibly help integrate the public and private clouds into a seamless environment.
Companies and Systems Integrators (SIs) who tool up with the correct technologies will be the ones who will outpace and out-compete the laggards. A sea change in the API revolution is just over the horizon, and those companies which are positioned correctly will be the ones to capitalize on the Second API Revolution that Hybrid Cloud will bring.
-Joe Marroquin, Director of Strategic Alliances