Rapid Software Architecture Exploration

At XP2013 this June in Vienna, Austria I ran a brand new workshop titled "Rapid Software Architecture Exploration."  In the workshop I presented a framework for thinking about software architecture design based on my essay, Exploring the Design Space, and gave participants a chance to put the theory to practice using four different exploration activities. Slides and handouts from this session are available online.

Huge thanks to everyone who came to the workshop.  Everyone did an amazing job and really ran with the activities we did.  I think the end results were very good -- surprisingly an almost fully architected system in only 45 minutes (plus some of the prep work that I did ahead of time).  I have no doubt, now even more so, that with a good facilitator and the right people in the room you can accomplish in hours or a few days what traditionally could take weeks.

The session was great because you guys made it great.  Thank you!  If you use these workshops with your teams or customers, let me know how it goes, I'd love to hear from you!

System Properties Web

The system properties web is intended to be a light version of the traditional Quality Attributes Workshop.  Combining structured brainstorming or a quality attributes taxonomy questionnaire with a spider diagram for capturing concerns, stakeholders can quickly identify raw quality attribute scenarios and create a visualization  depicting the "signature" of the system.

A group brainstorms raw scenarios and concerns.

Categorizing concerns helps create a visualization to assist in the workshop.

The stakeholders in this group seem most concerned with reliability and availability

While this stakeholder group identified concerns across many quality attributes,
notice that neither of the examples identified many scalability concerns.

Round Robin Design

Round Robin Design is a method for quickly generating many ideas and then helping to converge those ideas.  The idea is simple.  Working alone or in small groups you design a view of the system and then pass your design to another group for critique and yet another group for improvement.  Constraining the time forces you to get creative and actually design something while sharing your designs exposes you to new ideas and creates a sense of shared ownership among the team.

Everyone got very quiet during this activity...  Deep in concentration.

Another group of architect's working quickly to
design a physical perspective of the system.

Risk Storming

Risk Storming is a workshop proposed by Simon Brown of "Coding the Architecture".  The basic idea is to use diagrams of the system as a kick start for brainstorming risks in the current system design.  These risks then become the basis for designing experiments, research, or further detailing design for specific parts of the system.

Working together as a group, both engineering risk and
project management risk should be considered.

Each sticky represents a risk or worry.  Place the stickies directly on the diagram
in the area to which the risk applies.

Using different colored stickies also helps create a visualization of risk
in the system - or at least show what folks are worried about.

At least one view of the dynamic, physical, and static
perspectives should be evaluated.  Context diagram too if time is available.

Stakeholder Mapping

Stakeholder mapping is an exercise introduced to me by Ari Font.  This 30-45 minute activity is a great way to start a full day of workshops.  I like this activity a lot.  It is always a surprise to see how many stakeholders and stakeholder groups actually have influence or could be influenced by the system that you are building.  This is also an activity that helps break the ice and sets the tone for group participation.

Collaborating on a stakeholder map for their group.

One of the group's maps.

Groups only had about 10 minutes and quickly identified
more than just the usual suspects of stakeholders.

Reflection

Overall I felt this workshop went really well.  Front loading the theory and presenting the workshop activities first gave folks who were not interested in hands on practice a chance to learn something without committing to a group learning activity.  I understand it -- after a few days at a conference, a sit and listen lecture can be just what you need sometimes.  For those who stayed, the hand on parts were a fun and effective learning experience.

I was extremely impressed with how quickly everyone picked up the practices and applied the theory.  I take this as a good sign that the framework for thinking about design is a good approach. I know that I've been successful using this approach and these practices, but a true test is when someone else is able to apply the ideas on their own.  A future variant of this workshop might be even more aggressive in how much the teams design on their own.

XP2013 is one of my favorite conferences.  It's got a great mix of researchers and practioners, and a workshop like "Rapid Software Architecture Exploration" really benefits from this mix.

Call it what you will -- rapid exploration, lean software architecture -- combing best of breed practices from other design disciplines with lean versions of common architecture workshops seems like a winning combination.