Stevie Chambers wrote something in a tweet last night. He stated the following:
The problem with an IT specialist is that he only gets to do the things he’s already good at, like building a coffin from the inside.
And my first thought was that he’s absolutely right. A lot of the people I know are absolute cracks or specialists in their own area. I’ll talk to the colleagues over in the Windows team, and they can tell you everything about the latest version of Windows and know each nook and cranny of their system. I’ll talk to the developers and they can write impossible stuff for their ABAP Web Dynpro installations.
But then I ask my developers what effect a certain OS parameter will have on their installation. Or perhaps how the read and write response times from the storage array in the back-end might influence the overall time an end user spends while he’s waiting for his batch job to complete. And you know what answer you get a lot of times? Just a blank stare, or if you are lucky some shoulders being shrugged. They’ll tell you that you need to talk to the experts in that area. It’s not their thing, and they don’t have the time, knowledge, interest or just simply aren’t allowed to help you in other areas.
So what about our changing environment? In environments where multiple tenants are common? Where we virtualize, thin provision and dedupe our installations and create pointer based copies of our systems? Where oversubscription might affect performance levels? Fact is that we are moving away from isolated solutions and moving toward a solution stack. We no longer care about the single installation of Linux on a piece of hardware, but need to troubleshoot how the database in our Linux VM interacts with our ESX installation and the connected thin provisioned disks.
In order to be an effective administrator I will need to change. I can’t be the absolute expert in all areas. The amount of information would just be overwhelming, and I wouldn’t have the time to master all of this. But being an expert in only one area will definitely not make my job easier in the future. We will see great value in generalists that have the ability to comprehend the interactions of the various components that make up a stack, and are able to do a deep dive when needed or can gather expertise for specific problems or scenarios when they need to.
Virtualization and the whole “* as a Service” model isn’t changing the way any of the individual components work, but they change the interconnect behavior. Since we are delivering new solutions as a stack, we also need to focus on troubleshooting the stack, and this can’t always be done in the classical approach. In a way this is a bigger change for the people supporting the systems than it is for the people actually using those systems.
