Getting Your Software Architecture Right

Published in

Monster Culture

8 min readNov 12, 2018

You don’t need to be an expert to code something that works. If the project is small and the complexity is low, you don’t need a senior developer to get the job done.

http://themetapicture.com/the-life-of-a-software-engineer/

Take a look at the cartoon above. The only software engineer who has never experienced this is the one who never coded a single line.

Getting software right is hard. Years of experience and lots of different skills are needed to master this. It is a pleasure to work on a project whose engineers got it right. You can add, change or remove features without trouble. The developers, product managers, business people, and customers are happy.

When is the architecture right?

This really depends on which kind of project you do. If you do a small prototype you are going to throw away, you don’t need the best architecture. I like the following tweet from Andrey Breslav, the lead language designer of Kotlin.

In most of the cases though you are going to release and maintain the built system and add new features later on. Robert C. Martin states in his book Clean Architecture:

“The goal of software architecture is to minimize the manpower required to build and maintain the required system.”

So how can we achieve that? There are lots of different coding and architecture skills, that bring us closer to this goal. It is important to understand, that being a superb coder doesn’t make you a great software architect and vice versa.

Some software architects use a method, called ATAM, to evaluate the quality of existing or future software architectures. ATAM stands for Architecture Tradeoff Analysis Method. It has 9 steps and can require up to 30 people for days of effort. For software engineers without proper knowledge about software architecture and the ATAM I created a simplified version called LAAM — Lean Architecture Analysis Method.

LAAM to get it right

LAAM should help software engineers to get their software architecture right. It consists of four steps.

Collect quality metric goals
Brainstorm quality scenarios
Generate architectural approaches
Analyse approaches

You can remember the steps by MSGA — My Solution’s Gonna be Awesome: Metrics, Scenarios, Generate, Analyse

Collect quality metric goals

As a starting point you need to define how to measure your architecture. You do this by coming up with a prioritised list of quality metric goals. Make sure to include all different stakeholder views: users, management, product owners, QA, developers, support, … Keep in mind you don’t actually have to invite all stakeholders into a meeting. Otherwise you are going to end up with a huge round. The following image shows a few examples for quality metrics:

ISO 25010 software product quality metrics

Some of the quality metrics are in conflict with each other. A few examples:

High modifiability sometimes leads to lower performance. By having multiple layers of abstraction, models need to be mapped from the database to plain business objects, which leads to lower performance.
Concurrent high usability and high security is hard to achieve. Forcing users to use two factor authentication or long passwords has a negative effect on usability.
Having multiple servers with data replication for high availability and faster response time reduces the integrity of the data.

After defining the quality goals, it is good to prioritise them. You can use dot voting for this. Every participant gets a fixed number of dots and can put one or more dot on the most important quality goal from his perspective. Make sure that everyone chooses where to put his dots before actually placing them. When everyone is ready and has chosen their most important quality goals, put all dots down simultaneously not thinking where the others put theirs. This way you avoid influencing each other and being a victim of the Bandwagon Effect.

Brainstorm quality scenarios

At this step you collect different scenarios for your architecture. In the final step we are going to test our architecture against them. Especially here it is beneficial to include distinct stakeholders and more people to get various perspectives. Again keep in mind, you don’t have to set up a meeting for that. You can group your scenarios into three different types:

Typical: these are typical use cases such as the new feature needing to be able to handle 1000 concurrent users.
Growth: this is anticipated changes related to growth. For example, the new feature needs to handle 100.000 concurrent users.
Exploratory: here you think about extreme changes to your architecture. For example, adding a web application to your existing native apps.

Like the quality goals, the scenarios need to be prioritised by whatever make sense for you. If you have too many scenarios, you can cut out the lower priority ones. It is more efficient to only analyse the top priority scenarios.

Generate architectural approaches

Come up with one or more architectural approaches for your task or project. You can also skip this step if you want to analyse an already existing architecture. How you come up with an architecture is open to you. I don’t cover that in this blog post. However, here is some advice:

Don’t Reinvent The Wheel, Unless You Plan on Learning More About Wheels

Reinventing the wheel can be seen as an anti pattern.There are lots of great architectures out there that fulfil certain quality goals and are proved over the years by many good software engineers. For more information refer to these books and articles:

The output of this step can be different mediums, starting from a verbal description, a simple sketch on a whiteboard up to a proper UML diagram. In my opinion it’s always good to try to do proper UML when you do an architecture diagram. I know it’s complicated and can be annoying, but there is less room for interpretation. Some tools I personally like to sketch my architectures are PlantUML and draw.io, which has a nice JIRA and Confluence integration.

Analyse approaches

Now you are ready to analyse the architectural approaches. At this step you want to find out if your approaches fulfil the quality goals and how the quality scenarios affect your architecture. Doing this together with another developer makes sense.

Go through each of your approaches, play through each of your scenarios and estimate the effect on your quality goals. During this step look for risks, sensitivity points and tradeoffs. A sensitivity point is a property of the architecture that is critical for fulfilling quality goals. A small change to it is likely to have a huge effect. For example the minimum length of a password or the bits for encryption have both an effect on security. So when the security goal is increased, they are very likely to change. A tradeoff is a property that is a sensitivity point for more than one attribute. If one thing increases, some other thing must decrease. For example:

Redundant replication of data increase availability, but reduces integrity.
Complicated encryption algorithm with long key increases security, but reduces performance.
Layered architecture increases understandability and changeability, but reduces performance.

Shortly document the outcome and then go on to the next approach. Finally, compare your different approaches and choose one. Having written down the facts helps you to make an objective decision. Now you should know if your architecture is going to have a good quality or not.

If none of your approaches are satisfying, try to come up with a new approach and don’t adjust your quality scenarios and goals. Maybe you find out that some of your quality goals are in conflict with each other. This case then is tradeoff. It’s not possible to have the highest usability with the highest security. In this case you have to go to your stakeholders and tell them that you need to make some sacrifices and lower one of the quality goals.

Conclusion

To perform the LAAM, little preparation is needed and it can even be done under an hour already having a software architecture in place. Make sure to include various people to get different perspectives. Then apply the four steps: collect quality metric goals, brainstorm quality scenarios, generate architectural approaches and analyse the approaches. Maybe my mnemonic helps to remember the steps: MSGA — My Solution’s Gonna be Awesome: Metrics, Scenarios, Generate, Analyse

Pro tip: Document each step of the LAAM. This guards you against future accusations and helps you to understand why you made the decision even one year later. If a product manager or other developers accuse you that the architecture is not right, you have some evidence to prove why you decided for a certain architecture. You can show for which quality goals and scenarios the architecture is built. If the goals and scenarios change, so might the need for your architecture to change.