Extend integration requirements and strategy

This story covers different aspects to determine the interface requirements and complexity based on enlisted factors.

Middleware integration is emerging as an important part of distributed application architecture over the last decade or two. It comprises of many segmentations to deal with, different sets of business domains and this helps reap benefits for large enterprises. An enterprise or any individual application can communicate to other applications or network locations over protocols and systems such as HTTP, SMTP, SFTP, FTP and so on. In order to make available a key set of instructions and standards as a component, you have many integration strategies underlined by many technologies that can be chosen to establish seamless connectivity. This article will guide you how to strategize the type of integration patterns that will help fulfil viable business needs.

Purpose

How does the current digital IT ecosystem adopt the right integration for optimum business benefits and low-cost IT deliverables? This article helps illustrate the various options made available for cloud-based integration strategies to decide the right fitment and discover relevance of traditional integration tooling as well.

Getting started

Integration capabilities

Primarily, you have four major integration capabilities that can be focused on:

• EAI (Enterprise application integration)
• ESB (Electronic service bus)
• SOA (Service-oriented architecture)
• iPaaS (Integration platform as a service)

EAI: It is a framework that makes an enterprise communicate data from one on premises application to another and share data and business processes accordingly. It also defines the set of principles for integration of multiple system communication deliverables such as message-oriented middleware (MOM). The ability of the offerings to exchange data within the enterprise but cross-platform, cross-language is a critical component of today’s integration strategies.

ESB: It provides infrastructure and services for complex software architecture such as middleware infrastructure platform. To be associated with distributed and modular architecture, ESB enables product components to get decoupled and allocated to other computer resources. It supports migration between servers, private clouds, public clouds, and hybrid cloud environments; thus, maximizing deployment flexibility in loose coupling offerings. The extension of ESB is to create webservices and its related functionalities to seamlessly use the built-in message broker, visual tooling, analytics, debugging, and data mapping.

SOA: SOA is gradually emerging mainly because it is different from EAI and does not depend on any third party. It mainly supports business logic based on design principles than middle infrastructure strategy. As the name suggests, SOA processes IT function integration services and application development. It fosters service-orientation via loosely coupled systems. It has the flexibility to define application-level and enterprise-level design principles; and help overcome any shortage in EAI and ESB technologies such as web-based application supporting platforms that are ideal for service adoption, transport adoption, and common services. So, you can refer to the newer SOA architecture as ESB SOA. (SOA-based enterprise service bus.)

iPaaS: As you continue to move towards digital IT adoption and adopt more cloud-based options, iPaaS becomes the most viable solution (other than ESB, a minimum viable solution) to eliminate frictions with disparate systems; and to connect all applications and data made available for the enterprise and third parties. Having middleware integrations for many bi-directional systems, a single integrated system to connect any two source-target systems is an important step toward growing better. When you are connected and in-sync, you can go together further and help businesses save operational expenditure (OPEX) as well as capital expenditure (CAPEX).

Integration strategies to define and set up

As many available capabilities, are gradually shifting to cloud-centric solutions offerings, there’s a fine line between the relevance and non-relevance of available integration solutions in the digital IT ecosystem today. The paradigm shifts from XML to JSON to better manage structural and unistructural data, SOAP to REST APIs (application programming interfaces) for mobile-based solutions aided by lightweight designs are the new normal. So, the best and most viable solution as a combination of REST API strategies with JSON structure can be provided based on what would suit better in the context of large distributed enterprise integration architecture as in hybrid cloud, or multicloud.

Considering the current cloud and digital era in the IT ecosystem, EAI may not fit in to provide a viable solution. But ESB can be considered for on-premise to cloud, hybrid integration or vice-versa. As the internal factors in ESB with SOA comes with its own limitations in comparison to iPaaS, hybrid integration can have a sustainable option while providing minimum viable solution in this area. When you have a fully cloud-centric enterprise architecture, it is best to go with iPaaS.

Hybrid IT solution from cloud infrastructure platform (IBM Hybrid Cloud Transformation or HCT, AWS, GCP, or Azure) to SaaS (software as a service), mobile to social media integration and so on are highly dependent on data and iPaaS. On account of this, hybrid multicloud offering is a recommended option for large enterprises and high-volume user base scenarios.

Decisions to choose between traditional integration versus cloud integration tooling

There are many gray areas for both business and IT when designing a viable solution. Here are some questions that can be shared during a design thinking workshop to understand the processes better:

How does an asynchronous model define a distributed integration?
How do you clearly define publish-subscribe, subscribe-notify models, and conversation, messaging patterns?
How are you factoring OPEX and what is the CAPEX for productive development?
How are the compliance and security costs maintained during cross-cutting concerns?
What does it cost to accommodate new source-target systems, data sources, and formats?
What are the overall integration costs in terms of lost opportunities to innovate?
Will it be open source, open standard, or proprietary deliverables in terms of technology and licensing-model or both?
How does the strategy you choose support newer requirements such as microservices-based architecture, design, and development?
How does the vendor you choose deliver comprehensive capabilities such as messaging, runtime, mobile business process development and so on?
How would the deployment model — hybrid, cloud or multicloud and integration solutions support each other while hosting integration services? How does the container orchestration tool support?
What are the best practices around distributed integration for greater flexibility, containers for the ability to scale better, and managed APIs for reusability and hence speed?
How does legacy modernization and cloud-native API development harness the journey to cloud?

Integration to offer
Besides the inputs gathered from the above list of questions, architects can define the required conversations and integration strategy.

• In the traditional integration practices, small or large enterprises can sustain by complying with minimum governance practices. It must connect the application to ‘batch’ data collaboration and interaction using EAI or third-party tools.
• Now as integration systems are evolving, ‘transactional’ data using SOA are becoming popular and is also the need of the hour. So, on-premise application communications within an enterprise outside can back SOA or ESB as the perfect candidate.
• As most enterprises are hands-on with cloud infrastructure and platform, iPaaS or the cloud-friendly ESB aided by the liquid approach of the architecture design would be most preferred. This will let enterprises accommodate complex SI architecture with large amount of throughput per seconds, inbound or outbound messaging, retrigger calls, message transformation and routings as and when needed. It is also well-versed in handling multi-tenancy for multiple external systems.
• Other cross-cutting concerns to address are interoperability and portability readiness. As industries offer multicloud strategies, one external system or API must be agnostically supported by another system, API, or cloud vendors. This way, a loosely-coupled, highly-cohesive and complex distributed integration architecture can be easily maintained and extended when required.

Top 10 new-age integration requirement strategies

1. Application integration is primarily done through REST and SOAP services and accessible through SOAP or REST APIs
2. Large-volume data integration is available to a Hadoop-based data lake or to cloud-based data warehouses
3. Integration must support the continuum of data velocities starting from batch all the way to continuous streams
4. Integration is event-based rather than clock-driven
5. The data integration strategy is primarily document-centric
6. Integration is hybrid and spans cloud to cloud and cloud to ground scenario
7. Integration must be elastic
8. Multi-tenancy
9. B2B interaction — May be multi-geo with different regulatory perspectives as well
10. Enable IoT-related integration projects

At last to sum up by telling — Integration needs to be delivered as a service.