Well, actually vice-versa! The configuration management database (CMDB) is a hot topic these days in IT. With my arrival at Forrester, I am ambitiously building upon the solid foundation of thought leadership my colleagues have built on CMDB. One topic I wish to address is the notion that people (yes, you and me) are configuration items within the whole CMDB discussion.
When people talk about CMDB, they usually refer to infrastructure components as CIs. In some more enlightened cases, they accept that applications and business services are also CIs. As we assemble all of these CIs into cohesive views of our world, we need to include another critical domain — us.
That’s right, no view of the IT or business landscape is complete without considering the roles of the people. Some of us are technology support, some are users, some are external customers, some are executives, and some are outsourced service providers. In the context of business services, we are integral elements to the service definition.
Some will interpret this concept of relegating people to CIs as cold and demeaning. This is certainly not my intent, but when you realize that we are all cogs in the greater business machinery, it quickly becomes apparent that we are normalized at some structural level to business impact strikingly similar to infrastructure. That’s not cold, it’s just the way it is in a sound service model. It doesn’t mean anyone is any less witty, charming, or warm.
Although each role has unique definitions, we all have common characteristics that describe who we are, where we are, how we fit into the organizational structure, and why we are qualified (or not) to perform certain duties. These are all CI attributes, just as a server has a CPU type and physical memory capacity. The role-centric attributes are then extensions to the CIs, hopefully extended using object-oriented metadata to allow inheritance of the core attributes. Once we accept humans as CIs, we can then relate everyone in the CMDB and properly portray services.
So, where should we store all of this human CI data? The answer for most of us is that we already ARE storing it. Talk to your HR department. They most likely have a fancy software package like Peoplesoft that contains records on everyone who has ever worked in the company, agency, or institution, including more details than we’d all like them to know. This is an extremely rich data source for the CMDB.
As you continue to build out your CMDB and determine opportunities to federate the CMDB into a more comprehensive and flexible configuration management system (CMS), build federation to the HR database. As in any well-designed federation, you do not need to extract every detail. You just need those details relevant to the CMDB use case. With HR data, what you need should be limited (e.g., name, department, reporting chain, title).
To further determine roles and authorized actions based on those roles, you must then augment this basic HR data with (hopefully) consolidated authentication, authorization, and accounting (AAA) and single sign-on technologies. This particular facet of the human CI equation is still immature in many organizations, but it is quickly gaining recognition as a requirement, driven mainly by governance, risk, and compliance (GRC) demands.
So, the next time you are hammering out the details of your CMDB, don’t forget us — all of us!
Check out Glenn's research.