You have a vision of your system’s architecture in your head. How do you share that with your team?
Do Whiteboard Architecture. At Pivotal Labs, our teams do Agile Inceptions  to plan out a few months worth of work. Just after an inception is when you have a rough sense of what you’re going to be working on in the upcoming iterations. After planning, take some time to draw out the current architecture of your application and then discuss where the new work fits. Your requirements changed mid-iteration? Gather everyone around and draw a new diagram.
Often, somewhere in an architecture is a Big Ball of Mud which contains code you’ll be needing soon. Discuss how to improve your ball of mud. Maybe new packages are needed. Maybe some packages need to be split. Maybe your terminology needs updating. Your goal here is to create a plan, and not to lock-in decisions. Be agile. Value responding to change over following a plan.
Whiteboard diagrams are disposable, and that’s a good thing. Your drawings only represent your current understanding of the architecture, and the architecture will change. Use your eraser. Draw a new diagram later.
While drawing, it might be a good time to discuss some architecture principles. This will help you explain why you’re making architectural decisions, and is a great chance to spread your thought process and knowledge throughout the team. Share these, for example:
- Reuse-release equivalence principle
- Common-reuse principle
- Common-closure principle
- Acyclic dependencies principle
- Stable-dependencies principle
- Stable-abstractions principle
- Risk-driven decision making
- Non-functional requirements/Quality Attributes (scalability, maintainability, usability, extensibility, availability, etc.)
- Domains, Sub-domains, and Bounded-Contexts
here are some resources:
- Just Enough Software Architecture: http://www.amazon.com/Just-Enough-Software-Architecture-Risk-Driven/dp/0984618104
- Agile Software Development – Principles, Patterns, and Practices: http://www.amazon.com/Software-Development-Principles-Patterns-Practices/dp/0135974445
- Domain-Driven Design: http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215
At Pivotal Labs, our open workspace is surrounded by whiteboards. Every wall is either a whiteboard, a window, or a door. Every team can walk ten steps and be at a whiteboard. We like to use whiteboards for diagramming because they are a low-cost, low-effort way of collaborating on Software Architecture.
To be clear, I’m not advocating for Big Upfront Design. I’m just advocating that you should Have A Plan and then implement, iterate, and look for feedback from your design and team. Because Whiteboard Architecture is cheap and easy, you should be able to gather your team, draw a new diagram, and have everyone on the same page quickly.
As usual, significant architectural decisions should be delayed until the last responsible moment (like the choice of SQL vs NoSQL), but this should not stop you from knowing that data needs to be stored and retrieved.
What tricks do you and your team use to collaborate on Architecture? Please share!
About the Author