“X as a Service” – Are you sure?
You say it’s “as a service”
…but are you sure?
They say hindsight is 20/20…
In my last blog post (click here) I mentioned that I realized that I had never done anything “as a Service” correctly before joining the Enterprise Service Management SaaS company. Even though I had built numerous designs and architectures that were based on Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and IT as a Service (ITaaS) over the course of my career. When I joined NOW, I truly thought that I knew what “as a Service” meant. I would have gone toe-to-toe with anyone that wanted to discuss it. And, in the circles that I ran in, most would have agreed with me. From an Infrastructure point of view, we thought we knew what that meant.
The key factor in this epiphany is entirely based on perspective. We all see the world through a certain point of view and from that perspective we make assumptions and stories that paint a narrative that supports our views. In my case, I had about 17 years of infrastructure experience that dictated my perspective. Created my reality. My story of “as a Service” as an Infrastructure person went something like this:
· You must act like a service provider selling a product.
· You need to do elastic capacity management and just-in-time provisioning.
· You need to charge them like a vendor would. (Or at least show them what it costs and make them accountable)
For the most part, I wasn’t wrong in my initial judgement of what it takes to run something “as a Service”, but my definition and perspective was limited. There’s substantially more to the story. There is the user experience, for example. There is a continual improvement cycle. There is a real-time feedback loop that should be established. And, fundamentally, you should view the entire system as a workflow with a Requestor and a Provider and a process that takes place between them.
When I got to NOW, the first slide that I saw that resonated with me was a slide that Frank Slootman was using to describe the world of “work” that exists in most companies today. I remember his story was awesome and it resonated with me deeply. He told the story of how inter-office communications used to take place before e-mail. How the manila envelopes would pile up in his inbox in the morning and by night, he would have moved them all to his outbox. He then opened my eyes to the fact that all we really did with e-mail was provide an electronic way of blasting out unstructured work all over the company. However, the communications platforms we used to manage work were still entirely unstructured and the path from requestor to provider was 50% hopes and dreams.
That first slide lifted the veil of how I previously viewed the world and opened my eyes to a whole new way of thinking about day-to-day interactions in the workplace. To see the entire world through the lens of Service Management.
Figure 1- The Traditional Work Model - Unstructured Work
The following slide was also revelatory. How we look at the future of work and how we solve the challenges of unstructured work. The idea is to look at the end-to-end delivery of a service and map the entire workflow between requestor and provider. This end-to-end lifecycle and structure was what was entirely new to me as an Infrastructure practitioner. Suddenly, everything I looked at was different. (Once you take the red pill – your world will never be the same again.) The Service Management lens can be applied to everything in the enterprise. It’s all just… work. Work that needs to be managed and routed efficiently through the organization. Work we can provide workflow and automation around.
Figure 2 - A new model for work. Workflow and Automation.
To provide this end-to-end workflow and structure around work, NOW had an Enterprise Service Delivery framework that I learned. It provided a structure that you could apply to any work in the organization. It was brilliant! For the first time, I saw a system for defining all the things that we had danced around but never quite gotten right. Now, I am sure a lot of folks that grew up in ITSM or ITIL might be either A) Laughing at me for finally “getting it” or B) Scoffing at me for getting it wrong for so long. Trust me, I was just as embarrassed and shocked at how I had missed this entire service management discipline in my career pathing, only to find it 20 years in. But the important thing for me is – I found it. And now, there’s no looking back.
The reason I wanted to write this blog was to explain to everyone that another epiphany I had is that DevOps, Lean, Agile – all of them were born to do one thing: Increase FLOW through a system. (This is a topic that I will preach on continually. It’s the point of the whole thing…) Interestingly, however, I believe that initially most of the folks working on DevOps and Agile were also coming at it from a perspective that did not include the structure of a Service Management discipline behind it. Hence, a lot of developers and DevOps teams hate the words: ITSM, ESM, IT4IT, CMDB, or anything else that sounds like a CAB meeting is involved. And the piece that I believe is missing is: DevOps is just another form of work. Work that can be managed and routed more effectively. This is what I was talking about when I said: “DevOps+ an Enterprise Service Management approach” is the answer. We should be taking a similar approach to DevOps as NOW did to other areas of Service Management in the Enterprise. (see Below).
Figure 3 - A great framework for managing work
Now, these slides are a bit dated, and our storyline has evolved. It’s all about “Digital Transformation” now. (another blog coming on that) But the concepts that opened my eyes remain the same. How do you provide Digital Innovation to your customers as quickly and effectively as possible? You need to approach it through the lens of Digital Service/Digital Product Management. If you don’t, you will never achieve your goals of increased flow throughout the system.
I met with an analyst recently (Charles Betz) and he shared some research with us that showed that 80% of companies that have tried to adopt DevOps transformations have shown no increase in release frequency in their environment. 80%! When asked what the root cause is – it’s always the same: “They can’t get past their Security, Risk, Compliance – Governance bodies.” I fell victim to this myself at the Bank. We built a system that could do nightly builds into production, but the change management team said: “You cannot release nightly, we have a scheduled and accepted change window every 6 months. Your changes must adhere to that policy.”
Another bit of information that just got sent to me illustrates this as well. It’s about 6 months old, but Klaus Leopold has a webinar (click here to watch) that’s going around our company and in it, he talks about some of the biggest mistakes that he sees companies make when trying to “be Agile”. I found his discussion very entertaining and very accurate. He quantifies the challenge as: “While companies claim to be Agile, many of them fail to address the entire end-to-end value chain of DevOps.”. Without addressing those challenges, they are never successful and never achieve the goal of increased flow. I combined a couple of his slides, but he does a great job of illustrating the fact that most companies only focus on the development portion of DevOps. A fact that I see often. (The second you bring up DevOps – the company starts talking about its CI/CD tools.) Anyway, in his webinar he talks about the fact that the Development teams are Agile, but that does nothing to drive business agility. All the wait time and manual steps that exist completely kill flow and the company is “as lame on the market as before”.
My belief is that you must address end-to-end workflow through the lens of Service Management. From Ideation and Demand all the way through to Production with continual feedback built into every process along the way. And automated ITIL throughout the process. Automated Change Management, Release Management, etc. (much more to come on these areas)
Figure 4 - Klaus Leopold discussing how the end-to-end value chain is still not fixed just because the dev teams are Agile.
To wrap this post up, I wanted to lay the groundwork of why I believe DevOps in many organizations is incomplete, due to a lack of service management or “end-to-end management of the value creation chain” as Klaus calls it. Whenever I get all preachy about adding a service management discipline to your DevOps planning, this is the reason for it. I have watched many organizations fail due to their lack of systems thinking when they approach their Digital Transformation or DevOps transformations.
As always, thanks for stopping by. Feel free to reach out if you have comments or questions.