Standards turf wars scale back
In development organizations, the intensity of vendor competition tends to
politicize technology decisions. Some of us might recall that the choice between
COBOL and C wasn't just about the languages; it was also based on a hunch about
the future of mainframe or client/server computing. Likewise, 4GLs, including
Visual Basic and PowerBuilder, confronted us with lifestyle choices about whether
to accept new RAD techniques.
Today, choosing between Java and Microsoft technologies often equates to picking
sides in a gang war. And now that Microsoft's .NET Framework has largely closed
the technology gap with J2EE, the sociopolitical aspects of the choice have
become more pronounced.
Technology choices are rarely cut-and-dried, because the accompanying baggage
forces other decisions involving platform choice, the availability of packaged
apps or other tools, and which development methodologies to use. The quality
of the tool or the technology often winds up far down on the list of criteria.
Occasionally, vendors take the high road and agree to standards that supposedly
level the playing field, allowing technical folks to make technical decisions.
So, for example, when all major transaction databases supported SQL, we should
have been able to choose a database based on performance, scalability, or its
development or administration tools.
But it doesn't work that way. Vendors extend standards. With databases, each
vendor had its own SQL dialect and varying support from platform, app and tools
vendors. For de facto standards like J2EE -- which supposedly standardized component
architectures and interfaces with key infrastructure functions like messaging,
RPCs or load balancing - the choice of tool continued to have platform connotations
because some tools supported certain app servers, OSs and databases better than
Whether technology gets standardized comes down to one question: Can vendors
make money selling their own proprietary versions? For HTTP, HTML and newer
XML technologies, the answer is no.
There is another scenario. When the power lies elsewhere, technology vendors
can't call the shots. Digital ID is one example. When Microsoft first announced
Passport, a component of HailStorm (now .NET My Services), the idea was to develop
a technology for storing personal preferences and identifiers that would amount
to a de facto standard.
But if one vendor had a lock on personal ID technology, it could tax every
online transaction. That incensed companies concerned about Passport. Microsoft
has claimed 165 million Passport accountholders -- if you count every licensee
of the latest versions of Windows.
Predictably, the usual suspects -- Sun, Oracle and their friends -- responded
by forming what initially appeared to be a rival group, the Liberty Alliance.
Liberty's goal was to ensure that digital ID systems like Passport remained
interoperable, and that no single vendor would gain a chokehold on this critical
aspect of online commerce.
But Liberty isn't just any anti-Microsoft group. It has attracted household
names like American Express, MasterCard, GM, American Airlines and United Airlines,
who would use the system. Liberty also has technology players like HP, Nokia,
Sony, AOL and NTT DoCoMo. But merchants and bankers weren't willing to let technology
companies control the collection of customer information.
When this column went to press, Microsoft was already making positive noises
about Liberty, and by the time you read this, a formal hook-up or endorsement
will have probably become a done deal.
How does this pertain to development? The Liberty Alliance is the latest proof
that co-existence and federation will continue to be the rules for core app
development technologies. Development teams will continue to have choices, whether
that includes J2EE or .NET, digital ID systems, databases or even end-user client
platforms. There won't be any single standard, just groups of choices whose
technologies will connect. And decisions on technology will continue to involve
more than technology.
Tony Baer is principal with onStrategies, a New York-based consulting firm, and editor of Computer Finance, a monthly journal on IT economics. He can be reached via
e-mail at firstname.lastname@example.org.