The Architect Title Over-Specialization
Sometimes in the month or so after New Years, things pop into my head as “micro-resolutions.” Basically, it’s stuff that I ought to start doing that doesn’t rise to the level of importance of altering my life. One such thing is balancing the sorts of posts that I make here. I want to start getting a little more even between how-to/coding, “life of a programmer” posts, and answering reader questions. Toward that end, here’s a reader question.
You’ve mentioned the fact that you don’t like the title “architect”. I agree with you because architect has different meanings for different organizations.
I have [seen] that it can involve writing code, designing UML diagrams or just write Word documents.
Don’t you think that a developer should be [a] programmer who is also an architect and a problem solver?
In my career, I’ve held all of these job titles, so it is with some degree of admitted hypocrisy that I offer my honest opinion. This is certainly a subject that I’ve covered in the past, and covered from a variety of angles. It’s no secret that I don’t put a lot of stock into job titles in general. But I don’t know that I’ve ever, specifically, held forth on the difference between architects and developers, either in terms of what I perceive it to be or what I think that it should be. The question here, as I read it a little between the lines, might be rephrased as, “shouldn’t every developer wear the architect hat” or, perhaps, “shouldn’t architecture be any developer’s responsibility?”
Simply put, my answer to that is, “yes.”
Yes, every developer should be a programmer should be an architect and problem solver. Yes, every developer should wear the architect hat. Yes, all developers should take responsibility for ‘architecture.’ Now, with that out of the way, I’d like to dissect the architect-programmer distinction a bit. And in this dissection, I think we’ll get to why there’s so much of the fuzziness alluded to in the reader question around what the term actual means.
Consider programmer/software engineer versus architect as a study in contrasts (I used this post by Simon Brown as a research point for what people perceive to be the differences between architects and developers).
- Focus scope: programmers focus on details while architects focus on “the big picture.”
- Leadership: programmers are led and architects lead.
- Seniority: architects have been doing it longer than programmers.
- Cachet: architects are important visionaries while programmers do relative grunt work.
- Tech Selection: architects choose while programmers live with the choices.
- Skill: architects are more technically skilled than programmers.
- Code: architects write less code on average than developers.
- Organizational interaction: architects deal more with “the business” in meetings than programmers.
- Pay: architects make more than programmers.
- Value (status): see the last bullet and understand that an architect is more valuable than a programmer.
This is how the industry at large perceives this distinction. Architects are more tenured, important, valuable technical people that are in high demand, but often too important to do the thing that earned them their stripes (writing code). It’s confusing and even contradictory, and this intrinsic role-fuzziness is what leads to the lack of standard across the board. It’s why architects in some organization churn out UML diagrams while architects in others are indistinguishable from software developers except by job title.
The problem is that we cram together orthogonal concerns and ignore any resultant cognitive dissonance. We have a pre-canned narrative that explains all distinctions as long as you don’t examine it too closely. It goes something like this.
Our lives are steady, slow marches toward mastery. We start out young and inexperienced, and with each year that goes by, we improve, are worth a little bit more, and reap the fruits of that effort. The environments in which we work are meritocracies that recognize our steady, gradual improvement and reward us accordingly. As we move along, we thus earn titles decorated with terms like “senior” and “principal” on our way to leadership roles described by things like, “architect,” “manager,” and “director.” The more esteemed the title, the more deserving the person, and the more well compensated and respected one can expect to be. Furthermore, as we progress, we necessarily do more leader-y and business-y things, naturally shedding distinctions like, “detail-oriented” and “diligent” for “big-picture focused” and “visionary.” We become “idea guys/gals.” We get our due.
Against the backdrop of this implied narrative, the role of “architect” and the job title of “architect” both make perfect sense. Both are your reward for paying your dues and ascending to something more important, more valuable, and better than what you used to be. This means performing different activities, serving in different roles, and having different levels of responsibility.
But what if we put aside all of the implied value judgment temporarily? What would you have then?
Well, it’d be a much narrower set of distinctions, and it would look a lot like simple experience differentiation in any number of disciplines. One role would make decisions, focus on “the big picture” and spend less time “hands on” while the other role would take direction, focus narrowly, and be entirely “hands on.” Think of a partner in a law firm making big decisions on cases, while leaving more mundane, simple work to an associate.
But here’s the rub. The hotshot partner and wet behind the ears associate are not doing fundamentally different jobs — one of them is just running point and delegating. If you took this comparison and re-applied it to the programming world, you would have a tenured developer making tech choices (and living with them), writing the hardest and/or most critical pieces of code, and carrying the team, while delegating tasks for which the newer developer was ready.
To then revisit the beginning of the post, any developer should be an architect in the sense that any developer should be concerned with both the big picture of the software and the details thereof. Some will be more skilled and more experienced (and deservedly better compensated). Those are the ones that should be making the important decisions about technologies and about who should work on what. But that is not a fundamentally different role — it’s just a different trust level, and a trust level toward which everyone should be working.
If I were putting together a team of people to deliver software solutions, I sure wouldn’t want to have to go look for two different sets of people: one set of people to do the thinking, broad planning and decision making, and another set of people to do the grunt work. Give me one set of people: those that know how to solve problems, including the problem of taking care of both vision and details.
The entire industry is messed up when it comes to titles. I have seen senior developers that don’t know what is SOLID. why are they senior? because they have been in the company for a while (beginner expert phenomenon). It is true. I have seen some architects that are hands on code. I have seen some architect that got promoted to architects because they have been in the company for 8 years and they are experience in the business, but they have no idea what is web api (because they were writing the legacy code and they never got on… Read more »
I think there’s kind of a historical legacy of organizations letting IT grow from a position of non-expertise. Meaning, you’ve got a company in the 90s that has an accountant or something who is the part time IT Sysadmin. Over the next 10 years, company’s IT/software needs grow, and this involves really nothing more than making that guy a full time sysadmin and then hiring people here and there as the workload increases and more of the business is oriented around tech. Write large across the industry, this means that there were a lot of shops where seniority really was… Read more »
“I have seen some architect that got promoted to architects because they have been in the company for 8 years”. Yes, might be frustrating, but doesn’t have to mean that he’s not the right guy for the job/title. Because he might know the business better than the genius new hire, or he might know the organisation and everyone’s strengths and weaknesses better than the new guy. Because I feel that defining an architecture is not just pure ‘technical skills’, but also business knowledge, customer knowledge,… Also, what to do if no one currently in the company fits your expectations, technically,… Read more »
I agree with most of what you wrote…but it has to come with tech knowledge.
If you are a true architect, then you can switch a job, from being an architect in a payment company to ticket management system with no problems.
if you are just a solution architect that is working for that same company for 10 years and you coding/solutions skills are from 2005 and you got promoted because you are the expert of the solution, know the business, the client, the team, then you might not make it in a new company.
Following the Peter Principle, an architect is a developer or sysadmin or just a blowin who has risen to his level of incompetence.Many an architect is completely out of touch with modern technologies and while they can parrot the buzzwords to keep the business teams happy they may have lost touch due to lack of hands on experience with recent technology, and thus recommend things like standardisation (to ossify previous systems), governance (to keep out technologies recommended by newer generations), strategic sourcing (for vendor dinners), and migrations to the clouds (for more vendor dinners). OK maybe I’m a bit jaded… Read more »
Yeah. I have seen architects that we developers in 2004 and since then their are solution architects, meaning they know the business, which is important but they lose all connection to the tech. now go ask a question about CQRS and that architect is still stuck in the asp.net world.
(unless he is really getting his hands dirty)
Retention of software people is so highly valued in our industry (and hard to do, given the demand) that there’s a natural tendency just to throw title bumps at people every few years. The “architect” one is interesting, though, with its implied lesser degree of coding. I think for a healthy set of people, they think, “nice — I never really liked coding anyway — I’d rather ‘supervise’ ala Tom Sawyer.”
The issue I have seen companies struggle with is the other people, the ones who do want to keep on coding. I feel like in most corporate setups there is no notion of paying someone more money for adding value through quality and efficiency of work.
For HR/managers more money has to equal ‘more responsibility’ in some sense and so good devs either move, become bad managers or are railroaded into ‘architecture’ positions where they slowly lose touch as mentioned above.
Absolutely true. One of the things that I’ve been kicking around a lot in my head as I write the book that I’m working on is just how hard it is for an organization to understand what effect any individual developer has on the bottom line. Absent any clear sense of the value of that individual to the organization, everyone involved just leans on ineffective proxies like “years of experience” and “how much does the manager like the person.”
Someone mentioned Bricks and Mortar architects (BAM) . Taking that as an analogy the BAM does not need to know how to lay concrete or bricks or install plumbing and electricity or glazing. They DO need to know how bricks and concrete work and how to make sure that Electricity and Water never mix and that the roof does not collapse when it rains. Or, in one case I read of, take account of the weight of books when designing a library. What the architect does is plan the flow of activities through the building, using his knowledge of the… Read more »