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

How Long Should a CMDB / CMS Take to Build? Part 3: Process Engineering

This is the third post in the "How Long Should a CMDB/CMS Take to Build" series.


 


Today's tagline: YOU must make the final journey to the right process.  No one else, not even a cherished trusted vendor or analyst, can make it for you.  But they can act as a spiritual advisor.


 


ITIL Process engineering is the second most important part of the deployment, the most difficult to get right except for people and cultural change.  The only reason process engineering is slightly easier than these is because you at least have better measurement tools.


 


And I'm talking about ITIL processes here, for which additional complexities apply.


 


There aren't many vacant lots left in downtown ITIL.  I'm talking about process RE-engineering as well, because almost none of you are building a data center from scratch.  You already have some kind of processes, bethem manual or dysfunctional.  Part of the process-building involves assimilation and demolition of parts of the earlier generation processes.


 


So what do you start with:  Needs, goals, plans, budget, vendors, tools?  Turns out it's not so straightforward.


 


It's a paradox.  You can't easily build your processes without a tool in mind or you will not be able to find a tool that does everything you want.  Don't believe me?  Go ahead, try, you'll spend a ton of money on column fodder and end up picking the vendor that can just fill in the most columns - a disappointing and possibly unwise strategy.


 


However, you don't want your processes to be tool-driven because you will end up locking out the most important KPIs which are fulfilling your use cases exactly. 


 


So, do I pick a vendor first, or define my requirements first?  My answer:  it's an iterative process, there is no prescriptive approach that ensures success - you must have a good IDEA of your processes, then court a few vendors, then get some preliminary input to refine your idea of what config management should be, ask a few more questions, and repeat until you have a good foundation that will fulfill your use cases and is supportable by a solution you can buy and build.


 


The CMDB is a tool, maybe even a platform.  The CMS is a deployed operational solution.  You must still operate it with your own processes and people.  Good luck with ITIL.  You'll need more than that.  But I digress.


 


If you expect your vendor to supply all the processes because the tool won't work without them - you're in trouble.  You must still understand all your processes to the point where YOU are doing the service transitions and operations.  Most  vendors can't and won't care as much about how well your processes work, and at best will deliver incomplete, high-level, or overly-generic  processes, the same cartoon version of IT that ITIL already provides.


 


 As a vendor you have to work really hard to create and deliver a good process layer of best practices around your CMS and CMDB.  And while I've tried hard (that is one of my projects at HP), I cannot fool myself that we have gotten everything right, in fact or in principle.  Experience and the rigorous discipline of journal-keeping,  analysis, and continual improvement are our only lights into the future of process.  Don't let anyone else sell you otherwise.


 


Some final recommendations:



  • Get yourself some wild, angry beekeepers.  They'll keep your you, as well as your vendor, honest, and help you identify the needed, the unneeded, and the just plain stupid.

  • Come to recognize the smell of crap factoids.  Analysts and vendors, like Alpha Geeks, CIOs, bloggers, and help desk technicians, are not immune to hubris. 

  • Not all IT organizations need to "mature" all of their processes to the maximum "maturity".  Avoid unnecessary or self-fulfilling scaffolding, even if it's your vendor's favorite.  Even though ITIL says you should be doing something, you must decide for yourself whether you actually should be doing that thing.  And  it's not always easy to determine.  Read.  Study.  Know not just IT but YOUR IT.  In the vicious world of ITIL, knowledge isn't just power, it's survival.

  • Same thing I tell all the school kids I teach astronomy to: Keep asking questions.

  • Configuration management, like education, is not about filling a bucket, it's about lighting a fire.   Think, motivated, self-policing, continual service improvement.  Incent your people to seek out improvement and they will do so, to your benefit.  Too expensive?  Don't expect much help.

  • If you don't understand something but should, go ahead and ask the question.  But remember the risk.  And think about who you should ask first.


 


I hope this post touches a nerve, or gets through to someone, or even angers someone enough to post a reply.  I'd really like to hear what you think.  Thanks for your time.

Meet The Experts: A series of webinars on managing a virtualized IT environment

HP recently sponsored a series of virtualization roundtables, run by CIO magazine, titled "What your team's not telling you about virtualization". Over the course of these virtualization roundtables, we heard from more than 100 IT executives (C-Level, VP…) about what’s on their minds regarding the management challenges around virtualization. They were very interactive discussions between the HP speakers and the customers, and regardless of the industry or city they were in, a set of common needs were expressed by these IT executives, including the need to:


• Automate change across physical and virtual environments that make up the business service


 • Become more cost efficient


• Increase IT operations efficiency and delivering high-quality services


• Better enable business continuity and compliance


• Manage asset and software entitlements, contracts and deployments


• Learn from their peers and from HP about the best practices around virtualization


 As a result of this feedback, we scheduled an April web event series (six one-hour virtual discussions) that drills down to answer these common needs. They are called the ‘Meet the Experts’ presentations where virtualization experts discuss best practices. Some of the speakers are from HP, some are customers. The dates and topics are:


 • April 13 - Optimizing service modeling, discovery, and monitoring for VMware environments


 • April 14 - Protecting Virtualized Environments from Disaster with HP Data Protector •


 April 21 - Testing Smarter and Faster with Virtualization


• April 22 - Improve customer satisfaction and maintain service levels in virtualized environments


• April 27- BCBS of Florida builds a foundation for virtualization with HP Asset Manager


• April 29 - Virtualization: Compliance enforcement in a virtualized world


If you are interested in listening to any of these presentations you can attend by registering at: https://h30406.www3.hp.com/campaigns/2010/events/1-8K6H1/index.php?rtc=3-3ERQKL8&jumpid=ex_r11374_us/en/large/eb/adv3_virtualization_wave_sdr_ptr/rtc_3-3ERQKL8/20100310.  I think they will be interesting and insightful if you want to learn more about how to manage a virtualized environment!


 

Wild, Angry Bees and Why Your ITSM Vendor Needs Them

For some years now, I've been building up a resistance to kool-aid.  How?  Personally, I'm a pretty calm balanced person.  But as a software professional, I'm a wild, angry beekeeper.  I'll explain.


 


Angry is good, sometimes - A wise man once said, it is impossible to truly know the capabilities of a product unless it is used in anger.  This spoke volumes to me when I read it.  It explained so many problems, to me especially problems associated with product quality.  UI design and friendliness.  The OOBE (out-of-box experience)  KPI.   TTV (Time-To-Value).  Why it is sometimes so hard to get a non-trivial problem reproduced and fixed.


 


Wild vs. Tame - As a software professional employed by a vendor, one tends to become familiar and even attached in a geeky sort of way to the products with which one works.    From your product's perspective, you are "tame" to it, as opposed to a user, who is "wild" to it.  An example of a "wild" user is someone who has been given a tool without direct choice, someone who hasn't been "sold" on the product.  Someone who can draw objective, unbiased  conclusions about the product's suitability.


 


"Wild" users seem to frighten software vendors.  Wild angry users are more likely to seek out and verbalize defects, and are resistant to lame workarounds (we all know the smell of a lame workaound that's a poor fit, or impractical to implement.  Especially when an obviously lame feature is "working as designed".  Yes, but it was poorly designed.  WAD is a loophole designed to take the vendor off the hook .


 


And that is a very well-designed and functional loophole, don't you fall into it.  My advice for wild, angry users:



  • Get on the vendor's advisory board.

  • Be active on forums and communities where these ideas are discussed.

  • Don't give up.  Persistence will get you very far.

  • escalate if the Working-as-designed isn't

  • DOCUMENT your problem, don't just complain about it.

  • Have a positive attitude when you're working with Support, especially if you are a Wild user.

  • If you angrily tell the tech support person "Your product is broken, fix it.", while it may clearly be broken, and while it may clearly need fixing, you're going to get a lot more help more willingly if you are forthcoming with details and are just a little bit nice. 


 


Here's my hyphothesis:  If you are sufficiently "tame", "workarounds" become indistinguishable from "features".  But if you are wild, "workarounds" anger you.  Every time you have to do a "workaround", you just wasted a little of your time and your company's money trying to make a product do something which it should do (your justification for spending time on it) but doesn't (the problem wasn't anticipated or wasn't important enough to fix in the version you're using.)


 


 The lesson and challenge is for software organizations to use wild  QA and product management and (were it possible) wild marketing.  It will HELP you to find out your own problems before the paying wild customers do.  Expensive but worth it - tell me if you agree, would you pay more for a product that had wild users QA it first?    The famous physicist Richard Feynman said it best:  You first have to work at not fooling yourself - then it is easy to not fool others.  If you've never read his cargo cult science speech, it is illuminating and priceless if you care about research or technology integrity.


 


Bees - We tend to want to go after the major themes and features going into the next release, the "big game".  The relatively slow, big targets, and only dangerous if you get too close.


 


But while you're waiting for the big game to come along, you're constantly attacked by diminutive "almost-bugs"  -  bees and mosquitoes - all the small features or lack thereof which add up to either a very positive or very negative feeling about the product's usability.  It is these that will kill a product more quickly than starvation, if you don't deal with them quickly.


 


Tame users are used to the bee stings.  But wild users are not.  Bees can be big mistakes in the eyes of the "wild" users.  Anger-generating mistakes.  Anger not often understood by the vendor.    "Can't you just…" is the wrong attitude no matter what words  follow.  It's the death of a thousand bee stings to a vendor.  High TCO.  Unfriendly features.  It's not being run over by the elephant.  You can adjust your road map and invest in the new feature and do it right, recover or advance or whatever, but it's very difficult to recover from a thousand angry bees - wild users who get stung a lot tend to sabotage your product if they can in retaliation for being forced to use what they perceive as a poor choice of product.


 


This post is really an essay on software engineering.  The tie-in to Configuration Management is, I want this short post to be a mental runway from which you can fly to your own conclusions about your choice of vendor for your ITSM solutions.  For some really good  essays on Software Engineering, check out this gentleman, Mr. Fred Brooks,  and his timeless anchor-to-reality classic, The Mythical Man-Month.  Mr. Brooks is the father of much of what we know as commercial software today. 


 


Maybe you wild and angry beekeepers out there will understand a little better the tremendous opposing forces facing software vendors.  Maybe you competitors will realize how one gets so far behind GOOD software companies that understand my wild and angry allegory.  And maybe, just maybe, you can help me keep a burr under our own R&D saddle - they ride fastest that way.  With love to all my R&D friends, of course!  They really do a tremendous job given their constraints.


 


I'm very interested in what you have to say about my Wild Angry Bees.  Please comment and let us know.  Thanks!


 

Avoid a Vendor-Customer Disconnect with CMS and CMDB

So after all the soul-searching and researching, you've decided whether or not you need a CMS.  Or have you?  Have you yet sorted out the sordid relationship between CMDB and CMS?  CMDB was ITIL v2, but it's still around in v3's CMS, what's up with that?  What's a CMS again?  Can't buy one.  Has some CMDBs around, why won't just one do?  What's different?  What's a/the CMDB supposed to do?  Why doesn't the vendor just tell us what to do?


 


Does realizing you need something mean you've decided exactly what it should do, what you expect out of it?  One would hope so, but it's of course not that simple.


 


As a customer, it's a complex answer:  Fulfill and support my use case(s).  Build my processes according to the needs of my business family.  And within the capabilities of technology I can afford.   ITIL doesn't help much with the "T" part.  You must build or buy or fake something.  And you can't believe everything you read.


 


But as a vendor, getting it right is even dodgier - you have to decide what the technology should be, based on your knowledge, vision of the future and the needs of your market.  Not enough, and you lose to competitors.  Too much and you have quality ,usability, and other problems (I'm saving that for another post.)  You better trust who you go with into this very uncommodotized world.


 


Foremostly, by definition, the CMS and it's CMDB(s) are there to manage configuration information.  Everything else in the stack serves this purpose.  However, this isn't a very useful definition.  What does it take to "manage" configuration data?  It's not even so easy as to define it in terms of a lifecycle, or discovery or a database or APIs.  What's required is to understand how configuration management interacts with all the providers and consumers of CIs.


 


A CMS should understand dependencies and relationships as they exist in reality, not just contain a model created by a human - humans miss lots of things like this.  Tell me your all-knowing person keeps track of every .NET connection that lasts 3 milliseconds yet during those milliseconds some mission-critical data is exchanged.


 


Dependency discovery and mapping is not just for impact analysis.  There is compliance and audit, DR planning, data center transformations, and other use cases which absolutely require visibility to the dependencies and relationships of applications and infrastructure.  A CMDB must make it easy to make and use dynamic topology visualization (service models, application maps.) for a variety of use cases, not just the ones we can envision.


 


A CMS must support states of CIs, like "actual" state, "authorized" state (to compare to, control, audit, report, etc.)  There are reasons to make a CMS support an arbitrary number of user-definable states so customers can tightly couple their lifecycle stages together.  The importance of this is described in the ITIL books, and I will expand on it in a later post.


 


To support a CMS, a CMDB must be a powerful data integration platform, complete with



  • An ontology (Class model), and the ability to manipulate and extend it easily

  • Openness and interoperability (fully-formed discovery, federation,  and APIs.  It's also nice to actually document these things so users can use them, and even better - have a good UI that does all the hard parts of things like keeping names and properties right.  You wanna annoy users?  Make 'em configure the entire product and build all their integration with text files.

  • Capabilities to easily establish common identity and reconcile distributed data.   This is colloquially called a "reconciliation engine" but I'm uncomfortable with the term; it conveys the wrong focus on what should really be going on with multi-source identity.  It's an "engine".  Something under the hood.  Give it gas and it gives you power.  No, no, no.  Reconciliation is powered by business logic, not a commodity-like  fuel, and you can't buy it off (or the investment required) with descriptions like an "engine", even the software kind.

  • Easy-to-use Extensibility - you want to work with standard "pipe-fittings", not a welder-and-torch approach to customization.  Beware vendors whose only approach to integration flexibility is writing your own code.  It has to be actually easy to build and extend any kind of integration and discovery content you need.


 


Any CMDB and CMS has to be secure in all ways at all times, it has to perform and scale, and otherwise be Enterprise-ready.  You'll rarely get in the door without this.


 


A CMDB has to be deployable and supportable with practical TCO.  It can't take a room full of people to manage.  A lot of software is great at generating more work than the work it saves you from doing.


 


If you were expecting deep insight into vendor-customer relationship science, sorry to disappoint.  I believe that good technology that implements the right understanding of customers is what succeeds (usually, although the bookstores are full of examples that prove me wrong, where inferior technology won out because the salesperson's technique was better or more money was spent on marketing than the competition's.  These are exceptions rather than rules and that's why they make it into books - when a superior product wins, it's unremarkable except to the vendor, who is understandably happy.)    Agreeing on what the technology is and does is a necessary step to avoid a disconnect between IT organizations and software vendors.


 


The "why" of all this covers lots of ground, on which I hope you all have opinions you'd like to share.  What else do you think a CMDB has to do and why?  Feel free to post a comment and let us know.  Thanks!


 

Search
About the Author(s)
  • HP IT Service Management Product Marketing team manager. I am also responsible for our end-to-end Change, Configuration, and Release Management (CCRM) solution. My background is engineering and computer science in the networking and telecom worlds. As they used to say in Telcom, "the network is the business" (hence huge focus on service management). I always enjoyed working with customers and on the business side of things, so here I am in ITSM marketing.
  • David has led a career in Enterprise Software for over 20 years and has brought to market numerous successful IT management products and innovations.
  • Gil Tzadikevitch HP Software R&D Service Anywhere
  • This account is for guest bloggers. The blog post will identify the blogger.
  • Jacques Conand is the Director of ITSM Product Line, having responsibility for the product roadmap of several products such as HP Service Manager, HP Asset Manager, HP Universal CMDB, HP Universal Discovery and the new HP Service Anywhere product. Jacques is also chairman of the ITSM Customer Advisory Board, ensuring the close linkage with HP's largest customers.
  • Jody Roberts is a researcher, author, and customer advocate in the Product Foundation Services (PFS) group in HP Software. Jody has worked with the UCMDB product line since 2004, and currently takes care of the top 100 HP Software customers, the CMS Best Practices library, and has hosted a weekly CMDB Practitioner's Forum since 2006.
  • Mary is a member of HP’s ITSM product marketing team and is responsible for HP Service Anywhere. She has 20+ years of product marketing, product management, and channel/alliances experience. Mary joined HP in 2010 from an early-stage SaaS company providing hosted messaging and mobility services. She also has product management experience in the ITSM industry. Mary has a BS in Computer Science and a MBA in Marketing. Follow: @MaryR_Colorado
  • Michael Pott is a Product Marketing Manager for HP ITSM Solutions. Responsibilities include out-bound marketing and sales enablement. Michael joined HP in 1989 and has held various positions in HP Software since 1996. In product marketing and product management Michael worked on different areas of the IT management software market, such as market analysis, sales content development and business planning for a broad range of products such as HP Operations Manager and HP Universal CMDB.
  • Ming is Product Manager for HP ITSM Solutions
  • Nimish Shelat is currently focused on Datacenter Automation and IT Process Automation solutions. Shelat strives to help customers, traditional IT and Cloud based IT, transform to Service Centric model. The scope of these solutions spans across server, database and middleware infrastructure. The solutions are optimized for tasks like provisioning, patching, compliance, remediation and processes like Self-healing Incidence Remediation and Rapid Service Fulfilment, Change Management and Disaster Recovery. Shelat has 21 years of experience in IT, 18 of these have been at HP spanning across networking, printing , storage and enterprise software businesses. Prior to his current role as a World-Wide Product Marketing Manager, Shelat has held positions as Software Sales Specialist, Product Manager, Business Strategist, Project Manager and Programmer Analyst. Shelat has a B.S in Computer Science. He has earned his MBA from University of California, Davis with a focus on Marketing and Finance.
  • Oded is the Chief Functional Architect for the HP Service and Portfolio Management products, which include Service Manager, Service Anywhere, Universal CMDB & Discovery, Asset Manager, Project and Portfolio Manager.
  • Olivier is Product Line Manager for the HP Configuration Management System (CMS) which is comprised of UCMDB, UCMDB Configuration Manager, the UCMDB Browser, and Universal Discovery.
  • I am Senior Product Manager for Service Manager. I have been manning the post for 10 years and working in various technical roles with the product since 1996. I love SM, our ecosystem, and our customers and I am committed to do my best to keep you appraised of what is going on. I will even try to keep you entertained as I do so. Oh and BTW... I not only express my creativity in writing but I am a fairly accomplished oil painter.
  • WW Sr Product Marketing Manager for HP ITPS VP of Apps & HP Load Runner
  • Vesna is the senior product marketing manager at HP Software. She has been with HP for 13 years in R&D, product management and product marketing. At HP she is responsible for go to market and enablement of the HP IT Performance Suite products.
  • A 25+ year veteran of HP, Yvonne is currently a Senior Product Manager of HP ITSM software including HP Service Anywhere and HP Service Manager. Over the years, Yvonne has had factory and field roles in several different HP businesses, including HP Software, HP Enterprise Services, HP Support, and HP Imaging and Printing Group. Yvonne has been masters certified in ITIL for over 10 years and was co-author of the original HP IT Service Management (ITSM) Reference Model and Primers.
Follow Us


HP Blog

HP Software Solutions Blog

Labels
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