SPA Conference session: Effective architecture sketches | |||
| One-line description: | Communicating software architecture in a simple yet effective way | ||
| Session format: | Long tutorial (330 mins) [read about the different session types] | ||
| Abstract: | Collaboration and "moving fast" aren't terms that many people associate with the software architecture role, yet they're both essential. Why? Because collaborating on the software design process provides a basis for coming up with a better solution and paves the way for collective code ownership. And moving fast requires "just enough" up front design to avoid costly rework, which sits conveniently in that vague area between ivory towers and foolishly hoping for the best. Costly rework can be caused by a number of things ranging from not mitigating the key technical risks through to the team not understanding the high-level structure and therefore being able to work towards the same vision. This, as with agile in general, requires good communication skills and not being able to effectively communicate your software architecture will slow you down at best. Most people don’t get to practice the software design process all that often and fewer get to hone their communication skills. Join us if you want to practice collaborative software design and learn about how to communicate it through a collection of simple effective sketches. | ||
| Audience background: | Software developers/architects with an interest in designing software systems and leading software teams. | ||
| Benefits of participating: | There are two key benefits from attending this tutorial. 1. It's an opportunity to practice collaborative software design. 2. It's an opportunity to practice communicating the resulting software design, which is useful for presenting the vision both inside and outside of the immediate development team. | ||
| Materials provided: | We'll provide a short set of high-level requirements and some additional materials such as index cards, post-it notes, etc. | ||
| Process: | The process is as follows: - We provide a short, simple set of high-level requirements and ask small groups to design a solution before drawing one or more diagrams to communicate their design. - Each group then briefly presents their solution/diagrams. - Each group is asked to review the diagrams created by another group, making a note of what like and what they think could be improved. - The session leaders summarise the feedback and provide some additional guidance covering things like where to start, whether to use UML or block diagrams, how much detail to include in diagrams, whether to include technology decisions, etc. - Each group is asked to have another go at communicating their design with one or more diagrams considering all of the feedback and guidance in mind. - Each group again presents their own diagrams and reviews those created by another group. - Again, the session leaders summarise the feedback. | ||
| Detailed timetable: | [00:00 - 00:10] Setting the scene (introduction, objectives, process, etc). [00:10 - 03:00] Software design, presentation and review (round 1). [03:00 - 03:30] Break [03:30 - 04:00] Feedback summary and addition of guidance (e.g. diagram types, levels of detail, etc). [04:00 - 06:00] Software design, presentation and review (round 2). [06:00 - 06:30] Session wrap-up. | ||
| Outputs: | The outputs will take many formats, including posters at the conference and certainly one or more write-ups on the web. The content will vary depending on the outcome of the tutorial, but the goal is to include: 1. A number of example diagrams that effectively communicate different parts of the software design. 2. Some guidelines for how people can achieve the same level of effective communication on their own projects. | ||
| History: | This is part of a 2-day training course that is regularly run throughout Europe (i.e. http://www.softwarearchitecturefordevelopers.com). It has also been been run at other conferences in 2011 (e.g. http://www.codingthearchitecture.com/2011/04/03/deliberate_practice_effective_sketches.html) although there has never been a focus on producing any public output (e.g. example diagrams). | ||
| Presenters | |||
| 1. Simon Brown Coding the Architecture |
2. Marcin Floryan Energized Work / Emergn |
3. | |