Breaking up (Microsoft) is hard to do - Modularity is a technical issue

By CBDi Forums 03 May 2002 | CBDi Forum Limited, special to SearchWebServices

Digg This!     StumbleUpon     Del.icio.us

Guest Commentary -- Part 2
Breaking up (Microsoft) is hard to do - Modularity is a technical issue

Continued from Page One

It's a real world problem, folks
Perhaps the problem is a more practical one that everyone will empathize with. Bill Gates gave some insight into this when he said (reference 83),"Modern operating systems such as Windows are enormously complex products. Windows XP, for example, contains literally tens of millions of lines of software code, developed over the course of many years by thousands of engineers at Microsoft. In the course of creating any complex software product, bugs and other problems always arise. The only way to find these problems is to test thoroughly the product, trying out all its capabilities in a rigorous, organized way under various scenarios." And we agree. This is THE problem that faces everyone looking to modernize their systems. They have a mass of complex code, with inadequate interfaces.

In his testimony, Richard L. Ulmer of Unisys also gave some insight into this. He said "Unisys does not disclose all of the APIs in its proprietary server operating systems, but rather discloses only certain sets of APIs, such as those that relate to basic interoperability. Unisys restricts the exposure of its APIs because exposing an API for general use is a costly undertaking. Exposed APIs must first be "fireproofed," that is, enveloped in a protection scheme to make sure that their incorrect use will not cause system availability problems (i.e., system crashes). This "fireproofing" consumes time and resources." And as we all know, creating the level of fireproofing from existing systems is extraordinarily expensive, and under the covers, XP still has the good old Win32 API's that have never been properly fireproofed.

A key issue is also that of performance. Adding a Web services based API layer could likely have a noticeable performance impact. However, in domains where performance is critical, such as gaming, Microsoft has been able to deliver a high performance interface in the form of DirectX.

So Microsoft is almost certainly between a rock and a hard place. It would be almost impossible for them to comply with the requirement in its totality. Sure they could publish certain services, but in all probability it would be prohibitively expensive to "fireproof" all the necessary services to comply with the (NSPR).

But whilst we "understand" it doesn't necessarily help Microsoft's case. Because right now it looks like Microsoft is not eating its own dog food. It's response to pressure to open up its service API's is to circle the wagons, and say that Windows is entirely integrated. In contrast we reported a few weeks ago on SAP that with their service based technology are adopting a brave but necessary strategy that publishes open service interfaces between all of their product components.

Modularity impacts on business
This leads us to a very interesting conclusion that modularity is no longer just a technical issue. As we discussed in our report (4th April CBDi Newswire) SAP have a real business issue that is taking them down this track. They need to address their customer concerns for business flexibility, and the best way to achieve that is by enabling cloning and greater choice. In contrast the Microsoft operating system business needs are the complete opposite - they desperately need stability and trust. And whilst technically we can say it's possible to loose-couple many functions, their developers and particularly their QA folk will probably advise against this at this juncture, when resource investment is better directed at stabilizing core code.

I suspect that Bill Gates and his colleagues are making public pronouncements that they actually disagree with from a technical perspective. But from a business viewpoint they have little or no alternative. This is really very disappointing, because messages such as modularity is bad, doesn't work and so on, are the exact opposite of what we should be communicating. Interestingly, the .NET Framework does a very good job of supporting separation and modularity - in a couple of year's time when Microsoft are using the .NET Framework within their own products it might be a bit easier for them to comply with service oriented architectures.

It's time the software industry grew up
The software industry has to mature and the way forward is modular components offering services that are operated under formal, fireproof contracts and obligations. There's not another way that we as an industry will achieve the maturity of the electronic or automotive industries. And by the way in these industry sectors, cloned products are traded routinely because that's also a good way to achieve commodity level pricing, with revenues for the inventor protected through licensing patent and manufacturing rights to third parties. Experience tells us that monolithic systems will NEVER deliver the required degree of trust because testing them to destruction is literally impossible. Experience has taught us painfully that you can't rely on components just because you have tested them as an integrated product. You have to modularize, define the contracts and obligations, and loose couple them to reduce the complexity to increase the trust.

The real issue for Microsoft
Bottom line is that Microsoft is probably in pretty much the same situation as most other mature enterprises, both software industry and end user enterprises. They have a massive legacy code base that, just like any other software product, is subject to all the normal laws of setting concrete. It takes extraordinary effort and investment to make increasingly small improvements. So when we hear Microsoft managers defending their position, we interpret this first as "can't" rather than "won't?.

But Microsoft has to learn the lessons like everyone else. You CAN wrap existing code. You CAN expose good service based API's, and if this forces you to clean up certain aspects of the underlying code base, in order to be able to guarantee the service behavior, then this is an investment that will pay dividends in future. Once you have done this the API is transparent and that functionality can be replaced by either new code, or cloned product.

As we move into the service-based world, everyone needs to have a roadmap that goes something like this:

1. Decide on the services that need to be exposed.

2. Figure out the best way to deliver those services tactically from the existing code base, by wrapping, reengineering or replacing.

3. Determine the long-term strategy, which may be to stay with the tactical solution, reengineer or replace as part of the overall product investment plan.

Now our experience is that with very large systems this process is VERY hard and expensive. Without business justification, there's a huge temptation to say "too difficult, why bother." And of course in Microsoft's case, modularizing could be a big disincentive from a business perspective. However longer term as we move to a service based world, everyone has to address this issue, and for Microsoft, this has to be good for customers and their business.

We don't imagine for a minute that these problems will be addressed by legal pressure. However we do expect Microsoft to address these problems because they understand their responsibilities as software engineers to their customers, to eat their own dog food.

Feedback and comments are welcomed: david.sprott@cbdiforum.com

Copyright CBDi Forum Limited 2002. The CBDi Forum is an analysis firm and think tank, providing insight on component and web service technologies, processes and practices for the software industry and its customers. To register for the weekly newswire click here.

For More Information:

• Looking for shortcuts and helpful developer tips? Visit our Tip Exchange for time-saving XML and .NET tips.
• Visit our huge Best Web Links for Web Services for hand-picked resources by our editors.
• Discuss this article, voice your opinion or talk with your peers in our Discussion Forums.
• Visit Ask the Experts for Web services, SOAP, WSDL, XML, .NET, Java and EAI answers.

Digg This!     StumbleUpon     Del.icio.us

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary