TechWatch: Software Integration is Tough and Adds a Wrinkle to the Microsoft Case

It seems that some comments about the Microsoft anti-trust case are called for, especially in a journal that considers issues of fairness and justice in a business world supercharged with information technology. There are a couple of reasons why I have avoided the issue so far.

First, because I know a bit about technology, it is difficult for me to make the sweeping simplifications I often read in the press. I appreciate the quote attributed to Albert Einstein: “We should make things as simple as possible, but no simpler.” There are some very complex and technical issues at the heart of this case.

Second, this is a highly emotional issue. I have witnessed very intelligent people come close to blows in efforts to make their case. The technology community has many Microsoft supporters, and many detractors. It is hard to be heard in a climate where there is such a polarization of passion.

I believe that there are at least two sides to this complex issue, maybe ten sides. I will comment on only one aspect of this case, and to do this I need to take a detour through a discussion of an important software technology issue. I think the detour brings value in its own right, and I will come back to how I think this issue relates to the Microsoft case at the end.

For all of the research into how to build software better, more reliably, faster, etc., there has been remarkably little progress. Early years of research kept promising the “silver bullet,” but now there is almost universal agreement that the problem is hard and that there is no silver bullet.

No Silver Bullet

Software needs to be correct, without unintended consequences, which is hard enough. But it also needs to be robust. Changes are inevitable, whether from user requirements, underlying technology, or simply poorly appreciated assumptions. Thus software must be flexible so that these changes can be incorporated with appropriate effort. Too often, software is brittle: a small change means you might as well start over.

Another issue in building good software is assuring acceptable performance. A perfect word processor which took an hour to spell-check a page would be unacceptable.

Most now believe that the best way to build a large complex software system is to build it in a modular fashion. That is, rather than one large, monolithic software solution for a business or scientific problem, the solution is built in pieces which are then “glued” together. One key to this success is to contain changes in one module from affecting others, and object oriented technology, or at least object oriented thinking, has been significant here. A second key is to create the “glue” between the modules so that they “snap” together as easily as possible. This is where “middleware” technology contributes. A third key is to have high quality modules.

There does remain a tradeoff, however. A more modular solution with multiple interfaces may have poorer performance than one tightly integrated.

Using the principle of leverage, most companies have concluded they are better off buying rather than building software. This is often called a “COTS” strategy, standing for Commercial Off The Shelf software. The belief is that for many applications in business (a finance system, a human resource system, a procurement system, for example) or in scientific analysis (structural analysis and design, for example) buying a standard package from a third party vendor will enable business savings compared with building the software themselves, because they can take advantage of common development.

If anything would seem like a silver bullet in software it is this. Without hiring software people, or paying to keep the software current, the company can benefit from very complex tools for a fraction of the cost to develop them. In fact, there is considerable benefit from this strategy. Since the payroll problem in company A is similar to that of company B, why not simply buy a common solution?

It is not as simple as it sounds. In a longer paper, I have identified eight major issues that need to be considered as part of a COTS strategy. I will sketch two of them that will take us back to the Microsoft discussion.

First, when you purchase a piece of software to support a business process, it contains embedded business rules. Since the software is owned by someone else, you cannot change it. So, we need to use the business rules contained in the package. For example, I probably only use about 2% of the features in my word processor. I can’t delete the ones I don’t want, even the annoying features that try to help me in ways I don’t want to be helped. I also can’t add features. In both cases, I can communicate with the vendor, but that’s about it.
This tradeoff is not difficult to live with in a word processor, but is more difficult in a complex application such as a human resources package. I may want to offer employees a more flexible schedule than the package allows. I can either build a separate module which I add on and maintain, or not offer the schedule.

So, unless there is very strong justification, accepting the business rules of the software is the right compromise. Insisting on imposing your own business rules on a package intended to do something else can be a very costly exercise. In “Putting the Enterprise into the Enterprise System,” Harvard Business Review, August 1998, Thomas Davenport relates the case of the company that went out of business trying to force a purchased software solution to conform to internal business rules.

Second, often the COTS product deals with only a part of the problem we are trying to address. To create a solution we must then integrate multiple packages to operate as one system.
For example, a program manager wants to price a proposal, and selects the people to work on the project, the amount of time they need to work, and other required resources. The project manager needs salaries from the human resources package and estimating tools from the financial package, so the system solution requires integration of both.

The challenge in creating solutions from multiple packages is partly solved with middleware tools, and certainly involves integrating the processes through the data rather than “gluing” the applications together. But, the vendors do not coordinate their version releases with each other, nor with the users who have built patches around a system. Thus, when a new version comes out, there is a significant problem in validating the total system solution.

Some have proposed solving this problem by simply not upgrading either hardware or software modules for a period of time. The rapid changes in technology and user requirements, compounded by the practice of doing “bug fixes” in the next release, make this strategy unrealistic.

User support of such integrated systems is compounded by finger-pointing — which package caused the problem? Security is a system issue. The user doesn’t need security in individual components but in the whole system.

Some will argue that these issues go away when standards are adhered to in an “open system.” This is indeed a help, but doesn’t solve the problem. Each vendor has a marketing department which leads to new features in each product offering. Standards are developed looking backwards, and new features still have to be dealt with.

This brings me back to the Microsoft discussion. The technology community would like to keep things as open as possible so that multiple vendors can compete for pieces of the solution, leaving the integration to the users. In many situations this is the best for the user as well as the technology community.

However, there are a large number of cases where the user would rather not deal with the integration issues. The vendor that supplies the more complete solution, tightly integrated for performance, is the one that meets the user needs. For example, a browser integrated in the operating system means there is one less integration task that the user has to worry about, and better performance can be expected.

In most of the press related to the Microsoft case, competitiveness in the technology community has been the focus. Bundling prevents competition, but is often exactly what the user community wants. Almost no one has been talking about competitiveness, or loss thereof, in the user community. This is why the technology community exists.

As an interesting side note, this philosophy appears to be a practice within Microsoft as well. Most of Microsoft’s internal processes are built around a solution from SAP, which provides a large integrated solution package for internal resource management.

Even human resources solutions are accomplished with SAP. Since there are better known packages for human resource systems, I asked Microsoft’s internal program manager why they weren’t using one of them. The answer was straightforward (without any reference to the legal case) that the loss of capability was preferable to the cost of integration. They had decided to live with the business rules of SAP and give up “better” features from other packages.

The theme developed here doesn’t lessen allegations that Microsoft bullies competitors — or the concern raised by Lew Platt in our April issue over Microsoft not offering ethics training (see side bar) — or the very real technical concern that a tightly integrated solution may die of its own weight as it is migrated toward the future. The sheer size of Windows 2000 raises this concern. Neither does this point lessen the concern that users will be unable to take advantage of new technology when they use closed, proprietary systems.

My point is simply this: often it is advantageous to the user to have a solution rather than a bucket of parts. Bundling offers advantages to the user, who should not be forgotten in the dispute between the technology parts makers.

Postscript: We requested a response from Microsoft to the statement from Lew Platt in the April issue of Ethix: “They’re (Microsoft) proud of the fact that they do no ethics training, or any other training in terms of standards of business conduct…I’m not sure that’s smart.”
Microsoft chose not to respond directly to this statement, but did send us the following:
Here at Microsoft we believe that a key to our future success are the values by which we live, every day, as a company. The values are a set of principles which have evolved since our founding, and which capture the spirit, philosophy and day-to-day business practices of our company. These company principles underscore our relationships with customers, partners and employees. To make sure those principles are spread though the company Microsoft has an intensive management training course that incorporates and teaches these key values. “Doing Leadership at Microsoft” is our internal development training program that provides a framework for thinking about leadership, and a model for ethical behavior, that directly promotes leading with integrity.

Dan Leach
Microsoft Corporate PR


Al Erisman is executive editor of Ethix, which he co-founded in 1998.
He spent 32 years at The Boeing Company, the last 11 as director of technology.
He was selected as a senior technical fellow of The Boeing Company in 1990,
and received his Ph.D. in applied mathematics from Iowa State University.