Guest Opinion

Is Microsoft Enterprise-Ready?

Microsoft has a reputation for tools that don't meet quality and security requirements needed to build enterprise-ready apps. Despite recent successes, is this reputation still deserved?

• By Peter Varhol
• 10/01/2005

No one doubts that Microsoft software is ubiquitous within enterprises. Windows, Office, and Outlook are present throughout. Even on the server side, Exchange is more often than not the mail server of choice, and IIS powers many intranets and even some Web sites.

But is the platform ready for mission-critical applications with unique business needs? That has always been the knock against Microsoft—that its tools, languages, and architectures are simply not up to the quality and security requirements needed to build the types of applications on which large organizations can depend.

Microsoft has been attempting to overcome this reputation for years, and with some success. Managed code through the .NET Framework was the first concrete result of this effort, and Visual Studio 2005 and SQL Server 2005 are the latest. And Indigo looks like it will be a compelling way to build architectures employing Web services.

So is Microsoft's reputation still deserved? Yes, although asking the question in another way results in a slightly different answer. Has Microsoft internalized the commitment to building an enterprise-quality platform and tools? I'm much less sure of this answer, because internalization requires some insight into the Microsoft culture that I don't possess. However, external signs indicate the company still has some work to do. The shortcomings are less technical than business-oriented.

Microsoft's visible and consistent lack of honesty in its product and roadmap pronouncements must change. Despite the fact that it seeks a fundamental change in its market perception from scrappy competitor to trusted partner, Microsoft still uses these pronouncements as marketing tools rather than essential corporate planning data for its customers. Worse, when announced and published roadmap and product release dates slip, Microsoft spokespeople disingenuously deny that any slip occurred.

Another, less visible area of concern is the perception that Microsoft development teams practice barely controlled chaos in their own processes. This perception began when tales of marathon coding and debugging sessions and rapid employee burnout were published. These tales might have been badges of honor at one point in the company's growth, but they now do nothing to inspire confidence for customers. In fact, such tales today might be inaccurate, but Microsoft does nothing to correct the perception. If Microsoft development teams use state-of-the-art software engineering processes and tools, measure and manage risk, and adhere to their schedules, the company needs to make this known and make these processes and tools widely available as best practices. If, as seems apparent, teams fall short of this standard, then their practices must be elevated.

When schedules are extended by months or years in order to "get it right," it means that those on the technology side got it wrong to begin with. Yet seemingly, little is done to correct the problem, because the story is the same for each major release.

Microsoft needs to really get it right before becoming that trusted partner to enterprises. Schedules cannot continue to be driven by overly optimistic estimates that have become the butt of industry jokes. Herculean programming efforts frighten customers into thinking that similar efforts will be required of them.

Trust is built on making a commitment, standing by that commitment, and doing whatever is necessary to fulfill that commitment. And if you do not meet that commitment, you do not prevaricate; you stand up and say "We blew it," and you present a plan to fix it.

I have no doubt that Microsoft can get it right. The company has shown an enormous amount of tenacity and the ability to learn from its mistakes. But in order to become worthy of the trust it is seeking, Microsoft must turn its focus away from the technology and work on its software engineering practices and culture.

It's important that Microsoft define and publicize the best practices used today by its development teams and cite the research and real-life data that backs up those practices, or admit that it can make improvements and define a specific plan of action. These actions won't make Microsoft applications ready overnight, but they can be the first steps on the road to gaining the trust of enterprise IT.