What is i2M?
Integration Infrastructure Management

Integration, from Latin integrat- ‘made whole’, is the act of bringing together different things into a larger combined thing.

Nowadays, the term integration or integration technology is more commonly used than middleware. Integration is critical. According to Gartner “integration work will account for 50% of the time and cost of building a digital platform.”

It’s not just the glue; it’s the actual engine of the enterprise. Business is all about transactions. Money and products are being passed between different companies and people. Nowadays, this is done electronically using messages. If there’s a failure in the integration infrastructure, there’s a failure in the company itself.

Integration infrastructure is anything that performs or facilitates the integration.

The integration infrastructure includes the whole environment that the middleware is part of including underlying operating system, the hardware, the network, and even the applications using it. As well as cloud, containers and virtual machines.

Integration Infrastructure Management is the act of looking after the integration infrastructure. This can include supporting it from the point of view of security, performance, configuration, or availability. In the IT world this includes management of applications, the technology that connects them and the data that flows between them.

Monitoring events are alerts that tell you when something has happened. Like a fire alarm going off. It tells you that your house is on fire. But what you want are early warnings, like smoke detectors that can spot trends or key indicators and detect that there will be a fire soon so that you can do something about it.

We use an SRE approach (Site Reliability Engineering). A declarative paradigm focused on how things should be rather than having to identify all the different individual potential problems. We look for leading indicators like:

• the time it takes to process a transaction,
• the message throughput,
• the error rates,
• and resource usage.

We look for trends in these. Not how long it takes to process the message but whether that’s significantly longer than expected – How it compares to earlier in the day, a different day, or the same holiday period a year ago.

As well as events, we also look at the metrics themselves. We query the status of the middleware environment, like the queue depths, the messages processed, and the open input counts. As well as thresholds we look at derived metrics like the speed that the queue is filling using a relative strength index, or we can see anomalies with the standard deviation from the arithmetic mean.

As we move towards cloud, containers, serverless & DevOps, integration infrastructure configurations are changing faster and faster and even becoming ephemeral.  You don’t have time to manually create sensors and thresholds every time a queue appears. And what’s an acceptable depth on one day might not be acceptable on another day. The monitoring software needs to detect new middleware objects, set up monitoring for them automatically and to learn what an anomaly is. This is AIOps.

Our customers have an enterprise monitoring solution like Splunk, AppDynamics, or Dynatrace, but they still need monitoring software with built-in integration expertise. It’s like a build vs. buy choice. One of the most prominent American banks replaced BMC with us recently because their auditors said that they had a Key Person Dependency. Their middleware monitoring needed so much configuration, and only one person understood it, so if that person left the company, they’d be without support and maintenance for their monitoring. The middleware may provide all the metrics and events needed to be consumed by these tools but configuring them to correlate this data with issues is a big job. One company said that they already have a full-time job managing the middleware; they don’t have time to do another full-time job of managing monitoring software.

We have the integration infrastructure expertise and experience at Nastel to see that certain combinations of metrics are leading to an issue. And we know how to fix them. We know that if there’s a message on the queue and the open input count is zero; then it’s a problem. We can see a slowly draining queue with the queue depth gradually increasing or the depth not changing.

APM and observability vendors may be able to tell you that there’s a problem with the middleware. They may know that a message went in and didn’t come out, but then you have to fix the problem. They can’t necessarily give you enough detail to fix it before you’ve lost a lot of business.

Also, consider the support. If you’ve got an outage and you’ve set up your war room where everyone gets together to try to work out the cause, it would be good if you could get the monitoring vendor on the phone and that they would have a good enough understanding of integration infrastructure to help you find and fix the problem quickly.

Using open source monitoring software can be a false economy. Like “build vs. buy”, do you want to spend your efforts being a software development company or focusing on your core business? The total cost of ownership is much higher because the support costs and the effort needed to customize are much higher.

Some middlewares offer support for Prometheus and Grafana – two separate tools for visualization and alerting. You need this together in one tool. The critical question is how agile they are. When your integration infrastructure configuration, message rates, and business requirements are changing, how long does it take to build a new chart and a new set of rules? You don’t want your business delivery to be delayed because of the time taken to set up monitoring.

We provide message tracing for IT support and end-to-end transaction tracking for the business itself. “Where’s my message?” is a pervasive question that middleware administrators are asked. An application owner knows that they sent a message, and another knows they didn’t receive it. But they don’t know where it is. We capture and record the message at each hop so the middleware administrator can say exactly what route the message took and where it ended up. It’s essential to have both the current state of the environment and the historical record. We also use this for near real-time monitoring. We learn how long a particular message flow takes and if it takes longer for a specific message, we can alert on that.

When middleware comes into its own is when the business people start to get value from it. We have a view of the actual business as it happens. We have customers who use us for MIFID II compliance, PSD2, and Dodd-Frank. Transactions must be processed within 5 minutes or reported to the regulator within 15 minutes. We record how long each transaction takes. We alert if a transaction takes too long, and produce compliance reports for audit showing that transactions were processed on time. And we report on routing. A message is supposed to go from A to B to C, but sometimes it goes straight from A to C and we alert on that.

We also look at the payloads of messages if your security policy allows it. So if messages are stuck on a queue, we can see the one with the highest value and make sure that one gets processed first. A banking customer has a compliance requirement that a message isn’t changed while it’s in the hands of the bank. So we take a snapshot of it when it enters the middleware and also when it leaves, and we assure that the amount or the payee hasn’t been changed en-route.

Many of our customers use us for business reporting. We can say how many euros have been processed and how many dollars. Or the amount of a particular product that’s been sold.

The middleware people are critical to the running of the enterprise and could add even more value to the business.

Our tools allow middleware management at scale with very robust, granular security. For example, Citibank has MQ and IIB on over 4000 distributed servers and on the mainframe, as well as Kafka and TIBCO. UBS has 1500 queue managers. You need an industrial-strength tool to manage at that scale, to make bulk changes, copy a configuration from one queue manager to another, or move a set of messages. From a single screen, we enable someone to look at just the queues that are relevant to them, on different servers and different operating systems all at once, as well as different integration technologies, and to move messages and configurations between them. Thanks to our three-tier architecture, you don’t have to log onto each server one at a time.

We have very granular security with roles and profiles for groups of people, integrated with LDAP and single sign-on, and object groups. This enables secure self-service configuration management.

Typically companies have governance processes in place requiring that only the middleware team change the middleware. A team of around 10 people are handling requests from 6000 people and the middleware team is seen as a barrier to business. The business is delayed in getting new solutions out to market, and they’re beaten by competitors, and losing market share.

Because of our security model, we give that access to the 6000 users and empower them to look after their part of the middleware configuration. They can only change the relevant queues and are able to “view but not change” or “create but not delete” for a very strict set of objects based on rules or naming conventions. This allows them to get on with their work and for the middleware team to work on higher-value activities.

The real power of Integration Infrastructure Management over a generic monitoring solution is the ability to fix the problem. Monitoring tools will tell you that there’s a problem, and may be able to identify the cause but then you have to ask the middleware administration team to fix it. During this handover, time and money are being lost. Having configuration management as part of the monitoring tool means that we can detect a problem, identify a fix and then implement the fix all at once. And often, we do this automatically and proactively before anyone knows that there is a potential problem.

In summary, Integration Infrastructure Management (i2M) is the management of the middleware environment, including the infrastructure surrounding it, the IT availability monitoring and remediation, business and IT transaction tracking and analytics, and secure self-service configuration management.

Follow the discussion on the DoYouMQ podcast available on

• the IBM DoYouMQ website
• Spotify
• Apple Podcasts

Download White Paper: What is Integration Infrastructure Management (i2M)?