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

RE: [scrumdevelopment] Emerging Architecture

Expand Messages
  • Ken Schwaber
    If it s ok with you, I ll just describe things that work. The failures are too numerous. Mike Beedle points out in our book that building structures,
    Message 1 of 2 , Nov 30, 2001
    • 0 Attachment
      If it's ok with you, I'll just describe things that work. The failures are
      too numerous.

      Mike Beedle points out in our book that building structures, architectures,
      metadata, etc. outside the scope of what is needed in the product, and then
      asking others to use it, is like pushing a rope up a mountain road. If you
      build something that can be used across multiple product lines as an
      integrating architecture, and it gives structure and flexibility to that
      particular product, you have a "reusable component." Mike talks about how to
      then extract the responsibility for the reusable part into a "reusable" team
      that maintains it; the membership of this team might be you and part time
      people from the other various product teams. However, the real development
      of the reusable components and architecture is always within the
      prioritization and real world pressures of the individual product teams. The
      reusable team simply extracts what is reusable, sustains it, and
      reintroduces it into other products.

      You and others may have a vision of the architecture that will tie all of
      the products together. At one customer, this was an xml feed architecture
      that connected a proprietary database with a common web framework. As the
      xml feeds became viable and reusable, they sped up development among all of
      the teams. More often than not, the integrating parts are data oriented.

      So, you may want to draw up an overall product architecture, working with
      leads from the various product teams. It is the architectural vision. If
      everyone has the vision, they tend to make their design decisions around
      this vision as they build specific functionality. Take parts of the
      architectural vision that are common and integrating and have various
      product owners prioritize them into the product backlog, so they are built
      into these products as part of the releases. Incrementally, not the big
      bang. Then extract them and make these available to other teams. Don't force
      the issue. If you've selected the right parts of the architecture to be
      built, the other products will take advantage of them because this will
      speed development. You and others from the reusable component team can work
      on their product teams as they become familiar.

      Viewing the result, the products will be integrated by parts of the
      architectural vision that has been built as part of their normal product
      development. All of these common, reusable architectural components will be
      sustained as a set of corporate capabilities, and enhanced by individual
      product teams as they need further capabilities.

      Hope this helps.
      Ken

      -----Original Message-----
      From: Morris, Ted [mailto:tmorris@...]
      Sent: Thursday, November 29, 2001 11:28 AM
      To: 'scrumdevelopment@...'
      Subject: [scrumdevelopment] Emerging Architecture


      Ken:

      Many thanks for your stimulating work on the topic of agile development.
      You've made tangible some vague ideas that have drifted in and out of my
      thinking over the past 10 years or so.

      I am currently in an architectural role in a relatively large software
      company. I avoid the term "Architect" because the term is so heavily laden
      with connotations, and because I deeply feel that architecture is a process
      undertaken by teams, not a grand vision handed down from the One to the many
      (why do F. L. Wright's houses leak so terribly, I wonder?) . I am painfully
      aware that Big Architecture Upfront is problematic, but I also have this
      nagging sense that at some point, we need to do some level of "architectural
      mandate." Simply stated, our problem is that we have a long legacy of
      developing and selling independent software products targeted to separate
      markets. We are now moving into the bigger world of enterprise solutions,
      where we need to assemble larger systems from the various products and other
      software assets of the company. Suprise, suprise, many of them simply won't
      interoperate today.

      It is neither logistically nor politically feasible to immediately converge
      all project teams to a single vision of interoperability, so I am pushing
      hard to get a couple of the key products working together, via a common
      metadata architecture, with the idea that as others see the success, the
      political barriers will come down, and we can make some progress. The M-V-C
      design pattern is proving to be very useful in help people understand the
      technical aspects of this effort.

      What I am uncomfortable with is the lack of predictablity in the evolution
      of our metadata strategy and the uncharted pathways we may traverse as we
      work toward this objective. Not that I expect total clarity, but I need to
      find the right language and supporting arguments to help our executive team
      see how this will play, and why it is some important not to try to impose a
      rigid imperative on the whole of R&D. A couple of them "get it" already,
      but others are going to require a good bit of attention.

      So, I'd like to hear more of your thoughts on evolving architecture,
      examples you can point to, success and failures I might learn from. it's
      good to se more activity on the Scrum group. The dialog is tightly focused,
      unlike a few other groups I have recently abandoned.

      Regards,
      Ted Morris


      To Post a message, send it to: scrumdevelopment@...
      To Unsubscribe, send a blank message to:
      scrumdevelopment-unsubscribe@...

      Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
    Your message has been successfully submitted and would be delivered to recipients shortly.