Case Study: WMQ HealthCheck

Project Description

Large regional bank commissioned TxMQ to conduct a WebSphere MQ environment review to maximize use of resources and technology.

The Situation

TxMQ’s client, a large regional bank, requested a WebSphere MQ-environment HealthCheck. The Bank uses WMQ as a shared middleware infrastructure for all critical business applications to send and receive critical data between them.
In addition, the bank requested that TxMQ identify a solution configuration to meet the bank’s needs.

The Objective

The first key objective for the HealthCheck was to provide senior architecture consulting and a broad assessment and review. The assessment and review would be used to provide flow documents and possible recommendations including, but not limited to:

  • Software and system-configuration changes or upgrades/support packs needed
  • Technical impact and performance analysisResponse to solutions impactWritten recommendations based on meetings with stakeholdersStakeholder concerns mapped to specific infrastructure objectivesA second key objective for the HealthCheck was to analyze the WMQ environment and configuration to eliminate any potential performance, availability and security exposure, and to ensure there were no roadblocks for future growth and new applications. This included an analysis of current staffing structure, number and size.
    The final objective was to analyze the proposed capacity-increase solutions and the impact of each solution to support increases in business processes up to 100% of the existing transaction volumes. The analysis would help the client effectively plan MQ-capacity management strategy, identify technical dependencies and assist with identifying the costs and benefits.

    The Response

    TxMQ’s consultant – an MQ Subject Matter Expert – spent a little more than a week onsite with the MQ team at the bank. TxMQ dove into a diagnosis of the current OS and middleware environment, which included CICS V3.2, WebSphere MQ V7.01 and DB2 V8.
    The client had more than 23 MQ Managers spread over Mainframe, AIX and Windows. Some managers were used for development and testing and were standalone. For production, many of the applications went through more than one queue manager.
    In conjunction with the bank’s internal teams, the TxMQ consultant was able to deep-dive into the environment and architecture and create a list of observations and recommendations.

    Findings

    The HealthCheck revealed no major or current issues. Our consultant’s general observations were as follows:

    • Sound architecture and topology
    • WMQ V6 is due for upgrade
    • Uniform procedures and proper validation for software promotion
    • Add additional load-test environments to facilitate updates
    • Excellent logic and implementation of naming conventions
    • Offsite z/OS image available for regular testing
    • Offsite z/OS image available for regular disaster-recovery exercises
    • Solid business-continuity plans
    • Infrastructure is ready, should disaster recovery be needed
    • Tivoli OmegaMon XA used for monitoring
    • No high-level application and architectural documents readily available
    • System is well-tuned
    • Security is solid with only a small number of areas that need to be addressed
    • Excellent IT skills team with good problem-determination skills
    • Excellent working group with positive attitude
    • Staffing is lean compared to similar organizations. ?In the last 13 months there were three system outages due to application issues. There is no concern with the number of instances and it was determined that there is a well-designed and functioning system in place for tracking and logging instances.
    Additional Recommendations

    The TxMQ consultant provided the following additional recommendations to the bank:

    • Evaluate recent WMQ security features
    • Plan for WMQ migration to V 7.1 or 7.5
    • Modify the current WMQ recovery topology to handle possibility of improved recovery time for a mainframe outage
    • Implement shared queue when Sysplex is available
    • Evaluate additional ESB architecture
    • Review staffing

    Photo courtesy of FLickr contributor Howard Lake.