LEADERSHIP PERSPECTIVES

Bringing Down the Ivory Tower

A few thoughts on how to build architecture design function in an organization

Architect Ivory Tower (Illustrated by Emma Ping)

Among multiple hats I wore at Procore last year, one was the interim Chief Architect. I was trusted to lead a team of intelligent and capable software architects to define the technology strategy and drive the next-gen platform architecture design for the company. While navigating through the new role, one of my primary responsibilities was to figure out the proper organizational structure to implement the architecture design function with the ultimate goal of effectively driving the SaaS platform architecture transformation and meeting the demanding growth needs of the company?

Coincidently, a similar topic arose when I met with one of my Plato mentees, who is working for a 13-year-old Canadian Series C startup company. He was the VP of Engineering at the company and decided to switch to an individual contributor role a year ago. With his passion for software architecture design and strong desire to stay hands-on on software development, he was trying to identify a career growth path within the company that allows him to do both. He was working with his CTO to explore various options for helping the company create an architecture design function and position it within the company when he brainstormed with me on this topic.

In addition, when I moved to Google, one of my observations was that there is no dedicated engineering role called architects. Neither have I seen a dedicated central architecture team inside Google. Yet, the company can still make high-quality architecture decisions, and it’s known for its ability to build exceptionally reliable, secure large-scale planet-scale distributed systems. At Google, L5+ software engineers (SWE), who Googlers call TLs (Technical Leads), lead the architecture design of a component, a system, or multiple systems across a Product Area (PA), depending on their levels in the SWE ladder. And by following Google’s organizational structure, TLs report to their engineering managers who own the component(s) or system(s) engineering execution, creating a completely distributed organization model from an architecture design function perspective. Such a model sometimes creates execution challenges, such as slow decision-making, high risks of reinventing the wheel, etc.

By now, we can see that the answer to the question “How to build an architecture design function in an organization” is not straightforward. It depends on many factors, such as the maturity level of the engineering organization, the strategic impact the architecture team aims to achieve, the skillsets of the architects, the existing software development process, company culture, etc. Therefore, before answering the question, let’s go back to understanding some fundamentals first.

What is Architecture in Software World?

There has been some ambiguity over the definition of architecture in the software industry. For some people, architecture is the fundamental organization of a software system that determines how its high-level components are wired and interact. For others, it is the collection of the design decisions you hope to get right early in a project.

When I look at architecture in the software industry, I tend to think about the foundational building blocks of the software system that are likely to result in serious problems should they not be implemented right from the beginning. And at the heart of thinking architecturally about software is deciding what those foundational architectural building blocks are and how to implement them correctly. Such foundational building blocks cover the following aspects of the software system: Functionality, Performance, Maintainability, Extensibility, Flexibility, Usability, Accessibility, Customizability, Robustness, Scalability, Security, Infrastructure, and Monitoring. Identifying the foundational building blocks in software development varies with the scale of the context under consideration.

Good software architecture helps ensure the internal quality of software, leading to faster delivery of new features. In contrast, a poor architecture can significantly impede the ability of developers to understand the software, causing slow feature development and resulting in more defects.

Do we still need architects if we are agile?

In the software industry, architecture is done by people who are often called architects or technical leads. In engineering organizations that practice agile development methodology, I was frequently asked about the value of architecture design and what architects can do. The following comment is not unfamiliar to many of us, i.e., “We don’t need to do architecture design! And we don’t need architects! We are doing agile!” Is that the case?

Each software system has an architecture that decides how its key functional elements should work together, regardless of following the agile or waterfall process. It takes lots of thoughtfulness to choose what those elements are and how they interact consciously. However, people sometimes get hung up on whether there are people or teams with the title “architect,” but that should not be the key point. People can call themselves whatever they like. What matters here is the type of work they do. So, yes, if we are agile, we still need people who can do solid architecture design work regardless of whether their titles are architects or not.

How can we build a working architecture design function? What Model should we follow?

As shown in Figure 1, there are multiple models for architecture design. In teams that claim “we don’t need architecture because we are agile,” we often see Model (a) in practice where no one knows how architecture is done. Those teams usually struggle when the system’s performance, scale, and reliability requirements increase. Once they flounder, they often revert to Model (d) quickly, where a dedicated architect team is created to design the architecture and then tell SWEs what to implement. That is the Model that some late-stage startup companies adopt when they reach a certain scale and discover that it becomes more and more challenging for developers to agree on anything without lengthy debates. However, such a model can easily create the ivory towel architecture designs because architects are kept away from the teams from a day-to-day work perspective and are not close enough to frontline developers to ensure their design is pragmatic.

Figure 1. Different Organizational Models for Implementing Architecture Design Function

Model (b) and (c) are two models in which the architecture design function is distributed to each development team. In Model (b), architecture design is a shared responsibility among all senior enough SWEs in the group. Senior SWEs are doing both architecture design and software development work. Model (c) takes a slightly different approach, embedding one delegated architect in each development team. And the architect’s primary responsibility is to create architectural designs and then hand them over to developers in the group to implement. Since the architecture design function is embedded into the development, Model (b) and Model (c) can effectively help us mitigate the risks of creating ivory tower architecture designs. And I have seen success with both Model (b) and Model (c).

However, Model (b) and Model (c) might run into silo-ed execution challenges as the organization scales. Many localized decisions can be made to optimize the execution of each development team. These silo-ed execution challenges often appear when architecture designers across different groups are not making a deliberate effort to keep each other updated on their architecture decisions and thinking holistically across systems built by different teams.

Large engineering organizations usually implement a tiered model to solve this problem, as shown in Figure 2. Again, this is a simplified illustration. For each service area, an Uber tech lead (TL) ensures holistic architecture design and implementation across different development teams with minimized redundancy. Uber TLs from various services form an architecture design council to ensure that the holistic design principle is followed across service boundaries.

Suppose the complexity of the software system further increases, especially when it evolves into a platform. In that case, we might have to build separate service areas within the platform based on their functionalities. For instance, a service area in a cloud computing platform can be called Compute Services, Storage Services, Networking Services, Billing Services, etc. A service area such as Storage Services consists of multiple services related to storage, including Block Storage Service, File Storage Service, Storage Archiving Service, Backup Service, etc. For each service area, we can have an Area Uber TL whose responsibility is to work with each Service Uber TL and ensure consistent architecture design across the entire service area. And those Area Uber TLs would then form their council and jointly work together to ensure each service area makes the right architecture design decisions to create a holistic platform architecture and execution.

Figure 2. Tiered Model for Implementing an Architecture Design Function

Practical Recommendations on Building an Architecture Design Function

Now let’s talk about some practical tips on building an architecture design function, especially for a platform company.

• First, we need to recognize that when it comes to architecture design, there is no such thing as “the only right” architecture. They are always different ways to design architecture. The good architecture fits the purpose in the given context and constraints, where constraints can be related to organizational setups, talent availability, skillsets, business objectives, time-to-market, deployment environments, etc.
• Second, pick a model (shown in Figures 1 and 2) that fits your organization now. Keep it as simple as possible initially, and be ready to continue evolving and maturing it in ways that meet the needs of both the business growth and the scale of the organization. It is okay to start from Figure 1 (a) for early startup companies or organizations whose software is in the prototyping phase. The priority is to get things working as soon as possible and with the least cost possible. However, once you start building Minimum Viable Products with multiple engineers, it is time to consider architecture design. Naturally, you would consider evolving your Model to Figure 1 (b), where you hire senior engineers with the jointed responsibilities for architecture design and software development. As you further grow your software and organization, you might need to move from Figure 1(b) to Figure 1(c), where dedicated individuals would mainly focus on the architecture design. Suppose you continue evolving your software, eventually growing it into a platform offering. In that case, you need to start considering building architecture design overlays, as shown in Figure 2, to ensure the holistic architecture design across many more teams.
• Third, hire senior software engineers with solid architecture design or experienced hands-on architects who are still actively writing or reviewing codes. Without sufficient hands-on, it is hard to ensure that the architecture design is feasible and can be implemented under current talent skillsets, timelines, cost profiles, etc. At the end of the day, we are shipping software, not architecture design docs.
• Fourth, there are different types of architects Enterprise Architect, System Architect, Software Architect, Data Architect, Infrastructure Architect, etc. Although they all have the word “architect” in their title, each comes with different skill sets. Think ahead but not too far ahead. Ensure you understand the skillsets needed to support your organization’s growth and scale, and try your best to hire T-shaped talents. Don’t overhire and over-design to avoid unnecessary complexity.