Blog: IT's Not Supposed to be a Dirty Job

IT World has put out a list of the "seven dirtiest jobs in IT": it's dated in March, but just surfaced this week on my Google News radar. The good news, they hasten to say, is that mastering the associated skill sets for any of these tasks will pretty much assure you of employment; the bad news is that you can't expect to enjoy it.

Pardon my jumping out of the box, but my question is -- why should anyone have to do them at all? I'm not saying that any of these roles could be completely killed off, but I am suggesting that the need for them should be absolutely minimized.

For example: Dirty Job No.7 is "Legacy Systems Archaeologist." I totally agree that COBOL skills are more valuable than almost anyone realizes -- after all, I'm the guy whose quotation once appeared on an IBM COBOL T-shirt, saying that "Sharks Just Keep on Swimming." I had published a comment that COBOL is like the shark, which has been at the top of its food chain since the day of the dinosaurs.

On the other hand, there's a right way and a wrong way to get continued leverage from your COBOL assets. Wrong way: find or train people to write new COBOL that revises and extends the functions of old COBOL. Right way: use any of several technologies that wrap COBOL in a Web services interface, minimizing the need for future touching of actual COBOL source code.

Dirty Job No. 6 is "Help Desk Zombie": most organizations are staffing too many help-desk slots because they're using too much on-premise technology. Andy Steggles, CIO of the Risk and Insurance Management Society, told Baseline magazine last month that using software-as-a-service has allowed him to shift his limited IT headcount away from management and support toward addressing project backlogs.

Dirty Job No. 5 is "On-Site Reboot Specialist." The less fat-client code you run, the fewer times you'll have to help a system to its feet after it collapses beneath the weight.

Dirty Job No. 4 is "Interdepartmental Peace Negotiator." The conflict between control-oriented IT departments and innovation-hungry business units is substantially defused by a multi-tenant SaaS architecture, with its combination of disciplined governance and metadata-based flexible customization.

Dirty Job No. 3 is "Enterprise Espionage Engineer" -- and I have to admit, I believe I'd actually enjoy doing white-hat social-engineering and penetration tests for clients checking out the state of their systems. What SaaS can do, though, is minimize the value of stolen user credentials and reduce the amount of data that's readily stolen from the network's edge.

Dirty Job No. 2 is "Datacenter Migration Specialist." I can understand why that would be an ever more valuable skill -- but I hardly need point out that SaaS adoption can largely void the question, "where do we build the new data center?" (and how do you find the person to do it?)

Finally, Dirty Job No. 1 is "Sludge Systems Architect" -- and there, they have me. As ever more sophisticated IT goes into the bowels of the factory and the process plant, the digital roughneck who can interface bits with atoms is going to be an in-demand synthesist. If you're looking for a job that you can do today, or do next decade on Mars or next century on a starship, this is one of your options.

But if you want to stay out of the sludge, SaaS can help you stay away from the other six slots on this list.