2同行回答
CMDB从逻辑上应该是数据中心的核心，它承载了数据中心的方方面面不同粒度的数据。正因为所有数据中心都希望CMDB保存所有数据中心的不同维度、不同粒度数据，所以CMDB一直都不能很好构建好。几乎没有完美的CMDB能承载数据中心所有的数据。原因就是每个人都希望CMDB承载自己关注的粒度数据，不相关的粒度数据都不希望出现，因此CMDB都不知道到底重点在哪儿，该满足谁的为主旨，也难以确定用什么维度来实现各种粒度数据关联和输出数据服务。
CMDB承载另一个就是流程，如果CMDB与管理内容粒度隔离，那就CMDB为存数据而大量吸收数据，输出数据服务就变得很渺茫，现实就是这样的。
但是反过来，一旦与流程对接，本来是期望通过流程运转过程中把CMDB更新和准确性得倒保证，就会因为流程流转和更新诸多变更受限制，反而牵制了流程的顺畅，如此为了流程顺畅，就牺牲数据了，因此CMDB中的数据不但没有更新和准确，反而增加了一些冗余数据，而且为了迁就流程流转，甚至写入错误数据。
所以CMDB到底该怎么定位，用到什么地方，通过什么方式保持数据鲜活性，如何保持CMDB数据准确一致，与周边环境的数据同步机制和消费形式，这些都取决于数据消费粒度的管制，如果消费侧对CMDB所存的数据粒度不适应，消费侧自然不会使用，如此久而久之，则CMDB就变成了没人问没人更新的sunset平台。
所以CMDB的构建，首先确立消费侧所需要粒度，如果有消费侧和明确粒度，CMDB则可以构建，然后CMDB能够有足够的灵活性可以扩展，并不断优化完善扩展维度/粒度，这样增加更多的消费侧供给和用户范围，这样就会有一个良性循环，否则CMDB一定是思路一条。
比如CMDB与云管平台对接这件事，是大CMDB，小云管？还是大云管小CMDB本来就很难决策，原因就是CMDB粒度数据与云管平台适应环境所需要粒度数据是否一致，不一致怎么解决，是在云管解决还是CMDB解决，者都是需要看面向使用者/消费侧的关注粒度。而且实际上云管平台无论怎么设计都会增加CMDB，只不过这个为了云管平台自行管理体系单独构建的管理粒度。这个粒度与数据中心级的CMDB粒度本身就存在差异甚至舛误，因此怎么有机统一关联，这个需要云管平台团队和CMDB团队相互了解，并且定好各自界面，目标都是维持各自粒度数据的鲜活性、准确性、一致性，给消费侧以安全感、准确无误。