感觉对于CI的划分没有一成不变的规则吧，关键看用户的管理支撑力度及管理层的决心度，以确定相应的宽度和深度。
没有最好，只有最合适：）

个人感觉颗粒度和深度得问题，应该根据实际情况量力而为。如果有合理的工具资源又许可，当然是按要求做啦。但我觉得这些也仅仅是个类似资产管理的问题。如何提供各个配置的关系，能让变更管理有数据可依，有数据可以查，才是重点。因为配置管理是各种管理的基础，所以配置管理的要不要做，怎么做。也可以说取决于公司的流程想做到哪一步。很多公司，刚开始实施ITIL，想着各个流程都做，很努力的把配置管理各部分都做了。最终，其他部分没实施，也是浪费。如果仅仅做事件管理，个人认为，配置管理做个资产管理也就差不了。要做变更管理对配置管理的要求不同了，做到问题管理，可用性管理要求又不同。呵呵，不专业，仅供参考。

我们可以反过来思考，配置管理为了什么而建立？其实可以说为其他方面的管理提供服务，因此配置管理如何实施，实施到什么地步要看需求。

回复 yumyth 的帖子

ls说的很对，配置管理和服务管理根据用户需求而定，颗粒度也是根据实际情况而定。这个是一般意义上的。因为楼主没有给出客户和服务项的目标，所以只能看看架构上的一些东西了

配置管理肯定需要一个非常好用的工具，CMDB初级建设的时候可以用Excel表，但后期Excel表是没法维护，配置管理长期运行起来还是需要有工具的支持。可以基于CI类型或者地理位置来自定义CI树，CI属性可以自定义并且支持扩展，支持建立CI内部的关联关系，支持CI与其他流程进行关联，支持CI的权限控制，支持CI变更的版本控制，支持生成配置管理KPI报表。