Career Planning Model

One endeavor I took on earlier this month and glad I did was being a mentor for the Ascend USC Student Chapter. Each mentor gets grouped up with three undergraduate students along with another junior student mentor. Together all five of us meet as a group three times during the 10-week mentoring period, along with opportunities to have one-on-one between the students and the mentors during the same period.

One question that gets asked frequently by the students and probably being one of the main reasons why students seek out mentorship is the age old “What should I do after I graduate?” Or asked the other way around, “What do you want to do when you grow up?”

As a parent, I have hope and aspiration for my own children, but I also recognize this is a question that only the individually can truly answer. I, like the students when I was young, asked the same question multiple times while growing up, and still ask the same question from time to time. Personally, I have adopted a career planning model to help with this particular decision making process. I had talked about this model before with my children, so I presented the same model to the student mentees as well. It is a simplistic model of triangle with three basic considerations as the end points. (see the page 1 illustration in the PDF file)

The principle goes like this. I believe a viable career choice is a something that balances the “pull” or “reach” by the following three considerations. The basic considerations are:

  1. Talent: What are you good at doing? This is where your education, training, skills, and experience acquired all come into the consideration.
  2. Passion: What do you like to do? Your interests, aspirations, dreams, etc. What stuff motivates you? What r would you rather do when you have the time?
  3. MarketWho might pay you to do what you would like to do? Is there a market for the stuff you would like to or want to do? Is it financially rewarding or even viable enough?

I believe the job or career choices for most people will end up somewhere within the triangle due to those three basic considerations. Having a job or career that covers just one single consideration without addressing the other two is not practical for most of us. Having just two out of three considerations covered is doable but I think it usually results in a less than satisfactory job/career experience. For example,

• Situation One: Having just #1 and #2: Not economically viable unless you are financially independent enough. For most people I know, hobbies usually fall into this category.

• Situation Two: Having just #1 and #3: If your skill level is not there to maintain a certain base level of performance, you may not last very long on a particular job or in a career.

• Situation Three: Having just #2 and #3: If you don’t have some, minimum level of passion for what you do, the work itself is still worth doing but you may not be as aspired. Then again, it does the pay the bills.

When I explained this model to my children, one of them asked… What happens when people change jobs? Is it because of one of these three situations. Probably, but people also change jobs for a number of other reasons such as problems with the work environment, with the co-workers, or with the boss. This model cannot address those external factors just yet.

Another question came up was… Is this the only triangle where I will be confined to work with? How would I do something bigger and better down the road? Well, I think you will always need to work with these three constraints, but you will have more choices to work with as you become more experienced. As we grow older and acquire more experience, our own triangle expands as well (see page 2 of the PDF file). We will have more “room” to work with or have more job/career options as we expand the triangle.

Of course this is not the only or the best model of its kind. It is my own view of the reality. However, it is nice to know someone else also talks about a similar model – pretty cool.

Problem Management Process Design – Part 1

This is the first post of a series where we do the tutorial and some deep-dive of problem management (PM) process design. In this post, we will go over some of the process design considerations, such as the goals/purposes, the intended scope, problem prioritization, and roles and responsibilities. In the subsequent posts, we will go into more of the execution topics such as data capturing, process flows, as well as metrics and measurements.

Goal and Purpose of Problem Management

When designing an ITSM process, one of the most fundamental questions to ask is whether you need a particular process for your organization. By ITIL’s definition, a ‘problem’ is a cause of one more incidents. By managing problems, we are attempting to manage how we document, diagnose, and learn from the root causes after handling the incidents. Do most organizations need a problem management process of their own? I believe so. Even though most organizations may not have a formal problem management process defined, the act of diagnosing and finding root causes is practiced universally. Having a well-thought-out and documented process for root cause analysis can only help to strengthen the organization’s learning and knowledge management effort.

Scope and Policy Implication

In defining your problem management process, it will be useful to define a few scope or policy related items upfront. For example:

  • What organizational boundaries will the PM process be applicable to? Who can initiate, undertake, and/or authorize the PM activities? Like implementing most ITSM processes, the benefits will compound when everyone is adopting the unified approach and vocabulary. If you need to share the root cause data between organizations, it will be important to define the process scope beforehand.
  • Will all incidents receive the PM treatment? If you don’t plan to run all incidents through the PM process, what criteria will you use to decide which incidents to focus the PM effort on? Depending on the number of incidents you receive, practicing PM on every single incident may not be feasible, so you may need to be selective. Some organizations will initiate the PM process for incidents that meet certain criteria based on the incident priority (impact vs. urgency), the nature or category of the incident, the business segment affected, or some other factors.
  • It will also be useful to define what are some of the connecting processes to PM. Incidents, problem, and changes are typically closely tied to one another. What processes will trigger the PM process from upstream or receive the PM output downstream? Will your organization perform PM without having an incident? It is possible if you practice some type of proactive PM. Will all changes related to a problem be required to go through the change management process? Will the incident tickets, problem records, known errors, and requests for change be linked in some fashion? These are some governance related questions that will affect how you design the PM process.

Problem Categorization and Prioritization

When designing a categorization scheme for problems, I recommend using the same categorization for PM and for Incident Management. Having a consistent categorization for both problems and incidents will make designing, generating, and analyzing reports much easier. Some organizations use two separate categorization schemes for incidents and problems – a decision sometimes influenced by the tools. I personally think that is making things more difficult than it needs to be.

Prioritizing problems can help you focus your RCA efforts on problems that need the most attention. When prioritizing incidents, many organizations take the impact to the business community and urgency into consideration. For problems, I believe those two considerations are essential, and I would suggest adding two additional considerations into your problem prioritization matrix. The first one is the frequency of the incident. I think the higher frequency of the incidents; the higher priority should be assigned to problem. Also, the potential risk of not addressing the problems should also be taken into account.

Roles & Responsibilities

A PM process can involve a number of participants. Here are some typical roles to be factored into the design.

  • Requester: Who can initiate a PM exercise? How will the requester participate in the overall PM process
  • Problem Management Process Owner: The process owner ensures that the process is defined, documented, maintained, and communicated at all levels within the organization. The process owner is not necessarily the one doing the actual work but the process ownership comes with the accountability of ensuring a certain level of quality for the process execution.
  • Problem Manager: The problem manager is the main actor in the PM process and has the overall responsibility of implementing the PM process end to end, according to the process laid out by the process owner. The problem manager is also responsible for meeting the service level targets and reporting the metrics to the process owner for quality assurance purposes.
  • Problem Assignee: The problem assignee role is often played by the subject matter experts who does the actual RCA work and determine what the final root cause is. The problem assignee can also be assigned to ensure all changes get properly executed through the Change Management process.
  • Stakeholder: There could be several different types of stakeholders involved in PM exercise. At a minimum, the PM process needs at least one key stakeholder who can approve the handling of the problem records and the closure of the problems. The stakeholder could also act in a governing or mediation capacity when conflicts arise.

In summary, we just went over some of the planning elements for the PM process. We talked about why we want to PM in the first place, the scope of the process, how we categorize and prioritize problems, and the essential roles for executing the process. On the next post, we will go over the process flow and spell out more details for the PM activities.

Conference Planning How-To and Examples

One of the events I look forward to every year, other than my mom’s birthday and the anniversary with my wife, is the ISACA Los Angeles Chapter Spring Conference. Every year around March or April, several hundred participants take part in this three-day get-together at Hilton Universal City. Over the years, we have provided our membership with solid programs that have delivered great education values. At the same time, the organization committee has had many wonderful individuals who volunteered their time and made the conference event as excellent as it is today.

I first got involved with the conference organizing committee back in 2001. It was a much simpler event to plan for back then but has since gotten more sophisticated over the years. Even with its growing sophistication, the conference is still being put on by a group of volunteers, not by professional conference event staff. I surmise when you have great leadership and dedicated volunteers within the organizing committee, anything is possible. That said, we are no professional event planners and everything happens in the conference is an opportunity to learn and to fine-tune. For those of you who are planning or thinking about planning similar events for your organizations, I have something that might help.



I have posted two documents on this blog that give an overview of what we have to do for this annual event. If you don’t have such documents in place and would like to refer to something to start with, these two documents together could be a decent starting point. I had to remove the proprietary information from the original planning documents but the resulting documents can still be helpful. Putting on a conference is a project, and the typical project management principles and planning discipline can only help.

I hope you will find these documents useful for your planning endeavors. If you have any questions about how we plan the event or would like discuss any planning aspect further, please feel free to leave your questions here or contact me directly.

DIY Process Assessment Planning – Assessment Model, Schedule and Deliverables, Risks and Constraints

In the previous post, we discussed some process assessment planning considerations such as the problem definition, the scope (both organizationally and process-wise), and the analysis of the stakeholders. In this post, we continue and conclude the discussion with additional planning considerations on the assessment model, the schedule and deliverables, as well as the risks and constraints.

Assessment Model (Best Practices, Evaluation Process Integration, Organizational Context)

Using the information resources mentioned previously such as ITIL, COBIT, CMMI/ISO 15504, and ISO 20000, hopefully you would have constructed the best practice models and evaluation criteria to assess the processes and organization in scope. While an assessment spends a great deal of its effort in benchmarking and answering the question “Where are we now?”, it is just as important to start thinking and formulating the response for the question of “Where do we want to be?” In addition to coming up with the best practice model for the processes you plan to assess, I think it is also important to think about and include the following criteria into your assessment model.

  1. Integration between Processes: These days, the ITSM processes rarely get executed effectively in total isolation. The processes often need to inter-operate effectively with other related processes in order to gain a certain level of maturity. For example, I will be surprised to see a high level of maturity for the availability and capacity management processes, if the change management process has been determined to be weak in the same organization. For the processes you plan to assess, be sure to take additional inter-process relationships into account and assess the process effectiveness truly end-to-end.
  2. Organization Considerations: While understanding how mature of a process is and where you can improve is important, it is just as important to understand how the maturity score fit into the overall organizational context. For example, if the problem management process has been assessed to be highly mature but the organization places only a light importance on the process, the good maturity score will have only a limited significance. Hopefully from the problem definition exercise, you have already discovered what is really important to the organization so you can target your improvement plan accordingly.
  3. Benchmarking and Comparison: Benchmarking is the way to compare how your organization is doing relative to other similar organizations or environments. In-depth benchmarking data are often not readily available and something that is a value-add feature when you utilizing external consulting for the assessment. For DIY assessment effort, you may or may not feel compelled to compare your results to other similar organizations, depending on your problem definition. At the minimum, the assessment results can always serve as the baseline for you to compare to when you perform another assessment in the future.

Schedule and Deliverables

Just like any project worthy of an organization’s time and effort, the assessment effort should be run and managed like a formal project. The schedule and deliverables should be carefully planned and spelled out during the planning phase. Because the assessment will likely require participation from a broad array of departments and individuals, being able to communicate the timeline (of what will happen when and with whom) is something the sponsor and participants should expect to have upfront.

When constructing the schedule or formulating the deliverables, keep the following in mind as you plan:

  • What assessment techniques do you plan to deploy to gather the data? Will you use questionnaires or surveys? Workshops or focus groups? One-on-one interviews? Or a combination of two or more techniques?
  • The project should have a firm start date and an end date, with clearly identified milestones. The milestones should include at least the kick-off event, the beginning, reminder, and closing dates for the survey, as well as the presentation date.
  • Identify all potential meetings and schedule them in advance as much as possible. The assessment project will involve a lot of meeting invitations, attendee tracking, and calendar management activities.
  • Formulate a communication strategy and start laying out various communication artifacts and templates that will be used to target various stakeholders and roles within the project.
  • Identify the ITSM education needs and account for the workshops and training classes in the schedule. For most stakeholders such as the sponsor and survey participants, the ITIL Foundation level knowledge or awareness could be sufficient. For certain key participants who may need to provide more specialized information for the assessment, ITIL Intermediate level knowledge maybe necessary. For the assessor (you this case since we are talking about DIY) or anyone helping the assessor in constructing the surveys and analyzing the results, advanced understanding of ITIL and how various processes fit with one another will be required in order to perform the assessment tasks effectively.

Risks and Constraints (Time, Resources, Tools, Politics)

The assessment team should also identify any constraints or risks that could materially impact the assessment, negatively or positively. One typical constraint/risk is the key participants’ schedule and availability during the assessment phase. Considering the assessment’s results are heavily dependent of the quality and quantity of the input provided by the participants, not having the people you need at the time when you need them can pose a noticeable risk to the outcome of your project. It will pay dividend to figure out who you will need and what mitigation options you will have if you don’t get the people right when you need them and need to work around their schedules. Similar risks need to be identified with mitigation measures planned out accordingly during this phase.

After all these considerations are factored in, you should have sufficient information to put together a statement of work or an assessment project charter. The assessment charter will guide your effort and serve as the foundational governance piece as you move forward with the project. In the future posts, we will discuss kicking off the assessment, various approaches of collecting, validating, and analyzing the assessment data, plus presenting the finding and following up.

DIY Process Assessment Planning – Problem Definition, Scope, and Stakeholder Analysis

In the previous post, we talked about some potential information resources you can use to set up an internal ITSM process assessment effort. In this post, we will discuss some of the planning considerations that should be taken into account.

Problem Definition (Purpose and Opportunity)

It is always important to answer the question of “Why Bother?” In order for an assessment to produce meaningful results, it needs to address one or more business problems at hand. Document what are the drivers for conducting the assessment. Document why it is important to address the drivers now. Clearly identify what the organization or the sponsor intends to do with the assessment results. Once the purposes have been articulated with the agreement and support from the sponsor, the assessment team can use them as part of future communications to the stakeholders and participants.

Scope (Process and Organization)

The scope usually comes in two aspects, process scope and organization scope. An assessment can cover one or more ITSM processes, and the assessment purposes defined in the previous section should help to guide the scope definition.

The organization scope also needs to be defined for the assessment. Ideally an ITSM assessment should cover the entire IT organization but that may or may not be needed depending on the business problem you are trying to solve. Defining the organization boundary for the assessment can also be tricky partly because people and political considerations inevitably get involved. It is possible that the assessment will cover only a portion of the organization where the sponsor has more control over, infrastructure operations vs. application development as an example. When that happens, it is important to define clearly just how applicable the assessment’s scope is organizationally. That way, the assessment results will not be misinterpreted, and the follow-up action plans can be appropriately planned and executed.

For the process scope, the assessment should focus on assessing a process’ end-to-end effectiveness, or customer experience from the business perspective. It is quite possible that an overall assessment for a particular process will yield a score that may be different than what an individual team or organization expects. When that happens, it is important that the assessment can provide data to back up its finding or to explain the difference in expectation.

Also, don’t lose sight of the following. One reason to conduct assessment is to baseline what your organization is currently doing. Take advantage of the assessment opportunity to document the baseline performance of your processes, even for those which have had very little formal implementation or performance record.

Analysis of Stakeholders and Participants

Identifying and understanding the interactions stakeholders may have with the assessment is a critical aspect of the assessment planning. The stakeholders or participants of the assessment project can include a number of individuals such as the process owners, the IT staff, senior IT management team, key suppliers, and business customers. There are a number ways of mapping and understanding the stakeholders’ impact to the project. For most assessment projects, I would suggest thinking about the following factors. Customize the list further if your organization requires it.

  1. The stakeholder’s view of the assessment effort: Some participants feel strongly about the assessment for whatever reasons, and some feel less so. Try to gain a better understanding of the participants’ views towards the assessment.
  2. The stakeholder’s power to influence the assessment: Understand what role a participant will play in the assessment and how much influence they may have over the direction and execution of the project.
  3. The stakeholder’s work or responsibility impacted by the assessment: The assessment will have variable degree of impact to the participants’ work or functional areas. Take this factor, along with the view and influence considerations, you can gauge what impact a stakeholder may have on your project more effectively.
  4. The stakeholder’s need for communication or training: Understand and map out the communication strategy based on the information or reporting needs of the stakeholders. Some stakeholders will require periodic updates (say weekly) from the assessment team. Some participants may require more frequent or less frequent communication. Also understand whether the participants will require some form of awareness training or education prior to the actual start of the assessment activities.

At the next post, we will discuss the additional planning factors such as the assessment model, the schedule and deliverables, as well as the risks and constraints.

SACM and CMDB Tools – Strategy and Roadmap Example

Partly due to my track chair duties with the Fusion 12 conference, today’s post will be a bit light. I was going to leave the SACM and CMDB posts as they were, but I went ahead and put together a strategy and roadmap example deck. You can use the information presented in this deck as a starting point to formulate your own CMDB strategy and roadmap.

SACM and CMDB Tools – Strategy and Roadmap Example

As we discussed in the previous posts, the SACM process can enable and affect a number of other ITSM processes, so planning for it can seem overwhelming at times. My recommendation is to initially start with a well-controlled scope and focus on the value-added activities that can bring the quick wins. As usual, please feel free to comment or discuss anything directly with me if you like.

SACM and CMDB Tools – Implementation Considerations – Part 4

This post is the part four (and concluding part) of a series where we discuss the planning and implementation of a SACM and CMDB solution. Previously in Part One we discussed the fundamental considerations that should go into deciding whether to implement a CMDB solution for your organization. Part Two and Part Three discussed some of the planning considerations that will impact the quality of the CMDB solution. In this post, I will try to wrap it all up with some additional suggestions on the implementation approach.

Coming up with a CMDB implementation approach will be highly organization dependent. If you need something to start the planning process, I would suggest examining the following high-level approach and refining it with more detailed steps or activities.

  1. Do the homework. Examine the planning factors we discussed in the previous posts. Have a clear idea of what the organization hopes to accomplish with the CMDB data. Refine the scope. Determine how much data is really enough by balancing the information need/availability with the resources and effort needed. Depending on the size of the effort and your organization’s requirements, you may or may not need to formalize this as a funded project.
  2. Line up the right people for the CMDB effort. Explicitly funded or not, implementing CMDB should be treated as a formal project with activities and resources clearly identified and planned. Get the right people involved at the various stages. Help the people acquire the necessary CMDB knowledge before diving into the work.
  3. Work on the requirements and translate the requirements into data model designs. Collaboration with other teams is the key to success here. Don’t do the design in isolation. Work with you Enterprise Architecture team or person to collaborate on the design. The data model needs to have the necessary details so a number of things such as processes and tools can be designed around them.
  4. Select the tools that can handle your design or come very close to it. You will use the tools to construct your CMDB and figure out what support processes your team will need to maintain the CMDB. The tools will also help you populate the data into the CMDB the very first time and facilitate the on-going additions and changes.
  5. Towards the end of the implementation effort, you will need to train your CMDB administrators and the users who will interact with the tools. Once the tools go live, you will need to start gathering usage statistics and measuring the effectiveness of the tools and processes. Periodically check for results and validate your assumptions about how the tools and processes should work or behave like. Look for risks to mitigate and opportunities to extend the usefulness of CMDB to support other processes and business activities.

In addition, I would recommend another book “Step-by-Step Guide to Building a CMDB” ISBN-13: 978-0977811939 for implementation and reference purposes. The book goes into many details of planning and implementing a CMDB solution. I have outlined the high-level steps below, and the book is something to consider.

Stage 1: Assemble the Project Team and Define the Project

  • Step 1: Assemble Project Team
  • Step 2: Obtain CMDB Knowledge
  • Step 3: Create and Agree on CMDB Goals and Mission Statement
  • Step 4: Review and Define Benefits
  • Step 5: Build a Business Case

Stage 2: Define Requirements and Create IT Service Model Blueprint

  • Step 6: Identify & Review Governance Requirements
  • Step 7: Review and Select Supporting Best Practices
  • Step 8: Identify Requirements to Address Potential Problems
  • Step 9: Identify Inventory & Asset Requirements
  • Step 10: Define Service Catalog Requirements
  • Step 11: Define CMDB Requirements to Support Other Processes
  • Step 12: Define Configuration Item Level & IT Service Model
  • Step 13: Define Configuration Item Relationships
  • Step 14: Define Configuration Item Attributes
  • Step 15: Design IT Service Model Blueprint

Stage 3: Select CMDB Solution and Tools

  • Step 16: Select CMDB Solution
  • Step 17: Plan the CMDB Population
  • Step 18: Select Tools to Automate CMDB Population
  • Step 19: Calculate Project ROI

Stage 4: Construct and Maintain Your CMDB

  • Step 20: Construct Your CMDB
  • Step 21: Create Configuration Item Lifecycle Management Processes
  • Step 22: Build Support Processes
  • Step 23: Populate Your CMDB
  • Step 24: Train the CMDB Team and Users

Stage 5: Driving Ongoing Value

  • Step 25: Implement Measures and Metrics
  • Step 26: Create a Continual Service Improvement Program

Links to other posts in the series

SACM and CMDB Tools – Some Planning Considerations – Part 2

In the previous post of the series, we discussed what initial considerations should be taken into account when deciding whether your organization needs a full CMDB solution. Let’s say you went through the analysis and decided that a more functional CMDB solution is needed. You need the solution to have a better ability to assess the impact of a change, incident or problem on a service because your current analysis capability is not meeting the business needs. What other considerations need to come into the planning of a CMDB solution? I would suggest the following…

  • Scope: What data need to be captured, stored, and processed? What processes and activities will make use of that information? At this point, you should have some pretty good ideas how to answer those two questions, at least with some degree of precision. If you need a better handle on managing the changes within the data center, what sort of hardware and configuration information will you need to capture from the servers and the networking gears in the data center? Do your needs for CMDB/asset management involve needing configuration information from the client devices? If so, how do you plan to reliably capture that very fluid information? What processes do you plan to target the CMDB information for in the near term, just change and incident or more? What services or processes will the CMDB enhance in the long run? I would recommend start with what you absolutely need right now to show improvements in service and gradually build it up over time.
  • Data Model: Talking about what data you need conceptually need is one consideration. Translating those concepts into actionable data model design is another. I am a believer that a CMDB is an information cornerstone to an organization’s IT service management activities. I often compare how an ITSM system relates to IT as how an ERP system relates to an organization. The CMDB is the foundational information store for that “ERP” system for IT. With that said, it pays to implement the data model well upfront because frequent structural changes to CMDB afterward will easily kill the productivity you gain from using CMDB.

There are some potential benefits and understanding that can be derived from the data model:

  • How all CIs within the scope of the process relate to IT services provided to the business
  • How various total cost of ownership components are related to an IT service
  • How individual availability or capacity figures can relate to groupings of CIs and overall availability or capacity targets
  • Which CIs facilitate or enable which IT services
  • Prioritization of CIs in relation to disaster recovery or continuity management

If your organization has one, now is the great time to get in touch with your Enterprise Architecture (EA) folks and work on the data model. They should be your organization’s information and data architecture expert, and designing (or assisting in design) an ERP data model for IT should be the very part of their charter. Design a data model with a long-term end in mind. Try to put into as much forethoughts into the design as possible. The data model should remain structurally stable for the most part, with an occasional addition or removal of fields or attributes. If you find yourself needing a brand new entity or object in the schema due to legitimate business needs, that is OK, too. In any case, my experience tells me data model design is something to be taken very serious of, because it frequently plays a big part in making or breaking a CMDB effort. Get some competent, professional help and start collaborating across the organization boundaries.

  • Roles and Responsibilities: Who is your configuration management process owner that has the overall accountability for governance matters with access to senior IT management team for escalating policy discussions, if necessary? A CMDB manager role should be named and responsible for managing the operational activities of the process and ensuring integration with the other service management processes. The process owner or its delegates need to work on developing the CMDB data model (with EA’s help), the core policies, maintenance processes and procedures, key performance indicators and producing ongoing management reports.

Also, another important topic to work out is the data ownership issue. Another word, who will own which portions of the data in CMDB? Naturally, I think it is most productive for the organization when the CMDB data repository structure is centralized. Does that also mean the CMDB care-taker team will also be able to own all data within CMDB? By owning I am referring to the acquisition, maintaining, validation, and reconciliation of the data. Will your CMDB team or the server admin folks manage the server device data in the CMDB by themselves, or will there be some kind of collaborative arrangement in place between the CMDB team and the server admins? How about the ownership for the networking device data in CMDB? How about the ownership for the application specific information in CMDB? The data modeling exercise may give us more insights into what data we need. I would strongly recommend the data ownership issue get thoroughly reviewed and agreed upon during the planning phase.

In the part 3 of the series, I will discuss more planning considerations such as Control and Verification, Key Performance Indicators, and Awareness Campaign, Communication & Training. Planning for a CMDB solution can be a complex but also a fun and educational exercise. You are doing the organization a great service by fulfilling its on-going need for great information and knowledge to carry out its mission. Do this value-add project well by planning ahead and think things through.

Links to other posts in the series

SACM and CMDB Tools – Initial Considerations – Part 1

Those who have implemented configuration management (CM) practice would agree that implementing a robust CM discipline with the accompanied tools is no trivial task. The assets we acquired and deployed in IT can be massive in number and sophisticated in complexity. Keeping track of things coming in and out plus all the on-going changes can be tedious and error-prone when doing it manually. That is one major reason why we look to a SACM/CMDB tool to reduce the complexity of managing those IT assets. At the same time, a lot of people I talked with have indicated that CM is also one discipline that is usually the least mature in many organizations, when compared to other ITSM processes. Intuitively most of us would agree CM is something we should do well, and properly implemented tools can only help. How should we approach this complex issue?

For the sake of simplicity, I am going to use the term CMDB as the general, overall reference to the SACM and CMDB terms and concepts in this post. In ITIL V3, SACM is much more comprehensive, and they are not the same as CMDB. That is fine. For many organizations, we are still struggling to get the basic CMDB stuff down, so that is what this series of blog posts will target.

I believe the first of two questions to ask is… “Do we know what a CMDB is?

This question may sound basic, but it is worth asking because there are widely varies opinions on what a CMDB is. I believe a data repository, which tracks and manages the inventory in the IT infrastructure with key attributes such as asset tag, description, location, owner, user, etc., is a CMDB in itself. The inventory list may be rudimentary, but it nevertheless contains the configuration items (CI) that a full-fledge CMDB tool would keep track off. With that assertion in mind, we can see that many organizations have a lot of those inventory lists in our environment. Not surprisingly, everyone seems to keep a set of those inventory lists for the stuff they own or operate. For example, the server admin folks have a set of servers, physical or virtualized, that they manage with a bunch of details about those servers. The DBA folks have a similar list for the databases under their management. The application folks have something similar for their application portfolios.

Many organizations also have asset management tools installed for their finance department, and those tools track the financial lifecycle of those assets for depreciation or accounting purposes. Many of those assets such as computers, equipment, and software are also used in IT with location and ownership information. Sure they are not well connected with each other so that you can extract the relationships between various items, but they do exist. The truth is… every organization has a number of inventory lists or assets databases that contain, in reality, CMDB information.

Now we have some ideas on what CMDB information we have. The second question to ask is… “What do we need a CMDB for?” In addition to tracking the inventory and financial information about those IT assets, do you have a genuine need of…?

  • Performing more informed impact assessments for incident and change management activities? The relationships documented between the items in CMDB can be a valuable tool for understanding what impacts a change or incident can have on a particular system or application. When one component changes or breaks in the IT environment, a good CM practice and system in place will highlight how the change in state affect the rest of IT environment. With the localized CMDB info, the relationships are sitting in each technology owner’s head, and that has always made assessing changes and incident a labor-intensive activity. The assessment can also be less than precise or accurate if you don’t have all the necessary people involved with the information you really need.
  • Facilitating systems upgrade or platform retirement? A comprehensive CMDB, with the full view to all applications and correctly documented relationships, can easily facilitate the analysis when considering introduction of the new applications, retirement of the old applications, and even changes to the overall enterprise architecture.
  • Optimizing financial and capital expenditure planning? By having the full financial information available for all CIs, it will be easier to plan or project the upcoming financial obligations in expected hardware leases, software license fees/renewal, and maintenance contracts.
  • Contributing to service continuity or contingency planning? By having a comprehensive list of CIs and a full picture of the environment, it makes easier to identify the essential, needed components or systems quickly during a disaster recovery or business continuity scenario.
  • Making changes more visible and accountable for the operations and service delivery functions? The change history attached to each CI can provide valuable insights or trigger the attention by IT Management into changes that might have data protection, regulatory compliance, or other operational implications.
  • Facilitating compliance adherence or audit obligations? Your organization or environment may have special legal or reporting requirements beyond what the typical spreadsheets and inventory lists can provide.

Once you have identified the needs and understand what you have to work with, you can make a more informed decision on how to bridge the gap. After all, the CMDB information is useful and productive only if:

  • The CMDB is the central data repository for all configuration items we want to track in the organization, plus
  • The CMDB has the data we can reasonably store and manage well, and
  • The CMDB is the TRUSTED source and is used by all IT disciplines

Buying and implementing a full-fledge CMDB tool is not the only way to plug the gap. The gap can also be filled by marrying various CMDB sources you have on-hand with some well-designed middleware mechanism that provides the integration between the CMDB sources. Of course, the gap can also be filled by strengthening what you have with more robust processes and solid discipline. It all depends on what your business really needs. In the next post, we will explore some planning considerations that can go into what does it take to build a CMDB if you find yourself really needing one.

Links to other posts in the series