The ‘Chicken and Egg’ of IT asset auto-discovery…

  by Charles Rattray | 28 Jun 2007 | Permalink | Featured, IT Management

The ‘Chicken and Egg’ of IT asset auto-discovery…

In the world of IT asset auto-discovery we face a giant hurdle. That is the growing realisation that not knowing what we have is the first barrier to providing better IT. As any business leader can confirm though, barriers cost money and entering a new phase of IT efficiency and operational excellence will no doubt carry some cost. Our failure to justify the cost of IT asset auto-discovery is usually the first reason raised in defence of doing nothing. The return on investment is difficult to justify prior to expenditure and the net benefit even harder to articulate. That said we do meet visionary people in our industry who are willing to push their organisations into bringing together disparate IT teams to reap benefit from shared investments and solutions.

…but they face further barriers.

Most large business organisations have spent many years decentralising IT, giving autonomy and power to local users and business units, and pushing design choices further away from the CIO’s office. Technology purchasing decisions are being made further down the corporate food chain, while the power behind the technology itself continues to go up. At today’s prices, a business service generating a multi-million pound revenue stream may be running on technology costing only a few thousand pounds. This technology can be replaced cheaply and quickly, so why should anyone worry too much about how it is configured and where it is deployed. If it breaks, we just buy more.

Throw Service Management into the mix and we introduce the blue-eyed boy of IT, attempting to unite technology teams with promises of service maturity. New processes threaten to disrupt kingdoms and service management tools serve to prove just how un-enterprising most IT departments have become.

Some IT shops are bouncing back with a push to re-centralise and benefit from economies of scale and knowledge sharing in the provision of shared IT services. To be successful though still requires accurate knowledge of what assets are out there…

In order to understand what is out there, there must be a simple approach to joining the dots across disparate systems, infrastructures and organisations. Usually each system is surrounded by security and design foibles. These limit how we can get to them and capture the asset and, of course, the configuration details we want to know about.

People make the world complicated too. Power, political domains, and teams in silos, all require careful communication, bridging, inclusion and owner permission to access their kit. Often, access is only provided once the ‘what’s in it for me’ question has been addressed.

All of these issues or barriers aside, the biggest problem then becomes – “where do we begin?” Creating a CMDB seems like a good starting point. The CMDB underpins all other service orientated activity, and once we know what we want to record, designing the repository is relatively straight forward. Well, maybe not. A CMDB holds attribute data about a variety of different classes of configuration items. The only thing in common between these configuration classes is that they have attributes, and usually, multiple instances.

So we have hit another barrier – the design and enterprise approval of the CMDB, and we are still no closer to discovering what assets are out there…

We might adopt a different approach and think instead about what service we want to provide to our internal business customers. If we can determine this we can determine the policy and processes we need to agree and implement to make IT function like a business. Another good starting point, but again this requires a comprehensive design activity to build the required service processes, or at least, an undertaking to adopt known service management best practices across the organisation.

So far we’ve counted 3 barriers to discovering what’s out there: cost, technology and process. Interwoven among these barriers is the ‘people effect’. Some might argue that people represent the fourth barrier, but let’s not go there. While we negotiate any or all of these barriers time is passing, and meanwhile, it is most likely that no benefit has been realised either from point-in-time asset audits or from our attempts to build the larger solution.

An alternative approach might be to deal with the easy part first – automatically discovering the IT assets we have, and gaining immediately from the benefits this provides.

If we choose the right auto-discovery tool, our investment is minimal, and our future options plentiful. Two clear features of the ‘right’ auto-discovery tool must be the ability to configure which attributes we discover for each class of configuration item, and the ability to distribute and integrate the captured data with our future choice of CMDB. A third core feature of the right auto-discovery tool might be the ability to relate discovered data to vendor and product reference data thus multiplying the value of our initial purchase. Then we can be confident that the commitment to these tools provides extended returns on investment.

In adopting this approach, and assuming the auto-discovery tool is straight forward to deploy, we can quickly get to the benefits stage. From collective experience on customer sites, there are two immediate benefits of deploying an auto-discovery tool prior to implementing the CMDB and service management processes. The first is that we can explore which configuration attributes are important and determine how they will be captured. This may sound obvious, but often CMDB products record attributes because the CMDB designer thought it made sense to do so, and not because the data has value to the IT team.

The second benefit to adopting an auto-discovery tool first is that the act of automatically collecting the data relieves the infrastructure and application teams from maintaining their own inventories. It also means that they don’t have to first agree on the service management strategy or the supporting solution – both extremely time consuming and costly processes. Instead, they can free up resource to focus on providing effective decisions and actions, and thus deliver true customer satisfaction.