Architecture Is A Team Decision
Why We Care About Software Architecture#
A team is formed and a project begins. Features are being produced at a remarkably quick rate. The designers are able to experiment, the stake holders are pleased with the rate of progress and the QA team members have a steady stream of work coming out of the engineers. The Engineers are the happiest of all because they feel like heros. Being able to deliver on all of their promises and seeing the impact they are making with what they created. Engineers are all people pleasers at heart.
Fast forward several months. The stake holders are no longer getting the same output from the team that they once enjoyed. The design team now have a plethora of design changes in the back log that they are waiting on and the QA team members are getting huge eps and flows of work. Worst of all the engineers are no longer the heros. They have become the villains of the story. These days, the engineers are working harder then ever but yet what they can produce is a fraction of what they once could. When the engineers are asked on a status of a specific ticket, they “I am fixing a lot of existing features that I had to break”.
Many of us have been in a version of this team. Why did that happen? The project was going well. The value that the team was adding was beyond expectations. Then the team started to struggle. The engineers where having a hard time changing the code. Wait, lets say that again. The code became hard to change. That is exactly right. The people, project, nor technology was different. The code itself became brittle and rigid. Changing anything started to become a herculean effort. The structure of the code is preventing us from doing what we need to do.
This is where software architecture comes in.
Almost everything we know about good architecture has to do with making software easy to change. - Mary Poppendieck
Software architecture gives us paradigms and tenants for keeping our code easy to change. Keeping our code easy to change makes it so stake holders can request new features and changes to old ones. It allows designers to experiment with new designs and ideas with much lower risk. It allows the flow of work from the engineers to the QA team members to be constant and consistent. It allows for the engineers to continue to produce value for their team, clients and customers at the same rate throughout the lifetime of the project. Not just the beginning.
Why do we care about software architecture? It enables us all to do better work.
How Software Architecture Makes Software Easier To Change#
Software Architecture puts a focus on making code easy to change by focusing on some core tenets. These tenets can form many paradigms to help us. Lets go over these tenets.
Testability and Maintenance#
A well-architected system is easier to test, making it simpler to identify and rectify issues when changes are introduced. This improves maintainability and helps in managing the software’s evolution over time.
Modularity#
Architectural design that breaks down the system into smaller, independent modules or components allows changes to be isolated to specific parts of the system. This reduces the impact of modifications and makes it easier to understand the system’s behavior.
Abstraction#
Architecture often uses abstraction to hide complexities and expose only necessary information to other parts of the system. This allows changes to be made within a module without affecting other parts, provided the external interfaces remain unchanged.
Decoupling and Dependency Management#
A well-designed architecture reduces dependencies between different modules or layers. Loosely coupled components are easier to modify without affecting other parts of the system, thus facilitating change.
Clear Interfaces#
Explicitly defined interfaces between components help in isolating changes. When the interface remains consistent, changes within the component won’t affect others interacting with it, reducing ripple effects.
Scalability#
An architecture designed for scalability often incorporates the ability to handle changes effectively. This might include horizontal scaling (adding more instances) or vertical scaling (increasing the resources of a single instance) without significant alterations to the overall structure.
Design Patterns and Best Practices#
Following established design patterns and best practices in the architecture ensures that changes are made in a consistent and organized manner. This makes it easier for developers to understand, predict, and implement modifications.
Documentation and Communication#
A well-documented architecture assists developers in understanding the system’s structure and behavior, making it easier to implement changes. Clear communication regarding architectural decisions helps in fostering a shared understanding among the development team.
Adaptability to New Technologies#
A good architecture is adaptable to new technologies and tools. When changes are necessary due to advancements in technology, a flexible architecture can more easily integrate these new elements without a complete overhaul.
What Are Some Software Architecture Paradigms#
Now that we know why we care about Software Architecture and how it helps us. Lets explore two popular Software Architecture paradigms and the value that they provide.
Layered Architectures#
This category of Architecture has many variations. Some of these names are Hexagonal, Onion, Clean and N-Tier. They all follow roughly the same paradigm. The code is separated into “layers”. Where each layer is only acts with other layers through clearly defined functions. These functions are the contracts between each layer that must be honored by both side.
This type of paradigm reduces coupling code from each other. This makes it easy for the team to make accidental complexity changes more easily. For example a design like with will allow you to easily replace your existing database solution.
While this paradigm reduces it also reduces the cohesion of a given feature of the system. Imagine a feature like user login. In order to alter the way this feature works an engineer will likely need to make changes is every layer of this architecture. This makes even simple changes more difficult to reason about.
Sliced Architectures#
Sliced Architectures have more recently become popular. This Architectures Paradigm focuses on the collocation of features. Putting entire features as close together as possible and focusing on the isolation of them allows the alteration of existing features or the creation of new features to no longer have any effect on each other.
This has the effect of higher coupling of the features to the technologies that support them. Making it harder to replace a database for instance. However, this paradigm greatly increases the cohesion of the code. Allowing for the engineers to make changes to features more quickly.
Wielding Our New Knowledge#
The Architecture Paradigm that is used in a team effects the entire team. It decides how easy aspects of the project can be changed. Some teams needs the accidental concerns of the technology to be able to change. swapping out what 3rd party tools or database solutions may very well be the paramount concern of your project. Other teams primary concerns may be to iterate often and quickly on features.
Each team will need to first decide on their goals, values and measure of success. Then find an Architecture paradigm that aligns to their goals. This must not be done with only input from engineers. The entire team will have differing perspectives and concerns about how the project will evolve. This means that Architecture is a team decision.