With the Vista operating system in beta trials and so many new products coming from Microsoft, riding the wave of new technology may seem more like clutching onto the board than hanging 10 and surfing smoothly ashore.
We have found that our clients have benefited from looking at Microsoft's release cycles in conjunction with their own. With some perspective, they can plan how to take advantage of new technology when it makes sense for their organization.
Operating system history
The Microsoft operating system release history definitely has a pattern. Client and server releases -- with several anomalies -- have happened roughly every three years and, generally, in the second half of the year.
Several factors have affected timing. For example, Microsoft's Trustworthy Computing Initiative added about 10 months to the release of Windows 2003 and Vista. Also, the three-year time frame represents two rotations of Moore's Law, which is enough to cause technology advances significant enough to require new hardware.
Other factors include branching and update releases. The first major branching took place with Windows Server 2000, followed by multiple products and variations of the operating system, such as Windows CE for Automotive and Windows XP Tablet Edition. Branching may affect the progression of major server releases as the complexity of maintaining the Windows code base increases.
Update releases are a new approach for Microsoft and effectively add a year to the previous three-year release cycle (see Microsoft's Windows Server Product Roadmap). These interim releases will happen two years after a major release. This new pattern offers customers more options to consider for their upgrade strategies and allows the operating system to stay more competitive during the new, longer major release cycle.
Calculate cost justification
You can use these trends to help determine how to maximise your company's return on the cycle variation you choose for the Microsoft operating system. Release cycles' relative predictability lets you calculate and capitalize on the operating system during the supported days on platform (SDP). The SDP represents the period during which patching and support are available from the vendor, as well as the period over which you can spread the fixed costs of installing the operating system. By calculating the cost and net gain generated by an operating system, you can estimate the value of adoption.
Costs associated with the operating system include installation and maintenance activities such as patching. In our experience, many of these costs are quantifiable, whether based on your company's historical expenditure or on analysts' estimates. You may have other costs specific to your IT environment, too. Add these costs and divide by the number of days the operating system will be installed (the SDP) to come up with a daily cost of running it:
Cost per day of OS use = [Cost of Installation + (Number of Patches * Cost per Patch) + Maintenance + Environment-specific Costs] / Number of Days Installed
To calculate net gain, estimate income generated by features and functions the operating system supports.
Net Gain per day of OS use = [Additional Revenue Enabled by New OS Features+ Cost Reduction Enabled by New OS Features + Productivity Enabled by New OS Features] / Number of Days Installed
This calculation can become fairly complex. The idea is to estimate the point in the operating system life cycle when the difference between cost and net gain of the new operating system is equal to or greater than the differential of the old one. Keep in mind that constraints such as hardware age or supportability may mandate an upgrade, irrespective of your calculation.
Value = Net Gain - Cost
Subtract cost from net gain to estimate the value of your migration per day. Multiply that value by the SDP, and you can gain a sense of the quantitative impact of an upgrade for your organisation.
With insight into operating system release cycles and support, you can time your upgrade for maximum efficiency and drive down the cost per day of use. When the next server release offers features that could create additional gains, recalculate to determine whether and when the upgrade will provide greater value.
Through this process, you also may identify factors such as remaining SDP on the old system and time to deploy that will influence your course of action. And smaller firms' support requirements and degree of dependency on the software for revenue generation may give them greater flexibility and choice.
In general, we find it's good strategy to focus on operating system releases whose features best support revenue-generating activity and to make deliberate choices within the release cycle and your own constraints to lower the cost per day of use. You might even decide to upgrade because in the long term, synchronizing with the operating system release cycle outweighs the relative value of new features. As long as you've calculated the cost justification, you'll avoid an upgrade "strategy" that's really just a scramble to keep up.
Christopher Burry is technology infrastructure practice director and a fellow at Avanade, a Seattle-based integrator for Microsoft technology that's a joint venture between Accenture and Microsoft. Bruce Woolverton is a systems engineer at Avanade. Comments or questions can be sent to Christopher.Burry@avanade.com.