Organization - A Tool for Software Architects
Please log in to watch this conference skillscast.
Conway's Law, domain-driven design, microservices - the most important modern software architecture approaches use the organization as a tool for architecture. But software architects often have only limited influence on the organization. And teams should be self-organized - so how can you even influence them at all?
This presentation shows what exactly it means to use the organization as a tool for architecture and how software architects can use concretely. Because even if you are a manager: Organizations are people - and you can go out and work with them!
Q&A
Question: Is there also the problem of questioning everything, if we do that then nothing really gets done? Tends to be the issue I run into in teams I work in with those people who say you must do what I say.
Answer: Yes, you need to stay away from pointless or "religious" debates. But a team that doesn't get anything done is dysfunctional. To me, the question is whether an architect should be the one who is supposed to fix that. Certainly, they can help, but I personally don't think I would be able to solve that problem myself.
Question: I always get sucked in as I am passionate about reaching the "best solution" (lack of a better word)
Answer: I think that is quite natural. However, nowadays I try to figure out whether the decision that was made solves the problem at hand and if it does, it is fine by me. So I prioritize consensus and self-organization over the best technical solution. That is tough, though. It also helps me to realize that I might be wrong and in fact, the chosen solution might not be just "good enough" but actually the best....
Question: Decision-making purely by collaboration can lead to blockages on important decisions though - we have a senior technical staff for a reason.
Answer: Good point. However, often I think that the decision itself is not the problem - but enforcing it. At least I often get the question "How do you enforce the rules" - and I think if you convince people beforehand because they take part in the decision process, that problem might be easier to solve. And also your decision might be better because there is more expertise available. But in some cases that might be overdoing it and sometimes it feels slow and cumbersome.
Question: This assumes some form of collaboration is required--but how do you deal with cases where the culture says "You're the architect", and refuses to make any decisions?
Answer: Yes, that is a great question! I would even argue if you do have the title "software architect" you can't really escape that responsibility. So if there is a decision that in your opinion will make the project fail, you will need to step in and probably overrule it. If you have the responsibility, you will be able to do that. However, it will hurt self organisation and the decision-making process. So it is the last resort. I believe architects overrule decisions even if they don't have that risk so that is why I focus on the advice to do self-organization in the talk.
I have to admit that cases, where teams don’t want to make decisions, is not something that I see frequently. I guess I would try to understand the reasons behind that and consult with e.g. the Scrum master to figure out what to do. IMHO it's a social problem. I would try to stay away from just making the decision myself for as long as possible.
YOU MAY ALSO LIKE:
Organization - A Tool for Software Architects
Eberhard Wolff
Fellow INNOQ