In part 1 of my blog I discussed how to select a CMDB and how to identifying the ITIL process to focus on first. Now that you have selected the tool and identified the process to start with, it’s time to start planning for the actual deployment.
The CMDB is going to become a very important data source and system of record for your IT operations and there are some design decisions that will need to be carefully considered. The first of which is the layout of the CMDB system itself. Since the CMDB will need to be continuously available to the business processes (ITSM, ITAM, BSM) that become dependent on its data, the solution should be designed with an eye towards data accuracy, resiliency, and high availability.
For this reason, it is strongly recommended to consider a tiered architecture that separates the modeling and discovery activities from the Primary CMDB. This serves several purposes; first, it ensures that discovery issues, anomalies and errors are not propagated into the main production CMDB server corrupting the data. Secondly, it also ensures that discovery and modeling activities do not cause production outages or hinder the business processes dependent on the data.
In most cases, this will require multiple CMDB instances to be deployed and tightly integrated together as a single system. Discovery, CI reconciliation and initial application modeling activities should be done in a dedicated instance (Discovery CMDB) and then populated into the Primary CMDB once reconciled and validated.
Below is a high level architecture example:
Another reason to consider a tiered architecture is due to limitations of the discovery process itself. For large organizations, a single CMDB discovery process may not be sufficient to discover the entire infrastructure in the desired amount of time. Depending on the CMDB vendor, the discovery process may either be an internal function of the CMDB or an external process run on a separate system(s). Even CMDB architectures that support multiple discovery process/probes may still require multiple CMDB instances to ensure that discovery activities can be completed in the desired timeframe.
Lastly, some consideration needs to be made for the discovery of areas within the organization that may be segregated either geographically or through firewalled or DMZ zones. In this case, it may also be prudent to run the discovery process within the remote location or firewalled area instead of from the Discovery CMDB server. This can greatly reduce the impact on bandwidth constraints and the management overhead on firewall rules (since a single integration point can be made from the CMDB or discovery process inside these zones to the external Discovery CMDB server.)
While many may say all of this is “overkill” and it can seem that the solution will become more complicated than needed, I assure you that these are some of the biggest issues we face with customers and some careful planning up front can prevent a wealth of issues down the road.
Defining the Scope, Depth and Breadth of Discovery
The first question usually asked by customers embarking on a CMDB deployment is “how deep or wide do I go with my discovery out of the gate?” This is a really great question and one that needs some consideration. Generally there are two different approaches depending upon the ITIL process that you’re going to be targeting with the CMDB data out of the gate.
If your focus is going to be on change management, then you may want to employ a “wide and shallow” discovery strategy that tries to cover as much of the infrastructure as possible, but doesn’t necessarily go as deep on the application component or sub-component level. Since the power of the CMDB for change management use cases is deeply rooted in the number of application models available to perform impact and collision analysis against, it is important to employ a discovery strategy that will allow for the broadest coverage of devices and fastest method for modeling applications.
If your focus is going to be more on the monitoring side, then you may consider a “narrow but deep” strategy that targets a smaller subset of the infrastructure (your initial monitoring targets) but discovers at a much more detailed level. This includes doing a deeper discovery of running software and application components down to a very granular level. You especially want to ensure that you are discovering as much detail as possible for the items you will be adding monitoring instrumentation to so you can track them for changes over time (this can be a great source of triage information when outages occur, see my blurb on “operational change” in part 1 of this blog).
Implement in Phases
No matter what discovery strategy you decide to follow, it is still recommended that you discover in phases and manageable chunks. Administrators can quickly become overwhelmed by discovery issues, invalid CI’s or a glut of bad or inaccurate data. Pick a slice of the infrastructure to focus on first, then slowly add discovery depth. Fix any discovery issues, anomalies or inaccurate data before expanding to deeper levels of discovery or additional slices of the infrastructure. Once the bugs and issues have been ironed out, it becomes much smoother to expand the discovery scope to other areas of the environment.
Also, do not fret if you don’t get everything in there right away. One of the biggest mistakes that an organization can take with a CMDB deployment is the notion that if you don’t have 100% of the organizations infrastructure discovered and in the CMDB, the CMDB isn’t valuable and can’t be relied upon. I strongly disagree with this idea and will state that having a CMDB that is 100% accurate and complete is in most instances an overly lofty goal and an unrealistic expectation. I have observed that the most successful organizations start by modeling their top 20 most critical business applications and then add from there. Even having this small subset available has proven very powerful in providing visibility into critical issues and avoiding outages as a result of poorly planned changes.
Thanks again for taking time to read my blog. I hope you found it helpful and informative. As always all comments, thoughts and suggestions are greatly welcomed and encouraged and I look forward to hearing your feedback.