In this post, my aim is to elaborate on the role and to create a high-level guide for the people who want to be an Architect.

I had done some reading about the role of a software architect. During that reading, I also took some notes mainly from a great book called Software Architecture Fundamentals, and I want to share my notes with you.

Architects need to take a holistic view of the solutions they design and build, thoughtfully combining programming elements, patterns, and styles with refined leadership and communication skills to create complete and effective software architectures. To be able to understand the role of an Architect, first, we need to define the Software Architecture.

What is Software Architecture?

… the highest level concept of a system in its environment. The architecture of a software system (at a given point in time) is its organisation or structure of significant components interacting through interfaces, those components being composed of successively smaller components and interfaces.

… is a shared understanding between the people who build the system.

And here is my favourite one:

Architecture is about the important stuff. Whatever that is.

Ralph Johnson

If we take a close look at the definition above, an Architect designs an architecture and there are some interested parties around the architecture, and they all have some important stuff. Who are those parties and what are their important stuff?

Product Owner: What kind of capabilities are going to be delivered to me? Is this architecture able to bring my product forward?

Developers: I want to play with the newest and shiniest tools and frameworks and get to do interesting things. So they are looking to the Architect to enable that kind of behaviour.

Operations: How to operationalise this architecture you’re coming up with.

So the point is not only that of a shared understanding, but also of broadcasting that understanding to a variety of interested parties, and often an Architect has enough overview to see all moving parts.

Based on those definitions, we can visualise Software Architecture in three main parts:

  1. Source Code and functionality: All our source code
  2. Overall Structure: The overall pattern of the architecture. E.g.: microservice, monolithic or event-driven architecture. This also involves cross-functional requirements like availability, scalability or reliability.
  3. Architectural Decisions & Design Principles: Architectural Decisions are hard-and-fast rules, whereas Design Principles are more about guidelines.

Some examples of Architectural Decisions:

  • Only the business and service layers can access the persistence layer.
  • All shared objects need to reside in the shared service layer.

Some examples of Design Principles:

  • Inter-service communications should leverage async messaging whenever possible to increase performance.
  • Single Responsibility principle: every module within an application should only answer a single question and be responsible for a single functionality.

Expectations of an Architect:

Now we know what Software Architecture is, the next question is what the main responsibilities of an Architect are.

When we design a software system that meets business needs, there will be business requirements. But in the entire architectural scope, we also have multiple external factors called Cross-functional Requirements or Non-functional Requirements or ‘-ilities’. Part of the role of the Architect is to analyse all of these various factors, the requirements, and all these external factors that go into solving a software solution and actually coming up with a design and a plan of attack of how you can implement this piece of software.

In a nutshell, Architects’ main responsibilities are:

  1. Identifying architectural characteristics and manage those Cross-functional Requirements.
  2. Identifying architectural patterns. E.g.: microservices, event-driven…
  3. Identifying core components, building blocks.

Until now, we’ve defined the software architecture and the main responsibilities of Architects who design that architecture, and now, in order to achieve those responsibilities and design a good architecture, the Architect needs to;

  1. Define the architectural decisions and design principles to guide technology decisions for the company.
  2. Analyse constantly the technology and software environment and recommend solutions for improvements. The question is if that architecture we defined three years ago is still valid.
  3. Analyse technology and industry trends and keep current with the latest developments.
  4. Ensure compliance with the architecture.
  5. Have expertise on multiple and diverse technologies, platforms and environments. Have enough familiarities to know the implications with integrating each of those.
  6. Have a certain level of business domain expertise; use the language that the business uses.
  7. Possess exceptional interpersonal skills, including teamwork, facilitation and negotiation.
  8. Understand the political climate of the company and be able to navigate the politics.

Thinking Like an Architect:

The role and responsibilities of the Software Architect is a challenging one and there is no clear path for moving from Developer to Architect.

When we think about all the knowledge in the universe, we can split it into three sections: the stuff that you know, the stuff that you know you don’t know, and the stuff that you don’t know you don’t know.

So this is all the knowledge in the universe as far as you’re concerned. And part of what you are doing as you advance through your career is making the middle section bigger at the expense of the bottom section, meaning you know that more things exist. And then, gradually making the top section bigger at the expense of the middle section, because you’re learning more things and you’re becoming more expert in all those things. And that’s, in fact, how you become an Architect, by displaying expertise in a variety of different technical areas. But here’s the interesting thing about this in software architecture, which may be different from a lot of other fields; the stuff you know in the software, or the technology world is the stuff you have to maintain. So this is your technical depth: all the things that you are an expert in. And that’s probably the thing that’s most valued as you’re ascending through the role of Developer to become an Architect. But your technical breadth then becomes the more important thing. Because knowing that more things exist is more valuable as an Architect than knowing exactly how to implement something in a particular technology. So, for example, knowing that there are five different concurrency libraries available is more valuable as an Architect than knowing how to implement the solution deeply in one of those concurrency libraries. And so, as an Architect, you need to focus on your breadth rather than your depth.