Pink Elephant
The IT Service Management Experts

Troy's Blog

The Hitch Hiker's Guide to the IT Galaxy and Beyond
Don't Panic



Troy Dumoulin Photo

Troy DuMoulin, VP, Research & Development

Troy is a leading ITIL®, IT Governance & Lean IT authority with a solid and rich background in Executive IT Management consulting. Troy holds the ITIL Service Manager and Expert certifications and has extensive experience in leading IT Service Management (ITSM) programs with a regional and global scope.

He is a frequent speaker at IT Management events and is a contributing author to multiple ITSM and Lean IT books, papers and official ITIL publications including ITIL’s Planning To Implement IT Service Management and Continual Service Improvement.


The Guide

"This blog is dedicated to making sense out of the shifting landscape of IT Management. Just when we thought we had a good handle on managing technology, the job we thought we knew is being threatened by strange acronyms like ITIL, Lean, Agile, DevOps, CMMI, COBIT, ect.. Suddenly the rules have changed and we are not sure why. The goal of this blog is to offer an element of sanity and logic to what can appear to be chaos."

Hitch Hiker's Guide to the Galaxy

"In many of the more relaxed civilizations on the Outer Eastern Rim of the Galaxy, the Hitch Hiker’s Guide has already supplanted the great Encyclopedia Galactic as the standard repository of all knowledge and wisdom, for though it has many omissions and contains much that is apocryphal, or at least wildly inaccurate, it scores over the older more pedestrian work in two important respects.

First, it is slightly cheaper: and secondly it has the words DON’T PANIC inscribed in large friendly letters on its cover."
~Douglas Adams


Troy On Twitter

Recent Entries



Other Blogs


Fit For Purpose ITSM Processes

A key principle of Lean thinking is that Over-engineered solutions are a form of waste (Muda). However, what if those solutions / management practices are so immature, and inconsistent that they place the organization at risk? Or do they? Actually: The Answer is that it depends on context!

The real trick of our trade is to find the Fit for purpose balance between formality and ad-hoc approach for to the ITSM processes required to manage the delivery of Services. The concept for this article has been spawned in part by research I am doing on a new model to address the question of establishing the business case for maturing IT management practices,  and also, in part, by a friendly debate the IT Skeptic and I have had for years over the need for a Configuration Management Database (CMDB)

So, to start,  let me declare an assumption that the readers of this article may not have considered before.

Assumption - 1: ITIL brings nothing intrinsically new to IT Management that we have not already been doing since the genesis of our industry.

The original OGC mandate for the internal improvement project that birthed ITIL was not about coming up with new things they had never done before, rather to find better ways for doing what they were already doing.

I frequently get asked by Sr. IT Leaders about the business value of adopting and spending money $$ on this ITIL thing;  as if it is somehow new,  or some foreign idea they are being asked to take on. In these cases I ask them if they already have strategy/portfolio processes, design and build solutions for their customers, have to move those solutions into production, and once there have to support ongoing operations while keeping an eye on improvement opportunities. 

Of course, they always answer yes since this is what we have always done. Congratulations I say, your are already doing ITIL,  or better yet, are in the business of IT Service Management (ITSM). The only new thing ITIL brings to the table is an external reference model that provides an opportunity to align their current practices, if desired, with an industry accepted definition of what those practices could/should look like and common terms used by other organizations. The reality is that while organizations already do the ITIL processes, the average maturity of those processes is somewhere from ad-hoc to loosely defined.

ITIL does not introduce new practices to the IT industry!  It simply provides an evolved set of good practices for what we already do.

Not that there is anything wrong with having a process at an ad-hoc level of maturity.  In fact, let me say right now that some processes have a higher degree of value when they are unique each time they are used.

Now to address the question of Configuration Management:

To Rob’s comments on My Article CMDB – Spruce Goose, Death Star Or Answer To World Peace?:

“All the other processes which Troy describes, “identification, control, status accounting, verification and audit”, are either provided by asset management tools, or are not required if we don’t build a CMDB.

When we set up Impact Analysis Reporting process, and test it and rehearse it, we may find levels of unacceptable error, or unacceptable delays in reporting a result. Or we might not. If we do, then once we’ve exhausted the improvements from optimising the procedure and the team of people doing it, then we should look at tools.  Simple tools like spreadsheets, analytical reporting tools, data explorers and scrubbers etc… And if THEY don’t work, then maybe we can start building a business case for CMDB based on what we need out of Impact Analysis Reporting and can’t get when we do it with wetware (humans). If you are one of those 3-5% of sites, bummer. Good luck finding the funds….”

First, it has always been the accepted responsibility of IT to manage the IT assets/items under their control.  Part of that management accountability is to keep track of where those items are and what they are connected to in relationship to their use and purpose. It just so happens that most organizations do so very poorly with an accuracy level that would make most IT Managers blush and look uncomfortable if you asked some tough questions. Why is that? Simply put it’s a back office type responsibility that is not very sexy, fun, or exciting for most people and the last thing we probably find time for.  If this was not the case we would not have had to spend all that time and effort at Y2K to do inventory counts that were accurate for about 3 weeks max.

The reality is that they accuracy of our Inventory/ Asset Databases is more about discipline and culture then it will ever be about automation. Automation and discovery tools can help but there will always be items and attributes we will need to track manually.  Just because you purchased the world’s best tracking tools does not mean you will solve your people challenges.

Rob’s article makes reference to an Asset Tool versus a CMDB as if they are two separate things. In my books these are not two separate data repositories but simply a level of data management. In general a goal of data management is that we avoid managing data about the same object (server/application) multiple times if possible.  Rather than having one database / spreadsheet for inventory lists, another for financial asset data and yet another called a CMDB for “Impact Analysis Reporting” why not have a common place where we manage data at different levels a detail based on the need? For example desktops are managed as standalone records, other items include financial (asset) attributes and a subset of your items are managed at a relational / dependancy level.  A CMDB is not just another tool for managing data poorly for the use of Change Management.  It’s a concept of managing accurate relationships and dependencies between objects that are business critical enough to warrant the extra effort of data management.

The real question is to ask,  What level of data management in your environment (by domain) is Fit For Purpose?  Are you keeping too much information at a high a level of accuracy than is worth the effort?  Or are you at the opposite point of the scale with close to nothing in the way of useful management information about your environment?

The fact is that there is no right answer that applies to all organizations! That is why I would like to introduce the following model called “Linking Process Maturity to the Product Lifecycle” based on a Harvard Business Review article by Robert Hayes and Steven Wheelwright.

Linking Process Maturity to the Product Lifecycle

Hayes and Wheelwright originally Intended this model to apply to a business / manufacturing type organization but I have taken the liberty to tune it for information management processes.

The base premise it that everything in life that produces some outcome is the result of a process. Ex: You have raw inventory which gets fed into a sequential or parallel set of steps to get something out you want at the end. This is true if you are building a car, washing dishes, designing an airplane or managing changes and incidents.

The next reality is that we don’t document all processes in a 3 ring binder with slick automation unless there is a darn good reason to do so.  In fact,  in some cases the processes that produce tailored and unique solutions are better left as flexible and un-regimented since the value of their outcomes is based on the very agile nature of the steps used.

To illustrate this concept I have developed the following visual:

Certain Processes / Outcomes require more of a craft approach while others demand Process formality, a high degree of standardization and minimized variance.

To assist with this concept Hayes and Wheelwright introduce the following Manufacturing Terms:

  • Engineer To Order: Each time a customer has a request we apply unique specialist knowledge to develop tailored solutions based on one of a kind requirements. Think about Engineering or Application Development type processes. (perfect for low volume)
  • Make To Order: looks at the concept of doing something consistently in a batch format. We will follow a common method for a certain process or IT system during the project lifecycle but the next project may use a totally different approach.
  • Assemble To Order: We provide unique offers based on the assembly of pre-defined and approved components. Go to the service catalog and order a standard laptop but add options such as memory, disk drives or approved applications. (Balance between consistency and flexibility)
  • Make To Stock: Due to cost, regulatory, risk drivers we have to ensure that every time the widget comes off the assembly line or the release is deployed it happens the same way to minimize variance. (necessary for high volume)

Now consider how you would apply ITSM processes to this model. As I declared earlier all IT shops already manage to deliver services, but the reality from our experience based on hundreds of assessments is that almost all IT Management processes are over on the far right of “Craftmanship”

The important question for Sr. IT Leadership is not about adopting ITIL/ITSM, but rather if it makes business sense for all current IT processes to continue, to stay at a “Craft” level or consistency, repeatability and cost?

The honest answer to that question is not only for IT to decide but ask yourself what your customer, the person /group who funds IT’s Service Model would expect.

In some instances like Strategy Generation, Portfolio, Demand, etc. perhaps all we need in the way of documentation is a fact sheet declaring what the goal of the process is, the key measures, who is involved and how to get access to it. In other areas the risk and cost of leaving Incident, Change, Release and Deployment Management as a Craft across multiple silos and suppliers is too great, and more investment is needed in defining and standardizing your practices.

So getting back to Rob’s question about the need for a CMDB, the answer for each organization is “It Depends” on what is “Fit For Purpose” for you.  Do Excel spreadsheets of asset inventories managed to the accuracy needs of individual IT departments work for you? Or, do you need a higher standard of IT data and relationship accuracy to deliver on the service promises to your customer?

Only you can answer that question and it will change from year to year and from technology to service.

Whether you need a 3 ringed binder or a fact sheet, simple or complex tools will depend on your business justification for the investment!

Yes, Rob, we will definitely have to have that beer next year in Vegas at Pink12!

For additional thoughts on this concept check out the following article: Balancing Process Formality With Innovation “You need chaos in your soul to give birth to a dancing star”

Troy’s Thoughts What About Yours?

The great thing about being the only species that makes a distinction between right and wrong is that we can make up the rules for ourselves as we go along.—Douglas Adams and Mark Carwardine, Last Chance to See (1990)


Posted by Troy DuMoulin on 03/08 at 06:18 PM
  1. This post puts us in total agreement.  I never meant to imply CMDB and Asset as separate repositories, just separate mindset and practices when dealing with the data. A CMDB approach implies, as you say, “managing accurate relationships and dependancies between objects that are business critical enough to warrant the extra effort of data management.”  However this requires a whole raft of capabilities over and above simple asset records: federation, reconciliation, navigation, inference etc

    And we agree that the need for a CMDB tool will “depend on your business justification for the investment”.

    I reckon the justification exists for about 5% of sites.  I rant about CMDB because to hear the vendors and analysts (and ITIL books) you’d think CMDB technology was a given for everyone.  It isn’t.

    the IT Skeptic

    Posted by Rob England (IT Skeptic)  on  03/08  at  08:30 PM
  2. Rob I agree that many perhaps most organizations lack the necessary maturity, discipline and business justification for a CMDB level of data management. This is one of the key reasons we don’t advocate starting with this process in a roadmap context.

    However, that being said that does not make the need go away simply success harder to grasp. This will continue to be true until the urgent no longer outbalances the necessary.

    From a data management perspective start small with obtainable goals since something is better than nothing at all.


    Posted by Troy DuMoulin  on  03/09  at  09:34 AM
  3. You write, “In my books these are not two separate data repositories but simply a level of data management. In general a goal of data management is that we avoid managing data about the same object (server/application) multiple times if possible.”

    In the Van Haren IT Financial Management book, Jan van Bon wrote, “ITIL V3 defines asset management processes with configuration management, presumably because configuration items may also be assets.  With a deeper analysis, it is clear that ITIL describes mainly configuration management as no specific processes are described in detail to manage assets from the financial and contractual basis.”

    CMDB is about CONFIGURATION management.  Not about the stewardship of IT Assets - contracts and financials of software, hardware, telecommunications virtual assets, cloud and external services.

    The focus is way different.  CMDB belongs to operations.  IT Asset and Financial management are focused on centralized, proactive controls to manage business risk.  Preventative software management controls, details about costs, etc. 

    One of the reasons those issues, like cost of services, is just as you write - these very necessary administrative task ALWAYS take a back seat to doing in IT Ops.  Therefore, IT Asset Management has to be a centralized supporting service accountable for these activities. 

    Without an IT Asset Mangement service, you’ll have acquisitions spread all over the organization, software compliance and overspending issues, virtualization sprawl, and much higher costs. 

    It’s not part of ITIL.  But, neither is IT Governance or Project and Portfolio Management. Let’s not let the obvious limitations of ITIL keep us from doing the things that need to be done.

    Posted by Cary King  on  03/09  at  09:39 PM
  4. Cary

    It appears we may have very significant philosophical difference on this subject.

    First of all a Process like Configuration Management or Asset Management is different and separate from a data store some times called a CMDB.

    From my perspective there is a significant difference between data and processes.

    When Speaking about data the terms Inventory, Asset and Config Databases should not refer to 3 separate databases but levels of data management.

    Inventory Data: Stand alone records of data objects with attributes largely focused on management and support.

    Asset Data: Stand alone records of data objects with attributes primarily focused on financial aspects of the managed objects

    Configuration Data: Related records of data objects focused on life cycle status, usage and dependancies. 

    Regardless of what ITIL or our friends of Van Haren say or do not say this is more of an Architectural perspective versus process discussion. (Processes are not the same as Databases)

    As you would assume you can use data for many different uses and as input to many different management processes (covered in ITIL or not). Dealing with the concept of data alone for the moment it does not make logical sense if you can avoid it to have multiple databases managing records about the same objects multiple times. In some cases this in unavoidable due to systems that may have specialized functionality or in certain instances where regulation requirements make this a compliance issue.

    In these cases we then have to ensure we have manual and automated reconciliation processes to keep the various duplicate records in sync. This has always been the challenge of architectural models based on stand alone development of applications and custom databases designed to fulfil one function largely due to organizational silo needs (Architecture Level 1). The challenge then comes when the duplicate records of other systems have to be kept synchronized and provide data input into other processes. This is where we have the birth of Federation of different non-integrated systems and we have to leverage middleware and data mart technology (Architecture Level 2).

    In reality what should occur is that we store data in what ITIL calls a Configuration Management System of linked data bases and tables where the only reason we federate to another system is that it has unique functionality as opposed to the historical reason of it was created for a single purpose. If there are two “data sources” that are largely redundant in function. (Ie: Store data for specific application or process) these should be consolidated into a single source not federated to. (Architecture Level 3) Federation is complex, costly and prone to breakdown.

    This is the model used by ERP systems where a global general ledger supplies the necessary data for multiple processes. (Accounts Payable, Procurement, Inventory Management, etc..)

    In an ITIL Context such a data store (CMS) would supply many different processes as is depicted in the ITIL books. Incident Mgmt. Change Mgmt, Information Security, Configuration Management as well as those ITIL forgot to cover well but may be covered in other frameworks such as COBIT, or Prince2 eg: Asset Management, Project Portfolio Management,

    In essence the processes what ever they are should be independent of the data stores in an advanced architectural approach. Having unique data stores for each application duplicating data objects over and over for different management tasks is not a wise or cost efficient model.

    For more information about this please take a look at the HBR / MIT Enterprise Architecture As Strategy book.:


    Posted by Troy DuMoulin  on  03/10  at  11:29 AM
  5. Troy,

    You are right, we do have a different view.

    I tend to focus on the effectiveness of the business result.  I try to not let technical constraints limit the results.

    You mention how ERP systems work.  An ERP for IT is something that has been on for more many years - we certainly did when I was at Peregrine and CA. 

    Perhaps, some day, they’ll achieve that.  But, they had better hurry.

    IT is rapidly changing to a Service-Oriented, outsourced function.  We’re consolidating servers to have more VMs. W’re creating private clouds and hybrid clouds. The move to public cloud is irresistable because of the purported cost savings. 

    When your ERP and other key services are in a SaaS, your CRM is Salesforce, and your Service Desk is outsourced, etc. just how much Configuration Management will you be doing? CMDB becomes less important to the company - very important to the PaaS and SaaS and outsource vendors.

    Contract Management, Asset Management, Demand Management, Vendor Management, IT Financial Management - those things that are, for most, afterthoughts, become more important.  Administering the contracts becomes a big deal when your job is to act as a prime contractor and deliver your services through sub-contractors.

    Instead of preparing for the battles of the past, let’s invest in fighting the battles of the future and invest only minimally in the temporary problems of the present.

    ITIL guidance will, I believe, remain very important, because vendor capability audits must be based upon it.  As we concentrate more into the public cloud vendors, implementing highly disciplined processes that manage the sub-contractors and keeping expert staff to do so, will be a key.  Regular capability, process, security and performance audits will be the name of the vendor management game.

    Implementing proactive management controls over the financial risks that are associated with software and cloud will be important - else companies will be have increased risk of material misstatements.  As with the 20+% of total IT budget software audit true-ups that are happening out there.

    Ford’s River Rouge plant used to be the biggest single plant in the world.  Iron ore and other raw materials went in one side - cars came out the other side.  Very much like IT, they produced much.  Now 95% of the value of cars and trucks is subcontracted.  Manufacturers do Product Marketing, Product Management, assembly, distribution and finance.

    IT will follow the same path as did manufacturing.  Only far more rapidly.

    Think of IT as apps on your pad or thin client serviced by Amazon, Google, HP, IBM, Terramark, CompuCom, etc.  Prepare for that future.  It is already here.

    Posted by Cary King  on  03/12  at  02:44 PM
  6. Cary, you make the argument that in an outsourced model, a CMDB is less important to the company.  I would disagree on this point.  I believe that when ‘some’ of your assets are managed by an external vendor, the relationships to the services themselves become more critical.  Your 3rd Party vendors will not be responsible for defining your internal services provided to your customers, and they will certainly not be responsible to know which assets are used for which services (the relationships).  Your Services will always have Service Assets that make up some of what the service is made of.  3rd parties will manage some of these assets for you, and some will be managed by you.  You can never outsource 100% of the management.  Making this distinction is important.  When 100% of your Service Assets are managed by you, then doing an impact analysis on a Change is easier because all control is under the same roof.
    In an outsourced environment, you will find that your CMDB doesn’t contain detailed data about anything outside of your control or concern, but it should maintain data about the relationships to support your services.  You won’t necessarily know how much storage or memory or which Operating System a server has, but you will know that there is a internal service that is supported by a ‘system’ that is managed by an external vendor.  This system may be a black box with the details obscured, but it will still need to be identified in your CMDB.

    Posted by .(JavaScript must be enabled to view this email address)  on  03/22  at  06:38 PM
  7. Chris I agree - you must manage your own assets, so tracking in some form of CMDB is necessary - especially when you’re entrusting many of your assets to outside agents/outsourcers. At least start with the key assets from a value, cost and risk perspective. You cannot manage what you cannot measure.

    Troy I really enjoyed your explanation of the varying degrees of need for CMDB sophistication makes sense to me

    I agree that Inventory/Asset database is mostly a function of discipline and culture, manufacturing organizations learned this decades ago in their pursuit of perfection in Inventory and Bill of Materials record accuracy, which led to many clever techniques involving cycle counting. I recommend “Inventory Record Accuracy” by Roger Brooks – you might gain some surprising insights that could be applied to this area of ITSM.

    From your comments I am reminded of the “Principle of Good Enough” that I discovered while talking with the CIO of a large NGO, they’re constantly trying to make do with a fraction of the resources that an ordinary for-profit of their size could work with

    Posted by Steve Bell  on  04/07  at  09:57 PM
  8. Page 1 of 1 pages






Remember my personal information

Notify me of follow-up comments?

Please answer the question asked below:

ABC easy as 12_. What number is missing?