“Out with the old, in with the new” is a phrase which has been uttered for millennia.
With the recent introduction of ITIL 4, this phrase definitely comes to mind through an implication that much of ITIL V3, including the “Service Lifecycle”, is to be thrown onto the proverbial junk pile.
This notion was reinforced somewhat during an ITIL 4 webinar I recently watched put on by my good friends at ITSM Academy and presented by the brilliant Donna Knapp. Fairly early in the presentation, this slide was brought up:
Unless I completely misunderstood the point (which is entirely possible) this slide seemed to suggest that virtually everything done by Agile, Lean, DevOps and SRE (Site Reliability Engineering) somehow magically (note the magic wand) takes place in what was called a “gap” between the Service Design and Service Transition lifecycle stages and somehow separate from the Service Lifecycle.
Wait a minute.
While it took me some time to embrace the concept of a “Service Lifecycle” with the introduction of ITIL V3, I've come to realize that a "lifecycle" was and still is not only appropriate, but a naturally occurring phenomenon.
Lifecycles exists in virtually everything and everywhere. Insects, plants and animals (including human beings) – even planets and stars and our universe itself – are born, live and die. Beginning, middle, end.
Civilizations rise and fall. And yes, “The Game of Thrones” had a first season and now a final season. (Sigh.)
Every software engineer or programmer must recognize that there is, was and always will be a lifecycle associated with their work. Beginning, middle, end.
How that lifecycle manifests itself may change, for example, from “waterfall development” to “agile development”, but there is no denying that there is a lifecycle at play.
When ITIL V3 and the Service Lifecycle were first introduced in 2007, many people, including me, were scratching their heads about the “Service Lifecycle”. My good friend, Ken Hamilton, and I got together to discuss the implications.
Walking up to whiteboard in the conference room, Ken drew two tall boxes, labeling the first on the left side of the board “Business outcomes” (value) and the other on the right side of the board “Services”. The large “gap” between the two, he explained, needed to be filled by the two important parts of an IT organization: Development and Operations, each of which living within its own “lifecycle”.
He then added the “Operations Lifecycle”, a sort of truncated triangle, illustrating that Operation’s involvement may have started out as relatively small but grew larger the closer something was to being put into production. Below it he drew another truncated triangle - the “Development Lifecycle” – which, conversely, started out larger and grew progressively smaller the closer to production.
He then drew a thick line between these two lifecycles, pointing out that one of the biggest problems faced by many IT organizations in coming up with good IT Services to achieve customer outcomes is that there was often a “wall” (figuratively speaking, though sometimes literally) between the Development teams and the Operations teams and their respective lifecycles.
Ken laughed and said that he had recently asked a CIO how well the Development and Operations teams within his IT organization got along. Shaking his head, the CIO answered, “Well, let me put it this way: they don’t go out after work and have a beer together. And they certainly don’t get together on the weekends to play golf.”
Because they didn’t always get along very well, they didn't communicate or collaborate very well either. (Maybe this isn't an issue anymore?)
What Ken put on the whiteboard looked a bit like this:
Ken went on to say that the (then) recently introduced “5 Stages” of the ITIL V3 Service Lifecyle could be superimposed over those two lifecycles, like this:
As we discussed this, our biggest realization was that by introducing the ITIL Service Lifecycle stages and incorporating them into how IT as a WHOLE functions, they could effectively break down that “wall” between the Development and Operations Teams and replace it with both a better understanding of each teams role and clear points of communication and collaboration.
I have since referred to this diagram as the “ITIL V3 Value Proposition”, a (hopefully) clear illustration on how the Service Lifecycle - properly understood and applied - effectively integrates the “Dev” lifecycle with the “Ops” lifecycle thereby helping support and enable concepts of DevOps, as well as Agile development and other practices.
I will solidly go on record that there is a LOT to like about ITIL 4 and it does indeed help modernize the approach to IT Service Management. But isn't this diagram of the ITIL 4 "Service Value Chain" at least somewhat reminiscent of a lifecycle with a beginning, a middle and an end?
The bottom line is, don't be too quick to “throw the baby out with the bathwater”.
The concept of a lifecycle is certainly not dead. Go ahead and do a Google search on either “Agile lifecycle” or “DevOps lifecycle" and you'll get well over 22 Million results each.
Lifecycles won’t go away. It is important to understand where and how they intersect and where communication, coordination and collaboration points are required.
We need to understand the "big picture". It is ultimately about value.
While I will argue vehemently that there must always be a bias toward action, there will always be a need for (at least room for) some level of Strategy development. Design thinking and good design is needed as well. Steven Jobs said ”Design is not just what it looks like and feels like. Design is how it works”.
By whatever means something may be developed, it will have to be successfully transitioned into and ultimately must operate successfully within a “production” environment.
Lastly, of course, continual improvement all across and within every lifecycle stage is a fundamental requirement.
To paraphrase Mark Twain, “The reports of the death of the Service Lifecycle have been greatly exaggerated.”
Comments