It sounds to me like a "complete socket set" versus a "crescent wrench" argument. Both have their benefits. I would agree that a company with all the tools you mention already implemented and functioning properly with minimal expense would be very reluctant to implement CMDB. But if the sum cost of licensing and maintaining 7 or 8 different applications is greater than the cost of implementing CMDB, I can see where that would be attractive to CEO's.
I say the following without ever using or even seeing CMDB ( I only use ARS (Remedy), but it does seem that it would be a much more seamless process if it were all handled by 1 application instead of several different ones. Of course, you also have a single point of failure. Andy L. Mayfield Sr. System Operation Specialist Office: 8-226-1805 Alabama Power Company -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Kaiser Norm E CIV USAF 96 CS/SCCE Sent: Thursday, June 28, 2007 8:40 AM To: [email protected] Subject: Re: Real-World Value of SMS & CMDB I think we're coming at this from two different perspectives. Agreed--the CMDB might be somewhat useful if you are in an environment where NO OTHER AUTOMATION TOOLS EXIST. But I was coming at this from the perspective that certain "standard" network monitoring/management tools are already in place--HPOV, AD, SMS, SNMP, etc. For the sake of keeping a fruitful discussion alive, allow me to counter: - My account is locked out. Again, if you have nothing in place, you might be right, but in my mind, using the CMDB for this is like using a snow shovel to dig a trench. First, we also use Remedy to unlock accounts. I built an application specifically for it. It tells you whether or not the account is locked out, presents "challenge questions" so the person doing the unlock can verify the person's identity, unlocks the account, and submits a ticket behind the scenes for the action. Do I have a CMDB? Nope. Do I even have customer data in Remedy? NO! We do NOT store anything about our customers in Remedy. We store it all--100%--in the Active Directory, which, in our case is exactly where it belongs. Moreover, we have an excellent (not Remedy) product here that connects to the security logs of the domain controllers and is beautifully searchable. It can tell you Johnny on the spot why and from where a user's account became locked out. This way you not only solve the immediate problem but you do the root cause analysis as to WHY the account was locked out. So with these two solutions in place, does the CMDB help me in any way? No. - I can't get to XYZ website. An engineer troubleshooting this problem is far more likely to look at a live-view network monitoring tool (HPOV, NetCop, Smarts-In-Charge) to diagnose such a problem. Good network monitoring tools tell you IN REAL-TIME what servers are up and what servers are down AND WHY! Moreover, they discover the hardware and network relationships AUTOMATICALLY. So again I ask the question--if a tech has an industry-standard network monitoring tool in place...what, in this case, does CMDB get you? Again, I contend nothing. - How do I set up an email profile on my new computer? Come on! If your techs need to look at a CMDB to work this, you have a serious problem. - How do I access the terminal server from home? You contend that questions such as, "Does this person have the authority?" and so on. My reply again is, using CMDB for this is like using a snow shovel to dig a trench. In enterprise environments you typically have accounts management software that handles this. We have an excellent piece of software called AMI (Accounts Management Interface) that handles all these accounts issues. Again, I use a tool that's specifically designed for the purpose rather than go digging through a CMDB for a nugget of data that MIGHT be useful. - I need a new network password. Again, accounts management systems handle this. - How do I change this outline format in Word? This one I'll give you--knowing if a customer is yours or not. While this is a benefit, it hardly justifies on its own the expense and overhead of a CMDB. - My printer needs toner. No, in many environments, a technician must be dispatched with toner in-hand to replace the toner. In many environments end users are not allowed to self-service hardware. - I need my voicemail set up on my phone. Again, if you need to go into the CMDB to find out if the customer has a phone or not, you have a serious process issue. Put it this way--the customer calls me and says, "I need help with my voicemail." I ask myself, "Is this a customer we support?" (which, by the way, in our environment is very easy. We just ask, "Is this person in our department?") If the answer is yes, do I ask, "Ma'am...do you have a telephone?" Duh! She's on it! Again, CMDB gets me nothing. Bottom line--if you have good existing processes and use good industry-recognized toolsets designed FOR A SPECIFIC PURPOSE and you use that toolset for what it's designed and use it well, I'm very hard pressed to see what the CMDB gets you. In evaluating projects like these (especially stuff that's so big), I put myself in the salesman's shoes. I envision myself standing in front of a conference room full of tough, demanding network engineers, system administrators, tech managers, and support analysts. I envision myself trying to convince them that embracing the new thing (whatever it is) will be a good thing. Like this: Me: "Guys, with this, we can see who are customers are!" Response: "We already know that...and the tools we have are better and easier to use." Me: "OK, well, this will tell us about how stuff on the network is interrelated." Response: "We already know that. Our network monitoring tools tell us that." Me: "Hmmm...OK, well, it'll tell us what software is loaded on workstations and servers." Response: "Big deal! I bet you're pulling that from SMS. Why not just query SMS directly?" Me (sweating now): "Well, if a customer requests a service or permissions to something, we'll be able to know if they're authorized to request it." Response: "Duh! We already do that. We were doing that back in 1997. Now we use Active Directory toolsets for that." Me: "Well..." Norm ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
