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/