[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: XML and integration (was RE: Various presentations)

• From: "Bullard, Claude L (Len)" <clbullar@i...>
• To: "Simon St.Laurent" <simonstl@s...>, XML-Dev Mailing list <xml-dev@x...>
• Date: Wed, 5 Jul 2000 12:14:16 -0500

-----Original Message-----
From: Simon St.Laurent [mailto:simonstl@s...]

>I agree that 'Best of Breed' can be dangerous, if tempting.  My point is
>just that XML reduces some of the costs of such development by simplifying
>integration and making that integration open enough that it's much easier
>to see what's happening when necessary.

It can.  Best of breed usually enters the picture during the Request for 
Proposal or Request for Information phase.  It is a consultant's best 
friend because it forces the vendor to prove individual components, or 
at least, attest formally to capabilities in difficult detail.  The 
consultant doesn't have to be that smart; just cut and paste standard 
questions.  The vendors have to provide very focused answers.  

On the other hand, there are useful strategies.  Many markets do not 
have existing shared data formats, and for these XML 
features can and are used to cut the Gordian knot on this by emphasizing 
import and export of data.  The creeper is that unless a public schema 
exists, the defacto vendor schema is the current definition.  No magic here,

but a lot of expense if all parties aren't aware of the issues of 
shoehorning a namespace.  Competency is always a premium because it 
is usually not the case that those signing contracts are aware of the 
depth of these issues.  The costs show up later and have to be eaten 
by one of the parties.  For that reason, many companies pay someone 
to read and re-read the instruments of negotiation looking for 
details such as universal assertions ("all", "in every case", 
"at the buyer's option", and so forth).  Picking apart what 
looks to be clear language is an art, why lawyers make big bucks, 
and why standards are often written or decimated by them.  Rick 
Jeliffe's comments on Dr Goldfarb's style of work are revelatory.  
He is extremely good at keeping bull at bay until bull becomes baby.  
It is one thing to posit an idea and have the freeware groups 
experiment.  It is quite another to have someone tell you they 
just bet a million dollars on one's caffeinated brain fart.

>Multi-vendor solutions are and have always been difficult - but
>single-vendor solutions come with their own pitfalls.

Yes, but they have a single administrative record of authority.  Part 
of the problem is in the writing of the other instruments, eg, the RFP, RFI,

final contract past BAFO, etc.  These must eventually resolve to the 
Work Breakdown Structure, Factory Acceptance Tests, etc.  Again,
structurally, 
XML can be very useful in designing these and making them viewable at 
each phase of the work processes, but the details are hard and must 
be accounted.  A single wall to wall vendor has a much better 
chance of getting this to work.  Again, it also depends on where the
acquired 
technology is in its own lifecycle.  Procuring advanced technology without 
using heavy lifting logistics support and analysis techniques is a 
risky proposition at best even if those are expensive techniques in 
their own right.   

>I really like the vision of happy dancing munchkins,

Thanks to Ted Turner for making a gift of the film without commercials 
over the holiday.... s'wonderful.

> but I agree that
>trying to create 'global solutions' is a black hole.  In general, I don't
>think that contradicts the overall claim of the presentation: XML may
>actually be more applicable and less dangerous for smaller projects than
>for larger ones.

Yes.  Even then, one should be alert to the requirements for 
acquiring known tested technology vs something really new and different. 
XML is still helpful but the costs are still considerable because 
the technology reduces the handwaving possible when acquiring a COTS 
system.  A room with a view costs more.

> If you sleep better when you have the keys, using XML to integrate
packages to
> your own requirements may be a very pleasant dream.

XML reduces complexity through lexical unification.  It reduces cost 
through tests that instrument the results.  This obtains clarity of 
goal and visibility of reproducible results.  A simpler design is 
possible overall but the appearance of simplification can get lost 
in emergence of a more complex system:  in English, you can do more 
with less so you do a lot more.  Restraint.

>That's why I tend to push small vendors toward providing glue for other
>people's projects rather than suggesting taking on the big vendors
>directly.  Sometimes that glue can be sculpted into something powerful, and
>the small vendor becomes big, but it doesn't always happen that way.

Yes.  It is easier for smaller firms to play because the cost of getting 
into the game is less and shared across all parties.  It was not that 
long ago (a decade) when just the parser cost 100k and a working 
browser with a stylesheet system could be as much as 50k a seat.  
Until that changed, markup was a no-go even for very large companies. 
As I've said before, the toys are much better now.

Thanks for sharing the presentations.  Good work.

len

***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@x...&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************

• Prev by Date: RE: XML-Schemas: purpose of elementFormDefault?
• Next by Date: Re: Passing data
• Previous by thread: Passing data
• Next by thread: URLs for presentations from XMLDevCon
• Index(es):
  • Date
  • Thread