Biting the Hand - Conclusion

This is the final post in a three part series on Microsoft.  Be sure to read Part 1, on the history/state of the Windows operating system [2], and Part 2, on developing for the Microsoft platform [3].

Two More Stories - A Vicious Exchange

In late 2006, I moved an organization of about 500 people from Novell Groupwise to Microsoft Exchange 2007.  After evaluating the needs, I bought the standard edition, which supported message storageup to 16GB (Our Groupwise message base took up about 4GB).  A few days after we completed the migration, which included transferring the Groupwise messages to Exchange, an error popped up in the Event Viewer saying that our message store was larger than the 16GB limit, and, sure enough, it was - who knew that Microsoft messages were so much larger than Groupwise messages? 

The next day, Event Viewer reported that our message store was too large and that it would be dismounted at 5:00 am, meaning that email would be, essentially, disconnected.  Huh?  I connected remotely the next morning and remounted at about 5:10.  I also scoured the Microsoft Knowledgebase [4], looking for a recommendation on this, and found nothing.  I called up my vendor and ordered the Enterprise version of Exchange, which supports a much larger message store.  A couple of days later, same thing.  My new software hadn't arrived yet.  The next day, the message changed, saying that our message store was too large and would be dismounted randomly! What!?  This meant that the server could go down in the middle of the business day.  The software arrived, and I tossed the box on my desk and scheduled to come in on Sunday (which happened to be New Year's Day, 2007) to do the upgrade. But when I opened the box, I discovered that my vendor had sent me Enterprise media, yes, but it was for Exchange Server 2005, the prior version.  I was hosed.

Frantic, I went to Google instead of the knowledge base and searched.  This yielded a blog entry [5] explaining that, with Exchange Server 2007 Service Pack 2 (which I had applied as part of the initial installation), it was now legal to have message stores of up to 75GB.  All I had to do was modify a registry entry on the server - problem solved.  Wow, who woulda thunk?  Particularly if this had been documented anywhere on the Microsoft Knowledgebase?

But here's my question: What Machiavellian mind came up with the compliance enforcement routine that I experienced, and why was my business continuity threatened by code designed to stop me from doing something perfectly legal under the Service Pack 2 licensing?  This was sloppy, and this was cruel, and this was not supportive of the customer.

Cheap ERP

In early 2007, I hired a consultant to help with assessing and developing our strategic technology plan.  This was at a social services agency, and one of our issues was that, since we hired our clients, having separate databases to track client progress and Human Resources/Payroll resulted in large amounts of duplicate data entry and difficult reporting. The consultant and I agreed that a merged HR/Client Management system would be ideal. So, at lunch one day, I nearly fell off my chair laughing when he suggested that we look at SAP [6].  SAP, for those who don't know, is a database and development platform that large companies use in order to deploy highly customized and integrated business computing platforms.  Commonly referred to as Enterprise Resource Planning (ERP) software, it's a good fit for businesses with the unique needs and ample budgets to support what is, at heart, an internally developed set of business applications.  The reason I found this so entertaining was that, even if we could afford SAP, then hiring the technical staff to develop it into something that worked for us would be way beyond our means.  SAP developers make at least six figures a year, and we would have needed two or more to get anywhere in a reasonable amount of time.  It's unrealistic for even a mid-sized nonprofit to look at that kind of investment in technology.

So Microsoft holds a unique position -- like SAP, or Oracle, they offer a class of integrated products that can run your business.  Unlike SAP or Oracle, they're pretty much what they are - you can customize and integrate them, at a cost, but you can't, for instance, extend Microsoft's Dynamics HR package into a Client Management System.  But, if you have both Dynamics and Social Solutions, which runs on Microsoft SQL Server, you'd have a lot more compatibility and integration capabilities than we had at our social services org, where our HR system was outsourced and proprietary and the client management software ran on Foxpro.

Bangs for the Buck

So this is where it leaves me - Micosoft is a large, bureaucratic mess of a company that has so many developers on each product that one will be focusing on how to punish customers for non-compliance while another is making the customers compliant.  Their product strategy is driven far less by customer demands than it is by marketing strategy.  Their practices have been predatory, and, while that type of thing seems to be easing, there's still a lot of it ingrained in their culture.  When they are threatened -- and they are threatened, by Google and the migration from the desktop to the cloud -- they're more dangerous to their developers and customers, because they are willing to make decisions that will better position them in the market at the cost of our investments. 

But Microsoft offers a bargain to businesses that can't -- and shouldn't - spend huge percentages of their budget on platform development.  They do a lot out of the box, and they have a lot of products to do it with.  Most of their mature products -- Office, Exchange, SQL Server -- are excellent.  They're really good at what they do.  The affordable alternative to the commercial ERP systems like SAP and Oracle is open source, but open source platforms are still relatively immature.  Building your web site on an open Source CMS powered by PHP or Ruby on Rails might be a good, economical move that leaves you better off, in terms of ease of use and capabilities, than many expensive commercial options.  But going  open source for Finance, HR and Client Tracking isn't really much of an option yet.  The possibly viable alternatives to Microsoft are commercial outsourcers like NetSuite [7], but how well they'll meet your full needs depends on how complex those needs are - one size fits all solutions tend to work better for small businesses than medium to large ones.

Finally, it's all well and good to talk about adopting Microsoft software strictly on its merits, but, for many of us, it has far more to do with the critical, non-Microsoft applications we run that assume we're using their products.  For many of us, considering alternatives like Linux for an operating system; Open Office [8] or Google Apps [9] for productivity; or PHP [10] for our web scripting language are already nixed because our primary databases are all in SQL Server and ASP.  At the law firm where I work, we aren't about to swap out Word for an alternative without the legal document-specific features that Microsoft richly incorporates into their product.  But it leaves me, as the technology planner, in a bit of a pickle. Windows XP, Office 2003/2007, Exchange 2007, SQL Server 2007, and Windows Server 2003 are all powerful, reliable products that we use and benefit from, and the price we paid for them, through Techsoup [11] and their charity licensing, is phenomenal.  But as we look at moving to web-based computing, and we embark on custom development to meet information management and communication needs that are very specific to our organization, we're now faced with adopting Microsoft's more dynamic and, in my opinion, dangerous technologies. 

This would all be different if I had more reason to trust the vendor to prioritize my organization's stability and operating efficiency over their marketing goals.  Or, put differently, if their marketing philosophy was based less on trying to trump their competition and more on being a dependable, trustworthy vendor.  They're the big dog, just about impossible to avoid, and they make a very compelling financial argument -- at first take -- for nonprofits.  But it's a far more complicated price break than it seems at first glance.