Sustainable Software Architecture

Analyze and Reduce Technical Debt

Carola Lilienthal

• Éditeur: dpunkt.verlag
• Année: 2019
• ISBN:
  9783960887812
• Sujet: Computer Science
• Sous-sujet: Quality Assurance & Testing

Today's programmers don't develop software systems from scratch. instead, they spend their time fixing, extending, modifying, and enhancing existing software. Legacy systems often turn into an unwieldy mess that becomes increasingly difficult to modify, and with architecture that continually accumulates technical debt.Carola Lilienthal has analyzed more than 300 software systems written in Java, C#, C++, PHP, ABAP, and TypeScript and, together with her teams, has successfully refactored them. This book condenses her experience with monolithic systems, architectural and design patterns, layered architectures, domain-driven design, and microservices.With more than 200 color images from real-world systems, good and sub-optimal sample solutions are presented in a comprehensible and thorough way, while recommendations and suggestions based on practical projects allow the reader to directly apply the author's knowledge to their daily work."Throughout the book, Dr. Lilienthal has provided sound advice on diagnosing, understanding, disentangling, and ultimately preventing the issues that make software systems brittle and subject to breakage. In addition to the technical examples that you'd expect in a book on software architecture, she takes the time to dive into the behavioral and human aspects that impact sustainability and, in my experience, are inextricably linked to the health of a codebase. She also expertly zooms out, exploring architecture concepts such as domains and layers, and then zooms in to the class level where your typical developer works day-to-day.This holistic approach is crucial for implementing long-lasting change."From the Foreword of Andrea GouletCEO, Corgibytes, Founder, Legacy Code Rocks

1Introduction

Software systems are certainly among the most complex constructions that human beings have ever conceived and built, so it’s not surprising that some software projects fail, and legacy systems often remain unmodified for fear they will simply stop working. In spite of this complexity, I still encounter project teams that are in control of their software systems, regardless of their industry, technology stack, size, or age. Adding functionality and fixing bugs in such legacy systems involves much less effort than I would have imagined, and new employees can be trained with reasonable effort. What do these project teams do differently? “How do they manage their software so effectively in the long run?”

Sustainability of software architectures

The main reasons for long-term success or failure in software development and maintenance can be found on many different levels. These include the industry, the technology used, the quality of the software system, and the qualifications of the users and developers. This book focuses on the sustainability of software architecture. I will show you which factors are most important for maintaining and expanding a software architecture over many years without making significant changes to your staffing, budget, or delivery schedule.

1.1Software Architecture

50 definitions

Computer science has not been able to commit itself to a single definition of software architecture. In fact, there are more than 50 different definitions, each highlighting specific aspects of architecture. In this book we will stick to two of the most prominent definitions:

Definition #1:

“Software architecture is the structure of a software product. This includes elements, the externally visible properties of the elements, and the relationships between the elements.” [Bass et al. 2012]

Architecture Views

This definition deliberately talks about elements and relationships in very general terms. These two basic materials can be used to describe a wide variety of architecture views. The static (module) view contains the following elements: classes, packages, namespaces, directories, and projects—in other words, all the containers you can use for programming code in that particular programming language. In the distribution view, the following elements can be found: archives (JARs, WARs, assemblies), computers, processes, communication protocols and channels, and so on. In the dynamic (runtime) view we are interested in the runtime objects and their interactions. In this book we will deal with the structures in the module (static)¹ view and show why some are more durable than others.

The second definition is one that is very close to my heart. It doesn’t define architecture by way of its structure, but rather the decisions made.

Definition #2:

“Software architecture = the sum of all important decisions

Important decisions are all decisions that are difficult to change in the course of further development.“ [Kruchten 2004]

Structure vs. decisions

These two definitions are very different. The first defines what the structure of a software system consists of on an abstract level, whereas the second refers to decisions that the developers or architects make regarding the system as a whole. The second definition defines the space for all overarching aspects of architecture, such as technology selection, architectural style selection, integration, security, performance, and much, much more. These aspects are just as important to an architecture as the chosen structure, but are not the subject of this book.

Decisions create guardrails

This book deals with the decisions that influence the structure of a software system. Once a development team and its architects decide on the structure of a system, they have defined guardrails for the architecture.

Guardrails for your architecture

Create an architecture that restricts the design space during the development of the software system and gives you direction in your work.

Guardrails for development

Guardrails allow developers and architects to orient themselves. The decisions are all channeled in a uniform direction and can be understood and traced, giving the software system a homogeneous structure. When solving maintenance tasks, guardrails guide all participants in a uniform direction, and lead to faster and more consistent results during adaptation or extension of the system.

This book will answer questions regarding which guardrails lead to durable architectures and extend the life of a software system.

1.2Sustainability

Short-lived software

Software that is only used for a short period of time shouldn’t have an architecture that is designed for sustainability. An example of such a piece of software is a program that migrates data from a legacy system into the database of a new application. This software is used once and then hopefully discarded. We say “hopefully” because experience has shown that program parts that are no longer used can be still found in many software systems. They are not discarded because the developers assume that they might need them again later. Also, to delete lines of working code that were created with a lot of effort isn’t done lightly. There is hardly a developer or architect who likes to do this.²

The “Year 2000” problem

Most of the software we program today lives much longer than expected. It is often edited and adapted. In many cases software is used for many more years than anyone could have imagined at the coding stage. Think, for example, of the Cobol developers who wrote the first major Cobol systems for banks and insurance companies in the 1960s and 1970s. Storage space was expensive at the time, so programmers thought hard about preserving storage space for every field saved on the database. For the Cobol developers at the time, it seemed a reasonable decision to implement years as two-digit fields only. Nobody imagined back then that these Cobol programs would still exist in the year 2000. During the years prior to the turn of the millennium, a lot of effort had to be made to convert all the old programs to four-digit year fields. If the Cobol developers in the 1960s and 1970s had known that their software would be in service for such a long time, they would have used four-digit fields to represent years.

Our software will get old

Such a long lifetime is still realistic for a large number of the software systems that we build today. Many companies shy away from investing in new development, which generates significant costs that are often higher than planned. The outcome of new developments is also unknown, and users too have to be taken into consideration. In addition, the organization is slowed down during the development process and an investment backlog arises for urgently needed extensions. At the end of the day, it is better to stick with the software you have and expand it if necessary. Perhaps a new front end on top of an old server will suffice.

Old and cheap?

This book is rooted in the expectation that an investment in software should pay for itself for as long as possible. New software should incur the lowest possible maintenance and expa...