API Integration as an afterthought; deal with it!
In 2002, the ESB (Enterprise Service Bus) was introduced. For more than 3 decades, many different applications and systems were created and adopted by a large variety of organizations and around the 1990’s, IT professionals had to find ways to deal with dispersed and non-integrated data. Many ETL (Extract, Transform and Load) tools and other solutions where introduced as an afterthought.
These point solutions were hard to implement, manage and, most important, keep current with the explosion of new applications and new releases of existing software.
An ESB would solve many of the problems because both the sending and the receiving part did not depend on each others protocol. No more point-to-point integrations to exchange data between two applications, but once an application was able to receive requests from the ESB, data could be exchanged with every application in the enterprise and beyond! But still, integrations were developed as an afterthought and maintaining an ESB or maybe even 2 or more ESB’s from different vendors after acquisitions or mergers proved to be expensive, time consuming and error prone. On top of that, existing point-to-point integrations never disappeared because the IT adagio “don’t fix it if it isn’t broke” is valid till this day.
API’s to the rescue!
There had to be an easier way and the industry came up with API’s. More generic, powerful, based on the latest technology and a lightweight protocol. A guarantee for success! More and more new application vendors adopted the API standard and implemented API’s. Governments, industries and verticals like healthcare and education started defining standard API’s for their particular type of business. API’s that would allow everybody to exchange data with them as long as they were authorized to do so. API’s galore, and again, unfortunately often implemented as an afterthought.
More is more…
But many legacy applications and systems however still do not support the API integration standard. And where organizations already struggled to keep track of many different point-to-point integrations and an ESB the addition of one or more API Management Systems has caused major headaches to many ICT managers. If integrations are stored in many different places, it makes it harder to guarantee efficiency, security and manageability and turns integration of systems and applications into a nightmare instead of improving the flexibility of IT!
An integration strategy? Why?
Many systems and applications today support the RESTApi standard. API integration is easier and API’s are more or less independent of the release of the application. The arrival of this standard has created an increased awareness on a management level that a well integrated IT architecture offers a lot of benefits. Data is stored only once and has one owner and new initiatives can be launched faster because data can be retrieved from different systems much easier. But only if you KNOW where all these API’s and integrations are and that they are well documented, secure and managed.
This is exactly why more and more organizations have implemented an API Integration department or team where a CDIO (Chief Data Integration Officer) and his staff play an important role in:
- Setting priorities
- Proactively defining and/or creating integrations and making them available as standard business functions
- Define security- and management standards
- Implement standards for things like naming conventions
- A strong integration strategy helps to prevent integrations to be developed as an afterthought
- and much more….
The increase in digitalization efforts combined with products like no- and low-code solutions means that the amount of API integrations and integrations with legacy applications is increasing exponentially. The administrative overhead, security concerns and the organizations inability to cope with all this complexity is not helping digitalization efforts and this is why API Integration management is getting more and more focus.
API Management: DYI, (i)PaaS or CaaS?
Just as applications can only have one copy in the Development, Test, Acceptance and Production (DtAP) environment, integrations and/or API’s should only have one instance in the same type of environments. Secured with full lifecycle management and yes, also documentation. API Management solutions offer all that, and more and some Integration suites even offer complete management for every type of integration, legacy or API based. No matter how, you need to decide how YOU want your integrations to be managed: As an IT Service that you manage, including all the IT solution(s) and staffing you need or as a Service you buy from an external company where they host, manage and secure the integrations.
As digitalization requires you to integrate your systems and applications, you will develop more and more integrations and use more and more API’s. It is not a question IF you need your integrations to be managed it is a matter of doing it yourself or paying someone else to do it for you. In the latter case, your people can spend their time developing new business functions while you have the guarantee that your integrations are taken care of.