Scotts point that
executable architecture shouldnt mean MDA is well taken. I think the
mantra prove it with code goes a long way toward expressing the importance
of architecture as not being simply boxes and arrows on an OpenUP
project.
Maybe all the gurus
on this list can help me make this point in a concise and memorable way.
Weve all been on
projects where prove it with code amounted to little more than tinkering
with some idea, pattern, or open source package until it met the barest
standards of quality and seemed to vaguely demonstrate that this might
work. The problem is that it doesnt actually implement any of the
projects requirements. Inevitably, when we try to actually integrate
the new architectural mechanism or component into the system and get it
working as part of an end-to-end
requirement realization, all the unstated assumptions of the proof
of concept start coming out.
I believe that the
best approach to elaborating on the architecture is to incrementally build
working, tested requirement realizations that implement the most
architecturally risky parts of the solution first. I suspect that when
Scott Ambler says prove it with code, thats shorthand for something more
like prove it by adding working, tested code to the projects source
base. I want to be sure people dont think that in OpenUP, architecture
is a couple diagrams and some disconnected code examples or
proofs-of-concept.
Can anyone help me
with a terse slogan to get this point across?
Thanks!
Nate
Oster
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
todays 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 theres 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
- Its 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 hasnt ended.
- Refactoring the
architecture is an essential activity for most Elaboration iterations so
the final architecture is robust.
- Tacit knowledge
an experts 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 its the right way to go. It shouldnt 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
customers 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