Not true, IBM

adsey007 — Fri, 26 Jun 2009 09:47:00 GMT

By Mike Shaw

IBM recently made some incorrect claims on their web site about HP's management products. The network side of those claims was handled on our network management blog. I wanted to handle the application management claims here.

J2EE Diagnostics Claims

IBM claimed that HP’s BAC solution (our solution for application management) cannot provide drill down into J2EE applications. This is not true:

HP Diagnostics software for J2EE provides a top-down, end-to-end lifecycle approach for seamlessly monitoring, triaging and diagnosing critical problems with J2EE and Java applications – in both pre-production and production environments.
HP Diagnostics for J2EE starts with the end-user (real and synthetic), then drills down into application components, systems layers and back-end tiers – helping you rapidly resolve the problems that have the greatest business impact
HP Diagnostics will monitor any java application, and will discover and monitor the relationship between applications (java and .net)

Application and infrastructure data integration claims

IBM further claimed that HP’s BAC does not have the capability to correlate application data to infrastructure data. This is not true. Our integration between the application and the infrastructure layers is two-way - from bottom-up and from top-down.

Bottom-up:
- You can see how an event impacts business services above by looking upwards thru the service topology held in HP's CMDB. The services you can look up to may be applications, they may be a user experience (e.g. the online checkin user experience) or they may be steps in a business process. And, you can see what SLAs are resting on the impacted services and those SLAs' closeness to jeopardy.
- This service topology information can be discovered using a number of different methods, all under the overall control of the dynamic discovery manager. For example, if you have OperationsCenter's Smart Plug-ins (SPI), many of these do discovery of their domains and this is now fed into the CMDB. Or, if you are doing agentless monitoring (less expensive to buy and manage, but not the same level of fidelity and action control as with agents - it's horses for courses), this will also discover the hierarchies under the items it's monitoring. And if you have NNMi, our network management product, it will put its end-point discovery into CMDB. If you want everything discovered from business service on down, you can use our advanced discovery technology. As I said earlier, ourdiscovery manager is the overall controller, orchestrating the other discovery methods like SPIs and NNMi should you choose to use them
- The new OMi "TBEC" (topology-based event correlation) technology is able to take an event stream, map the events to services, and then group events related by services in the service topology and thus infer which are causal events (events we need to take action on) and which are symptomatic events (events that are as a consequence of a causal event and thus don't need to be actioned). Included in the symptomatic events may well be an event from our user experience or business transaction monitoring technology. Imagine a DB is having a performance problem. This, in turn, causes a user application to slow. The real user monitor notices this an raises an event. The OMi TBEC will notice both events, realize they are related in the service topology, and infer that the DB problem is the cause and the real user monitor event is a symptom. Is this new? No - the technology was invented by Bell Labs and has been in our NNMi network management product for about 18 months now.
- Summary: bottom-up we have two links up to the application / business service layer. The first is for exntensive "service impact analysis" and the second is for TBEC - for analysis so you just get to see the actionable events you need to do something about.

Top-down
- Our performance triage technology takes performance and event information from dependent services (those services the business service having a performance problem rest on). It uses an HP Labs' patented algorithm to infer causal relationships between infrastructure service performance and fault and the business service's performance. So what? This allows you to know which area is causing the performance problem. Useful given that the average performance problem goes thru 6 to 8 groups before being solved! By the way, the event stream doesn't have to come from Operations Center. We can, should you still have it having not swallowed the rip'n'replace mega-pain yet, take events from Tivoli (or any other event management system).
- The performance triage module doesn't just look at performance and event streams. It looks at recent changes in the dependent services as determined by the discovery monitor (e.g. Server XYZ has had 4gig of memory ripped out). I'm sure you've heard the stat that if a change has a occurred, there's an 80% chance it's the cause of the problem.
- And, as of last November, the performance triage module also considers the compliance state of the dependent services. How does it do this? The ex-OpsWare Server Automation product now puts its discovered information into the CMDB too, and compliance state is one of the things it discovers. I'm sure there's a stat on how non-compliant systems screw up business services above :-)

And finally, something we are very proud of, and something that people really like - the 360 degree view. Take a service, any service. For that service, you can see the following.....
- The performance of the service versus its KPIs. Now and over time.
- What services are above it
- What user experiences are resting on it and what their state is
- The business processes resting on it and the throughput of those services (i.e. Are they slowing down because of this service?)
- The SLAs resting above this service their closeness to jeopardy
- The status of the services this service is resting on
- The change state of services at and below this service
- The compliance state of services at and below this service
- The planned changes for this service
- What the service desk knows about this service in terms of incidents - "do we get an incident on this every Monday at this time?"

OK. I've gone to town on this response a little bit. But to HP Software saying we can't correlation application data to infrastructure is like telling Eugene Bolt he can't run!

Rip out Operations Center and replace it with NetCool

Finally, in this piece of their web site, IBM was suggesting people move from Operations Manager to NetCool. As you probably know, the migration from Tivoli to NetCool is a rip'n'replace. Operations Manager has never done this to our customer base. As a recent and concrete example, the new OMi functionality with its ability to do topology-based (i.e. no writing of event correlation rules) event correlation to reduce event streams to actionable events is an ADD-ON to existing Operations Center installations. No rip, no replace.

If however, you have a predilection for rippin' and replacin', then please do consider the move from Operations Center to NetCool. Personally, I'd add OMi instead because I'd want the topology based event correlation and easy life - but maybe that's just me!

Application Management : CMDB

Not true, IBM