Architect's Job

The job of a software architect is often nebulous and heavily influenced by the context they operate under. However, I distill an Architect's job into two key components: an Evangelist and a decision Coach.

Architect's Job

The utility of a software architect is questionable. Joel Spolsky has infamously used "Architecture Astronauts" to define career architects who work in large corporations (Like me).

Don't Let Architecture Astronauts Scare You When great thinkers think about problems, they start to see patterns. They look at the problem of people sending each…

Architects have a role in complex organizations, not as "Chief Abstractionists" but as evangelists of ideas and principles. In his book "Building Micro Services "Sam Newman discusses the evolutionary role of Town Planners than Building Architects.

Some of the best Engineering Organizations do not have Architecture Roles anymore; they are either embedded in a Staff or a Principal Engineer role that fits more Organically into the Team.

In a heavily matrixed organization, like most enterprises are, Architects have an essential role to fill. Irrespective of the type of Architect you are; your job boils down to two key elements

  1. Evangelist - Be the torchbearer for the technology strategy, champion the principles that are important to your organizations
  2. Decision Coach- Help teams make technology decisions aligned to the enterprise's goals.


Architects should identify and develop the principles that are most important to the software development organization. These should be designed based on business strategy. Your list should be short and straightforward. It should be broad enough to cover the big picture but specific enough that people can reason with it. Some examples

  1. Internationalization  — All the end-user facing apps should support multiple languages
  2. Availability — All application needs to be continuously available

Principles change less often, but practices that implement these principles change frequently and evolve throughout a project or an organization. Different teams might have a different set of techniques if you are a large organization. Indeed, you would want to keep the variation in the practices to a minimum.

It's an architect's job to be the chief communicator of these principles and ideas deep and wide across the Teams.

Decision Coach

Architects fail when they act as Technology Czar's and push Technical Decisions down to the Team without consulting.  Good Architects empower the Team to decide, provide clarity on the guiding principles, and offer mental models to help the Team reason through the problem.

There are times when you will have to step in and prevent things from going wild, but if you have empowered the Team to make the decisions, they will be much more open to occasional overrides.

Empowering the teams is also in line with the idea of technology decisions moving to edges and more freedom available to the developers.

In a matrixed Organization, Architecture is the owner of the decision model; this doesn't mean that an architect is the final authority of the decision. Still, they are responsible for ensuring the Team performs the due diligence appropriate to the decision. The architect is responsible for ensuring that the Team adheres to the Decision Model.