[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
RE: [xml-dev] The Best Technologies Don't Win
- From: "Bullard, Claude L \(Len\)" <len.bullard@intergraph.com>
- To: "XML Developers List" <xml-dev@lists.xml.org>
- Date: Fri, 14 Jul 2006 09:48:54 -0500
It isn't so much that the best technologies don't win, it is that they
don't matter in an evolutionary game of selection. Remember, this isn't
a Darwinian model; it is a model of evolutionary stable strategy and in
that game, all that is required is that the dominating genetic base/rule
set/schema/architecture (pick one) cannot be replaced by a minority or
invader set. (This is a model that is more robust than a Nash
equilbrium because it doesn't rely on rational players.)
1. To dispute Rick Jeliffe a bit: there are applications that use the
exotic non-overlapping functionalities of XSD. The one that comes to
mind in the markets I see is GJXDM. Why? It needs a data dictionary
that is customized, not a single schema for one XML application. Why?
It must map to multiple overlapping local jurisdictions because the
Federal government does not have the power to mandate local system
reporting requirements except insofar as these report up the chain
through the State switches to Federal databases, and insofar as grant
money is predicated on conformance to Federal standards. These are very
loose functional relationships. I suspect that for many multi-million
dollar buys, this is true. When building a web site, the functional
relationships that dominate the requirements are different, but they
require many sales. The scaling qualities are quite different.
2. When picking among the alternatives, requirements dominate clever
code. A very real challenge to cat herding is knowing which cats are
doing something useful, say, can be sold in a contracting environment if
you sell big systems.
If the RFPs require an SOA that uses GJXDM-derived Reference Models to
derive local schemas (the problem is not XML or REST; the problem is
local jurisdictional choice over Federal models), then attempting to
apply REST/RELAX means losing the contract, not the technology. If one
bids 'strong-objects with data entities', one loses. It doesn't matter
that the code is clever; it matters that it doesn't map to the
requirements AS WRITTEN.
Web architecture isn't as important to big sales as selling applications
that use the Internet and a message switch. If you take the path of
architecture and open source, you have to map it to the requirements in
the customer's solicitation. Otherwise, you end up with $4 a share
stock (see Sun) because you lose too many big sales. The evolutionary
game is won in the Proposal response to the Request for Proposal, not
the coding shop.
Sad but so. The low cost transport model uses the bidding process, not
the design process. One can feed the other but that is very slow and
the trade IS time for energy. Until you shape the customer's
preferences, you lose.
Note carefully the function of abstract types over derived types. That
is the requirement for GJXDM and any other schema that has to map into
multiple local customizations.
len
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]