With our feet now firmly in the year 2009 it's time for a look back - way back - to see where we've come from. I like to use a looking back segment like this as a checkpoint on our way as an industry, as organisations, and as individuals, to see if we're on target with our goals we set.
ESM has matured in the past few years with the popular adoption of ITIL/ITSM to move from Enterprise Server Management, to Enterprise Systems Management, and today; Enterprise Service Management. My opinion is that we're on track here at the highest levels and intentions of ESM because the understanding and adoption of ITIL/ITSM principles into ESM gets us where we've always intended to be - managing and monitoring the services that our IT infrastructure provides to our various customer groups.
The challenge is that the software developers providing ESM software solution have gone off in three directions; one group moving too quickly toward monstrous "ideal" solutions, another focusing on very niche solutions, and the third (where I think they have it right) scoping out existing & proven point solutions to become more mature and process-oriented products.
It's always interesting to me that the big software manufacturers and Gartner (et al) feel that they are setting the direction for ESM through their acquisitions and marketing. The reality is that a lot of what they are providing is just irrelevant for 90% of the organisations trying to put an efficient ESM solution in place. It's great stuff for that top ten percent of customers who are process-mature and cash rich. But for the rest of us, we need more focus on the practical and less on where those in their ivory towers feel that the industry should be heading.
From my experience, most people are still just trying to get ESM right, and get it to fit into their processes. The tools, people, and processes (of course) must go hand-in-hand - but just like you need the right number of people (not too many, and with the right skills) and processes that are tailored to fit the way your organisation operates, you need ESM applications (the tools) that fit the people and processes. Ideally you start with the processes that fit the vision; get the right people the skills they need, and then find the right tools. There are SO MANY choices for ESm products these days that doing the tools last shouldn't be a problem, yet, ironically, it seems so often to be the starting position.
Another gap I've found with the ESM industry in 2009 is that there's a lack of information out there on trends in network management. It's not sexy anymore so it's become the red-headed step child of ESM. More's the pity because it's still a critical aspect and great starting point.
With all the hoopla and focus on (not undeserved, but distracting) ITIL, ITSM, and the federated, unified, CMDB attention has been diverted from interesting things that have been going on in the OpenSource ESM world.
Upcoming ITManageCast posts are going to focus on these areas: trends in network management and trends in open source ESM.
Have a fantastic summer.
Tuesday, April 28, 2009
Thursday, April 16, 2009
HP Software OMW vs. OMi
Yesterday I was in attendance at a presentation by HP Software gurus and one of the topics was HP Software Operations Manager. One of the items I found a little confusing at first, and thought I'd share with the online community was the idea of OMW versus OMi. Currently, most of the install base of the Operations Manager product from HP software is one of the following:
"old naming conventions" old products (still supported, but not sold)
HP OpenView Operations for Windows 7.5x (OVOW)
"new naming conventions" current products
HP Software Operations Manager for Windows 8.x
HP Software Operations Manager i 8.x
(note that I'm just focussing on the Windows platform for the moment)
As it turns out, OMW & OMi are differing products, primarily in the interface. Keeping in mind that OMW (& OMi) architecturually are split into three peices - agentry, server, and console. OMi uses the same agentry & server components, but layers a new console on these.
Confused yet? :-)
OMW is currently at release 8.10 and will continue with future releases for now (next expected later this year to be 8.15) as fixes/improvements are added to the product. OMi is being developed in parallel, and is an upgrade (free for current OMW support contract holders) to OMW 8.10. Once you've "migrated" to OMi you stay on that platform. HP is not "pushing" customers to OMi at this time, so if you've got OMW running well, and don't see an immediate need for OMi features (to be discussed in my next posting) then don't rush out the door, but start your research.
Please feel free to ask for any further clarification that I can add to my next postings!
"old naming conventions" old products (still supported, but not sold)
HP OpenView Operations for Windows 7.5x (OVOW)
"new naming conventions" current products
HP Software Operations Manager for Windows 8.x
HP Software Operations Manager i 8.x
(note that I'm just focussing on the Windows platform for the moment)
As it turns out, OMW & OMi are differing products, primarily in the interface. Keeping in mind that OMW (& OMi) architecturually are split into three peices - agentry, server, and console. OMi uses the same agentry & server components, but layers a new console on these.
Confused yet? :-)
OMW is currently at release 8.10 and will continue with future releases for now (next expected later this year to be 8.15) as fixes/improvements are added to the product. OMi is being developed in parallel, and is an upgrade (free for current OMW support contract holders) to OMW 8.10. Once you've "migrated" to OMi you stay on that platform. HP is not "pushing" customers to OMi at this time, so if you've got OMW running well, and don't see an immediate need for OMi features (to be discussed in my next posting) then don't rush out the door, but start your research.
Please feel free to ask for any further clarification that I can add to my next postings!
Subscribe to:
Posts (Atom)