MyServiceMonitor, LLC

Back in February of 2007 I wrote a blog post called, Implementing a CMDB is Like Blogging Alone: Why Products & Process won't be enough to reconnect with the business. In this post I ranted about things like social capital and made the claim that the CMDB -- as depicted by ITIL --- did not provide people with a real-time connection and that intelligent service oriented monitoring is a better path to ITSM excellence.

 I still feel that "the case for service-oriented monitoring, particularly where real-time analytics can be incorporated into the solution, can provide every stakeholder with an end-to-end view of the IT business service infrastructure that is tailored to their perspective; without the time, cost and risk of implementing a CMDB. (See the White Paper, Choosing a monitoring system for your IT infrastructure?)".

 Of course with the release of ITIL Version 3 what I used to call a CDB --- simply because the ITIL Version 2 guidance left me little other choice --- I realize now that this 'CDB' is really another CMDB within ITIL Version 3's "CMS (Configuration Management System)".

 In fact I've always felt  it doesn't really matter...CDB, CMDB, PMDB, and the debate over these and other terms it just distracts us from the real problem and encourages the status quo. Big vendors, 'integrated ITSM suites' and 5 year visions of nirvana....

 Then today I came across a book in PMI's eReads & Reference site (a nice deliverable itSMF might consider) called Dialog Mapping -- Building Shared Understanding of Wicked Problems.

Event Management automation and implementing service-oriented monitoring have all the same characteristics of adopting IT Service Management; they are WICKED PROBLEMS. This rant is about this book and how it applies to monitoring automation in ITSM environments.

 Fragmentation and Organizational Pain

 This particular quote early in the book screamed at me:

 “There is a subtle but pervasive kind of pain in our organizations. It is characterized by such frequently heard complaints as 'How am I supposed to get my work done with all of these meetings?' and 'We always have time to do it over again, but never time to do it right.'

 It is a sense of futility of expecting things to be one way and repeatedly banging into a different reality. It is the dull ache of déjà vu when you are handed an impossible deadline or a vague assignment. It is the frustration of calling a meeting to make a decision and watching the meeting unravel into a battle between rival departments, or get lost in a thicket of confusion over the meaning of a technical term. It is the frustration of finally achieving a hard-won decision and then having it fall apart or get 'pocket vetoed' because there wasn't really buy-in. It is the pain of fragmentation.”

 The book went on to describe Wicked Problems as 

“so commonplace that the chaos and futility that usually attend them are accepted as inevitable. Failing to recognize the 'wicked dynamics' in problems, we persist in applying inappropriate methods and tools to them.”

 It also notes that, 

“Another force of fragmentation is social complexity, the number and diversity of players who are involved in a project.”, and goes on to say, “Social complexity means that a project team works in a social network, a network of controllers and influencers including individual stakeholders, other project teams, and other organizations. These relationships, whether they are with direct stakeholders or those more peripherally involved, must be included in the project. For it is not whether the project team comes up with the right answer, but whose buy-in they have that really matters. To put it more starkly, without being included in the thinking and decision-making process, members of the social network may seek to undermine or even sabotage the project if their needs are not considered. Social complexity can be understood and used effectively, but it can be ignored only at great peril.”

 I cannot elaborate more without simply copying the entire book, but it makes the following points that are extremely relevant to ITSM adoption and particularly the challenges of moving from multiple, silo-based monitors to a single, intelligent and service-oriented monitoring paradigm.

1. Understanding the social complexity in a large organization is extremely difficult, and without a sustained and concerted effort projects are likely to flounder or be sabotaged.

2. Scoping or targeting the introduction of service-oriented monitoring is extremely important, and provides an opportunity to plan an effective strategy to deal with organizational complexity.

3. Because adopting ITSM and implementing service-oriented monitoring are Wicked Problems, people managing these projects must be on the lookout for organizational coping mechanisms such as studying the problem and taming it[1].

 Managing Monitoring Automation Projects

 Customers who really want to leverage investments in monitoring automation should incorporate project management into the business case. While the technical complexities of some automated solutions are not severe, the social complexity makes this a Wicked Problem.

 Project managers with good facilitation skills, management support, and some organizational knowledge may be more important that pure technical skills. Conducting Event Management workshops, modeling business services and facilitating --- perhaps using dialog mapping or similar techniques – are important factors for realizing the full potential of these investments.