Nastel_IT_Layer_Web(First of a six-part blog series that describes how a team of IT pros and managers at one of the world’s largest global banks accommodated a bank acquisition and mastered a complex messaging environment.)

In the beginning, there was darkness…

Ok, I’m being a bit overly dramatic. What was happening in New York a couple of years ago at a really big global bank with almost U.S. $2 trillion in total assets—let’s call it MegaBank—was a serious lack of control.

Let me paint the scene. The IT team was getting along pretty well… Among other development and operations activities, they were successfully monitoring and managing their WebSphere MQ middleware family of products as well as a homegrown messaging solution. All was well with bank applications utilizing WebSphere MQ and its associated tools.

So what was the problem? MegaBank acquired another firm—which I’ll dub TargetBank—that employed TIBCO EMS (a fully compliant JMS service implementation) and TIBCO Rendezvous (messaging middleware) instead of WebSphere MQ for their middleware and messaging layer. The process of combining two completely different infrastructures was creating a major disturbance in The Force.

But being experienced pros, MegaBank’s IT team quickly set about putting DataPower appliances to work acting as a translation bridge between the two technology platforms, transforming and routing messages coming from MegaBank applications using WebSphere MQ into the native TIBCO EMS format that TargetBank’s applications employed, and vice versa.

To monitor and manage performance of the combined middleware and messaging infrastructure end-to-end, the team needed visibility for:

  • Their custom applications
  • WebSphere DataPower
  • Solace Message and Content Routers
  • WebSphere MQ
  • TIBCO EMS and TIBCO Rendezvous (RV)

…and they wanted a single product to handle it all.

Unfortunately, MegaBank’s home-grown tools couldn’t handle the complexity of the new technology environment. Something better was needed to help maintain improved productivity, reduce MTTR (mean time to repair) for problems, and keep costs associated with problem resolution at acceptable levels.

The search was on for a global monitoring solution that could provide a single point of control for:

  • Unified operational procedures that span multiple technology platforms
  • Run-time operations, WebSphere MQ administration, rapid problem detection and isolation, and operational review and planning
  • Message auditing – used to trace the granting or denying of permissions
  • Tracking – stitching together a flow of transactions, each defined as a group of activities targeted at achieving a common goal or task. These activities are deemed related based on observation of messages exchanged between them or more precisely between logical units of work (LUWs). LUWs represent a collection of operations and messages within a session that must all be done or none done, and are typically delimited by START/CMMIT calls
  • Transformation – used in IBM Message Broker (IBM Integration Bus) where the structure of a message is changed from one XML format to another. This is often required to provide communications between applications that read different formats
  • Routing – employed in IBM Message Broker (Integration Bus) to send a message to a receiver based on message contents
  • Performance – measuring application throughput in terms of metrics such as messages/second or transactions/second

The right tool would help improve interoperability between WebSphere DataPower, Solace, WebSphere MQ and TIBCO. Last but certainly not least on the team’s wish list was the ability to track messages through JMS, WebSphere MQ and DataPower.

Would they be able to find a single software product that could do everything and save their universe?

Of course they did! (Otherwise I wouldn’t be writing this blog.) Stay tuned next week for answers in Making a Happy Marriage of WebSphere & TIBCO Infrastructures – Part 2.