[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Open Source XML Editor
- From: "Bullard, Claude L (Len)" <email@example.com>
- To: Marcus Carr <firstname.lastname@example.org>
- Date: Fri, 16 Feb 2001 08:54:38 -0600
Don't swim in quicksand. The flowing water and
the action of particle against particle pull you
under. Float and look for a branch or yell for help.
There is a difference between specialization of
human skills and decentralization of organizational
management, or specialization of roles individuals
play and decentralization of the parts they can play.
That difference IS competence. We can call it an
elite, but actually, it is pure skill and reliable,
Anyone out there in business taking on new XML
projects without XML experts, and XML experts
taking on projects without business understanding
are all screwing each other over. Be very clear
because once you set these beasties, these golems
in motion, they are very hard to stop and they
do a lot of damage to the villagers.
We are agreeing. Let's be sure this is understood.
Too many people, very important people, presented
XML, the semantic web, etc. as something that leads
to that one button push system of Johnny fame.
Rick, Simon, others are saying,
wait a minute, who needs agreements, we just need
to route messages (push communication down to
the network protocols and consider any standardization
above that local choice). This kind of message mapper
might range from an organizer (inbox style)
to a scheduler (Work breakdown structure type
of hierarchical message routing). I am saying,
fine for some kinds of work but really only
where the messages are understood a priori, the
communication protocol is known in advance. This
newtwork level approach avoids the enterprise
engineering problem the way plumbers avoid the
family bathing schedule. If you don't know how
much hot water you need in advance, tough. You
get the forty gallon water heater because they
have lots of those in stock.
Discoverable systems have APIs with registered
descriptions (advertised, public) for drilling
down into deeper descriptions. These descriptions
may be adjustable (terms and conditions) but the
process is to negotiate the schedule for the route.
This is the middle ground. We create a registry
for services. We describe the services so others
can choose the description that, in their opinion,
meets their requirements. They engage in a
negotiation (RFI, RFP, RFQ, BAFO, CONTRACT)
and then watch the process to ensure the terms
and conditions of the last piece (contract)
are met. This is ontological commitment and
behavioral testing. See XLang in BizTalk for
one current implementation for this kind of
system: choose interfaces and route by schedule.
Berners-Lee says "semantic web". Gates says
"frictionless economy". Sun says "the net effect".
These are all just cheerleading terminology to
get buy in prior to product. A lot of energy
gets expended but few know what the end game is.
The choices of the tools are critical, as you
say. Why? Because what you allude to is what
the old AI crowd used to call the competence
problem. It is an uneven quality among the
agents/performers/employees. The use of generic
tools (as Rick points out) is applied. But how?
I, perhaps others, prefer markup because a competent
player can share that competence by adjusting that
tool, tuning it to make a process tight or loose
depending on LOCAL competence values. Even the
interface between two or more companies is inherently
local. But the CALS systems that worked well
were sustained by the enterprise engineers. Not
just MIS or IT, but people with a good overview
of the tech and the business. If the tools they
use, or the requirements get too complex, they
are in quicksand. The water is flowing, the particles
are bumping, and they thrash until they disappear.
In CALS, we started out with a simple endgame:
digital documentation. We discovered as we
tried to achieve it that certain islands of
complex knots of process (graphic to text and back)
made it difficult and expensive to get to the endgame.
As we untangled each knot, we found very long strands
of entangled types of information, some because
the information itself was complex, and some because
the tool strategy made it impossible to separate
the strands, to identify them or isolate them
from the products that wove them together.
In still other cases, we found that the personnel
who understood these tools had come to a point
where they considered change unendurable or
This was for single companies executing single
projects with a few subs and one customer.
Now we tell the world that we can sustain a
semantic web, a web in which we can describe
information to sufficient detail and by such
means as machine processing can be relied upon
to run it while our "needy employees" do other things.
<rant>Those Microsoft commercials suck, Mr. Gates. Do
something about your ad agency.</rant> It may be
sustainable; it may not be endurable. We have to
work that out.
We understand the use of standard document types
and business protocols. We understand discoverable
interfaces and message routing. UDDI will work
fine and then each organization gets to choose
the document types ((ebXML, roll-your-own)(choose one)).
But ultimately the problem of using the technology
is the willingness of those who must choose and
those who must use to learn the technology. We can make the
type definitions/schemas as tight or loose as
they want and even if some have some points of
view they want to enforce (as someone said,
XML writers writing about XML), ultimately the
customer has to choose based on their knowledge
or lack of knowledge of their own business/art/application
as it is affected by this technology.
That choice is the business semantic. The elite provides
the means to choose the means. That's us. We
do that by analysing the local conditions, tuning
the technology, and when we get into quicksand,
get the locals to throw us a rope.
Or we disappear.
Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h
From: Marcus Carr [mailto:email@example.com]
I don't doubt that you are able to relate this to a particular organisation
circumstance that you have in mind, but for the life of me I can't draw a
between this and an operating methodology. If this can't be standardised -
is, if I have to be able to think like you - then the middle ground solution
relies on elites too.
I feel as though I'm swimming in quicksand.