What Data Do You Really Require?
In the recent months I have been involved in the delivery of a number of baseline services and it has been rewarding to see that we not only have a product that does what it says on the tin but also a team of consultants who know very well what it takes to achieve what the customers want. As a project manager I can see how our experience has grown in delivering those services and I am glad we now have a delivery framework that lets us do those things almost in our sleep.
What I have realized though is that customers find it a bit challenging to qualify their requirements – which configuration items will be required for let’s say a software audit project? They’ve seen Foundation and what it’s capable of but they find it hard to sit down for a moment and think about what they REALLY REALLY want from the vast amount of data Foundation can offer.
Foundation can discover a large variety of configuration items and most likely not all of them are needed for the customer’s specific project. In my opinion the service would be more efficient if we narrowed down our discovery and reports to a small set that is fit for the purpose of baselining. Clearly customers see value in discovering every element of configuration in their infrastructure and are tempted to say ‘discover everything and then we will decide what we are going to use’. It is a bit like going to a shop in the January sale – too much choice makes decision pretty difficult.
The danger is that time and effort is spent unnecessarily trying to achieve 100% coverage on attributes that are not required for the initial baseline purpose. Unnecessary effort might be spent analyzing large amounts of data and understanding potential gaps in attributes due to lack of permissions to hosts. Quite often resources are being called into the equation by customers trying to remediate access issues until they realize the attributes they were trying to discover were not required in first place.
Although we do deliver baseline services in a matter of days, I believe customers take quite a bit of time during the service to understand, digest the data and then select the set of CIs required to meet their objective.
Recently we put together a little toolbox to help customers in two ways:
- define the baseline they require by selecting a set of configuration items/attributes and dependencies;
- assess the data completeness once the first scans of infrastructure were performed.
The main benefit of performing this data assessment is the added transparency over the attribute/dependencies coverage on the discovered hosts from one single dashboard. The project team can take action if necessary to remediate the gaps that are due to lack of permissions or commands on discovered hosts and see the progress reflected as new scans are performed.
And finally the service will be delivered a lot quicker and more efficiently allowing the customer make confident use of the data within days rather than weeks. Stating the obvious a baseline service is not a full deployment and it will deliver amazingly quick results as long as it’s used the proper way.
For details on the data completeness assessment process and tools visit our data completeness assessment howto

