What is a Software Architect, Anyway?

Part 1 of 2: De-mystifying the Architect Role

“Software application architecture is the process of defining a structured solution that meets all of the technical and operational requirements, while optimizing common quality attributes such as performance, security, and manageability. It involves a series of decisions based on a wide range of factors and each of these decisions can have considerable impact on the quality, performance, maintainability, and overall success of the application.”
— Microsoft MSDN

In the software industry, there is a well-known concept of software architecture, but there is no exact or standardized definition of what the related job entails — leading to a wide variation from company to company. While there are many articles that describe what the role is, this article also describes what the role is not. This is needed because we often see cross-over with other software team roles such as Manager and Developer or Engineer, creating room for additional misinterpretation and leaving important aspects unaccounted for.

In modern software development, an enormous amount of knowledge, effort, and expertise is required to build a long-lasting, reliable product that customers want to use. This includes technology, process, and business domain knowledge. While we should strive to be generalists and understand each aspect, we do need specialists for the more complex work to be able to predict timeliness and quality — we can’t all be experts at everything. Architecture is another focus area of expertise.

So, then, what is an architect? I’ve seen a vastly oversimplified definition of architect that effectively stated “one who documents,” next to the developer who, of course, is “one who codes.” Oh no, no, no. We need to set that record straight.

First Things First — What Exactly is Software Architecture?

Software architecture is difficult to succinctly define because it is a constantly moving target; it morphs every year as new technologies become available at an increasingly fast pace. Add cloud vendor offerings to an already overwhelming amount of variation and choice between platforms, languages, frameworks, libraries, paradigms, patterns, and tools, and the challenge increases exponentially. The goal for an architect in this context is to know what is available and where or how it fits into your ecosystem. They can help by analyzing and ruling things out, thereby eliminating options and narrowing the focus. In some ways, cloud offerings have made the job easier by providing managed resources that encapsulate the important concepts. However, again the challenge becomes knowing what is available, how mature it is, what it’s good at, where it’s headed, and how well it suits the given problem domain from the longer-term perspective. The age-old problem of vendor lock-in needs to be considered here as well, albeit in a brand new form.

Ralph Johnson’s famous definition: “Software architecture is about the important stuff…whatever that is.”

It’s true the “important stuff” changes, depending on the environment and context. Let’s start with the premise, then the architecture encompasses the decisions that have long-term impact and implications.

My Take, Borrowed and Adapted From Various Experiences

• The distinction between a software developer and an architect can be blurry at times. Software architects play an important role in the early stages of the software development life cycle (SDLC), and they are ideally highly active in execution and delivery stages as well. They work in a critical liaison role, helping the business and technical teams work together toward a common vision while addressing needs to meet stated goals within given constraints (budget, time, infrastructure, etc.).
• Architect is a role, not necessarily a rank, although it does require a high degree of technical experience and expertise, coupled with strong soft skills including influence, involvement, and leadership across a broad array of different areas (technical and functional).
• The architect’s job is to guide, not dictate or mandate.
• An architect is not a “super-senior” developer. The title is often used as a promotional rank at the top of the developer hierarchy. This isn’t quite the right way to frame it; rather, it is a tangential job function requiring a distinctly separate, broadened skill set in addition to senior developer skills.
• Just like not all developers are on a career path to manager, not all developers are necessarily on the path to architect. At times, “promoting” a productive developer into an architect role is a promotion into unhappiness and should require additional consideration and alignment with career goals. Architecture is its own discipline and should be approached as a career change.
• As a team member transitions from developer to architect, they may have to change the way they view knowledge acquisition, as they will need to let some of the hard-earned technical depth go. Architects require a great deal of breadth of technical knowledge to guide decision making. A large part of that breadth occurs in the form of understanding the various options, so they can pick the best tool, language, or method for the problem balanced against known constraints.
• An architect must exhibit management and leadership skills to successfully fulfill the duties of the role.

Image source: PluralSight Training — “Developer to Architect”

• In some organizations, the Architect is also the Manager. That is, of course, fine if it works in that organization and aligns with the individual’s career goals. However, this isn’t always the greatest idea because it takes them even further away from the detailed solution. With the rapid pace of technology change, if you’re “hands-off” it doesn’t take more than a few years to become technically obsolete. Before you know it, the critical architecture decisions are being handed off to another senior team member. That’s fine, too, if it works for your team. But, it needs to be recognized that you’ve effectively now split the role across individuals and likely created inefficiencies. It’s important to make sure it’s not getting short-changed, or completely overlooked in the process, as the product matures.
• Architect is also not just another name for a Technical Lead. A handy way to distinguish it is to view it in this way — a Technical Lead makes the team better, an Architect makes the product better. Both roles lead in slightly different ways:

— The Technical Lead leads by inspiring and setting the bar for code quality, process guidelines, and other standards for the development team, as well as helping to solve the complex implementation problems.

— The Architect leads by building consensus, particularly related to competing design and non-functional quality attributes. It is typically up to the architect to make strong judgment calls and decisions around how to optimize design for conflicting priorities and make appropriate trade-offs, leveraging system instrumentation, team, and end-user feedback cycles, and communicating to the stakeholders for buy-in.

— Therefore, the Architect has more strategic focus, while the technical lead is more tactical.

The Architect focuses on non-functional requirements (STRUCTURE)

The Technical Lead focuses on functional/feature requirements (BEHAVIOR)

— The Technical Lead is responsible for figuring out how best to construct the solution within the boundaries defined by the Architect and potentially working with the architect to identify specific exceptions to those rules.

— The entire development team needs to build out the product with consideration for each of these facets but responsibility of definition, guidance, communication, methodologies, and enforcement belongs to these leadership roles.

— Often on small to mid-size teams, the Architect and Technical Lead roles are combined and fulfilled by one person. On very large or complex projects, multiple architects may be assigned with the leader designated as “Chief Architect.”

• The Architect may be, but is not always, the strongest member of the team in a given technology or framework (again, specialists and experts).
• Just like the Developer track, there are different levels of experience and skill in the Architect track.

Neal Ford & Mark Richards (well-known architecture trainers and experts) say it best: “…the nature of knowledge changes as you start in the architect role. A large part of the value of an architect is a broad understanding of technology and how it can be used to solve particular problems. For example, as an architect, it is more beneficial for me to know that five solutions exist for a particular problem than to be a singular expert in only one. The most important parts of the pyramid for architects are the top and middle sections; how far your middle section penetrates into the bottom section represents your technical breadth.”

Types of Architects

There are several types of Architects.

• Enterprise Architect — highly abstracted interaction, across projects and departments/organizations
• Solutions/Systems Architect — focused on solutions, with detailed (less abstract) interactions, across multiple teams/projects
• Software/Technical Architect — focused on a single project, with emphasis on component and library re-use and maintainability, performance, scalability, testability, security, etc.
• Data/Information Architect — focused on how information moves across the system and from one application to another; develops a data map that defines how to store, use, and interpret the data collected.
• Business/Functional Architect
• Infrastructure Architect
• Etc.

Simple perspectives to consider:

Expectations of depth vs. breadth by role

Each type of architect has a different range of vision, and a given architect’s specific role may change depending on the needs of a project or initiative. The gaps between the different ranges of vision may also become important because these represent potential areas for failure in communication and future “misses”.

Lastly, it is also not accurate to think about a progression, seniority, or reporting hierarchy between different architecture roles. These things can and do exist, but they are independent of the varying roles that architects fulfill from the job responsibility perspective. They entail similar job functions, but from varying organizational perspectives, and require similar skills.

Architect Role Responsibilities

The Architect’s responsibility is for the integrity of the entire system and satisfying business goals while mitigating risks. They need to define and guide early, the things that are difficult/expensive to change later and ensure that the business needs and pain points are properly addressed by solving the right problems. Architecture requires a holistic view to see the big picture and understand how the software system works from a high level, while also getting deep into the implementation details (ability to zoom in and out, as needed).

Overall responsibilities:

• Provide Architecture definition (or ‘blueprint’), by applying proven software engineering practices to the problem domain
• Technology selection — Be wary of “hype”, if it doesn’t lend itself to the problem space or team skills and strengths. The inelegant acronym UNPHAT conveys this concept well.
  — Limit choices available during development by choosing a standard way of pursuing application development and identifying criteria to select tools and frameworks to build the application. Sometimes these choices are guided by company standards; often they are not (which creates a different set of challenges).
  — Keep decisions pragmatic, but also strive to stay up to date on modern technologies, to avoid what is known as the “Frozen Caveman” anti-pattern.
  — Understand the team’s related skills and align for the best result.
• Management of non-functional requirements and verify/enforce that they are satisfied as the system evolves; Communicate and document appropriately as technical and related trade-off decisions are made.
  E.g. maintain Architecture Decision Record
• Architecture evaluation and collaboration
• Ensuring cost feasibility of the overall solution from personnel/tools/licensing/infrastructure
• Ensuring the critical security aspects of the solution are accounted for
• Recognize potential reuse in the organization or in the application by:
  — Having knowledge of other applications in the organization
  — Observing and understanding the broader system environment
  — Creating the component design
• Define and maintain the interactions and dependencies among system components; Manage external system integrations and help define the bounded context of the application(s)
• Subdivide a complex application into smaller, more manageable pieces
• Monitor hosting environments (Cloud & DevOps has turned this on its head)
• Communicate these concepts to the development team and provide the path for build-out
• Communicate these concepts to the business stakeholder team and incorporate changing requirements as appropriate
• Seek feedback on designs and communication/documentation for continuous improvement and assessment of proper fit for the problem space
• Help solve development-related roadblocks

Design and Architecture are often difficult to distinguish. Simon Brown’s C4 Model breaks it down to Context, Container, Components, and Code, but this can blur the line even further, as coding is clearly not just an Architect task. A good rule of thumb is to base it on “impact” of the decision to the system, both in terms of short-term and long-term product goals and requirements. In any case, the Architect has responsibility for ensuring any design change fits the overall architecture definition and ensuring that vision is clear to all.

Everyone on the team is responsible for providing technical documentation. The Architect and/or Technical Lead is responsible for setting the standard and ensuring it gets done to enable building and supporting the system.

A Software Architect must also maintain responsibility for writing and reviewing code. It is particularly important for Agile and iterative methodologies where the early architecture is designed and documented only informally or as a prototype system, but the final architecture “emerges” throughout the development of the product along with detailed requirements definition. Without this involvement, there can be no meaningful enforcement that the development team is building to the evolving architectural design, adding risk to the project, with the additional pitfall that the Architect isn’t getting the built-in feedback they need in order to know that their designs actually work in practice. Staying involved helps keep them firmly grounded in the real world, away from the perfect boxes and lines in the diagrams. The Architect sets the direction and steers the team toward the destination, which may in fact, be a somewhat moving target.

Further Reading — Part 2 of 2: We’re Agile! Why Do We Need Architects?!