Sven-Torben Janus, Principal Architect and Partner at Conciso GmbH, argued in an October InfoQ article that software architecture is fundamentally a social and organizational construct, not just a technical one. While architecture is often depicted as boxes and arrows, the article emphasizes that real systems are shaped by communication patterns, incentives, power structures, and decision-making processes inside organizations.
Drawing on Conway's Law, the author explains that architectural outcomes usually reflect how teams are organized and how leaders think, rather than purely through technical choices. Many architectural issues are not caused by poor design skills, but by misaligned responsibilities, unclear ownership, and conflicting priorities. These problems surface as brittle systems, awkward boundaries, and excessive coordination costs.
The article highlights a common frustration among architects: seeing better solutions but lacking the authority or organizational alignment to implement them. This frustration should be treated as a diagnostic signal, pointing to unresolved tensions or missing conversations rather than technical failure.
Ultimately, the role of an architect is reframed. Architecture is less about selecting frameworks or drawing diagrams and more about shaping the conditions in which systems can evolve successfully. Good architecture emerges when organizations support clear communication, autonomy, and shared understanding. If architectures could speak, the article concludes, they would echo leadership thinking, because systems inevitably mirror the organizations that build them.
This content is an excerpt from a recent InfoQ article by Sven-Torben Janus, "If Architectures Could Talk, They'd Quote Your Boss".
To get notifications when InfoQ publishes content
on these topics, follow "architecture and design", "sociotechnical architecture", and "culture and methods" on InfoQ.
Missed a newsletter? You can find all of the
previous issues
on InfoQ.
Sponsored
|
|
Java teams face rising cloud costs, growing complexity, and modernization efforts that often add more overhead than they remove. As systems scale, cost-to-performance is a critical concern for architects. This fact sheet highlights what actually reduces Java spend in 2026—without sacrificing resilience or delivery speed. It explores where Java complexity comes from in cloud-native environments, practical cost-optimization levers, when lift-and-shift helps or hurts, and Kubernetes patterns that reduce orchestration sprawl, with real-world examples of lower OPEX at enterprise scale.
Download the Guide “Cutting Java Costs in 2026 Without Slowing Delivery,” sponsored by Payara
|
|
