Consumers drive Providers, Providers are Transparent to Consumers: NOT a paradox!

The Setup.

OK, the happy man that was Jody has stepped out for a moment.  He's left the curmudgeonly, pedantic System Programmer of his past in his place.  And he's torked. 

 

My problem.

There's a new CMS going up.  They have some discovery going on.  Somebody talked to me about some fool application mapping thingamajig.  They're promising a better change process (my changes always work, though, this is for everyone else).  And now they're saying I'm going to have to "consume" from this thing when I need config data?  This rocks my world, moves my cheese, takes my polished refinements that let me be lazy a lot of the time and makes me do a lot more work.  Harumph.

 

The configuration manager said he would have the data as requested.  I'm sure it'll be wrong.  I know because Bill wasn't involved.  His spreadsheet-o-servers is the perfect match for my needs.  Why can't that wonky Configuration Manager just go discover Bill's spreadsheet and be done with it?  It's what everyone uses, anyway.

 

Intervention.

Ok, happy Jody is back.  Yes, I know it's a straw man - a target set up that's easy to argue against.  But you'd be surprised at what I've seen, what I've heard, how many pointy-haired bosses there are out there...Decisions are made based on many many other factors than the benefit of the outcome.  Fear.  Political expedience.  Malice.  Ignorance.  The list goes on.  Dilbert is funny because it's true.

 

COP Model to the rescue. (COP = Consumer/Owner/Provider - CMS Strategy Guide)

"Consumers drive providers" means that no provider shall onboard an attribute unless there is a consumer present with a use case.  It is the configuration manager's role to respond to consumer requests with an evaluation of the current providership, and augment it if ncessary, based on the consumer.

 

"Providers are transparent to consumers"  means that the consumer is not allowed to dictate a specific provider to consume from.   They may request or suggest, but it is the Configuration Manager's role to choose the provider of the data.

 

Both of these tenets are meant to protect the integrity of the data.  Think about what happens in their absence:  Data is onboarded without a consumer in mind.  And consumers get to pick and choose data sources that get onboarded.  Both of these are bad things.  They degrade the integrity and actionability of the CMS overall, for other consumers.  They may bias choice of provider data based on factors other than business accountability. 

 

The Process Protects the Process.

The Configuration Manager insulates the consumers and providers by acting as an emmisary between them.  The Configuration Manager is responsible directly for tings like saying "no" when an important consumer attempts to onboard non-authoritative data to the CMS.   For avoiding provider conflict when new providers are being onboarded.  One of the Configuration Manager's most powerful tools to protect CMS data integrity is the simple assertion: "We already have a provider for that attribute."

 

Who owns a CI?  Nobody.  Everybody.

Many apparent conflicts and problems go away when you look at providers with attribute-level granularity.  CIs may have multiple providers, so no one provider "owns" the whole CI.  Fiscally relevant attributes:  owned by Asset Management.  Service-related attributes, the Service and Configuration Managers,.  Operationally-relevant attributes, the Operations MAnagement system.     SACM and others are more prescriptive for who should be the provider for certain

 

The COP model is the strategy for building  processes used to build the operational ITSM processes around configruation management.  It lives inside any other stratege e.g. SACM you are implementing with.  The COP model is designed to help you create that squeaky-clean, intimately actionable CMS that provides that all-important common view of services, the one version of the truth.  No one provider owns a CI, the common denominator of CI owner is the business itself.

 

Want more of the COP model?  Talk to me.  That new change management system having trouble living up to the expectations of improved MTTR, MTBF?  Talk to us.

Thanks for listening!

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