Cart
[Home] [By Thread] [By Date] [Recent Entries]
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@s...] >>Sent: Thursday, May 01, 2003 6:39 PM >>To: Hunsberger, Peter >>Subject: RE: (data) medium is the message >> >> >>This is cool - did you mean to send it to the list? >> >> >>Peter.Hunsberger@s... (Hunsberger, Peter) writes: >> >> >>>Simon St.Laurent <simonstl@s...> writes: >>> >>> >>>>Peter.Hunsberger@s... (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> > >
|
