hiho,
I think you should cut a possible concern
off at the pass by stating somewhere that this is not Big-Architecture-Up-Front.
I think you hint at it with “How does a team create a
robust system without over-analyzing the architecture in early iterations”, but I don’t think that is enough. In fact, the
incremental improvement of the architecture based on what is learned or what
changes in a project should be an important part of this… which argues
against the “Knowing when the architecture is complete” outline item.
I wonder if it is worthwhile to give a
bulleted list of architectural representation options. I think it is an
innovation that OpenUP does not disregard architecture, but instead provides agile
techniques for iteratively working together to come up with it and supports a
very lean representation of it.
When you actually create the presentation,
don’t forget to include the shadows metaphor. I love that bit.
I know you use the phrase “proof of
concept”. Is there a place to get the phrase “executable
architecture” in there? That should spark some thoughts in the
readers of this that we are not just talking about circles and arrows.
You’ve edited enough of my stuff for
me to feel comfortable with this nit-pick: I use “ensure” to “make
sure” and “assure” to “give confidence of” (e.g. “I
assure you that I will ensure success”).
-------------- b
From:
epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of Jim Ruehlin
Sent: Wednesday, January 24, 2007
8:23 PM
To: epf-dev@xxxxxxxxxxx
Subject: [epf-dev] Agile 2007
Abstract: OpenUP Architecture
Hello all,
I’m considering submitting the following abstract for Agile 2007.
Any comments you have are welcome. I have to submit this by Friday so please
respond before then.
Thanks,
Architecture the OpenUP
Way: An Agile and Unified Approach to Architecture
Topic Summary
The purpose of a good architecture is to assure you can keep delivering
business value in your software far into the future. However, Agile teams often
have difficulties defining what the architecture is and how to produce it. It
seems like a proper Agile method would allow the architecture to emerge over
the course of development. But experienced practitioners have encountered
serious problems in later iterations when a defined architecture isn’t
created in early iterations. From a practical perspective, experienced
developers tend to work on architectural issues in early iterations to achieve
overall system stability. But how much architecture is enough? How does a team
create a robust system without over-analyzing the architecture in early
iterations? How can long-term business value be supported without sacrificing
the delivery of value in the next iteration?
This presentation illustrates how to build architectures in an agile
way by leveraging OpenUP/Basic architectural guidelines. The presentation
describes how to focus on architecture in early iterations without sacrificing
business value. It defines what architecture is in an agile context, how to
define just enough architecture, and how to evaluate when the architecture is
complete and verified. Attending this presentation will provide context for
creating just enough architectural information to support the long-term
delivery of business value.
OpenUP/Basic is available for free download from www.eclipse.org/epf.
This presentation is geared towards developers tasked with defining
robust systems, and the developers who use those definitions to fully realize
the system. Developers of all experience levels will find it useful.
Attendees will benefit from understanding OpenUP/Basic architectural
guidelines by:
- Increasing their
ability to judge how much architectural description is useful without
getting stuck in architectural analysis.
- Learning how to
create and describe architectural mechanisms that solve architecturally
significant requirements such as persistence, logging, and security.
- Understanding what
kinds of architectural representations can be useful in an agile context.
- Learning which
architectural representations are appropriate for different circumstances.
- Gaining a context
that makes defining the architecture a first-order goal.
- Acquiring insight
into identifying architecturally significant requirements.
Outline
- Architecture in an
agile context
- Identifying
architecturally significant requirements
- Reaching the initial
architectural state (proof of concept)
- Choosing the right
architectural descriptions
- Identifying and
evolving architectural mechanisms
- Balancing architectural
value with business value
- Validating the
architecture
- Knowing when the
architecture is complete
____________________
Jim Ruehlin, IBM Rational
RUP Content Developer
Eclipse Process Framework (EPF) Committer www.eclipse.org/epf
email: jruehlin@xxxxxxxxxx
phone: 760.505.3232
fax:
949.369.0720