If it's ok with you, I'll just describe things that work. The failures are
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.
From: Morris, Ted [mailto:tmorris@...
Sent: Thursday, November 29, 2001 11:28 AM
Subject: [scrumdevelopment] Emerging Architecture
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
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.
To Post a message, send it to: scrumdevelopment@...
To Unsubscribe, send a blank message to:
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/