Many IT organizations think they have meaningful IT automation services in place. The truth, however, is an illusion. The more I work with IT automation tools the more I realize that very few organizations actually do meaningful automation. Sometimes there's an expectation of automation, such as when folks use a front-end system like VMware vRealize Automation. A tool like that has extensive automation capabilities. Look closely, though, and you'll see the automation used for tasks like approval workflows and sending e-mail messages to humans to get them to do work, like entering items in a configuration management database or setting up replication. I thought automation was supposed to reduce the work humans do.
I've been thinking about this quite a bit, and I think it's due to one big problem: IT people don't know about system programming for the computers they work with.
There was a time when you needed to understand the computers you used at a very deep level. Actually, it wasn't all that deep -- machines had many fewer layers of abstraction, much thinner operating systems, and applications were much closer to the hardware. Commercial software was scarce, and businesses tended to write their own applications. Sure, there were non-programmers in IT back then, too, but the ratio of system programmers to other roles was much higher, mostly out of necessity.
Then personal computers and commercial software booted programmers out. IT staff stopped learning to code and focused on vendor certifications. It was enough to know how something worked, and much less important to know why it worked. The computer science types were replaced by business school graduates. The MBAs serve a valuable purpose in IT, but very few of them know how to program. And now, as we announce our desires to build a cloud and rely on automation services, we look around and see that there's nobody left in our own organization to do this kind of work, even at the most basic level.
Resurrecting the system programmer
We could let professional services do all this integration and automation for us. I'm skeptical, though. Consultants don't have our organization's evolving long-term best interests in mind. They want to do a job, call it done and move on. They're not going to be there when something breaks. They're not going to be there when it needs a security patch. And they don't improve our organization's understanding of the technology we rely on.
We could resurrect the idea of system programmers, and hire some of our own. Should they have everything we usually look for in an IT staff hire? Yes. But instead of the business degree, perhaps we look to the computer sciences and software development fields. We need people who understand why computers do what they do, and can make them do things for us on our own terms, not a vendor's.
We need to support system programmers well. We need to hire more than one programmer, to provide collaboration, backup, and internal support. We also need a promotion track for technical folks that doesn't have to lead into management: Programmers should be able to gain seniority, earn promotions, and work as team leaders without being forced into a traditional management role.
I believe that IT will only realize its IT automation services and data center cloud dreams if we re-embrace our system programming roots, especially by making organizations more technical again.
Bob Plankers is a virtualization and cloud architect at a major Midwestern university.
Sizing up hardware resources to allocate to IT automation tools
Automating IT offers cost savings and efficiency. But beware.