For more than a decade now, the Configuration Management Database (CMDB) has been heralded as the “single source of truth”. It’s been touted as the “end all, be all” for the converged corporate asset inventory.
Indeed, companies have poured significant manpower, computer resources, and money into trying to build a central repository. But many have failed. Some have been marginally successful, sure. But only a relative few have achieved the promise of a complete and credible inventory.
Even for those who have reached the pinnacle of CMDB excellence, the on-going costs of management and maintenance have become unfeasible.
Common CMDB Frustrations
Speaking to countless IT and security professionals over the last two years, I’ve discovered an alternative narrative taking place in the market.
While ITSM groups within companies continue to expand their teams and eat up a larger share of the overall IT spend, many consumers of the CMDB have become increasingly frustrated and disillusioned with this commonly accepted approach. The number of security leaders among the Fortune 1000 now searching for alternative solutions has grown to epic proportions.
Why is this happening? Because the CMDB was never intended to be used as an asset inventory offering. The CMDB’s original intent was for managing each asset as a configuration item (CI) — not to provide a complete view into the asset or even to discover that an asset exists.
Somewhere along the way, someone had the idea they could transform the CMDB into an asset inventory platform. On the surface, this idea has merit. In truth, CMDBs do have many of the key ingredients needed to construct an asset inventory, including a scalable database, the ability to ingest and structure data, as well as search and reporting functionality.
That said, I have many examples of costly, incomplete and/or failed attempts to build a usable asset inventory from the base CMDB platform. The most common statement I hear in the market in almost every discussion with security practitioners is, “We can’t trust the accuracy or efficacy of our current CMDB.”
5 Elements to Evaluate
While the CMDB platform isn’t an asset inventory solution out-of-the-box, it’s feasible to build inventory functionality around the CMDB. As companies try to obtain a complete, credible, and fully contextual asset inventory, the first and ultimately most important decision that must be made is whether to build vs. buy.
Here are five critical elements that companies should consider as they approach the solution to the problem.
1. Speed: Fully functional asset inventory platforms are purpose-built. Time to value is extremely low. In fact, the buy situation should yield a platform that’s deployed in hours and days — not weeks, months or years.
How long would it take to build similar functionality in a DIY model? Experience suggests at least 24 months, and six to 10 full time engineering resources. The various efforts, from requirements gathering and selection of talent, to the acquisition of tools and the development efforts themselves, can all be lengthy, difficult tasks. As Maverick said in Top Gun, “I feel the need. The need for speed”.
2. Execution risk: Buying purpose-built software means the platform is already developed, built with numerous customer environments and edge cases in mind, and most importantly “field and production” battle tested.
What percentage of customer software development efforts occur on time and under budget? What’s overlooked when companies make the decision to build vs. buy? As they say, the devil is in the details.
3. True cost to develop: Design, planning, development, QA and testing, ongoing support, various staff and skill set types. Not to mention hiring, training, and retaining that staff. And the tool and environment costs to procure, deploy, and maintain. How often are ongoing costs to maintain software under-estimated? When has any project come in on time and under budget?
Most companies are simply not experts in developing custom tools for internal use. Often the final, true cost ends up being multiples of the original plan.
4. Opportunity cost: What’s the core business of an IT department inside of most companies? Are you in the business of selling more widgets? Or in the business of building an asset discovery and inventory platform? Ultimately, internal resources from various IT teams must be repurposed from other projects and important tasks.
As Isaac Newton’s Third Law of Motion states: For every action, there is an equal and opposite reaction. The same is true for building an asset inventory. Companies either have to pay for additional resources, or they pay for service degradation on other projects as they pull staff away to build a new platform.
5. Diversity: Buying an existing platform in the market means companies can benefit from the input of many clients feeding ideas into the platform vis-à-vis the numerous engagements and customer feedback from real-world environments. This is contrary to the singular view of an individual company trying to build a similar solution.
As Lucius Annaeus Seneca once said, “A gem cannot be polished without friction, nor a man perfected without trials.” The same applies to the build and evolution of an asset inventory platform. Perfection comes from the steady and continuous cycle of listening to customer needs and building new requirements into every version release.
As your organization contemplates how to tackle asset discovery, visibility, and management problems, keep the above in mind. If your journey leads you to the decision to buy a tool in the market, you’ll be presented with a different set of questions and requirements. I’ll tackle the key characteristics to look for when choosing a suitable vendor in my next blog post.
