In the bad old days, before specialized update deployment program management, it was the responsibility of the update release manager to deploy their own updates. And in a sense, things haven't really changed so much from the bad old days, except that they have. Let me explain.
Believe it or not, getting important hotfixes and service packs into the hands of millions of customers worldwide is a somewhat complicated thing to do. A recent security update from our team consisted of over 100 unique packages (patch executables), each functionally equivalent (that is, each contained the same logical fix), but each targeting a unique subsection of the .NET Framework ecosystem. And believe it or not, exactly one of my colleagues was responsible for that update end-to-end.
The fix itself was easy, it was packing and deploying that fix that was complex. Over 100 unique packages deployed via three versions of Windows Update, one managed network security tool, and the Microsoft Download Center, all with an international focus. All in all, there were something like 400 unique ways that an arbitrary customer could get this necessary fix.
My colleague worked extraordinarily long hours with many sleepless nights (seriously) to get it out the door as fast as humanly possible before the black hats could do their worst. That time frame was on the order of six months.
Getting all of that done was a full-time job for my colleague for literally months on end, and these were months after the update packages were already signed-off by everybody else: The bits were golden, my colleague just needed to get them into our customers' hands. But what makes this story tragic is that it didn't need to be that way. Most of that deployment work could have been done in parallel with the earlier work, the only reason it wasn't was a resource constraint: my colleague was only one person and the work required could have been more efficiently performed by two. In this case, two resources instead of one could have literally cut the end-to-end time in half.
Those were the bad old days. Those days are past. Today we recognize that much of this deployment work can be done in parallel with other activities. That's where the update deployment manager role comes in. It's my job to help streamline the process: Get updates into customers' hands faster by parallelizing the work and specializing in deployment.
In a sense, things haven't changed so much at all. If the same security issue were felt today, my colleague would still own the issue end-to-end. What would be different is that my colleague would now have the support of resources dedicated to facilitating the deployment aspects of the update release. In a nutshell, that's what I do: I do everything that I can day-to-day to make sure that valuable updates are delivered efficiently to exactly the right customers. It's a complex mission (as I am hoping this blog will help to show), but it is both achievable and necessary. I definitely feel up to the challenge.
