I have been responsible for architecture design in quite a few projects. The mostly used tools for communicating architecture design is class diagram, package diagram, sequence diagram, delopyment diagram. And in some cases flow chat is also used for important business process modeling. For now I think it is OK. But I am wondering if there are better alternatives for this purpose. I have checked out 4+1 view method. It seems a more holistic approach. I will get a try next time. So what's your favorite ways to communicate architecture design?
A:
One of my favourites is Data Flow Diagrams, which date from the days of so-called "Structured" analysis and design.
ChrisW
2009-05-13 19:22:32
A:
I know this is perhaps not what you were thinking of, but... a whiteboard. Seriously, for communicating design well, nothing beats being able to draw out the design and the interaction between the various moving parts and annotate as needed. It's not a formal method, but it works well for the critical "person-to-person" discussions.
McWafflestix
2009-05-13 19:23:27
+3
A:
Talking to people. Tell them what you are trying to achieve: what nonfunctional requirements you are trying to meet (and which are less important); what the major tradeoffs are; what basic principles and patterns you are using.
Diagrams are there to support your story, but they aren't the story in themselves. I've never used exactly the same list of artifacts in two projects. I don't think it's because I'm fickle, but because every project has its unique challenges (if not in technology, then in people or process).
Be prepared to use UML, ER diagrams, process models, mockups or tap dancing if that's what it takes. Supplement what you're saying with images and texts (so you can reach more people over a longer period of time). But the core of what you should be doing as an architect is to find out what's most important, and communicate it, to all stakeholders: your current developers, future maintainers, systems operators, end users, business sponsors -- at various levels of detail. What means you use must be adapted to their strengths and weaknesses. There ain't no such thing as the Optimum Architectural Documentation format, alas.
Pontus Gagge
2009-05-13 19:26:01
An undocumented architecure can be a little more difficult to learn and to maintain. Also a documented architecture can help to gate the communication between teams (e.g. the teams which develop each component, the QA team, etc.): without documentation you might be relying to word-of-mouth and people's memory to keep up changes in the architecture.
ChrisW
2009-05-13 19:33:33
Actually I use whiteboard sometimes. It is quite effective. Guys can follow my thoughts through my drawing and also supporting explanation.
yanky
2009-05-14 04:41:33
+1
A:
I tend to agree with the concept of whiteboard and face to face for determining requirements. Then use UML to standardize/formalize those idea's.
During the collaboration process, I find adhering to a strict standard is a distraction from your actual goals. That said, I took some PMP ( project management cert ) training and they used large spools of paper, blue sticky goop ( I forget what this stuff is called, something tack? ) and cue cards and its actually pretty amazing how effective this is compared to whiteboard. Unlike a whiteboard, a giant piece of paper is easily moved and cue cards are easy to relocate, remove or replace on the paper. I recommend trying this.
When you are done, hand the giant piece of paper so some poor schmuck who must then enter it into a formal UML diagram.
Serapth
2009-05-13 19:34:06