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.

References

• The Cult of Best Practice

• THE FRUGAL ARCHITECT

• Domain Driven Design

• Conway's Law

No Degree Engineer is a dedicated space where I'll share my personal experiences, where I aim to share the insights and lessons I've gathered over the years about creating and managing large-scale, resilient, and efficient tech infrastructures and, what I learned building, organizing, and leading tech teams.

On Substack, I aim to write more frequently (I'll try monthly), using a newsletter format to bring these experiences.

Why No Degree Engineer?

My career path has been unconventional. Rising to a senior leadership position in the tech industry, I've navigated the complexities and challenges without a bachelor's degree and this inspired the name of this page.

I spent two and half years on my Bachelor's degree in Information Systems, which I didn't graduate, mainly because of personal life circumstances. A few years later, my job application was declined because I didn't have a Bachelor's degree, even after going through the entire interview process.

As a result, I decided to become a student again. This time, I enrolled in a Bachelor of Technology in Analysis and Systems Development mainly because this course was shorter, lasting only two years, and allowed me to skip several classes. During this period, I was already an experienced professional, which made the classes feel very boring. Coupled with some life circumstances, I once again didn't graduate.

Disclaimer: I'm not advocating against formal education, unlike that, this is my personal history.

Despite not graduate I gathered a lot of knowledge about the foundation of computer science that helped me to leverage my career which proves the importance of formal education.

Learn to learn

There are several other notable autodidacts over history, but Leonardo da Vinci characterizes these characteristics he was an Italian polymath: painter, sculptor, architect, musician, scientist, mathematician, engineer, inventor, anatomist, geologist, botanist, and writer.

The tech industry is dynamic, where things are changing every day, and experience and how you’ve done something before aren’t as important as the ability to think and learn new things.

My daddy tells me that when I was a kid I asked a lot of “why”, and named me “why-boy”. My curiosity drove me to the path to becoming an autodidact capable of learning almost everything I needed during my career to deliver projects.

The journey shaped my perspective, proving that it's possible to succeed in a professional career not going through the traditional academic paths but also with determination, skill, and continuous learning.

Your presence here is not just about reading content; it's about sharing a journey where every step challenges expectations and redefines possibilities. Whether you're carving your unique path or seeking diverse perspectives, I hope my stories resonate and encourage you in your endeavors.