How to Architect your Organization

Good software architecture is one of the cornerstones of a successful software product. And being able to come up with a sound software architecture depends a great deal on how your organization is structured.

This is hardly any news. In 1968, the same year when the term ‘Software Engineering‘ was coined, Melvin Conway phrased what is known as Conway’s Law, stating that:

“Organizations which design systems… are constrained to produce designs which are copies of the communication structures of these organizations”

I wish to suggest that this term has a much deeper meaning than usually attributed. In particular, with advances in computer architectures of the recent decades, organizations that will neglect to introspect on their own architecture may end up building products that are hard to impossible to evolve and maintain.

The Common Meaning of Conway’s Law

Normally, in my experience, Conway’s Law is interpreted almost at face value. That is, observe the organization’s structure in order to explain the product architecture.

For example, Eric S Raymond (The Cathedral and the Bazaar) states that “If you have four groups working on a compiler, you’ll get a 4-pass compiler.”

James Coplien (Organizational Patterns of Agile Software Development) states that “If the parts of an organization (e.g. Teams, departments, or subdivisions) do not closely reflect the essential parts of the product, or if the relationship between organizations do not reflect the relationships between product parts, then the project will be in trouble… Therefore: Make sure the organization is compatible with the product architecture.”

The Dark Side of Conway’s Law

In contrast to this view, I wish to suggest that the opposite is also true. That is, that the architecture of the product is a reflection of the architecture of the organization. And that there is an opportunity in observing the product’s architecture to highlight blind spots in what individuals in the organization do not see.

Put in an example, if your product is buggy, it may suggest that the organization is flawed, too.

Moreover, the evolution of software architectures may be an indication of the evolution of contemporary organizations.

In subsequent posts I will review popular software architectures, and how they may be telling on organizations of their time, and this day.

  • Mainframe computers: A strong centralized management, with manpower to carry our orders – much like dumb terminals
  • Minicomputers, Microcomputers, LAN and WAN: Emergence of decentralization of management, and of peer to peer autonomy for management and decision-making
  • WWW and mobile apps: reaching out to customers to get self-generated information that was unavailable before
  • Cloud and grid computing and IoT: Extend decision making further to clients, users, and customers, automating the generation of data, and the emergence of patterns that before were assumed as sole owner of the organization.

I will also hypothesize that many organizations are attempting to develop WWW, app, and cloud-style products, while their own organization is somewhere between client-server to peer-to-peer. The result, according to this concept, is that their products are short of reaping the fruit they are aiming for.

My goal in this series of posts is to suggest tools to identify what your organization may look like by observing your own products and to propose ways to alter the organization to match your needs.

In fact, this is also a call for readers of this blog: Please comment or email me at with thoughts and requests for what to write in the next post in this series.

Share on print
Share on facebook
Share on twitter
Share on linkedin
Share on whatsapp
Share on email