Executive Summary:
Windows Server 2008 demonstrates the biggest change in Windows Server development over the past decade. Looking behind the scenes of Server 2008 development, we learn from Alex Hinrichs, Server 2008 product manager, that the big change in server development was the move to a roles-based management architecture. This componentization of roles helped Windows Server 2008 development proceed in a more orderly way than other Windows OSs in the past. A clear list of desired features helped the Windows Server team to hit its milestones as well as an impressive quality bar without having to "churn the code" in response to unexpected feature additions. The most important lesson the Server 2008 team learned was to deploy early and often, with at least 18 months of testing for important components.
|
With Windows Server 2008 heading toward first
quarter 2008 launch, I sat down with Alex
Hinrichs, the Server 2008 project manager, to
discuss the development of the product and how changes
to it will benefit customers going forward. There’s no doubt
about it: Server 2008 is the most customer-driven version
of Windows Server yet, and though it’s a major revision
that will surely bring with it some compatibility problems
in the short term, the long-term benefits are obvious and
unassailable. Here’s what you need to know about the
development of Server 2008.
Hinrichs Maneuver
Much of the work around Windows Server occurs in Building
43 on the Microsoft campus in Redmond. Alex Hinrichs
runs the Windows Server ship room and manages the
development of this increasingly complex product line that
affects almost every level of Microsoft’s customers. He sets
the schedule, defines the processes, and is the point man
for any decisions that need to be pushed up the ladder to his
superior, Iain McDonald, or Bill Laing, the general manager
of Microsoft’s Server Business.
A 12-year Microsoft veteran, Hinrichs was originally
hired as a Windows NT program manager. He worked as the
release product manager for all Small Business Server (SBS)
releases from SBS 4.0 to SBS 2003. On the heels of SBS 2003’s
completion, Hinrichs jumped over to Windows Server.
Define Servers by the Roles
They Perform
The fundamental change in Windows Server development
has been the move to a roles-based management architecture.
Microsoft began working on nascent versions of this
architecture as far back as Windows 2000, but it wasn’t until
Server 2008 that the OS was finally componentized, allowing
the management roles inside the product to map both
to the underlying architecture and to the product groups
working on Windows Server.
“The thing we really hang our hat on is that we’ve had a
clear vision for Windows Server 2008 from the beginning,”
Hinrichs said. “We talked to our customers and they don’t
think of the product in terms of product versions, but rather
about the server boxes. In their data center and server
rooms, they can point to different machines and say, ‘That’s
the domain controller, that’s the file server, that’s the Web
server, and that’s DHCP. 'That’s how they think. The problem
is, we produce a Swiss Army-knife kind of server product
that does a bunch of different things. But customers wanted
to define their servers by the roles they performed.” Thus, the
roles-based architecture in Windows Server was born.
“This also allows us to better engineer the product from
the start,” Hinrichs added. “Roles define things from the
beginning, and deep componentization means we can
install as little functionality as possible by default and give
admins only exactly what they need.” Even Microsoft’s
engineering teams, with few exceptions, are organized
by roles. “We have general managers and product unit
managers whose job, literally, is to manage things like the
Terminal Services business, the Active Directory business,
the IIS business, and so on,” Hinrichs said. “We engineer the
product soup to nuts to make that happen. Again, it’s a very
clear focus and vision that helped us scope the product and
make the right decisions.”
Manage Complex Product Changes
From a process perspective, Server 2008 has been in development
longer than any previous version of Windows
Server. To manage such a complex product over many
years and not run into the problems that, quite frankly, were
rampant with the Windows Vista team, is an achievement.
In stark contrast to that of Vista, Server 2008 development
was steady, sure, and without controversy.
“
The way we get to this point is that we had a clear feature
list from the start,” Hinrichs told me. “We locked down
the bulk of the features we wanted to include in 2005, and
did a final triage on features back in December 2006. Of
course one or two things did trickle in over time, but the
feature list was locked and loaded at end of 2006.”
By doing so, the Windows Server team was able to hit
its milestones as well as an impressive quality bar without
having to “churn the code” in response to unexpected
feature additions. “We just have so many OS components,”
Hinrichs said. “If you make a change to some low-level
component, components that are high on the stack can be
affected. So you have to lock it early. It reduces the amount
of shifted sand.”
This clear vision of a roles-based product lets Microsoft
steer a ship that would otherwise be unwieldy. “We can tell
a few thousand people [in the Server division] that this is
what we are doing, and then they can execute on it,” Hinrichs
said. “The scope of our customer base is pretty big,
from small businesses to the enterprise. But it’s not as big
a challenge as what you see on the client [i.e., Vista] where
the scope runs from the consumer all the way up to the
enterprise desktop.”
Replay the Positives from
Windows 2003
The development of Server 2008 was also
affected by lessons Microsoft learned from
previous product versions. “What we tried to
do with Windows Server 2008 is take the positives
from the Windows Server 2003 playbook
and replay those,” Hinrichs said. “And then we
avoid the mistakes. We know what’s working
because customers tell us it’s good.”
The most important lesson was to deploy
early and often. Microsoft knew that some
of the more “disruptive” server roles-Web
server, Active Directory (AD), Network Access
Protection (NAP), Terminal Services Gateway-
needed to be rock solid before they
could be shipped in final form to customers.
So these roles got at least 18 months of testing
internally at Microsoft and externally with its
Technology Adoption Program (TAP) customers.
“Over time, we’ve discovered that that’s
the magic time period,” Hinrichs noted. “So
that’s what we’ve done, and over two years in
some cases. We deployed Beta 2 [back in 2005]
within Microsoft and externally with 50 customers
we watch very closely. They get weekly
calls and extra funding and people out to visit
them on the road regularly. They were running
[Server 2008’s] Active Directory two years ago,
just like [Microsoft].”
Continued on Page 2