Why Everyone on your Team Should Understand the System Architecture (Even a Little)?

In today's rapidly evolving engineering landscape, it has become increasingly important for engineers to have a strong understanding of system architecture. Acting as the foundation of any engineering project, system architecture provides a comprehensive blueprint outlining how various components and subsystems interact to achieve the desired functionality.

A thorough grasp of system design enables engineers to have a better overall understanding of the project's objectives, effectively collaborate with their peers, successfully contribute to the project’s development and implementation, and proactively identify potential design flaws or bottlenecks.

While it may seem daunting to delve into this complex field, even a basic understanding of system architecture can greatly benefit engineers in multiple aspects of their work.

Architecture is a Team Sport

---

“This requires the designer to move from the lonely ivory tower of creative genius into the shared apartment of the team mind.” -  Manuel Dahm

We intuitively understand that software engineering is a deeply social kind of work, requiring close collaboration to coordinate efforts, integrate different parts of the software, and ensure that the final product is cohesive and functional.

It’s understandable, however, that the same intuition might not be extended to architecture design. This is partly due to the legacy of the Ivory Tower Architect, where for years the practice involved having a single Software Architect (or an Enterprise Architecture team) produce detailed system designs upfront and in isolation, and then “imposing” them on the development teams without soliciting or incorporating their input.

Regardless of the legacy — and the persistent tendency in some organizations to view software architecture as a solo, reclusive process — an increasing number of teams are recognizing that it’s a collaborative effort. Successful system design necessitates input and contributions from various stakeholders, most of all the developers who will build and maintain the system.

This reflects a shift from software architecture as a title to software architecture as role or an activity that is performed throughout the entire project lifecycle. Depending on the technical leadership needed and the project’s complexity, teams can adopt different approaches: there might be a dedicated senior engineer owning this role for the project's duration, or a group of practicing engineers who collaboratively review and make decisions.

Regardless of the approach, there are three constants:

1. Architectural decision-makers are also practicing software engineers. Only those with substantial engineering experience can become effective software architects: if you want to make decisions about high level abstractions, you need to understand the underlying systems.
2. Architecture is a team responsibility. Complex systems demand the expertise of experienced Software Architects, who have practical experience coping with difficult distributed systems problems. However, everyone has blind spots, biases, preferences, and unique experiences and knowledge. It’s everyone’s responsibility to understand the architecture, be able to discuss it and point out potential bottlenecks or performance improvements. A healthy give-and-take between different people with different experiences leads to discussions that lay bare the competing trade-offs that a development team needs to make. The team's combined experience is an invaluable asset, and feedback is crucial.
3. Architecture is always evolving. Even though your team will perform some upfront design before starting a project, it’s impossible to foresee every business requirement or technology shift. System design is an iterative and incremental process, and should be a ongoing activity. This includes upfront design for development work like releasing new features, adding or changing APIs, refactoring existing solutions, or migrating to new technologies.

Ultimately, effective architectural decisions hinge on cross-functional collaboration and a shared understanding of goals and constraints. This promotes alignment across the organization, ensuring that the architecture fulfills the needs of all stakeholders.

Stop Architecture Knowledge Loss

---

When a team collaboratively engages in designing the system architecture, they experience many benefits, including:

• More effective communication: A team-wide grasp of the system architecture fosters informed decision-making, reduces misunderstandings, and aligns efforts with the project's objectives. This collective understanding ensures a more integrated and cohesive final product.
• More robust end solution: Inclusive team discussions enriched by diverse insights lead to a more thoughtfully crafted system architecture. Engineers, understanding the system's structure and dependencies, can pinpoint optimization opportunities, contributing to cost-effective resource allocation and heightened overall performance. The result is a more robust and well-designed solution.

However, there is one benefit that stands out due to the current tech environment: ensuring every developer within your team knows and understands the system architecture, significantly reduces the risk of losing architectural information when developers leave, or of making uninformed decisions due to siloed knowledge.

To truly grasp how pervasive and critical the risk of architectural knowledge loss is, let's consider current industry-wide trends:

• The average lifespan of a software system is about 6-8 years, although lifespans for large, distributed systems can realistically span decades.
• The average tenure of a software developer is 1 to 2 years, with the turnover rate being the highest of any industry at approximately 13%.
• Between 2022 and now, more than 435,000 people have been laid off across vast swathes of the tech industry. Cost-cutting remains a key focus for CxOs for 2024, as evidenced by the recent Google layoffs.
• Regardless of the ongoing RTO vs WFH debate, large organizations still need to manage teams working cross-office and with global vendors and partners. Distributed teams remain the norm, underscoring the importance of updated, thorough documentation to enable coordination and asynchronous work.

In addition to these industry-wide considerations, organization-specific reasons also contribute to the concrete risk of architectural knowledge loss:

• The role of an architect varies greatly across the industry. Some companies have eliminated the title, favoring 'principal engineers' for architectural decisions, while others maintain an 'aristocracy' of design decision-making, dominated by dedicated architects or highly opinionated individuals
• Many organization have been seduced by low-cost vendors promising to provide the same skills as team members with years or decades of experience, deciding to outsource system design work. This approach is often not cost-effective, as these vendors lack the specific organizational knowledge needed to tailor system architecture to business requirements.
• The slow adoption of new tools and processes results in a piecemeal approach, where developers often rely on outdated, static diagrams, multiple sources of truth, or, in some cases, lack critical information.

Let’s consider a typical scenario in numerous organizations:

A large software system invariably accumulates complexity over the years as requirements evolve, new features are added, and the system expands.

Given the average tenure and turnover rate of developers, we can expect a multitude of hands and minds to contribute to this system. This means a continuous influx of new code, potentially leading to future legacy issues, and various individuals storing fragmented information about the system's logic and architecture in random places like Google docs or even their heads.

Some developers might document their decisions and system knowledge through diagrams, Architecture Decision Records (ADRs), or other internal documents. However, this is often a time-intensive task that frequently ends up sidelined in the 'backlog.' Additionally, there's typically no enforced standard for how or where this information is recorded. Even when documentation is maintained, it quickly becomes outdated if the responsible developers stop updating it or leave the company.

Without clear visibility and coordinated design, the system tends to sprawl, becoming increasingly chaotic and leading to redundancies and more complex dependencies.

The system might operate smoothly for months or years, but eventually, a new release or update could introduce a breaking change in production. When this happens, the team might face significant challenges and spend considerable time and effort unraveling the cause of the issue.

Given this scenario, it’s clear that when every person within a team has an understanding of the system architecture, the risks of uncoordinated work and knowledge loss are significantly reduced.

Adding to this, the adoption of a purpose-built, collaborative tool to assist engineers in making technical decisions, considering trade-offs, and maintaining up-to-date, accurate system assets, fosters a more cohesive, efficient work environment and contributes to the long-term health of the software system.

Architects are always looking for improvements on how to document, communicate, and understand decisions. - 2023 InfoQ Software Architecture and Design Trends Report

Characteristics of Good Architects that Every Engineer Should Embrace

Understanding system architecture brings significant benefits not only to the team and the wider organization but also to developers' personal development and professional growth.

While coding skills, knowledge of syntax, and familiarity with specific frameworks are essential, the most critical skill in a developer's toolbox is problem-solving. This is a core skill that can be developed with architectural work, along with the additional skill of being able to make trade-offs.

A thorough grasp of system design will develop or enhance these skills:

1. Holistic Problem-Solving: Understanding system architecture allows engineers to gain a comprehensive view of the project, enabling them to address issues from a broader perspective and propose solutions that consider the impact across various components and subsystems.
2. Pragmatic Decision-Making ('Satisficing'): Balancing the need for timely decisions with the pursuit of optimal solutions (especially in a rapidly changing technology landscape) allows for 'good enough' decisions that satisfy current needs while acknowledging constraints like time, resources, and budget.
3. Effective Management and Communication: Understanding system architecture enhances an engineer's ability to communicate ideas and concerns, fostering clear, efficient team collaboration, especially in a distributed teams of specialists.
4. Knowledge of the Technology Ecosystem: Familiarity with modern software architectures and paradigms is crucial. Architects should not only have solid technical knowledge but also be adept at navigating technological alternatives, choosing appropriate architectures, and determining the best tech stack for the organization’s needs.
5. Fostering Innovation and Creativity: A thorough grasp of system architecture encourages engineers to think innovatively and explore unconventional solutions. This knowledge base also enables them to challenge traditional approaches, promoting a culture of creativity and innovation within the team.

Overcoming Challenges in Learning System Architecture

There is often the mistaken impression that you need to know the following before you can participate in designing a system architecture:

• UML (Unified Modeling Language)
• Specific architectural practices (e.g. TOGAF)
• Documents with various acronyms such as HLD, SAD, KDD, ARD, LLD, ADR, etc.

“Architecting” at its core is discussing the pros and cons of a solution and making informed decisions, while also being well aware of the trade offs. Having a formalized method for recording that solution (i.e. an architecture practice or specific diagramming language or document type) can be helpful but it’s not a must have requirement.

The main challenge in learning system architecture is often:

• Dealing with Rapidly Changing Technologies → Technological advancements drive frequent changes in system architecture practices. Engineers must adapt to these changes by continuously updating their knowledge and embracing new technologies, ensuring their skills remain relevant and useful in a dynamic engineering landscape.
• Addressing Complexity → System architecture can be complex and intricate, often overwhelming engineers who are new to the field. A large, complex system will result in a large, complex diagram. The key is leveraging the right tools to “tame” the complexity, allowing you to visualize all the components and dependencies of an architecture in real-time, while also filtering by the architecture branch or feature you want to focus on.

In conclusion, every engineer in a team stands to benefit from having a basic understanding of system architecture. It enables engineers to have a broader perspective, make informed decisions, contribute effectively to team discussions, anticipate challenges, optimize system performance, and communicate effectively with stakeholders. System architecture knowledge enhances teamwork, problem-solving skills, and innovation, fostering the delivery of robust and efficient engineering projects.

---

Architecture visualizations play a pivotal role in planning, deploying, and managing your software system. Don’t use general purpose whiteboarding tools or scattered architecture documentation, use a purpose built, collaborative tool for teams that want better solutions for system design and architecture documentation.