Increasing Costs of Integration and Redefining Integration
With the rise of digital initiatives outside the traditional IT, integration needs have evolved and are encouraged to grow significantly.
Join the DZone community and get the full member experience.Join For Free
New use cases, new technologies, a new integration.
With the rise of digital initiatives outside the traditional IT, integration needs have evolved and are encouraged to grow significantly. Gartner estimates that integration costs will increase by 33% this year. Another significant figure: integration projects will represent 50% of the cost of designing & building an application in 2018.
Between Digital IT and historical IT, we no longer wonder whether to integrate, but how to integrate simply and effectively:
When we do not work the same way (bimodal IT).
When Digital is massively deployed on the cloud while historic IT is on-premise.
When the constraints of web, mobile, and IoT spread throughout your IT.
When new architectural patterns appear.
When it is necessary to integrate the SaaS that employees imposed.
These questions already arise to architects and their leaders, C-Level Officers (CDOs, CIO, etc.). How should you respond?
The first part of the answer lies in the concept of integration stack. By "stack," we mean cooperation between different categories of middleware solutions for dealing with complete uses cases: files, data, services, APIs, and all of that on-Premise and/or in the Cloud.
The second part of the answer lies in the following diagram, which positions the various technological components together:
An API Management solution is the central point of your integration. Its role is to be accessible to all regardless of the technologies and deployment chosen for your applications. This is crucial because it allows a re-centralization of your assets, and therefore a complete governance, including on security issues.
The API Layer is not to be confused with the API Management. The API Layer is for microservices. Its role is to manage orchestration of microservices and decoupling to different service consumers. Compared to API Management solutions, differences are:
Constraints on safety and accessibility to a non-technical public that are much lower.
In contrast, constraints on performance and on the integration of these tools in a CI or CD environment that are much stronger.
Next is the on-premise integration, which includes proven integration solutions. These solutions have evolved: the time of non-industrial, not easily scalable, and highly centralized ESB is gone. DevOps, cloud, IoT, API, and Continuous Integration are everyday words for them. Classic integration is not afraid of the pace of digital anymore.
We then find in the cloud the same couples API Layer and microservices and on-premise integration at the top left in XaaS (IaaS and PaaS). Also, stay assured, the technology can be exactly the same! This is extremely important to facilitate development and deployment, but also for possible rollback on environments deployments.
Then we have what we call simple integration, consisting of iPaaS and iSaaS:
The iPaaS is to stay simple, an ESB hosted by the editor. The iPaaS has its scalability and its strong relevance to do simple cloud to cloud integrations and cloud to on-premise integrations, with simplified development tools.
The iSaaS is close to iPaaS but is aimed to "citizen integrators." iSaaS allows a non-technical audience to manage their own integrations themselves (such as a Community Manager who would like to write each tweet received in a row in an Office365 Excel file).
All these solutions will become the backbones of IT in the next five years. It is, therefore, important to qualify and choose carefully. This will depend on the controlled evolution or not of these famous integration costs which will constitute a hinge between digital and traditional IT.
Published at DZone with permission of Thomas Jardinet, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.