Blogpost

Tribe Read: Fundamentals of Software Architecture

Continuum reading groups

At Continuum, continuous learning and knowledge sharing are highly stimulated because we believe they are the key to our success.  One of the ways to put it into practice is by organizing reading groups.  A group of 5 to 10 colleagues with a common interest reads a book and schedules a couple of meetings to discuss the acquired knowledge.

Reading a book in a group is encouraging and makes the learning process more efficient and also more pleasant.  Talking about new knowledge and best practices acquired while reading a book leads to interesting discussions and is often a trigger to share work experiences.

fundamentals of software architecture

At the beginning of this year, a new reading group was born.  Ten Software Crafters received the book “Fundamentals of Software Architecture” in their mailbox. 

The expectations about the book were high because it promises to provide a comprehensive overview of software architecture’s many aspects and an engineering approach to software architecture.  The book is based on 70 years of collective experience between the two authors.

Mark Richards is the founder of DeveloperToArchitect.com.  Neal Ford (http://nealford.com/) is Director and Software Architect at ThoughtWorks and author of other books like “Building evolutionary architectures”.  

The authors claim their book differentiates itself from others in terms of practical use.  You can pick up the book, learn practical experience and apply it immediately to your job.

The book consists of 3 parts: Foundations, Architecture Styles and Techniques and Soft Skills.

Part 1 – Foundations of architecture

Part 1 is a long introduction to get all readers up to speed.  It covers the topics you can expect in a book about software architecture.  What is architecture, what is the difference between architecture and design.  It describes non-functional requirements, architecture characteristics and the importance of modularity and component based thinking.

Part 2 – The what and how of architecture styles

Part 2 is more practical and to the point.  It explains the different architectural styles.  Architecture styles describe a named relationship of components covering a variety of architecture characteristics.  Giving the large number of different styles, a name helps architects during discussions, because  each name captures a wealth of understood detail.  Architects must understand the various styles and trade-offs encapsulated within each to make effective decisions.  Like design patterns give developers a common language and a way to think about design problems, knowing architectural styles gives architects a common language and a way to understand architecture problems.

Architecture styles can be classified into two main types: monolithic (a single deployment unit of all code) and distributed (multiple deployment units connected through remote access protocols).  Monolithic includes styles like layered, pipeline and microkernel architecture.  Distributed includes styles like service-based, event-driven, space based, service-oriented and microservices architecture.

The authors describe the history and context of when, how and why different architectural styles became popular.  Some of them became irrelevant over time.  As we all know, the software development ecosystem changes gradually and constantly.  In fact, every decade it becomes a completely new ecosystem. 

What makes the book interesting is that it provides a rating for each of the characteristics of the different architectural styles.  This makes it easier to compare the different styles and get a better understanding regarding when a particular style might be more applicable than another, depending on the context and requirements. 

They also emphasize that the perfect, golden bullet architecture that solves all problems doesn’t exist.  Everything in software architecture is a trade off.

Part 3 – Decisions, teamwork and effectiveness

An effective software architect must not only understand the technical aspects of software architecture, but also the primary techniques and soft skills necessary to think like an architect, guide development teams and effectively communicate the architecture to various stakeholders.  Part 3 of the book addresses the key techniques and soft skills necessary to become an effective software architect.

One of the most effective ways of documenting architecture decisions is through Architecture Decision Records (ADRs – https://adr.github.io/).  An ADR not only clearly states the decision it also provides context, describes alternatives that have been evaluated and defines compliance criteria.

Analyzing architecture risk is one of the key activities of an architect.  By continually analyzing risk, the architect can address deficiencies within the architecture and take corrective action to mitigate the risk.  A risk matrix (the overall impact of risk + the likelihood of risk occurring) is a useful technique to assess architecture risk and reduce the level of subjectiveness.

As already mentioned, effective communication is critical to an architect’s success.  No matter how brilliant an architect’s technical ideas, if they can’t convince managers to fund a project and developers to build it, their brilliance will never manifest.  Creating diagrams and presenting architectures are two critical soft skills for architects.  The book describes a number of tools and techniques that can help the architect.

Last but not least, a software architect is responsible for guiding the development team through the implementation of the architecture.  Being able to make teams productive is one of the ways effective and successful software architects differentiate themselves from other software architects.  Control freaks and armchair architects will never be truly successful.  Becoming an effective software architect requires working closely with the team and gaining the respect of the team.

If you haven’t read the book yet, I hope your interest is triggered now.  Fundamentals of Software Architecture is definitely worth reading.  

The next big challenge for all participants of the reading group is to put this knowledge into practice.  The book’s website presents a list of architecture katas (http://fundamentalsofsoftwarearchitecture.com/katas/list.html) that will help us to get started.

There’s no time to rest for the wicked.  Another book  is already lurking around the corner.  The other architecture book of Neal Ford “Building evolutionary architectures” (https://www.thoughtworks.com/books/building-evolutionary-architectures) is probably a good candidate 😉

Wij bieden aan externen ook de mogelijkheid om deel te nemen aan onze leesgroepen. Wil jij op de hoogte gehouden worden wanneer wij starten met nieuwe sessies? Registreer je van voor onze nieuwsbrief en dan houden wij je op de hoogte!

peter

Peter Moorthamer

Craft Lead

Peter behaalde zijn master aan de Karel de Grote Hogeschool te Antwerpen. Hij heeft ondertussen meer dan 20 jaar ervaring als consultant in diverse sectoren zoals telecom en farma. Reeds 10 jaar maakt hij deel uit van de Continuum Tribe en werkte hij voor verschillende klanten. Binnen Continuum heeft hij de rol van Craft Lead en Coach en beslist hij mee over de technologische koers die ons bedrijf moet varen.