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

Agile Architecture - Follow-Up

Expand Messages
  • Matt Heusser
    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
    Message 1 of 4 , Nov 1, 2007
    • 0 Attachment
      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


      [Non-text portions of this message have been removed]
    • 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 2 of 4 , Nov 1, 2007
      • 0 Attachment
        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 3 of 4 , Nov 2, 2007
        • 0 Attachment
          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 4 of 4 , Nov 2, 2007
          • 0 Attachment
            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.