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 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 a.. 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. b.. 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: a.. List of architectural decisions categorized by viewpoints or other relevant taxonomy. b.. UML visual model using 4+1 architectural view. c.. List of interfaces that connect significant parts of the system d.. Other simple templates.? c.. 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. d.. Refactoring the architecture is an essential activity for most Elaboration iterations so the final architecture is robust. e.. 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. f.. The architecture is verified through demonstration, not documentation. g.. 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
