Solution shaping workshops

When architecting a new IT system, at some point fundamental decisions need to be made. For instance about the structure of the system and its components, about the usage of some commercial product, or about the integration of components. These decisions are architectural, as they are fundamental – they cannot be changed easily afterwards.

In a typical project, architects, designers and other stakeholders all have their own view on the system that is to be built. They create their own views and sketches, have their own mental map, talk to each other (but not to everyone, let alone the lead architect) and make up their mind on how things should be solved. However, not everyone has the same knowledge level on all relevant topics and few – if any – are able to oversee the consequences of their proposed solutions.

Various architectural methods define some point “where the magic happens”. Some methods are quite vague about it (come up with the best fitting solution), and other try to highly organize it, such that is becomes unpractical (create extensive lists with alternatives, use a repository of architecture building blocks, etc.).

But in practice, the magic happens in a discussion by a small group of architects. Brainstorms are held, solutions are found, and the most fundamental views are created. I call it the Solution Shaping Workshop.

Now, don’t confuse a Solution Shaping Workshop with a traditional workshop, as in for instance the MetaPlan Method or a Brown Paper session. A Solution Shaping Workshop can be planned, but can also happen spontaneous – for instance as a result of an informal discussion between architects at the coffee machine.

A Solution Shaping Workshop has the following characteristics:

• No workshop mediator, no system
• Small group of people (2 to 4 members)
• Availability of whiteboards or flip-overs to make drawings
• Relaxed environment
• Focus on one problem
• Everyone is free to brainstorm, ideas are welcome
• One hour max

In a Solution Shaping Workshop one architectural concern is addressed (for instance: “How does our system interface with the current system?”). In the workshop one member of the team explains the problem and provides his first line of thinking. Then a free-format brainstorm is done, where all members are expected to provide input. In practice, quick sketches are made on whiteboards or flip-over pages that help the creative process. When everyone agrees about the outcome of the creative process – the drawn picture – the workshop ends. When no solution can be agreed upon in one hour, the Solution Shaping Workshop should end; apparently the team is not ready to make a decision on the subject yet. In such a case, actions should be agreed for a follow-up (for instance, it could be agreed to get more information from other stakeholders, or to put the issue on the architectural concerns list).

Be sure to make pictures of the whiteboards (using your phone) before the meeting ends, or to take the flip-over sheets with you. One person (typically the one that started the Solution Shaping Workshop) transforms the drawings to a proposal for an architectural decision. Such an architectural decision typically states:

• The definition of the architectural concern that is addressed (what problem are we solving)
• The proposed solution as agreed upon in the Solution Shaping Workshop (including drawings and clarifying text)
• The pros and cons of the proposed solution
• The alternatives that were discussed and the reason they are not chosen
• The impact and implications of the decision

This architectural decision (typically a few pages in length) is then sent to the members of the Solution Shaping Workshop to be peer-reviewed. After this review, the decision typically needs to be approved by some project board or design authority.

When the solution is approved, it is very important to share the solution with all relevant stakeholders, to avoid new discussions about possible solutions at a later stage. Preferably, this is done by presenting the solution to the group. In such a setup, it is most helpful not to show the created drawings on a projector, but to sketch them again on a whiteboard. This way people can understand how the solution is built up, step by step. While sketching the solution, the group builds up a mental map of the solution. Questions can be answered as soon as they arise, during the buildup of the sketch.

Was the picture shown to them in full, they could get confused, overwhelmed by detail, or question some detail instead of grasping the total solution first.

Be prepared to answer questions from the stakeholders, as they might have their own view on the subject (and sometimes even a worked-out solution in some form). Try to avoid discussions about new alternatives. By getting approval before presenting the discussion to a larger group, the decision is not under discussion, but a fact.

This entry was posted on Saturday 07 June 2014