[
Lists Home |
Date Index |
Thread Index
]
Peter.Hunsberger@stjude.org (Hunsberger, Peter) writes:
>Although I can understand this vision and even buy into some of it I
>wonder how close it is?
It's not close. The vast majority of people are going down the "we need
prior agreement on all semantics" path. I translate that as "we need
information totalitarianism", but it's painfully common.
> We spend a lot of time here trying to get
>agreement on what the business rules are around a given piece of
>information. We iterate over those definitions until we think we've
>got them right and we formally document everything. We then
>automatically generate metadata from the business rules documentation.
> From the metadata we generate schema. What we don't do is arrive at
>these business rules by bouncing data around until we get it right and
>frankly I don't see how we could.
"Bouncing data around" is, of course, how business rules emerged in the
human world. When I was a sales assistant, if I got a fax I didn't
understand, I took it to my boss or to the warehouse or whoever I needed
to talk with about how to handle it, and learned from that experience.
>One might be tempted to say that's
>because we're doing research and the common ground has yet to be
>invented. I don't think that's the case; surgery or chemotherapy might
>have lots of variations, but at the level we're documenting them it's
>basically things like is it a date or a datetime?, use a Snomed code to
>capture the procedure, and a Snomed code to capture the location,
>etc...
I think the basic problem comes from where this all started. Computers
used to be incredibly expensive creatures, and the rule has always been
to give the computer problems in terms that it understands. Human
intervention, except for explicitly interactive tasks, has pretty
consistently been shunned. In general, the idea has been to put as much
into the computer as possible up front and tinker with it as little as
possible.
(This of course feeds into a business case of managers controlling
information flows and using computers to squeeze efficiencies out of
them which aren't possible with salary and benefit-demanding humans. It
sells very well - the only question is how well it works over time.)
>I guess I don't buy into any vision of applications being built bottom
>up by playing with the data. Maybe some day lots of little data
>handling objects will somehow self assemble themselves into
>applications, but that's when I stop and say not time soon.... I'm
>still a top down kind of guy.
And I've argued for years that secretaries know more about office
information than anyone in the company, so I'm obviously coming from a
different perspective. I've actually done this myself, building a
database that did most of my job's menial tasks with minimal
intervention, so I know it's quite possible, but the social milieu isn't
there at present.
>Maybe Joe user can do top down
>development, but that means stepping back and understanding the big
>picture and that's not something that everyone can do. So I think for
>the next couple of years there's still going to be a need for Frank the
>IT guy, or at least Frank the consultant who helps you build some
>schema.
For a long time, sure. But it's time to start exercising some
imagination and asking what else we can do. Trading pre-defined data is
boring, to put it mildly, and top-down development requires trusting the
top. I don't trust the perspective that people at the the top or
looking from the top of a problem seem to share; I never have.
Frank the IT guy's job is safe. I'd just like to develop systems that
include people beyond Frank the IT guy, people who may not know a lot
about XSLT or C, but do know about the actual subject matter they're
working with.
--
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com -- http://monasticxml.org
|
