Secure collaboration and delegated administration in enterprise middleware management may sound like a response to today’s hybrid IT complexity. But the idea reaches back to the market trends that helped inspire Avada Software. Back in 2012 an Avada paper examined a contradiction: business units were increasingly sharing infrastructure to control costs, yet the specialists supporting their applications could not safely share access. Twenty years after Avada’s founding, that insight still explains part of why Infrared360 was built.

In the 2000s, enterprises were consolidating servers and middleware. Strategic business units (SBUs) shared messaging backbones, application servers and integration technologies rather than maintaining duplicate environments. The savings were attractive. The operational implications were less straightforward.

An application specialist could understand an airline’s ticketing transactions without knowing its messaging infrastructure. An IBM MQ Admin (then called WebSphere MQ or WMQ) could keep queue managers healthy without understanding every application using them. Another expert might manage the enterprise service bus. When an incident crossed these boundaries, each person investigated a different piece of the problem.

And shared infrastructure introduced a security dilemma: how could the ticketing team troubleshoot its application without seeing or changing unrelated crew or cargo systems running nearby? Giving everyone full administrator access was not an acceptable answer.

The original paper drew on a 2007 executive survey to make the broader point that successful business units collaborate. A newer benchmark reinforces the relevance of business–technology alignment. McKinsey’s 2026 Global Tech Agenda survey, based on 632 business and technology respondents, found that 29% overall reported co-creating strategic plans throughout the year; among top-performing companies, nearly half reported doing so.[1]

That survey is not a study of middleware operations. Its relevance is the management principle: shared goals work best when the people responsible for business services and underlying technology can collaborate continuously. During an incident, that principle needs to become an operational capability—not merely an organizational aspiration.

The approach Avada described was Secure Collaboration™ paired with delegated administration. Instead of forcing every participant to work through a central administrator—or handing out excess privileges—the organization could define a shared problem domain with different levels of visibility and control.

The distinction matters. Role-based access control (RBAC), as explained by the National Institute of Standards and Technology, ties permitted actions to authorized roles rather than granting everyone the same capabilities.[2] In middleware operations, that can mean:

• An application support analyst sees the queues and channels relevant to their service, but cannot change their configurations.
• An IBM MQ administrator manages authorized MQ resources across multiple applications.
• An incident coordinator gets visibility needed to bring the right specialists together, without being able to issue administrative commands.

Everyone can contribute to diagnosis; no one needs permissions unrelated to their responsibilities.

Avada’s answer was a platform-independent, web-based management portal that could bring monitoring, investigation, administration and auditing into one place. The purpose was not simply a common dashboard. It was to allow people with different expertise to work on the same issue within clearly defined boundaries.

Today, Infrared360 Trusted Spaces™ carries forward that design. Administrators can assign users or groups access to selected middleware objects—such as queues, channels, topics and applications—and specify which actions each role can perform. This supports targeted self-service and cross-team troubleshooting without making every user an all-powerful middleware administrator. Infrared360’s agentless architecture and action auditing further support centralized oversight.

The technology landscape has broadened from the WebSphere MQ and service-oriented architecture era to IBM MQ, Apache Kafka, ActiveMQ, IBM App Connect Enterprise and hybrid environments. The naming and platforms have evolved; the underlying need for controlled collaboration has not.

A practical starting point is to identify which application teams need visibility into which resources, separate read-only investigation from change privileges, and review those entitlements as responsibilities shift. Then make authorized actions auditable. Secure collaboration should accelerate troubleshooting without weakening governance.

As we celebrate 20 years of Avada Software and Infrared360, this early research perspective is worth revisiting. The innovation was never just about seeing more middleware from one screen. It was about helping the right people see—and do—exactly what their role requires, together.

It means granting a user or team limited administrative capabilities over specified middleware resources instead of unrestricted access to the entire environment.

Secure collaboration gives participants role-appropriate visibility and actions. Shared administrator credentials blur accountability and can grant far more access than each participant needs.

Yes. With appropriately scoped visibility, they can inspect resources relevant to their applications while configuration changes remain limited to authorized personnel.

[1] McKinsey & Company, “McKinsey Global Tech Agenda 2026,” February 9, 2026. Read the survey[2] National Institute of Standards and Technology (NIST), “Role Based Access Control: FAQs.” Read the guidance