September 16, 1996
Who Really Benefits from Component Software?
By Bob O'Donnell
If you've even glanced at a copy of the print version of InfoWorld over the last year,
you know that the software industry is headed full-steam into the world of components.
There's disagreement over which component model is best and which mechanisms for bringing
together the various components work most efficiently, but most everyone seems entranced
by the notion of reusable software objects that can be easily upgraded and interchanged.
Add the Internet into the equation - offering relatively seamless access to a never-ending
network of available components - and you have what many consider to be the makings of an
amazing future.
I have to admit that I don't get it. I understand the appeal of the concept of
being able to piece together documents using small applications from a variety of
different vendors, providing best of breed functionality in a very specific area. But I
think the reality of putting all this together is going to be a nightmare for IS managers
and end-users.
First of all, component software adds a level of complexity and confusion to desktop
computer setup, configuration, and operation. For example, how do I, as an end-user, know
I have all the components I need to get the functions I want? At least with a monolithic
application I know I am getting the spell checker, grammar checker, table creator, and
text editor all in one word processing package. I also don't have to bother with setup and
configuration issues - most users expect to install a program with one click and start it
up with a double-click. Component software, by its very nature, will require more effort
on the typical user's part.
In large companies, IS departments can take on the job of piecing together a suite of
components to provide the functions needed by their end-users, but how is this much
different from simply installing an office suite from a single vendor?
Component supporters go on to say that you're supposed to be able to mix and match them
for different requirements and needs. One group of users in an organization might need a
sophisticated text-editing component and a relatively simple spreadsheet, whereas others
would need the opposite, a third group might need the full-featured versions of both, and
a fourth could need the simplest of each. Who's going to test all these configurations?
And most important of all, how do we know they're even going to work together?
Component software devotees will argue that components will need to match rigorous
interoperability and compatibility standards, but do you really think that's going to
happen? The software industry has had a slew of established standards over the years in
the form of operating system APIs. Yet it's relatively commonplace for two applications
written for Windows 95 or the MacOS --or any other operating system -- to fail to work
with each other. Either the machine they are running on won't start, or one of the apps
won't run. And that's with two monolithic apps. What's it going to be like when you're
dealing with twenty or thirty different components? Of course, I haven't even gotten into
the possible problems with multiple competing object standards....
As if that's not bad enough, there's the issue of support. Even if we make the leap of
faith that most of the objects are interoperable, what happens when there are problems:
Whom do I call if the text-editing engine causes my spreadsheet component to crash inside
my document container application? Help desk and tech support staffs have a hard enough
time reconciling problems between operating systems, applications, and networking gear.
How are they possibly going to be able to track all the permutations available with
components?
And who owns the file format specs? How do I know that documents created with my set of
software components will be readable by your set of components? What will get lost in the
translation? And finally, how many people really create compound documents on a regular
basis? One of the arguments for object-oriented components is that they allow you to
forget about the notion of word processors and spreadsheets and concentrate on creating
documents containing all kinds of different information. I don't know about you, but I
very rarely need to put together compound documents, and when I do, cutting and pasting
works just fine. The only people I know who create sophisticated documents on a regular
basis are designers and artists - a very small group with a very refined skill set.
One of the arguments made on behalf of component software is that it could break up
Microsoft's monopoly on desktop applications and give people the freedom to choose. But a
preconfigured set of components doesn't really offer that much more freedom to end-users.
So, why would anyone want to get involved with component software? Well, it's a clear
win for the software vendors. By breaking up their monolithic apps into smaller chunks,
they can improve the speed and quality of the development process by having separate
groups of programmers work on more manageable chunks of code. The result should be
better-written, less buggy software, which is clearly a benefit to end-users and IS
departments alike. The real reward for vendors, however, will be monetary. Instead of
hitting us up for a $99 upgrade to their monolithic apps every 12 to 18 months, my guess
is we'll start getting $25 to $30 component upgrades every two to three months. It might
be easier to take in smaller doses, but it's bound to cost us more in the end.
There's no question that many stand-alone applications (and operating systems) have
reached the point where something needed to happen to make their continued development
feasible and, in many ways, component software is a logical step forward. But the harsh
reality is that we'll probably all still be using pre-packaged, single-vendor office
suites made up of more components in two to three years because the component software
free-for-all that many proponents of the technology envision is a recipe for sure
disaster.
©
Copyright 1996, by InfoWorld Publishing Corp., a
subsidiary of IDG Communications, Inc. Reprinted from InfoWorld,
155 Bovet Road, San Mateo, CA 94402. Further reproduction is prohibited.
