“There’s no rocket science here. It’s all about due diligence.”
This is the first of a two-part interview, with it originally being posted on the Microsoft Enterprise Viewpoints blog at this link. In Part 2, we conclude with developer challenges, writing scalable applications, security and how to get started.
I had a chance to sit down with Mike Olsson, Senior Director in Microsoft IT, to talk about how Microsoft is aggressively moving internal applications to the cloud. Mike provided a great perspective on how to think about which applications to migrate, the importance of using a measured and rational approach, and how to get started.
Steven Ramirez: Microsoft currently has over 1,500 internal applications varying in size and complexity. At a high level, how was your mission explained to you?
Mike Olsson: Well, the mission came about largely as a result of a meeting between Tony Scott [Microsoft’s CIO] and the Server and Cloud folks. Tony articulated the situation this way: “If I was still at Disney, I would have a stream of Microsoft execs coming to me, telling me about their products.” But when he got here, that wasn’t happening. The assumption was, you’re in Redmond—you must know everything. So we set up a series of meetings between Tony and senior VPs. The meeting with Server and Cloud was remarkably successful. Tony was clearly enthused about the cloud and what it might be able to do for him.
The outcome was to go make the Auction Tool [an application used during the United Way annual giving campaign] cloud-specific. At some point, it became clear that this was going to be the focus of the group. We started relatively small. Each success led to more investment and the final push came as a result of Steve Ballmer’s “We're All In“ speech [see “Steve Ballmer: Cloud Computing”].
Microsoft IT prides itself on being Microsoft’s first and best customer. In this case—because there was no other enterprise organization that’s ever done anything like this—we really were the first customer and, as a result, the partnership with the product group has been outstanding. We learn, they learn, we share learnings.
SR: So when you got this dropped into your lap, what was your reaction?
MO: We were, as a team, universally excited. Every programmer in the world will finish a piece of code and say, “If I could do that again, I would write a really good one.” We’re looking down the barrel of an opportunity to redo all of the stuff that we’ve done in the past. Maybe not every single piece. But for large portions, we get a chance to rearchitect based on what we already know and based on really excellent technology. It’s the coolest thing out there.
SR: Before we go into details around moving the applications, can you talk about your team—how big it is and what kinds of skillsets it encompasses?
MO: Sure. PGSI [Product Group Strategic Initiatives] is a team of twelve people, give or take. We are predominantly old timers, meaning many of us have been with the company five, ten—even twenty years.
SR: So this is really traditional IT coming into the world of the cloud?
MO: Well, I was in the partner group and, before that, in international marketing. We do have people from traditional IT roles. We also have people who were product planners, Operations folks, Procurement, project managers, test managers. We are from every part of the organization. The common thread is, we have substantial experience with Microsoft and working in cross-team situations.
SR: Probably the most vexing question for customers is, “How do I decide which applications to migrate?” Can you describe the process you used?
MO: We started with a fairly straightforward segmentation approach. We ignored applications that were end-of-life. We initially put to one side apps that we thought had regulatory, Payment Card Industry or Sarbanes-Oxley implications. Then we eliminated applications that might be dependent on specific hardware or high-performance network equipment or anything non-standard. That left us with well over a thousand applications.
Next we built a grid that had technical complexity down one side and business complexity on the other. We ended up with basic, intermediate and advanced applications. Basic: low technical complexity, low dependencies on upstream or downstream systems, low risk. So essentially areas where we could get our feet wet without putting the company’s business in peril.
No sooner had we done that than we were asked to really go all in and migrate the Volume Licensing and Performance at Microsoft applications, which are at the other end of the scale. These are multi-year projects and we’ve been able to take a phased approach.
We are now building much more sophisticated methodologies for doing that segmentation. Once we started to look, we realized that there were four or five groups who had each built tools to help with this decision-making process. And we are now working with those groups to pull all of those tools together.
There’s no rocket science here. It’s all about due diligence. You need the Azure knowledge to a large extent and you need the application knowledge. Then you need to apply standard discipline.
The opinions and views expressed in this blog are those of the author and do not necessarily state or reflect those of Microsoft.