So many stakeholders... providers, consumers, interested parties... oh my!

Back To Resources

In May, we introduced the topic of how to be successful with Configuration Management Databases (CMDB) this is the 2nd in our blog series on the topic and in this post, we’ll be going over how to onboard and manage stakeholders into Configuration Management.

As a Configuration Manager, one of the expectations many have for your role and the processes and tools you support is that they will be a magic bullet and solve the world’s problems. Of course, we all know this is an unreasonable expectation! Configuration Management is a supporting set of processes and tools which enrich everything they interact with. Because of the disconnect in expectation vs reality, it is important that those that own Configuration Management processes and tools are clear about the role they play.

Onboarding new groups, teams or tools into the Configuration Management ecosystem can be fraught with challenges. The largest obstacle to overcome is usually ensuring that people understand that Configuration Management owns very little data, whether that is published into the CMDB or consumed by the consumers of the CMDB. Data is owned, and always owned, by those that publish it – if there are issues or errors in data then the owner must be accountable for resolving the errors.

The needs of Configuration Management are varied and onboarding new groups who have sources of data you need is critical as the goal is to enrich and provide the highest quality data to the consumers. BUT you must ensure you are not onboarding providers of data for the mere sake of doing so, you have to have a consumer for any data you onboard, otherwise, things will get messy fast! it is easier to add data than take extraneous data out of your Configuration Management tools.

Based on this, it is important to ensure your Configuration Management Policy contains clear criteria for data onboarding – When do you research new data sources? How will you assess potential data sources? You must also ensure the data you onboard is ‘worthy’ of inclusion in your Configuration Management data published for consumers. Is it reliable? Is it appropriate? Is it of sufficient quality? All these questions need to have guidelines for assessment to provide the quality data your consumers expect and deserve.

Onboarding consumers of Configuration Management is more difficult than providers of data because you need to understand their needs to a detailed level. If you don’t take the time to do that your CMDB and other tools will become cluttered with data your consumers don’t need. It is critical that when you onboard new consumers, you have a structured methodical approach where you build close relationships, and understand the processes they expect your data to support and the touchpoints between you, your data and their needs. Ideally, as a result of onboarding a consumer, you should be able to build a map between each attribute of data and the consuming endpoint. Yes, you will most likely have multiple consumers for a given attribute. This is a GOOD thing! The more shared data in your ecosystem, the more supportive of the business needs your Configuration Management becomes and thus is seen to be delivering core business value.

So to summarise: onboard data from providers only when you have a use case to fulfil for that data; understand the consumer needs, what the data means to them and the work they are trying to achieve with the data you are providing; keep a map of consumers vs the data you hold; and keep in touch with both providers and consumers to ensure value delivery for your organisation.


Next time we’ll discuss approaches for managing your CMDB and Configuration Management practices ‘in-life’ so you continue to deliver value and also ensure Configuration Management remains relevant within your organisation.


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


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.

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.

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.

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.