Ibrahim Sowunmi

Introduction to Architects

In my hard headed (pick and go) continuation of my professional journey. I’ve recently decided, to become an architect. The move towards the role feels like a healthy escalation in technical scope. There will be more responsibility/agency and a somewhat welcomed transition to a more “stable” role.

In this article, I’ll be discussing what an architect is. The functions of an architect and the division of that role in a more “traditional” ecosystem. I will also briefly cover the typical architect titles. After which I’ll touch on the seniority of architects and their roles in relation to each other.

What is an Architect?

Unsurprisingly, this has little to do with the designing of buildings. It does, unsurprisingly, however involve architecting. The Merriam-Webster definition of an architect is.

2: a person who designs and guides a plan or undertaking

At its most fundamental level, this is what an architect is. simple as. Within the software world this takes on additional complexity. To simplify, you’re the brains behind the blueprint when a service is provided.

Functions of an Architect

The function of an Architect describes what they do. I’ll be going over it in bullet points. They will cover the characteristics/tendencies of an Architect

  • They have expertise in different areas whether that be in terms of breadth or depth.
  • Deep domain expertise gives them contextual knowledge of all things in a particular industry.
  • They tend to have deep technical expertise. They are capable of outlining/performing a series of complex actions, or tasks to get something done.
  • Functional expertise through exposure provides them with general business knowledge
  • They are adept at dealing with stakeholders and translating technobabble into human speak.

Being an architect in different companies, with different titles, is ESSENTIALLY the same thing. Depending on what company you’re at and what variant of the architect title is under your name your day-to-day may change. The percentage of your time spent between delegation (people handling), hands-on and interfacing with the businesses is where the differences lay.

Architect Titles

Some Architect titles are more common than others but there are three, in my opinion, that stand out. I have previously alluded to some characteristics that an Architect may exhibit, but there are a few that are especially pressing to me. These titles encompass three particularly common distributions of these characteristics.

  • Solution
  • Technical
  • Enterprise

These 3 are the main techno-functional (tech side and business side) titles that you come across. This is in contrast to project managers, who are purely functional, and devs, who are purely technical.

These titles are based on a mixture of areas of expertise (Functional, Technical & Domain) and scope of expertise (Breadth or depth).

Solution Architect → Broad functional and technical understanding with deep domain expertise (potentially be deep technically)

Technical Architect → Deep technical and broad functional understanding

Enterprise Architect → Deep technical and functional understanding with broad domain (Potentially less technically deep depending on how large the team is)

Depending on the size of the project the roles are combined/rolled up. Just to make things that bit more confusing :)

Architect Seniority

There aren’t absolute titles, roles or seniority levels that I’m outlining. This is closer to “Consultant speak” than absolute definitions. In terms of seniority it is typically:

Enterprise > Technical > Solution

###Compensation

As implied by seniority. EAs are GENERALLY paid the most as they lead entire implementations and can change “hats” on the fly depending on the business need. They are the OG-do-it-all gurus. TAs are generally paid less than EAs. To become a TA there is also a higher technical bar when compared to SAs and even Some EAs. In some cases, a TA can be analogous to “a senior developer who can manage teams and/or be seated at the table with stakeholders”. A SA is not expected to have senior dev capabilities. They are more likely to be heavily weighted against a TA in every other area though.

When you have both neither would necessarily be “leading” the engagement. Although they would both represent different kinds of workstreams that roll up to some kind of manager. Some people would consider a TA to be more senior as TAs (when compared to SA) can be where the “buck stops”. Which is itself an indicator of seniority.

Summary

In summary, I’ve outlined what an architect is. The general tendencies/outlining of the architect roles. The 3 primary (IN MY OPINION) types of architect types and a brief comparison of architects.

This article does not even cover how they sit within the SF ecosystem!

Thank you for reading :)