The Good Architecture
Make it simple, boring, and flexible
Good architecture it's a set of decisions over time
No matter how good it is (today), it will change over time, based on several variables we can’t fully control, like leadership change, the experience gathered, technology evolution, problems to be solved, growth, performance, cost, etc…
Over the past years, I realized that good architecture needs to be flexible and adaptable. To achieve this it should be simple enough to be boring. Concepts are important, but don’t tighten too much to then, mainly because they will make the architecture unflexible, pay attention to the core of concepts and the problem to be solved, not to the system design or technologies.
Here are some aspects that can change how good an architecture is over time…
The Conway's Law
“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure” — Melvin Conway
Conway's Law implies that as an organization evolves through leadership changes, team restructuring, or shifts in communication strategies, the same happens with the architecture of its systems, which will reflect the changing communication patterns and decision-making processes within the organization.
Consequently, what is considered a 'good' architecture today might not align with tomorrow's “new” organizational structure since this is influenced by how we communicate with each other.
As teams grow, new skills, perspectives, and capacities come together with the new hire individuals and change how some problems are approached and solved, raising new opportunities or efficiencies that weren't clear before. So, an architecture that was working before may need to be re-evaluated to accommodate the new capabilities of a larger team.
Standards & Patterns
An effective architectural strategy must balance these specific goals overarching goals of the project or organization. Standards and patterns aim to reduce the risk of introducing unnecessary complexity, as these standards often encapsulate the collective wisdom and experiences of the broader community.
The reality is that, nowadays, there are at least 46 different patterns — don't forget Anti-patterns — that aim to offer a way to build reusable solutions to common problems.
It's almost impossible to remember all these patterns, so we tend to talk more about the most recent and popular, and it’s common to try to fit a pattern into a problem not the other way around.
Microservice1 is a good example, over the years it has become the default answer to almost all architecture scalability issues, but microservices try to solve an organizational problem2, reducing teams’ dependency and improving velocity by the cost of introducing a significant amount of complexity to manage multiple services, their deployment, testing, monitoring, and managing dependencies between services.
Accidental Complety
The Accidental Complexity anti-pattern happens when we introduce non-essential complexity into a problem. - Mark Richards3
This often happens due to a lack of understanding of the problem, poor communication, or misalignment between the system design and business needs, an architecture should minimize non-essential complexity by focusing on the problem that needs to be solved and aligning the system design with the business objectives.
Relying on a one-size-fits-all architecture can lead to inefficiencies and inadequacies in addressing specific challenges. An architecture tailored to a specific problem needs to be flexible, allowing components to be added, removed, or modified as the understanding of the problem evolves or as new requirements surge.
Conclusion
Legacy is just a decision made in the past with or without your participation
Problems evolve, influenced by changes in technology, market demands, organizational structure, and other external factors. This means designing systems that are modular, flexible, and capable of integrating new technologies or methodologies as they emerge is hard.
Everybody has some good or bad experience with some (even the same) architecture or technology, every time you build a new shiny design, a new legacy is also built. So every time you face this scenario try to answer the following questions:
What's problem(s) will be solved?
What's the ROI of the proposal?
Who owns the actual (legacy) architecture?
How can the actual architecture be changed? How easy is it to do?
What can be done with the time and people if the new architecture isn’t implemented?
With the above questions answered start building.