accurate (some have admitted to being far below that). How can you track changes to technology when you don’t even know what or sometimes where a component you are changing is. What is the true version of OS, microcode, revision level, executable version of a given artifact/component is running. Making sure that you can identify and track each of every component that requires change in the infrastructure is extremely critical. In other words anything that is plugged into a power cord, connected or communicates to a network, runs a OS, is loaded with microcode and let us not forget the source code or linked libraries that gets turned into a binary and is executed as either lower level code bound or linked to the end programs that run the application itself. Having the ability to query some DB which you hope in turn feeds your CEM tool each and every asset means that all changes to any identifiable component can be tracked. Linking these dependent components within your asset DB or your CEM tool enables you to identify collisions and cross functional or customer impacts and their associated risks.
So you think that asset collection and tracking is hard to do? As the saying goes, “Anything worth doing is worth doing right” and the benefits FAR outweigh the cost and time required to ensure you have a proper accounting of your assets. Once completed and the right data (what that data is, is critical too) is captured you can pull metrics on any aspect of your infrastructure and these reports can provide management and everyone responsible for IT with a wealth of vital information. What revision of microcode is any NIC running, what patches or versions of an OS does each and every server or desktop/laptop in your infrastructure run, and of course what versions of code your client facing applications are running. The list goes on and on and you can clearly see the benefits.
Once a full accounting of all your assets is completed all that you need is sound process to ensure new hardware, software or change to any asset that requires tracking is immediately placed into your tool of choice. I’ve seen Notes DBs, Xcel spread sheets, to simple entry sequenced data files on mainframes as well as the pricey “Enterprise” Asset tools from some of the biggest computer vendors in the world used for asset tracking. None of these tools are worth the effort to design, buy or outsource if you cannot enforce compliance by utilizing documented procedures for all users to follow as a sound and solid process to ensure the right data is entered. Compliance in updating your asset data is a topic for another time for how to ensure data continues to be correct is a process unto itself.
Any robust CEM methodology or process starts with a tool that can communicate with your asset data base. Many do not as once again I have seen everything from homegrown Notes DBs, INFOMAN on the mainframe, Spread sheets and basic email systems to Perigrine Service Center, Remedy etc. so you once again need to turn to sound documented processes to ensure you can at least obtain information needed to avert collisions or impacts while getting the proper groups of people to approve and promote a change record (CR) thru the life cycle. To initiate a change to your infrastructure you would generate a CR which should be populated with asset information along with a list of cross impacted components that are associated to your component that requires a change. This CR should have