I've been asked recently "What should I do about ITIL version 3?" My first answer is "What did you do about ITIL version 2?" If you've already started down the service improvement path based on version 2 then I would strongly advise not trying to hold any of that work up while researching the delta between 2 and 3. If you have never really considered any kind of ITSM (Information Technology Service Management) work before now then it's probably best if you start with some foundations (or, more formally, "ITIL Foundations") learning and take things from there. Not a lot of education vendors are offering ITIL V3 Foundations courses, the bulk of them are V2 based, but if you're at the point of just getting started either is of enormous benefit.
If you have the time, check into vendors offering a delta course; there are several decent ones available. Better yet, check in with your local itSMF chapter and see what's cooking there. Many of them partner with education providers in your area for member discounts on ITIL v3 upgrade courses, or put on local branch meetings featuring speakers on that topic.
So, "what should I do about ITIL v3" is best answered by taking a look at where you are on the ITIL path today, and where you are planning on being in the next two months. It also matters how much you already know about ITIL. To break into a few simple scenarios...
1. If you are ITIL savvy, and your organization is already underway with an ITIL-oriented service improvement strategy, you should be educated on the changes in v3 and how they can assist with the work underway. Beware the urge to stop any active work; because in my opinion none of the changes are so dramatic that you should rethink any major initiatives.
2. If you are new to ITIL & the concepts therein, and your organization has service improvement initiatives underway, then don't worry about v3 right now - if you have an opportunity to learn more about it, great, take advantage of that. But otherwise don't panic!
3. Assuming you are ITIL savvy but there are no organizational ITIL-oriented initiatives underway, then definitely invest some time in researching and learning about the changes in v3. It is likely they will help in the planning for any initiatives that may be upcoming.
4. Lastly, if you are "ITIL-ignorant" and the organization has no ITSM work planned or afoot, start with an education on ITIL Foundations. If it is inclusive of V3, great, but if it's only V2 based that is not an issue to be concerned about at this time. Get your feet under you first!
Saturday, September 29, 2007
Tuesday, September 11, 2007
Agents or Not?
Well, it's been a long time coming but let's get this blog going. The first topic up for discussion in itmanagecast is whether an Enterprise Systems Management (ESM) platform should be agent based, agentless, or some combination of the two.
This discussion came up a lot two years ago when Microsoft was heavily marketing against HP in the area of application and system management. As a systems management professional I was frequently asked about my opinions of the two competing products. Unfortunately, I was often asked for my opinion on this topic within the framework of an over-simplified question - agent-based monitoring (i.e. HP OVOW) vs. agentless monitoring (i.e. MS MOM).
People frequently felt that a solution had to be one or the other - the use of some sort of (semi-)proprietary agent technology or a mechanism that polls WMI data from windows hosts. This discussion becomes even more complex when SNMP is added to the discussion. SNMP agents by definition would be agent-based management. SNMP is in fact the classic agent-based enterprise mangement technology - and is frequently frowned upon by Windows sysadmins, where it is used most commonly by network sysadmins and UNIX/LINUX folks.
So does this become the usual MS vs. the world religious debate? Too often, yes. Is that really the question? No. MS based ESM solutions as well as non-MS can be either agent-based or agentless. So lets take the OS and associated doctrine out of the equation.
At the end of the day, all things being equal, the question comes down to whether you should ultimately have to choose one technology or the other. Ideally you do not have to choose but can leverage both. Agents can then be used in situations where you need the ability to have systems "self-manage" when there is the risk of disconnection between the managed nodes and management server. Agentless can be advantageous in situations where there is limited overhead available on the managed node.
So, the great and useful answer is "it depends." What technology you choose should be based on what you need, not what someone likes better. Really, that's the point. Don't have a decision made by emotional basis, or someone's opinion on whether agents are good or bad - make the decision based on what works for your organizations business and technical needs.
This discussion came up a lot two years ago when Microsoft was heavily marketing against HP in the area of application and system management. As a systems management professional I was frequently asked about my opinions of the two competing products. Unfortunately, I was often asked for my opinion on this topic within the framework of an over-simplified question - agent-based monitoring (i.e. HP OVOW) vs. agentless monitoring (i.e. MS MOM).
People frequently felt that a solution had to be one or the other - the use of some sort of (semi-)proprietary agent technology or a mechanism that polls WMI data from windows hosts. This discussion becomes even more complex when SNMP is added to the discussion. SNMP agents by definition would be agent-based management. SNMP is in fact the classic agent-based enterprise mangement technology - and is frequently frowned upon by Windows sysadmins, where it is used most commonly by network sysadmins and UNIX/LINUX folks.
So does this become the usual MS vs. the world religious debate? Too often, yes. Is that really the question? No. MS based ESM solutions as well as non-MS can be either agent-based or agentless. So lets take the OS and associated doctrine out of the equation.
At the end of the day, all things being equal, the question comes down to whether you should ultimately have to choose one technology or the other. Ideally you do not have to choose but can leverage both. Agents can then be used in situations where you need the ability to have systems "self-manage" when there is the risk of disconnection between the managed nodes and management server. Agentless can be advantageous in situations where there is limited overhead available on the managed node.
So, the great and useful answer is "it depends." What technology you choose should be based on what you need, not what someone likes better. Really, that's the point. Don't have a decision made by emotional basis, or someone's opinion on whether agents are good or bad - make the decision based on what works for your organizations business and technical needs.
Subscribe to:
Posts (Atom)