Skip navigation

A Snapshot of Exchange Server Today and Tomorrow

With the announcement in January that Microsoft Exchange Server has hit the 100-million-seat milestone, I thought I'd look at Exchange messaging systems today and where, in my humble opinion (worth about $.02), they are going.

My first observation concerns the effects of Microsoft's .NET strategy on Exchange Server as a messaging system. In some ways, .NET signals the end of messaging systems in the Microsoft environment. Over the past 2 years, Microsoft has gutted the Exchange Server development team by spinning off the client (Microsoft Outlook), wireless/mobility functionality (Mobile Information Server), real-time collaboration (Conference Server, Instant Messaging), collaboration/search functionality (SharePoint Portal Server), and the Exchange Store (JET/ESE) to separate development teams or product lines. This trend tells me that messaging services are headed for a role as core OS services. Microsoft won't cease to market Exchange Server as a key component in its .NET Enterprise Server family; however, Exchange Server will likely be a set of add-on OS services rather than the current monolithic service architecture. Messaging services will simply be integrated business application services.

Another emerging trend is the use of wireless access to messaging services. Although International Data Corporation (IDC) estimates that only 5 percent of organizations currently provide wireless access to Exchange services, this situation likely will change with the growing ubiquity of email-capable wireless devices and services. In fact, IDC believes this number could rise to 50 percent within the next year. Wireless access to Exchange Server is important to Microsoft, and the company has added a lot of mobility functionality to the .NET strategy with the .NET Mobility Enablement Kit, Exchange Server Software Development Kit (SDK), and other mobility tools. And in a reversal of direction, Microsoft recently moved the Mobile Information Server (MIS) group back into the Exchange Server development team. This move comes less than 2 years after Microsoft split off the MIS team. This reversal signals the significance of wireless and mobility technology in Microsoft's messaging plans.

I also expect the Exchange Development Platform to become less important, primarily because of .NET initiatives such as the .NET Framework, Visual Studio.NET, and .NET My Services (formerly Hailstorm). Don't misunderstand me. IT staffs will continue to develop applications that use Exchange Server and leverage its services, but the Exchange Development Platform is a thing of the past. Eventually, developers won't need to worry about Exchange Server, which will simply be a data source or a transport that developers access with common interfaces.

The success of this change depends on several requirements. First, Microsoft must successfully build .NET into Exchange Server. Second, Microsoft will need to deploy Exchange 2000 Server on .NET Server. Third, Microsoft must gain developer acceptance. Microsoft has already frustrated Exchange Server application developers with its changes in direction and misfires (can you say local store?) over the past 2 years. Microsoft will have difficulty convincing developers that it's serious about .NET in Exchange Server. According to IDC, only about 15 percent of Exchange deployments have custom Exchange Server applications, and only 16 percent integrate Exchange Server with other business applications. But to combat the Lotus Notes/Domino threat, Microsoft needs to make developer acceptance important if the company intends to promote Exchange Server as a collaboration platform. However, the entire .NET strategy might make Exchange Server application development a moot point because the focus likely will shift to building business solutions rather than Exchange Server applications.

The final trend I'll address is hosted messaging services, or outsourcing. According to IDC research, only about 16 percent of Exchange Server shops are interested in outsourced Exchange messaging services. This lack of interest might relate to security concerns, loss of control, or economic conditions. Until the economic climate improves and IT staffs move from their protect-and-defend posture, I don't see many organizations moving to outsourced Exchange messaging services, even though that option has many compelling arguments and possible cost savings.

The future direction of Exchange messaging is uncertain. Microsoft's ability to convince customers of the benefits of .NET and entice developers to that platform will be key. I have no crystal ball, but I have some opinions based on what I'm seeing and where we've come from. I'm also interested in your opinions, so drop me a note with your $.02 worth.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.