Process Governance: The Dark Side of CMS

Ditch the suit, get your boots on, and bring a good flashlight!   Today we're journeying into the center of the ITSM Universe, Configuration Management.  What will we find?


 


Planning  or designing a CMS or CMDB?  Beware deceptively well-lit, short and simple paths to success.  They're illusions.  The actual path of achieving substantial ITSM ROI involves lots of crawling around in tight spaces and heavy organizational and technical lifting.  And there IS a wrong and a right way to do it.  There are all kinds of ways to fail, but only a few ways to succeed.  I'm thinking not "tour guide" but "expedition leader". ITSM is more Lechugilla than Carlsbad.


 


Like caving, CMS solution architecture can be, well, dark.  For example:  "should the _____ process interact with the _____ process through ____ or _____?"  Plug in your question of the day.  There's a million of 'em: Change Management,  Incident Management, the CMDB, directly.


 


Adding process and automation to an IT organization can be as challenging as any other organization in a business.  Possibly more so because that sort of thing IS our business and we don't like our business getting messed with.  But I've been covering that in my last three posts.   Today's hypothesis:


 


After a dark and strenuous trip, you arrive to find ITIL is hollow in the center.  The missing part is the data, how to handle the configuration data itself.  All the process and governance around the data and information about the data, for example, how accurate or timely the data is.  You have to think about what to fill this gap with and the operational ebb and flow of the data.   From the beginning.  Ultimately, it's as much about the data as the process.  But ITIL is forthemostpart dark on this, and it's also least-filled-in part all around.  The documentation, the stakeholders, the technicians, the consultants don't focus on it.  The process and governance work is left to evolve organically or for you, the accountable party, to figure out.  While you must ultimately craft your own processes, it's still not nice of the consultants to leave anything undocumented, especially any custom work like integration or model extensions, etc.  But that's not what I'm writing about.  Back to the gap. 


 


The gap is, the discipline of constantly measuring all the onboarding, as well as the operational, activities related to the data against the desired state.  Not just a successful installation and demonstration, and not even just usage and operation, but successful operation, where the CMDB measurably reduced risk and cost and improved reliability of the configuration data provided to IT's consumers.    And I presuppose a well-defined use case and an achievable, understandable, quantifiable ROI here.  If the data is sloppy going in, your ROI suffers an you see sluggish or no ROI up in the business KPIs.


 


I'm not talking about Asset Management or SACM!  These processes  do things like, call for specific ownership of certain CI types, and call to be the specific provider of certain CI types.  This is not what I'm talking about!  I'm talking about the layer that sits between ALL the processes and the CMS, the governance part, that which is responsible for evaluating the data and its fitness for consumption.


 


If CMDB is about plumbing, CMS is about water quality.  


 


So you have a working  CMDB, a building full of experts ready to federate, a bag full of use cases, now what?  Oh yeah, maybe you already did some discovery.  You'll probably have to undo some of that.  Rewind for a minute.


 


As you go through the presales demo, your Proof of Concept, your testing and lab work, and finally, your move to production, can you answer the following questions:



  • Who is the intended consumer of the data?  (Hint:  You better have at least one)

  • Who owns each CI and attribute?  (Hint:  Someone needs to)

  • What provider conflicts exist?  For example, between the discovery and the asset or service or network management systems? (Hint:  There shouldn't be conflicts in the finished CMS.  Not a misprint.)

  • Who does the business see as accountable for this configuration data?  (Hint:  not the Alpha Geek's spreadsheet)

  • Who decides what data is provided to what consumer?  (Hint:  It shouldn't be the consumer or the provider.  No really, not a misprint.)


 


The answers reveal your config data onboarding processes, or lack thereof.


 


Here is the dark space in the center of ITIL:  You need a good governance model to build the processes around onboarding and managing configuration data, which, when followed, will result in the highest quality data possible provided to the consumer in the most efficient and secure manner possible.   "Data Stewardship" is a good way of thinking about it, here is a gentleman who understands.


 


By accounting for the authoritative nature of the data, and the entitlement of the consumer, one can construct such a model which can guide those creating processes for using a CMS, during and after CMDB and CMS implementation.


 


Such a model must minimally account for three things:  the consumer, the provider, and the owner.  The model must provide a few basic tenets which reach into every aspect of how configuration data is handled by the CMS.  For example, how provider "conflict" is handled, how ownership of data is established, and why consumers must be understood vs. merely serviced.  This is the missing gap in the center of ITIL.  I hope. 


 


I and a bunch of my friends have developed such a model, and it happens to be called the Consumer/Owner/Provider Model, or just the COP model for short.  In my next posts, I'll be introducing some of the major tenets of the COP model and discussing each one in  more detail.  Perhaps you think of some of these tenets in other ways or using other language, but I want to see how well this relates to you. 


 


I hope I've whetted your appetite and that you're full of questions.  Feel free to ask them here or comment with a reply.  Thanks!


 

Comments
| ‎04-07-2010 01:09 AM

Captivating writing style. Do NOT like this little white font on a black background. The RSS feed to my Outlook is much easier to read. Iterative guidance is good advice. This approach will mate well with an Agile scrum approach and get you live sooner rather than later or worse, never, the bane of many CMDB efforts.

Jody Roberts | ‎04-15-2010 08:22 PM

Brent,

Thanks very much for the feedback.  We need your comments.

I don't know what browser is, but you can increase the font size by CTRL +.  This at least addressess the "little" part of your issue.  

Personally, I'd prefer an alternative to the shades of gray background as well.  In fact I do most of my reading and editing on another page that is white bg and black text.

We've listened to yours and other feedback.  Look for improvements of the color scheme and other things, coming soon!

Thanks again

JR

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.
Search
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 ...
Featured


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.