Malcolm Ryder
Sep 7, 2018 · 2 min read

Hi Jon,

as the pre-BMC strategy management lead for the Remedy ITSM product line and eBusiness Infrastructure Solutions, I’m really pleased to see you in place now so many years later with your POV and energy — and it is finally not surprising, however, that things have mostly not changed in the field since the late ’90s. I love the observation that (said in different words from yours) ITSM has not yet switched from a Swiss Gears & Torque engine to a Quartz & Solar engine… but I also think that the reason new acronyms and paradigms sprout and then diverge, overlap or compete is because management is multi-dimensional and most people don’t learn management across multiple dimensions.

The myopia of one-dimensional or two-dimensional experience actually gets reinforced continually by things like organizational reporting hierarchies and hyper-competitive hiring — which are both driven more by business competition than by operational effectiveness; but of course the logic of managing business is not going to uncouple those two things. There is the “inertia” we face, and I believe it is another (but related) discussion.

Instead, what our discussion needs to accomplish, as a learning experience, is a broadly shared awareness that the entire constellation of paradigms, models, and “best” practices is simply the current state of how our attention to the big picture is distributed and focused. DevOps is not the big picture. ITSM is not the big picture. Agile is not the big picture. Each exists for a distinctive reason that becomes far more apparent when we ask the question, “what happens if we just remove <whatever> from the picture?”

Our big picture, which has not changed since the 1990s, continues to identify (a.) managing engineering as a strategic source of infrastructure; (b.) managing infrastructure as a platform for service provision; and (c.) managing service as a product for business operations. While the logic of hierarchical dependencies is explicit in that wording, it is nonetheless true that each of the three changes somewhat independently of the other two, because it can. Over time, the aggregation and alignment of changes looks like (fair enough) “evolution”.

So, segue back to the topic here, which is about ITSM transformation/revolution… and regardless of ITIL v.X or any other reference documentation, the issue is to distinguish what is a service, why it needs to be managed, and what it is about a service that gets manipulated to satisfy the “why”. ITSM’s own re-engineering probably is not about changing timekeeping, but it probably is about finding the quartz and using it appropriately to satisfy the why.

    Malcolm Ryder

    Written by