I have been using HP OM for several years and have been forced to upgrade more than once.

Two come to mind:

First, using HP OMW 7.1 we had to upgrade to 7.2 to make use of the PeopleSoft SPI. We had a new version of PeopleSoft rolling out and only the more recent SPI had support for the PeopleSoft tools being used. No upgrades are cheap and all can have problems. This one introduced issues with HP Reporter (3.5 I think?) to the (then) new OMW. This comes into an issue we've seen time and time again - how one product in the HP stack has to be upgraded for (pick reason, support/required features/etc) but once upgrade it breaks integration we've had with other HP products (NNM to OM, OVIS to OM, OVIS to NNM, Reporter to OM - yes, OVIS is gone now, so in its place put BAC).

The second one was going to HP OM 8 that again we needed to do so we can have effective monitoring of our environment. In this case it was Solaris on x86. OMW 7.5 wasn't going to have it but 8.0 did.

Well, I'm sure you know that 8.0 is quite possibly the worst product ever released by HP. We (my company) funny enough even had a speaking engagement at the HP Conference in 2008 about upgrading to 8.0 because we did it several times in our lab with only some minor issues.

But once we went into production (again, this was just so we could monitor our production environment) it didn't fly very well. Months and months of calls, even getting 2x a week calls with HP (Critical Response Team?, Gina is her name), getting our CIO involved - it was nasty and messy. It hardly points to "stability" of the product.

On the upside, moving to 8.1 has been better but still not flawless. We still have open cases (with 8.1) on service discovery from the agent, various SPI issues (mostly MS Enterprise, and AD), we've had problems with reports/graphs working after agent upgrades (path changes from DCE to HTTPS - but coda apparently doesn't know this), we are about to open another case as well on the myriad of 'opcerror' messages we get - which we were told by HP would 'go away or significantly reduce' when we get to the latest 8.53 agent - but they haven't.

Again, the word 'stability' must be relative here - or not really mean what I think it should mean - basically I install it and out of the box features work and continue to work day after day - week after week.

By the way, I'm confused how a new product speaks to 'stability'?

At any rate, your chart shows up there multiple upgrades every year for HP OM. This is not really a good thing. It might be from a Sales perspective but it is not from an Operational one.

Upgrading costs me time and money and introduces problems and instability into my environment. What I'd like to see actually is less versions coming out. More consolidated across the HP product set upgrades. With me having BAC (gone from 7.0 to7.5 to 8.0 in under 1 year - RUM/BPM reasons),  NNM (7.5 to 8.11), HP OM (detailed above), and Reporter- I seemingly constantly in an planning or implementation of an upgrade to some component of this environment - this causes disruptions to my customers and my ability to actually enhance (through policy writing/tuning - VUGen script enhancement, education, or custom reporting) our service.

Fewer upgrades, more testing (QA) on your part (so, less on mine for you), and making sure one upgrade won't break integrations with other HP products would be great. You do that - and I'll agree that you have achieved some level of stability.

I'm the VP of R&D for BTO Operations within HP software and I wanted to take a few minutes to respond to your comments.

We take our customer feedback very seriously  – both in terms of our responses to blog activity but also in our actions with regards to the evolution of our product portfolio.

In summary I think you brought up four major topics; OMW quality, the challenges of upgrading where multiple products interact, the need to upgrade to get access to new functionality and the desire for ‘less’ new versions of the OMW platform. Here are my brief responses in each area.

1: Some quality issues with OMW 8; valid point. OMW 8 was a very major release and the quality has not met our expectations. We are not happy with this situation and our team has worked hard during the last months to address the issue and it is now under control. We’ve released a number of patches to alleviate immediate customer concerns and will make some announcements on additional activities in this area in the next month or so.

2: Cross-portfolio synchronization of upgrades. We’ve been applying some additional resources to this topic over the last year and are working on some alignment activities which will be tied to a future release and which should significantly reduce the potential for conflicts or issues when upgrading one product which interacts with others in our portfolio.

3: New releases required to get new functionality

This is very clear and everybody in the software business requires this. Sometimes it is just not possible to support new platforms or ‘retrofit’ new functionality onto existing software versions. Unfortunately the reasons behind some of our version support decisions may not be apparent to customers. For example we sometimes add additional functionality into new versions of the OM platform (policy editing features etc.) which are exploited by a specific SPI – so that SPI can only be supported on that specific OM platform or later. The detailed technicalities of this are not always apparent to our customers but there is always a good reason why we only support specific combinations of products.

4: Less versions of OMW: After we complete the activities to address the OMW 8 quality concerns we plan to move to a release schedule based on  less versions (like we already do for OMU).

I hope that helps address some of your issues.

Wolfgang

I have one more comment.

I’d like to start by taking a step back and revisit what Peter was referring to when he used the term “Stability”.  The point that Peter is making is that our platform strategy with Operations Manager is based around the tenet that we actively work to enable our customers to move forwards with what they have. A “stable” platform that can be evolved / upgraded over time.

Yes you will need to upgrade occasionally, either to stay ‘current’ in terms of supported releases or to gain access to new features and functionality, but this is the nature of software. Wolfgang's earlier comments cover this so I’ll not expand my thoughts here.

However, we have never required a complete “rip and replacement” of the solution. Let me explain a little what this means.

When you moved from OMW 7.x to 8.x you will have needed to upgrade the agents at some point. One of the reasons that this is required is that OMW 8.x supports HTTPS based communications between the OMW server and the agents. Patently to provide this functionality the agents need to be upgraded so they have HTTPS protocol stacks.

However, what we do not expect our customers to do is to throw out the substantial (and very ‘personalized’) configuration work that they have done to set up the monitoring rules (policies), actions, data collections etc. of the agents to meet their specific needs. Upgrading agents is a ‘canned’ process – granted it may hit the odd bump in the road, but we work to minimize the effort and RISK associated with this activity for our customers. Recreating your entire monitoring definition (doing a “rip and replace”) would be a huge, and in our opinion unacceptable,  effort and risk to your business.

If we contrast our position – a defined, controlled, evolutionary upgrade path – to those of many of our major competitors then you can see significant differences. I’ll not mention names but many  (at least three) of the major event monitoring solution vendors have all required their customers to completely replace their entire monitoring solution in order to move to the next “version”.  A complete removal of the ‘old’ software and installation of new technology with new monitoring definitions, actions etc. etc.  A “Rip and Replace”. Sadly at least one company is a repeat offender….

These companies do not seem to understand (or acknowledge) that a consolidated event and performance management solution, serving a NOC or Operations Bridge, is a business critical application – the actual business services are dependent upon the correct operation of the monitoring solution. Rip and Replace is not just a massive effort for IT staff, it is also a significant exposure for the business.

In most cases the apparent reason behind the forced “rip and replace” is simply a lack of innovation within the ‘legacy’ solution – so the vendor acquires new technology and makes that the next ‘version’.

Peter referred to OMi in his blog post. OMi is a great example of how HP is avoiding forcing customers to “rip and replace” whilst still delivering industry leading technologies and capabilities. We specifically designed OMi as an overlay on top of existing Operations Manager environments. OMi is based on lots of new technologies – which would have been impractical to ‘roll into’ existing Operations Manager platforms – but we knew that we needed to fulfill our commitment to help our Operations Manager installed base to evolve and gain access to these new capabilities without major disruption, so we made some fundamental design decisions to enable this.