We hear a lot of talk these days about KPAs and ITIL process areas. KPAs (Key Process Areas) are used to help develop and measure the benchmarked standards of ITIL and are a good way of measuring your organization’s ‘maturity’ level within an ITIL process area (such as Configuration Management

KPAs apply to a repeatable maturity level. In the Infrastructure Technology Infrastructure Library (ITIL), a repeatable maturity level means that the most important processes have been introduced and the effective structure of the IT process in question is predictable, and the provision of its IT-related services is repeatable.

So what about KPAs associated with Configuration Management? The main purpose of Configuration Management is to establish and maintain the integrity of products that are subject to or part of IT services. Configuration Management involves the identification of the relevant hardware and software components that need to be put under configuration control. Changes to the configuration are evaluated with respect to the service level agreement and with respect to possible risks for the integrity of the configuration.

A Configuration Management plan covers the Configuration Management activities to be performed, the schedule of the activities, the assigned responsibilities, the resources required (including staff, tools and computer facilities) and the CM requirements and activities to be performed by the service delivery group and other related groups

With all these things in mind, you may be able to develop and benchmark your Configuration Management KPAs using the following questions. Remember that each question has three possible answers of (1) consistently (2) inconsistently (3) never. Which category your answers fall into will quickly steer your assessment of configuration management maturity as either consistent (repeatable), inconsistent or having no organized approach

Try your hand at some of these questions and see how your organization ranks against best practices.

Keep up the good work until next time.

Also, Don’t forget to register for Evergreen’s change management webinar: Take Change Management from Firefighting to Fire Prevention

Don

  • Is a Configuration Management plan prepared for each service according to a documented procedure?
  • Is a documented and approved Configuration Management plan used as the basis for performing the Configuration Management activities?
  • Is a Configuration Management library system established as a repository for the configuration base lines?
  • Are the products to be placed under Configuration Management identified?
  • Are action items for all configuration items/units initiated, recorded, reviewed, approved, and tracked to closure according to a documented procedure?
  • Are action items for all configuration items/units initiated, recorded, reviewed, approved, and tracked to closure according to a documented procedure, by an automated process or toolset?

Posted in: CMDB  Tags:

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
DonCasson posted on August 21, 2007 22:54

So you’ve thought things through now and you think you’re ready to begin working on a CMDB. Whether your motives are centralized change management control, the need for a standard set of configuration items or just improved change governance – you know the organization needs it.

The next question is where to start. As the white rabbit told Alice in ‘Alice in Wonderland’ – “I’ve always found it’s helpful to start at the beginning.”

So start at the beginning - by developing a strategy, one that surveys the industry, defines the critical elements of your CMDB and tailors the process to meet the needs and IT ‘maturity’ of your organization. Who knows, you might even want to develop a ‘model’ that could provide a roadmap towards your desired ‘end state’?

So here are a few ideas about how to ‘start at the beginning’ by developing your CMDB Strategy:

  • Review current ITIL Change and Configuration Management ‘best practice’ thinking.
  • Review ‘whitepapers’ written by some of the sectors’ leading CMDB software and solution vendors. Just remember that some of the white papers are written by vendors that may have an agenda.
  • Review the functional attributes critical to the implementation of a CMDB and evaluate them against the ‘fit’ with your business.

Attributes that you may want to consider include:

  • Reconciliation (the ability to rationalize one or more instances of a CI that is discovered and determine that they are the same item and that their relationships are identified are accurate.)
  • Federation (which enables multiple data sources to be brought together to represent a coalesced view of a defined level of data.)
  • Mapping and Visualization (which provides the ability to illustrate logically and physically the hierarchical and peer-to-peer relationships between CIs.)
  • Synchronization (which provides the ability to update the CMDB with approved changes).

Next time we’ll discuss benchmarking your organization against industry best practices. Until then, remember, start at the beginning…

Don

Also, don’t forget to register for Evergreen’s change management webinar and learn how to Take Change Management from Firefighting to Fire Prevention

Are you trying to build a business case for a CMDB? Download Evergreen’s newest white paper on the subject: “The Business Case for Change and Configuration Management and the CMDB”.

—–


Posted in: CMDB  Tags:

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Last blog I talked about CMDB and its relationship to overall Service Level Management. What about is relationship to ITAM and Asset Management?

Oftentimes enterprises believe that if they have an asset management database, they also have a CMDB database. There is a fundamental difference and an important link.

IT Asset Management is the discipline of managing finances, contracts and usage of IT assets throughout their lifecycles for the purpose of maintaining an optimal balance between business service requirements, total costs, budget predictability and contractual and regulatory compliance. ITAM activities include the management of inventory, software licenses, vendors, procurement, leases, warranties, cost accounting, retirement and disposal.

The goal of Configuration Management, on the other hand, is to provide a logical model of the IT infrastructure that is accessed by all ITIL processes, the purpose of which is to drive consistency among them. Configuration activities include identifying, controlling, maintaining and verifying the versions of configured items (CIs). CI information should be stored in a single repository, or a Configuration Management Data Base (CMDB).

So here’s the link - the only difference between a given component in an asset management database or a CMDB is whether it is considered an ‘asset’, a ‘CI’ or both. The difference is only determined by what you do or plan to do with that component.

A component should be considered an ‘asset’ if you decide it is worth managing a contract, cost or usage attribute, throughout its lifecycle. In other words, does that component have an asset that is calculated ‘on the books’, such as software licenses or hardware maintenance contracts?

A component is considered a ‘CI’ if you decide it is worth managing operationally for incidents, problems, changes, releases, capacity, etc.

So there are three points to my ramblings:

  • If the same component can classified as both an asset and a CI, it can be managed for both administrative and operational purposes.
  • An asset management database is an important underpinning to the development of CMDB database.
  • ITAM and ITIL’s best practice Configuration Management share the need for reliable data about components in the IT environment. Thus discovery tools (a scalable means of keeping accurate data on deployed components) and a CMDB (a repository for reconciling and accessing the discovered data) can serve both ITAM and Configuration Management.

ITAM and ITIL are both key IT improvement processes and all IT processes that rely on and contribute to CIs are dependent upon an accurate CMDB to provide best practice service level management.

So I’ll say it again- what is good for the CMDB is good for ITIL and overall service level management. And it starts with an asset management database.

So what do you think?

Don

Also, don’t forget to register for Evergreen’s change management webinar and learn how to Take Change Management from Firefighting to Fire Prevention

Are you trying to build a business case for a CMDB? Download Evergreen’s newest white paper on the subject: “The Business Case for Change and Configuration Management and the CMDB”.


Currently rated 5.0 by 1 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

In my last blog I laid out the proposition that Configuration Management and a CMDB is all about Change and that CMDB and Change are ‘partners’ in executing the work of IT efficiently and accurately. Seems pretty clear, right? Then it should be easy to justify and implement a CMDB based on large numbers of Changes, right again?

Not necessarily. Justifying, developing and implementing a CMDB is not an isolated activity, a technology implementation or a database development effort. A CMDB is a means to an end, not an end in itself, and the end(s) are increased ITIL best practice Change Management and control and increased Configuration and Release Management control.

So the business value of a CMDB has to be built on results achieved in other ITIL practice areas, including an improved Change and Configuration Management process, better Change control and overall better service level management. These objectives have to quantified to prove metrics that could include:

  • Business process re-engineering
  • Change Management lifecycle improvements
  • Change Management approval board activities
  • Change and Configuration Management executions
  • Metrics to support and make the case for improved Change and Configuration Management and the CMDB

Ultimately the CMDB should be profiled as a crucial tool to the improvement of overall ITIL best practice Service Level Management and an important underpinning to an accurate and effective Asset Management system.

A good CMDB is good for Change, Configuration and Release management and ultimately good for the entire ITIL Service Level Management process.

Do you agree?

Until next time,

Don

Also, don’t forget to register for Evergreen’s change management webinar and learn how to Take Change Management from Firefighting to Fire Prevention

Are you trying to build a business case for a CMDB? Download Evergreen’s newest white paper on the subject: “The Business Case for Change and Configuration Management and the CMDB”.


Posted in: Business Value of IT , CMDB  Tags:

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Is the business value of a CMDB all about Change Control? And what if your organization performs root cause analysis? Do you really need a CMDB? We’ll address these and other CMDB, Change and Configuration Management issues in a new series of blogs this month.

As enterprises and their IT support organizations grow, their infrastructures become increasingly fragmented and spread across a variety of functions, technologies and organizations. As this IT infrastructure ‘sprawl’ continues, efficiency, optimization and overall control over IT resources suffers. Organizations often address the IT infrastructure ‘sprawl’ issue with automated or, in some cases manual, Change ‘root cause’ analysis tools. These tools analyze changes, in many cases failed changes, to get at the ‘root cause’ of the problem.

Although root cause analysis is critical to the improvement of change control, analysis that doesn’t take into account all configuration items (CIs) and their inter-relationships can be reactive, incomplete and in some cases, downright ineffective. Spreadsheets and manually maintained asset and specific purpose configuration repositories also do not sufficiently take into account the inter-relationships of CIs and can fall far short of effective root cause analysis for complex IT infrastructures.

So here’s my proposition - change process and CMDB are ‘partners’ in executing the work of IT efficiently and accurately. At the highest level, change is the workflow of IT and the CMDB is the information store that provides data to support the decision-making process. This partnership is the functionality that drives an efficient change flow engine.

Until next time,

Don

Also, don’t forget to register for Evergreen’s change management webinar and learn how to Take Change Management from Firefighting to Fire Prevention

What do you think about the relationship between Change and Configuration Management? Download Evergreen’s newest white paper on the subject: “The Business Case for Change and Configuration Management and the CMDB”.


Posted in: Business Value of IT , CMDB  Tags:

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
DonCasson posted on June 14, 2007 22:55

ITIL introduced the CMDB several years ago yet many are confused about its purpose. Do you think you know what a CMDB really is, as well as it’s purposes, components and applications? Test your CMDB knowledge against these five very common misconceptions about the CMDB.

The common misconceptions detailed here include:

  • A CMDB is just a database
  • A CMDB enables ITIL
  • CMDB is just a part of Change Management
  • My Asset Management system is the same as a CMDB
  • Federation is the key to CMDB

  1. A CMDB is a database
    A CMDB, despite the name, is not (just) a database. It is an analysis tool that happens to use an internal database to maintain configuration state and snapshots. A unique feature is that the database is populated by auto-discovery instead of business transactions.
  2. A CMDB enables ITIL
    This can be a confusing phrase. A CMDB is a trusted source of configuration or structural information. Controlling the ITIL workflows and collecting process metrics is managed by a separate workflow, forms and dashboard tool.
  3. CMDB is part of Change Management
    Change Management uses the CMDB analysis and report capability to identify rogue changes, simulate the impact of proposed changes and confirm releases. CMDB is an important tool for automating the Change Management process. A CMDB implements the ITIL Configuration Management process.
  4. My Asset Management system is the same as a CMDB
    Asset management is a database and set of processes to acquire and track equipment and software to perform financial and custodial duties such as ownership, location, license utilization, lease terms, disposal. Asset management is not concerned with configuration structure and mapping relationships. But an Asset Management system and process is both a good idea on its own, and an important prerequisite to development of a CMDB.
  5. Federation is the key to CMDBFederation is fiction. It is a term to hide the fact that no vendor wants (or is able) to solve the overall data integration problem across the disparate and standards-free world of IT tools. A CMDB does not have to federated to be effective as long as the Configuration Items (CIs) follow consistent naming rules. Later it may be useful to integrate selected attributes about CIs from other systems, such as application monitoring, security, and asset management.

Want to know more about how to develop your own CMDB? Download our comprehensive white paper on nine steps to developing an effective CMDB.

Also, don’t forget to register for Evergreen’s change management webinar and learn how to Take Change Management from Firefighting to Fire Prevention

—–


Posted in: CMDB  Tags:

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
JoeKoester posted on May 31, 2007 22:57
  1. Improved overall release, change and configuration management through bringing all configuration items and transactions under centralized change and configuration management control.
  2. Automated discovery and mapping of all key applications, computing and network IT infrastructure.

  3. Sharing of the information gained from mapping and discovery across all IT functional groups and personnel, improving decision making and workflow efficiency.
  4. Significant risk reduction through complete, automated impact analysis (of all relationships and inter-relationships of CIs) from initial planning, through the CAB, to execution.
  5. Improved security and regulatory compliance through the virtual elimination of all non-compliance with security and regulatory policy as a result of the automated audit of unauthorized changes.
  6. A higher level of execution and coordination with application management for critical enterprise improvements, which yields significant gains in agility, efficiency, and accuracy.
  7. Advanced ‘real time’ management of the data center server and software footprint through accurate and complete data set support cost analyses that quantify moves, changes, consolidations, compliance auditing, and disaster recovery activities.
  8. Accelerated execution and governance of SOA initiatives as a result of being able to “see” the complete component-based application and the relevant infrastructure.
  9. Reduction in problem resolution through rapid root cause analysis as a result of being able to see and perform triage real time on the entire affected IT infrastructure, driving up performance and availability of IT services, enterprise-wide.
  10. Accelerated and simplified ITIL initiatives as a result of providing a common, accurate system-level view across IT, speeding workflow and decision-making and supporting ITIL re-engineering efforts

Also, check out our White Paper on How to Implement a Succesful CMDB and our newest whitepaper: Developing the Business Case for Change and Configuration Management and the CMDB.

Also, don’t forget to register for Evergreen’s change management webinar and learn how to Take Change Management from Firefighting to Fire Prevention

—–


Posted in: CMDB  Tags:

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

So what’s up? How are things going? I hope everyone had a good holiday full of quality family time and turkey. Such is life-all holidays must come to end, and we all have to get back to work.

So when last we chatted, we were discussing some benefits of undertaking a strategy to construct a service catalog and CMDB in a joint effort. The first benefit that I mentioned was the ability to identify the composition of a service, which includes Hardware, Software, Manpower Governance, Standards, etc. Let me elaborate. One of the biggest challenges for IT is to gain a universal understanding of what a service is. You might laugh but a common reaction when first trying to define a service is skepticism and uncertainty. A common feeling is that if the item can not be shoved in a rack or is not the latest flashy piece of technology, it is worthless or a waste of money. The reality is that IT functions in the realm of the tangible. So there is not the typical warm-heart welcome when someone brings up the concept of a ’service’.

So how does one get around this?

By defining a service with the items within the CMDB, individuals can better solidify relationships and the composition of a given service. This allows items that were not tangible to become tangible and have identity. In addition this provides an additional (service) layer to be integrated with the CMDB structure from day one, which provides IT with a very powerful data structure that includes a complete set of views (including business, customer and IT).

Any questions?

Well until next time; remember to use your powers for good.

Also, check out our new White Paper on “How To Develop a Service Catalog”.

Technorati Tags:


Posted in: CMDB , Service Catalog  Tags:

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Okay, so last time we had a chance to chat, I made the statement that running CMDB and Service Catalog projects can increase the acceptance of operating in a service-oriented fashion. If you recall, my reasoning was largely due to how foreign a service concept is to IT. So I proposed that by building a data model that integrates the service catalog and CMDB, one can establish a familiar reference point for IT which brings the adoption rate into acceptable portions.

In addition to creating an approach for adoption, you can now create an environment of continuous momentum as the Service Catalog and CMDB projects feed off each other. On one side the CMDB gains enterprise-level exposure and identity of importance. Alternatively, the Service Catalog goes from a simple document that requires continuous maintenance to a credible, customer-facing vehicle for IT to use to manage business relationships with its customers.

So does it sound good? Is there any interest in the challenge? Let me know your thoughts? I would love to help out. Take care, and until next time, keep up the good work.

Also, don’t forget to register for Evergreen’s change management webinar and learn how to Take Change Management from Firefighting to Fire Prevention

Check out our new White Paper on “How To Develop a Service Catalog”.

Technorati Tags:


Posted in: Service Catalog , CMDB  Tags:

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Hey all! I am back. I wanted to chat for a spell about another point that I brought up in Part 2 of my wonder twins powers series. If you remember, and I do not know how one could forget, but just in case the thoughts of Thanksgiving dinner have made our discussion slip your mind, I will refresh your memory. I was pontificating on the benefits of establishing a service catalog and the value of spearheading a CMDB effort simultaneously. Does this refresh your memory? Cool.

So why do this? What are the benefits? Thank goodness you asked.

The reason that this is the bee’s knees is related to the day after the service catalog is deployed. What happens?

The second has to do with addressing the management of a service catalog structure. So after you rip out your hair and the wounds heal from the effort of developing a service catalog structure, you finally have done what seemed impossible - you have a document titled service catalog (Fans Cheer). I apologize if I am a being cynical. Please believe me when I say, I know the amount of effort it takes to build such a document. I definitely have the scars to prove it. So what happens next? How does a business obtain real, hard-dollar value?

The reality is the next day, or the next month, components within a service begin to change and when that happens the nice document that took such a long time to create is sadly out of date. Ouch? I know this is painful. While the document is not a waste of time, the thinking that has to go into creating a service catalog document is good work, it just falls to the hands of progress. To avoid this situation, a service catalog needs to be integrated with the source that contains all its pieces. This will provide the catalog components to adopt changes as they occur. Does this make sense? Let me know if not. As always, I would love to chat about this some more. Well until next time; remember to use your powers for good.

Also, check out our new White Paper on “How To Develop a Service Catalog”.

Technorati Tags:

—–


Posted in: CMDB , Service Catalog  Tags:

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Search

Calendar

«  February 2010  »
MoTuWeThFrSaSu
25262728293031
1234567
891011121314
15161718192021
22232425262728
1234567
View posts in large calendar