Many industry watchers, including me and my Forrester Research colleagues, often highlight an elite group of management software megavendors commonly known as the “Big Four” that consists of BMC Software, CA Technologies (as it is now called), HP Software, and IBM Tivoli. These four have dominated the management software business for well over a decade. They are big by just about any measure, each with a broad array of product families and annual revenues exceeding one billion US dollars. Because of their stature, they are generally positioned as anchors in most enterprises' management software portfolios. An anchor vendor becomes a strategic partner to the enterprise and is usually the default first choice for a particular need.
I've had many discussions with clients and others about CMDB (configuration management database), not surprising as I am coauthor of a book called The CMDB Imperative. These discussions almost always come back to questions about how this thing called a CMDB looks. How is it built? What tool(s) do I use? Which "database" is best? There are many more.
My first response is usually, "I hate the term CMDB, so let's try to kill it off in favor of the ITIL v3 notion of a CMS." If you pursue a CMS (configuration management system) as opposed to a CMDB, a few things become evident:
The CMS implies a distributed (federated) model consisting of many management data repositories (MDRs). Each of these MDRs hold data relevant to the scope of coverage for the tool that encompasses that MDR (e.g., a network discovery tool is a network domain MDR and an application dependency mapping tool is the key MDR for the application domain).
While a CMDB can certainly be formed in a similar federated fashion, the term "CMDB" has become tainted by the implication that it is a database. The natural assumption here is that this database is one big monolith that holds every detail being tracked. This is unwieldy at best and almost always destructive.
The CMS has a more complex structure, but because it enables a divide-and-conquer approach to the overall system, it is a more pragmatic approach. You can bite off each piece and gradually build out your CMS. A "big bang" is not needed and certainly not recommended.