Different types of architecture design – from doodling on paper to more accurate modeling

When we start to shape the architecture of a new application, the result is often familiar.

I would say that across different geographies, industries, and application types, some elements are common. The architectural sketches are usually made of boxes and lines, with labels, arrows, and similar artifacts. That’s an intuitive way to shape our thoughts on paper.

However, in the following section, we will go through different ways of expressing those concepts. This will make us aware of available styles and techniques and will make our diagram clearer and, ultimately, easier to share and understand.

But first, let’s find out what the characteristics of architectural sketching actually are.

Sketching the main architectural components

As we discussed earlier, there are a number of different components that are recurrent in a high-level architectural sketch. Let’s examine them one by one:

• Boxes: These represent the software components. They can refer to one complete application or specific subcomponents (such as packages, modules, or similar things).
• Lines: These describe the relationships between the boxes. Those links imply some sort of communication, commonly in the form of APIs. The lines can also represent inheritance or a grouping of some sort. A direction (that is, an arrow) can also be specified.
• Layers: These are a dotted or dashed line, grouping components and their relationships. They are used to identify logical slices of the architecture (such as the frontend, backend, and more), the grouping of subcomponents (for example, validation and business logic), network segments (such as the intranet and DMZ), physical data centers, and more.
• Actors: Simulating the interactions of users within the systems, actors are usually represented as stickmen, sitting on top of some components (usually frontends or UIs of some sort). It is not uncommon to observe different channels represented, in the form of laptops or mobile phones, depending on the industry and type of application (for example, ATMs, branch offices, and physical industrial plants).

Now, let’s view an example sketch:

Figure 1.1 – The common components on a first architectural sketch

As we’ve already mentioned, the quick and dirty representation shown in this diagram is useful since it’s an easy way to start thinking about how our application should look. However, on a closer look, there are some common inaccuracies:

• The software components (that is, our boxes) might be represented with different levels of zoom: sometimes representing applications, sometimes features, and sometimes software modules. This is inconsistent and could generate confusion.
• Some components are specialized (for example, databases), while others are not. As noted in the preceding point, this leads to an inhomogeneous view.
• In some parts of the diagram, we are representing use cases or information flows (for example, with the actors), while elsewhere, we are drawing a static picture of the components.
• Some points of view don’t cope well with others because we might be representing network firewalls but not referencing any other networking setup.

Now that we’ve learned what a naïve representation looks like and what its limits are, let’s take a look at some other types of diagrams and how they represent alternative points of view.