When building a client solution from the ground up, you'll almost inevitably have to weigh the benefits and drawbacks of whether to go the Microsoft route. Here's what you need to consider about interoperability, security, cost, and several other factors.
When clients call on me for help, their constraints usually dictate most of my technology choices — that's because they're rarely starting from scratch; they have an existing solution that needs to have some new features added to it, or the solution needs to interface to some other service. Based on the time-honored maxim of "if it ain't broke, don't fix it," I would never recommend rewriting an existing solution under those circumstances unless there were no other reasonable paths leading to the desired result.
Occasionally, your client will hand you a slate that's nearly blank and ask you for your best recommendation on building a new solution from the ground up. Among all the other questions that you must consider, one of the first that inevitably arises is "To Microsoft, or not to Microsoft?" More specifically, should you recommend a solution that is based on Microsoft products such as Windows and the .NET Framework, or should you avoid Microsoft products like the plague? Here are several points to consider:
- The client's existing investment in Microsoft technology. I'm not saying that you shouldn't encourage clients to try new things, but if all of their servers are running Windows, their Web sites are all on IIS, their administrators have never worked on any other platform, and all their programmers are used to .NET, then switching to something else adds cost and risk.
- Availability of additional developers. If they need to hire new people for the project, they can certainly find developers with Microsoft experience. On the other hand, some of the brightest developers prefer not to work with Microsoft products, while beginner developers often gravitate towards Microsoft in order to increase their marketability. This increases résumé noise when looking for qualified .NET developers, as opposed to other frameworks that attract adherents for less mercenary reasons.
- Training materials and support. Microsoft products offer paid support, free documentation on MSDN, and a huge online developer community. Open source solutions vary widely in terms of their community support; in some cases, you could be left out to dry if you have a problem. On the other hand, I find that Ruby and Common Lisp developers (among others) often provide better assistance for free than you can get from Microsoft's paid support because the members of these communities feel strongly about promoting the growth of their product's usage.
- Interoperability. If your client's product will need to integrate with other Microsoft solutions (Office, SharePoint, etc.), then sticking with Microsoft has its advantages. I've written COM interfaces in Microsoft-neutral languages, and it's not pretty. If you do anything with Microsoft, it pays to do things The Microsoft Way. That cuts both ways, though, because it's also a good reason to avoid Microsoft products when you need to integrate with non-Microsoft solutions. Even when employing open standards, Microsoft likes to "enhance" openness in ways that create headaches for everyone else.
- Ubiquity of Microsoft users. If your client intends to market this product, then they must consider the constraints imposed by their market. Like it or not, Windows still rules the desktop, so writing a desktop application that doesn't target Windows is like opening a restaurant that only serves people with advanced degrees. Even in Web-based applications, you're cutting off a large potential market if you don't bow to compatibility with Internet Explorer, although that can be achieved without using Microsoft solutions for development. Maintaining compatibility with Internet Explorer and other browsers can be a pain in the you-know-what, but if you don't also support Firefox, Safari, and Chrome, you risk alienating a growing group of more savvy Internet users.
- Key components. The .NET Framework offers components that cover a wide range of needs, and third-party offerings augment those needs. For some specialized components, you may not have a choice between .NET and other alternatives, or the alternatives might be second-class citizens in terms of support and enhancements. You could end up writing more of it yourself, which has its trade-offs: better control over your fate vs. more time spent reinventing the wheel.
- Security. Microsoft suffers from a bad history of security vulnerabilities that took ages to patch; nevertheless, many consultants see the security of Microsoft products as a relatively known quantity — that is, something they feel comfortable with because it's "the devil they know." The old adage "no one ever got fired for buying IBM" gets applied to Microsoft these days, especially regarding security: If the client suffers from a vulnerability in Microsoft products, that's just the way the firewall crumbles — but if it happens in some non-Microsoft component that you recommended, then it's your fault. But if you truly have your client's best interests at heart instead of the interests of your own backside, you can rarely if ever recommend Microsoft on the basis of better security — if for no other reason than that Microsoft's market share makes the company a big target.
- Closed source. If something doesn't work the way you expect, you can spend a lot of time with technical support and/or trial and error trying to figure it out because you can't look at the source code. Increasingly, Microsoft has made more of its source code available to developers, but key layers remain hidden from view. If you've ever looked at some of what the company does make public, you'll understand why they're shy — most of the code is as overgrown as their organization. Open source alternatives tend to be much better written because they're under constant public review and improvement.
- Cost. Microsoft is almost never the most expensive alternative — in fact, I still encourage my clients who are software vendors to use Microsoft as a pricing benchmark for their products. However, Microsoft's products are still infinitely more expensive than "free." Microsoft and its proponents argue that Total Cost of Ownership is lower for its products, but I remain unconvinced. While it's true that "there ain't no such thing as a free lunch," I don't think that Microsoft has adequately demonstrated that the price of its products is offset by the supposed extra costs of using something else.
I expect this article to generate some heated comments in the discussion. Many of our readers strongly support Microsoft products, while others are just as strongly repulsed by them. I've tried to present a balanced view here.
While I feel that Microsoft's success is due more to the quality of its marketing than its products, I can't dismiss the company's dominance, and it's a fact of business that consultants have to live with. If you refuse to offer Microsoft-based solutions, then you're severely restricting your niche. But if every problem automatically looks to you like a nail awaiting the Microsoft Hammer(tm), then you're cheating your clients and yourself.
Related TechRepublic resources
- The Linux consultant: The Maytag repairman of the IT world
- Maximize your IT consultancy's Microsoft relationship
- What Windows 7 means to IT consultants
Get weekly consulting tips in your inbox TechRepublic's IT Consultant newsletter, delivered each Monday, offers tips on how to attract customers, build your business, and increase your technical skills in order to get the job done. Automatically sign up today!