Technology Decisions vs. Architectural Design Decisions

In the latest three weeks I have been watching the video series of Software Architecture Fundamentals: Understanding the Basics and Taking a Deeper Dive by Neal Ford and Mark Richards. A more straight forward name for these videos is from developers to architects. As both of the names indicate, these videos discuss the fundamental knowledge, skills, and responsibilities that a software architect need to exhibit. Now I would like to talk about an interesting problem arising from watching one of these videos.

Architecture in software engineering is a multifaceted subject with no agreed-by-all definition. Correspondingly, those who are doing the architecture work – the architects, very often ill-defined role – have various titles, e.g. data architect, solution architect, application architect.  But above all, it’s widely accepted that architecting is the process during which architects make decisions to reach a finalized architecture. These decisions are named ADDs (Architectural Design Decisions) referring to those that determine and describe the final architecture.

In the video series, Mark had a discussion on whether technology decisions are ADDs. He gave two examples for demonstration:
  1. Is the decision to use Java Server Faces (JSF) an architectural decision?
  2. Is the decision to use a web based client an architectural decision?
Mark emphasized that the first one is not an architectural decision but the second is. ‘Use JSF’ denotes an implementation detail, although it implies that a web based client will be developed. But ‘use a web based client’ is an architectural decision because it determines the architecture style. The scope of the two decisions is different. Mark highlighted that the choice of technology should not drive the architecture. Even though architects very often make technology decisions, these decisions are not ADDs.

Interesting enough, Philippe Kruchten regards technology decisions as ADDs. In his paper An Ontology of Architectural Design Decisions in Software-Intensive Systems, three types of ADDs are given, within which the type of executive decisions encompasses technology decisions and tool decisions etc. According to Mark’s theory, tool decisions, e.g. ‘the system is developed using the System Architect Workbench’, again are not ADDs.

So, why do they have such conflicting views? And what decisions are really architectural ones? Or probably we should ask firstly: why do we care whether a decision is architectural or not?

As mentioned previously, architecting is the process of architects making architectural design decisions to reach a finalized architecture. But if architects make a decision which is not an architectural one, say ‘use JSF’, before they decide explicitly to use a web based client, problems might arise. Firstly, this too early decision of using JSF kills other alternative architecture style, e.g. peer to peer architecture style, which might better suit the context. Secondly, it hinders the choices of other web application technologies if a web based client is really the best choice. So it is the sequence of decision making that matters. Architectural design decisions have to be made before making technology decisions. It is the ADDs that should drive the choice of technology.

So what decisions are really architectural ones? Like the decision of using JSF, it does imply an architecture style and definitely impacts the final architecture – sounds really architectural. So where is the boundary between ADDs and other decisions that architects might make while architecting? The first thought come to my mind is scope. But more thoughts are needed to add in. Hopefully I will figure it out.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>