OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] Hobbsian processes

[ Lists Home | Date Index | Thread Index ]

It isn't just money.  Some agencies have duties 
to perform that would work much better if they had 
standard data structures.  DoD and Public Safety 
are two examples.   It has taken years and years 
of work to get the DoD entities to adopt common 
data standards and I don't know what the outcome 
of that has been not being a contractor there today.

In public safety, recent events have shown just how 
dire the need is for the systems to communicate 
in real time (simple radio communications and 
other wireless devices), but when you step back 
to look at the big picture, the need for sharing 
information in less than near real time is even 
greater.  But the same slow moving, let's do it 
top down processes that bedeviled CALS are settling 
in there as the marketing tiger teams sit back 
on their butts waiting for direction from a slow 
forming mega-bureaucracy in the Beltway.  Just 
as CALS managed to waste billions down the 
rat holes of consultancies and committee lead 
conferences, the Homeland Defense teams lead 
by retired brass will do the same.

Meanwhile, the war goes on.

What is required is industry leadership in 
the industries that can make a difference.  
It has to be recognized plainly and clearly 
and without refutation or lawyerly marketing 
wonkspeak just who's job it is to get the 
kinds of secure interoperable communication 
systems in place.  It is the responsibility 
of the CEOs and CIOs of each of these companies 
to go to their development staffs and ask for 
possible approaches, to take these results 
and prototype, then present these to the 
customers, not to the brass in bhe beltway.

We have jobs to do.  We should be doing them 
and not waiting for the brass to move.  Yes, 
that has risks.  Tell me what doesn't.

The problems of interagency communications are 
massive, but parts of it are just local illusions, 
and that is the problem with Walter's approach. 
We shouldn't be calling local illusions software 
expertise and trusting the machine point of view.

We have over 50 pages of configuation options 
in some of our applications to make it possible 
to take semi-shrinkware and field it.  Our high costs 
are not the software development; they are implementation 
in local agency sites.  Some problems are real; the 
scaling factors of workflow between very large and 
very small agencies are real.  But the data model, 
the labels, are remarkably consistent in what they 
describe if not in what they call that.   

These agencies spend unreal amounts of money 
and time on import/export in comma-delimited 
ASCII to hook up edge systems (say fingerprint 
ident) to their records management systems, and 
more so that the local sheriff and the local 
police can talk to the local jail.   We 
make decent money on intellectual sloth and 
not-invented-here.   Some try to enter our 
business field and lose their shirts because 
they assume naively that comp-sci is an adequate 
background, but it isn't.   It takes SMEs to sort 
out the issues, but believe me, most of the time, 
we are simply making a local mayor or police chief 
happy that his process as he defines it is 
carried out in accordance with his wishes so he 
can go to his mayor or city council to demonstrate 
the success of his plan.

Meanwhile, the war goes on.

The industry has to lead the customer.  One 
cannot abdicate responsibility for the need 
to create **at a bare minimum** some data standards. 
I understand massive backplane translation. 
We do it every day.  It wastes money, and that 
isn't a good thing except that we get the 
money.  But look at the recent kidnappings, 
look at the serial killers, look at the rise 
of terrorists attempting to enter your borders 
as visa'd students and tell me that you really 
think local expertise in the form of the 
program is the answer to networked communications. 

Code it as you will. Call it as agreed upon. 
It works better.  Market be dammed.

len


From: Paul Prescod [mailto:paul@prescod.net]

If you don't even *define* the schema then there is a danger that the
market won't even come into existence. Look at all of the companies
taking a wait-and-see attitude towards web services while they "wait for
standards to solidify." Once the schema exists then all of the usual
market pressures will work out the way they did before there was XML.
Sometimes the market leader defines the defacto profile. Sometimes they
follow the spec closely. Sometimes conformance testing shames them into
being strict. Sometimes they have a "strict" or "loose" flag. etc. etc.




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS