The role of the architect in the software development organization? What is it really, and on which level? Is there a standard? Can we establish best practices for the organizational placement of the architects? Yes, probably to every point apart from the one about standard, but I do not want to come to any of these conclusions, maybe some other time.
Here I want to observe core software architecture and the state of role globally in the industry. These roles commercially range around technical and solution architects, sometimes also getting names like cloud, security, or data architects. Other important types would be domain and enterprise architects, which are lot smaller fractions of the org, and their role is very esoteric in most cases - so, I will not be talking about those this time around.
Part 1 - Overloaded
I would like to discuss architecture as a multidisciplinary trade within a very broad software industry. How did we come here, what is the main direction and why do we need architecture (and do we need architects)?
Method overloading in computer programming means two or more methods have the same name but have different parameter lists: either a different number of parameters or different types of parameters.
Architect as an entity and a role in software development and delivery is the youngest one of the bunch in terms of the time it exists. At the time when software became big enough to need multidisciplinary thought leadership, we just followed the usual mantra of not thinking about it too much. We picked up the name from another branch of engineering, but everything else was still to shape up.
The software passed a certain complexity threshold, and business cases became bigger and more complex, as a snowball of appetite for more money-making capabilities rolled downhill.
We needed someone to make the growth of the snowball sustainable.
A small number of people with a holistic tech view, the ability to talk product language, and a strategic view on their level became distinguished members of the software development environments.
These were usually very experienced software engineers with an affinity to develop their knowledge in other related trades, like product design and management, and/or with very good soft skills to handle stakeholder management, but surely with strong structure and problem-solving skills.
Of course, every organization had its understanding of the role depending on internal structure, product, requirements, and generally understanding of what the position should be. It is what you need it to be, or so it seems.
I want to discuss how we ended up in this lovely mess, and obviously, give my take onstate of it today.
And this is how we came to the state of overload.
Same as the software engineering term, in a general sense, we can use the term “overloaded term/name”to describe a noun/reference that can refer to a multitude of things. This quite usually happens in cases of multidisciplinary existence of the same philosophical approach, school of thought, or similar. Along comes THE ARCHITECTURE.
I belong to the group of people who thinks that it has lot to do with the way the term came to be.
The well architected
Vitruvius, the Roman architect, was the first person who defined multidisciplinary trade, a blend of a few different types of art and engineering that he named architecture. This was in the first century BCE and he wrote a few works on the topic (they are all quite nice to read and I recommend them if you want to do deeper research on the topic).
He also defined what makes a well-designed (architected) building and summarized it into three words - firmitas (solid/strong), utilitas (useful/functionally meeting requirements), and venustas (beautiful/pleasant/like venus - goddess of love).
You are right, the name is familiar, altho to most of you not by knowing the architect Vitruvius, but by knowing Leonardo Da Vinci’s drawing inspired by his work - the Vitruvian man.
Now, we could have a glance at the time this was written - the ancient time when content was created for a select few, usually well-educated, co-located, and in the same informal intellectual competition.
They competed in making philosophical statements that would become these three words that would replace thousands of pages. Very smart and completely disregards anything closer to the common folk.
Skip 2100+ years
We unknowingly just ride the ancient wave of - if you are not entirely sure what it is, just use a handy multidisciplinary term, and voila…
Naming things stops being a problem. Knowing what is going on successfully takes its place, and fewer people see that problem, so it is quite decent work done for today,
It is a temporary solution, but it will serve us well forever.
Preferred and antagonized, desired and misunderstood
Moving into the software architecture space. It turns out that it is not just a handy multidisciplinary term, but the one that tops the charts of the most preferred and the most misunderstood professions.
Is it really a profession, that is the question.
From the perspective of software professionals - the job of the software architect is one of the most appealing jobs in the software-making world and surely one that is the most misunderstood. Maybe because it is not real, and maybe beacuse it is a bit complicated.
From the perspective of the organizations, it is a job often looked at as a silver bullet for solving any organizational or developmental conundrum. You need to grow fast - put an architect or two or three in every team. If you are facing a big risky project, do not worry - just hire an architect. You got a high-value program that is facing delivery issues - you got it, hire an architect. You need a business-savvy tech consultant for your teams - architect what else?
In quite a few cases I have seen this has led to a confusing number of architects being hired by the companies - with a relatively sane range of job descriptions but with an insanely broad set of actual responsibilities. As an architect in different companies, you would do anything from tech leadership to business analyst work, to (unfortunately today quite dominantly) sales work.
If you rely on something as much without understanding it enough - you end up blaming it for your own failures. This way some organizations start antagonizing the role of the architect. I guess in this kind of dynamic, you might need a scapegoat as much as you need a savior.
The new trends straight out of the bay area tell us that we should not have architects in the teams, but should have staff and principal engineers as individual contributor engineering experts who do the architecture.
We think it is not suitable for our organization so we will rename it because the job it performs is still very much needed.
How about understanding the thing for a change?
Part 2 - The way the cookie crumbles
I am offering you a few observations based on some particular architecture role case studies. This is where it gets opinionated :)
TLDR; You probably need a lot fewer architects than you think.
We already established that my opinion is that the role of the architect in many cases will appear unclear to the overall org. This is due to the perception of the architect’s role being overloaded (or maybe multifaceted, who knows).
Case study 1 - “We are partnering with our customers”
Merit-based authority is something we wish for - we also want to be merit-based authority one day. Watch what you are wishing for.
The majority of big old software industry players that defined the industry are companies that are providing products and services to other companies. Growing Saas and cloud offerings that many new companies base their products on has created a need for sales support engineering teams, more account managers, technical sales, etc.
In the old bay area tradition, we decided that names mean nothing. Why would we call something “technical account management”, or “sales support engineering” or something like that and just make it sound dull? Why? There is no need - we can just call it something cool sounding. You guessed it - we call it THE ARCHITECT.
If you are lacking the context here, the other good example would be the company hiring position “Head of Engineering Culture” and promoting it on engineering channels, but the actual job description and position in the company representing HR manager for tech. And, yes, it does make less sense further you get in reading this.
To be completely clear, let’s not diminish the role AWS, Google, IBM, Red Hat, etc, had in shaping the high-quality architecture definitions and frameworks we currently have. They have played a major role in sharpening and making software architecture better, but improving the ice cream recipe should not allow you to call a bucket of cookie dough “a bucket of icecream” even if it is cold (no, not even if it is really really cold).
What we are talking about here are Solution Architecture and similar jobs that are most widely believed to be sales or pre-sales architecture engineering jobs, because FAANG companies are hiring them as such. In most of these companies, these roles even have sales quotas. The same logic as for engineering roles doing the architecture applies - if it is described as a sales role, and it fits in the sales part of the product life cycle, and it is measured like a sales role - it is a sales role.
Observation
I admire the need to push your product, support sales, and do the “right” thing at the same time, especially the last of the three, but it is just impossible in most cases (sometimes people do not care, so it is possible).
Please consider stopping making architects salesmen - you are making the industry go through all the trouble of reinventing the job titles and descriptions for nothing. It is just not helping it mature properly.
Case study 2 - Product Owner, Business Analyst, and mature product development
Point of view - you are creating a growth plan for the software product development company or for a big IT department that enables more classical business of non-software product companies (logistics, retail, etc). As your org grows, your leadership is experimenting with team sizes and compositions and at some point in your growth you end up having two types of POs - ones more classical, oriented towards product design and work with stakeholders, and more technical ones that are doing more analysis, roadmap management support, stakeholder management support, etc. I would say this can be categorized as a Business Analyst role any day of the week, but it quite often goes in a different direction.
In some (maybe more toxic) environments, I have even seen that more tech-savvy / support POs / BAs get organizationally bullied. They basically get turned into PO’s personal assistants and are lost to attrition.
What usually happens as growth keeps going and organizations gain more experience with particular roles is that they would want to split out these tech-savvy roles. Some really figure out that this is still a business/product role, so they just put a BA there, but in lots of cases, ARCHITECTS GET HIRED. This is also a solution architect in most cases.
Observation
As all of the case studies I am providing are the results of growth, they can be considered growing pains.
I am not sure why we should all go through growing pains, in a social and business organization sense, we can easily learn from others’ mistakes. So here is a piece of advice - assess the needs of your organization very carefully.
Not every part of your tech organization needs the same team structure, and not every expert in your org has to be bound to the team and context. Take two examples:
- To keep everything in shape, alignment, or standard obeying, some roles need to be horizontal and transcend the team boundaries.
- Sometimes there is not enough work for certain expertise in one team, but they can act as a consultant or a floating member of multiple teams.
Case Study 3 - architect for every team
We came to understand that multidisciplinary teams need architecture capacity, so we hire architects for every (feature) team.
Now, this particular scenario makes sense in smaller environments, there actually maybe 2 teams in a startup, where you got one team on one technical domain.
As soon as you grow into multiple teams handling various topics per domain (teams becoming actual feature teams), it becomes more complex to figure out. However, what I see quite often (I’d say in the majority of organizations that I have seen grow), we keep following the same pattern.
This, unfortunately, creates the misunderstanding we have mentioned at the start, and architects start doing very localized architecture work, tech architecture of fractions of the cases. Another aspect of this positioning is that architects are positioning themselves as software development generalists in the area slowly moving away from some of the essential involvements like the product, risk management, strategic alignment, and quite often even stakeholder management.
Observation
If one domain area has multiple feature teams, the need for an architecture capacity is differently estimated than the need for engineering capacity.
Engineering capacity (number of people or number of teams) is directly proportional to the current or planned growth of scope. The more we have to build in the coming period, the more throughput we need, and the more engineering capacity we need.
Architecture capacity depends on the need for software design, solution design, technical strategy alignment (, etc) between different topics, different teams, products and tech, and not on the number of teams.
Coming to peace with it - the fact of life
Over the course of the last several years of being in various Engineering and Architecture leadership roles, I was thinking of writing articles like this. At first, it was for going after organizations that are doing such terrible things. I was going to call the case studies I have refined in this article (there is much more material on the topic that did not fit the format) “Facepalms”.
What came to me in the last decade or so, is that I have been a part of multiple leadership teams and have been a consultant for even more. This way I understood that these were the most usual results of hypergrowth - these are the growing pains.
So, I decided to finally put this together - maybe it can help you avoid, or fast-track the development through and beyond these growth phases.
Comments