CHAPTER 12. Building a Configuration Management Team
Every significant endeavor requires some kind of organization to balance the workload of the team. For configuration management, there is plenty of work to go around, so it is important to clearly define the roles that will help the team operate at maximum efficiency. One set of skills is needed to plan the effort and document what a complete configuration management solution will look like. Additional roles are needed to move the solution from the dream into reality by implementing configuration management for your organization. After implementation, a new set of roles will take over as stewards of the process and tools to actually achieve the business results expected from all the effort. Finally, throughout the lifecycle someone needs to look after the quality of the effort, making sure that the organization’s goals don’t get lost in the daily grind of getting the job done.
Chapter 8, “Implementing the Process,” touched briefly on staffing the configuration management team, but it didn’t go deeply into the skills and job descriptions that you want to include. This chapter provides much more complete detail on each role to be played in the overall configuration management effort. Figure 12.1 displays the visual outline of the chapter.
Figure 12.1 Different roles are played at different points in the overall program.
So, what makes an adequate definition of a role? There are three primary aspects to defining any role—a job description, the set of skills needed to succeed in the role, and the responsibilities of the person in the role. The job description should be succinct, descriptive, and helpful in understanding the job described. The set of skills includes not only the technical skills, but also the business skills needed to get the complete job accomplished. The responsibilities should be consistent with the needs of the process work in fulfilling the overall configuration management effort. Many people are familiar with the RASIC model where you define a set of tasks and assign individual roles to be Responsible, to Approve, to Support, to Inform, and to Consult on that task. If your organization is familiar with this model, it can be a helpful tool to organize your team. Each of the following role definitions includes all three of these characteristics.
But creating a configuration management team is much more than assembling a group of individuals. Much has been written about the need for a vision in bringing groups together, and in configuration management this is definitely the case. Every member of the team must understand the big picture of what is being accomplished, must see the business value of accomplishing it, and must be committed to do whatever it takes to achieve that value. Most parts of building the team will fall on the configuration management architect as the technical team leader, so it is extremely important to choose an architect who has the ability to work with people, along with the technical skills to guide and direct the configuration management effort.
Planning Roles
The first set of roles to consider are those needed to plan the configuration management effort. Typically, these are people with higher skills to get your program off to a solid start and to build a foundation for solid progress for years to come. Note that although these roles are designated for planning, they will be important through all the lifecycle phases. The project manager, for example, will be needed during implementation and occasionally during operations as significant enhancements are being made to the configuration management process or tools. These roles are introduced here because they are all necessary in the planning phase of the work.
Configuration Management Architect
The configuration management architect is the technical leader for all configuration management efforts. The key job of the architect is to define the overall configuration management solution, including people, processes, and technology. A secondary job is to lead the technical team that will implement and later operate the solution. The architect should be well respected for both technical depth and leadership skills by both the team and the stakeholders. Clearly, the architect role is a key job for the overall configuration management effort and should be staffed very early in the planning phase. In the IT Infrastructure Library (ITIL) literature, this role is called the Configuration Manager, but I’ve chosen to provide the architect title to indicate the level of thinking required to fill this role.
The configuration management architect should be deep in configuration management, but broad in information technology (IT) topics in general. Although it isn’t critical to know every nuance of every environment, understanding the key pieces of information in almost every IT domain is certainly helpful. For example, the configuration management architect may not understand the intricacies of every routing protocol, but should understand the importance of a router in the network and what impact a router failure could have in delivering IT service. In addition to this technical breadth, the architect should also have the skill to understand business cases, know the value of configuration information, and participate intelligently in the tradeoff discussions that are an inevitable part of determining scope. Clear written and spoken communications skills, and the ability to relate well to both management and the technical team, are also necessary in the configuration management architect. To have had time to gain all of these skills, the configuration management architect is likely to be a senior technical person with at least ten years of IT experience.
The responsibilities of the architect reflect the broad range of required skills. From the beginning of the project, the configuration management architect participates in the requirements discussions to ensure that all requirements are understood and can be technically achieved. The architect has primary responsibility for the scope and granularity discussions, and documents the results of those discussions, as described in Chapter 3, “Determining Scope, Span, and Granularity.” The architect must then work with the process engineer and the requirements analyst to ensure that the configuration management process is defined in a way that meets the requirements. Finally, the selection of a Configuration Management Database (CMDB) tool is the primary responsibility of the architect. In producing the project architecture documents, the configuration management architect considers all these work products: requirements, scope documents, processes, and technology. This overall solution architecture furnishes the guiding principles for the implementation team.
The following table summarizes the configuration management architect role:
Requirements Analyst
The requirement analyst (RA) role is specific to the planning and implementation phases of the project. As the name implies, the main job of the requirements analyst is to gather and manage the requirements around configuration management. Requirements are critical because they are the best way to understand and document the value of the configuration management effort to the overall business. The requirements engineer is not a configuration management specific role, but someone who might come from a general pool of system engineers. After the requirements have been documented and agreed on by all stakeholders, the role of the requirements analyst is needed only if changes to those requirements are desired. Once implementation is complete, this role is no longer needed.
The key skill for a requirements engineer is the ability to understand the business and imagine the value of configuration management to this business. This involves many people-oriented skills, such as interviewing business managers, communicating with executives around overall business strategy, and facilitating group discussion with those who will use the configuration management data. Standard systems engineering skills such as requirement elicitation, traceability analysis, and requirements management will also be important for this role. A good requirements engineer should have a broad technical background to understand how to take the business-oriented requirements and drive them down to overall system requirements in the areas of performance, reliability, compliance, and manageability. This role should be staffed with a seasoned technical professional with at least five years of experience.
The first responsibility of the requirements analyst is to conduct a workshop in which representatives from all stakeholders come together to define and refine the business requirements for configuration management. This workshop is generally seen as the kickoff for the project and should be sponsored by the senior IT executive, but planned and run by the requirements analyst. The requirements analyst is also responsible for documenting the business requirements that come out of the workshop and working with the technical team to refine those business requirements into system requirements for the overall configuration management solution. After these lower-level requirements have been adequately documented, the requirements analyst leads a series of reviews to make sure that the implementation team understands and agrees with the requirements of the total system. Throughout the lifecycle of the project, the requirements analyst should be available to handle changes to the requirements caused by new understanding of the project or changes in the business climate.
This table summarizes the role played by the requirements analyst.
Process Engineer
A process engineer also should be employed during the planning phase of the configuration management project. The key job here is to make sure that the total process—including the part automated by tools and the part done manually—is documented, refined, and implemented. The process engineer works alongside the architect to take a “big picture” view of the effort, but specializes in documenting the key workflows and control points rather than worrying about the infrastructure and tools that are used to accomplish the work. The process engineer role is needed primarily in planning and early implementation.
Business skills are more important than technical skills for a process engineer. The ability to see the business value of configuration management and arrange people and tools to meet those needs most efficiently is the most important task. This requires broad knowledge of the business, an understanding of the culture and roles involved, and the ability to assimilate this knowledge into a cohesive process. Other specific skills required include architectural thinking, process engineering techniques, and the ability to work with a wide variety of people. The process engineer should not be a dedicated configuration management expert, but rather a strong process engineer who has the ability to create processes in a variety of business contexts.
The primary responsibility of the process engineer is to define and document the configuration management process, but the work certainly doesn’t stop there. All processes, by definition, are at a high level. The process engineer is also responsible for working with the implementation team to help document lower-level procedures, which will fill in the gaps on how to execute the process. As these procedures are developed, the process engineer is responsible for training one or more trainers and helping to develop a curriculum to teach the entire organization how to do configuration management. The process engineer is also responsible for establishing some objective measures of the effectiveness of the configuration management process. These measures will be used throughout the organization to show the business value being gained by the process and to make incremental improvements as the organization matures.
The process engineer role is summarized in the following table:
Project Manager
The project manager rounds out the configuration management planning team. As would be expected, the project manager coordinates and organizes the actions of the architect, requirements analyst, and process engineer. The project manager role is not specific to configuration management, so no further description is needed here.
Implementation Roles
Implementation is always a transition phase between planning and production. The configuration management project is no different. The following roles reflect this transitory nature, as they are important for a short while during the actual implementation of the process and tools but then become much less important. All operational roles described below will be present during implementation as well, but the following roles are dedicated just to implementing the system.
Logical DBA
The Database Analyst (DBA) role is important throughout the entire configuration management effort, but in transition there is a specific role to be played by the logical database analyst. In the planning phase, the architect created some high-level diagrams to show the scope and granularity of the intended CMDB. The role of the logical DBA is to take these diagrams and turn them into a full database schema that can be implemented by a specific tool. From the high-level diagrams to the actual database description language that will implement the schema, everything related to making the scope and granularity real in software is the domain of the logical DBA.
The most important skill for the DBA is database design. The ability to effectively organize attributes, configuration items (CIs), relationships, and categories into a set of entities and relationships is critical for the overall success of the project. Other skills needed for the complete DBA are a good understanding of the selected CMDB tool, strong communication skills, and the ability to read and understand the system requirements. The logical DBA role should be filled with someone who has at least five to seven years of database design experience.
The responsibilities of the logical DBA are straightforward: Design the perfect structure to hold the critical configuration management data. The DBA begins by attending the scope and requirements reviews in that planning phase to get a good understanding of what the database needs to contain. Then the DBA pulls together a draft design and sends it out for technical review by several other competent database designers. After incorporating changes, a business review is conducted to ensure the high-level business requirements are going to be met by the proposed design. Finally, the DBA commits the design to software and oversees testing and actual implementation of the database schema in the tool.
This table summarizes the DBA role:
Communications Person
It makes sense that you need good communications around your configuration management efforts, but does this really warrant a full person? For a large organization, it might take more than one person. Communications is essential to getting the agreement of all business units to support IT in making the CMDB a success. The communications person is a very visible role that makes sure everyone understands and agrees to the goals and functions of the configuration management system. Without adequate staffing for this role, someone else (most likely the project manager or architect) will try to fill it part time and won’t give it the attention it deserves.
Only two skills are needed for a communications person—deep understanding of the business and strong ability to relate technical plans to business leaders. But these skills are not necessarily common. People with a deep understanding of the business—including the current political currents, the unwritten organizational structures, and the personal interplay between business leaders—are not exactly common. It is usually best to choose as communications person someone who is well-thought of in the business community, and this person may not necessarily be the normal IT spokesperson. But be sure the communications person also has the ability to quickly catch the vision of what configuration management is and is not. Unfortunately, many businesspeople have heard the latest hype from the IT department too often and no longer believe in the promises of value throughout the enterprise. The communications person has to understand the IT speak and be able to translate it to the real business value in terms that are believable and compelling.
The responsibilities of the communications person fall into two different categories: defining the message and sharing the message. The communications person begins with getting into the heads of the configuration management architect and the project manager. Getting a deep understanding of the scope and effort and the kinds of business decisions that will be enabled will definitely help in understanding the overall value of configuration management. After the heart of the project is well understood, it is time to look at the schedule and resources in conjunction with the project manager. While the communications person will be telling others about the scope, they also will be answering many questions about the more practical aspects of how and when the project will impact the business units. The third step in preparation is to really understand where to find the most valuable audience and schedule meetings, web page updates, newsletter articles, and any other communication forms that can reach those audiences. Having a detailed plan that targets the entire audience in manageable segments will help ensure complete coverage of the message, and thus, more complete acceptance of the program. Finally, after all the preparation, the communications person should have some fun with sharing the message—be creative, enthusiastic, and even a little silly. Use the best aspects of the corporate culture to get the message out there as best as possible.
Here is a summary table for the communications role:
Trainer
Depending on your organization, the communications person may be able to also train all the people who need to use the configuration management system. For larger organizations, the trainer is a separate person. Regardless of who fills this role, the trainer has a great opportunity to influence the acceptance of your configuration management process and tools. Because they get to interact with all of the users, they can be an effective cheerleader for the entire effort, or they can be the corporate equivalent of a wet blanket. Just as with the communications person, the trainer must understand and believe in the vision in order to effectively teach others both the how and the why of the process and tools.
The trainer requires the technical skills to learn the tools, the business skills to learn the process, and the communications skills to effectively teach both of these skills to others. The technical skills become important because even with the best-tested software, it is likely that some student will try something unexpected with the configuration management software. If the trainer gets confused or doesn’t know how to recover, everyone gets the message that this new software is difficult to use and confusing. The business skills are equally important because it is critical to not just explain the tools and the process, but to relate them to the actual business areas represented by people in the class. Someone from accounting may not care at all about this IT discipline of configuration management until they realize the value of understanding the “total cost of ownership.” The need for communication and teaching skills is obvious to anyone who has endured a very boring corporate training course.
The responsibilities of the trainer are simple: Prepare the training materials, organize the courses, determine the training delivery method, and then deliver the training. The duration of the training role will be determined by the number of people to be trained, the frequency of changes to the process or tool, and the job turnover in your organization. Even in the most static organizations, refreshing the training from time to time will help keep configuration management a vital and maturing process.
The following table describes the trainer role:
Operational Roles
Although all of the previously described roles are important to getting set up, it is the people in operational roles who will determine the long-term success of configuration management for your organization. Unlike the planning and implementation roles, which have a (hopefully brief) time of importance, the operational roles are permanent. One key factor in the success of long-term operations is the understanding of the process and the tools gained by the operational team during the implementation. For this reason, the operational roles should be staffed fairly early in implementation so that they can be a significant part of the deployment effort, and therefore have ownership in the longer term success of the effort.
Configuration Management Integrator
In any IT organization, multiple data sources must be brought together to create a complete CMDB. At the very minimum, you’ll have some data about people, perhaps in a corporate directory or a legacy human resources system. But you’re also likely to have some asset data in one or more inventory scanning tools, some data about the locations where your company does business, some software license information, and perhaps some information about the IT products that have been purchased—all in separate databases or applications. The job of the configuration management integrator is to oversee the regular transfer of data from all external sources into the CMDB. The integrator, as the title implies, worries about getting all the data, transforming it to a common format, and then populating it in the right place in the configuration management tool. This role is also described in the ITIL literature as a configuration librarian.
The key skill for this role is data integration. This involves a broad knowledge of the various technologies used to get data out of systems and push it into other systems, including XML/XSL, SQL, and the query languages of whatever corporate systems your organization uses. This person must also be detail-oriented and patient to massage large data sets into a format that will be acceptable to the CMDB. There is nothing exciting or glamorous about changing a list of names from “last name, comma, first name” format into “first name, space, last name” format, but without someone to do this work, the data in your configuration database will quickly become a confused jumble that provides no business value.
The responsibilities of the configuration management integrator are many. She must be a detective to find sources of data that others may not have thought of. The configuration management integrator becomes a salesperson to convince the guardians of corporate data to turn it over to this new effort. Then she becomes an accountant, poring over rows and rows of data to look for inconsistencies and discrepancies. Finally, the configuration management integrator becomes a watchdog, guarding the integrity of the data against anyone who wants to transport a mess they’ve been holding without cleaning it up first. In addition to all of these roles, the configuration management integrator has the day-to-day job of scheduling when the various input feeds will reach the database, checking the logs to ensure they run successfully, and correcting any errors that are found. The configuration management integrator will be a very busy person indeed.
The following table summarizes the role of the configuration management integrator:
Configuration Management Tools Support
Because even the simplest of organizations needs an automated tool to support their configuration management efforts, you also need someone to support that tool. The tools support person helps in selecting the tool, is responsible for installing the tool, and then does all the things necessary to maintain the tool. It is unlikely that you will program your own configuration management tool, so you will most likely have a vendor organization to help the tool support person. But there are certain tasks that cannot be done by a vendor, and a whole variety of tasks that the vendor’s service organization would charge you too much to perform. Thus, you should maintain at least one person, and perhaps several, who are deep experts in the tools of configuration management.
The skills needed in tools support are among the most technical and specific. This person needs to understand the tool, any middleware required to run the tool (including the database management system), and the operating system on which the tool is going to run. In many cases, you will want to run your configuration management system in a clustered or other highly available environment, so your tools support person should at least be familiar with the specifics of supporting the tool in those kinds of environments. Unless your organization is very large and has dedicated people for support of the server hardware, the configuration management tool support person may have to be knowledgeable of backup and recovery mechanisms and other general hardware operating concepts. The tools support person typically comes from a background of desktop or server support.
The responsibilities of the tools person are simple—keep the configuration management tool available and running at peak performance at all times. This often involves troubleshooting, planning and executing software upgrades and patches, performance tuning, and evaluating new versions from the vendor. Occasionally, the tool support person will also get involved in significant new projects, such as refreshing the hardware under the system or perhaps even moving to a more highly available architecture. In general, the tools support person acts as the guru for anything related to configuration management tools.
This table summarizes the tool support role:
Reporting Specialist
By its nature, configuration management data is complex and difficult to visualize. Although many people will have some knowledge of how to get things out of the CMDB, one person will know the data in great depth and be able to access just the right information very quickly. That person is the reporting specialist. As the name implies, the reporting person will take business queries such as “How many dual-processor servers do we have capable of running the next DB2® version?” and turn them into queries that the database can process. This person is part requirements analyst and part programmer so that they can interpret what business users are asking for and get the system to produce the right data.
The key skills for a reporting specialist are listening and data manipulation. Like the configuration management architect, the reporting specialist must listen to the language of business and translate what he hears into the technical terms needed to get the right data. Like the configuration management integrator, this person must also be able to understand the structure of the data in the CMDB and relate the various pieces of data together to extract meaningful information in the most efficient way possible. Using this combination of listening to the users and navigating the data, the reporting specialist can be a critical and very busy member of the operational team.
The reporting specialist has two broad classes of responsibilities. The first is creating reports that will be executed repeatedly. These standard reports typically have a wide audience and need to be well-defined and easy to read. A large block of standard reports will be created during the implementation of the configuration management process, but additional reports will most likely be needed along the way as the process gets refined and the data becomes more useful. Creating the standard reports and overseeing their execution and distribution are all in the domain of the reporting specialist.
In addition to standard reports, the reporting specialist will most likely need to build ad hoc or one-time reports. Ad hoc reports are useful for many different events in the normal business cycle. Making IT decisions, such as when to refresh servers, requires some configuration information, and thus requires an ad hoc report. Audits often spark queries for specialized data that can be gained from a one-time report. In many cases, these one-time reports need to be created quickly to ensure timely response to a business need. Although the standard reports are more widely read, the ad hoc reports are most likely more urgent and more important. The reporting specialist must have some free time available to handle these requests when they come.
This is a summary of the reporting specialist role:
Impact Manager
Although all the previous roles are fairly common in IT, you need to find a different person to staff the role of impact manager. The impact manager is the person ultimately responsible for making sure the relationships between CIs are accurate and helpful. The impact manager populates data that will help all other IT decision makers to better understand the impacts of a proposed change or a current incident on the overall IT infrastructure. As an example, you will probably learn from an automated inventory discovery tool that a particular server is connected physically to a particular hub, and that the hub in turn connects to a router. The impact manager is responsible for digging deeper to understand that the server hosts your inventory ordering application and the router connects to the primary business location of your purchasing staff. Any proposed change that causes the hub to be out will mean that your company cannot order replacement inventory. The role of the impact manager is to bring the business sense to the mass of information in the CMDB, and to code that business knowledge into the relationships stored in the CMDB.
The impact manager should be skilled in understanding all primary functions of the business. They need to be able to communicate freely with each set of IT consumers to really understand the value of IT to the overall business. Skills such as systems analysis, business analysis, process evaluation, and financial management are the key ingredients to a good impact manager. The technical skill of capturing the discovered relationships into the CMDB can be learned, but the business skills should be hired.
The responsibilities of the impact manager are likely to evolve as your configuration management capability matures. Initially, the impact manager will mostly find facts and capture data. As the database gets more accurate and thus more useful, the impact manager will be called on to help evaluate any significant change or ongoing problem. Later on, the impact manager will fade to the background as more of the relationships are documented in the CMDB and users gain confidence in using this data directly without an interpreter. The impact manager never fully goes away, however, because each new project will add another web of complexity that needs to be assessed and documented.
The impact manager role is summarized in the following table:
Quality Role
Over the life span of your configuration management effort, the quality of the process and the data determine the value of the work. The quality role is described last, but it is one of the most important roles. The quality person uses all the tricks available—audits, inspections, reviews, and more—to make sure that the overall configuration management process has integrity. Acting as a guiding conscience, the quality manager validates that the plans developed early will lead to a quality system, then checks that the implementation is done according to the plan, and finally monitors the process and the data in an ongoing basis to make sure that everyone can be extremely confident in the value of the information that is your CMDB.
The quality manager needs skills very much like those of other quality assurance or quality control professionals. The most important are a driving passion to make the project a success, the independence to speak up when things are going wrong, and an eye for details that others might overlook. Quality can sometimes become a very lonely role, so it is critical that the person chosen for this role have strong support from management and a good ability to handle confrontation constructively.
The responsibility of the quality manager is simple. She simply has to make sure that everything about the configuration management process, tools, people, and data is top notch. This involves watching how people work, looking at the outcome as represented in the data, analyzing the process to see inefficiencies, and auditing everything to make sure there are no organizational failures. The role will mature over time and eventually can be included in a shared IT quality department. But to begin, the quality manager should be a specifically named individual who everyone on the configuration management planning and implementation teams should recognize.
The following table summarizes the quality manager role:
Some Notes on the Roles
To close this chapter, let’s observe a few things about these roles. First, we’ve represented a fairly large and complex team. Depending on the size of your enterprise or the complexity of your scope, you might not need a dedicated person for each role. In fact, some roles can be combined in a single person as long as that one person has all the skills needed. It wouldn’t be unusual, for example, for a single person to be both the reporting specialist and the impact manager because those are related roles.
For very large organizations with a high degree of complexity, additional roles might be needed, or different aspects of a single role might be split among multiple people. You might have one project manager to focus on getting the tools and processes ready, for example, and a second project manager focus on data integration and population.
To move from these role definitions to a specific staffing plan, you need to use the process work you’ve done to create more specific responsibility lists. Then estimate the number of hours per week needed for each responsibility, and you will begin to see how many hours of work might be required. Don’t forget to account for vacations and other work absences that are normal in your organization. Divide the number of hours needed by the number of hours a typical IT person works for your organization, and you’ll get a good picture of how many people should be on your team.
When you actually start to put people into the team, some flexibility will be required to account for different skill mixes. You might have defined a specific job position that puts the trainer and the communications person roles together, but if you cannot find a single person with both sets of skills, you might have to rearrange your staffing plan. Figure 12.2 shows graphically how you build a staffing plan.
Figure 12.2 The staffing plan springs from a clear understanding of the roles and responsibilities.
Also note that the roles described in this chapter are limited to IT people or people working directly with the core configuration management team. There are many roles outside the team that will be impacted by configuration management. Change coordinators and change approval board members need to understand how to use configuration data to assess the impact of the changes they are proposing and reviewing. Incident managers and people who resolve incidents will likewise learn to use configuration data in assessing the severity or impact of IT incidents. Department leaders will get new understanding of which IT components are servicing their business functions, and this new knowledge will enable their decision making.
Although all these people, and many more, could be said to have roles in configuration management, they are extant roles that are simply augmented by the existence of configuration data. The people in these roles are important for the communications and training plans, but not the staffing plan.
Finally, you should think a bit about how the configuration management team will be organized. During planning and implementation, they will most likely be organized as a project team, with a project manager and architect taking the lead. Governance of the team will be accomplished through your normal project governing practices.
When you move into production operations, however, there are some decisions to be made. Do you create a department for configuration management, complete with a department manager? Or do you put the configuration management people into an existing operations department, such as the server administrators or the service desk? To some extent, these decisions are dictated by your corporate culture, but in general the configuration management team should be as closely related to the incident and change management teams as possible to allow the synergies inherent in ITIL.
Obviously, no book can tell you how to build out a staff. Hopefully this chapter has at least given you a basic outline of the skills and roles you should be thinking about as you build a configuration management organization.