Solution shaping workshops

2014-05/solution-shaping-workshops.jpg

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

Earlier articles

Quantum computing

Security at cloud providers not getting better because of government regulation

The cloud is as insecure as its configuration

Infrastructure as code

DevOps for infrastructure

Infrastructure as a Service (IaaS)

(Hyper) Converged Infrastructure

Object storage

Software Defined Networking (SDN) and Network Function Virtualization (NFV)

Software Defined Storage (SDS)

What's the point of using Docker containers?

Identity and Access Management

Using user profiles to determine infrastructure load

Public wireless networks

Supercomputer architecture

Desktop virtualization

Stakeholder management

x86 platform architecture

Midrange systems architecture

Mainframe Architecture

Software Defined Data Center - SDDC

The Virtualization Model

What are concurrent users?

Performance and availability monitoring in levels

UX/UI has no business rules

Technical debt: a time related issue

Solution shaping workshops

Architecture life cycle

Project managers and architects

Using ArchiMate for describing infrastructures

Kruchten’s 4+1 views for solution architecture

The SEI stack of solution architecture frameworks

TOGAF and infrastructure architecture

The Zachman framework

An introduction to architecture frameworks

How to handle a Distributed Denial of Service (DDoS) attack

Architecture Principles

Views and viewpoints explained

Stakeholders and their concerns

Skills of a solution architect architect

Solution architects versus enterprise architects

Definition of IT Architecture

What is Big Data?

How to make your IT "Greener"

What is Cloud computing and IaaS?

Purchasing of IT infrastructure technologies and services

IDS/IPS systems

IP Protocol (IPv4) classes and subnets

Infrastructure Architecture - Course materials

Introduction to Bring Your Own Device (BYOD)

Fire prevention in the datacenter

Where to build your datacenter

Availability - Fall-back, hot site, warm site

Reliabilty of infrastructure components

Human factors in availability of systems

Business Continuity Management (BCM) and Disaster Recovery Plan (DRP)

Performance - Design for use

Performance concepts - Load balancing

Performance concepts - Scaling

Performance concept - Caching

Perceived performance

Ethical hacking

The first computers

Open group ITAC /Open CA Certification


Recommended links

Ruth Malan
Gaudi site
Esther Barthel's site on virtualization
Eltjo Poort's site on architecture


Feeds

 
XML: RSS Feed 
XML: Atom Feed 


Disclaimer

The postings on this site are my opinions and do not necessarily represent CGI’s strategies, views or opinions.

 

Copyright Sjaak Laan