This is Part 2 in a two-part series on the three generations of integration. Part 1, focused on the first and second generations, can be found here.
Around 2010, cloud-based business applications (Salesforce.com, MS360, and others) started to be heavily used. This made it possible to have business processes partially in-house and partially in the cloud. Cloud applications initially exposed services by using SOA methodologies, but more and more needed to support agile mobile application development. The rigid schemas of WSDL and bulky serialization of XML were a hindrance. So, the much more free-form REST protocol and JSON as a serialization was used. These sorts of interfaces are currently referred to as APIs.
Don’t Always Know API Consumers
It turns out that the same pressures for agility that drove adoption of cloud apps also affect internal development, with a lot of enterprises keen to use internal APIs to turbocharge their integration efforts. I believe this is the third generation of integration. In contrast to the world of SOA, there is much less design-time governance when you produce an API. You don’t necessarily even know who your API consumer is. The API needs to be treated more like a general-purpose product so you have much less interaction with individual API consumers and their custom requirements. Eventually and ideally, with a public API, anybody can find the API and begin consuming the data and services offered.
Even if the adoption and design time process is agile, when it comes to production, an API should deliver significant business value. By this, I mean that consumers will rely on it to carry out their businesses. The API needs to be highly available because the consumer may be in a different division or even outside of your company, and if the API goes down, it may break additional processes beyond the scope of the API. There isn’t always the same organizational contract between consumer and provider— which means there’s always the chance that one consumer may overload the API, and thus negatively affect another consumer. Having reduced the burden of design-time governance in order to gain agility, it becomes even more urgent to have robust run-time governance to protect, control, and ideally monetize new enterprise APIs.
The first two generations of integration brought us new pieces of infrastructure software, with maturity curves and eventual complete functionality. First, we saw tools that could unwillingly pull data from enterprise applications. Then we saw platforms that supported centralized management of all integration. Now, in phase three, we see tooling for API management. This assists application owners in actively providing information and services. Using these tools, we deliver business agility while still maintaining the resilience required when APIs become part of critical business processes.
To learn more about TIBCO API Exchange, click here.
