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.
- 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
- 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
“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
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
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.
- 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
Friday, November 22, 2013
PR Radio 50 - The Ins and Outs Of Process Assessments
Thoughtful and Careful Reflection Is Key To Purposeful and Effective Improvement
In the world of military strategy it is always a good thing to do reconnaissance and gather intel before storming the beach or charging the the hill. Of course, process improvement is never quite so dramatic. However those of you who have lived the life in the CSI Warrior in the process engineering trenches can probably attest to the fact that knowing the lay of the land and avoiding political mines and hidden tiger traps is always a good thing. A little foreknowledge can go a long way when identifying solid ground for project scope identification, or the existence of an existing centre of excellence you can leverage and reuse in other places of the organization.
From this perspective I believe that most listeners would agree no one likes to thrash about blindly and that having a current state map of the existing practices landscape will help greatly in navigating to a chosen end state destination.
With this premise in mind Chris and I are delighted to have Robin Hysick as a guest on today’s Practitioner Radio show to talk to us about the right and wrong ways to go about conducting a process assessment.
- Robin Hysick – Director of Product Management & Pink’s ITSM Process Assessment Practice Lead
- Assessments do double duty. (Where are we today & Critical for building buy in
- Capturing People’s voice is critical for management of change
- People don’t care what you know until they know that you care
- Why should I bother having you tell me what I already know?
- Organizations usually have more in place today then they may realize
- Standardization is a key goal for assessments. Reduce Variability
- Four Reasons For Process Assessments
- Planning (What do we have and what’s next?)
- Validation (Getting beyond Relativity & Subject Opinion)
- Deployment Insurance (You get what you inspect)
- Proof of Benefit Realization (What have you done for me lately?)
- Surveys (Good for Raw Data)
- Attend Meetings
- Leading Questions (Don’t teach while assessing)
- Open and Closed questions
- Avoiding leading questions
Robin’s Thunder Bolt Tip Of The Day: Treat the Assessment for what it should be – an opportunity. Not a task in a project plan but something that will take you a lot further. In understanding where, how and over time. An opportunity to improve the people side of “Buy In” for your project goals.
In the words of my good friend and fellow Pinker, Gary Case “You Can Expect What You Inspect”
To subscribe to Pink’s Podcasts on iTunes