每个企业和公司都需要一个配置管理数据库（CMDB）。当前架构配置的精确记录对每步IT操作和过程来说都是至关重要的。如今，故障排查速度越来越快了、资源分配的分析也比以前容易了、基础设施的更改给服务带来的影响也越来越小，这些都可以说是头版新闻。

　　然而，并不是每个公司都有必要用数据仓库来存储每个细节的每个架构信息。任何想要一次性执行这样一个项目的企业都是对解决IT难题没兴趣的企业。

　　我们首先要讨论的不是“我们需要CMDB吗？”。IT经理应该意识到，CMDB只是一个工具而已，它不是能让我们一夜“暴富”的摇钱树，并不能迅速地带来丰盛的ROI果实。这一点很重要。CMDB是一项用于存储架构配置数据的技术，人们需要用到它存储的数据来完成某些工作，仅此而已。要成功应用CMDB，一定要以达到特定目标为背景。在一个项目决策过程中，良好的开端应该包括如下要素：

• 根据对业务的影响，将各IT问题进行优先排序
• 确定解决问题所涉及的IT过程
• 制作一个人员名单，罗列出这些过程所涉及的所有人员
• 确定名单中每个人在完成他们那部分过程时需要的数据类型和流量

　　第一步非常重要，因为任何可能跨组（涉及到企业的多个组或部门）的项目都需要领导层的维护来保证它在正轨上运行。关键部门受到的业务影响越明显，项目获得的帮助和支持将会越多。同时，这一步也确立了衡量CMDB项目成功与否的标准。毫无疑问，业务的提升就代表了项目的成功。

　　任何项目都不可避免的会有一定的范围蔓延，过程确定这一步可以有效地限制蔓延问题。由于CMDB是每个IT过程所依赖的基础，大家都很容易额外地考虑一些相关的问题和过程，所以CMDB尤其容易发生范围蔓延。一旦加入这些过多的考虑，就很难放手，从而灾难随之而来。

　　这些过程到底涉及到哪些人也很关键，因为这个项目是为了改进和规范相互的合作。名单中的每个人都必须能感受到执行CMDB的好处，否则他肯定不希望做这个项目。

　　确定过程和所涉及的人员后，再把焦点放到信息需求和数据的理解上。这将使CMDB的技术要求具体化。例如，有这样一家小型IT公司，由于不断地部署新的软件，所以遇到一些故障检修问题。那么，它们的CMDB解决方案就必须恒定地自动追踪问题出现前后的配置情况，进行比较，从而找出问题的根本原因。

　　但如果是换了一家面临同样问题的大型企业，情况就有所不同了。解决方案过程会涉及到更多的人员和部门，比如架构师、客户关系经理和一堆业务经理。对这样的企业来说，获取所有配置细节信息并不能帮助他们更好的合作。相反，他们觉得各团队之间的架构关系共享更为重要。他们的CMDB应该包括的仅仅是最基本的设备配置数据、关系信息和细节信息资源指针。

　　尽管，这两个公司的CMDB执行有很大的差别，但都给业务带来了好处——应用故障检修时间更短。只有花时间认真完成上述四个步骤的IT企业才会更深刻地理解CMDB执行，才能了解什么样的CMDB执行会取得成功。