The Role of a System Architect

Unraveling growth challenges: Could a system architect be the solution?

Most startups that go through hyper-growth tend to face the inevitable Bottlenecks of Scaleups, as masterfully described by ThoughtWorks.

Having navigated the hyper-growth journey myself, I’ve witnessed firsthand how these technical bottlenecks can impede business progress, causing churn and chaos.

In light of these challenges, I wondered if a system architect's role could hold the key to identifying and circumventing these bottlenecks and reducing complexity like this infamous Amazon Deathstar.

To that end, this article explores the benefits, operating philosophy, guiding principles, job description, career progression, success criteria, and implementation approaches for the role of a system architect.

Benefits of having a System Architect

My hypothesis is rooted in the belief that a clear and purposeful approach to technical architecture can prevent false starts and accumulating tech debt.

Picture a system architect whose sole responsibility is to observe the big picture and facilitate knowledge sharing across teams, breaking down silos for better collaboration.

This individual would need to possess exceptional skills in designing and managing the overall technical architecture of a system. Their role includes assisting teams in defining system components, services, and interactions.

The benefits of having a system architect would ultimately translate into:

• Improved alignment and coordination — Foster a common goal and architecture across teams, leading to more efficient and effective development.
• Enhanced technical expertise — Offer a deep understanding of system design and architecture, guiding and mentoring other engineering team members to elevate the organization’s overall technical capabilities.
• Improved quality and performance — Co-create a well-designed system architecture to boost performance and reliability, resulting in quicker time-to-value, better user experiences, and heightened customer satisfaction.
• Reduced technical debt — Proactively manage system architecture to prevent tech debt buildup, saving time and resources in the long run.

Harmonizing With the Agile Philosophy

You may be curious how this role fits into the agile methodology that many organizations follow. On the surface, the role of an architect may be antithetical to being agile.

However, several sources discuss the role of an architect in an agile environment. For example, Agile Architecture describes it as:

The role of the architect in an agile project is to provide guidance and direction to the team on the technical aspects of the project. The architect is not a dictator, but rather a facilitator and coach, who helps the team find the best solutions to their technical challenges.

Similarly, the Scrum Alliance discusses the role, stating that:

[the architect] is responsible for guiding the team to make technical decisions that align with the project’s goals, scope, and delivery schedule. They should be able to communicate the technical vision to the team and help the team understand how their work contributes to that vision.

Large-Scale Scrum (LeSS) Framework’s view on the architecture role is more philosophically aligned with how I see the role. The following statements on the Architecture & Design page in the chapter “Technical Excellence” shape their opinion about software architects:

• The sum of all the source code is the true design blueprint or software architecture.
• The real software architecture evolves (better or worse) every day of the product, as people do programming.
• The real living architecture needs to be grown daily through programming by master programmers.
• A software architect who is not in touch with the evolving source code of the product is out of touch with reality.
• Every programmer is some kind of architect–whether wanted or not. Every act of programming is some kind of architectural act–good or bad, small or large, intended or not.

LeSS promotes the idea that architects are regular team members. They should participate in hands-on engineering and especially mentoring through design workshops and pair programming. LeSS warns against architecture astronauts (a.k.a. PowerPoint architects):

These are the people I call Architecture Astronauts. It’s very hard to get them to write code or design programs, because they won’t stop thinking about the architecture… They tend to work for really big companies that can afford to have lots of unproductive people with really advanced degrees that don’t contribute to the bottom line.

Guiding Principles

Now that we have some grounding philosophy behind a system architect’s role in an agile organization, let’s discuss the guiding principles of this role.

For this, we don’t need to reinvent the wheel. Principles proposed by Agile Architecture hold strong:

• Value people — You must recognize the value and importance of people and their expertise. No dictators or PowerPoint architects.
• Communicate! — Communicate effectively with all stakeholders and tailor information to their needs.
• Less is more — Minimize complexity and strive for simplicity in design and communication.
• Embrace change — Be prepared for change and welcome it as an opportunity for competitive advantage.
• Choose the right solution for the enterprise — Customer centricity. Make sure the solution is right by verifying it with the customer.
• Deliver quality — Foster a culture of craftspersonship and sustainable development at a pace that can be maintained indefinitely.
• Model and document in an Agile fashion — Leverage proven and effective modeling/mapping and documentation strategies.

Carving the Job Description

Equipped with the guiding philosophy and principles, if you were to recruit someone for this role, let’s see what the job description could look like. A system architect typically collaborates with other teams in several ways:

• Guide system design and architecture — Provide guidance and expertise to other teams on how to design and build systems that align with the overall architecture of the organization. This can involve working closely with teams to understand their needs and requirements and recommending the best approaches.
• Review and provide feedback for technical designs — Review and provide timely feedback for RFCs proposed by teams. This can involve evaluating the proposed designs to ensure they align with the system’s overall architecture and do not introduce any potential issues or technical debt.
• Help resolve technical challenges — Help teams resolve technical challenges during development. This may involve providing guidance on approaching a particular problem or working with the team to develop a solution.
• Participate in planning and estimation — Participate in planning and estimation meetings with other teams. This can involve providing input on the technical feasibility of proposed features and estimates for the time and resources required to implement them.

Overall, the specific ways in which a system architect collaborates with other teams will vary depending on the needs and goals of the initiative and the members working on it.

Navigating Career Progression

Now that we have a job description, one may wonder how someone would become an architect and what would their career trajectory look like.

Various avenues exist for senior engineers to advance in their careers. On the individual contributor (IC) path, adding a system architect role alongside roles like SRE, Data Engineer, and Staff Engineer is a viable option.

Illustrations below help visualize what that may look like courtesy of CodeCapsule.

Note the key difference between an architect and staff/principal engineers: while the latter focus on ensuring their teams’ work functions correctly, architects take a broader view, looking after how all the pieces fit together.

Before you ask, yes, staff and principal engineers also do think about how their work fits into the broader ecosystem, but most often, they don’t consider that their full-time concern.

This role sits at the intersection of ‘What’ (is it we are trying to do/solve) and ‘How’ (are we going to approach the design), and ‘Why’ (are we doing it this way) as described by Peter Cripps.

Becoming an architect also has to do with having increased communication and relationship skills, on top of solid tech skills, as ‌architects have to deal with and influence larger groups of people across multiple teams and organizations.

Measuring Success

Introducing the role of a system architect into an organization is a strategic move aimed at improving the technical architecture, fostering collaboration, and overcoming growth challenges.

However, to validate the effectiveness of this role, it's essential to measure its impact and quantify the value it brings to the organization.

Here are some potential KPIs that can help gauge the effectiveness of the role:

1. Technical debt reduction: Measure the decrease in technical debt over time as a result of proactive architectural decisions made by the system architect. (Related: How Google Measures and Manages Tech Debt)
2. System performance and reliability: Evaluate the performance and reliability metrics of the system after the system architect makes architectural improvements.
3. Collaboration and team satisfaction: Conduct surveys or feedback sessions to gauge how well the system architect facilitates collaboration and team communication.
4. Time-to-Market reduction: Determine how architectural improvements by the system architect have contributed to faster product development and time-to-market.
5. Resource optimization: Assess how architectural decisions have led to better resource utilization, whether regarding hardware, cloud services, or personnel.
6. Impact on productivity: Analyze the impact of architectural improvements on the productivity of engineering teams.

Measuring success should not be a one-time activity. Adopting a continuous improvement approach is crucial, wherein feedback from stakeholders, teams, and customers is regularly collected and incorporated into the system architect’s strategies.

Feedback loops enable the system architect to adjust their approach based on real-world experiences and emerging challenges. This will help protect the organization against a gatekeeper or an ivory tower architect, which would be antithetical to the role’s intention.

Considerations for Implementation

Differentiating from EMs and Senior/Staff/Principal Engineers

While engineering managers (EMs) and engineers are usually involved in making architectural decisions, their focus is typically on the domain or squad they operate in. The system architect’s distinctiveness lies in their primary focus on enabling effective cross-squad collaboration and communication, particularly regarding cross-cutting technical implications.

Reporting structure

A role like a system architect often reports directly to engineering leadership, offering broad oversight and visibility across multiple teams. As such, it may be positioned under a Director or VP, or above, depending on the organization’s hierarchy.

Determining the number of architects

Given the depth of domain knowledge required, complex domains may require experienced architects. Hiring for this role may entail identifying existing engineers with the right skills and interest in stepping into the architect role. This may affect the pace of filling the role based on the current team’s availability and skills.

In Closing

In conclusion, I hope this exploration helps gives you a better sense of how this role could be introduced and the benefits it could bring.

I’ll leave you with this timeless video by KRAZAM. Enjoy!

---

If you liked this post, 🗞 subscribe to my newsletter and follow me on 𝕏!