3 ms·

Don't you think that centralising the responsibility of the architecture design is an antipattern? For what I saw normally architects can't keep up with all mod

Don't you think that centralising the responsibility of the architecture design is an antipattern? For what I saw normally architects can't keep up with all modern techs and if they do, it still takes the ownership of the solution from each domain (FE, BE, DevOps etc). Wouldn't it be better to have tech leads design the architecture/solution together?

jaabe 8y ago
I work in the public sector of Denmark, we’ve spent the past 15 years trying to get some cross-sectoral standards up and running. We’re getting there on data services as well as authentication and indexes of data, and that means we’re starting to build systems that work together everywhere. 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.
mindcrime 8y ago
I would say that a good architect, and a good development process, certainly involve collaboration between numerous stakeholders. The solution architect, tech leads, product owners, QA, etc., all have a voice and should all be talking to each other quite a lot. 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.
- oaiey 8y ago
  Well said.
option_greek 8y ago
I have seen this only when working in European companies. For some reason, these roles exist which is not bad in it self. However the majority of the architects I encountered are completely hands-off on the development part which causes lot of problems like teams that are not empowered to move fast and ridiculously complex architectures in MVP stages of products.
- oaiey 8y ago
  This is the art in being a good architect. Let the chaos reign for a while and then tighten control when necessary. Start with a skeleton and let the teams flesh it out and sometimes break a bone. But once you can benefit from architecture start to enforce your architecture. PS: European. German to be exact. We love to plan and over engineer.
  - jungturk 8y ago
    Agreed - this results from the Last Responsible Moment principle: https://blog.codinghorror.com/the-last-responsible-moment/ https://blog.codinghorror.com/the-last-responsible-moment/ 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.
- TomMarius 8y ago
  > However the majority of the architects I encountered are completely hands-off on the development part which causes lot of problems like teams that are not empowered to move fast and ridiculously complex architectures in MVP stages of products 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.
oaiey 8y ago
No, I do not think so. The software (but not the solution/enterprise) architect is a technology expert. For a solution architect it is less important to know all details of a technology but more about understanding the technology landscape. Software Architects are best embedded with the teams (basically your tech leads) but Solution Architects have to consider things which are beyond the understanding of the team (and then carry that into the teams). 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.
deleted 8y ago
[deleted]
Kalium 8y ago
You're right! Having a council of tech leads is absolutely a viable approach to designing overall architecture. 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..

jaabe 8y ago

I work in the public sector of Denmark, we’ve spent the past 15 years trying to get some cross-sectoral standards up and running. We’re getting there on data services as well as authentication and indexes of data, and that means we’re starting to build systems that work together everywhere. 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.

mindcrime 8y ago

I would say that a good architect, and a good development process, certainly involve collaboration between numerous stakeholders. The solution architect, tech leads, product owners, QA, etc., all have a voice and should all be talking to each other quite a lot. 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.

oaiey 8y ago
Well said.

option_greek 8y ago

I have seen this only when working in European companies. For some reason, these roles exist which is not bad in it self. However the majority of the architects I encountered are completely hands-off on the development part which causes lot of problems like teams that are not empowered to move fast and ridiculously complex architectures in MVP stages of products.

oaiey 8y ago
This is the art in being a good architect. Let the chaos reign for a while and then tighten control when necessary. Start with a skeleton and let the teams flesh it out and sometimes break a bone. But once you can benefit from architecture start to enforce your architecture. PS: European. German to be exact. We love to plan and over engineer.
- jungturk 8y ago
  Agreed - this results from the Last Responsible Moment principle: https://blog.codinghorror.com/the-last-responsible-moment/ https://blog.codinghorror.com/the-last-responsible-moment/ 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.
TomMarius 8y ago
> However the majority of the architects I encountered are completely hands-off on the development part which causes lot of problems like teams that are not empowered to move fast and ridiculously complex architectures in MVP stages of products 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.

oaiey 8y ago

No, I do not think so. The software (but not the solution/enterprise) architect is a technology expert. For a solution architect it is less important to know all details of a technology but more about understanding the technology landscape. Software Architects are best embedded with the teams (basically your tech leads) but Solution Architects have to consider things which are beyond the understanding of the team (and then carry that into the teams). 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.

deleted 8y ago

[deleted]

Kalium 8y ago

You're right! Having a council of tech leads is absolutely a viable approach to designing overall architecture. 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..