Cesare Pautasso - Software Architecture: visual lecture notes

This book collects the revised and illustrated notes of the Software Architecture lecture of the Master in Software and Data Engineering held at the Software Institute at USI Lugano, Switzerland during the Spring of 2020.

The book includes the script for the following lectures:

1. Introduction
2. Quality Attributes
3. Definitions
4. Modeling Software Architecture
5. Modularity and Components
6. Reusability and Interfaces
7. Composability and Connectors
8. Compatibility and Coupling
9. Deployability, Portability and Containers
10. Scalability
11. Availability and Services
12. Flexibility and Microservices

The lecture is designed for master students attending the second semester of the USI MSDE master program with a background in data management, software engineering, software design and modeling, domain specific languages and programming styles.

This book version was published on 20 February 2023.

I started to teach Software Architecture and Design back in the Spring of 2008, encouraged by Mehdi Jazayeri, the founding Dean of the USI Faculty of Informatics, who shared with me a preview of Software Architecture: Foundations, Theory and Practice by Richard N. Taylor, Nenad Medvidovic, Eric Dashofy, to whom I will always be in debt.

I would not have been successful in teaching Software Architecture without the insightful experience and practical advice on architectural decision making shared by Olaf Zimmermann, whom we had the pleasure of welcoming to Lugano as a guest speaker in many editions of the lecture. It has been really great to harvest Microservice API Patterns for the past four years together with Olaf as well as Mirko Stocker, Uwe Zdun and Daniel Lbke.

During later revisions of the lecture I started to recommend to my students to read and study Just Enough Software Architecture: A Risk-Driven Approach by George H. Fairbanks (2010) as well as the more recent Design It!: From Programmer to Software Architect by Michael Keeling (2017).

It is still a challenge to model something as complex as a software architecture. But since Architectural BlueprintsThe 4+1 View Model of Software Architecture were proposed by Philippe Kruchten (1995), we have come a long way with, for example, Simon Brown's C4 model (context, containers, components and code) which as part of this lecture has been augmented with connectors (C5).

The lecture also includes valuable concepts, good ideas and their powerful visualizations borrowed from: Joshua Bloch,Grady Booch,Jorge Luis Borges,Eric Brewer,Peter Cripps,David Farley,Martin Fowler,Luke Hohmann,Gregor Hohpe,Jez Humble,Ralph Johnson,James Lewis,Rohan McAdam,M. Douglas McIlroy,Bertrand Meyer,David Parnas,Jon Postel,Eberhardt Rechtin,John Reekie,Nick Rozanski,Mary Shaw,Ian Sommerville,Michael T. Nygard,Will Tracz,Stewart Brands,Werner Vogels,Niklaus Wirth,Eoin Woods.

The lecture has achieved his current shape also thanks to the feedback of many generations of students attending our Master of Software and Data Engineering and the generous support of my past, present and future teaching assistants (in chronological order): Romain Robbes, Alessio Gambi and Danilo Ansaloni, Marcin Nowak, Daniele Bonetta, Masiar Babazadeh, Andrea Gallidabino, Jevgenija Pantiuchina, and Souhaila Serbout. A big thank you to everyone!

Since 2013, the entire lecture has been delivered through ASQ, a tool for Web-based interactive presentations developed by Vasileios Triglianos, which now can also automatically generate books like the one you are reading.

Cesare Pautasso

Lugano, Switzerland

Software architecture like software engineering is a metaphor that we borrow from some other discipline and we bring into Informatics. There is something that we do when we develop software at scale with large teams, when we need to make certain kinds of important decisions, which reminds of what architects do. We call those decisions architectural. How well does the architecture metaphor fit with software? There are some similarities and there are some mismatches. So now before we talk about software architecture want to spend a little bit of time to introduce what is it from architecture that we can bring in and learn from. After all software architecture is a relatively young discipline. Architecture's been around for longer.

For example, one of the basic ideas of Architecting Buildings is that you should know how to design a building that can last for a long time. There are buildings from thousands of years ago that are still standing today. They have been built using stones only. As with every technology that you choose to adopt. You should know the limits and you should know when it's applicable when it's not. You should be confident that the building will not collapse while or after attempting to build it. The second principle is that what you built should be something useful. A bridge which connects two sides across a river, making it possible to cross it. A house for people to live in. A university with classrooms for students. The third one concerns the effect of the building on the people inside. Does it provide a welcoming place for people to live inside? Do people enjoy working in it? Or do people want to escape from it as soon as they can?

Architects are notconcerned about how to create new and improved building technologies. They are also not concerned with the actual construction of the building themselves.

They're mostly interestedin how to select and compose the right tools, introduce the right elements,and connect them appropriately. How to establish the right kind ofrelationships between theelements so that we have a goodbuilding that fits its purpose?While doing this, thearchitect is making thedecisions for the building's plan, which will be executed to construct the building by someone else. If you'd like to learn how to be an architect,you need to learn how to plan.And you will learn how to do itbefore the actual building exists.

The same holds for software architecture, full of ideas that youshould be able to express in yourdesign for the software beforeit's being built so that someoneelse can go and write the actual code for it.As experienced individual developers, you may wonder how this works, where does the architect fit between the customer requirements and my work writing the software?The architect is key to be able to lead the development effort and scale it so that you can have hundreds of developers working on the same project. And making sure these developers agree on how the architecture for this code should look like.

Overall this is what we call architecture: a kind of design process, with selection and composition activities, but also a process rather different to simply writing and testing the code.