IT Service Management Blog
Follow information regarding IT Service Management via this blog.

What Should Be a CI?

    No really, a little perspective and understanding can go a long way.  A big part of the problem as many customers have reported to me is not knowing who to believe amidst the chaos and conflict.  The heart of this conflict may surprise you.  It's  not who has the best data model, or who's federation performs the best, or who's topology visualization is easiest to use.  It's about understanding -with precision- what is required to support your use cases.  This requires in turn an understanding  - with precision-  exactly how your ITSM processes interact.  The kicker  - you can't learn this from reading anything produced outside YOUR IT organization.  Herein lies how your bomb shelter works:  If you merely follow ITIL or SACM, you may get something functional, but not necessarily strategic, not necessarily agile, not necessarily differentiating in YOUR business space. 


    That's right, I said "business" - as IT services become more and more coupled to the business, IT's success criteria become commensurately coupled to the business's success criteria.  For ITSM and the CMS, this means, you have to understand the business, then the business services, then the business processes, then the interaction between the services and processes, and ONLY THEN will you know what you need to craft your ITSM to support those processes efficiently and robustly.  And then and only then will you have a well-defined use case.  This is the beginning of wisdom for CMS population.


    While I'm at it, I'm going to change my vernacular, and hopefully yours too.  I'm saying "population", but that carries some baggage I'm going to ditch here and now.  I'm going to change "population" to "providership".  This frees the CMS contents from the uncomfortable association and limitations of the implied replicative processes traditionally used to populate a CMDB, and expands it to what is exposed to the CMS via federation.


    Here's the objective part of the bomb shelter:  Your providership should -with precision- match your consumership.   I'll explain.



    providership and consumership alignment - disparity.jpgIn this scenario, a CMS attempt is made but is not actionable.  You can't trust the data, you aren't sure where the data came from, or perhaps you can't get to the right data due to organizational or technological barriers.  Maybe you onboarded the wrong data.  Maybe you got a thick book of requirements dumped on you without you being involved to this point.  Maybe you tried to save some time and effort by promoting your test CMDB into production with the first Full-Monty discovery intact, 12 million CIs and none of them usable (yet).  Whatever your scenario, all these smell the same:  expensive and not very useful.  There are many of these derelict projects in the garbage.  Go find a few and learn from the mistakes.  Or, read our CMS best practices strategy guide.




    providership and consumership alignment - sub-optimal.jpgIf you try to follow some industry standards, you may achieve partial success but only at a high TCO and without removing the barriers that impede the CMS making ITSM truly able to support competitive differentiation in the businesses' space.


    Not as an aside, if that is not your goal, your CMS will not be all it can be.  You must derive your use cases, and the resulting providership and consumership requirements, from the business.  Anything short of that will create a disconnect and a ceiling at some point that could be extremely difficult and costly  to undo.









    providership and consumership alignment - optimal.jpgIf you design your CMS with your use cases in mind, and don't onboard any bogus data, and rationalize each consumer and provider as they are onboarded, then you should be optimally aligned as shown here.  A "side effect" of making the effort to match the consumership and provider ship is, you understand the providership sufficiently to trust it, making your CMS much more actionable, at the lowest possible TCO.


    You will never achieve 100% perfect alignment, even if you properly rationalize each provider and consumer as they are onboarded.  This is ok.   On the provider side, technology will require the odd "overhead" CI.  Don't worry about these.  On the consumer side,  technology or organizational challenges may preclude onboarding certain consumers, and new consumers may need to wait until the right time to be onboarded.  These kinds of exceptions are perfectly healthy and normal, you may deal with these as you wish and as your time and cost permits.


    As for the subjective part, If you read my last post, you know that you can ask anyone what should go into your CMS and you will get a different answer every time.  That's because the answers are mired in technology, emphasizing the strengths of this or that product/paradigm and de-emphasizing the use case.


    It comes down to, following as broadly as possible the  common best practices, AND THEN adding the parts that are specific - subjective - to your businesses.  This helps you decide, with authority, what your CMS should be providing.


    One of my favorite quotes came from an attendee at the 2009 HP Software Universe, who said, and I paraphrase:  "Ask not what you should put into your CMS, rather, ask what you want to get out of your CMS, and what to put into it becomes clear."  Thank you Mr.. P.


    The Part You've All Been Waiting For: So when it comes down to the CI types, this is what it means - the providership should be "whatever you need to support your services".  Not a prescriptive list of CI types or relationships, although this will certainly be substantively determined by best practices, BUT NOT ALL of it.  If you decide that your office furniture, or your son's pickup truck, or the NOC console  is a critical part of (relates to) a service, then it should be a CI.  No vendor or standard can tell you this.  Realizing this is the real essence  of your bomb shelter.  You are in control, so BE in control.


    As Radiohead said, "Whatever makes you happy, whatever you want, you're so very special."  It's YOUR CMS, YOU decide what is right.


    And when necessary, deploy your bomb shelter!


    Any of that help?  Talk to us.




Honored Contributor | ‎08-30-2010 12:01 AM

Hello Jody!

Thanks for a very nice article. The only one point which is not understandable to me is the part that you say "It's YOUR CMS, YOU decide what is right". Do you really think that it is right? If you say that to organization which IT wants to design CMS but has no clue how it should be done and built it according to their own understanding and approach the result will be huge amount of spent time and money and model Disparity as outcome (case 1 in your graphics). I don't want to say that it is a must to do straight as it said in best practice but it should used as an example around which you can built what you exactly need in your case. Best practice is called so because it is considered as best approach by some part of authority, which should not be ignored.

Why much part of the companies is not implementing such thing by itself and invite outside consultants for that purpose? Because they does not want to invent something new, they prefer to use model which is already used by their predecessors. That's why there still are people called consultants which advice others how they should work :smileyhappy:

Jody Roberts | ‎09-20-2010 07:05 AM

Hi Vadim, I understand your question.  I am not suggesting that IT organizations should not listen to or use professional services to guide or work for them, or should not use best practices.  


What I am suggesting is that they get at least a clue or two so they are not at the mercy of any one body of knowledge.   Would it not be prudent to at least be able to ask good questions of the consultants, or of a body of best practices? 


The consequences of NOT having this level of understanding, is DRIFT.  Unless someone is at the wheel once the consultants leave, the ship is going to eventually run on to the rocks of change.  THAT is why YOU must decide, ultimately, what should be a CI.


I maintain that it is dangerous, as a customer, to completely give up the understanding of what your CMS will be to any third party.  Again I say, YOU must internalize enough understanding, one way or another, to be able to decide, for example, what should go in your CMS and what should not. 


We walk a fine line, as both customers, and as vendors and service delivery organizations


On one hand, customers want us to tell them how to do it.  On the other hand, we cannot tell customers completely how to do it except for knowledge and experience gained through previously engaging with customers.  Best practices are a combination of real-world experience, experts thinking about things, and customers expressing needs based on profound understanding of the workings of their business services.  No one party brings all this to the table except iteratively e.g. a best practices library.  Which we have!


Please, keep the comments coming, this is very good engagement.  Thank you again for your reply.


Honored Contributor | ‎09-20-2010 07:12 AM

Hello Jody!

100% correct! Job of the consultant is not only to do the job for which he was payed like to built a process type loads of documents and then tell the customer "cya guys i am leaving, i finished my job here гшы your working system" is really way to the fact that at one point they will understand that they dont have any clue what is the purpose of CMS and did they needed it at all. Proper way should be to involve customer in the process so after consultant leaves they can keep it live by their own.

Cheers and thank you for very nice reply!

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Showing results for 
Search instead for 
Do you mean 
About the Author
Jody Roberts is a researcher, author, and customer advocate in the Product Foundation Services (PFS) group in HP Software. Jody has worked ...

Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.