RE: Context and Domain
"Alleman, Glen B." <[email protected]> Wed, 8 Jan 2003 09:26:04 -0700
| Newsgroups | gmane.comp.programming.extreme-customering |
|---|---|
| Message-ID | <[email protected]> |
Bill, > -----Original Message----- > From: Bill Walton > > > Thanks for focusing the "context and domain" discussion. > > You're welcome. Thanks for doggin' it. It's a topic that's interested me > for a long time. It looks to me like you're OK, at least as a starting > point, with the two axes I proposed. I'm kind of anal about making sure > we're using the same words to mean the same thing, so let's see... ;-) > > > Although I would say that many of the practices of agile > > development are generic - "continuous testing" - they > > need a context and domain to be useful. Continuous > > testing in a web app powered by Java is much different > > than continuous testing in a satellite on board navigation > > system and different again in a PeopleSoft asset > > management system. > > Here I think you're talking primarily about different domains. on board > nav > systems and asset management systems are, to me, clearly different > instances > of what I would call domains. I guess the word "domain" makes me think > "domain knowledge." Is that how you're thinking about it? You also > address > something I left out in my initial stab at this: platform. That raises a > question that I hadn't / haven't figured out yet. I'll bring it up below. > > > The challenge is to apply the agile practices "starting" > > with the context and domain rather than come with > > the practices and then discover resistance to the > > practices because the context and domain have > > boundaries that have been violated. > > When you say "boundaries" I think "constraints" and read "context" which I > think is seperable from "domain." What say you? [>] Yes boundaries can be constraints. We tend to see the world through interface boundaries, both physical and logical. So might say this is restricting but it is how it is defined here. The point being that the physical and cultural environment defines the interfaces and boundaries. We have some visitors today and the "protocol" for getting them into certain places is well defined and controlled. That same "culture" also defines how the software is seen. > > If the B and C-Levels are to become supportive > > starting with the existing environment is necessary. > > Couldn't agree more. It's about credibility, IME. If I'm going to pay > someone to solve a problem for me, the first thing they have to do is show > me they understand the problem space. [>] There is a paper in the Journal AIS "Mimetic Isomorphism and Technology Evaluation, Does Imitation Transcend Judgment?" about how managers (CTO's and CIO's mostly) make selections. This is a very useful view of how methods are selected as well. > On the topic of platform, the question you've raised in my mind is this. > Is > platform part of domain, part of context, or a third axis that needs to be > considered? > > On one hand, I could see it as part of domain. I could characterize Java > vs > C# vs Peoplesoft as different areas of technical domain knowledge. > > On the other hand, each of these different platforms comes with their own > set of constraints in terms of implementation options. Not that you > *couldn't* make the same approach work with each. Just that, IME, a > team's > technical approach will differ somewhat based on the tool set they're > using. > So if I see platform in these terms, I more easily see it as part of > "context" than "domain." > > At the same time, I can see it more suitably characterized as a third axis > of the problem space, seperate from Domain and Context. To me, Domain and > Context are both driven / defined by business-side characteristics. > Platform seems, from my thinking above, to driven / defined by > technical-side characteristics. Flipping again, choice of platform can > definitely be a business-side decision. Hmm... how 'bout some help here > ;-) [>] The problem space could definitely be another, since ERP in finance is much different than petrochem. A method used to manage a SAP integration at a petrochem firm is much different than a bank. > Best regards, > Bill [>]Glen B. Alleman ------------------------ Yahoo! Groups Sponsor ---------------------~--> Flexible Keyboard is the ideal accessory for PDA users that are on the move. http://us.click.yahoo.com/dCBVZC/WnCFAA/xGHJAA/NhFolB/TM ---------------------------------------------------------------------~-> To unsubscribe from this group, send an email to: extremecustomering-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/