[
Lists Home |
Date Index |
Thread Index
]
From: W. E. Perry [mailto:wperry@fiduciary.com]
"Bullard, Claude L (Len)" wrote:
>> Walter, as much as I respect you, this is like saying all rifles should be
>> handmade: in other words, no interchangeable parts.
>Surprisingly, perhaps, that is what I am saying. I am in the midst of writing a
>long and tiresome defense of my non-2PC, internetwork-native transaction model.
>I have been forced to realize that current distinctions between 'front office'
>and 'back office' are grounded entirely in what was automated when, and how.
Disaster Management e-Government initiative.
"interoperability agreements must be driven
by specific needs as they are identified at the interfaces among
active participants".
I agree in general. Ok, what about specification for interoperation
at the interfaces where the active participants include millions
of users and hundreds of thousands of applications? Seems to me
that a basic agreement they all share is a win. For XML, that
is the syntax first, then after that in ever smaller groups,
the infoset.
>The assembly-line workers, the processors of batch jobs, the makers of, as you
>say, "interchangeable parts" have been discriminated against as 'not craftsmen'
>from the moment their product was no longer handmade. The current hierarchy
>supposes that they are good at production but incapable of directing it
I can understand that for many human processes, but for interfaces among
computers, it doesn't make sense to me if applied without exception. A
common output model for markup systems is a pretty big win if enough people
agree to it.
We are in the throes of a process initiative here in which the first
decision was to divest all current stakeholders (people executing the current
processes) of any responsibility or input to the design work or the decisions
about changes in the processes, and more importantly, the tools we use
to maintain them. Here is a typical decision (I am not making this up):
"Only Vicki and I are empowered to enter new customers into the database
because if anyone can enter them, anyone can delete them."
"Ummm... that's ok until you and Vicki are gone at the same time and
we have some critical proposals to start on. Couldn't you trust us?"
"No. This is too important."
"Ok, but a better reason for what you want is the one we encounter
most often: different individuals starting independent work entering
different names for the same customer. That is better handled by
enabling the code to search and identify similar customers and offering
the user a list to choose from before they create a new customer."
"I can't manage that!"
"You don't have to; the code does."
"I can trust Vicki! Who knows what the code does..."
"Right...."
"Next item. All of these fields are now MANDATORY. We must track
who entered each item!"
"Ummm... there are relationships in the data that make it necessary
to cross-check some of these entries. If we make some of them
mandatory, that person and only that person can update. Is that
what you want?"
"Absolutely!"
"Ok, again, this makes the process a bit more rigid, and in some
cases, decisions that a person could make on their own will now
require them to consult with three other people every time."
"Tough! We have to make sure people are responsible."
"Ummm... they've done a pretty good job so far. It might
be better to go on trusting them."
"No! I need oversight and this tool is how I will get it!"
"So you don't trust the code to help them enter customer
names, but you are willing to incur higher costs just
so you can make sure who did what when?"
"You aren't being a positive contributor. I need positive
contributors!"
Silently ... "no you want power and you are too
insecure to trust anyone to do their job because they
might not support you given how little you know about
their jobs."
and so it goes... one stupid decision at a time all
the way to insolvency.
len
|
