site banner

Small-Scale Question Sunday for March 5, 2023

Do you have a dumb question that you're kind of embarrassed to ask in the main thread? Is there something you're just not sure about?

This is your opportunity to ask questions. No question too simple or too silly.

Culture war topics are accepted, and proposals for a better intro post are appreciated.

3
Jump in the discussion.

No email address required.

Ok I'll bite, what's a "software architect"?

I mean as a job description.

I've been a software engineer for over 15 years. I have a grasp of what "architecture" means in terms of a large-scale enterprise application. But a handful (not all or even most) of my jobs have had a guy I would sort of report to called a "software architect" and best I can tell he answers some occasional questions about frameworks to use, etc.

But like is that what he does all day? There seem to be long swaths of time when nobody on the dev team interacts with the guy at all. What is he doing then?

I guess what I'm asking is, is this a good grift?

My workplace (eng team is in the 5-20 people range) has someone with the title of architect - most of his job is just normal feature work (we don't have any software developers whose job isn't primarily writing / testing / deploying software), but he's also the one in charge of having and sharing a coherent vision of what abstractions our system is built out of. So for example, "we're doing domain-driven design, here are some examples of changelists that were good, here's the standard folder structure, here is the auto-formatter config so we can never think about code formatting again" style of stuff.

I don't know what the story is at larger companies though, and I've heard a lot of people speak of architects as if they don't do much, so the situation at my workplace may be atypical.

To be honest I think calling it a "grift" means you're probably not prepared to do it.

Yes it can be exactly that. But for your to succeed at it you either have to understand/care enough to do it or be good enough at grifting it to suck the blood out of each org as you move from place to place.

If a Tech Lead can apply their experience and skills to solutions they haven't worked on extensively, and actually do greenfield design, and understand infrastructure, then they can be a good architect. I always call these folks "Keyboard Architects". So many engineers have a tough time looking at the bigger picture of the solution they've worked with for years, much less more than one.

But the title is rife with "Whiteboard Architects" who can only draw rounded squares which I have very little tolerance for. Anyone can imagine a cool solution at a high level or play stump the chump while name-dropping cutting edge tech. My rule of thumb is that if you wear toe shoes you're in the latter camp.

I held this title a number of times in my career. It can mean anything, from "a fancy title to give to a senior developer when you want to give them something but $$$ for some reason is not your first choice" to "a person responsible for overseeing the complex software project and ensure individual developers do the right thing and do not step on each other toes and do not pull the project apart by each doing their favorite thing and ignoring the bigger picture". I know this is also used to mean "an expensive consultant that would sell you some kind of highbrow methodology, supposed to make everything better but you will never know whether it did" - but I personally never been on either end of this one, thankfully.

I guess what I'm asking is, is this a good grift?

The quality of a grift is not measured by the title. Titles can mean anything, and in different companies usually mean different things. But what's a good grift for you? Lotsa money? Doing much less for the same money? Having fancy title that impresses persons of the sex you find attractive? Doing exciting things nobody did before? Being paid for doing whatever you find interesting, without anybody pulling your strings? Hard to give an answer without knowing it. As I said, I personally had this title a number of times, and I like my job and plan to do roughly the same thing as long as there are people willing to pay good money for it. I'd hate to sit around and do mostly nothing all day though, that'd be depressing. In fact, I changed jobs when I had a suspicion that's what is going to happen to me. But I know people who would dream of it. Not judging, to each their own.

There are all kinds of architects around. At the places I've worked there have been:

  • enterprise architects, who are probably the biggest grifters. I guess they are supposed to tell the business what tech there exists that they can leverage, but I've never seen them do anything

  • technical architects, who were in charge of managing the system software and hardware stack

  • solution architects, who would draw boxes and arrows and manage the business software stack

  • data architects, who would look at these arrows and ensure the data would end up in the appropriate system

  • platform architects, who would manage either the evolution of a complex enterprise software or the use of some development platform

I'm probably missing some.

Good platform architect can help in a situation like "ok suppose we want to use AWS for our project, now which services out of slightly over 9000 we'll need to look into to solve this specific set of problems?" - there's probably a specific name for that but I don't remember now. Good data architect is hugely valuable because proper data architecture may mean the difference between running a job for a week or being done in 15 minutes. But those are also very hard to find, in my experience.

But like is that what he does all day?

He draws UML diagrams and discusses them with management.

More seriously it does vary a bit on the company.

In some cases it basically is just a sinecure -- he was a solid developer early on and now the CTO is his buddy and feels the company owes him. He probably knows a lot about legacy systems the company has so they want to keep him around just in case.

How were major decisions about architecture made? Was it just the dev team?

Usually major stuff he was at least in the room for, often (but not always) exuding authoritative energy

Maybe you could set your sights a little higher and become a "software city planner."