With critical business services for almost any enterprise flowing across multiple platforms—including Windows, UNIX, Linux, IBM mainframe, and Linux on System z—it would seem natural that best practices for systems management of these services would be a cross-platform approach. The business advantages of managing such services with cross-platform systems management include reduced costs, increased availability, reduced service outages, shorter time to diagnose and repair, more efficient systems management (fewer people handling a larger scope of work), and less risk to the business. Nonetheless, there has been significant resistance to implementing cross-platform efforts in most systems management disciplines.
Although we might blame territoriality for the resistance, most IT professionals recognize that putting aside territoriality and silo mentality is the right thing to do. There’s no need to prove their platform is the “best” one or the “right” one. What is important is to ensure that the business services executed on their platform are executing correctly, and that proper intra-platform communication is happening as and when it should. One barrier to achieving this may simply be language. Each platform has its own unique language and acronyms. The acronyms seldom translate easily when moving across silo boundaries. It’s particularly pronounced between distributed systems and IBM mainframe technologists. Instead of learning how to communicate in a “foreign” language, IT continues for the most part to use platform-specific systems management processes and tools that perpetuate the inefficiencies and business impacts that result from such a siloed approach.
When a problem occurs with a critical business service, the business owner asks, “When will my service be restored?” IT responds by inviting all the IT specialists for the participating platforms and technologies to a ”war room.” Here, supporting evidence is provided with the goal of proving that the problem isn’t theirs. However, the cause of the problem often lies in the interaction between different technologies. Terminology, data, and tooling differences lead to confusion, wasted time and effort, and delays in restoring the business service to promised service levels.
The business value of cross-platform management is so compelling that IT should be searching for a solution. In fact, it may be available today in the form of middleware management. Most IT sites use IBM WebSphere MQ for their middleware. It includes common concepts and terminology across disparate platforms. Unfortunately, many technicians still manage MQ with individual platform tools. Since MQ provides a crucial connection between platform services, problems need to be addressed quickly and service restored with minimal disruption. The MQ technology lends itself to true proactive management, in which problems can be identified before they impact business services, and are automatically resolved, eliminating outages and manual time and effort to diagnose and triage.
A single pane of glass can provide visibility into MQ health and performance across AIX, Linux, Windows, and z/OS. It delivers a view of business services as well as the technology pieces that support them. The common picture and common metrics foster easy communication between MQ teams. It can also provide the basis for extending the scope of platforms that one technician can manage. An automated response to a developing problem enables the proactive management of this environment and the ability to rapidly restore service for the customer service application and without the need to convene a war room.
Business processes today are cross-platform, and they need cross-platform management structures. IT will need to institute processes and solutions for cross-platform management. Middleware management is a logical and appropriate starting point, and instituting cross-platform middleware management will ensure IT meets its goals of delivering service levels the business requires while reducing the cost of delivering those services.