In the past few months, Microsoft has made a number of sweeping changes that will have long-term consequences for the company, the businesses that depend on Microsoft, and the IT professionals that support Microsoft's products. How will these changes affect identity professionals in the Windows world?

Shifting Tides

Microsoft has made it quite clear that it is evolving from an "on-premises software company" to a "devices and services company." The company has been beefing up its hardware product line from keyboard/mouse to tablet/PC devices; my colleague Rod Trent believes that Microsoft will begin to build servers as well. It has acquired Nokia's devices and service business, putting Microsoft squarely in the smartphone market as number three after Google and Apple. And it has eliminated a couple of important programs for IT pros: TechNet software subscriptions and the Microsoft Certified Master program. I'm sure these aren't the last of the strategic changes we'll see coming out of Redmond this year.

To gauge how these changes and the overall impact of services versus traditional on-premises systems will affect the identity professional, let's compare identity to another infrastructure system: messaging. Running a robust and reliable email infrastructure isn't a trivial or inexpensive task, and letting someone else handle the complications is very appealing. In addition, messaging has the Achilles heel of spam filtering, spear phishing, and Denial of Service (DoS) attacks to deal with; protection against these vectors is ever-changing and can get very expensive to manage yourself. As a result, hosted email has become one of the most popular cloud service migration targets.

As with email, the future of the corporate identity professional's job role depends on the on-premises/cloud equation. The difference between email and identity however, is that—unlike email—identity is a critical part of the entire IT infrastructure, not just one aspect of it. Because Active Directory (AD) is a major part of on-premises identity, let's focus on how on-premises/cloud impacts it.

Active Directory Impact

With an on-premises capability, you must handle it all. You must deploy, support, and upgrade the service infrastructure (which means capital hardware and software costs), then pay for sustaining software maintenance and human resource costs. You must also manage the service's data—archiving, recovery, and governance. For AD, this means maintaining both the service (the network of domain controllers—DCs) and the logical administrative structure of AD (the identity and network data it contains). In the largest enterprises, the management of the AD service itself and the data within it are delegated to two or more groups (e.g., AD infrastructure support and account management). How do cloud identity services affect these jobs?

In the simplest terms, as long as you've established on-premises applications, you'll want to have an on-premises identity infrastructure. (It's possible to have on-premises applications with completely outsourced identity, but I see that as an edge case.) The size of your identity infrastructure might decrease as you move your computing to an external provider, but it won't go away; there are too many perfectly functional production applications that show little to no return on investment (ROI) for moving off-premises, and they'll need identity to work. Even if you could easily move production virtual machines (VMs) from your data center to the cloud (and it will become much easier as Windows Server 2012 plus Windows Azure IaaS gains traction in the enterprise), why would you want to start paying for Windows Azure when you've already invested in your own data center and have depreciated hardware? Over time, this scenario might become more inviting as your data center hardware approaches obsolescence—but not immediately.

Hybrid Cloud

An equally important factor is security. Do you want to store the keys to the kingdom (your company's identities and passwords) in the public cloud? What is far more likely is that your cloud computing will be of the "private cloud" type for the near future. And the identity infrastructure required for an on-premises private cloud is every bit as complicated, if not more complicated, than what you have today.

If you build a hybrid cloud strategy, you might well have an identity presence in the cloud (e.g., Windows Azure AD or another IDaaS provider), and therefore some identity data management responsibilities without the corresponding service management. But with that scenario will come identity-bridge (the connection between local AD and cloud identity services) management responsibilities.

The AD data-management aspect is a little less exciting, which in this context about career security is probably a relief. Whether you're on premises or in the cloud (or both), you still have the account management lifecycle—also known as "create, read, update, delete" (CRUD)—to deal with. It's simply the mechanisms to handle this lifecycle that will change.

SSO to Cloud

Finally, the recent revelations about NSA surveillance have only underscored the importance of using federation to provide single sign-on (SSO) to cloud service providers. A federated trust between identity provider and relying party does not provide passwords to the relying party (aka a service provider such as Tripit.com). This is why I don't recommend the password synchronization option of Microsoft's Dirsync account synchronization utility for Office 365 or other Windows Azure-based services; you should instead use Dirsync in combination with Active Directory Federation Services (AD FS) or another federation service to create a federated trust between you and Windows Azure AD.

I'm not worried about the future of the identity professional. In fact, the role of identity and the need to comprehend it well has only grown in the past few years. The installed base of AD might shrink somewhat over the coming years, but it'll be a long time before we talk about AD as one of those "used to have" technologies.

Follow Sean on Twitter @shorinsean.