3 ms·
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
by 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 agoThis 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 agoAgreed - 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.