There really is no merit to the argument against using a discovery tool, unless you only plan to track things that you can't discover, are just trying to replace an Excel spreadsheet for a few CIs, or can't afford to put one in place. In my opinion, any significant architecture accompanied with a serious effort to manage it using the CMDB and Change Management requires discovery tools to succeed. First let me start by addressing points in the argument.
If your company follows a strict Change Management process, all changes, additions, deletions of CIs should be marked in that process. As a result, if you have a change request to dispose of a server, you should attach the CI to the change request and you should mark the CI with a status of "Disposed" before a discovery tool would be able to detect that it no longer shows up. Yes, you should, but how do you guarantee that this happens? How do you confirm that all changes made are reflected in the CMDB? How do you know if the change even happened? How do you know if changes were made that weren't documented in the RFC? How do you know if people are making unauthorized changes? For example, how do you know that someone has plugged a new server into the network with telling anyone else? How do you find out if someone is stealing memory from servers or workstations? Without a discovery tool, you have no real, effective way to answer most of these questions for anything but simple changes. Without discovery, you can only manage the face of the process. Configuration Management is also about verifying changes, validating your architecture, detecting unauthorized changes, etc. Change Management doesn't address those aspects of the ITIL processes at all. About the closest you get is doing PIRs, but if that's all manual, chances are you're going to miss things. The argument further states that using a discovery tool to update your BMC.ASSET dataset could result in other problems. For example, if a development server had a hardware failure and you shut it down for a week while you were waiting to have time to fix it, how would the discovery tool know that it will be coming back and not simply mark the CI as "Deleted" or some other status? That is simply FUD (Fear, Uncertainty and Doubt) fueled by a lack of understanding of the process in general and the tools in particular. If you took BMC's discovery tools and set them up as is, OOB, with the default reconciliation rules, etc., then I might agree with this. I would never recommend doing that. After developing a better understanding of the discovery process and tools, you need to determine what your policies for updates will be, what sources of information are the most accurate, what types of information you think could be updated/created automatically, etc. With those policies in place, you can put a discovery solution in place that will meet your needs, allow you to answer questions like the ones above, etc. For example, I would not delete a CI from the CMDB just because discovery doesn't see it anymore. That could, however, trigger an audit to determine why the server is no longer being discovered and determine if processes were not being followed, the server died and no one noticed, etc. Another example might be a corporate laptop. What if it stops getting discovered for a few months? Is it just not being used now, or has someone stolen it? A rigorous change process does nothing to discover and change these kinds of things. Without the context of Change Management, the data the discovery tool feeds you is not that useful. Nonsense. Change Management is about managing changes to the environment, not changes to the CMDB. The CMDB is supposed to represent the actual current state of your environment, not some idealized version of it that you think is the case, because you believe that you've captured all of your environment that you care about in your CMDB and that people are following all of your manual processes. People don't always follow processes, and steps often get forgotten or simply left out. This will lead to unintended discrepancies in your CMDB with your real environment. Without an accurate CMDB, you can't properly manage change. The more your CMDB becomes inaccurate over time, because you are relying on people to always do their job perfectly, the less reliable your Change process becomes, because you can no longer accurately assess risk and impact of changes. Now, the CMDB does need to be managed, and updates to the CMDB as a result of Changes is necessary and good, but that doesn't mean that all changes made to the CMDB must be manual changes and entered by people. Deciding how discovery solutions will impact the CMDB is managing the CMDB. Putting processes and procedures in place for how people can change the CMDB is managing the CMDB. Verifying that those processes and procedures are effective and are being followed is managing the CMDB. In fact, ITIL even suggests that a discovery solution that automatically updates the CMDB after changes are made to the environment is a good thing (I can find the actual page in the Blue Book if I need to). That's all part of Configuration Management which really must be in place alongside Change Management. Having a CMDB is not Configuration Management, and having a CMDB without Configuration Management is potential recipe for failure. In addition, I would be very hard-pressed to believe that most organizations actually even know what all is in their infrastructure. At my last position, they had a tool that they were supposed to be tracking servers, etc., in, and they thought that was accurate. We imported that into the CMDB. After putting a discovery solution into place, we found that there were well over 1000 servers in place that we didn't get from the previous asset management solution, and that was just at that site - that didn't take into account all the servers at remote sites that were being tracked in spreadsheets, etc.. In short, chances are, you really don't even know what's out there, and without a discovery solution that can search your infrastructure and report back to you what you actually have, there is no way for you to figure it out, unless you're a very small IT shop with a very simple infrastructure. I think that any serious CMDB and Change Management effort for anything but a near trivial infrastructure is pretty much doomed to failure, or at least very gross inefficiencies, without having a discovery solution in place. Yes, you need to figure out how you want to handle the data you get, and what rules will dictate what data gets auto-created or updated in the CMDB, etc., but fear about that process is not a valid argument against it. I hope this helps a bit and was at least somewhat coherent. Cheers, Lyle From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Pierson, Shawn Sent: Wednesday, April 01, 2009 7:16 AM To: [email protected] Subject: What purpose does a discovery tool serve? ** Good morning, This email was meant as more of a general discussion rather than me being obtuse and not really seeing any benefit to using a discovery tool to populate Asset Management. However, I've been discussing this with the CAB manager and I'd like to have a better argument than I do now in favor of using a discovery tool. The argument against a discovery tool is this: If your company follows a strict Change Management process, all changes, additions, deletions of CIs should be marked in that process. As a result, if you have a change request to dispose of a server, you should attach the CI to the change request and you should mark the CI with a status of "Disposed" before a discovery tool would be able to detect that it no longer shows up. The argument further states that using a discovery tool to update your BMC.ASSET dataset could result in other problems. For example, if a development server had a hardware failure and you shut it down for a week while you were waiting to have time to fix it, how would the discovery tool know that it will be coming back and not simply mark the CI as "Deleted" or some other status? Without the context of Change Management, the data the discovery tool feeds you is not that useful. My argument in favor of using a discovery tool is that we don't have a perfect world and changes will happen without people updating Asset Management, so it's better to keep the CMDB closer to reality that way. Also, we can use the reconciliation engine to only automatically process certain updates, and someone can manually fix other records that we can't tell the system what to do with (e.g. the development server example in the previous paragraph.) However, I'm starting to warm up to the other argument, because I can see using discovery tools as an excuse to not update Asset Management and makes the relationship between Change Management and Asset management a little less useful. What are your opinions? Thanks, Shawn Pierson Remedy Developer | Southern Union Private and confidential as detailed here<http://www.sug.com/disclaimers/default.htm#Mail>. If you cannot access hyperlink, please e-mail sender. __Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"
