The Secret Power of Conway's Law

As a part of Riverty´s ambition to become the most human-centric fintech, the tech department is overhauling the company´s core software for its Buy-Now-Pay-Later and parts of the Order-to-cash business.  

Competing FinTechs with a software based on modern microservice architecture are able to deliver new features faster and more often, and, hence, can react faster to market trends and innovate more easily. Riverty has started an ambitious tech transformation initiative to close this gap, and to enable its product team to develop more client-centric features with a better user experience.

Gregor Schumacher is Tech Lead Growth and accompanies this transformation journey publicly via a series of interviews with Riverty tech experts. 

Gregor: What is your mission here at Riverty?  

Thomas: I am employed at Riverty as an enterprise architect, so that could entail a lot of things, right? I will answer with a quote from a series I was watching some years ago. Its hero, detective Bosch, had this sign on his desk: “Go out and knock on doors”.  

If you are having the role of an enterprise architect, you have to get up and knock on doors. You have to discuss with people in the organization to understand. You're basically trying to make sense of a complex environment in terms of systems and application, but also in terms of information and business. We call it “BIAS”.  

Essentially, enterprise architecture is the practice to document, understand, and influence the chaos that has been made. But my mantra is: go out and knock on doors. 

Gregor: Sounds like a salesman.  

Thomas: Yes, indeed. As an enterprise architect, you want to advocate things, ideas, principles. You want, for example development teams to adopt certain basics around APIs or product teams to understand APIs not just as technical interfaces but as actual products. So it's sales andI am the salesman of good solutions.  

 

“Enterprise architecture is influencing the chaos that has been made.” 

 

Gregor: Once I was in a meeting with you and it felt like you want to sell Conway´s Law to me. Tell us what that is and what its implications are for Riverty.  

Thomas Conway´s law is more a principle or a consequence than an actual law. Mr. Conway identified in 1968 that the structure of a software system usually reflects the social structure of the organization that developed it.  

It means that if you continue with a certain type of organization, the architecture will evolve accordingly to that. For example, within Riverty we have developed a software for our venture “Corporate Mobility Budget” as a part of the innovation department outside the normal product organization. And, very much aligned with Conway´s law, it now stands quite aside from our standard Riverty tech stack. It was meant to be a speedboat, it became one, but of course it does not leverage all opportunities that would have come with deeper integration.  

 

Conway´s Law states that organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. 

 

So what will happen if you change your old monolithic application to a modern microservices-based software in order to become faster and more flexible, but you don’t change your organization and communication structures accordingly? Your software transformation will most likely fail because you will run into bottlenecks. 

Gregor: Bottlenecks? You mean even when you throw more developers on the monolith, they won't produce more features because it takes so long to learn the monolith?  

Thomas: Yes, that's one aspect of it. And, it gets increasingly harder to change it. And we have now seen that. The architecture and the software running will be increasingly more complex as you add more code to it. It takes longer to define the changes, to develop the changes, to test the changes.  

And you risk making changes that would affect certain parts of the systems that you were not aware of. It is like a snowball running down the hill: it gets increasingly harder to see inside that snowball because the layers get thicker and thicker.  

Gregor: And here we are back to Conway's Law. Growing companies lead to more internal complexity which leads to more complex software. And now? 

Thomas: Well, that is the journey we have embarked on. We are going into microservice architecture, so we also need to change the organization.  

 

“We are going into microservice architecture, so we also need to change the organization.” 

 

Gregor: Into microteams? 

Thomas: Kind of. We need smaller teams that are cross-functional developing these microservices.  

Gregor: Where I follow is that the teams need to be smaller, but why do they need to be interdisciplinary?  

Thomas: Because you want to keep the amount of communication and dependencies between different organizational functions at a minimum level. If you want a microservice taking fully care of one capability, let´s say payment, you need to have all functions relevant for that capability in the team. Obviously, you will need developers, but also domain experts that have some knowledge of the payment industry. And if this service has an interface, you will also want UX designers and front-end developers on the team. Only then, the team can develop new payment functionalities quickly without waiting for external functions approving the compliance or developing the user interface. 

Gregor: Ok then, back to our challenges here at Riverty. We have successfully broken up the old structure where we had one entrepreneur per monolith. As each monolith had its own payment feature, like in a surgery, we are pulling reusable capabilities like payment out of each monolith and unite them in just one microservice. Sounds tough. Isn't there any possibility where we can trick Conway´s Law? 

Thomas: Well, we can try to ignore it. But it is not really a law, it is more of a consequence. You can try to keep the organization untouched, but it will lead to difficulties in software development, in operations, in product, in lack of speed, in reliability. It is a little bit like growing bananas here in Norway. You can try, but most probably you won't succeed. The dependency between changing the system and changing the organization is just very strong. So we are having a chicken/egg problem here: Do you start with the organization first or the architecture? 

 

“Ignoring Conway´s law is like growing bananas in Norway.  
You can try it, but it will most probably fail.” 

 

In our case it would be very difficult to start with the architecture first and then follow with the organization. From a legal and administrative perspective, the classic functional line organization remains. But in reality more and more employees are working in small, cross-functional teams on specific microservices. This is like an additional organizational layer on top. We are now documenting who is in which team, what are their roles, what are they working on, how they interact and with whom. The inspiration came from an excellent book called team topologies.  

Gregor: Now try to be concrete, how are you actually doing the transformation? 

Thomas: We are documenting the actual teams we have as they really work together around our capabilities. Before we started doing that, we just had a flood of different perceptions. Now we are trying to empower these ~50 teams to become autonomous. But full autonomy is dangerous, too. We do not want the teams to develop everything inhouse or vary too much in their interfaces to the outside world.  

 

“A team who develops a microservice for ‘ledger’ needs to take responsibility for the remaining ledger functionality in the monolith.” 

 

Gregor: So you have established some kind of oversight?  

Thomas: I would rather call it “enabling teams”. For operations we have established an ops team, for coordinating the services on the platform layer, there is a platform team. Our API and Architecture guild are driving standards, governance and communication around internal and external interfaces. Especially standards for architecture and tools are important to enable employees to move from one team to another.  

Still we are having another big challenge: These independent teams love being responsible for their microservice, let’s say for ledger. But in a transformation phase, there is always some ledger functionality left in the monolith, and product teams tend to forget that because it is less fun.  

Gregor: When did we start this journey and when will it be done?  

Thomas: Well, we have started our journey about 2 years ago. But a definition of done? That does not exist. I had this funny situation at a former employer where I was looking for an architectural model and found this file called “the complete model”. I had to laugh; how do you ever get a complete model?  

Gregor: I know, the sweet dream of every perfectionist.  

Thomas: It's never going to happen. We need to measure progress differently. For example: We are investing already more than 50% of our new development efforts into microservices. We have delivered our first major new feature in less than 3 months. But still, there are too many features left in the monoliths. And we have to improve our client facing features on the experience layer. And our external developer experience needs to improve.  

Gregor: What is a milestone you will really celebrate? 

Thomas: When we have moved 80% of our transactions into microservices. And I will celebrate every bigger feature in the monolith that we have turned off. And when we become so fast in new features that we quickly develop two alternative features seeing which one the consumers prefer. 

But we should also celebrate when we fail, if we do it fast. Then we can move on based on our learning. Moving faster and becoming better is what our transformation to microservices is all about.