Why are CMDB’s so hard? Some thoughts to set you up for success:

Back To Resources

Let’s take this back a step and just remind ourselves of what a Configuration Management Database (CMDB) is supposed to be. The CMDB was born in the days of ITIL v2 when Configuration Management was introduced as a formal process within the framework.

The goal of a CMDB is to provide a repository that can be deemed authoritative for all the things an organisation cares about, there are philosophical debates and discussions about what a ‘thing’ is but they are separate from what a CMDB is intended to accomplish. Normally a ‘thing’ would be a server, a piece of network equipment, Desktop PC or Laptop and even things like HVAC systems and in some cases, we’ve seen Laundry equipment and lightbulbs be stored there.

Whatever a customer wants to track, apply Change Management processes to or deems important enough to reference on an ongoing basis likely belongs in a CMDB. 

Once defined the next step is to work out what information you actually want to hold about those things, the attributes of interest. Many CMDB tools will come with a prebuilt data model for this but that doesn’t mean you have to follow that data model in your situation. The normal guidance would be to adhere to the provided model and deviate only where you need to and I would go along with that approach. In fact, in previous lives, I’ve had many conversations with organisations around how to fit esoteric devices into the packaged data models and 99% of the time we’ve found a home with appropriate attributes provided out of the box, so don’t overthink how unique your requirements are as it might be they likely aren’t.

Only store what you need to meet the needs of your consumers, what do I mean by consumers? Well, think about how the data in your CMDB is going to be used within the business, what reports, processes or activities will make use of your CMDB data? These are what you are building the CMDB for, do NOT fall into the trap of ‘dumping everything into the CMDB’ and then ‘working out what you’ll use it for later’. All that happens is your data will build up, become stale and be deemed useless and die on the vine. Your CMDB WILL fail, and by fail I mean it will not be used for the purposes it was created, data will not be maintained, you will not find owners for the data held in it and thus it will be seen as a problem rather than a solution to business challenges.

Do not over promise. Building a CMDB is a significant undertaking and requires effort, quite a lot of effort to be fair, this effort is from all areas of the business not just IT or the Configuration Management team. Consumers have input, Configuration Managers are the control point, data providers also contribute significantly to the implementation. Everyone has their role to play and this alone makes the implementation of CMDB ‘hard.’

Critical to the success of building and maintaining your CMDB is a Configuration Management Policy. One of the key elements here is defining what ‘things’ are interesting enough to be stored in the CMDB, with this in place everyone has a common understanding of ‘if’ something should be in the CMDB and then expectations are managed and set appropriately. Of course, this is not a one-time definition and depending on your situation you will want to review the criteria of ‘interesting’ as and when you deem fit. Critically, do not leave this on the shelf, keep it alive, keep it refreshed and keep it relevant.

The key to CMDB success is truly being transparent, communicative and sharing the vision of what Configuration Management means to your organisation, the contribution it will make and the value it will bring. Never lose sight of the value!

This is the first in a set of blog posts we’ll be making on the topic of CMDB. In our next thrilling instalment, (I know you are all on the edge of your seats!) we’ll talk about managing the stakeholders, strategies for on boarding and also how do you look after, feed and water the beast you are creating and keep it happy so it can continue to provide the value your organisation is investing in.

That’s it for now!

Stephen Earl, Product Manager

About Cloudhouse

Avatar photoCloudhouse is experienced in problematic application migration and config monitoring systems to fix the unfixable and modernise any IT estate – whether it’s run on-premises or in the cloud. With two proven solutions; Alchemy: Cloudhouse Application Packaging Solution modernises IT estates by fixing unfixable apps and moves them onto a supported operating system.



Load More

FREQUENTLY ASKED QUESTIONS

Commercials
How much does Cloudhouse cost? Down Arrow

Cloudhouse costs are split into two elements – the licensing required to deploy application compatibility packages, and the professional services needed to create the application compatibility packages.

Licensing is offered on a per user basis for desktop applications and a per server basis for server applications. There are discounts available based on volumes.

Professional Services costs are dependent on the nature and complexity of the application. We quote a cost for packaging once we have been able to see the application, or portfolio of applications.

Contact us here with your requirements and we will provide you with a quote.

Packaging and Maintaining Applications
Who is responsible for packaging desktop and server applications? Down Arrow

Cloudhouse provide the Professional Services to package applications.

Requirements for Test and Development Down Arrow

Cloudhouse recommend packaged applications are tested in the standard UAT environments used for natively installed applications, or applications packaged in App-V. The more representative the test environment is of the live environment, the greater the chance of finding any issues prior to go-live.

Updating Applications Down Arrow

Service packs and updates can be applied to the applications in a package using the Editor, refer to Updating, Editing and Maintaining Containers which describes how a new snapshot is created for the update, and how it is then applied to the package.

Operations
Who manages Cloudhouse operationally within an account? Down Arrow

Cloudhouse recommends the same team who manage the operations of native apps.

Automation and Deployment Down Arrow

Applications running in Application Compatibility Packages can be deployed, and managed with same tools, or scripts used to deploy natively installed applications e.g. SCCM, InTune, LAN Desk. Please refer to Supported 3rd Party Products and Versions for details.

Support
How do we know which of our departments/ teams should support the Package? Down Arrow

The Cloudhouse Package does not include OS components, it only contains the packaged application plus Cloudhouse components. Cloudhouse recommend the same team that is responsible for supporting applications packaged with App-V, or delivered as natively installed applications, support Cloudhouse Application Compatibility Containers.

Documentation for Service Desk & Service Management Down Arrow

Full documentation is made available to Cloudhouse partners and customers as required.

Training
Do Cloudhouse provide training? Down Arrow

Cloudhouse offers a full packaging service that can scale to meet any requirement. In the event, however, that a partner wishes to offer application compatibility packaging as part of a wider solution, Cloudhouse will work with that partner. Please contact us here for details.