Multi-Release Strategies and Role Based Access Control

Following the ‘why we built Exchange the way we did’ theme, I wanted to take some time to explain some architectural changes that have been made to Exchange over successive releases.

After Exchange 2003 shipped we took a step back and assessed the state of the code base. At that point, Exchange had grown fairly organically over the various releases since the start of coding about a decade earlier. It was clear that there were assumptions built into the core architecture that were no longer optimal given the steady but exponential changes that were accumulating in the hardware we ran on and in the way customers were using the product. One option was to start with a blank sheet and attempt to rewrite the product in one release. 

We decided this was not a likely path to success given the large scope that Exchange had evolved to encompass. However, it was also clear that dramatic changes were needed and that we had exhausted our ability to approach Exchange development in a feature-by-feature and release-by-release manner.

The 3-release refresh cycle that we embarked on is a subject of a future video posting. So rather than talk about the broad approach, I thought it would be better to start with an example of an important scenario that we delivered as part of Exchange 2010 that had its roots in some key Exchange 2007 investments.

Specifically, this video focuses on the RBAC story in Exchange 2010. In it I explain how the role based management delegation story in Exchange 2010 is rooted in, and was a key driver for, the work to switch to a verb oriented, task/cmdlet-based system management infrastructure back when we were planning the 2007 release.

This is a great example of a multi-release strategy successfully solving a problem that had eluded previous attempts to build useful management roles in the scope of a single release.

Perry