Tech Talk: "What is Software Architecture?" mit Simon Lasselsberger

Tech Talk: "What is Software Architecture?" mit Simon Lasselsberger

Today I’m going to talk about software architecture! My name is Simon and I am a software-architecture and -development consultant and today I would like to introduce you to software architecture.

There are a lot of definitions what software architecture is – some of them are more scientifical, others are rather vague. This one looks a little bit weird at the first glance but this is the most actionable and clearest I could find. It is from Ralph Johnson – he is one of the founders or one of the authors of the Gang of Four book – and he is quite famous in the software industry.

It goes like this: „Architecture is about the important stuff – whatever that is.“

It does not sound clear yet but I will break it down for you. Let’s take a look at the important stuff first.

Ralph Johnson also said: „In most successful software projects, the expert developers working on that project have a shared understanding of the system design. And that shared understanding is called the architecture.“

So what does that mean? It's not about documentation or whatever – I mean documentation can help to build a shared understanding – but it is the stuff that is going on in the heads of the experienced developers that have experience with the system itself. And that is that is really a very useful explanation of what is important because that shared understanding is important.

And he also said another thing, he said: „Architecture is the decisions that you wish you could get right early.“

I mean this is not too easy to implement because how could you look into the future? But there is another very important guy in the software industry. He's called Martin Fowler and he rephrased that statement from Ralph Johnson a little bit different and he said: „The decisions that are hard to change later.“

And this is something that we can always tackle. We can always try to figure out if we had to change this and that – how easy could this be?

And this is very actionable. And if you combine those two things, the shared understanding and the stuff that is hard to change, then you have the important stuff. And there is another aspect to the definition from Ralph Johnson and that is that „whatever that is“ – and that is really also important because software architecture is not about certain technical decisions. It's really about „whatever“ you can do to make change easy. And this could be high level patterns like choosing a microservices architecture over a monolith or splitting the client and the server using a hexagonal architecture or event driven architecture, or how do your data structures look like, … And it's not only about choosing one of them. You can also mix and match. But this is – again – the „whatever that is“ part. Of course the persistence layer – do you use NoSQL databases or relational databases or whatsoever?

How does the communication work between components in your system? Is it API? Do you have a system that just renders plain old HTML on the server side, or what application platform do you use – for example which programming language to choose? This is also part of of software architecture. The frameworks, the libraries or even make or buy decisions are also part of software architecture. Deployment is also very important of course – do you have in-house infrastructure or do you deploy to the cloud or have a hybrid solution? Of course the CI/CD pipelines are important as well.

But there are also a little bit different aspects like the engineering process itself. So really software architecture tackles everything that makes change easy. Agile development is all about making changes quick and fast, so we need to support this as well. Are there other people that need training and coaching something like that.

And then one very important thing is Conway's law where you need to take care in your architecture what communication patterns you have within your company and between your teams. And if you ignore the Conway's law then you will have problems communicating your architecture and driving it forward.

But why is it called architecture in the first place? It’s kind of weird maybe and if you talk to non-technicians this makes sense. You can always tell them: OK when you go to an architect they will make a plan for your house and then you can hand it over to a construction workers and they will build it. Roughly put, a software architect could do the same thing. You will tell them what you want, makes a plan and then hand it over to a development team and they will implement. But this is not true if you take a deeper look. This is really just a rough explanation for long technicians, because in civil engineering we understand the environment a lot. We know how the physical world works, we know the laws of nature and these factors influence the design. And once the building is built, it roughly stays like this, right? It doesn’t change significantly. Of course it can be expanded and changed here and there but the rough shape will stay the same. This is not true for software development. Software must be able to deal with extremely fluid and dynamic environment. Everything changes – from the user requirements over to the software environment itself over to extending it and living it. So the software compared to a house is more like a living thing and not very static. And the fundamental expectation that we have for software is that it supports these changes. So it needs to have easy changeability almost like a transformer that can always adapt to the current mission.

So Eric Doernenburg said something different. He said it is better to compare software architects with town planners because they need to take in more information from all kinds of perspectives. And they need to optimize the layout of the whole system and not just focus on one building. And they also need to look wider into the future. What are future requirements or the current requirements and stuff like this. So if you take a look at this picture you can see – maybe you decide to keep old buildings because they do not need to change or there is no need to do something about it. But in the background we see a modern skyscraper where you maybe have your core business and you need to invest more. And this is really the better explanation or the better picture that you can draw for software architects.

And software architects must not be seen as a person but rather as a role. And every developer can from time to time or more often choose to take over this role. The goal is to create, foster and document this shared understanding that must always be based on business goals. We need to focus on the business goals because we are not building the architecture for itself to be beautiful. We always solve business problems. And this is this is something that is very important for an architect because the architect has a wider and broader vision and a broader understanding of the business goals than a developer must have to can focus on the next sprint goals – but developers should also take this role from time to time.

Architects also need to identify things that are hard to change later and they are responsible to make solutions and decisions upon them.

So if something is hard to change, is it worth investing time to actually make it easier to change? That is always a question that you have. And the responsibility lies on the architect role – but it does not really mean that the architect itself must develop the solution. So it just is there to be responsible for it. It can also be developed by other people in the team. One other very big aspect is a software architect should not dictate solutions. They should build bridges between teams and people to really drive the software forward and make change easy.

And to make change easy, there is one thing that Martin Fowler – the guy from before – also developed is the Design Stamina hypothesis. It’s a hypothesis because there is no real data that could be measured to actually validate this thing. But this is an axiom for a lot of people in the software industry and it goes like this: on the x-axis you have time and on the y-axis you have the cumulative functionality of the software. And when you take a look at the blue line you see it is steeper in the beginning – that means you can create more functionality in your software than in the red line. The blue line represents a software that has no design, where you do not invest in design. And the red line, as you see, is slower in creating more functionality in the beginning. But at some point those lines will cross. And above this design payoff-line, there is no tradeoff anymore that you could do below this line. That means if you want to be fast in the market and you really need to launch your product, then it could be wise to trade good design versus implementation speed. But in the long run, good design will always beat no design. And one interesting thing is also – and I believe that is true – that this design payoff line does not come after years, not after months but after some weeks. And this is really important to understand. And this is also something that we need to communicate as software engineers to product teams as well to understand how this works. Because once you’re above the payoff-line, there is no argument against not investing in good design.

This is not good design – this is how bad design feels. Imagine you want to change something here – it is a mess.

This is something we want to achieve – this is really good, well structured design – I mean this is not software, this is obviously a datacenter but this doesn’t matter. It is clear, everybody can work there and can quickly understand what to do. And this is really what we want to archive.

So, coming back to the explanation or the definition of software architecture that I mentioned in the beginning: Architecture is about the important stuff – whatever that is. You know what the important stuff is – it is the shared understanding, it is the stuff that is hard to change and we need to do whatever we can to make changes here easy. And this is software architecture.

Thanks a lot. My name is Simon and if you want to know more about software architecture or want connect with me do this on linkedIn, Twitter or Facebook. Thanks a lot!