There is a famous anecdote about Sinan, the architect: when he was building the Selimiye Mosque, a child pointed at the minarets and claimed one of them was leaning. Sinan reacted immediately, instructing the workers to attach ropes to the minaret and pull until the child confirmed the minaret was now straight. The minaret wasn’t actually leaning, and the workers didn’t change anything by pulling. The perception of the minarets was at risk, and Sinan addressed that.
Continue reading Communication is crucial to architectureTag Archives: organization
The power of verticality in SW (and manufacturing)
I learned about cellular manufacturing when I was majoring in industrial engineering. In this post I’d like to show the game-changer nature of vertical organization by drawing some parallels between this idea and the organization of software work.
In a functionally organized plant, the shop floor is structured according to functionality: lathes are organized together, as well as mills, painting and polishing stations and various other functionalities. This brings efficiency in terms of keeping tool magazines, needed chemicals etc. together, centralizing the maintenance, optimizing utilization of the machines, sharing knowhow among the people operating the machines and so on.
Continue reading The power of verticality in SW (and manufacturing)Conway’s Law, communication & architecture
When designing an architecture, one should respect Conway’s law. Respecting it does not mean reversing the BAPO model, and deriving the architecture from the organization. Rather it means taking the organization and its adaptability into account when designing. Even if the architecture is perfectly aligned with business, but the architect doesn’t have the means to influence the process and the organization accordingly, there will be architectural drift caused by the mismatch with the organization.
And when we can, we try to define teams according to the architecture. Often with the premise of reducing the communication overhead in the organization, we try to break down the system into cohesive subsystems and corresponding, ideally two-pizza-sized teams. The math behind is explained simply in The Mythical Man-Month that the number of necessary communication channels grows quadratically in relation to the team size.
But, communication is essential in software development. Why do we want to reduce it?
Continue reading Conway’s Law, communication & architectureBAPO imbalance
All parts of BAPO[1]BAPO model explains how the business, architecture, process and organization should play with each other in a SW organization. I like it personally, as it helps me explain several things such as … Continue reading have a home turf of problems/aspects/challenges it can address efficiently. For instance, maintainability is best addressed in the architecture, rather than some complex maintenance processes or special teams designated in the organization. In most cases, modifiability is best first addressed in the business, where only the essential modifiability is prioritized and rest is eliminated to save on complexity. Knowhow management and regulations etc. are mostly best addressed in the organization and process areas. While some technical risks are best addressed in the architecture, I was surprised to hear of a case where the business people covered against a risk by just arranging an insurance, thereby relieving the architecture of the complexity. Continue reading BAPO imbalance
Footnotes
| ↑1 | BAPO model explains how the business, architecture, process and organization should play with each other in a SW organization. I like it personally, as it helps me explain several things such as Conway’s Law being an inverse interaction of architecture and organization. Check out the following document for details, or just Google it: Obbink, H., Müller, J., America, P., van Ommering, R., Muller, G., van der Sterren, W., & Wijnstra, J. G. (2000, August). COPA: A component-oriented platform architecting method for families of software-intensive electronic products. In Tutorial for the First Software Product Line Conference, Denver, Colorado. |
|---|