Re: Context and Domain

Hi Glen,

Glen B. Alleman wrote:

> Bill,

> 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?

> 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.

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
;-)

Best regards,
Bill



------------------------ 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/