Lately I've been thinking a lot about complexity in Microsoft Exchange Server and its surrounding infrastructure. One of my largest customers (I can't say who, but the name rhymes with "US Navy") still has a substantial population of Exchange 2003 servers, and the organization is in the process of moving some of its sites to Exchange 2007. Meanwhile, I work daily with Exchange 2010, and Exchange 15 is right around the corner. Are there any lessons we can draw from the increasing sophistication of these products?
The immediate answer: Yes. I vividly remember a vigorous discussion at a past MVP Summit wherein Andy Webb, former Exchange Server MVP and a great American, pointed out that one certain side effect of the new complexity introduced in Exchange 2007 was that smaller customers wouldn't upgrade or would look for alternatives such as hosted Exchange. I've heard similar complaints -- "this is too complicated," "SMBs won't deploy it," "there needs to be a simpler way" -- levied at Exchange 2010 and Exchange 15 as well.
Only Microsoft knows for sure what its adoption numbers look like when broken down by customer size. I think it's fair to say that some smaller customers have avoided upgrading as long as possible because of their fear that additional complexity in later versions of Exchange would cost them money or reduce their operational efficiency. However, I don't think that's the real issue. The real killer of complexity with Exchange isn't what Microsoft puts in the product; it's what we do with the product after we deploy it.
One case in point: resource forests. A resource forest, you might recall, is what Microsoft calls a dedicated forest that contains only services or applications such as Exchange. User accounts go in one forest and Exchange goes in another. I can honestly say that I've seen only a handful of customers whose business need for a resource forest (and the isolation of accounts and services that it can provide) outweighed the additional cost and complexity of maintaining a separate Active Directory (AD) infrastructure, providing directory synchronization (where necessary), and operating a second forest.
Virtualization is another, perhaps less extreme, example. Microsoft and VMware have tried really hard to tamp down the complexity of maintaining virtualized environments, but the fact remains that they are inescapably more complex than the same number of physical servers. Virtualized environments are more complex simply because they require you to manage not only the virtual machines (VMs) but also their physical hosts and the hypervisor itself -- plus any shared storage you might be using, as many highly virtualized environments depend on shared storage for efficiency and performance.
There are tradeoffs, of course; the increased complexity of virtualized environments comes with the potential for lower operating costs and increased resource utilization. But my suspicion is that many organizations who turn to virtualization for these benefits actually end up realizing little net gain when they include the additional complexity that comes as part of the package.
Microsoft's take on the phenomenon of increasing complexity seems to be that operational maturity is what will save us all. "Operational maturity" is sort of a catch-all phrase that, loosely translated, means that your messaging admins have both knowledge
and wisdom. What's the difference? Knowledge is knowing that tomatoes are fruit. Wisdom is knowing that you don't put tomatoes in fruit salad.
In Exchange, operational maturity means having the knowledge of how Exchange works in enough depth to realize what configurations are possible, and what the support and cost effects of different choices are. Wisdom is being able to counterbalance these support and cost effects with business requirements and the overriding "keep it simple, stupid!" philosophy that has been a linchpin of IT operations since the early days of vacuum-tube computers.
That said, what have you done to make your Exchange environment less complex? Drop me a note to let me know. I think this is a pretty fertile topic to explore, given how creative Exchange administrators tend to be with solving problems.
