Loading ...
Sorry, an error occurred while loading the content.
 

Question about XP and Architecture

Expand Messages
  • Charlie Alfred
    Hi, I sent the message below to Kent Beck, in response to a debate between he and Barry Boehm in the June 2003 issue of IEEE Software. Kent thought it might
    Message 1 of 1 , Jul 3, 2003
      Hi,

      I sent the message below to Kent Beck, in response to a debate between he
      and Barry Boehm in the June 2003 issue of IEEE Software. Kent thought
      it might be interesting to post the message in the ExtremeProgramming
      Yahoo Group. I agree, so the email thread with my original message
      and Kent's reply is provided below.

      On the whole, I'm very interested in the XP approach. I've seen too many
      projects where the "collect all the requirements up front" approach was
      doomed from the start, because:

      a. the requirements aren't all knowable at that point,
      b. the requirements change significantly over the project's lifetime,
      c. the people gathering the requirements might not know enough about the
      problem space early in the process to accurately capture them, and
      d. efforts to anticipate future requirements often missed the mark.

      At the same time, I'm convinced that large system development efforts
      (say 10 person-years of effort and up) live and die by the quality of their
      software architecture. Because of the interdependency between requirements
      and architecture, I'm not sure I quite understand how architecture and XP
      fit together.

      My belief is that software architecture can be formulated in an iterative
      way. I think the most important part of this is knowing which problems
      to approach first. The original message I sent to Kent outlines an approach.
      I've called "architecture challenges" which is a technique for identifying
      the key problems (challenges) to attack first.

      I'm interested to hear:

      o how you think software architecture fits with XP (or not),
      o comments on the architecture challenges approach, including how
      well (or not) it fits with XP.

      Thanks,
      Charlie Alfred
      Technical Director
      Foliage Software Systems, Inc.
      168 Middlesex Turnpike
      Burlington, MA 01803

      e. mailto:calfred@...
      p. 781.993.5500 x448

      -----Original Message-----
      From: Kent Beck [mailto:kentb@...]
      Sent: Thursday, July 03, 2003 11:09 AM
      To: calfred@...
      Subject: RE: Question about XP and Architecture


      Thanks for the extended message. I like your idea of challenges. I sat
      next to a guy on a plane once who'd built Visa's infrastructure. They'd
      beef up their tests until the system broke, and then and only then would
      they put in the next round of infrastructure ideas, and only enough to
      get the test to work cleanly. That sounds similar.

      I 100% agree that if you don't pay attention to architecture, you won't
      be able to develop for long. The question, as it so often is in XP, is
      when should you invest. Theoretically, architecture investment should be
      continuous, as is the investment in testing, implementation, analysis,
      integration, and everything else.

      Does that answer your question?

      Kent
      P.S. I'd like you to send your message on to the XP mailing list
      http://groups.yahoo.com/group/extremeprogramming.

      > -----Original Message-----
      > From: calfred@... [mailto:calfred@...]
      > Sent: Wednesday, July 02, 2003 6:01 AM
      > To: kent@...
      > Cc: Charlie Alfred
      > Subject: Question about XP and Architecture
      >
      >
      >
      > Hi Kent,
      >
      > I read your debate with Barry Boehm in the June 2003 issue of
      > IEEE Software with interest. As a longtime fan of good
      > metaphors, his "elephant and monkey" and your "dinosaur and
      > mouse" reply creates a very interesting juxtaposition.
      >
      > As a practicing software architect and developer, I've
      > experienced the types of shifts in requirements, business
      > conditions, and technology platforms that you describe, first
      > hand. So I definitely see the value in Agile methods.
      >
      > Here's the part where I start disconnecting. What is the
      > proper role of software architecture in Agile Methods?
      >
      > Early on, I some a description of the Chrysler system that
      > you worked on (I'm not sure if you wrote it, or someone else
      > did) that described the use of a "system metaphor." In
      > Chrysler's case, you chose the automobile assembly line as
      > the system metaphor for the payroll system (essentially
      > workflow ~= assembly
      > line) and it worked well.
      >
      > Question to ponder: what is the connection between a system metaphor and
      > software architecture?
      >
      > I have a hypothesis about this that I'd like to share, and
      > get your reaction to. I'll try to state it as a list of
      > premises. I apologize in advance if it seems long. This
      > isn't a trivial problem.
      >
      > 1. The objectives for a system are derived from the context in which it
      > will be used. This includes the immediate context, as well as all
      > ancestors.
      >
      > For example, suppose a J2EE application server is used to construct an
      > airline flight operations system. The context (and objectives) at United
      > are likely to be very different than those at Southwest. This statement
      > applies both the the flight ops application AND the J2EE server. At the
      > same time, the J2EE app server could also be deployed in insurance,
      > securities, payment processing, and customer help desk systems.
      >
      > 2. The objectives for a system (whether stable or dynamic, captured or
      > undiscovered) fall into two categories:
      >
      > a. requirements these are objectives that every alternative
      > implementation must satisfy. These must be
      > able to be stated as a boolean condition
      >
      > b. benefits these are objectives that generate value for
      > the system stakeholders. They are stated as
      > questions that yield a scalar value over some
      > expected range (e.g. if I'm trying to get from
      > city X to city Y, what is the relative value of
      > arriving at 4:00 PM, 7:00 PM or 11:00 PM)?
      >
      > 3. The set of benefits combine to form a "value proposition", which expresses
      > the relative importance between benefits. For example, how much arrival
      > time might I trade for a later departure time?
      >
      > 4. Many, if not most, of the benefits fall into the category of "quality
      > attributes" such as throughput, latency, availability, modifiability, etc.
      >
      > 5. The Software Product Lines group at SEI has defined a good process (IMHO)
      > for evaluating the suitablilty of a software architecture. They call the
      > method ATAM, and it was a subject of the book "Evaluating Software
      > Architectures" by Clements, Kazman, and Klein. The underlying model for
      > this process is:
      >
      > a. Quality Attributes for a system must be identified
      > b. Scenarios must be written so that the attributes are specific and
      > testable
      > c. Prioritize scenarios - they suggest by importance and difficulty
      > d. Identify the key architecture approaches (sets of related decisions)
      > e. Determine the impact (good or bad, strong or week) that each
      > approach has on each scenario
      > f. Examine the result for risks, tradeoffs, and sensitivities
      >
      > One of the nice things about this model is that is works well at many
      > different levels of abstraction. It isn't necessary to have every
      > quality attribute scenario or architecture approach defined first.
      > The whole point of the exercise is to identify areas that need to be
      > addressed, so if you have a partial starting point, you just end up with
      > more holes.
      >
      > 6. I felt that if the model in #5 is a reasonable starting point for
      > beginning an evaluation, it ought to be a good ending point for a
      > software architecture definition.
      >
      > At Foliage, we've started using an approach I call "Architecture
      > Challenges" as a way to formulate a software architecture. The
      > rationale is:
      >
      > a. The quality attribute scenarios are the constant. You need to
      > know about them as early as possible (otherwise, there's a good
      > chance that your architecture might never be able to satisfy them.
      > For example, distributed failover support is not really the kind
      > of thing you want to be adding 2 years down the road.
      >
      > b. The architectural approaches/decisions are the elements being
      > solved for.
      >
      > c. For the formulation process, we need something to map to quality
      > attribute scenarios. I chose "External Factors" - forces from
      > the system context(s) that impose their will on the system. These
      > come in two flavors:
      >
      > o Uncontrollable Forces laws of physics, chemistry, mathematics...
      > o Imposed Constraints laws, regulations, industry standards,
      > technology mandates...
      >
      > d. Given a spreadsheet with External Factors as columns and Quality
      > Attribute scenarios as rows, the cells represent the nature of the
      > impact of each Factor on each QA. Some impacts are positive (e.g.
      > this technology really helps us achieve high-availability). Most
      > impacts are negative.
      >
      > e. Each negative impact represents an Architecture Challenge. The
      > significance of each challenge is a function of:
      >
      > o How important is the impacted quality attribute scenario?
      > o How large is the impact of the external force?
      > o How many realistic alternatives exist to address it?
      >
      > f. The process of formulating a software architecture is driven by the
      > prioritized architecture challenges. In other words, the earliest
      > architecture decisions we should make are the ones that address the
      > most significant architecture challenges.
      >
      > I call this the "packing the car trunk with suitcases to go on
      > vacation" method of architecture. If the number and size of
      > suitcases is much smaller than the trunk, this is a no-brainer.
      > However, if the aggregate size of the suitcases is close to or
      > exceeds the trunk capacity, or there are any large or oddly shaped
      > items, the problem is much more difficult.
      >
      > The plan for loading the trunk is based on:
      >
      > > making sure the most important suitcases get packed, and
      >
      > > making sure we have a plan for where to put the
      > awkward suitcases that are important, that doesn't
      > waste space or preclude other important decisions.
      >
      > Note that a simple approach, such as packing the suitcases in
      > decreasing level of importance is likely to get stuck. While
      > it is possible to adjust (refactor), the amount of adjustment
      > might be unacceptable (i.e. unpack the whole trunk and start over).
      >
      > 7. As with architecture evaluation (#5), challenge-driven architecture
      > formulation also lends itself to an interative approach. The useful
      > property of the model is that early architecture approaches/decisions
      > become external factors (imposed constraints) for those that follow.
      >
      > For example, an architecture strategy can be formulated using a few
      > (~10-15%) of the most significant architecture challenges. This often
      > is sufficient to define:
      >
      > Central Organizing Principles
      >
      > o how the system is partitioned into subsystems and which
      > responsibilities are allocated to which subsystem.
      >
      > o how the subsystems are (or might be) distributed over a
      > network of hosts
      >
      > Theory of Operation
      >
      > o how the subsystems collaborate to achieve the system's
      > value proposition
      >
      > o what mechanisms are needed to facilitate this collaboration
      >
      > o how control is maintained in the system (scheduling,
      > synchronization, etc.)
      >
      > More detailed definitions of the architecture are possible as the
      > number of architectural challenges addressed increases. For example:
      >
      > o identifying the list of capabilities (interfaces or services)
      > that the system must possess,
      >
      > o identifying the components that comprise subsystems,
      >
      > o determining which components provide which capabilities and
      > which components require which capabilities (to function)
      >
      > o identifying which capabilities participate in which external
      > use cases, etc.
      >
      > In summary, I see software architecture as an essential
      > process, but I also see it as an iterative one. Agile
      > methods without a well-defined, disciplined approach to
      > software architecture increase risk, the same way that a
      > mouse who cannot hide itself from predators risks becoming a meal.
      >
      > Any comments?
      >
      > Regards,
      > Charlie Alfred
      >
      >
    Your message has been successfully submitted and would be delivered to recipients shortly.