Pink Elephant
The IT Service Management Experts

Troy's Blog

The Hitch Hiker's Guide to the IT Galaxy and Beyond
Don't Panic

Home

Author

Troy Dumoulin Photo

Troy DuMoulin, VP, Research & Development

Troy is a leading ITIL® IT Governance and Lean IT authority with a solid and rich background in Executive IT Management consulting. Troy holds the ITIL Expert certifications and has extensive experience in leading IT Service Management (ITSM) programs with a regional and global scope.

He is a frequent speaker at IT Management events and is a contributing author to multiple ITSM and Lean IT books, papers and official ITIL publications including ITIL’s Planning To Implement IT Service Management and Continual Service Improvement.

 

The Guide

"This blog is dedicated to making sense out of the shifting landscape of IT Management. Just when we thought we had a good handle on managing technology, the job we thought we knew is being threatened by strange acronym’s like ITIL, CMMI, COBIT, ect.. Suddenly the rules have changed and we are not sure why. The goal of this blog is to offer an element of sanity and logic to what can appear to be chaos."


Hitch Hiker's Guide to the Galaxy

"In many of the more relaxed civilizations on the Outer Eastern Rim of the Galaxy, the Hitch Hiker’s Guide has already supplanted the great Encyclopedia Galactic as the standard repository of all knowledge and wisdom, for though it has many omissions and contains much that is apocryphal, or at least wildly inaccurate, it scores over the older more pedestrian work in two important respects.

First, it is slightly cheaper: and secondly it has the words DON’T PANIC inscribed in large friendly letters on its cover."
~Douglas Adams

Syndicate

Troy On Twitter

Recent Entries

Categories

Links

Other Blogs

Archive


Friday, December 20, 2013

PR 52 - Dev&Ops: Defining Value From Two Sides Of The Same Coin

There is an instructive parable called “The Five Blind Men and The Elephant”  where five blind men set out one day to decide on how to describe an Elephant. Each person approaches the elephant from a different perspective and as you can imagine each produce a different result. One insisting that upon touching the Elephant’s leg that the Elephant is like a tree, another that the Elephant is like a snake, another touching the tusk states emphatically that the elephant is like a spear, and so on. Of course the moral of this story is that they were all correct based on their point of reference.

It is the author’s belief that this parable can be very easily applied to the core principles of DevOps and IT Service Management (ITSM). On the surface the two management approaches may seem dualistic in nature based on their general themes but look a bit deeper you will find more than a few parallels.

From the media hype one would assume that DevOps is entirely focused on increasing the speed of stakeholder value realization through shortening and automating testing and release cycles (get it done faster). However, another main tenant that does not get the same airtime is that DevOps also describes the need to bring operational requirements back into the early release cycle in order to establish the basis for release standardization and reliability.

IT Service Management on the other hand focuses on defining value in terms of customer outcomes expressed as services which are supported by a set of IT Management processes established to ensure value is defined, realized and improved through the discipline of Continual Service Improvement (get the right things done in the right way).


The million-dollar question (perhaps literally) is whether these seemingly opposing objectives can both be achieved by establishing a fit for purpose approach to blending the processes and timely actions needed and deliver both speed and quality?

On this show Chris and I discuss how Dev&Ops are co-dependent and indivisible.


Show Notes:

  • Troy’s New Role: VP of Research, Innovation and Product Management
  • Pink’s Conference in February
  • Practitioner Radio Live at Pink14
  • Conference Session: Dev & Ops – Two Tribes Under One Flag
  • Paper: Dev & Ops: Defining Value From Two Sides Of The Same Coin
  • Parable of the 5 Blind Men and The Elephant
  • DevOps and ITSM seem dualistic but are actually looking to both produce value
  • ITSM Perspective – Value Realization, Deliver Secure and Reliable Services
  • CIA: Confidential, Integrity and Available
  • DevOps: Looking at shorter release cycles and speed of value realization, culture of collaboration, bring operational requirements earlier in the lifecycle.
  • Just because you are looking for speed you cannot forgo security and stability
  • DevOps needs to get its Non-Functional requirements from ITSM, Architecture, Security, etc.
  • Service Orchestration via ITSM must coordinate all the value added build activities
  • Most people spend the majority of their time in un-planned non value added work.
  • The challenge of Technical Debt and Fragile Infrastructure
  • “IT organizations are expected to respond quickly to urgent business needs while simultaneously providing stable, secure and predictable IT service. However, the systems on which the business operates are typically fragile and hostile to change. Adopting Agile development processes without improving operational reliability or communication between developers and operations only makes this problem worse. The increased frequency of releases from development creates even more of a burden on an already strained IT Organization. Similarly adopting ridged ITIL/ITSM standards without addressing development issues and improving communication channels results in an inflexible IT organization that simply cannot respond to business needs quickly enough.” ~Puppet Labs - DevOps Report 2013
     
  • DevOps Report from Puppet Labs 2013
  • Lean Bright talk Session
  • The Phoenix Project
  • Article: Incident, Problem Change Dance
  • COBIT 5 Definition of Stakeholder Value: Benefits Realization, Risk Mitigation and Resource/Asset Optimization
  • Value is in the eye of the business Stakeholder

Troy Thunderbolt Tip: DevOps and ITSM are different sides of the same coin and I believe they are mutually supportive and in actual fact co-dependent and indivisible

Technical Debt & Service Orchestration:


Troy’s and Chris’s Thoughts What Are Yours?


“There are two questions a person must ask themselves: The first is ‘Where am I going?’ and the second is ‘Who will go with me?’  If you ever get these questions in the wrong order you are in trouble.” ― Sam Keen, Fire in the Belly


To subscribe to Pink’s Podcasts on iTunes 

(0) Comments
Posted by Troy DuMoulin on 12/20 at 11:12 AM
ITIL & Beyond (0) TrackbacksPermalink

Don't Panic

Tuesday, December 10, 2013

PR 51 – Geeking Out On CMDB Object Models

Do We Truly See Or Fully Understand Without The Perspective Of Context?

Regardless of the marketing hype to the contrary I think that most people would agree that technology has made our lives more complex rather than simpler?  This is also true of our human or personal systems as much as it is with our lives at work. Facebook, Twitter, LinkedIn, etc. continue to increase or private networks as we connect / re-connect with people from our current life and distant past. To help us maintain sanity and perspective these social tools help us to visually map our relationships in ever widening arcs of relationship and connectivty.

A critical element in keeping all this detail in a form we can easily understand is a visual map or model that represents with whom and how we are connected. Whether this map is presented as a Mind Map or a Family Tree we need a relationship model we can visualize and follow in order for us to place ourselves within the context of the overall system.

These same visual models are are key for IT professionals to understand and represent the complexity of an IT System that is often made up of hundreds of dependancies. Many of these dependancies are outside our own organization in the same way that our human system is made up of people from across the globe.  From an IT Service Management discussion this discussion is part of the Process of Service Asset and Configuration (SACM) and specifically called out in a deliverable referred to as Configuration Management Data Base (CMDB) Object Model Design.

In discussing this with many people over the years the SACM project has often been started and abandoned and re-started many times. The very nature of the complexity of the project is often used as a reason to stop or not start. However, my perspective is that the complexity of the system is in actual fact a business case for giving SACM the attention it needs.

As a base premise I believe it is reasonable to assume that IT professionals should be able to articulate and describe how any technology element enables business outcomes. If we cannot do this how do we understand technology value or risk or claim to be aligned with business objectives?

No - Complexity is not in and of itself a reason to throw in the towel but it is a good reason to build a business case for high degrees of discovery and automation in a SACM project. My experience shows me that any organization’s which attempt a SACM / CMDB project from a purely manual perspective will not be able to maintain the accuracy of the CMDB over the long term. On the other hand this is not something we can delegate totally to Nano Bots and automated systems without human governance and some degree of human data entry.

All this said and done a CMDB project must start with a Data Model design as well as a process defining governance and management roles. In this Podcast Chris and I explore the interesting world of CMDB Data models.


Show Notes:

  • There are Circles and then there are circles
  • The Movie Inception
  • The CMDB Unicorn in the room?
  • CMDB – Spruce Goose, Death Star Or Answer To World Peace?
  • Context is necessary for System Thinking
  • Service Definition is the DNS Construct for All Service Management
  • CMDB = Visual representation of the Service Model
  • The Picture Is The Thing That Captures The Imagination Of the King – Shakespeare
  • CMDB & Google Streetview – Pulling back for context
  • Configuration Management System (CMS)
  • Service Knowledge Management System (SKMS)
  • Visual Representation of Service Relationship & Tools eg: CA Unicenter TNG 10 years ago



  • What’s the business case for a CMDB when you don’t understand or manage against services?
  • Tools are not the constraint to CMDB
  • CMDB Visualization tools
  • The true constraint for CMDB is task specialization and cultural resistance on system’s thinking
  • BMC Atrium Example



  • Modelling Cloud Services and Virtual Elements in a CMDB?
  • Today’s Cloud Discussion is the same as the WAN Modeling Challenges



  • Modelling Physical and Virtual Objects (SANs, VLANS, VMs)
  • Fit for Purpose Modelling
  • Complexity is its argument for definition
  • The more complex the puzzle the more important the picture on the puzzle box
  • We design in context to systems but we manage technology in mythical isolation
  • Need the blueprint before I can build the thing!
  • Article: CMDB Resort Condominium



  • Context is subjective?
  • The need for Context relies on core beliefs and language
  • Subject change: News Microsoft abolishes Stake Ranking
  • Stack Ranking re-enforces silo or individual focus and results
  • Human Systems are even more important as Technical Systems

Troy’s Thunderbolt Tip: Until we understand and culturally accept the need to manage services and technology systems dependencies we will never really be able to say IT is aligned with business needs

Troy’s and Chris’s Thoughts What Are yours?


“Remember, always, that everything you know, and everything everyone knows, is only a model. Get your model out there where it can be viewed. Invite others to challenge your assumptions and add their own.”
― Donella H. Meadows, Thinking in Systems: A Primer


To subscribe to Pink’s Podcasts on iTunes 

(0) Comments
Posted by Troy DuMoulin on 12/10 at 12:21 PM
ITIL & Beyond (0) TrackbacksPermalink

Don't Panic

Page 1 of 1 pages