A featured contribution from Leadership Perspectives, a curated forum for enterprise technology leaders, nominated by our subscribers and vetted by the CIOApplications Editorial Board.

Inc

Conway's Law in the Era of Agility

First, who is Mel Conway? Back in 1968, Conway published an article in Datamation, stating that “organizations are constrained to produce application designs which are copies of their communication structures.” This later became known as Conway’s Law.

The simplest way to understand Conway’s Law is that your software architecture and product is going to be a reflection of your organizational chart.

Some managers misinterpret Conway’s Law as cautionary: don’t ship the org chart. The reason is that a product team which becomes too focused on a particular part of the software architecture will lose sight of the bigger picture. Software needs to have a purpose. We aren’t shipping technology and features in isolation, we are shipping a complete solution to some customer’s problem. Ideally, customers experience one consistent product vision rather than a collection of modules that feel glued together by different teams.

While that’s an important and humbling truth for product teams to remember, it isn’t what Conway’s Law is about. Conway was telling us that there is natural and unavoidable symmetry between an org chart and product. Since we are always shipping the org chart and we should continually make sure we have the right one to meet our customer’s needs.

In a world where customer’s needs and market dynamics are as unpredictable as ever, we must find a way to respond with agility – not just through our product offerings but through our organizational structure. Fortunately, modern development methods give us that power.

The Inverse Conway Maneuver

If products reflect the org chart, then why not flip the script? The “Inverse Conway Maneuver” recommends evolving your team and organizational structure to promote your desired architecture.

Or put another way: start with the product you want to make, next define the teams necessary to construct it, and the right software architecture will necessarily emerge. It’s a particularly compelling idea in a world where software development is increasingly embracing DevOps and microservices.

Rather than shipping large monolithic codebases, modern products can be thought of as a web of smaller services connected by strong contracts. There may be many more dependencies to track but contracts and other DevOps standards allow services to be updated faster, deployed independently, and implemented without any internal constraints.

Taken to the extreme, there is no central architecture and what emerges is a star network of services that are organic, highly optimized, and able to rapidly evolve. Similarly, the teams owning and operating these services form a fluid network rather than a strict hierarchy. This leads me to my second favorite Conway quote

“[My idea] creates problems because…the design which occurs first is almost never the best possible, the prevailing system may need to change. Therefore, flexibility of organization is important to effective design”—Mel Conway

Conway points to the need for continual self-assessment and flexibility to address ever-changing business challenges. Engineering leaders are responsible for driving that growth and channeling it effectively. With the emergence of DevOps, microservices, and highly-networked teams we can achieve unprecedented levels of agility in both our product and organizational designs.

In the highly-networked and flexible teams of the future, the value of mission, culture, and relationships will dominate that of organization and architecture.

The articles from these contributors are based on their personal expertise and viewpoints, and do not necessarily reflect the opinions of their employers or affiliated organizations.