4 ms·

> Architects, Technical Directors, and the like barely override any team decision if at all. I would be interested to see how the products turn out in the long

> Architects, Technical Directors, and the like barely override any team decision if at all. I would be interested to see how the products turn out in the long run, when the team decides on architecture A but the company as a whole bets on architecture B, e.g. the team likes AWS but the company wants to use Azure.

ElViajero 5y ago
That is a very interesting point, and it is solved in negotiations between the teams. One team cannot use a technology that forces another team to change theirs. That will take away the autonomy of one of the teams. e.g. If one team decides to use Protocol Buffers for their public APIs instead of HTTP/JSON that is the standard, that needs to be discussed at a higher level. As that decision forces other teams to change their tech-stack, one team cannot make that change unilaterally. If the team's application is composed by several micro-services and they want to use Protocol Buffers for their private/internal APIs, that is not a concern for anyone else. The directors or architects will be arbiter of the discussion to make sure that it is taken fast and everybody opinion is weighted in. And, if the end there is no agreement, then the director will take the decision to keep things moving. The main downside of this approach is when a team changes project and ownership of the code changes hands. In that situation you get a tech-stack that you may not find attractive. Usually the team will end changing that tech-stack to something they are more comfortable with, but it takes a long time.
ChrisMarshallNY 5y ago
There's a joke in the US: "A camel is a horse that was designed by committee." Of course, camels are pretty cool. If you read Pratchett, they are the world's greatest mathematicians. But they ain't horses. There's a lot to be said for a single, focused, experienced, architectural "czar." As to how much leeway the team is to be given, I think the jury is still out, and I'll bet it depends on corporate, or local societal, culture. Team overhead is a big deal. The more leeway and autonomy that is given to the team, the more overhead is required to maintain the product focus and lifecycle. But it can well be worth it, if the team is comprised of experienced craftspeople. Less so, if it is mostly junior-level folks, who need to "stay in their lanes." I am not a fan of "One Law to Rule Them All, and In the Darkness Bind Them" rules. Every team, and even every project, will have many factors that will inform the structure, overhead, deliverables, quality, future maintenance, etc.
- chousuke 5y ago
  I think rather than a single person, you want exactly two people who have to agree on something to make a decision; and if you can't get to a decision, it's probably a sign you need to solve other problems first. That way, there's someone who can challenge your opinion and you have to convince them to agree with it or find an alternative. Often during the convincing part you identify issues that you wouldn't have thought of by yourself, and since you don't have ultimate authority by yourself, you're less likely to unintentionally shut up someone who wants to disagree but defers to authority.
  - ChrisMarshallNY 5y ago
    Very good point.
marcinzm 5y ago
There would be some sort of process for coming to a decision on choices that have broad impact. The same way there would be a process within a team when different individuals disagree on direction. The problem with a top down approach is that the architect doesn't actually know what is actually needed by teams. They're too far removed from the day to day. So you get a uniform but generally suboptimal set of technologies.
c17r 5y ago
They did say "barely". I'd imagine "we want AWS just because" would be one of those scenarios. The rest of it doesn't have to be an explicit override, but asking the team for clarification: "You've spec'd out A but we do have B that is similar, is there something missing from B that you need?"

ElViajero 5y ago

That is a very interesting point, and it is solved in negotiations between the teams. One team cannot use a technology that forces another team to change theirs. That will take away the autonomy of one of the teams. e.g. If one team decides to use Protocol Buffers for their public APIs instead of HTTP/JSON that is the standard, that needs to be discussed at a higher level. As that decision forces other teams to change their tech-stack, one team cannot make that change unilaterally. If the team's application is composed by several micro-services and they want to use Protocol Buffers for their private/internal APIs, that is not a concern for anyone else. The directors or architects will be arbiter of the discussion to make sure that it is taken fast and everybody opinion is weighted in. And, if the end there is no agreement, then the director will take the decision to keep things moving. The main downside of this approach is when a team changes project and ownership of the code changes hands. In that situation you get a tech-stack that you may not find attractive. Usually the team will end changing that tech-stack to something they are more comfortable with, but it takes a long time.

ChrisMarshallNY 5y ago

There's a joke in the US: "A camel is a horse that was designed by committee." Of course, camels are pretty cool. If you read Pratchett, they are the world's greatest mathematicians. But they ain't horses. There's a lot to be said for a single, focused, experienced, architectural "czar." As to how much leeway the team is to be given, I think the jury is still out, and I'll bet it depends on corporate, or local societal, culture. Team overhead is a big deal. The more leeway and autonomy that is given to the team, the more overhead is required to maintain the product focus and lifecycle. But it can well be worth it, if the team is comprised of experienced craftspeople. Less so, if it is mostly junior-level folks, who need to "stay in their lanes." I am not a fan of "One Law to Rule Them All, and In the Darkness Bind Them" rules. Every team, and even every project, will have many factors that will inform the structure, overhead, deliverables, quality, future maintenance, etc.

chousuke 5y ago
I think rather than a single person, you want exactly two people who have to agree on something to make a decision; and if you can't get to a decision, it's probably a sign you need to solve other problems first. That way, there's someone who can challenge your opinion and you have to convince them to agree with it or find an alternative. Often during the convincing part you identify issues that you wouldn't have thought of by yourself, and since you don't have ultimate authority by yourself, you're less likely to unintentionally shut up someone who wants to disagree but defers to authority.
- ChrisMarshallNY 5y ago
  Very good point.

marcinzm 5y ago

There would be some sort of process for coming to a decision on choices that have broad impact. The same way there would be a process within a team when different individuals disagree on direction. The problem with a top down approach is that the architect doesn't actually know what is actually needed by teams. They're too far removed from the day to day. So you get a uniform but generally suboptimal set of technologies.

c17r 5y ago

They did say "barely". I'd imagine "we want AWS just because" would be one of those scenarios. The rest of it doesn't have to be an explicit override, but asking the team for clarification: "You've spec'd out A but we do have B that is similar, is there something missing from B that you need?"