Discovery: Master Inventory…Really, it’s more than just a server list?

By Matt Brown

‍

Why take the time to write an article on “inventory”?  It’s such a simple and mundane topic.  Just list your CI’s in the most left column and include your descriptors to the right, right?  “Not so fast, my friend!” (as I channel my inner Lee Corso).  A true “Master Inventory” is a dynamic data set that evolves and matures throughout the transformation lifecycle.  It should be a source of truth that includes numerous elements to help organizations make decisions.  It is the most important work product for any transformation/migration project.  If it’s inaccurate or incomplete, it can wreak havoc on a project creating tremendous disruption for the business.  This is precisely why so many migration boutique companies are investing millions into purpose-built migration repository tools.   

Let’s talk about the components of solid Master Inventory.   

Asset List 

The attributes for this list are pretty standard and typically most CMDB extracts will give you what you what you need.  But let’s be honest, very few organizations have a CMDB that is more than 75% reliable.  So how do we obtain this information?  I recommend taking a 3-Point approach: 

• Point 1: Electronic Discovery Tools 
• Deploying an electronic discovery tool (or set of tools) to collect information is a great way to get a view of what’s active on the network.  See our earlier article, Discovery, Not all Tools are the Same, for additional information.  
• Point 2: Physical Inventory 
• Electronic discovery tools are great, but what about unknown subnets or protected zones that the tools may not be able to scan?  A physical inventory will provide a complete picture of what’s on the data center floor that can be compared with the output from Points 1 & 3 to find gaps.  See our earlier article, Physical Inventory?  I thought we were talking about Cloud?, for additional information.    
• Point 3: Hypervisor and/or Cloud Extracts 
• For virtual workloads, all hypervisor or public cloud hosted instances can easily be extracted for inclusion.  This is the simplest, quickest, and most accurate way to obtain asset information for all virtual workloads.   

Now that we’ve got four or more data sources (the 3-Point approach + client provided data), we need to do a cross comparison, identify gaps, and then go into an investigative mode to remediate those gaps.   

Application List 

Once again, a lot of the application profile data required here can be found in the CMDB attributes.  However, when it comes to transformation and migration, the Context information that is gathered through an interview process is what must be documented an included.  See our earlier article, When It Comes To Migration, Context Matters, for additional information.   

Services (Cloud Specific) 

This will apply to organizations who have implemented SaaS and/or PaaS solutions.  Nearly every organization subscribes to some type of SaaS service today.  And that service is integrated into the service stack that IT provides to its business.  While these services are not migrating/transforming, the internally hosted applications may be, and therefore coordination with these services will be required.  I advise my clients to utilize some type of electronic application mapping tool which will note a communication point leaving the on-prem data center.  From there, it’s a manual discovery process that involves the application development team, procurement, and perhaps business analysts.   

PaaS is actually a bit easier to document.  This can be gained completely from reviewing the provider statement as well as the obtaining read only access to the cloud console.  From there, many of the same tools clients use to perform app mapping on-prem can also be used in public cloud.   

Database List 

This one is frequently overlooked and requires more manual effort to collect.  Some electronic discovery tools that perform application mapping can provide this (typically agent-based or service call tools) information.  Also, DBA’s will be able to provide this information through various tool sets depending on the database platform.  However, manual manipulation will be required to show correlation and association to hosts and applications.   

Performance Data 

In years past, most migration projects had a fundamental guiding principle…”As Is”.  After all, you were moving a workload to a new location, so let’s minimize any ancillary changes to reduce potential impact to the business.  With transformation and cloud migration projects, that principle is fading in importance.   In order to build the appropriate architecture and right size the instance type for cloud, having baseline of average and peak usage for Disk, CPU, and RAM for at least the previous 6 months are now basic requirements.   

Ok, so we now know what components are needed to create a solid and accurate Master Inventory.  Job well done!  But the work does not stop here.  No client’s environment stays dormant for long.  The components and attributes of those components are going to change and evolve throughout the lifecycle of the project.   

If you’re a migration/transformation consultant, it’s time to get fully integrated into your client’s change management process so you can keep up with new adds, decommissions, and changes throughout the lifecycle of the project.   

If you’re a client, this is the perfect time to update your CMDB and refine your change management workflows so that all of that hard work and money spent can pay residual dividends.   

‍