Manage Learn to apply best practices and optimize your operations.

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

The Microsoft Antitrust trial could set precedents by accident, which will have adverse impacts on our use of Web services.

Guest Commentary
Breaking up (Microsoft) is hard to do - Modularity is a technical issue
by CBDi Forum Limited

Beyond the MSFT antitrust trial
Just in case you have been asleep for the past few years, the heart of the argument between the non-settling states and Microsoft is that the states want a modular Windows. The states accuse Microsoft of deliberately commingling (sic) Internet Explorer and Windows (operating system) to deter OEM's from installing a rival browser. The non settling states proposed remedies (NSPR) is that Microsoft must be required to offer its operating system on an unbundled basis. That Microsoft must not bind any middleware products to the operating system, unless an otherwise identical version of the OS that omits the bound item is available. Further, Microsoft must take all necessary steps to ensure that such an unbound version operates effectively and without degradation without the removed Microsoft middleware product.

Whilst there are many other recommendations from the non-settling states, such as the unbound product must be cheaper, available on time, offered on anon-discriminatory fashion etc, we need to examine this core issue of binding very carefully.

Integration a reasonable objection?
In his testimony, Bill Gates makes the point (reference 74/75) that "If OEMs and others were free to remove software code from the ten or more so-called "middleware" categories from Windows, all that ISVs could rely upon in developing new products would be the relatively small and ill-defined subset of Windows that remained appears that Windows itself could not rely upon any software code that fell into any of the ten or more "middleware" categories. That means that ...would expose Microsoft to contemptibility for engaging in the basic engineering practice of pursuing an integrated design, i.e., a design whereby one part of Windows would rely on capabilities provided by another part of Windows."

The issue to be considered is what do we mean when we use the term integrated? Long standing software engineering practice has been to modularize software products using technical criteria that reduce coupling and cohesion. More recently we have understood better the need for interfaces between components that formalize the dependencies and obligations. Today we understand that "integrated" systems are actually very bad news. They are hard to build, maintain and change and provide a poor foundation for delivering quality, trusted products. A sensible design heuristic is to use loose coupling techniques unless it is really very obvious that the (two) functions are part of a single unit of management that will be created, deployed, versioned and upgraded on a common basis.

Are operating systems different?
Bill Gates and his team understand these issues very well indeed. To their credit, they have actually led much of the ground breaking thinking in developing loose coupled (Web services) protocols and architectures. So is there possibly some difference between the issues and solutions that we should apply to the design of an operating system as opposed to a business application?

Well again in his testimony Bill Gates goes on to say (reference 90) that " would be utterly impractical for Microsoft to undertake the level of testing and problem solving described above if the NSPR were in place. As it stands today, Microsoft typically conducts testing against two primary versions of a new Windows desktop operating system, one of which (the "professional" version) is a superset of the other (the "home" version). Microsoft could not assure the level of quality that it provides today if we were required to test Windows on the assumption that OEMs or others might run Windows in any of 1,000 or more variations, with entire blocks of interdependent code removed altogether. Nor could we effectively diagnose and fix problems that arise when PCs are actually in use."

But why not formalize services?
But wait a minute; the whole idea of services is that the interface contains the contractual obligations between the components providing services. OK, SOAP and WSDL are quite basic in their coverage, but a whole stack of higher level abstraction protocols are currently in work which are addressing conversational choreography, transactional management, resource dependencies, QoS and so on. And, before you ask, there is widespread agreement that all these standards are equally applicable regardless of transport. In other words they are "service" standards, not specific to "Web" applications.

Now I am quite happy to accept that many operating system functions today will be more complex than perhaps even the future standards can comprehend. However that's the challenge of designing loose couplings, reducing the complexity of interactions, in order to establish federations of loosely coupled services, that minimize interdependency. Even more relevant, Microsoft is encouraging their customers to develop applications that are created from collections of services that are loosely coupled. And I quote verbatim from "Programs using this model will run across multiple Web sites, drawing on information and services from each of them, and combining and delivering them in customized form to any device." So what's good for the (ISV and end user) goose, should be good for the (Microsoft) gander! If Microsoft is recommending its customers engage in this form of loose collaboration we should expect them to do the same.

There seems no particular problem about loosely coupling for example a media player. The interface seems quite straightforward, and the obligations of provider and consumer no more complex than the provider and consumer of say a straightforward automated supply chain service interaction.

Again, Bill Gates and his folk understand these issues very well indeed. In briefings last year, the Microsoft developers were indeed discussing with us the ways they are using XML in their products, and focusing on creating exactly the levels of loose/tight coupling that you would expect.

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:

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:

This was last published in May 2002

Dig Deeper on Microservices pattern, platforms and frameworks



Find more PRO+ content and other member only offers, here.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.