One thing I’ve noticed, over the years, is the habit of people blaming technology for the problems rather than taking a look at the processes behind the problem.
A personal example
A big example, for me, was when I was part of the Unix enterprise authentication team. The technology worked, and it worked well. It was resilient, reliable, fast. We literally turned off the infrastructure in one datacenter and all the clients correctly failed over to the next nearest one.
But it had a bad reputation. If you so much mentioned the word “Keon” to some people then their eyes will start to twitch and they get a haunted look.
Because the processes around configuring the environment were bad. To build a new application you needed to think ahead and plan your requirements; “these are my servers”, “these are my app team members” and “they need these Unix permissions” (I know a lot of people don’t like this, but I thought it reasonable; we can’t put servers on the network without access controls).
But it got worse. You had to fill out a spreadsheet using complicated jargon and half a dozen tabs, just to say this. Then you had to attach this to a “consulting request” in the corporate request system. With a 5 day SLA and a high likelihood of the request being rejected.
How do I know the process was bad? Because my request was rejected; not because it was wrong but because the implementer missed the attachment!
So when a new head of technology joined the company they heard all these complaints about Keon and how it was so bad, and he planned to replace it.
I just couldn’t convince him that replacing the technology stack would not fix the processes; it was the process that people hated. Focus on that.
Unfortunately the process side of the house wasn’t in his remit (that was run by a different technology tower) so instead of working with that tower (we could have created better tooling for the request system that would have made both the requester’s life and the implementer’s life better) he treated it like a technology problem and tasked me with evaluating replacement tools.
(I soon moved out of that team and into the new cloud team)
Iterated madness
“The definition of insanity is doing the same thing over and over and expecting different results” – Albert Einstein
Elsewhere I’ve seen teams get stuck in a loop; they would buy the best in breed technology for a solution and deploy it. It would fail to meet the requirements, so they would go back to the drawing board and get replacement technology. Rinse repeat.
The underlying cause is that they were looking at this as a technology delivery problem, and not as a service delivery problem. The team were technologists, so this kinda made sense; they were told “deploy X” and they did.
So the blame lies higher up the management tree; the VPs and SVPs who didn’t see the bigger picture, who didn’t understand the problem they were told to solve, and who believed the vendors.
The role that was missing was one of “service owner”. What do we need to do to make this a consumable service? They could have saved millions of dollars and reduced technology disruption just by having this bigger picture.
Service and Product owners
There are multiple ways this can be defined, but I look at it this way.
The Product Owner is the one that owns the technology stack. They’re the one who is responsible for keeping it running, for ensuring it’s patched and updated, for understanding the vendor technology road map for the product, and for handling any integrations with other systems (request system, change management, HR, etc).
The Service Owner is the one that is responsible to the users of the product to ensure the business needs are met. They create the overall service road map that is informed by the vendor road maps, but may also takes into account customer complaints, service issues, etc. It may be the vendor product road map includes sprouting wings and flying, but if you want to dig tunnels we may not implement that function… unless your service needs include rapid deployment to remote locations :-)
These two owners should work tightly with each other; they may even be the same person, but need not be.
Each role is critical to the success of the service.
Summary
“Technology is easy; process is hard” – me
We deploy tools to meet a business need, not for the sake of deploying them. These tools are not standalone; they have inputs and outputs, even if it’s just reporting to the CISO about what they’re doing, how they’re reducing our risk, and how well they’re achieving those goals!
So we need to look at this as a service and not a technology. And when the service fails we need to look at it from a service perspective. Is the technology to blame (it could be!), or are we using it wrong? Even if the technology is wrong, is it because we didn’t deploy it correctly and it can be fixed?
Don’t just change the technology because it’s easy (for some values of “easy”); look wider. Find where the problem really is.
The problem may be that you have the wrong people; it may be that you have the wrong processes; it may be that you don’t actually understand the problem!
Replacing a technology stack will only fix the problem if the underlying technology is wrong for this problem space, and if you’ve bought the best of breed then it’s not likely. You may have deployed it wrong (fix that) or aren’t using it properly (ditto) but if you just replace it and hope this time things will work out better… well, that’s Einstein’s definition of insanity.