3 ms·

Congratulations. I've been in exactly the same position many years ago so I can share with you some of my insights. I've proceeded with my career keeping those

Congratulations. I've been in exactly the same position many years ago so I can share with you some of my insights. I've proceeded with my career keeping those on mind: - listen to what people say, you can't and won't be an expert on everything - when you listen to them - verify and deepen your knowledge on topic, it's good to be able to connect dots - be a practitioner - there's nothing worse than an architect that doesn't know how to code/configure server etc ;) - attend both developer teams' demos, plannings and product teams' meetings - context is king and as an architect you have to see things both broad and narrow connecting technology with business needs - be realistic - most businesses don't need super-high-tech-microservices-based-kubernetes-mesh-powered architectures ;) - remember that architecture is about structure, guidelines, policies and order that aligns with business needs (so this is the starting point - understanding what business tries to achieve). Technologies really don't matter - they are just a tool - always assume that you don't know everything - challenge your own assumptions - be authentic and polite - people don't like super-star-asshole-know-it-all-architects (been one, don't recommend that :)) Good luck!

mateuszserafin 6y ago
Oh I forgot one thing. It's ok to make mistakes and change your decisions. Sunk cost fallacy is a bitch and you have to be aware of that (sometimes it's cheaper to fail than do everything to be right)
giantg2 6y ago
I completely agree with the need to be a practitioner. In my experience, a good architect can create a POC project to demonstrate that their approach will work. It's not necessary to create a POC for every little thing, but it sure helps when the team is dealing with a new stack or large/complex project.
- mikro2nd 6y ago
  Just want to agree fully! I've been known to say that an "Architect" who doesn't code is no better than a bullshit artist. Architects don't necessarily write production code (they won't have the time/bandwidth) but they should be (at least involved in) coding up PoCs and key abstractions that have impact across a range of systems (in existence or to-be-built). Architecture is a process not a product.
  - mateuszserafin 6y ago
    I think that it's both actually as architecture as a process produces some artefacts (diagrams, decisions, PoCs, guidelines, policies, structure, knowledge, roadmaps, etc)
- dajonker 6y ago
  Also not great. An "architect" once threw a POC at my team like "hey, look at how easy it is to do this!", then other people started adding requirements and then wondered why it took us that long if the "architect" can throw something together in an afternoon. The POC was completely unusable for the end product.
  - dotdi 6y ago
    > The POC was completely unusable for the end product. That's why it was called a proof-of-concept, and not an end product, I think. But if it was unusable, then it probably tried to prove the wrong concept :)
jimbokun 6y ago
> - be realistic - most businesses don't need super-high-tech-microservices-based-kubernetes-mesh-powered architectures ;) At my company, we developed a monolith that eventually reached the point where it couldn't scale anymore with the same design and was becoming more difficult to modify and update. Then over time migrated to a super-high-tech-microservices-based-kubernetes-mesh-powered architecture. Which is to say, I agree with you. It is counter productive to start with the super-high-tech-microservices-based-kubernetes-mesh-powered architecture at the beginning. We certainly would not have came up with the specific microservices and technologies we ended up with, and never would have had a viable system to refactor at all as the microservices would have taken much longer to develop up front and iterate on than the monolith approach.
vorpalhex 6y ago
> attend both developer teams' demos, plannings and product teams' meetings This is critically important. I try to cycle through my team's standups through the week so I know what's going on with them and what challenges they're dealing with. Often times I've found teams will raise issues during standup they won't raise at a big cross-team meeting.
btschaegg 6y ago
As someone that has no experience with the role at all, but had to deal with some… special people, I feel the first three cannot be overstated. Your job will be more one of herding people into doing things the right way, and it should never be one of you doing all the interesting decision making or prescribing the whole structure from the get go. Talk with people, make sure they are invested in the overall architecture as well. And don't assume someone didn't think it through on their own until you discussed their ideas. People who do all the architecture planning themselves, even if they aren't butting heads with anyone, can have a really negative impact on the team as a whole, because all other team members stop worrying about the topic and just let the other guy do it. I already had to deal with outcomes of this; code that has been written by "drones" is nothing you want to work with.

mateuszserafin 6y ago

Oh I forgot one thing. It's ok to make mistakes and change your decisions. Sunk cost fallacy is a bitch and you have to be aware of that (sometimes it's cheaper to fail than do everything to be right)

giantg2 6y ago

I completely agree with the need to be a practitioner. In my experience, a good architect can create a POC project to demonstrate that their approach will work. It's not necessary to create a POC for every little thing, but it sure helps when the team is dealing with a new stack or large/complex project.

mikro2nd 6y ago
Just want to agree fully! I've been known to say that an "Architect" who doesn't code is no better than a bullshit artist. Architects don't necessarily write production code (they won't have the time/bandwidth) but they should be (at least involved in) coding up PoCs and key abstractions that have impact across a range of systems (in existence or to-be-built). Architecture is a process not a product.
- mateuszserafin 6y ago
  I think that it's both actually as architecture as a process produces some artefacts (diagrams, decisions, PoCs, guidelines, policies, structure, knowledge, roadmaps, etc)
dajonker 6y ago
Also not great. An "architect" once threw a POC at my team like "hey, look at how easy it is to do this!", then other people started adding requirements and then wondered why it took us that long if the "architect" can throw something together in an afternoon. The POC was completely unusable for the end product.
- dotdi 6y ago
  > The POC was completely unusable for the end product. That's why it was called a proof-of-concept, and not an end product, I think. But if it was unusable, then it probably tried to prove the wrong concept :)

jimbokun 6y ago

> - be realistic - most businesses don't need super-high-tech-microservices-based-kubernetes-mesh-powered architectures ;) At my company, we developed a monolith that eventually reached the point where it couldn't scale anymore with the same design and was becoming more difficult to modify and update. Then over time migrated to a super-high-tech-microservices-based-kubernetes-mesh-powered architecture. Which is to say, I agree with you. It is counter productive to start with the super-high-tech-microservices-based-kubernetes-mesh-powered architecture at the beginning. We certainly would not have came up with the specific microservices and technologies we ended up with, and never would have had a viable system to refactor at all as the microservices would have taken much longer to develop up front and iterate on than the monolith approach.

vorpalhex 6y ago

> attend both developer teams' demos, plannings and product teams' meetings This is critically important. I try to cycle through my team's standups through the week so I know what's going on with them and what challenges they're dealing with. Often times I've found teams will raise issues during standup they won't raise at a big cross-team meeting.

btschaegg 6y ago

As someone that has no experience with the role at all, but had to deal with some… special people, I feel the first three cannot be overstated. Your job will be more one of herding people into doing things the right way, and it should never be one of you doing all the interesting decision making or prescribing the whole structure from the get go. Talk with people, make sure they are invested in the overall architecture as well. And don't assume someone didn't think it through on their own until you discussed their ideas. People who do all the architecture planning themselves, even if they aren't butting heads with anyone, can have a really negative impact on the team as a whole, because all other team members stop worrying about the topic and just let the other guy do it. I already had to deal with outcomes of this; code that has been written by "drones" is nothing you want to work with.