Preparing for hyperscale integration

In mid-2024, Boomi announced Boomi DesignGen, a feature that enables users to design integrations via GenAI chat. As this feature matures, you can imagine the potential benefits for integration experts tackling the toughest mission-critical integration challenges - or for low-skilled integrators connecting simple systems. 

DesignGen is just one of Boomi’s AI features, and, of course, Boomi has offered intelligent data mapping features for years. Armed with a growing number of smart AI-assist features, Boomi customers can develop integrations faster and at lower cost than ever. 

But Boomi isn’t the only integration vendor offering AI features that are radically altering the process of integration engineering. For example, IBM has its conversational AI integration assistant. The fact is all integration vendors are announcing new AI features quarter on quarter. And it’s not just features in the integration platforms themselves that are giving integrators a boost; there are also: 

• Specialised copilots for accelerating programming tasks 
• DevOps tooling AI features to further automate and ease all stages of the software lifecycle 
• GenAI chatbots for general assistance 
• and a whole lot more. 

Whatever technologies your business utilises to connect its applications, you can look forward to developing integrations faster and at a lower cost than ever before as you adopt and leverage each new release of AI-powered platforms and tools. 

So, with the steady rise of these productivity improvements and cost efficiencies, where is this all heading? 

Today, when we view a complex integration architecture in a large business, we typically see: 

• Thousands or tens of thousands of integration assets (e.g. interfaces, integrations, topics, etc). 
• A rate of change (to integration assets) limited by the delivery capacity and speed of projects or product teams. 

But what happens to this view over the next few years, with greater productivity and cost levers? We could see businesses with: 

• Hundreds of thousands (or more) of integration assets. 
• A radically higher rate of change, with some integration assets only fleetingly in existence. 

This begs the question: Why so many integrations, and why such a high rate of change? Because in the future, there will be: 

• A proportion of new integration assets delivered by projects or product teams that are significantly more productive. 
• A proportion of new integration assets that won’t rely on traditional teams. Let’s, for now, assume no humans are involved (though that is unlikely to be entirely correct). This adds even more growth to the rate of change. 

Welcome to the world of hyperscale integration – where: 

• The volumes of integration assets and connected endpoints are orders of magnitude greater than today. 
• Likewise, the rate of change (to integration assets and endpoints) is orders of magnitude greater than today. 
• The integration architecture seamlessly connects vast numbers of dynamic endpoints as those endpoints appear, change, and disappear from existence – often with little to no human intervention. 

Phew! I’m sure you’re starting to get a feel for where we’re heading now. This all sounds good for integrators and good for businesses, especially those who recognise the true size of their mountainous integration backlog. 

An overwhelming integration backlog is likely your number one integration challenge. Consider the size of your backlog mountain, which likely includes:

• You likely have a continuously overflowing integration delivery roadmap. 
• You have a pile of valuable integration requirements that never even made it into the roadmap because integration demand significantly outweighs supply. 
• Everything your business still wants to connect to make life easier for customers and staff and drive operational and commercial efficiencies and insights. 
• You are juggling the pent-up (but often unarticulated) demand from customers and staff for things to be connected, despite you all knowing that it simply won’t be done. 

With today’s technology capabilities, this mountain of work is so unconquerable that we usually ignore its existence and keep busy on the immediate tickets in Jira. 

With hyperscale integration, the high productivity level and high change rate will result in far higher integration throughput. But what does that mean for our mountainous backlogs? 

Today, our teams' delivery throughput mildly erodes the backlog mountain, but tomorrow, we could get closer to its destruction. Expect other things to change, too. 

Beyond the hyperscale integration explosion in the number of integration assets and the significant rise in throughput, let’s talk about naming and documentation. 

Today, integration assets typically have lovely names that make them easy for humans to understand. If you look them up in a directory, you’ll see lists and lists of names. Whether they are nice, standardised nouns, strange camel-case sentences, or some other format – they are all human-readable. But could this change in the future?

Remember the days before hyper-scale computing, how we named the few servers we owned? Back then, servers could be fun to name. I saw servers named after characters in books, colleagues’ relatives, and all sorts of other things. Years ago, when joining a Severity 1 incident call, it would not be strange to hear that (server) “Bilbo Baggins” was down. And in those days, bad things happened if a server went down. 

Then hyperscale computing came along and offered us auto-scaling compute. These days, in many architectures, no one cares if a server goes down. And often, no one knows that it went down, knows the server name, or cares whether it had a name. 

As we proceed towards hyperscale integration, what does that mean about all those nice human-readable integration asset names? Will we care about the names of assets if there are hundreds of thousands of them and their rate of change is frankly overwhelming for us humans? What does this mean for other integration basics – like versioning? What will happen to integration asset directories that rely on manual updates? Will our integration architecture documentation remain in static tools and Microsoft Word? 

Are you feeling overwhelmed yet? Perhaps there are downsides to the world of hyperscale integration, too. 

As you can imagine, with volumes of integration assets beyond the mental capacity of the average human, such a high rate of change, and humans being out of the loop on many aspects of integration, not everything will be easy in the world of hyperscale integration. Things could get very messy as businesses look to manage and secure their integration architecture. 

Are you preparing for hyperscale integration? How will you reap and measure the benefits? And how will you prevent your integration architecture from becoming a giant, unfathomable mess?