Conway’s one-way street
“Organisations which design systems […] are constrained to produce designs which are copies of the communication structures of these organisations.”
Very freely translated, he expressed the fact that a software architecture that emerges in an organisation always reproduces its structure.
A widespread interpretation of this statement indicates that a software architecture therefore adapts itself almost constantly to the organisational structure. Because every software architecture is constantly evolving, it is constantly being redesigned, so to speak, and would thus reproduce the current organisational structure. If this works like this, a software architecture could even be consciously influenced.
Let’s take a look at two practical examples:
Example: Modularisation of a monolith
During my time at idealo a few years ago there was exactly such a case: The frontend at that time was a big monolith that had grown historically (as they say so beautifully) on the one hand and on the other hand was actually developed by an ever larger frontend department and therefore actually reproduced the organisational structure. This made it more and more difficult to develop several parts of the frontend without getting in each other’s way. For a while all parts of the frontend, even the mobile website, the mail dispatch and the backend of the mobile apps could only be deployed together.
It quickly became clear that the monolith had to be broken down into smaller modules and later services. idealo also reorganised the formerly large frontend department and divided it into teams, each of which was responsible for a clear subdivision. This was associated with the expectation that the monolith would virtually modularise itself. After all, it was important for the new teams to be able to develop independently in order to work on their goals in a goal-oriented manner. The right intention and motivation were present, as was a meaningful organisational structure. So it should have worked quite simply …
It soon became apparent, however, that it would not work that easy. The decisive point was that it was more complex to change an existing architecture than to create a new one. Even after months the teams were not in a position to work as independently as everyone involved would have liked. To arrive at an architecture that would allow independent and rapid development, the teams’ goals had to be reprioritised and significant architectural efforts had to be made.
Ultimately, the monolith no longer exists and the development speed has increased significantly. We learned from this case that despite Conway’s Law, breaking up software architectures can be very time-consuming for an organisation.
Example: Consolidating a Distributed Service Architecture
In my current position at Zalando, I experience a quite contrary example. When I took responsibility for the Product Offer Platform there, it consisted of a certain amount of services. Soon another existing service was added, which was previously the responsibility of another team. It represented a subsequent step along our processing pipeline and so it was consistent in terms of content to take it over. A little later another service from the next downstream system was added, which also made sense in terms of content.
The software architecture at Zalando is based on Microservices. One principle for the design of microservices is “shared nothing”, or more precisely the principle of data locality. This means that each service should keep the data it uses locally. This was the case with our services – including the new ones.
What seems desirable from an academic-architectural point of view has a number of concrete disadvantages in practice. The Product Offer Platform is to a large extent a stream-based system that processes very large amounts of data – both in terms of volume and update frequency. If these data are persisted by each service itself, this is a considerable cost factor, since we do not have to operate one, but in the concrete case four databases with significant size (besides, persisting in each processing step also increases the total latency). Another negative side effect of the many services was that the business logic was distributed across the entire pipeline and was therefore more difficult to adapt.
Based on these efficiency considerations, it became clear to us that the services and in particular the data storage had to be consolidated. Although we were now organisationally responsible for all these services, this did not automatically lead to a simplification of the architecture. Instead, we have drawn up a roadmap of how we can iteratively reach our target architecture in steps.
The challenge in modern architecture management
Both examples clearly show that Conway’s Law has an effect on the development of software in an organisation, but that it has a much slower effect on the modification of existing software architectures. Architecture does not change simply by changing organisational structures. Architectural changes usually require the prioritisation of corresponding efforts. In this respect, Conway’s Law is more of a one-way street to be considered when designing new software, but should not be relied upon to change architectures.
This leads to one of the most important challenges in digital product development today: a healthy balance between new developments and the management of existing architectures. As I have shown, sometimes significant effort is needed to keep an architecture efficient and effective. At the same time, this remains an ongoing task. Often you hear of old “legacy software” that would limit the agility in development – combined with the promise that all these problems would be solved if you only got rid of this legacy. In fact, today’s new software is tomorrow’s legacy. The high speed with which we can build new microservices contributes to this.
Architecture management must therefore be a continuous process that needs to be well balanced with the development of new business functionalities. Organisational structures can help here, but they cannot relieve the work.
Notes:
Jan Hegewald blogs about modern leadership and agility at https://www.agil-gefuehrt.de. And at https://www.jan-hegewald.de you can find more content on topics relating to digital product development. You can easily get in touch with him on LinkedIn.
If you like the article or would like to discuss it, please feel free to share it in your network.
Jan Hegewald has published two more posts in the t2informatik Blog:
The agile migration of an application
A different kind of effort estimation
Jan Hegewald
Jan Hegewald is VP Engineering at SumUp Ltd. in Berlin. Previously, he was Director of Engineering for Product and Category Experience at Zalando SE and Head of Technology B2B at idealo internet GmbH.
Before that, he spent many years designing, building and implementing customised IT systems for critical core processes for large companies. He also advised a wide range of clients on project, programme and portfolio management methodologies, in each case with a view to processes, organisation, tools and the personal skills of employees.