ITSM Architecture Missing a Fourth Dimension?

Yep, I found the problem.  There seems to be an intrinsic temporal dimension to ITSM implementations that I think needs to be called out.  A reference implementation of even a rudimentary ITSM "out of the box" will be different depending on what you start with and the order in which you implement your use cases. Meaning, if you implement Asset  then Change then Configuration Management, your resulting CMS will work differently than if you changed the order of just these three around!  ITSM math is apparently non-commutative!  I personally find this hilarious.

 

But we don't want this.  We want it to make more architectural sense.  But what happens is reconciliatory incumbency.

 

Yeah, digest on that one for a minute.  Reconciliatory incumbency.  It devolves into the old Abbott and Costello routine "Who's on first?"

 

Who do you start with?  Yes.  Who we started with.  Right.  What?  And so on.  It makes no sense until you can semantically unravel the English language's propensity to be abused.

 

We abuse the semantics of our ITSM, too.  The COP model (in the HP CMS Best Practices Library) attempts to sort things out by saying things like "avoid provider conflict" and "every CI must have exactly one owner and exactly one provider".  That's fine, but what do I integrate first, then?  Do I discover first, then bring in Assets, then ship 'em all to Service Manager?  Do I set the Authoritativeness of my various Providers in Stone, then let the consumers belly up to the trough?   It seems to MATTER, in some big ways, what you do first, because identity reconciliation seems to have a kind of domino effect.  Whoever is there first, the next provider has to reconcile with whatever identity data the incumbent happens to have.  And it's not bidirectional! 

 

I think HP has the answers, but there is controversy here judging from the kind of discussion such as Michael Pott documented in the German Vivit Meeting the other day.  Customers can't agree.  Vendors don't.  Even product groups have to work hard to make the story consistent.  Heated discussions just seem to end up with "it depends."  Not good enough.  I want to know exactly on what it might depend, and then have a way of proving or disproving it.  Let's try to do some ITSM science here!  In between the times we're merely trying to get work done. 

 

But just saying that doesn't cause the white papers to flow.  Let's actually build and document a viable, non-dependent, temporally-sensitive, series of correct use cases that account for Change, Asset, and Config Management as a basis for our ITSM, that doesn't end up with "of course, it depends on what you're trying to do."  Let us build that reference implementation.  Then, let us see what the real world challenges it with, what oddly-shaped corners need handling, what small child asks what unanswerable questions.  Let us purge ourselves of assumptions and see what can be directly brought to bear on the most pressing problems.

 

Should we go on to map the correctness of this missing temporal dimension?  Or should we strive to unlock ITSM architectural commutability?  Today reconciliation parts seem to have a "handed-ness", like enzymes.  But come on, ITSM isn't molecular biology!  These constructs and their principles of operation should be much simpler to understand if we just got all the rigth people in the room at the same time, with enough attention span, with enough coffee, and enough white-board space  - and made the right time map - how the reconciliation builds up and unfolds into viability.  It CAN be done, it HAS been done, and we can show you how.  You show us your time machine, we'll show you ours.  Talk to us?  Thanks for listening!

 

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
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