From Fragile to Agile: How Cloud Pak for Integration Can Help You Transform Your Business

IBM Cloud Pak for Integration is a hybrid cloud platform that offers seamless interoperability between integration components to meet any business needs or expectations.

Your business not only relies on its IT infrastructure; your business IS your IT infrastructure. Business processes orchestrate the overall flow of your applications and data, with everything connected and enabled by your integrations. Integration is the essential fabric tying all these components together which ensures your business runs smoothly. You have likely spent years trying to get your integrations to work like a finely tuned racing car engine. You have spent valuable time and energy endlessly optimizing for every application to connect the right way. You need the APIs to access the right data at the right time in the right location.

If asked, you might want to describe your integrations as robust. But the reality is they are fragile. They are built to run as they are, non-adaptive to rapid change. Forcing change on your integration or the wider infrastructure would cause it to break.

Almost every business is in this position. The IT infrastructure and the integrations powering the movement of data between applications might do exactly what they were required to do when they were designed and built. But do you have the tools you need to adapt to change? Fragile, in this case, doesn’t mean that the integrations break, but that they don’t respond well to change. To make any substantive changes to existing integration infrastructure would be a major disruptive project. Indeed, many businesses spawn countless numbers of new integrations to meet new project needs, with no intention of trying to change the existing integration holding their business infrastructure together. What this means is that the number of integrations grow almost exponentially. Each new integration, although built well, and working to design, is ultimately legacy and adds to the fragility problem, with the infrastructure supporting the applications and integrations becoming ever more complex.

This fragility is not sustainable and slows down the business as it tries to respond to new opportunities. Consider if you had a new project needing to integrate into multiple back-end systems as part of a new sales tool that needed the ability to access and update customer records, invoices and billing, stock levels, and logistics. While the integration team builds the connectivity needed to ensure access to deliver the right data in the right format at the right time, the business team is already making changes to extend the remit to cover new regions, new products, and new ways of ordering. By the time any integration is built and running, it would be out of date, and another integration would be needed. On top of those concerns, there are deployment and operational needs to provide scalability and availability to be taken into consideration.

With integration specialists being a scarce resource and generally viewed as a cost to the business, no business is going to throw unlimited additional resources at the problem to speed up the creation and update of new integrations. So how can they resolve this continuing and growing problem of complexity, cost, and fragility and instead build a set of integrations for the future?

See Also: Center for Automated Integration

In the perfect scenario, today’s infrastructure would be as follows:

• Highly available. Multiple instances on multiple different servers. Serving multiple locations globally.

• Highly resilient. Individual instances restart after failure without intervention. No transactions lost or data isolated. The workload is switched transparently in case of site or location failure. Multiple locations protect from individual site impacts.

• Without fault. No service interruption during planned or unplanned downtime. Changes can be deployed and updates made without needing to go offline. Multiple decoupled instances allow for work to continue during unplanned outages.

• Well-designed. Designed to scale up and scale down rapidly to meet performance and throughput changes without redesign or engineering rework.

• Independent. Access to the offering, latency, and throughput are independent of the location of the offering deployment.

• Scalable. Offering components that need to be changed, updated, migrated, or scaled in a way that does not impact other components or the overall execution of the offering.

• Highly secure. Deployment needs to be secure, encrypting data at rest and in motion, with secure gateways protecting external access through the firewall, as the deployment is no longer limited to a single location where efforts can be made to protect in depth.

In common with those infrastructure goals, the goals for any integrations would likely adhere to the following eight points:

1. Building integrations shouldn’t be dependent on integration specialists only. Anyone should be able to create simple integrations quickly that work alongside the wider existing integrations.
2. Integration configuration shouldn’t require complex coding, which increases the need for skills, limits reuse, and adds time and complexity. Instead, the focus should be around low-code/no-code, with templates and suggested inputs to maximize reuse and best practices.
3. Development should work around reusable assets, with lessons learned from past integrations automatically feeding back into future integrations.
4. Integration deployment should also be as simple and repeatable as possible. No matter what is being deployed or where it is being deployed, the process should be straightforward and as automated as possible.
5. Updates to integrations already deployed should be able to co-exist with and replace existing integrations without disrupting ongoing workloads.
6. Integrations should be able to scale up and down to match changes in the workload being integrated.
7. Integration specialists should only be needed to optimize integrations or to solve more complex issues, but these specialists should be able to ensure the integrations are meeting the business needs in every way.
8. Updates made by integration specialists should also be used to improve future integration guidance.

While none of these points specify the details of the integrations needed, they embody healthy practices to minimize the skills, time, and complexity needed to integrate the business and to reduce the fragility associated with integrations being unresponsive to change.

Business expectations have evolved and will continue to do so. The past approach to projects, workloads, and IT planning is no longer acceptable. When designing to meet the needs of today, many expectations of the qualities of service, which might have been hard to achieve in the past, are now taken for granted. There are many expectations today:

• There must be a high level of customer satisfaction
• The offer must be differentiated from competitors
• Higher levels of service need to be delivered at lower costs
• A smaller access to resources, including skilled personnel
• A faster delivery cadence

IBM’s solution for integration is IBM Cloud Pak for Integration. It is a hybrid cloud platform with seamless interoperability between integration components to meet any business need or expectations. Built on and optimized for Red Hat OpenShift. Capable of highly available resilient repeatable deployments in any location with development, testing, and deployment powered by AI-infused automation. Your agile integration solution is ready to explore.

Start your free trial today.