Very few actual technologies have been dictated in this process. We have architectural standards for how data should be handled and how information flows are supposed to function, but no one dictates what technologies you use to build or deploy your system.
We do have some, like I said, like a national standard for how we authenticate users and handle their rights using something called OIOtokens. They work with standard federated services though, so you can use key-cloak if you’re into Linux or ADFS if you’re into Windows (95% of the public sector) or something else that does federated SAML authentication.
Our dataservices similarly aren’t dictated to use X, simply instructed in how information is supposed to transfer. So you can use SOAP, REST, GraphQL or whatever floats your boat, as long as the information fits the national architecture standards.
You couldn’t do any of this without centralisation. On a lower level, most suppliers adopt the national standards into their own, and then add to them within their own companies or organisations, but that works perfectly fine, because everyone knows the patterns for sharing data and information.
That said, it's good to have somebody who owns the overall vision of the technical architecture, and can be a tie-breaking vote, or exercise veto authority over things when needed.
All in all, I believe the main job of the solution architect is to define, and defend, the "skeleton" of the solution, and then let everybody else hang their respective pieces off of that skeleton. Done right, the skeleton should be just prescriptive enough that any "component" attached to it will work smoothly with the others.
With that said, it seems to me that each tech lead might individually suffer the same problem you have wisely identified - architects failing to keep up. As a result, it's perhaps possible that you might wind up with a committee of tech leads that have useful expertise in their domain but minimal knowledge outside of it.
My experience with design-by-committee is that it can be challenging to get a quality design out of one when members have broadly shared expertise, backgrounds, and interests. It's very possible that putting a bunch of people with different expertise and interests in a group and asking them to design something might get you a far superior design! It may be worth considering that it could also produce one with one with opportunity to adopt a unified vision.
My experiences to date have been that you're absolutely correct - a council of tech leads is unquestionably invaluable for their ability to supply critical technical detail to an architectural project. It just may be worth considering having an owner for the architecture itself, rather than having it be subject to the vicissitude of community ownership..
PS: European. German to be exact. We love to plan and over engineer.
An effective architect assesses _when_ they should constrain choices to achieve the -ilities.
For instance, in projects aimed at learning about the customer or market, you might reasonably defer many traditional architectural goals (maintainability, modifiability, perhaps even secury), while in projects aimed at creating durable long-term value in a well-understood space you probably wouldn't.
I agree with your observation but IMO there is no causality, it's a matter of competence of the architect; and the architect is (should be) in the team, not outside.
In my own experience as an architect, it is the other way around. I can invest in new technology knowledge while we keep our dev teams at 100% workload. When they idle the company practically loose money and cannot deliver to the market (and I know that this is stupid for an individual). This usually results in a situation, that if a team comes with a tech solution, the architect team already has a good rationale about it.
It is not a full
Doing software architecture for the business side of the house, traditional IT, at any company is next to impossible. We are at the mercy of the business and the business doesn't care about standards, efficiencies. or anything, except making the quarterly estimates. The business is very supportive of all efforts right up until they decide that it might impact quarterly estimates, and then everything is out the window. When operating in such an environment there is no way software architecture, or security and compliance has a possibility of success.
On the Engineering or product side of the house especially for software product companies, software architecture is easy, and welcomed.
It all comes down to who you work for and what you are doing.
There is so much noise in the space of Software Architecture. And I think is something natural: building software is not architecture, nor engineering, nor mathematics... still it is all that at the same time. It also has strong social, linguistic and design components. Maybe it is just too new a discipline to define it clearly.
Personally I find these resources more convincing than the booklet or the references mentioned inside it:
For the technical/organizational (Dev teams) part
Architecture without Architects: https://www.youtube.com/watch?v=qVyt3qQ_7TA
Clean Architecture: https://www.youtube.com/watch?v=Nsjsiz2A9mg
For the Enterprise Architect part: