This is the third blog in a series on Cloud Adoption and Cloud Migration. Previously I wrote “The GAP between Cloud Migration and Cloud Adoption” and “Office 365 and Bandwidth – Adoption to Cloud Computing“. This one is on Ownership of Cloud Adoption and Ownership of Cloud Migration. As explained in previous mentioned posts Adoption and Migration are two totally different things.

IT Departments are responsible for Cloud Migration(s). It’s about the technical challenges of moving workloads to the Cloud. Ownership of Migration lies with the IT Department, somewhat automatically delegated by the Organization. Not much to discuss here.

Now Cloud Adoption, who has Ownership of that? I have seen a lot of Migrations not yielding the expected results, not because it was a bad Migration but because the Organization did not benefit from it, or even worse, continued “business as usual”. Didn’t even have to do with Cloud Migrations; could be Onprem Exchange, SharePoint, Desktop OS or Office migrations as well. A lot of Organizations run the latest versions of those but still live in the dark ages when it comes to using them. Because nobody in the Organization took Ownership of the Adoption. Mostly that was left to IT Managers. But who listens to IT Managers, not the Sales and Marketing Managers for sure. They are busy. And so any free 1996 Pegasus mail server and mail client could actually do the job. IT should not be owner of the Adoption of features made possible by the Migration. It should work the other way around. First there is a Feature Requirement list made by the Business. Out of that an IT Project/Migration may get started.

That being said, Adoption first, leaves the question of who must be the Owner if not IT. The answer to that is very simple: the CEO. If the CEO is not the Owner of Adoption every IT Manager will set himself up for failure when engaging in whatever Migration. Adoption touches the very heart and nature of the way people work and thus the Organization. If that is not endorsed, empowered and owned by the CEO, well, good luck. All will trickle down into the Organization from the highest management making sure all is in place when the stages of Migration arrive. I have very good experiences with Migrating higher Management first. Let them “Walk the Talk” and show that “all is well”.

Also, when progress stops because of CEO’s are not taking Ownership, Shadow-IT becomes a painful reality. Percentages of users finding their own way to do their job are rising, IT loses yet more control as will the Organization itself. Mobile Devices, Tablets, Notebooks, Drop Box, Skype, OneDrive, unmanaged devices, unmanaged storage, where is the corporate content going? That makes any’s Organizations fear of safety in the Cloud a bit ridiculous, doesn’t it?

To set up that CEO’s come back in control IT Management needs to have good connections with the higher Management. As a Consultant I can’t do much if I’m stuck on the level of IT. IT may understand what direction to go or not, but if higher management speaks a different language then IT is also stuck. This morning I had a one hour conversation on this with the IT Manager of one of my customers. He’s stuck in that exact situation. I could only listen to him and coach him on how to repair the damages of the past in those lines of communication in order for his CEO to get aligned again and put his fist on the table to move forward. I asked him to keep me posted on how that will go.

Another Customer sits at the other side of this. His CEO is enrolled in Azure and they are really moving forward FAST now. The CEO knows nothing about Technology but he was informed in such a way he could endorse and empower the Organization to move in that direction.

Conclusion: Cloud Adoption starts at the CEO!

 

CEO’s, Happy Adopting!!! You really should!

Users want to access applications and data that run anywhere, and, they want to run them from anywhere. There is only a very thin line left distinguishing business apps from non-business apps and they all need to be accessible anytime, anyplace, anywhere. That calls for Identity Management which can be very confusing for users. So here is a little explanation on the why, the what and the how.

In the old days we used to logon to our computer using this format:

• Domain\user
• Computer\user

Or maybe even without the domain\ or computer\:

• User (domain user)
• User (local computer user)

As long as the applications and their data sat on that local computer or in that local Active Directory domain, a logon like this worked perfectly. (Really? No. It uses NetBIOS and that protocol is soooo 1987, but that discussion is out of scope for this article)

The logon identity for a user must now be valid outside of the local computer and the local Active Directory as well. It must identify the user as a unique identity across multiple platforms, preferably: local computer, Active Directory, cloud applications like Office365 and personal applications like Facebook, Gmail, Twitter and the rest of it all.

The format to logon is called User Principal Name and a UPN looks like an email address and that can be very confusing for some users, for example:

• firstname.lastname@domain.com

NOTE: this is NOT necessarily a mail address! A mail address for this user could be, for example:

• firstinitiallastname@companydomain.com

If your computer is running Windows 8 (or above) you can logon using a Microsoft Account (a.k.a. LiveID or Hotmail.com or outlook.com account). The format of such an account is always the UPN format and it may or may not correspond to your private email account.

If you use multiple devices like PC, laptop, tablet, Windows Phone, the Microsoft Account synchronizes a lot of settings between your devices (like recent documents, desktop wallpaper, etc.) so that the user experiences a unified work environment, on whatever device.

Next to having a Microsoft Account (private, individual) you can have an Active Directory account to access corporate resources in your corporate network, maybe even remotely. Active Directory can (and should) have UPN as logon format instead of the NetBIOS domain\user.

When using Microsoft Online services like Office365, Microsoft Intune or Microsoft Azure you may have a so called Organizational Account, always in the format of a UPN. It can be synchronized from your Active Directory account, even with synchronization of your password. But beware, unless a thing called Federated Identities is enabled by your administrators, it still is 2 separate identities; you logon to separate authentication providers, your local Active Directory and a Cloud Authentication provider like Azure Active Directory.

So until now, this is all on accounts, the mechanism with which you authenticate yourself. Now we get to email addresses.

An email address always comes in the format of UPN (actually UPN’s were there first and email addresses were derived from the UPN). As noted above, the account does not necessarily have to match an email address. It can but it is not a requirement.

And that is exactly what can make it very confusing for users if they do not distinguish the difference between accounts (UPN, identity) and email addresses. THEY ARE TWO DIFFERENT THINGS! A user can sign with one UPN and have access through that to multiple mail addresses (aliases) even in different domains.

Some organizations and users try to match the account UPN to the email address, making it simple for users: who you are (account UPN) is your mail address. It gets confusing when you have multiple accounts AND multiple email addresses. In order to get it straightened out for yourselves you can create a little table like this and fill out the appropriate UPN’s:

 

Happy logging on!