Great excitement echoed through the halls of Building 34 in Redmond on October 11 when the Exchange development chiefs met to decide whether Exchange 2013 met the bar necessary to commit the code to RTM, or “Release to Manufacturing”. The vote was positive and the software (build 15.00.0516.32) has moved on to the next stage in its lifecycle, the preparation for general availability.
Given that Exchange is developed by a very large corporation that is beset by its own internal politics, the decision to release a product or hold it back is not always straightforward. In this case, I imagine that a fair amount of pressure arose from the fact that Exchange 2013 is just one part of Microsoft’s “Office Wave 15”, intended to be a coordinated release of major Office server applications such as Exchange, SharePoint, and Lync alongside client applications like Outlook, Word, and PowerPoint. In some respects, it would be inconceivable for Exchange to say “no” if all the other Office groups said “yes”.
Discounting internal politics (yes, please, but not always possible), the bug count is another major influence on whether a product is ready to be released. Bugs are not created equal and one person’s terribly important bug might be placed in another person’s easy-to-ignore category. It all depends on whether a bug is obvious, stops major functionality working, can easily be reproduced, and so on. Product groups use a triage process to figure out whether a bug must be fixed before a product can proceed or can be addressed in the future, for example by inclusion in a service pack or roll-up update. At the end of the day, negotiation between the various interested parties (development, testing, product management, program management, and group management) concludes whether the code is of sufficient quality to proceed.
Customers have a say too. Microsoft runs a very committed Technology Adoption Program (TAP) for Exchange that allows customers to have early access to beta code that they can install and use (including for production, in limited circumstances agreed with the development group). The information flowing back from the TAP is invaluable to Microsoft because it represents real-life experience to complement their own testing. The TAP customers are asked to vote whether software is ready for release and their views carry a certain weight when Microsoft makes the final decision.
Of course, saying that software is ready to be released and customers proceeding with deployment are two very different things. Exchange 2013 has quite a road ahead of it before we see it making much of an impact when measured as more than even 5% of the installed base. First, Microsoft has to get the final code into customer hands, a process that involves things such as updating marketing material, TechNet, and MSDN and figuring out how best to distribute the software around the world. Then customers have to assess the finished form of Exchange 2013 against their own requirements. If a sensible match exists, we then move on to the challenge of deployment, probably involving a migration from a now legacy version of Exchange (how quickly Exchange 2010 has become “yesterday’s version”). Dependencies exist on other software if you want to use some of the new features in Exchange 2013 such as site mailboxes (SharePoint 2013) or Data Leak Protection (Outlook 2013), so that can cause further delay. Everything takes time, possibly more time than anticipated.
It’s good that Exchange 2013 is finally emerging as a fully-fledged product. The engineers will no doubt mark this point with an appropriate celebration of their own (“MAPI beers, anyone?”) before they get back to figuring out what should be included in future versions of Exchange. The rest of us will now get on with the more hum-drum steps of figuring out when and where to use Exchange 2013 – or whether it would be wiser to wait for Exchange 2013 SP1.
Follow Tony @12Knocksinna
