Jun 17, 2020
Why You Can’t Decide Your Software Architecture
The company decided to develop a whole new project / feature. Everyone is excited about that, new technical challenges will pop up, finally you will be able to use that new technology and solve all the problems. You do not need to maintain that old school (written 6 months ago, by yourself ) code anymore, a whole fresh project. And of course you want to decide on your architecture first, you’re thinking hard on it. How is the best possible way can it be?
Well, some sad news, that’s not how it works if you’re not considering your organization’s structure. You can decide the way how your code shapes of course, how will the functions execute, how many times and on what kind of hierarchy they will call each other… But if you can’t decide WHO will write them, or your architectural design is not fully matching with the organization, your decisions on the architecture will eventually fall. They will be problems more than problem-solvers, people will get angry on them, while you’re insisting on some issues on maintainability, integrity, reliability, and other topics. If your rules do not match with the development teams’ forms, they’re just blockers of the work and they will eventually forsaken by the teams.
Luckily this relationship between software architecture and organizational structure have been identified before. It’s called Conway’s Law and it’s identified firstly at 1967.
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
— Melvin E. Conway
Remember the time, that you were doing your part hard and there was a co-worker who was really hard to communicate, and your work was related to her heavily. The basic human behavior on this kind of situation is just avoiding from the communication. So, if there’s a possible workaround on that issue instead talking to that guy, well guess what happened? A hole in the software architecture, small one maybe if we’re lucky, but still a hole, isn’t it?
If you have four groups working on a compiler, you’ll get a 4-pass compiler.
— Eris S. Raymond
Since our examples are very minor ones, the bigger problem is will reflect on the organizations themselves. While managing the organizations we’re parting them into different areas, such as Domain Experts, Finance, Marketing, Development Teams, and so on. Each department have their own working style, even different communications styles & behaviors. So in their style of doing the work they create the communication channels for interacting other teams, and the work is done inside this loop of communications. And the product will eventually reflect these communication channels, decisions-by-decisions.
Actually when managing the organization, we’re doing the same what we do to the code. We’re creating abstractions, trying to encapsulate the details and while doing that, the interfaces become important and important…
So, can it be a good idea, to split up the functional teams, into smaller (because communication needs to be simple) and cross-functional teams? If we split the people as we want to split our product, the trick is done? The agile framework also suggests this too…
Both yes and no I think. Creating smaller cross functional teams are a good practice still, but Conway’s Law is still working within these teams, too. With this kind of working style we’re optimising the teams, but what about the whole big organization? Won’t this cross functional teams, miss the bigger picture? Do we want them to miss? Will they create new cliques? How will be the alignment done between teams?
A Forbes Article is written three years-ago on this gives a good point-of-view. Josh McKenty argues the collaborative platforms to overcome the “Not Invented Here Syndrome”. Inside the world of smaller cross-functional teams, we need to optimise our working styles and also our personal behaviors. We’re going to need the soft skills more and more. We need to re-learn how to communicate and the “kindergarten” values to overcome the barriers of the Conway’s Law.
Thanks for reading.
