How to pick Web tools
To talk to top-level government managers and chief information officers
nothing could seem to be less controversial than focusing on Internet/intranet
technologies and putting agency systems "on the Web."
Despite the interest, agencies are cautious to set foot on the World
Wide Web — and sometimes, when they do, they get run over.
Few people in government publicly advocate continuing to develop and
deploy older client/server applications in Visual Basic, Visual C++, PowerBuilder
and the like. Nevertheless, in one recent case, an agency was faced with
the prospect of spending additional tens of millions of dollars developing
and testing a client/server application, plus more than $20 million in new
desktops to run it. The alternative was to have the whole thing redone in
Java and deployed on the Web, at a much lower cost. The future of this system
is undecided because of factors that are mostly organizational and psychological,
not technical and financial.
This doesn't happen because government developers and managers aren't
smart or because they don't see benefits.
One reason these choices aren't easy is because government decision-makers
have been burned by Web systems. Some ran too slow, lacked good security
or were developed using superficial approaches that led to problems such
as inadequate data validation and database corruption. A simple architecture
that's sufficient for, say, an at-home Web page devoted to favorite music
albums is not sufficient for major agency systems — even if at first glance
it may be hard to see the difference. Failure of agency managers or contractor
programmers to understand those issues can lead to disaster.
Another problem is picking isolated tools — rather than entire toolsets — for Web development. Often, the primary factor in picking an application
server, for example, can turn out to be the persuasiveness and persistence
of a particular salesperson, favorable articles or reports, or a great price — not the role of the technology as part of a proven toolset within the
agency.
Agency managers first need to pick an integrated architecture and do
one or more projects to evaluate which tools work together best to accomplish
the kind of Web development they need.
The problem is compounded when the separately selected tools go separate
ways. The future of Netscape Communication Corp.'s Application Server is
uncertain as it gets merged with Sun Microsystems Inc.'s NetDynamics application
server. Symantec Corp. sold its Visual Cafe product to BEA Systems Inc.
Those kinds of changes can mean that the tools you picked a year ago may
wind up not being able to deliver the architecture you want to build today
or field tomorrow.
Web enablement is a must for agencies: The deployment and maintenance
savings are too great to be ignored. Understanding and solving these practical
problems can turn the rhetoric into reality and make Web systems the norm
for federal agencies.