What I would expect is what I actually have: you own the design and architecture of your own work, but you get feedback from more experienced people on your design proposals until they are in line with what the more experienced people would expect.
That's sounds preferable to having a few blessed folks do all the high level planning, completely detached from the lessons being learned from trying to implement those ideas.
Anything that harms those feedback loops is going to create pain.
Absolutely reasonable, however how do you know who are the more experienced folks?
In a small organization, that's doable, but when you get to 50 engineers, knowing who to ask is important.
The legwork, thinking, and writing come from the software engineers who are also going to be building and maintaining the thing. The review simply verifies that their plan is reasonable and perhaps suggests some angles they hadn't thought about. Reviewers are engaged in the same kind of work as the people going up for review - which is how they are able to make useful suggestions. After the meeting, some will be going back to coding, others to investigate the alerts they just got paged for, others to design/UXR workshops, others to go run sprint planning, etc.
I would expect an Architect team to deal directly with the product requirements, stakeholders, etc. and produce a design that they hand off to others to execute, while they move on to the next set of requirements. Architecture is part of the project lifecycle for everyone. This process is simply the architecture complement of code review, only slightly more formal.
What happens in case the design is actually highly incorrect, will the people restart the work from scratch?
Regarding the Architecture team, that's literally what caused problems in so many companies, that's the definition of how to have bad architects: the architects are so disengaged with the system that they cannot make recommendations.
An architect team should be highly integrated, participate in the coding aspect and only once something is shipped, moves on.
We schedule follow up meetings with smaller groups of interested parties about the areas of controversy or deficiency.
>An architect team should be highly integrated, participate in the coding aspect and only once something is shipped, moves on.
At that point, why are they a separate role or team? That sounds pretty close to architecture being one of the responsibilities of the main development team.
Someone who is functionally part of the development team but has more experience than others and some kind of supervisory capacity over technical direction is, in my world, a senior or staff engineer. Do you also have those? How are they different from architects?
How are you going to design database schemas if you don't know Postgres? Controllers and models if you don't know Rails? Components if you don't know React? I don't think design and usage are such separate skillsets.
Put another way, wouldn't you want the Postgres expert to design your Postgres schemas? Or the Rails expert to lay out your Rails application?
Again, I agree on that, my perception of architect is that it's a strongest software developer with a high specialty in designing systems.
It shouldn't be a person out of the software loop, it wouldn't make sense.
I never intended to create a low bar for the title, nor a separate role from "software developer". I'd expect the architect to still be a software developer able to contribute to the existing stack.
There are two stages: an architect defining the big picture and then a technical senior person reviewing the small picture. You describe the later. The big picture you cannot do like you describe.
I guess that depends how you define “big picture.” If you’re talking as a company what kind of infrastructure are we going to buy, what will be the storage platforms, ingress, message brokers, service mesh, sure. That is handled centrally by a platform group, which gives product teams a relatively constrained sandbox to play in. But specific products, features, and services are handled directly between product management and senior engineers, with a design doc reviewed by other senior engineers. No one has the title Architect and the same person generally owns architecture and implementation of the same functionality.
What if the feature/module designed has to interact with other parts of the system?
I saw that all the time, it's really hard to identify the right partitions in a system. It requires a lot of research and experience. Whenever one of those partitions is missed/overlooked, the software gets muddy and hard to work with around that area.
When brought to the extreme where very little boundaries were identified, this is common in CRUD apps where entities are confused with partitions the entire time, every change to the code ripples from the database all the way to the frontend.
In Rails world, this is a highly common problem: a change to database schema affects the UI directly, so every time something is changed in the schema, the following has to change:
- JSON renderers
- React or HTML views
- db schema
Thinking though those kinds of issues is bread-and-butter software engineering, we would not work with anyone past new intern/new-grad level who couldn't handle that.
That would be amazing, but we are faced with the reality that when a lot of people need to be hired, the bar can't be that high, or there is literally a barrier in how many people you can hire.
If you are in a smaller company, totally agree. Get way stronger foundational developers.
