This is Part 1 in a series focused on the evolution of integration projects.
We’re often brought into customer projects that push the boundaries of what is possible with current technology. Over the last four years, many of these have been API-led integration projects. The development of our current TIBCO API Exchange product reflects the breadth of API projects in large enterprises.
API deployments are not exclusively focused on the API as a channel for external business partnerships and monetization, but as an architectural pattern. In fact, the majority of our customers’ API projects are internally focused. This predominance echoes the overall use of APIs as reported by Forrester (Forrester Wave for API Management Q3-2014), where analysts found that 80 percent of the projects were internally focused.
Why Is This and What’s Going on Here?
I believe that APIs represent the third generation of technologies deployed to solve integration problems. They address internal IT and business problems, as well as externally facing requirements and opportunities.
The first generation of integration was enterprise application integration (EAI), born in the late 1990s. Here, the biggest challenge was creating business processes that worked across dozens of monolithic business applications used in large enterprises. The desire was simply to get data flowing automatically. This reduced manual re-entry along with all the associated quality and timeliness issues. Messaging and adapters became a very large focus as well. Initially, proprietary messaging (IBM MQ or TIBCO Rendezvous) and data formats led the way, but over time, standards-based messaging (JMS) and data (XML) began to dominate.
EAI was a hell of a lot of fun because you could essentially connect anything to anything, even if it wasn’t a particularly good idea (or maybe I was just younger then). Of course, once you’ve successfully joined your CRM system to your order-handling system, you suddenly have business processes that span organizational silos. You now need to be able to answer questions such as “Who is able to create orders?” or “Where is my order now?” However, the people who owned those silos generally didn’t communicate very often or very well, so answering these questions was challenging.
Around 2003, business process management systems came of age, and monolithic applications became more component-based. Now you could create new business functionality by composition of existing capabilities. In the integration space, we started defining every cross-application interface as a contract (WSDL) so that we knew what sort of data was being exchanged and what it meant. This was the second generation of integration, or service-oriented architecture (SOA).
To address the organizational challenges, we put in strong design-time and run-time governance so that the SOA team could figure out what was going on when things broke down. This killed the fun to the extent that, in some cases, the governance boards would refuse to let a new project use an existing service because it might adversely affect an existing project. In this sense, SOA governance, often by central committee, has had a negative impact on business agility.
Check back soon for Part 2!
