hiho,
As I was reading Jim’s message I cringed
a bit at 4+1. Every time I describe it in a training session or something
I say “There was this guy trying to describe an air traffic control
system in Canada
and…”. I always end with “Now as a person creating a
smaller-scale MIS app, you probably won’t bother to specifically render
the process or deployment views. Think of this in the abstract: you need
multiple perspectives that must not contradict each other and must clearly
align with the use cases. Maybe you’ll have a data view and a user
experience view. But they should all be verified with an overarching
use-case view.”
I would love for the 4+1 views to be a
distant reference mentioned in a guideline on examining the architecture from a
range of perspectives.
Though executable architecture is key and
we need to prove it with the code, I want to be clear that someone should jot
down architectural decisions. This need not be a formal document, but I
would like to know the decisions we have made. It is fine to say that an
expert is not mandated to defend the decision in a document, but I would
suggest it is a good idea to describe why the decision was made.
BTW, we should be clear that the
non-executable parts of the architecture need not “contain” any
design, they reference design elements that are either in the Artifact: Design
or in some other more external place (e.g. “We are using these J2EE
Blueprint items”).
I look forward to re-examining and
slimming down the architectural approach in OpenUP.
------------- b
From: epf-dev-bounces@xxxxxxxxxxx
[mailto:epf-dev-bounces@xxxxxxxxxxx] On
Behalf Of Scott W. Ambler
Sent: Tuesday, November 28, 2006
9:34 PM
To: Eclipse Process Framework
Project Developers List
Subject: Re: [epf-dev]
OpenUP/Basic Architectural Approach
Architecture is a touchy subject in the agile
community. What I've written about architecture, do a little bit of
sketching on a whiteboard up front to give you an initial vision and then move
forward from there, is seen as far too heavy.
4+1 is going to turn off a lot of people. It already
does in the RUP, let alone OpenUP. Maybe we should mention it in a
guideline somewhere, but I wouldn't have that in the main text.
With agile approaches we treat documentation like any other
requirement -- we prioritize it, estimate it, and put it on the stack along
with everything else. The architecture should be documented only to the
extent that the stakeholders are willing to pay for it. And, that
documentation is often written late in the project once things are stabilized,
typically based on the surviving diagrams on the team's whiteboards.
I've worked on very complex systems where the architecture
"documentation" was a few whiteboard sketches until pretty much the
end of the project. The PM also captured these diagrams in PPT to
communicate to senior mgmt, but that wasn't our official architecture
documentation.
Ana's comment that we should move a lot of this material
into guidelines is a good one. This is true of a lot of stuff in OpenUP I
suspect.
Nate's comment about executable architecture is good, but we
need to make sure that we're not talking about it in the MDA sense of the
word. The MDA approach is valid, but only for a very small portion of the
marketplace. In Agile Modeling we included the practice "Prove it
with Code" to get this point across.
Every organization gets the process that it deserves.
----- Original Message -----
Sent: Tuesday, November
28, 2006 5:23 PM
Subject: [epf-dev]
OpenUP/Basic Architectural Approach
One of the items we discussed in today’s review of the
OpenUP Architecture package was changing the approach we take to Architecture
(see https://bugs.eclipse.org/bugs/show_bug.cgi?id=165258).
There was general agreement that we need to be more agile in this area than we
are now, although there’s a lot of useful guidance now.
Based on our discussion and some other thinking, I put
together some initial bullet points for discussion. The intent is to describe a
lighter-weight perspective for how architectures are created in OpenUP/Basic.
Comments are encouraged.
Properties of OpenUP/Basic Architectural Approach
- It’s more important in a
small team to start building and experimenting with architectural ideas
early than to do lots of up-front architectural analysis. This implies short
iterations and rapid adjustments during Elaboration.
- The architecture is always
important enough that it needs to be documented, even if no other part of
the design is documented. It can be documented through one or a
combination of the following:
- List of architectural
decisions categorized by viewpoints or other relevant taxonomy.
- UML visual model using 4+1
architectural view.
- List of interfaces that
connect significant parts of the system
- Other simple templates…?
- The bits of new architecture
that are added during an Iteration must be documented by the end of the
iteration, or the iteration hasn’t ended.
- Refactoring the architecture is
an essential activity for most Elaboration iterations so the final
architecture is robust.
- Tacit knowledge – an
expert’s perspective that delivers useful insight and guidance - is
an accepted architectural input. For example, assume Mark is the
acknowledged expert on some part of the system. He may define a set of
architectural decisions that are difficult to justify directly, but his
experience tells him it’s the right way to go. It shouldn’t be
necessary for Mark to provide detailed justifications. He should only need
to provide enough information to gain the support of the team members.
Justifications should be brief if Mark has made good decisions in the
past.
- The architecture is verified
through demonstration, not documentation.
- In general, the architecture is
the least amount of the design that can be documented that still
illustrates the way in which the system reifies a solution to the
customer’s problem.
- Jim
____________________
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
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
