Software engineering is a complex field. As such, it sometimes attracts heated debate around technology choices, frameworks, methodologies, and yes - even titles. One such debate has been happening across the industry around the role of the Software (or IT) Architect.
More specifically, the debate revolves around the question of whether this role is something that has inherent value to the organization and industry as a whole? Or - is it valueless and is simply something used by organizations for all manner of corporate chicanery?
Over the course of my career in software development, I have met many software architects, and at some point, I began asking the question of whether this role was the next step in my career too. Yet, it took me a while to understand how to thrive in this role and how to unlock its true value - to the organization, and for the individual in that role.
It wasn't very clear to me at the time - what was it exactly that software architects do or should be doing. How does one even become a software architect? Are there specific courses or certifications to take? All of these were questions that I was preoccupied with.
Although I only began to understand the real value and responsibilities of the software and technology architect role at a much later time - I had a general idea that there had to be something beyond the typical aspects of the software engineer/developer role that the software architect had to be responsible for.
I knew that the role of the software architect, and other "architect" types of roles exist and are popular within large technology organizations. I also had noticed that these roles seemed to have a lot more sway over management, and the organization at large, than "mere" software engineers.
It seemed to me that software architects deal with matters that are slightly more arcane than pure software development. They would supposedly wrestle with high level design of systems and questions such as:
We have a million user requests coming to our system at the same time - what do we do now?
Yet, most software architects that I have met until then - fell into either one of two camps.
One camp was that of the hardcore software engineer. The kind of person who is deeply entrenched in writing code and is rarely bothered with anything beyond that. Questions of scale, alignment with stakeholders, and setting up the application for the future are not part of what this type of architect likes to be bothered with. There is really no noticeable difference between what that person does and what the rest of the software developers and engineers do.
The other camp were these architects who had absolutely nothing to do with the code or any other "lower-level" dimension of software engineering altogether. These software architects spent most of their time in meetings, coffee chats with business stakeholders, and occasional criticisms of the software engineering team and its practices. Otherwise, they were completely detached and out of touch with anything remotely dealing with software development in general, let alone the team working on the concrete product.
Other than these two camps, there were also the types of architects who seemed to be completely absent from the software engineering process. They may have been officially "assigned" to particular projects, but you were not able to tell as their presence would rarely be felt. What these architect types of folks were working on or doing was a mystery to me and to the other software developers around. It certainly did not feel like these software architects took any active part in our team's day to day work.
All in all, though, the people with the title of the software/technology architect, for the most part, seemed to play an important role as they had been walking around quite proudly through the halls of whichever organization I happened to work for at the time.
Ok - maybe "halls" sounds a bit over the top. They walked in between cubicles or desks within the "Agile", open-space environments of those particular organizations. They had also often participated in meetings. Many meetings. With people who were influential within the organization.
Yet, I was completely mystified as to how one can become an architect. Was it simply a matter of promotion and a natural technical path for software developers? Or was it an entirely new career track?
Adding to the confusion, what was the difference between a "software architect" and "solutions architect"? What about the "IT architect"? Enterprise architects?
Why are some companies omit the architect path and have staff and principal software developers/engineers instead?
Why did some folks who were not software architects seem to treat the software architect role with the utmost respect and admiration while others - with distrust and underlying annoyance?
All of these were questions that I wanted to get answers for. I know for a fact that many others are asking these very same questions right now. I get these questions a lot in my current work as an enterprise technology consultant and career coach.
So in this article, I want to answer as many of these questions as possible. In particular:
What does the role of the architect within technology organizations mean today.
What it is and what it is not?
How can it provide true value to the team,
and most importantly - is this role "fake" or "real".
Before we jump in though, it's imperative to understand the nomenclature around "architect" types of roles in technology. Why are there so many variations of this role and what do they all mean?
First and foremost - know that I am using the terms "Software Architect", "Technology Architect", and "IT Architect" in reference to a general type of role that exists specifically within technology organizations. This is in contrast to a "real" architect that designs actual physical entities such as buildings.
Whether it is correct to call someone an "architect" in the context of software is an entirely different, mostly philosophical, discussion. For the purpose of this article we aren't concerned with that question. Reality is such that this role exists in the context of software engineering and so we will take this fact for granted as such.
The Many "Architect" Roles in Software Organizations
There are many architect types of roles within the technology industry. There are software architects, and solutions architects, enterprise architects, technical architects, systems architects, data architects, security architects, and more.
The term "software architect" is sometimes used as a general reference and at other times as something that is more specific.
To make things clearer, in this article, I am using the term "Technology Architect" or "IT Architect" as umbrella terms that includes all of the various architect-type roles - including that of the software architect. I am using the term "Software Architect" to also loosely refer to Solutions Architects, Technical Architects, Systems Architects, Application architects and others who deal with software applications. The concept of an IT Architect can be further divided into various sub-roles.
Roles such as Data Architects, Network Architects, Security Architects are more niche. Although they are also part of technology organizations, they deal less with the software products and more with the ecosystem that surrounds these products. For example, a network architect will deal primarily with the planning and governance over computer networks. Software products will be deployed in these networks but the work of the network architect is not necessarily to deal with these products in a direct manner.
Everything that we will talk about applies to most of these roles - especially to the roles of "Software Architect", "Technical Architect", "Solutions Architect", and "Application Architect". These roles - although tend to have distinct meanings and responsibilities across different organizations - also have a large degree of overlap and are often fluid and generic enough to be used as synonyms with "IT Architect" rather than as its subtypes.
This lax use of these terms within the industry contributes to the wishy-washy reputation that the role of the technology architect sometimes carries with it .
However, as we will discuss, there are reasons for why this happens. These can be addressed, managed, and fixed.
Below is a list of the most common Technology Architect types of roles with explanations on what they typically are responsible for.
Software Architect - Responsible for all aspects of the software development process and is in many ways a combination of the solutions, technical, and application architect while focusing heavily on the overall design and architecture of applications
Solutions Architect - The main responsibility here is to understand the technology landscape within the industry, products, services, and frameworks involved and to recommend how to solve business problems, create products, and build services using these technologies.
Enterprise Architect - The EA focuses on the overarching interplay between business, technology, and the organizational structures that support the integration of these two spheres. This role creates and maintains technical standards across the entire organization.
Technical Architect - Focuses on the technical aspect of architecture, systems, and components. Works closer with the development team than many other architect roles. Often, dives deep into the different components that make up the system.
Cloud Architect - Focuses on cloud-specific architecture and components. May be confined to one cloud (AWS, Azure, GCP) or multi-cloud.
Integration Architect - Focuses on integrating different systems both internally and externally. Organizations that integrate with external parties will typically have an integration architect to help with these exercises. Deals with things such as API contracts, authentication/authorization mechanisms, and integration standards.
Infrastructure Architect - Similar in some ways to the Cloud Architect but is not confined to a particular "Cloud" environment. Focus here is on anything that is related to how and where your applications are deployed, underlying technologies, and platforms. Oftentimes, less business focused than a Cloud Architect role.
Application Architect - This role's main focus is the actual application(s) and it may touch to some degree on many of the elements that other architect roles deal with.
Data Architect - Data architects play a leading role in building out the organization's data platform and its overall strategy in terms of both storing data, moving data around, and making data accessible and useful to business stakeholders.
ℹ️ The list above is a summary of a larger list of roles from my Unlocking the Career of Software Architect guide where I go in depth into how to succeed and thrive in the role of a software architect.
There are also other roles such as Business Architect, Domain Architect, and Systems Architect, Network Architect, and more. I describe some of these in the aforementioned guide as well.
Now, going in depth through all of these roles would be a subject matter for another day. For the purpose of this particular article however, just know that I will be using the terms software architect, solutions architect, IT architect, and technology architect a bit interchangeably.
This isn't entirely correct because, like we said above, software and solutions architects are subtypes of the more generic overarching IT architect role. However, many organizations use these titles interchangeably and so these roles do overlap quite a bit.
Even when used correctly within an organization by having clear role definitions, these roles have some overlapping responsibilities.
So from here on, consider everything that we say applicable to all of these titles.
Now that we got at least some grip on the different meanings, nomenclature, titles, and sub-titles related to technology architects - there is another important topic we have to tackle and understand.
Something that has absolutely nothing to do with software architects, software engineering, or technology altogether.
On Roles, Title, Occupations, and Organizations
Before we tackle the question of "is a software architect a real or fake role", it helps to understand a phenomenon called the Law of Requisite Variety.
This law states, in a nutshell, that to effectively manage complexity, a system must have at least as much internal variety as the variety in its external environment. What this means in the context of an organization is that the more complex the work, the more complex the organizational role structure becomes. As work gets more nuanced, different roles start to emerge to tackle its different aspects.
To illustrate this, let's take a short detour into another popular technology role.
The DevOps Phenomena
Those of you who have been in the industry for a while, have seen this unfold right in front of you. Take for example the role of the DevOps Engineer. When DevOps began as a concept somewhere around 2008-2010, it referred to a function of software engineering. In other words, you as a software developer/engineer were to take a more holistic ownership over the end-to-end software delivery process. You were no longer just a "coder" but someone who can build pipelines and manage processes that deploy your software into different environments.
That was the vision of DevOps, which literally is a combination of Developer and Operations. However, very quickly, what was envisioned as an extension of the Software Engineering/Development role, became a role in its own right. DevOps became a role in itself - distinct from that of a software engineer.
Now, at this point, some of you reading this will shake your heads in disagreement, thinking
No way! I am a software engineer and I do DevOps! That's the whole point!
Fair enough - I am not saying that no software engineer is doing DevOps. It really is an integral part of software development. Rare is the developer nowadays that doesn't have anything at all to do with DevOps.
That being said, if you look across the industry overall, a very large portion of "DevOps type" of work has been shifted to dedicated DevOps roles. They aren't always called that. Sometimes these are Platform Engineers or Production Engineers or Release Engineers or Build Engineers. Sometimes they are simply "software engineers" who happen to spend 90% of their time on "DevOps" type work. The name doesn't matter. The point is that these folks end up specializing in "DevOps".
That's because the work associated with building, managing, securing, troubleshooting, and maturing CI/CD pipelines has become complex enough to warrant an entire role dedicated to that. Still not convinced? Look at the typical DevOps job requirement:
Infrastructure Automation: Design, implement, and maintain Infrastructure as Code (IaC) solutions using tools such as Terraform, CloudFormation, Ansible, or Pulumi.
CI/CD Pipelines: Develop, optimize, and manage Continuous Integration and Continuous Deployment (CI/CD) pipelines using tools like Jenkins, GitLab CI, CircleCI, or GitHub Actions.
Cloud Management: Deploy and manage cloud infrastructure on platforms such as AWS, Azure, or Google Cloud Platform (GCP), ensuring scalability, security, and cost optimization.
Monitoring & Logging: Implement monitoring, logging, and alerting solutions using tools like Prometheus, Grafana, ELK stack, or Datadog to ensure system reliability and performance.
Collaboration & Culture: Work closely with development, QA, and IT teams to promote a DevOps culture, ensuring seamless integration of new features and rapid resolution of incidents.
Security: Integrate security best practices into DevOps workflows (DevSecOps), including vulnerability scanning, secrets management, and compliance checks.
Incident Management: Participate in on-call rotations, troubleshoot issues, and resolve incidents to minimize downtime and ensure system reliability.
Now, imagine doing all that while also building the actual product. There are not enough hours in the day.
What this DevOps example illustrates is that the role of the DevOps Engineer evolved out of necessity to manage a specific part of the software delivery life cycle. That part, namely the deployment of software to an environment, has become complex enough to warrant its own role in many organizations.
This is not limited to DevOps or technology in general. Throughout the history of human occupation, jobs, roles, and titles have been springing up to address emerging needs that may not have existed 5, 10, or 100 years prior.
Why am I telling you all this? Because, the role of the software architect has evolved out of the same necessity.
The Origins of Software Engineering and Software Architecture
Much like the concept of DevOps, the concepts of both Software Engineering and Software Architecture arose as a response to a need for tackling the growing complexity of software applications and the processes surrounding the creation, maintenance, and shipping of such systems.
The term "Software Engineering" was coined around the early 1960's to denote the rising complexity of software systems in general. It was popularized at the NATO Software Engineering Conference in 1968 as a response to the need for software development processes to evolve.
"Software Architecture" became a concept around the early 90's and was formalized by Mary Shaw and David Garlan in their seminal 1996 book, "Software Architecture: Perspectives on an Emerging Discipline."
The reason was, once again, the growing complexity of software systems and what was necessary to manage that complexity.
As systems became increasingly complex, the skills required to build and reasons about these systems rose in complexity too. It was no longer sufficient to code a system in a particular programming language - which has become increasingly complex as it was.
Suddenly, software organizations had to contend with distributed applications, their integration, the interconnectedness and design of multiple components within the system, constant interplay between the business and technology, as well as thinking of how a system will adapt and evolve into the future.
It didn't stop there. New types of services were being created and old ones were evolving and changing. Databases, message queue, service buses, caches, cloud environments, edge computing, machine learning, APIs, serverless, service meshes, Data Lakehouses, LLMs, and on and on and on.
The proliferation of infrastructure software and solutions and tools seemed to have been rising exponentially with every passing day - not stopping for a second, but only accelerating.
And we haven't even talked about the more abstract items that surround software development these days. Things like compliance to standards, information security, IT governance, data modelling, privacy, user experience, and a myriad other less technically specific and yet ever so important aspects of building software systems.
Now here's the part to remember. At many points in human history, the increase of the complexity within the job market would eventually give rise to new types of jobs. The same is happening in modern times with the field of software engineering and technology in general.
Just like the DevOps role became a thing in itself independent of the role of the software developer or engineer - the role of the software or IT architect has gone through the same thing.
The complexity of building large-scale distributed applications gave a natural rise to a role that will be responsible for some aspects of these applications.
But, what are those aspects and are they really that much different from software engineering/development?
Software Architecture vs Software Development vs Software Engineering
Before we move forward let's also tackle the concept of software engineering vs software development. At their core, they really are synonyms. They are the same thing. The difference is in their origin where software engineering, as we mentioned above, has had a clear and definite beginning. Software Development, on the other hand, is a concept that naturally came into being as a less "formal" reference to the process of creating software applications.
One reason for that was the contention around whether Software Engineering should even be included within the "Engineering" umbrella as that has connotations to physical engineering disciplines. Disciplines such as mechanical or electrical engineering.
The concept of Software Development became a more lenient and loose alternative.
It is worthy to note, that over time, and across the industry, some organizations did draw a distinction between a "developer" and an "engineer". This same distinction was also amplified by using the terms "programmer" and "coder". At different points in time, all of these terms were widely used in reference to a role that primarily deals with the creation of software applications by way of using programming languages and related concepts.
Many still use these interchangeably. However, over time, a sort of hierarchy was built across the industry where someone was referred to as a "coder" or "programmer" to indicate that they primarily deal with producing code. This was in contrast to a "developer" or "engineer" who not only produced the code but also, presumably, dealt with higher level constructs, such as system design, and, to make it even more confusing - software architecture.
There have been many philosophical and rather pointless debates over these titles and the nomenclature that surrounds them. Regurgitating these debates in this article will probably lead nowhere.
Suffice to say that different companies will use these terms interchangeably and they will vary in meaning company to company. At the core of it all though, and for the purpose of this article, let's just all agree that
software developer == software engineer
Now, when it comes to the distinction between a developer and an architect, it helps to think of responsibilities rather than titles. In other words, what are the responsibilities or activities that are involved with creating a typical working software application?
The Many Dimensions of Building Software
Below is a list of activities and areas which are part of the modern software development and delivery life cycle. Although there are exceptions for very small or non-production applications, the vast majority of production-level applications involve all of these dimensions/activities to one degree or another.
Gathering functional requirements for the application - in other words, how does the system behave and what functionality does it cater to the client
Gathering non-functional requirements - Does the system need to scale? Does it need to be resilient? What is an acceptable response time? In other words, this is where we understand what is commonly referred to as the architectural characteristics of the system.
Choosing the Technology Stack - Programming languages, frameworks, libraries, tools, and services for the project.
Producing the application code - this is where you (or perhaps ChatGPT or Copilot, nowadays) create the actual code.
Designing the system's internal components- closely related to the code, this is a higher level activity by which you not only write the code but structure and organize it in a thoughtful way by using design patterns where it makes sense and best practices. Modularity, loose coupling, high cohesion, are all an integral part at this stage. Many would argue that this is not different than writing the code. However, for a project of any meaningful size, that is not necessarily the case. Producing code that will answer a functional requirement does not necessarily mean that you will produce it in a way that is optimal. Usually, extra thought and effort is required for that.
User Interface and User Experience (UI/UX) - Designing the visual and interactive elements of the application, styling, and overall user journey.
Automated Tests - Unit tests, integration testing, End-to-End tests
Code Reviews - Reviewing the code of others and participating in the ensuing discussions
Database Design - Defining the schemas, entities, relationships, indexing strategies, and general data modelling.
Designing the external components of the application and their interaction - How does the system interact with a database? Is there a cache involved? Are there multiple databases? What about message queues, events, API gateways, and a plethora of other components that live around and interact with your application?
Defining the System Boundaries - Identifying the scope, interfaces/APIs, and integration points.
Infrastructure Design -
Identifying hosting environments (e.g., on-premises, cloud, hybrid).
Defining compute, storage, and network requirements.
Selecting deployment models (e.g., containerization, serverless, VMs).
Integration Planning - Managing interactions with external systems or third-party APIs and services.
Security Architecture
Designing authentication and authorization mechanisms.
Ensuring secure communication (e.g., TLS/SSL).
Handling data encryption (at rest and in transit).
Implementing compliance standards - e.g., SOX Type 1 & 2, PCI-DSS, GDPR, HIPAA, and other industry standards that may be required to adhere to for that system
Architectural characteristics and trade-off analysis - Does the system need to scale horizontally? Does it need to be resilient and fault tolerant? To what extent? What are the trade-offs between the different architectural qualities that are required of the application?
Disaster Recovery and Business Continuity -
Setting up backups and recovery mechanisms.
Defining failover strategies.
Planning for system downtime and recovery objectives (RTO/RPO).
Observability and Monitoring -
Defining and setting up logging, metrics, and alerting mechanisms.
Choosing tools for real-time monitoring and analytics (e.g., Prometheus, Grafana, Cloud native tools).
Defining Deployment Strategies -
Planning for blue-green, canary, or rolling deployments
Establishing CI/CD pipelines for updates, dependency management, securing the pipelines
Creating the build process and all of the related jobs, machinery, and checks
Cross-Team and Stakeholder Collaboration - Communicating with outside teams in building the system(s). Translating technical concepts into business-friendly language to align technical work with organizational goals.
Cost Management
Performing cost analysis of various system components - especially when making architectural decisions of one solution vs another
Estimating and tracking development and operational costs.
Optimizing for cost efficiency, especially in cloud environments.
Standards and Governance
Defining coding standards, design patterns, and architecture principles for the team, across teams and the entire organization
Ensuring compliance with organizational or industry-wide best practices and standards
Knowledge Management
Creating and maintaining system documentation
Establishing a culture of knowledge sharing within the team
Innovation and Experimentation
Introducing new tools, technologies, and methodologies to improve workflows
Running proof-of-concept projects to test emerging ideas
Performing detailed technical analysis of different solutions
Working with business stakeholders in setting the vision, objectives, and success criteria
This is just a partial list of items related to the software development process - not an exhaustive list by any means.
There is also a lot more in terms of budgeting, resource planning, people management, product requirements, and so forth - all of which will be handled by roles such as project managers, product owners, and development managers.
There are also numerous aspects that will also be dealt with by specializing roles. For example, Infrastructure Architects and Platform Engineers will handle much of the underlying infrastructure.
In any case, as you can imagine, it turns out that the laundry list of the items above is way too much for one role to reasonably handle. This is both in terms of time as well as the sheer complexity that one role needs to own and reason through.
There are smaller projects, teams, and companies that don't have to worry about tackling that entire list. Within these organizations then, fewer roles are needed to produce software. However, in teams and organizations where the development of digital systems involves all of the above - it is simply unfeasible for one role to be responsible for the entire process.
Hence, some of these responsibilities are divided between "lower-level" and "higher-level" responsibilities. Lower vs Higher in this context refers to a level of abstraction as well as how wide the purview of the role is - rather than an indication of personal experience or organizational hierarchy. Although oftentimes the more abstract matters happen to be handled by those more experienced or higher up in the company's hierarchy - it is not always the case nor it is always a direct correlation.
Another way to think about it is that there are aspects that are internal to the application and aspects that are external to it. For example, the structure of application code is internal to the application while integration with external, third party systems and the architectural characteristics that govern these interactions - are external to it.
What ends up naturally happening is that when the application/project hits a certain degree of complexity, there happens a division of responsibility. Under these circumstances, the role of the software developer/engineer will focus on those aspects that are internal to the application while the role of the software architect will focus on those aspects that are external to it.
Please also keep in mind that this does not mean the two roles have a crystal clear division of responsibility. There is a lot of overlap between them, and one can argue that it has to be that way. In other words, it's not that the software developer will not touch on anything that is "architecture" related or that the software architect will not touch on anything that is "development" related.
It's simply a matter of where each role will focus in order to provide the most value to the organization and being able to tackle something that is reasonable in scope.
The image below summarizes, approximately, the typical focus of responsibility between software developers/engineers and software architects.
The Objections
Now, at this point, there may be several objections.
Objection No. 1: "We don't have software architects and my team does everything you mentioned in that list!"
Sure, I am not saying that your team isn't doing all of these things. In fact, it has to! Otherwise, your application wouldn't exist. But here's the kicker… the fact that your team doesn't have a designated "architect" type of role is irrelevant. The responsibilities are still there, it just so happens that they are spread out among the team in other ways.
Allow me to illustrate with a few possible team configurations:
Team Configuration A:
Junior/Intermediate Software Developers
Senior Software Developers
People Manager
Team Configuration B:
Junior/Intermediate/Senior Software Developers
Staff Software Developers
Principal Software Developer
Engineering Manager
Team Configuration C
Software Developers
Engineering Manager
In some teams, the work that commonly would be in the domain of the architect, would be done by senior software engineers. This is the case of Team Config A.
In other teams, the staff or principal software engineers would really just be another name for a "software architect". This is the case of Team Config B.
Yet in other teams, there won't be any particular division and any developer would really be responsible for any of the activities described above.
What is common to all of these configurations is that in almost every single case, there will be a delineation of these responsibilities - even if that delineation is not clearly spelled out.
For instance, if your team is of Config B, have you noticed that the "higher up" the software developer is, the less hands-on work they do, and the more they focus on the "non-technical" "abstract" stuff?
That's no coincidence. This is exactly what we are referring to in terms of the "delineation of responsibility". It doesn't matter if someone has the title of, for example, a Principal Software Engineer, Software Architect, or even a Senior Software Engineer. If the role's focus is on things such as high level architecture, non-functional requirements, setting system standards across teams, and so on - it is an "Architect" type of role.
Objection No. 2: "FAANG-type Company XYZ does not have an architect role and it's doing fine. More than fine, actually!"
While it is true that there is a large and important sector of the technology industry where "architect"-type of roles either do not exist or have a different meaning, there are some important nuances here that we need to understand.
What usually happens in these types of companies is that, like we pointed out in the previous objection, software architecture responsibilities are spread out differently. Nonetheless, these responsibilities do exist.
Also, these responsibilities may be spread out between software engineers, with Senior, Staff, and Principal engineers typically being involved in the design of large scale systems (ie architecture).
These roles will also liaise with stakeholders and be part of business conversations - much like software and IT architects in other organizations. Also, it is often the case in large FAANG-type organizations, that the people managers of teams may also be involved to a degree in the technical aspects of building these systems - which may or may not be an antipattern. Though that is a separate discussion.
So what really is happening is that the software architect in one organization may be a staff/principal software engineer in another or a combination of roles in a third organization.
And now we come to yet another common objection…
Objection No.3: "A staff or principal software engineer may do all of that high-level architecture stuff across teams, but they are still a technical contributor involved with the systems under their care on a low-level. In other words, they contribute to the code base. An architect-type of role is detached from the low-level workings of the system. That is not right."
This is really the core of the issue and why there is often a negative association to architect type of roles in some parts of the tech industry.
It is the conviction that an "architect" is somehow removed from the software development process and yet has the audacity to dictate to development teams on how to build their software products. It is this conviction that since the architect does not participate in writing or reviewing the code, the input of the architect is irrelevant at best and counterproductive at worst.
However, going back to our earlier examples of the responsibilities attached to software development - the more abstract responsibilities related to software architecture increase and get magnified as the size and complexity of the system/product increases.
Even if you do not have "architect" type of roles in your organization, but you do have Senior+ software developers - many of these responsibilities fall on them as we have discussed earlier.
When the scope and complexity of these responsibilities reach a certain point, the role handling them will inadvertently have less time and capacity to spend on coding and other "lower"-level / technical activities.
To make it crystal clear, if your organization has principal software engineers - think of how they spend their day. Most of their day goes towards communication with stakeholders, cross-team meetings, tackling large scale complex technical problems, and contributing to the overall technical vision and strategy of the product, team, or entire organization. That is exactly what a software or other IT architect type of role does!
Now, your principal software engineers might be involved with the code from time to time, but they will not be involved in it in the same way and to the same extent as less experienced engineers. And if they are - then their role is simply not optimized for the most value it can provide.
More than that, there is nothing to say that a software architect cannot be involved on a lower level with the systems they are responsible for. In fact, this is what distinguishes the best software architects out there - it's precisely that ability to be involved on that level where the need arises. The point is that although it is important for software architects to understand how the system under their care operates on a code level, this is not where they bring the most value.
Just like the principal software engineer, an IT architect can be involved on a lower level. Thing is, they simply do not have the capacity to do so to the same extent as Junior/Intermediate/Senior engineers.
So there really is little difference in this case between the role of a staff developer, principal developer, or an architect. The responsibilities may be the same but depending on the organization, they will be spread out differently and mapped to a different degree and extent onto different roles.
But, what about organizations where -all- of these roles exist at the same time?
Where Staff Developers, Principals, and IT Architects Coexist
Notwithstanding everything we have just discussed, there are organizations where all of these roles coexist within the organization's technical landscape. In those cases, there are two common responsibility patterns:
Pattern No.1 - Same Career Track
This is where an architect type of role (technical architect, solutions architect, software architect) is more or less on the software engineering career track. This career track would typically have the architect role positioned in the career ladder after the staff or principal developer.
The distinguishing features of these roles will look as follows:
⚪ Staff Software Engineer/Developer
🔹 Very technical
🔹 Helps shape the technical direction of a team
🔹 Involved with code but less than senior software engineers are
🔹 Focuses on system design, technical leadership, and architecture
🔹 Collaborates with stakeholders across several development teams
⚪ Principal Software Engineer/Developer
🔹 Very technical
🔹 Involved with code but less than staff engineer
🔹 Helps shape the technical direction of multiple teams
🔹 Focuses on cross-team technical leadership and architecture
🔹 Collaborates with stakeholders across many development teams
⚪ Software Architect / Technical Architect / Solutions Architect
🔹 Heavily involved in overall system architecture
🔹 Can range from very technical to less technical
🔹 May not be involved with code outside of proof-of-concept project
🔹 Helping shape the technical direction and strategy of the organization
🔹 Significant collaboration with stakeholders across the entire organization
Pattern No.2 - Separate Career Tracks
This is where the architect role is in a separate stream from software engineering altogether. Typically, what happens here is the presence of a solutions architect career track. The responsibility of this role is geared towards customer success and pre-sales activities.
In other words, the architect would be involved on a fairly deep technical level with potential and existing clients to help either sell them the solution (as with a pre-sales architects) or build a solution if this is for an organization that is a client already.
This type of a "pre-sales" or "customer solutions" architect is popular in some of the M/FAANG companies such as Amazon, Google, and Microsoft who assign folks in this role to help potential and existing clients to build cloud solutions on the respective platform.
Whichever pattern is used, the organization will most likely have a very clearly outlined description of responsibilities and career tracks for these roles.
There is one other nuance that we also need to account regarding the role of the IT Architect though - regardless of which type of an organization it resides in.
Molding Roles to Personal Preference
In the beginning of this article, we talked about how the evolving complexity of work - software engineering in this case - warrants the creation of new roles. At the same time, as these roles proliferate and expectations around them are built, there is a degree of personal freedom to shape and mold these roles to fit around the way a specific individual works.
To provide a concrete example, think of people that you know in these roles - even within the same organization. You might be thinking of a software architect who is very hands-on and who is working alongside the development team as an integral part of the development process. You might also be thinking of another example that is completely opposite - a software architect who is far removed from the development process and who is dictating things to the team that have little bearing on the reality of the product being built.
These two software architects might be working for the same organization, yet following two very different operating models despite having the same title and role.
The reason this happens has to do with both the degree of leniency to role definitions within an organization as well as the strength of individual preference and individuals gravitating towards one operating model or another.
Few organizations have such a strict and stringent role definition that each and every individual would have to follow that role with 100% accuracy compared to the next individual.
To make it clear, this isn't necessarily a good or a bad thing in itself. As typical in software architecture and engineering - balance is key.
The "best" and most successful architects out there know the degree to which they need to balance the hands-on element of their roles with the ability to detach from details to gain an understanding of the bigger picture..
There is another factor that is at play here, though.
The Lack of Definitions and Guidance
At this point, you might be saying:
ok… there are all of these different responsibilities and it might make sense that we have some sort of an IT architect type of role to tackle these responsibilities. But… in my experience at company XYZ, software/IT architects don't do any of that. In fact, I don't know what they do. What it feels like is that their role is meant to create some sort of an ego boost for technically incompetent software developers who at the same time have the "people skills" to "climb up the ladder".
There are a number of reasons why something approximating the sentiment above may happen. First, it comes from a lack of role definitions in an organization. If the role of the software architect is not properly defined and the right expectations aren't set, it increases the likelihood that people in that role will shape it in the way they want. It will vary with each individual. If that individual is gravitating towards using the role as purely a step in their career, they are unlikely to fulfill the role to its fullest extent and value.
Secondly, and this is true for large organizations especially, the increased complexity of systems, teams, and the sheer number of different roles involved, blur the lines between role responsibilities. What often happens is that the issues that the field of software architecture is meant to tackle get spread out between different roles - even when an architect-type role exists within the organization.
Thirdly, there is another reason, there is another reason for the somewhat shaky image that the role of the software architect has garnered within some organizations.
The problem is that few organizations provide clear guidance to those being promoted into an architect type of role. This is also related to the first point above that talks about the lack of setting clear expectations for this role.
It isn't only that the role of the software architect is not properly defined and communicated. It is also that many organizations do not even know what that role needs to entail so that its full value to the organization is realized.
Even if it turns out that there is an understanding, on an organizational level, of what the value of the IT/software architect brings - there is seldom any education, formal guidance, or path to help individuals get to this role or to excel in it.
Consider the following scenario, which is all too common in many organizations of all sizes.
There is a senior software engineer who really is excelling in this role. This engineer does all the things necessary to get promoted. By all accounts, this individual is considered an excellent software engineer in that organization. Now, let's say that "Senior" is the highest engineering level in that company. The next step is to become a software architect.
This individual is being put in line for promotion, and for good reasons. As a developer, this individual has worked on complex applications, built end-to-end features, collaborated with stakeholders extensively, and had mentored junior engineers. Maybe this individual has burned midnight oil and worked tirelessly when needed to ensure that features are released in time - even under uncertain conditions and through unexpected challenges.
Now, this individual is promoted to that next level which happens to be "software architect". Imagine that this individual is you.
Unless you are aware of what it really means to succeed and thrive in the IT architect role, you will simply continue on the same path as before.
You will continue being an excellent software engineer, but unless told otherwise, it is unlikely that you would pick up the full responsibility set of the software architect role. You will simply not know what these responsibilities are because the organization that promoted you had never put the effort to provide the education on what it means to be a software architect.
You will continue producing system design. You will continue to do code reviews and probably code as part of the project. You will be invited to more meetings with business stakeholders and be put in touch with other architects throughout the organization. But there will be a personal struggle there. There will be a lack of clarity, fuzziness of expectations, and most likely - a level of discomfort at first.
Eventually, you will shape the role however you can. Often - unconsciously. It doesn't end there though. Many individuals who didn't get the right guidance, mentorship, and coaching as they step into these higher level roles, will take their flawed understanding of the role into their next company and the next one, and so forth.
It isn't something that is unique to the role of the IT architect either. It also holds true for principal engineers, managers, directors, and other higher level roles in technology. The reason is that while shifting up in responsibility and ownership, these roles require the careful balance of technical understanding with non-technical skill sets. Getting this balance right is crucial to empower these roles for bringing the most value to the organization and in turn getting the individuals in these roles to thrive and to reach personal fulfillment in these roles.
The Takeaways - For Organizations and Individuals
So what can we take away from all of this? There are a number of lessons to be learned - on both the organizational and individual levels.
What Can You Do As an Organization?
Create clarity around IT architect roles. Set clear expectations and success metrics for these roles. For software developers, this is usually done to some extent. However, for software architects, solutions architects, and other IT architecture roles, this clarity, as we have discussed above, is often missing.
Define and communicate the career paths for how individuals can grow or get into these IT architect types of roles. Also, very important, define how an individual can grow and thrive once in this role. What are the available career paths from there? Is it enterprise architecture, people leadership, or something else?
Provide the tools, guidance, and mentorship opportunities for employees who want to become IT architects. Provide them with what they need to succeed, evolve, and thrive - thereby enabling them to contribute to the fullest extent of their ability.
What Can You Do as an Individual
For individuals who are either aspiring to be a software/IT architect or who want to succeed and thrive in this role, there are some takeaways as well.
Learn the skills that will help set you up for success in this role. There are many free and paid resources out there. If you don't know where to start, I've built a free curated list of such resources on software architecture.
Non-technical skills are of extra importance. These are skills such as communication, influence, negotiation, decision making, writing, presentation, and many others. Often, these skills are neglected but they are the ones that provide you with an advantage and that position you towards advancement in your career. Technical skills are important. However, the non-technical skills are usually the ones that make the strongest difference in this role.
Many companies do not have a clear understanding or plan for how to position software architects for success. Be ready to build such a plan for yourself. As an added bonus, you can make this plan generic enough so that it can be shared at your workplace. This is a force-multiplier activity that can set you apart from other software architects and can help towards your career progression.
Titles are often meaningless as the same title can be used completely differently across organizations and even teams within the same organization. Much of what has been said in this article can apply to architect-types of roles, staff/principal software engineers, as well as technical leads, managers and directors.
Summary
We talked about a lot of things here. Firstly, we discussed the context in which different roles are created. The more complex the work becomes, the more specialized roles are required to keep it going. This is true for any profession in any field. The software engineering domain is no exception.
Stemming from this, the various "architect" types of roles began to proliferate within software engineering to tackle the rising complexity of building software. Things like non-functional requirements, architectural characteristics, technology governance, and oversight of large scale distributed systems within growing organizations are all aspects of building software that go beyond pure software development.
That does not mean that a software/technology architect has to be somehow detached from the applications that they construct. In fact, doing so is an anti-pattern.
Instead, the architect has to be involved and understand how the system functions. It doesn't necessarily mean that the architect will be involved with coding. It does mean, however, that the architect needs to be involved on a day to day basis with the team by collaborating in designing and building the application all throughout the software development life cycle.
Otherwise, the role of the software architect does indeed devolve into what is commonly known as the "ivory tower architect" whose work does little, if at all, in helping the team move forward.
Now, not all organizations need to have a separate role for a technology architect, and if they do - not all organizations name that role as such. Within many organizations, the roles of Senior+ software engineers as well as those of engineering managers bear these same responsibilities. Whether these responsibilities are assigned to a "software/IT architect", "principal software engineer" or "technical manager" is less relevant than the evident need for these responsibilities to be handled.
At the same time, many organizations do benefit from having a separate role that tackles software architecture when the complexity and scale of the systems involved demand for it. The key to this role providing value is that the organization must have a clear understanding of what this role is responsible for and what its operating model is.
Lastly, both organizations and individuals in this role need tools and guidance that enable software architects and equivalent types of roles to thrive, grow, and succeed. Without these tools and guidance, you are leaving the success of people in this role up to chance.
As for the question — is Software Architect a real or fake role?
The answer is — it is as real as any other role in information technology.
I have created the Unlock the Career of Software Architect guide - to provide clarity and actionable insights for software architects and the organizations they support. This guide dives into how software architects can deliver maximum value to their organizations while positioning themselves for success, growth, and career fulfillment. It offers a comprehensive exploration of the essential skills, tools, and knowledge needed to excel in the role of a software architect.
Going beyond this guide, if your organization is grappling with unclear role definitions or is facing challenges with how to empower software engineering professionals and their leaders to thrive - consider using outside expertise.
CloudWay Digital — helps organizations establish a culture of excellence where software engineering professionals and their leaders can thrive, grow, and succeed. We also coach individual software engineering professionals on how to reach the next step in your career.