The genesis of this article was a conversation had between about six IT engineers and myself at a conference a few years ago. Since then, it has come up in various angles in separate discussions. Essentially it revolves around crystal ball gazing, about the converging (or divergent) paths of technology, business and employment scenarios, which involves nearly as many shifting dynamics as does meteorology.
2025. It sounds like a long way off, but it’s only ten years away. You’ll wish it was tomorrow after reading this. Not because I’ll paint a rosy picture, but because I’m going to gang rape your mind with so much idiotic techno-minutia babble, and dry, stupid jokes, to the point where 2025 can’t save you soon enough. So, sit back and enjoy (if you can).
Up Til Now
Looking back at 2010 in the IT world isn’t much effort really. In human terms it’s a decade, but in technological market terms it translates into a century. And working forward to 2015, a lot has changed but most of it unnoticed even by seasoned professionals who live and breathe it every day. It’s the old “boiling frog” syndrome at work again. Most of the remainder of this article could be metaphorically related to the changes in grocery store products and prices over the past decade, but that would be way too easy.
Aside from the usual name-dropping of which products were “cutting edge” in 2010, I find it way more interesting (and telling) how IT jobs were situated in 2010, and how their roles have changed in 2015. I won’t try to bore anyone with mundane talk of which version of what smartphone was “king” of the market then. What really matters are what IT jobs were like, and what trends they’ve endured.
I break this into three distinct groups. Actually 2-1/2 but who’s counting? The first is what’s drying up, the second is about what’s blossoming, and the third is crystal ball stuff.
[A] 2010 roles which are dead or dying in 2015:
- Microsoft Exchange Admins
- Intranet Portal Developers
- Dedicated IT staffing roles
[B] Roles which have increased towards 2015:
- IT project managers
- IT business analysts
- Application Developers
- Cloud engineers / architects
[C] Which roles will be dead or dying in 2025?
- Server hardware engineers
- Exchange admins
- Server Admins
- Device-Provisioning Technicians
(play sound effect of car hitting brakes and skidding here)
Dead or Dying – The “A” List
Let’s back up to the [A] list first. I’m sure some of you are looking at that list in disbelief. As if watching a snake swallowing this guy in front of you.
- I have yet to meet or chat with an Exchange engineer who doesn’t agree that their role is evaporating at an equal rate to customers moving to Office 365. Whether you feel this is “good” or “bad” depends on your (job) position I suppose, but it’s happening.
- Internet portals were the bomb in 2006-2010. Then came Domino, WebSphere, Plone, WordPress, Drupal, Joomla, and SharePoint. What was once a big room filled with PHP and ASP developers, is now mostly module and “web part” developers for retail platforms.
- Dedicated IT staffing roles – my favorite subject. Allow me to digress…
In the old days (of IT), there were relatively distinct job roles defined. Text books from back then used terms like “technician”, “engineer”, “administrator”, “analyst” and “architect”. That was before America shifted from innovation to cost-efficiency as a primary profit driver. Thinking about new ideas is too hard and too risky. Much safer, and more reliable to turn that flashlight inward and find ways to eliminate what you already know. Trim the fat.
“Fat”, in this context, refers to redundancy. The evil word of business process optimization. BPO goes with Business Process Automation (BPA) like a lobbyist’s hand goes with a politician’s prostate exam. But I digress.
The term “redundancy” has subtle variances in both definition and application, particularly in the IT field. On paper, some terms don’t qualify. But after a few martini’s, well…. Why have an “engineer” AND and “architect”? Can’t the same person design AND build it? Why this “technician” AND and “administrator” person? Really. So much waste on too many humans.
(tip: If you read the previous paragraph using your flat-out best British aristocratic accent, it adds way more weight)
It started in the mid 1990’s actually, with merged role titles like “programmer-analyst” and “engineering-admin”.
The question began as: Why pay two people when you can combine their roles? Why deal with two sets of burden (benefits, tax withholdings, records-keeping, regulatory compliance overhead, etc.)? Eh? EH?! Come on – are you with me now!?! (says the VP at the board meeting). The managerial view overall has typically been that the employee is on the lower-value end of the bargaining scale, and will therefor accept anything of benefit to the organization, as long as it’s presented in a palatable manner.
So, call in Junior Engineer, Duey Spreadham
“Hey, Duey. Good to see you. How’s the family? Good… good.” (replies rhetorically, before Duey even opens his mouth)
“Say, John, …”
“Sorry. Duey, we’d like offer you a promotion. How would you like that?” (grins, folds hands and nods)
“A promotion!? That’s awesome! What’s my new title?”
“You’re going to be a Engineer Architect! Aren’t you excited?” (carefully slides letterhead printed sheet across table to smiling Duey, while grinning wide)
Duey screams like a sports fan who’s team just won the game, “Hey everybody! I’m a Engineer Architect!!“.
Mr. Manager explains the $5k raise and new “responsibilities”, while Duey stares into the letter with “Engineer Architect” in bold, oblivious to most of what Mr. Manager says afterwards.
Duey leaves the room, pumped and excited. Mr. Manager just “promoted” him from his $40k role as an “engineer” to a $45k role as “engineer-architect”, while simply compressing two job descriptions into one. Now, they achieved-cost cutting nirvana, which he can brag about to the CFO he’s brown-nosing during the next fishing trip.
Meanwhile, Duey slowly but surely realizes that he now handles two jobs, but being salaried, it just means more hours for a minor raise, and he’s not going to get any additional help. Realizing just how big his rectal orifice was just enlarged, he quits. Mr. Manager posts the same combined position on Monster and hires a younger, over-eager kid to fill the role and assume the position.
Savings: Eliminated a potential $60-95k position, for only $5k.
Laugh and scoff if you want. I’ve seen this (or evidence thereof) again and again, all around this wet and sticky ball of dirt we call Earth.
Make no mistake: In many cases this is a good thing. There are (or were) a number of organizations with too much division in roles, and collapsing them does (or did) provide measurable improvements in a variety of areas. Good for them. However, the trend evolved far beyond those that needed rank-collapsing, and now we’re seeing over-collapsed ranks. Technicians doing Admin and even Engineering work. Admins doing Engineer and Architect work. Engineers doing PM work too.
The symptoms are familiar enough for most IT folks: complaints of too many duties piled onto one person. Lack of acceptance or approval for requests to hire additional staff. Rejected training requests. Longer ticket resolution queues. Increasing turnover rates. And so on…
The “B” List
Cloud Engineers and Architects are a no-brainer, so I’m not going to bother justifying or explaining that bullet item. But aside from some technical-based roles, such as software development, information security and asset management (semi/quasi technical, actually), the biggest role increases in IT these days seem to be in the business-oriented areas. Things like project managers, business and technical analysts and so on.
The reasons vary, but by and large, it seems to indicate a desire on the part of executive management to create a translation buffer between them and the tech-nerds beneath them. They hate trying to understand the Red Bull swilling Skittle’s munchers as they explain what their new app is doing and where they are in the dev-test cycle. Their eyes roll back in their head, thinking “why?! why can’t this kid just tell me how much profit I can count on?!?! God almighty!”
So, create a layer of translators who can sort of speak nerd-ese and biz-ese and everyone is happy. Until they realize it doesn’t really add any value for the cost incurred.
The “C” List
- Server hardware engineers
- Server Admins
- Device-Provisioning Technicians
Hardware is already drying up in many private data centers. In fact, many of those data centers are in the process of drying up right now. “Servers” as we’ve known them are gradually moving to cloud services. Some customers have already moved. Some are moving aggressively, and some taking their time. But almost every customer (and I know of about 500 or so) is moving at least some of their data center operations into a cloud service configuration.
This migration doesn’t necessarily mean bad news for vendors, since the hardware that evaporates from private data centers is simply built-up in the cloud data centers.
Server Admins, including Windows, SharePoint, SQL Server, Oracle, MySQL, Exchange, and so on, are seeing significant changes in what and how they manage systems. Rather than breaking open a toolbox to assemble a server rack, cable racks, and installing hardware, they’re running P2V or deploying templated VM guests or guest profiles via DevOps automation.
Rather than spending hours on performance tuning, backups, patching, and monitoring, they’re accessing a web dashboard to see what the cloud services are reporting. Many of the traditional hardware-related tasks have been, or are being, moved into the hands of Amazon, Microsoft, Google, RackSpace, Equinix, and so on.
Technical staff may refuse to accept this as a potential reality. But don’t assume the employer hasn’t been reading up on this. At the very least, they’re having conversations with their peers at conferences, golf outings, and social parties. Once one of them starts sloshing his whisky sour on the floor while getting giddy about how much savings he/she gained from moving boxes to the cloud and jobs to the parking lot, the others gather around quickly.
It’s the new “off-shoring” approach, but this time, it’s to a friendly face (Microsoft, Google, Amazon, etc.). The trust/comfort barrier is knocked over by the fact that your CIO/CTO looks at the pains of off-shore outsourcing and then compares that with the over-eager, smiling face and friendly voice of the big-name IT vendor rep, handing them a swag bag, while shaking hands after talking them through the foreplay of data center “optimization and cost efficiency” 101.
They finish off their drink, go back to the hotel room, toss the swag bag on the floor, type some emails to the CFO and CEO, similar to, “I have a fantastic idea for profit improvement I want to share with you…” and then passes out on the bed with his/her clothes still on. And in a few weeks, you hear about it in a surprise all-hands meeting.
In every case, the results I’ve seen or heard have been:
- Fewer servers and server racks
- More open-floor space in their data centers
- Fewer lights turned on in the data center
- Reduced IT staff
That last one is the kicker.
As for end-user device provisioning, that too will change. As products become more commoditized and deployment tools become more streamlined and automated (and cloud oriented), the need for elaborate imaging stations, workbenches and dedicated staff often diminishes. Today it’s MDT and SCCM, but tomorrow we’ll see the next generations of these and even newer products.
On the data center devops side: Nagios, Chef, Puppet, SCOM/SCORCH, and things like containers. Expect future products and future processes to evolve towards being more “off the shelf”.
If this hasn’t convinced you yet, try this on: Ask any storage engineer what it was like provisioning storage ten years ago. Then ask them what it’s like using current tools and methods. Then fast-forward that another ten years. Get it now?
Let’s also not forget to mention Software-Defined Networking, or SDN. To summarize this newer trend, it moves a lot of the traditional router/switch customization activities to a software console. As one Cisco CCIE said to me recently, “shit, this could mean the end of a lot of network engineering jobs”.
Will this all happen tomorrow? I doubt it. Most of IT changes occur gradually. The problem is that we often ignore the writing on the wall, assuming we know better and things will remain within historically-predictable paradigms.
The Shape of Things
So, as promised, let’s point the Technogasmatron towards 2025 and see what it looks like:
- Data Centers return to the small server rooms (or closets) they began as
- Many companies will have no dedicated “data center”
- Most shared services are in the cloud (spread across multiple cloud host services)
- Dedicated work devices are replaced by personal BYOD devices
- Rather than paying to procure, deploy and support company devices, employees will be expected to provide their own (within constraints)
- Federated/SSO authentication is the norm
- Most end-user work is stored in the cloud, not on a device
- Networking devices become more homogeneous and SDN-based.
- Infrastructure management is cloud hosted (System Center, Altiris, etc.) with or without new product names
- IT infrastructure support staff is smaller than it was in 2015
- IT app-dev staff increases in size, but marginally
- IT security roles will continue to expand
- More telecommute work force policies
- Smaller physical facility presence (fewer square feet/meters for compute services)
Another area which will likely impact the shape of IT workforces in the future isn’t even technological in nature. It’s about “legal jurisdiction”. If you read the Trans-Pacific Partnership, or TPP agreement (it’s around 5,000+ pages right now, phew!), there are terms included which appear to lay the foundation for ironing out some of the pain points being exposed by international law and information management. One example of these pain points is the Microsoft/Ireland vs. US/DOJ court case. The TPP and TISA (component of TPP) may impact the nature by which cloud services are structured, managed and exposed to clients. More on this later.
What Could Change This?
Ah! This is the $64 dollar question. There are two general things/events that could change the future course of cloud services adoption at this point:
- Shaken Customer Confidence
- Shaken Vendor Backing
Allow me to explain.
Shaken customer confidence would be any situation, trend or event which causes a general rise in fear or concern on the part of current/potential cloud services customers, to elicit an aggregate consideration of returning to the on-premises data center model. Anything from a wide-scale systemic failure, to a wide-scale security breach, could cause this. And if it only occurred once, vendor marketing could possibly overcome it with enough kool aid pouring. But if it happens repeatedly, it could spell death for the entire market.
Shaken vendor backing refers to anything that would undermine the perceived value placed on the entire market by the vendors seeking to gain revenue from it. This could be the result of increased regulatory compliance costs, legal defense costs, and privacy-vs-transparency delineation complexity. All of these, or combinations of some, could have an enormous impact on the market’s viability and profitability. After all, even the best ideas can die off, if they’re aren’t profitable enough.
- Regionalized data center grids.
- Shell companies / subsidiaries
- Limits on types of data replicated across jurisdictional boundaries
- Market shift back towards hybrid data centers (on-prem/off-prem)
So. Have you started drinking yet? What do you think?