services
A holistic approach that accelerates your current vision while also making you future-proof. We help you face the future fluidically.

Digital Engineering

Value-driven and technology savvy. We future-proof your business.

Intelligent Enterprise

Helping you master your critical business applications, empowering your business to thrive.

Experience and Design

Harness the power of design to drive a whole new level of success.

Events and Webinars

Our Event Series

Sommelier

Turntable

Featured Event
24 - 25 Apr
Virtual event: 7 live sessions
Our Latest Talk
By Kanchan Ray, Dr. Sudipta Seal
video icon 60 mins
About
nagarro
Discover more about us,
an outstanding digital
solutions developer and a
great place to work in.
Investor
relations
Financial information,
governance, reports,
announcements, and
investor events.
News &
press releases
Catch up to what we are
doing, and what people
are talking about.
Caring &
sustainability
We care for our world.
Learn about our ESG
initiatives.

Fluidic
Enterprise

Beyond Agility, the convergence of technology and human ingenuity.
talk to us
Welcome to digital product engineering
Thanks for your interest. How can we help?
 
 
Author
Richard Wheatley
Richard Wheatley

Conway’s Law applies to modular software systems and states that:

"Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure".

Conway’s Law was brought to my attention a few years ago whilst in dialogue with a major Swiss Investment Bank, who were referencing this as a limitation on their ability to build software products. Intuitively, I could see that this might not be such a good thing, but Melvin Conway came up with this in the 60’s right and it wasn't like this could be all that bad, could it? So with a certain curiosity I engaged in a conversation to better understand these concerns. What I discovered was that it's more like “a software system whose structure closely matches its organization’s communication structure works better (defined broadly) than a system whose structure differs from its organization’s communication structure”. “Better” in this context means higher productivity for the people developing and maintaining the system, through more efficient communication and coordination, and higher quality. All of a sudden what previously seemed intuitively to make sense was now clearly making sense - productivity and quality being both tangible and desirable.

Fast forward to today, the adoption of Microservices provides us with further reason to suggest that Conway’s Law is even more relevant. Microservices, a pragmatic implementation of Services Oriented Architecture (SOA) based on loosely coupled API’s is well suited to the implementation of small teams working on autonomous components. Martin Fowler and James Lewis article goes into more depth on the subject, highlighting the fact that these architectures allow organizations much more flexibility in aligning the architecture of their systems to the structure of their teams in order to ensure that Conway’s law works for us.

That naturally leads us to reflect on the implications if we can't make Conway's Law work for us? Under what circumstances might that be the case? Let’s consider an instance where an organizations structure and software are not in alignment. Typically, this arises where a distributed team are put to work on a monolithic codebase. The communications channel that Conway refers to are not aligned. Generally, this leads to frustration and tension within the implementation teams, resulting in a loss of efficiency and diminished quality.

The alternative to this would be a modular codebase (enabled by Microservices) that can be worked on by small distributed teams, located anywhere. Netflix and Amazon for example structure themselves around multiple small teams, each one with responsibility for a small part of the overall system.

Microservices embraces Conway's Law to leverage the power of distributed teams, making distributed teams the norm irrespective of whether they are located onshore, offshore or nearshore. Enterprises that are unable to engage a distributed team due to monolithic products or codebases, are likely to be at a competitive disadvantage or at worst case markedly increasing their technical debt.

Author
Richard Wheatley
Richard Wheatley