Here's Anton's first comment on my Illinois series last week:
It all fits.Software from a single vendor known to work together well. Or, All Microsoft, all the time. No bits and pieces, and software "known" to be comfortable to users supplied without great difficulty to central IT.
That's making the "problem" of IT go away.
This response nicely captures one of the most common rationales for picking the Microsoft desktop, but that rationale has two significant problems. First, the reality is that Microsoft's software is anything but "install and forget" - it requires considerable maintenance effort and is responsible for a disproportionate share of the world's software failures.
The second problem is more subtle: the hidden assumption that for all significant user purposes the Microsoft product set offers comparable or better integration than do the products offered by Microsoft's competitors.
This one has two main problems: first the productivity consequences of various forms and/or levels of integration are unknown. Secondly, Microsoft's products are integrated at the architectural or sales level, not at the application level; so when you compare them to something like OpenOffice on Linux or Windows you're dealing with a completely different integration focus. Look at the Microsoft Office desktop and you would think it's an integrated suite: you can, for example, move data between applications fairly easily. Look closer, however, and you'll see that all of this is externally mediated. Run Word and the Windows Exchange client under win4sol, for example, and you'll find there's no built-in integration - you'll be forced to use the cut and paste capabilities in the X interface to get these two to communicate.
What's going on is that the apparent desktop integration you get with a full Wintel deployment depends on other wintel system components: desktop OS libraries, the dot.net framework, Exchange Server, Windows Server OS libraries, and Active Directory.
Put these two problems together and what they mean is that comparisons between application suites like Microsoft Office and Lotus SmartSuite are fundamentally misleading - what you have to compare is all of the software contributing to user accessible functionality: i.e. Smartsuite on one side versus Microsoft Office plus Windows/XP plus Active directory plus Windows 2003/XP Server plus the Exchange Server, etc etc on the other.
Fundamentally Windows application integration for large organizations depends on the mainframe - or, at least, the server farm running the multi-user components linking the stuff together and incidently providing both most of Microsoft's revenues and the mechanisms needed to impose and enforce IT control over user activities.
You can look at this as good or as bad: see it as good and multiple application clients sharing backend processes can be presented as efficient; see it as bad and it's not a stretch to describe the fully locked down corporate PC as nothing more than an expensive and remarkably dysfunctional successor to the IBM 3278 terminal.
In contrast to Microsoft's tarball approach most of the alternatives to Microsoft's desktop applications suites are internally integrated. Thus Domino, for example, can access AD, but includes an integrated directory that can be used with both OpenOffice and SmartSuite desktops - on Linux or Windows.
Fair cost comparisons between them must therefore account for all of the pieces needed to deliver the service - but when you do this for the Microsoft tarball you run into an allocation problem. If, for example, you wanted to compare Do mino to Exchange for a real business you might first have to decide what proportion of an existing AD installation und ertaken to support a small dot.net development effort you should allocate to Exchange. Since the smaller the percentag e allocated the better the case looks for Exchange the standard Microsoft approach is to recognize none of this cost - presenting the Exchange decision simply as taking advantage of a free good (the pre-existing AD installation) to impr ove overall organizational return on that earlier and independent decision.
It's a great argument widely used by mainframers seeking enhanced corporate IT control in the late 70s and early 80s, but it wasn't right then and it isn't right now - for two reasons: the refresh cycle and the marginal cost of service expansion.
The refresh cycle problem, particularly for public agencies, is that the lifetime of the Microsoft investment is often comparable to the length of the decision process: deciding in 2005 on using AD state-wide because you invested in AD for a judiciary subsystem in 2004 ignores the need to refresh that AD investment in 2006. The marginal cost problem is that total licensing and support costs rise super-linearly with user counts - meaning that adding large numbers of us ers to an existing installation increases rather than decreases average per user cost.
Thus all six of the puff pieces cited last week make the apparently sensible argument that the government agency involved had committed to the Windows system for some smaller project and therefore that extending Windows agency-wide effectively dilutes that cost over a larger a user base - but in reality the statewide decision increases local costs and they should have done the opposite thing: re-evaluate the future cost of maintaining that decision for the smaller group as part of the cost analysis for the agency wide deployment plan.
Had they done so it seems likely that not a single one of these projects would have been justifiable on cost or performance - and that's the real bottom line here: when estimating cost for Microsoft products you need to include the whole tarball over the long term - not just the immediate marginal cost of a bit more tar.