Well, it's great to be back in the saddle again! Special thanks to Evan Morris and Kieran McCorry for filling in as guest editors during August while I took a short break. I hope you enjoyed their columns as much as I did. Look for great articles from Evan and Kieran in Windows 2000 Magazine's Exchange Administrator monthly print newsletter.
I've been pondering the future of Exchange Server amidst the huge fanfare around Microsoft .NET and Exchange 2000 Server's Release to Manufacturing (RTM—see news story later in this UPDATE). I think we're going to see a major change in the way we think of and use the BackOffice family of products (now disappearing into the .NET architecture).
My own organization is going through this thought process also. In the past, users have seen products such as Windows NT, Exchange Server, and SQL Server as "plumbing" or application enablers. The IT department solves a particular business need (email) by deploying a product such as Exchange Server. We've all become experts at deploying Exchange Server and can do great things with the product. Service organizations have also fared well because they've become experts at deploying this plumbing for their customers. I expect you, like myself, have fallen victim to this unforeseen trap. I call it a trap because we've focused on the product (Exchange Server) and the technology and have become expert plumbers; however, in the future, we'll have to expand our plumbing expertise into solutions expertise.
Most of us have seen this situation coming. The complexity of mission-critical, line-of-business applications is growing beyond one product technology from Microsoft (or any other vendor). In the past, we deployed applications for our customers that were typically (but not always) limited to one product technology. For example, in my organization, we used SQL Server to deploy a customer service tracking database. With the exception of some Access or Visual Basic (VB) code on the client, the entire application was within the confines of SQL Server technology. We, as experts, only had to be familiar with our respective plumbing platforms (SQL Server, Exchange Server, IIS), and we served our customers well. By the way, Microsoft has the same problem in its development and marketing teams.
With .NET and the increased complexity of line-of-business applications in the future, we must have a firm grasp of all technologies and interfaces from which we can build business solutions. We must be able to look at business problems and apply a solutions framework that might include pieces or services from Exchange Server, SQL Server, Commerce Server, and BizTalk Server. These solutions might extend beyond the Microsoft suite of technologies. As Exchange administrators, planners, and implementers we'll have to extend ourselves outside of our comfort zones and develop a solutions mentality that lets us leverage technologies and interfaces to solve real business problems. We can't solve these problems with one technology (e.g., Exchange) alone. In fact, in the Microsoft .NET Framework, technologies such as Exchange fade into the background and become simple enablers. This is a call for all (myself included) to change our mindset. Let's become architects instead of plumbers.
