We can’t emphasize enough the importance of continual investments in security. In the past we did releases every three to five years. Those releases establish a baseline of security – a plateau of the security capabilities. That means that there is a constant level where the bad guys can exploit weaknesses in the platform – it was perfectly secure when it was released, but over time people figure out how to poke holes in it. That leaves these protection gaps. Sure, we do security updates with fixes to keep patching the holes. But you can only apply so much spackling before you need to replace the dam. We need to make architectural changes. We need to add new security features. We need to stay ahead of the bad guys.
Releasing every three to five years doesn’t work anymore because the bad guys have organized. It used to just be script kiddies in basements trying to create chaos but it’s much broader than that now. So we need to have those twice per year releases just so that we can stay ahead. Every single Windows 10 release is guaranteed to add new security features so if you don’t deploy one you’re at a disadvantage: you don’t have those security features, and therefore you aren’t able to withstand the latest new type of attack that’s coming your way.
We also know the productivity is important and disruption is bad. So how do solve for both? How do we give you capabilities more quickly, and at the same time reduce the amount of disruption? Fortunately, those two tend to go together: if we do every three-to-five-year releases, we’re basically then depositing years’ worth of changes onto your users at once. That’s a big amount of change and that tends to be fairly disruptive. If we do releases twice per year, those changes are much more incremental and as a result of that don’t impact the end users nearly as much – they adapt much more gradually because the change is coming much more gradually.
That gets us to the biggest challenge of this. If you look at your typical deployment project it was big – probably anywhere from a 12 to a 36 month project where you pulled a large group of people together who spent time going through and testing out every single application, every single webpage, all parts of your infrastructure, easily spending probably 12 to 18 months before you even deploy the first machine – just to plan and prepare for that deployment that, combined with infrastructure updates, creating new images, etc. All of that effort results in a very big project.
So what you have to do now is try to translate that into something much smaller – how do you go from this really big project every three to five years to a much smaller project about every six months. First, you don’t do it as a project, you do it as a process. We want to get into a continual process of doing this in order for this to really work.
The biggest problem in the past has been application compatibility. As you moved from Windows XP to Windows 7, application compatibility was fair – you had to go through a lot of testing to validate your apps. As we went from Windows 7 to Windows 8 to Windows 8.1 to Windows 10, the compatibility has been a whole lot better and as a result the validation can be much more relaxed. We want to move away from explicitly testing every single application that you have in your portfolio to instead prioritizing and finding the most important .
We have a lot of people running Windows 10, over 500 million that we’ve talked about. We have large customers that have deployed Windows 10 inside of their organization and are now starting to go through this Windows as a service model. We’ve talked to some of them like Kimberly Clark who said great, we’ve been going through this exercise that’s reduced our overall operating system deployment time by 75%. Great, although if you think about it if you look at the pace that we’re deploying if you deployed every five years and now you’re deploying twice per year that’s a ten-times increase in the rate of deployment, therefore your cost should be probably about 90 percent less. So we would look at that 75 percent and say it’s a start; we’re not quite there yet we can make this better, we can continue to improve it, which is why we continue to make these tweaks in these adjustments to the Windows as a service model, why we keep making more engineering investments to make this better overall so that the next quote we get from them says “yeah, we’ve now reduced it by 94% from what we had originally started from.” We want this to become a smooth, normal day-to-day process that you don’t have to worry about.
