How to Live With Standards (When You Can't Live Without Them)

Everybody loves standards. That is probably why there are so many of them. Aside from meeting the need for standards for the most minute bit of software, hardware, firmware and so on, human ingenuity has gone on to invent multiple standards for almost every last thing we do.

Everybody loves standards. That is probably why there are so many of them.

Aside from meeting the need for standards for the most minute bit of software,

hardware, firmware and so on, human ingenuity has gone on to invent multiple

standards for almost every last thing we do.

"Information technology standards" is close to being an oxymoron. At

least in these early stages of IT growth (and I expect it to remain in the

early stages for my lifetime), standards are an inhibitor and an enabler

of creativity.

The Microsoft Corp. legal case is the icon of this dilemma. The relatively

stable (monopolistic?) platform of Windows has allowed innumerable software

developers to create and market applications to a world of office and home

users. Consumers can buy software and have a reasonable chance of getting

it to work on their platforms without taking software engineering courses.

On the other hand, software and device creators who have other (better?)

ideas for operating systems and applications experience immense difficulty

reaching the marketplace gated by consumers' limited PC choices.

Even ignoring what the marketplace should be, just coping with the myriad

choices is a nightmare for organizations of every size. All budgets, no

matter how large, are constrained. And, no matter how big the staff, it's

never enough to support all the platforms, software and applications that

offer useful functionality.

Inevitably, the organization — usually in the guise of the villainous

IT department — must say no to its users. "That application shown at the

conference cannot be brought in-house." Or, "That handheld device used by

another company cannot be used here." Only so many choices can be made,

and those are called standards.

The evil of standards is their necessity and their fragility. Picking

the standardized operating system, the standard PC configuration, the corporate

enterprise resource planning system, takes precious resources and months

(or years) of investigation. The choices (standards) must be sold on the

basis of their cost savings and simplification of the computing environment.

And woe betide the IT director who promises that standards will reduce

the necessity for users to change or upgrade their systems. Because no sooner

is a set of standards in place than one vendor, or several, will "update"

their product.

If we cannot live without standards, how can we live with them? Some

organizations have tried to show flexibility by naming two or three brands

within each category — such as Microsoft Word and Corel Corp.'s WordPerfect

word processing packages. However, since software suites have increased

in popularity, this strategy is fading because it bogs down when customers

want to take advantage of the suite integration.

Also, support costs are almost doubled because few technical staff members

can master all the details of more than one suite, not to mention the intricacies

of sharing files among suites.

Many organizations are moving painfully toward the single-standard

approach, especially for desktop hardware and software. As the capabilities

of hardware platforms and associated operating systems deliver increasingly

similar functionality, the benefits from multiple standards fall below the

cost of maintaining multiple environments.

Any attempt to set standards for rapidly developing new software, especially

for World Wide Web development and deployment, meets with considerable difficulty.

We want to apply the disciplines we know will save money, yet commonality

is far from being achieved in those new environments.

There's a treacherous likelihood of choosing something that might turn

into a backwater, analogous to picking Wang Global word processing a couple

of decades ago — great in its time, but not the market winner in the end.

On the other hand, we also have far too much experience with the anarchy

of letting too many people select their tools based on short-term application

development needs.

The only answer I can recommend is two-fold: Keep abreast of market

changes, and educate staff members and users regarding the benefits and

pitfalls of standards.

Avoid creating false expectations while selling standardization. Cooperation

in negotiating rapid change is probably the best way of minimizing the pain

and maximizing the gain.

— Judith Umbach is executive director for the Year 2000 at Calgary, Alberta,

Canada. She can be reached at jumbach@home.com.

NEXT STORY: VA's time line