[sjg007]

People downplay software architects but I've found it's a critical role. You have to interface between business and stakeholder requirements, modeling the domain effectively, engineering management, product processes and then reality. A lot of business logic ends up encoded in the software so you really want to isolate it as much as possible so that when change is needed you know where to look. That and you have to create a lot of documentation and train new developers and stakeholders. So it's really a job where you spend 95% of your time contextualizing, writing and communicating to others. It's a bit like doing continuous self reflection of a project.

It's kind of a thankless job, do your job well and it's like flowing water and nobody notices you. Do it badly and things dam up quickly.

[rmah]

Back when I was starting out, what your describing was called an "systems analyst".

[sjg007]

Back in the day people were computers.

[Geminidog]

> You have to interface between business and stakeholder requirements, modeling the domain effectively, engineering management, product processes and then reality

This is the Technical product managers job. The architects role is suppose to be an extreme high level view of purely the technical side of the business.

From my own anecdotal experience "architects" who try to fulfill the role to the definition end up being mostly useless.

[nitrogen]

I've had my worst experiences in teams where the Product and Engineering were completely siloed. Things go a lot more smoothly if there's a bit of overlap. Also, many orgs don't have a TPM role, so that falls on Staff/Principal engineers and engineering managers. In fact, roles should be fluid and slightly overlapping, as every team and every org will have different needs.

[pc86]

I'm biased, as an architect, but you can't be a good software architect if you don't know the domain very well - both the industry as a whole, and your company specifically.