Conway’s Law Meets Digital Transformation

In 1967 a programmer called Melvin Conway wrote a paper for the Harvard Business Review which stated businesses would design systems that perfectly replicate their internal communication structure. The argument being made was that technical innovation shouldn’t be defined or limited by historic business processes. At the time, the idea was rejected as he had not proved his hypothesis but as with all good ideas the peoples vote won and this adage became known as Conways Law.

Businesses would design systems that perfectly replicate their internal communication structure.

Back then computers were the size of small cars and the idea of engineering as we know it today seems very distant, but the design process remains the same. Which is why Conway’s Law is one of those phrases all engineers know today. I previously wrote about the distinction between digital transformation verses being a FinTech with a blank sheet of paper. In many ways this article is the prequel to that one as it describes the challenges faced by an organisation before they accept the need to digitally transform their architecture.?

Let’s first look at how this concept manifests in an organisation in the finance space. Take a bank or insurance company, someone with a good history and a respected brand name but also one that has been around for a while. Their first product will be built with a single purpose, a ledger with a corresponding database for capturing customer data and a set of product requirements. Often this is purpose built, or a licensed piece of software that has been significantly customised to suit the clients needs. In both cases, the software is unique but let's not use the word legacy, yet.

As the business grows, the organisation adds another product to its inventory. Same brand, same customer base, but a different set of product requirements and a wider number of ledger entries. At this juncture the approach should be to upgrade the existing architecture to suit, but if the new product deviates significantly from the original system, then the business case for purchasing a new system often outweighs the cost and complexity of upgrading the existing one. So a new team is set up to source the new system and install it. This decision making process is entirely logical at face value, but it has unintended consequences. For a start, it has introduced legacy, the idea of new and old into the architecture.

Perhaps more significantly, it has spawned a new entity or communication structure within the organisation. There are now two operation teams speaking to customers and managing their data over two different systems. These distributed systems were not designed to talk to one another, but yet the customer calling in is the same human, they don’t care that their data is held on two different systems, they just want their question answered. Enter the need for a single customer view, a new system designed to consolidate customer data from two separate systems and become the master record.?

From here on the business grows and so does it’s customer base and product suite. The organisation has an established and proven approach to growth. Adding products and features that reflect the way its teams are now organised. Conway’s theory is now very much law and order. The extreme version of this is where these teams are set up with different P&Ls or even competing revenue targets making interoperability even more challenging.

Over time the business has to respond to customer demands for digital engagement. This new requirement necessitates a revisit of the architecture and the security of customer data, data that was previously maintained behind established protocols within an on-premise environment. This inflection point kicks off the need to digitally transform the architecture.

At this point the organisation looks to contemporary solutions such as micro-services to be the conduit between the existing systems and the new digital engagement layer. A new and accepted pattern for growth is introduced and the next chapter of this story begins.

Conway’s law and the point being made here is that for a business to truly transform, it can’t just change digitally, it must also change organisationally. Without this introspection and self analysis, the new digital features will simply reflect the legacy architecture and therefore its legacy thinking.

At Smart, we started with that blank sheet of paper and seven years on we have held on to the idea that one system, one customer view and one digital experience is worth fighting for. We may have distributed our engineering teams as we have grown, but they all work off the one code base and one CI/CD pipeline deploying common features to all of our PaaS clients. Our next chapter therefore is not to shape our code base around our communication structure, but to shape our people around our code. This antithesis in approach is known as domain driven design (DDD). Take your people from different domains or skills, such as payment or investment and link them to their associated code. From there they can own their product roadmap and use an established public interface (API’s) to communicate with other domains. This hive mind allows the business to grow following a shared approach to code and business process.

The above is how my mind works, so treat this as my thoughts alone. But I found myself wanting to put pen to paper on this topic after receiving countless RFPs that wanted a new digital solution, but mandating that micro-services be used. Don’t get me wrong, micro-services are great, used in the right context. My conflict is simply that one shouldn’t seek digital innovation whilst also mandating an architecture that speaks to a legacy thinking.

Digital transformation shouldn’t be about new innovative systems alone, one should also innovate the mindset that drives those systems and thus distance the business from Conways Law.