“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.”
I think this is the key litmus test for how “agile”
we’re being in the architecture discipline, so long as we focus on the
fact that in OpenUP the architecture is executable
architecture. It’s easy in a group like this to take that
perspective for granted and forget that much of the world, even in small
projects, still doesn’t think that way. When we say “focus on
articulating the architecture,” we want our users to immediately make a
mental connection with working code, not simply with “boxes and arrows.”
As OpenUP continues to mature while remaining minimalist, I
hope that one of it’s bedrock principles continues to be that it’s executable-architecture-centric.
Nate
From:
epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of Jim Ruehlin
Sent: Tuesday, November 28, 2006
5:24 PM
To: epf-dev@xxxxxxxxxxx
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