In my
experience how and how much of the architecture should be documented, is a
collaborative decision between the consumers (most others but the analysts
and architects), providers (analysts and architects), and other stakeholders
(Architectural Review Board, PMO etc.) One size does not fit all. 4+1
(+data+service) views could be explained in OpenUP guidelines by the particular
concerns they address. However allowing agility in architectural description is
very important, I have seen excellent projects with architectures drawn from
whiteboards to napkins to Visio diagrams, and also, the 4+1+1+service
views. I attribute the power of the human brain to its ability for
fuzziness (say, a Visio diagram implicitly combining some of the 4+1+1 views, or
other suitable means.) That, I believe should be leveraged in OpenUP.
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
