Software Architecture

Software architecture can refer to a number of different things:

Why is Software Architecture Important?

"The entire history of software engineering is one of rising levels of abstraction" -- Grady Booch

Software Architecture

There are several different approaches to testing the architecture of a software system, and the specific approach will depend on the nature of the system and the goals of the testing. Some common techniques for testing software architecture include architectural risk analysis, which involves identifying and assessing potential risks to the system's architecture; architectural review, which involves evaluating the architecture against a set of predefined standards or criteria; and simulation and prototyping, which involves creating models or prototypes of the system and testing them to see how they perform. Other techniques for testing software architecture include performance testing, which involves measuring the system's performance and identifying bottlenecks or other issues; load testing, which involves testing the system under heavy workloads to ensure it can handle large volumes of data; and stress testing, which involves testing the system to see how it responds to extreme or unexpected conditions.

Architecture Principles

Software Architecture Practices

Software Architecture Design

There are many approaches to Software Architecture Design.

TODO: SAD Approaches outline...

SAD Approach: RFC Architecture

One approach to architecture design

Software Architecture Principles

TODO: INTRODUCTION

TODO: DIAGRAM WITH BOXES KINDA LIKE VENN DIAGRAM AND MIND MAP. SEE: https://miro.medium.com/max/4800/1*jMIkg9P335NJSfiGF5V0Pw.webp

SOLID Principles

TODO: OVERVIEW

Single Responsibility Principle

This is the principle that each component (module, service, API, etc.) should have only one responsibility, and, perhaps more importantly, one reason to change. Keeping the responsibilities as narrowly defined as possible allows others to more easily understand the purpose of the component, and helps minimize the potential for errors.

Open-Closed Principle

This is the principle that software components should be open to extension, but closed to modification. In other words, it should be easy to add to the capabilities of the component, but not possible to change what a component does. The idea here is that building components that are adaptable help extend the longevity of the component as well as the systems that use the component.

Liskov Substitution Principle

This is the principle that derived classes need to be able to replace their base class without breaking the software.

This principle bears resemblance to Bertrand Meyer's Design by Contract principle in that two services or objects are able to communicate via a common contract between them that defines their inputs and outputs. In other words, the contract provides the definition of expectations, and any subclass of the contract should be able to substitute for the contract without breaking the system.

Interface Segregation Principle

This is the principle that contracts (interfaces) must be as client-specific as possible. In other words, they must be as fine-grained or minimal as possible, and only declare the minimum required inputs and outputs.

This principle goes well with the Single Responsibility principle; by breaking functionality down into minimal interfaces, we give preference to design by composition of small, minimal components.

Dependency Inversion Principle

This principle deals with coupling between components, and is one of the most foundational software principles. The core of this principle is that high level modules should not depend on the low level components that they are composed of. Instead, components should be loosely couples using interfaces that abstract away the details and remove dependencies between the layers.

LEAST Principles

TODO: OVERVIEW

Least Astonishment

The principle of least astonishment (or Least Surprise) suggests that a solution or approach must not surprise a reasonably knowledgeable person when encountered. If a component exhibits unpredictable or unexpected behaviour, it is likely that the component is not well designed.

TODO: APPLIES TO...

Least Effort

This principle (also called Zipf’s Law) stems from a basic human behaviour: Everyone tends to follow the path that is as close to effortless as possible. So for example if our design follows a particular pattern, the next developer will be motivated to follow the same pattern again and again unless there is a significantly easier way to perform the task, in which case they will change! Or, taking this further, once they find acceptable results for a task, there is no immediate need to improve the current solution.

As such it is imperative to aim for a strong start by putting the right architecture in place: it sets high expectations and ensures everyone understands that the quality is not compromised in the project’s lifecycle and it will be adhered to in case of future changes.

For me, the greatness of this principle lies in the fact that its benefits extrapolate: once we put a right design in place, we can create an architectural framework which will be the basis of the next systems we build. In other words, we are able to establish a template for the software that is flexible, adaptable, and lightweight.

Cost Principles

TODO: INTRODUCTION

Opportunity Cost

Every time we make a choice, there is a certain value we place on that choice. Value has two parts: benefits and costs. The opportunity cost of a choice is what we give up to get it. To make a good economic decision, we want to choose the option with the greatest benefit to us but the lowest cost. For example, if we have two choices, either an in-house built system or an off-the-shelf vendor product and we choose the latter, then our opportunity cost is the shiny new system our development team could have developed but didn’t.

This is what architecture is all about: weighing choices against each other and trying to make an informed decision on which one will add the most value for the project. For instance, a very common dichotomy is whether to create a tactical solution with quick time to market or a more strategic one which will be more expensive now with the view to leverage it in future projects and hence minimize the cost later down the line.

What is the time available for the architectural analysis/evaluation? It is challenging enough to come up with one solution, let alone a few! What is the product pipeline for the next 1–3 years? And what other projects are lined up? Can you see any synergies? What is your current technical debt that you could potentially address? And turning this around: How much new technical debt will incur if you pursue a tactical solution? Which quality attributes tend to be the most important for systems in your organisation and how will they be compromised by the proposed solution? Apart from the architecture team who else is a stakeholder that will affect the decision? The Business? Your boss? The Technical Design Authority? What are the key objectives of each stakeholder? How will you mitigate conflicting needs?

Cost of Delay (Last Responsible Moment)

This principle originates from Lean Software Development and emphasizes holding off on taking important actions and critical decisions for as long as possible. This is done so as to not eliminate potential alternatives until as many of the requirements, constraints, and potential issues are identified and understood. By delaying irreversible decisions until the last responsible moment, we are reducing the potential risk and cost of rework by having.

Early in a project we should make as few binding decisions as possible!

Conclusion

Architectural principles help us evaluate design decisions and ensure the architecture is cohesive and the software is meeting it's goals and objectives.

Software Architecture Design

TODO: Introduction

Design as Code (Design Docs as Code)

Software Architecture designs should be treat as code; both in terms of workflow, and in terms of keeping them up-to-date.

SAD Approach: RFC Architecture

One approach to architecture design

References