Jesal Gadhia

The Role Of A System Architect

08 Aug 2023

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

Serverless Architecture from Classic Programmer Paintings

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.

Bottlenecks of Scaleups

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.

Amazon internal service dependency visualization

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:

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:

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.

#211 — The Architect by Comic Agile

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:

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:

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.

Enterprise Architecture Footprints

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.

Career Growth: What Paths After Senior Engineer

The Skills Map of Senior Tech Career Progression

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.

On Thinking Architecturally

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 𝕏!

Related Posts