I recently joined a group of architects that aren't responsible for delivering anything and you are not totally wrong. But it isn't the architect role to involve themselves in weeds of the implementation - that's your job. They should be helping if the project is falling behind, though. Then again, if the project is falling behind, then that is probably more indicative of a poorly-run product team and/or a bad SDLC process.
Then again, if the project is falling behind,
then that is probably more indicative of a
poorly-run product team and/or a bad SDLC process.
That's a worrisomely glib take on the impact that architecture can have on the project especially since in practice "architecture" includes the choice of language, platform, and tooling for a project.
Architecture choices directly or indirectly affect every line of code, every minute, every meeting, everything. As you said there are plenty of other places where things can go bad. But it's galling to hear an architect say, "Probably not the architecture, must be something else."
a group of architects that aren't responsible for
delivering anything
And here's the root of the problem. The craft of delivering software is, well, delivering.
The code itself is often somewhat trivial. Effective delivery is all about working about quirks and potholes and traps in the toolchain and architecture inefficiencies.
As we all know software moves fast, and once you've divorced yourself from the reality of actually delivering anything at all, your knowledge quickly decays. You know abstract concepts and how to draw the rectangles on the whiteboard, but before very long you don't know how anything at all actually happens and soon you are unqualified to tell anybody else how to do it.
There can be exceptions to this rule, like projects with an extraordinarily stable toolchain and environment. If you've been writing COBOL at a bank for 40 years you can probably step back into an advisory role and benefit the company by getting yourself out of the trenches and guiding others instead.
If architects are responsible for shipping features, they won't have time to be platform-wide architects. If you are shipping product-level features, you are on a scrum team and if you are on a scrum team, your other platform-wide duties are not your priority. At some point, companies realize they need people focused on the full picture, and they end up calling them architects.
It's certainly true: architects' primary focus needs to be that architecture/platform work.
Architecture isn't something you can just do on the side when you've got some free time, while still crushing out feature requests and bugfixes 40-50 hours/week.
But.
Architects can't be so detached from shipping code that they have no idea how things are actually made and shipped.
Otherwise you get situations like aloof architecture astronauts casually dreaming up complex distributed or microservice architectures, which look great on the whiteboard, but entail an enormous shift in thinking, tooling, and processes. As well as lots of overhead in general compared to a monolithic architecture. Sometimes that is the right move, but it is a costly one and not a shift to make lightly.
Had another "architect" 20 years ago dream up what was probably the world's dumbest architecture. He demanded that all application layer code be stripped out. We were going to build an entire interactive website with nothing but XML and XSLT. Where conditional logic was required, we could use conditional XSLT <xslt:if> statements. He tried to have us implement a social networking site with that. Had he tried to ship a single bit of code he would have realized it was insane.
Also recently had architecture astronauts push an entirely new primary language on the team. The old one was deprecated. This change was largely championed by people who had never written a line of code in either language with no thought to the tooling changes, process changes, or the overhead of throwing away 10+ years of company-wide language expertise in Language X or the ramp-up time and bruises that would be required to get good at Language Y.
After all, what did they care? They're architects.
One way to avoid/mitigate this is to have architects build and ship proofs-of-concept and reference implementations using the proposed shiny new architecture bits before the rest of the team is expected use and master them. Learn as many of the speed bumps and potholes as possible. They should continue to do this and work closely with scrum teams as those teams build and ship. (That may sound obvious, but lol @ this industry)
With examples like that, I can't blame you at all for being skeptical. Architects should definitely deliver POCs and/or reference projects for totally new stuff.
Yeah. In those negative examples, clearly the root of the problem was "architects making bad calls" and not necessarily a fundamental argument against the existence of architects.
But, when the role is poorly constructed, it's a nearly guaranteed mess.
One could say the opposite extreme is just as bad of course. Without architects, you have a bunch of unherded cats. That's also true.
Must the "platform" be so different from a "product"? I think a platform team should think of their output as a product, and so should the rest of the company. Have a PM, scrum or whatever, normal engineering titles, all the usual trappings.
And then you conveniently avoid the architect title!
I just hope one day I am good enough at programming to draw some boxes, tell someone else to figure it out, and then blame them when it doesn't work out
It's the job of all engineers involved to utterly understand one another. That goes for junior engineers cranking out unit tests as well as for architecture astronauts.
If someone here is a junior and gets "figure it out" from some strategic level engineer, ask professional for clarification or a team-up until you understand. Involve management if the other engineer is uncooperative or fails to help. It's their job to explain slightly more than it's your job to understand.
If all else fails, find an organization that expects the architecture astronauts to be explainers in chief as well.
