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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
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.
- Scott
Scott W. Ambler
Practice Leader Agile Development, IBM
Senior Contributing Editor, Dr. Dobb's Journal
http://www-306.ibm.com/software/rational/bios/ambler.html
Every organization gets the process that it deserves.
----- Original Message -----
From: Jim Ruehlin <mailto:[EMAIL PROTECTED]>
To: [email protected]
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: [EMAIL PROTECTED]
phone: 760.505.3232
fax: 949.369.0720
________________________________
_______________________________________________
epf-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/epf-dev
_______________________________________________
epf-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/epf-dev
