According to Michelle Feaster, director of product management for HP software, and a principal involved with the acquisition, Opsware will be operated in what she terms incubation mode.

Opsware will find a home in the BTO [Business Technology Optimization] organization under [HP Softrware vice president] Tom Hogan, but at this point we will incubate them, said Feaster.

For now, Opsware’s sales and product organizations will remain autonomous from the rest of HP software. We will do everything possible to have 99% of the staff stay with HP, she said.

HP previously announced that Opsware CEO Ben Horowitz would move up to heading product R&D for all of HP Software. With the incubation arrangement, the head of Opsware’s product own development will report to him.

While HP won’t be announcing the full product roadmap until the end of next month, Feaster shared with us some early thoughts about where product synergies and overlaps were found.

The first area that she pointed to was client management, where HP’s Radia complements on the client what Opsware already offers on the back end, stretching from server to network and storage.

We believe there is tremendous synergy between Radia and Opsware, she said. In all likelihood, the Radia client management piece will be folded into the Opsware automation system.

We also intended to go deeply into storage essentials, she added, pointing to the storage resource management that came to HP through the 2005 AppIQ acquisition and Opsware’s recently acquired Creekpath, which is now the Opsware Storage Automation System.

In some areas, product overlaps weren’t as great as first appeared.

For instance, the application mapping capabilities that came to HP through Mercury’s Appilog acquisition don’t duplicate what Opsware offers in its Visual Application Manager. Appilog is more about the mapping of application dependencies on the server and storing it to the CMDB. [Opsware’s] VAM [Visual Application Manager] shows port connectivity in real time on a dashboard, but does not persist the data, Feaster explained.

In other words, Opsware’s VAM charts dependencies at lower levels than Appilog, uses agents while Appilog does not, and is intended more as a real-time dashboard. Feaster said that in the long run it would make sense to connect the Opsware VAM function to HP’s Universal CMDB (configuration management database).

Another area is the CMDB itself. Earlier in the week, when we reported on Opsware System 7, we were corrected by Opsware when we stated that it did not have its own CMDB. Opsware protested that in fact it did have such a database (and we removed it from the historical archive of our article).

HP’s Feaster said, however that there was no real overlap. Opsware OMDB is not a real CMDB. It is more a reporting solution for their technologies, she said, adding that the Opsware OMDB lacks the federation and reconciliation capabilities that are normally part of a CMDB.

Our View

In some respects, the Opsware acquisition is a replay of that of Mercury, almost a year ago. In both cases, HP’s goal was to keep the product development, and to a varying extent, the sales organizations intact. And in Mercury’s case, much of senior management was retained (by that time, people tainted by indictment were long gone from Mercury).

But otherwise there are very clear differences. The Mercury deal was more of a reverse acquisition, as Mercury principals in effect took the helms of sales, marketing, and product development of the mother ship. They proceeded to recast much of the HP OpenView legacy under Mercury’s Business Technology Optimization label. In essence, HP realized that Mercury’s business, while dwarfed by OpenView’s, was the growth engine, and that the overall business should be steered in that direction. Besides, Mercury’s availability centers provided the higher level business views lacking from the OpenView portfolio.

And that makes the entire stack a much higher level sale, in that it is more of a CIO than a director of data center operations deal.

With Opsware, the CEO has indeed been catapulted upstairs to steer all product R&D. But while Mercury, in effect assumed direction over much of the legacy HP Software organization, Opsware for now is being left for now to steer its own course.

HP realizes that Opsware’s market is currently less mature than Mercury’s was at the time of acquisition, and more importantly, that much of Opsware’s appeal was the fact that it still carried much of the agility of a startup. For the time being, the last thing HP wants to do is trip up that growth engine for a company that was just starting to enter the black.

Of course, the flip side of startup is that not all the i’s are always dotted or the t’s crossed. And in this case, it has been the fact that Opsware’s products were not terribly integrated. Opsware has begun to address that with System 7. But, as shown by the differences in Opsware’s application monitoring and what it called its CMDB, its functionality doesn’t have all the depth of a mature product.

While HP is probably wise for the moment to leave its hands off the Opsware growth machine, it’s inevitable that the company will eventually have to join the mother ship. There are too many potential product synergies, ranging from interaction with HP’s Peregrine Service Desk, to correlation of business service availability and IT infrastructure changes, for the companies to remain separate.