There is, by contrast, a "right place for you" to start - and you will not find the answer for that in ITIL or from a vendor trying to sell you a CMDB solution. You need to assess your own operational and business objectives, dialog and communicate with key stakeholders, and judiciously decide where to begin based on readiness, resource, and impact. The notion of a constituency-driven CMDB System may sound threatening and complex, but it can also be liberating - as long as you do not make the mistake of trying to do it all at once.
You can start small for example, several successful, germinal deployments have focused on life-cycle desktop and end-station asset management , or you can start with your most strategic core but keep the objectives finite, well defined, and still associated with clear objectives and a clear constituency. An additional liberating thing about a constituency-driven CMDB System is that it will open up the market to multiple design points, optimized to support different processes and different roles within and even outside of IT.
The challenge, of course, and the price of admission, is a normalization and reconciliation capability to support navigation across these sources with consistent CI and CI-attribute definitions. If I am right, then, the coming years should witness a substantial amount of industry innovation as vendors with different strengths, constituencies, and design points contribute to the variety and depth of CMDB offerings - making it easier for you to target more specific, finite objectives with faster time-to-value.
If properly understood, the CMS can promote flexibility and innovation; if misapplied, it can lead to overarching complexity that can stall even the hardiest CMDB initiative. Why federation is beginning to take off There are lots of reasons why federation is beginning to take off.
Getting ahead of the curve The key point to make about this diversity is that there is not a single generically "right" place to start. The information gathered from this assessment should then be used to manage the cultural change.
The requirement for improved documentation can change the culture from information hoarding to information sharing. This requirement can have a significant impact on the culture. Your organization, like all others, will learn as you go. As your organization matures, you will continue to build on that learning through CSI. Without implementing a CMDB, no organization can grow past a certain level of maturity. There will always be growing pains, but the results will be more than worth it.
Nov 11, AM. About Author. It also manifests itself, for example, in the table structure of the databases used to store configuration information. CI types and sub-types managed in the CMS, usually in the form of a tree structure as in the following example:. The exact set of attributes to be maintained for a CI will vary depending on the CI type at hand, as specified in the Configuration Model.
In an Incident Management system, for example, an Incident Record will contain a reference to one or more affected CIs. So these relationships are recorded in Incident Records rather than the CI records.
0コメント