How to create a software architecture

Lately, I participated in an ISAQB certification for software architects. Part of the training was about the process, how to create a software architecture. The trainer focused on factors and requirements which have deep influence on the system and which pose the biggest risk. For each of these factors a specific solution has to be found. Thus, we were told, if you have all these solutions, you are ready with your software architecture. But is this the complete picture?

I have lots of doubt about this idea. I’d like to call it “architecture in the void” because it tries to create an architecture out of nothing, only taking risk and influence factors into account. No misunderstandings: risk and influence factors are very important and they have to be taken into consideration. But you can't build an architecture just on grainy details - with no big picture in mind.

In fact, I have never experienced an architecture being created by this kind of process in a real life project. But maybe many projects just don’t follow a sensible process? Yeah, that’s most probably true. But on the other hand, my personal experience says, that most of the time – as an architect – you already have some rough sketch of the architecture in mind, before you start with the detailed work. And there is nothing wrong with that. This is just my point: I believe that the art of software architecture is – and has to be – an iterative process. This means, that you already have some rough idea of your architecture and that you refine it in the iterations that follow. The bottom line is: architecting is as well an analytic as a synthetic process – it is a combination of both. Therefore I’d like to describe the process of creating a software architecture like this:

1. Get an overall big picture of the business idea and the most critical business and technical requirements.
2. Create the rough initial target architecture. Most of the time, you would choose one of the prominent architecture archetypes (like ‘web application’) and add some refinement.
3. Analyze risks and requirements in more detail.
4. Find solutions for requirements and address risk.
5. Let the team and a fellow architect review your architecture.
6. Document and communicate your architecture.
7. Repeat steps 3 to 6 until the end of the project.

As you can see, analytic steps alternate with synthetic steps (the ones in italics). The loop indicates that I have an agile and iterative process in mind here. Nevertheless, the most important requirements - those with the most impact on the architecture - have to be addressed early. 

The main point – in contrast to the idea presented in the training session mentioned above – is, that you already start off with a coarse-grained picture of the architecture in mind. That is especially important, since if you would not have such a picture you could not evaluate risk and technical requirements. A risk does only unfold in some environment, which is just what the initial rough architecture is creating.

My message here is: software architecture remains a creative task after all!