Many times, when making an architectural decision, I am faced with multiple decision points. Each point leads to a new possibility of making another decision with three, four, or even five levels of decision implications. Let’s take a simple, yet very common example: choosing the database for a new service. MySQL or MongoDB? Externally Managed or self-managed? Outsourced management or internal management? You can see how each decision leads to another decision and another decision and it becomes complicated to understand where it all began.

In the context of such complicated decisions, creating a visual representation is a must not only for the architect making the decision but also for the stakeholders who need to understand the implications of each decision point.

I discovered this concept in the book The Art of Strategy by Avinash Dixit and Barry Nalebuff. Originally, in the book, the technique is described backward, starting with the end goal and identifying each decision that needs to be taken before reaching the end goal, all the way to the present moment. However, in the world of software architecture, the end goal is split across multiple perspectives (scalability, security, maintainability, etc), and it’s easier to start from the present moment and build the implications of each decision to see if it fits the overall business strategy and vision.

How to use decision trees

In the simplest form, I often start by building the decision tree myself to see where it takes me. It’s easy to model decision trees in almost all diagram software solutions that are out there. Depending on the results of this first draft, I can decide if I have the information to move forward and put everything in text form or something else.

When things get complicated and it’s not so straightforward to make sense of the decisions, it’s important to get feedback from outside. I typically do this by taking an initial draft to my peers and working with them to further refine it. For each decision point, I add their feedback as a note. The best part of it is when we discover new decision points or creative ways of tackling future challenges.

Ultimately, decision trees are a tool that can be brought to a workshop. I haven’t tried building a decision tree with a group of 10 people and I think that might be quite difficult to work out since each decision must be added to the previous decision so that the whole tree has meaning. However, I have brought an already-built tree to a wide audience and gathered feedback on each decision and it’s quite effective.

Overall, decision trees are an effective tool that can help in making sense of complicated architectural decisions with multiple implications. Decision trees provide a visual representation that can help with individual work, as well as group thinking and team collaboration which makes them suitable for bigger audiences.