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