This is part two of a three part series. Read part one, What does it take to succeed in IT in the era of Cloud?, and come back next week for part three.
In the late 2000s, a new trend started to become clear. As Microsoft and Amazon (and, to a lesser extent, Google) started building large networks just to provide software-as-a-service (SaaS) offerings, they realized that they could use these networks for two things: to drive SaaS adoption and to sell capacity on these networks to their customers. (For a fascinating inside look at some aspects of this transition at both Google and Amazon, see Steve Yegge’s article at https://plus.google.com/+RipRowan/posts/eVeouesvaVX). Microsoft in particular saw that, as their Global Foundation Services group built infrastructure to host services such as Xbox Live and Hotmail, and as their customers complained about the increasing complexity and cost of managing on-premises Exchange, that they could re-engineer Exchange as a cloud service (not incidentally, taking SharePoint and Lync/Skype along for the ride). Their first offering, Business Productivity Online Services (BPOS), was largely on-premises code that had been forced into unnatural service as a multi-tenant cloud platform, but after years of Herculean effort, Office 365 made its debut and has grown steadily into the powerful, rich service platform of today.
In parallel, Microsoft and Amazon invested enormous effort into providing infrastructure-as-a-service (IaaS) offerings: Microsoft Azure and Amazon Web Services. These services allow you to consume computing capacity on a pay-as-you-go, buy-what-you-need basis, whether that simply involves moving work from on-premises physical servers to cloud-based VMs or using cloud services such as Azure DocumentDB, Azure Media Streaming, or Azure Active Directory.
The emergence of capable cloud services was greeted with two overlapping choruses: a joyous one from IT decision makers who were elated at the potential cost savings and functionality increases, and a loud lament from IT pros who worried that their jobs would evaporate as their employers’ services moved into the cloud. Both sides were right.
What the cloud means to IT pros
There has always been a skill ladder in the IT world: a helpdesk tech, for example, could learn the skills necessary to become a Skype administrator, then an architect, and then perhaps move into a supervisory or management role. The cloud doesn’t change that. What it does change is what the rungs on the ladder look like, and perhaps how far apart they are.
Consider Alice, an Exchange administrator at Contoso, a 5,000-seat company. Alice knows how to deploy, manage, and monitor Exchange and keep it running smoothly. She knows how to create and operate database availability groups (DAGs), manage mailflow, and all the other big and small tasks necessary to run on-premises Exchange. Other people on her team are responsible for Active Directory, storage and SAN management, and security. If her employer moves to Office 365, the likely effect on her position is not that it will go away—it’s that Alice will have to shift to other tasks. Ideally these tasks would be ones that are higher on the value chain. For example, because Microsoft manages high availability, Alice’s skills in configuring and managing DAGs may no longer be needed, but Microsoft doesn’t do anything to help Contoso maintain business continuity for services such as Active Directory, Active Directory Federation Services, or Internet connectivity.
The diagram below illustrates one way to frame the discussion around skills; as you move higher on the pyramid, there are fewer people who can fill the role, and they are correspondingly better-paid and harder to replace:
-At the commodity level, labor is cheap and plentiful: outsourced call centers, offshore technical support, and no-experience-required entry-level positions fall into this category. People working at this level tend to be very early in their IT careers and often have no formal training or certification, just what they’ve picked up on the job.
-A specialist is just what the name implies: someone with particular skills for a given product. Alice might be a good example; as a skilled, experienced Exchange administrator she’d be considered a specialist, but she doesn’t have the necessary cross-product or soft skills to move up. Specialists usually have some formal training and certifications, but this isn’t mandatory, as much of their skill comes from long hands-on experience.
-A synthesist has deep product knowledge in multiple products. An example might be someone who administers both Exchange and Skype for Business, or a SharePoint administrator who’s also a Microsoft Certified Solutions Developer (MCSD). People who operate at this level are normally able to display strong soft skills in addition to their technical knowledge: strong project management, conflict resolution, and oral and written presentation skills are all typical at this level.
-A master can operate at every level in every technology within a particular enterprise. She can move seamlessly from troubleshooting a bad network port in a cubicle to presenting a strategic technology plan to an executive team. Someone at this level is expected to have impeccable technical credentials (likely including formal experience teaching or mentoring), plus an extremely strong background of experience, plus superb people and communication skills.
Next week, in the final installment in this series, we'll look at what you need to know to climb the ladder.
