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

Re: [XP] Agile Architecture - Follow-Up

Expand Messages
  • Steven Gordon
    I cannot confirm or dispute what constitutes architecture to various specializations or aspects of development. My take on what would make any of them agile is
    Message 1 of 4 , Nov 1, 2007
      I cannot confirm or dispute what constitutes architecture to various
      specializations or aspects of development.

      My take on what would make any of them agile is to avoid prematurely
      committing to any solution for any architectural problem any sooner
      than absolutely necessary by:
      - doing whatever constitutes architecture during the implementation of
      a thin, representative slice of the system,
      - getting concrete feedback (testing and interaction with stakeholders),
      - reflecting on what worked and what did not work,
      - taking into account everything that was learned, repair and then
      repeat on the next thin slice of the system (until the entire system
      is satisfactorily done).

      Steven Gordon

      On 11/1/07, Matt Heusser <matt.heusser@...> wrote:
      > I've been thinking more on that whole Agile Architecture thing ... here's
      > some ramblings on the subject to spark debate.
      >
      > am a bit frazzled by the term "Software Architect." I don't think it means
      > anything. <http://www.ddj.com/architect/184407745>
      >
      > Or, perhaps, to put it another way: Perhaps it means everything?
      >
      > The confusion of the word reminds me of the confusion over the term testing,
      > which reminds me of Brett Pettichord's Four Schools of Software Testing.
      > <http://www.io.com/%7Ewazmo/papers/four_schools.pdf>
      >
      > It occurs to me that there are at least five distinct schools of computer
      > architecture:
      >
      > CPU Architecture: Highly specialized and different; slim to never confused
      > with the items below
      > A CPU Architect looks a lot like: An electrical engineer
      > Exemplar: Multi-Core CPU's
      >
      > Systems Architecture: Interested in the technology stack used by the
      > business – for example – HP/UX servers running Oracle as DB servers, linux
      > web servers, desktop PC's with windows
      > A systems architect looks a lot like: A director of IT services
      > Exemplar: Service Level Agreements, Redundancy, Failover, Backups
      >
      > Software Architecture: Interested in implementing various strategies to
      > solve problems, such as Session, State, Domain Logic, Polymorphism, MVC, and
      > so on
      > A Software Architect looks like: A highly-abstracted programmer
      > Exemplar: UML Diagrams
      >
      > Organization Architect: Interested in how to seamlessly integrate people,
      > processes and tools while speaking a common business language
      > A Organization Architect Looks a Lot Like: A professional design-reviewer
      > Exemplar: The Zachman Framework, "Enterprise" Architecture, The City
      > Planning Analogy
      >
      > Consulting Architecture: Interested in helping the customer and technical
      > staff reach a shared understanding of the work, breaking the work up into
      > manageable chunks, helping the customer understand the solution, and
      > sticking around to see the solution implemented.
      > A Consulting Architect looks a lot like: What we used to call a 'systems
      > analyst' in the 1980's
      > Exemplar: Story-Cards and a release schedule
      >
      > This is really just a conceptual framework. Thus, when I get into arguments
      > about the meanings of the word "Architecture", I can say "Oh, wait, you're
      > coming from the consulting school" and do translation. (This can explain a
      > lot of the conflicts I've gotten in where, for example, I realized a
      > consulting architect wasn't really technical or an organizational architect
      > stood up and said "This isn't really an architecture question" and stepped
      > out while we were planning the systems infrastructure.)
      >
      > But what do you think?
      >
      > --
      > Matthew Heusser,
      > Blog: http://xndev.blogspot.com
      >
      > "Objectivity cannot be equated with mental blankness; rather, objectivity
      > resides in recognizing your preferences and then subjecting them to
      > especially harsh scrutiny — and also in a willingness to revise or abandon
      > your theories when the tests fail (as they usually do)."
      > - Stephen Jay Gould
      >
    • Scott Ambler
      I have a few thoughts about architecture at http://www.agilemodeling.com/essays/agileArchitecture.htm and the primary message is to keep things as simple as
      Message 2 of 4 , Nov 2, 2007
        I have a few thoughts about architecture at
        http://www.agilemodeling.com/essays/agileArchitecture.htm and the
        primary message is to keep things as simple as possible. From your
        discussion I suspect that you might be over-complicating things or
        looking for a more complicated solution than you really need.

        At http://www.agilemodeling.com/essays/initialArchitectureModeling.htm
        I describe how to do a bit of architecture envisioning at the
        beginning of a project to get you going in the right technical
        direction. You can do architecture modeling without it turning into
        some form of ivory tower documentation effort.

        - Scott
      • Matt Heusser
        ... Did I miss an email chain? Your statements here seem to assume that we share some agreement on what architecture *is*. My point was that we do not, in
        Message 3 of 4 , Nov 2, 2007
          Scott Ambler wrote:
          > From your discussion I suspect that you might
          >be over-complicating things or looking for a more
          >complicated solution than you really need.
          >....
          >I describe how to do a bit of architecture
          >envisioning at the beginning of a project
          >to get you going in the right technical
          >direction. You can do architecture modeling
          >without it turning into some form of ivory
          >tower documentation effort.
          >

          Did I miss an email chain? Your statements here seem to assume that we
          share some agreement on what architecture *is*.

          My point was that we do not, in fact, share such agreement.

          In general, I'm for simplest design that could possibly work, design as you
          go, and good designs often mean delaying decisions as long as possible.
          (Example: "Apache or IIS?" "Well, if we use this component stack, we don't
          have to decide now, we could support both ...")

          I am not supportive of using terms like "quality" or "architecture" without
          first explaining what we mean.

          Or is this a response to someone else's post?

          Regards,

          --
          Matthew Heusser,
          Blog: http://xndev.blogspot.com

          "Objectivity cannot be equated with mental blankness; rather, objectivity
          resides in recognizing your preferences and then subjecting them to
          especially harsh scrutiny � and also in a willingness to revise or abandon
          your theories when the tests fail (as they usually do)."
          - Stephen Jay Gould


          [Non-text portions of this message have been removed]
        Your message has been successfully submitted and would be delivered to recipients shortly.