Kelly Summers, CHCIO, SVP & CIO, Maricopa Integrated Health System

In previous articles I have promoted the application of the ITIL (Information Technology Infrastructure Library) framework as a cornerstone to a well-run IT organization. The current minimum certification for ITIL is referred to as ITIL v3 Foundation. This basic certification offers a common set of vocabulary, vernacular, and processes when referring to IT Service Delivery. Over the last 10 years, I have mandated that my entire IT organization achieve this basic certification.

  We must look at automation, especially in the arena of discovery and technical entity relationships to aid us in managing our complex environments  

A critical component of ITIL is the development of a CMDB, or Configuration Management Data Base. It’s not my objective to train the reader on ITIL, however, a key to the principles are contained within the CMDB. Each system component, be it infrastructure or application is referred to as a CI or Configuration Item. CI types can be Hardware, Software, Databases, Communications/Networks, etc. A large system may be comprised of multiple CI’s that end up representing all the configurable items for a system or application.

I needed to give you the basic background and why this information is so critical, before discussing the supporting tools and automation required to generate it.

Unfortunately, most of our IT organizations are not as disciplined in manually maintaining these types of design documents that aid in support, trouble shooting, or re-design and replacement activities. The reason is likely that this work is laborious to begin with and even more challenging as applications and systems move down their legacy lifecycles of release and change management. In a perfect world, we would have all of our CI’s defined at initial deployment and then we would keep them documented and updated as our systems work their way through their respective lifecycles.

All of us are continually challenged with the ongoing complexity of our environments and unfortunately, we’re also challenged to maintain operational costs, so we likely cannot grow our staffing to manage this level of administrative documentation. We must look at automation, especially in the arena of discovery and technical entity relationships to aid us in managing our complex environments.

We must rely on automated “discovery” tools that can build these relationships for us and orient them into a repository for easy search ability and root cause analysis in support of our IT service management abilities.

Upon my arrival at the Maricopa Integrated Health System no such legacy documentation existed. We were faced with aging and obsolescence within all of our technology portfolios. I needed a fast way to identify every device that had an IP address, every application and component on the network AND its relationship to each other, in an application oriented hierarchy. I needed an automated way to generate my CMDB!

I quickly identified a tool that would allow for the automated collection of both physical and logical infrastructure and application data. This approach also needed to include data “traffic” that was flowing into/out of these applications.

After the initial automated discovery efforts, that data then was presented to both IT and Business/Clinical leadership to validate 1)All of the component’s “CI’s” of the application or service; 2)Identification of an IT and Business Owner; 3) Its Application Tiering, meaning was it a Tier 0 (Foundational), Tier 1 –“Mission Critical”, Tier 2 “Business Critical”, etc.; and 4) Its associated service level expectations, etc. The following graphic highlights a Tiering Matrix:

Once that data was validated, it was then migrated into our comprehensive IT Service Management application, which does include a Configuration Management Data Base “CMDB” component.

Now, any IT or business person for that matter, can easily search the CMDB for their application, its relative components, etc. This is truly invaluable from an IT Service Management perspective when performing maintenance upgrades, etc., since now we can “see” every component and its relationship to each other to ensure our testing strategy and coverage includes all components of an IT managed service.

I truly believe that the ability to do this electronic and automated discovery is the only realistic way we as IT leaders can truly have the up to date reconnaissance on our application’s portfolio and their interdependencies that will drive our opportunities for improved IT configuration management and control yielding higher valued IT service delivery.