The best software architecture

What is software architecture?

Is it a system design with which I define certain rules in a system or design clear modules? Or even concrete classes and functions that I define?

If we look at software architecture from the perspective of agile software development, we quickly come to the conclusion that it is hardly possible to define classes and modules at a detailed level well before the actual implementation, since requirements can change sprint by sprint and the application itself also keeps changing over time.

So what exactly is this software architecture, that we use to flesh out how a system will be developed before we start an implementation?

According to Ralph Johnson, software architecture is defined as, „Architecture is the important stuff, whatever that is?!“

This definition may certainly seem rather sobering at first, and yet it holds a lot of truth.

A software architecture basically represents the decisions made by a software team. It is less about documenting or drawing diagrams, and more about the development team working together to make the decisions for a software design. Software developers, designers, product owners, thus agree on specific architectural decisions such as REST or GraphQL, Python or JavaScript, two services or just one.

This also puts the role of a software architect in a completely different light. You’re not there to design a software architecture in a dark closet, using UML and BPMN, and then hand off the diagrams to the software team. The role is rather intended to point out different perspectives of a software architecture and to make the decisions for the software architecture with the team, and not for the team. After all, the team will implement it in the end.

So which is the best software architecture?

There are several software architecture styles, such as Microservices or Space-Based Architecture. But as the name suggests, they are only styles that can be used for decision-making.

This actually answers the question of what the best software architecture is quite quickly – there is basically no such thing as the best software architecture. The decisions that a team makes together with the best will for a software is the best conceivable software architecture for the team and the requirements provided. This is because all team resources are used to involve everyone in the decision-making process to develop the best possible architecture with the people available.

If exactly the same requirements were provided to another team, very different architecture decisions might be made. However, these decisions would again be the best ones for the entire team. This is the only way that the software to be developed could be implemented by all the available software developers.

Nevertheless, there is one architectural style that I have come to know during my career and that has stood the test of time. Most importantly, I hardly ever develop an application not in this architectural style anymore.

We are talking about the domain-driven hexagonal architecture or also called domain-driven hexagon. The architecture style is a mix of Domain-Driven Design by Eric Evans, Clean Architecture and Clean Coder by Robert C. Martin and the Hexagonal Architecture, also called Ports and Adapters, by Alistair Cockburn. Here, different concepts from well-known programmers are combined to achieve clear rules and a clear structure of the application, but still leave the individual architecture decisions, such as REST or GraphQL, Python or NodeJS, to the team.

Here is a picture of the Domain-Driven Hexagon, which nicely illustrates how clear rules are defined, but enough room is left for architecture decisions.

This can be compared with an example from road traffic. It is better to have everyone on the road following the same rules than to have a few who follow similar rules and then have everyone else follow them. What decisions one makes in road traffic is up to each and everyone, but in which direction traffic flows is clearly regulated. And so we come to the following final sentence.

A choreography of the team concerning the architecture has in the long run a better performance, than an orchestration of the architecture by certain persons, who push the architecture decisions fast, but thereby remaining team members are neglected. Thus orchestrated software architectures do not create it in the long run fluctuations, simple changes and shorter implementation times to withstand, whereby choreographed software architectures are initially sluggish by the high synchronization expenditure of the team members, however lastingly to ever faster results leads, is resilient against fluctuations and in general it makes much more fun with one another to develop something than against one another.