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

Emerging Architecture

Expand Messages
  • Morris, Ted
    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
    Message 1 of 2 , Nov 29, 2001
    • 0 Attachment
      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
    • 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 2 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.