The role of the software architect remains a subject of considerable debate: it is vaguely defined, difficult to pin down, and sometimes leads to nonsensical responsibilities in certain job descriptions.

I will not discuss here the precise day-to-day responsibilities of an architect within a team or company, but I will attempt, through my experience, to describe some of the aspects and qualities that any architect should possess.

Many of us think that we are the central figure or hero of a team or company, responsible for holding the design or resolving the issues that arise throughout a project’s life. We are certainly not movie stars nor gurus, but we are change catalysts by guiding, enabling, and moving people.

Architects are skilled craftsmen

Skill as in the ability to use a specific set of knowledge to relate to a specific context.

It is a broad definition depending on how the functional, organisational, business, enterprise, marketing, or technical field is.

However, I do not think that an architect must have or pass multiple exams and certifications to master all these fields, but I assume that when facing any new challenge, they must be the reference point to drive the team and the [technical] vision of any project.

You may know that creating software architecture is not a process we can plan in advance; it’s about how you employ your skills and experiences to guide a process with some accuracy. As I often say:

Your intelligence is about the way you approach the solution, not the solution itself.

Remember that the solutions developed for a project aren’t necessarily applicable artifacts for another project, but the effort that went into making those solutions and the experience gained can be seen as a skill that can be reused and considered an asset.

Unquestionably, architects must be logical, methodical, and organised. They must be passionate and self-disciplined with a mindset geared towards achievement.

Architects are storytellers

Alistair Cockburn once said :

“At its core, software development is people inventing and communicating, solving a problem that they do not fully understand, which keeps changing underneath them, creating a solution that they do not fully understand, which also keeps changing underneath them, and expressing their thoughts in artificial and limited languages that they do not fully understand and that also keep changing underneath them, to an interpreter that is unforgiving of error, where every choice has economic consequences, and resources are limited. Software development is a resource-limited, goal-directed, cooperative game, whose moves consist of invention and communication.”

– The end of software engineering and the start of economic-cooperative gaming, 2004

To rephrase his quote, let’s say that an architect must be a great interpreter. They must be available every day:

  • discussing with stakeholders to understand the real needs,
  • talking with the managers to notify and alert them about the risks and how to avoid them,
  • and finally, understanding and driving the teams by giving them the vision, the keys, and the responsibility of what will be built and delivered.

Architects must be storytellers: they must share enthusiasm, engage and excite their audience, be able to explain complex concepts and topics using simple explanations, and particularly build a relationship through their storytelling.

However, semantics are essential. Depending on the audience, the jargon has to be adapted and be comprehensible; as an architect, you have to rule out any misleading understanding and support a clear vision and ideas.

Therefore, dealing with people and being a hub between multiple teams or levels often means knowing how to manage conflicts. Conflicts are usually derived from insecurities (or often ego), which are often unspoken, kept hidden, and are extremely contagious.

As an architect, you have to be a good observer to identify such problems and empathise with them in a very non-threatening manner, often in private.

Architects are doubtful artists

It is tempting to think that the goal of software architecture is solely to build an intricate yet adequate diagram of components with relationships among each other or to choose tools and impose the patterns to implement. Additionally, the completeness of the architecture is sometimes measured in terms of how the architectural artifacts of the system appear.

I’m sorry to say, but this is a narrow view of what architecture is

Architecture is about understanding the requirements, the purpose and the goal of the system, its added value, benefits, complexity, and sustainability.

Note that any implementation is a technical response to a precise requirement, and we all know that we can’t be certain about our choices without being aware of what the final result will be.

As a rule, before any design process, you need to take a step back in your mind and see the design in full function. This needs to be done before any cardboard mock-ups or prototypes are built, and the process should be revisited at every major change point during the life of the project.

The architect has to mimic the user and envisage using the system.
Although the end user is not the goal, their expectations are, and the fulfilment of this goal is the real reason a system will be built.

The better the architect is at visualising this, the better they will be at understanding what needs to be put in place or implemented.

I believe that art is a significant part of software architecture, and that includes the ability to visualise a product ahead of time, to feel it or envision it as a large, comprehensive system in rich detail. It’s not only about skills and experience but more about experimentation, creativity, awareness, and adaptation.

As an architect, you must possess a good imagination and be adept at painting mental pictures.
This skill may be taught, but an aptitude for this activity is critical. Experience builds it, too.
By having this mental picture in your head, the real design process will be more precise and elegant, which does not end until the project concludes.

Architects are negotiators

Undoubtedly, any project is always an acknowledgment of a customer’s purpose, and often the client themselves is the main provider of the trickiest parts of the project: the constraints and the users.
Software is always a tool that any end user needs to simplify and/or eliminate constraints in an activity or a workflow, and often to accelerate the processes by decreasing latencies.

Usually, what’s obvious and trivial to a customer/end user may mean hidden constraints and extra work, thus costs for the project.
In fact, depending on the size of a project, there are several other roles, such as the business analyst function, that can handle much of the work of gathering requirements. Even though an architect might not have to be personally involved in requirements gathering, regardless of the final specifications, the architect always needs to comprehend and feel what the end user truly needs.

Note that for any expressed requirements, end users don’t understand technology, and developers often struggle to understand people! Hence, this is one of the problems that needs to be intelligently bridged.

Understanding the needs, making and evaluating choices, negotiating about eliminating or delaying a request, bargaining about using a technical solution or pattern are the day-to-day tasks of the architect.

As an architect, you need to be a good negotiator, with a broad visibility of the project’s goals while also being detail-oriented to steer the project correctly.

However, architects don’t have to be expert psychologists, but they need to feel how the winds blow in an organisation (customer, managers, stakeholders, team), especially if the winds are not just gentle breezes.
I believe it is a fundamental mistake not to listen to the organisation when creating architecture.

Architects are decision-makers

I believe that any architect constructs the architecture of the solution in a way that enables developers to use their tools effectively.
They enforce high standards and ensure that work on the project is as enjoyable, straightforward, and efficient as possible.

Yet it’s not only about the implementation but about the best practices and the best tools to use to deliver the project.
It’s not about inflated egos and guru-style attitudes, but about decision-making and the choices that need to be made to fit the requirements.

Having said that, Uncle Bob said:

Good architecture allows major architectural decisions to be deferred. The job of an architect is not to make decisions, but to defer decisions as long as possible, to allow the program to be built in the absence of decisions so that decisions can be made later with the most information possible.

Gregor Hohpe rephrases this in his book The Software Architecture Elevator by saying:

[…] Architects are commonly described as the people dealing with non-functional requirements … they deal with non-requirements.

Architecture isn’t good or bad; it’s fit or unfit for a purpose.

Obviously, decision-making is about the context, the trade-offs, the choices, the possibilities, and finally, the proof.

Hence, a software architect is always labelled as the flame keeper who owns the principles of the project: They don’t let stress get the better of them; they assess the goals and values, they evaluate the choices and reconsider them.
They must be a stickler for detail and an enforcer of high standards, while always having the courage to make critical changes to a design when necessary.

Buy me a croissant

Architects are agile wizards

First, let’s assert that:

Adaptability is mostly centred around considering all possible options, identifying opportunities, and devising a plan, whereas agility is more about having the confidence to take swift and decisive action in the face of unexpected change.

Admittedly, one of the primary purposes, and the most valuable one, of the Agile Methods is to deal with uncertainty, such as incomplete/hidden requirements or any potential risks.

Moreover, architecture is a journey on an unknown road where we spend most of our time dodging speed bumps and potholes. Architects must provide systems that can evolve alongside the growing understanding of needs and technology.

Proposing or setting boxed-monolithic-tightly-coupled software or code won’t help you if you have to steer out of a pothole; in fact, it’s a nightmare scenario.
Any system that can’t be touched, that can’t evolve or change, and has no agility at all is by definition an isolated legacy system.

The value of an architecture increases with its ability to change and ensure the sustainability of a system.
Even though many architects may adopt “Fail fast, Learn fast,” this approach has more impact on the overall quality, yet reacting quickly and prioritising changes make your system sustainable by achieving and following suitable architectural patterns.

Architects are influencers and impact-makers

As stated above, the role of an architect is not limited to being labelled as a technical wizard; their interaction with peers inside and outside a project may also compel them to push boundaries, improve overall morale, and influence the general atmosphere.

Furthermore, architects have to break new ground with innovative ideas, spread new concepts, and derive new proposals. Additionally, by taking time to step out of their comfort zone, they’ll create more opportunities and may inspire their peers.

Likewise, by updating their colleagues about progress and sharing their knowledge, they encourage them to share and collaborate with each other.

Architects also need to deliver high quality work and ensure they can be trusted by sharing their skills, oversight, and solid solutions; they must be the person others count on by offering help, patience, and understanding. They are the model to follow and refer to for their proven sense of leadership.

Additionally, architects must speak up, share, state, and defend their opinions by being opinion leaders, but they also need to be great listeners and empathetic.

And obviously, Architects are agnostic

Being technology-agnostic supports the notion that there is no ‘one size fits all’ solution for a particular problem; there are many ways to resolve it.
It also means that the decision to use or not use a technology/component/solution/pattern is an informed decision grounded in wisdom and experience.

Ordinarily, the position of architect is (one of) the natural evolutions of a skilled developer, but as an architect, you have to remind yourself that “technology is a tool,” it can be leveraged or disposed of.
You need to focus on the big picture and understand the limitations of any proposed or potential solution according to the customer’s constraints and requirements; it’s not just about choosing the cheapest solution that you are most familiar with.

Similarly, you need to be flexible, open-minded, and self-confident to explore a wide spectrum of tools, solutions, and brands across the market. An architect’s maturity lies in avoiding vendor lock-in, high dependencies, and ensuring that the architecture accommodates the project while cost-saving without necessitating expensive modifications.

Generally speaking, it’s about the right tools for the right purpose.

Closing

Despite the fact that I penned the first draft of this post about eight years ago, this updated version summarises multiple thoughts, experiences, readings, and findings. I’m sure there is a lot missing here, but I chose not to delve deeply into the low-level/day-to-day details but to share the most common qualities that a software architect must possess.

Let’s not forget that the customer wishes to efficiently and preferably enjoyably use their software, and the software architect needs to focus on realising this while keeping goals clear.
It’s not an easy job, but we must measure our value in our ability to understand hidden requirements and trade-offs, to look and foresee beyond the product and to be articulate while delivering a high-quality package.