[
Lists Home |
Date Index |
Thread Index
]
I'm in violent agreement with the thread at this point.
Business people want to think in terms of whatever is "intuitive,"
and that usually means there is a need for intermediaries to
construct at least part of a solution, or be a sounding board.
BTW, I think UML's visualization of use-cases trivializes the
concept and execution there-of. I'm more impressed with the
effectiveness of XPers' user stories and Cockburn's approaches
using structured narratives.
(I still don't get the use-case for having the Reply-to go to an individual.)
Hunsberger, Peter wrote:
> Arg, bitten once again. Yes, this was meant for public consumption...
>
> Peter Hunsberger
>
>
>
>>-----Original Message-----
>>From: Simon St.Laurent [mailto:simonstl@simonstl.com]
>>Sent: Thursday, May 01, 2003 6:39 PM
>>To: Hunsberger, Peter
>>Subject: RE: [xml-dev] (data) medium is the message
>>
>>
>>This is cool - did you mean to send it to the list?
>>
>>
>>Peter.Hunsberger@stjude.org (Hunsberger, Peter) writes:
>>
>>
>>>Simon St.Laurent <simonstl@simonstl.com> writes:
>>>
>>>
>>>>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're more at "we need some agreement on the use case" stage
>>
>>of things.
>>
>>>Sure, when arguing use cases one does end up arguing
>>
>>semantics but only
>>
>>>to make sure you're all actually working on the same use
>>
>>case. Again,
>>
>>>I'm not
>>>a huge fan of UML and less so of RUP but I do like having a use case
>>>hanging
>>>around for everyone to aim at.
>>>
>>><snip/>
>>>
>>>>>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.
>>>
>>>And if the business was big your boss probably handed you a SOP
>>>manual...
>>>
>>><big snip/>
>>>
>>>>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,
>>>
>>>Having business processes in place that work might be boring
>>
>>but that's
>>
>>>what's needed for the most part?
>>>
>>>
>>>>and top-down
>>>>development requires trusting the top. I don't trust the
>>>>perspective that people at the top or looking from the
>>>>top of a problem seem to share; I never have.
>>>
>>>Well if the secretaries are the ones with the knowledge
>>
>>that's who you
>>
>>>talk
>>>to get your business rules... Let me be clear, when I say
>>
>>we document
>>
>>>business rules I don't mean the developers. I mean the business
>>>analysts
>>>(who wouldn't know a DTD from a XSD at the best of times)
>>
>>and the end
>>
>>>users
>>>(who might know how to use Excel and maybe Brio). The analysts are
>>
>>also
>>
>>>the
>>>people who create and review the metadata. The developers tweak the
>>>metadata to make it consumable by our applications, but that's more
>>>because the current state of the art (the mapping tools)
>>
>>then anything
>>
>>>else...
>>>
>>>
>>>>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.
>>>
>>>Absolutely, that's why I say the end user needs Frank the IT
>>
>>guys help
>>
>>>to
>>>create the schema, not the other way around...
>>>
>>
>>--
>>Simon St.Laurent
>>Ring around the content, a pocket full of brackets
>>Errors, errors, all fall down!
>>http://simonstl.com -- http://monasticxml.org
>>
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
>
>
|
