Conway’s law - an architecture and organization journey

I’ve been at Just Eat for 6 years, and I’ve experienced first hand how Conway’s law (1) had a big effect on the Architecture of our system.

This is how I personally perceive the Just Eat technology journey and is by no mean the only and univocal truth about how the company evolved.

Roughly, over the last 6 years, these are some of the major events that shaped our organization and architecture.

~ 2012

In 2009 the headquarter of Just Eat Technology moved from Denmark to the UK. Back then, the entire eCommerce platform was hosted on physical servers in a data center in Aarhus and order volume was starting to pick up.

Most of the code was shared via Shared Data Access Layer libraries. I remember how the entire Just Eat Visual Studio solution took ~40 minutes to build.

We had a handful of teams, looking after the Website, Mobile, and Restaurant devices, and we were starting to spin up teams to move the business logic into standalone APIs

The Consumer architecture evolved into a Service Oriented Architecture, where APIs were calling APIs in a synchronous way

~ 2014 / 2016

In 2014, due to the large growth of the UK business and the impending IPO, it was decided to fork the codebase and create 2 distinct product development teams, one focused on growing UK revenues (UK Product Development ) and one focused on International (International Product Development ) countries.

The codebase was forked, and over time development on consumer facing products happened on 2 separate codebases, diverging over time.

In 2015, a Global Partner Product Development team was formed, and Partner teams were structured around products.

In the Partner architecture, having to talk to 2 separate Consumer platforms (UK and INTL), we had to make sure we were not tightly coupled to many APIs, so we had to decouple ourselves from some of the synchronous API calls and implement a more Event Driven architecture ( mostly based on https://github.com/justeat/JustSaying ).

Due to the need to integrate with logistic partners, we also had to develop a more mature External API layer ( http://developers.just-eat.com/ )

~ 2017 / 2018

Over time it became harder and harder to deploy new consumer facing features globally, due to the split codebase, so in 2017 IPD and UKPD were merged back into one Consumer Product Development team and the process of merging back the code base began.

Merging back the Consumer Platform to a single code base and architecture is probably one of the most complex projects to execute. We talk about this like “changing the wheels of a car while driving”. In such a high growth competitive market, we can’t stop the business for a year and re-platform.

We had to come up with a way to do it, in phases, starting from the highest value slice of the platform ( Mobile, Search, Menu)

We spent a significant amount of time with the Senior Technology Leadership to talk about architecture and what distributed domain driven design to adopt for our Target Architecture.

We ultimately settled on something like this:

The 2 common infrastructure layers are the API Gateway ( to expose externally internal capabilities ) and the underlying message bus for all asynchronous events.

A system can be made on multiple services / lambdas, data stores.
A System has 3 types of connectors:
#1: Synchronous HTTP Calls
Used for Commands / Query
#2: Events is Publish / Listen to
Used for Async Eventing / Broadcasting
#3: Webhooks
Used for Sync Eventing

Key to the success of this architecture is the movement from a single monolith website to a number of microsites to allow us to slice up the entire platform in vertical slices, owned by a number of cross functional teams.

Roughly, this is how we’re planning to break up the website ( we know it works as we’ve done it already with internal and partner facing products ):
It starts with isolating the SSO module, and allowing multiple microsites to share the authentication mechanism, and it then should morph into thin layer decoupled microsites that use the shared platform capabilities exposed via the API Gateway.

We have a similar strategy for mobile, breaking down the app in different modules, that can be owned by different teams and globalised one module at the time.

This allows us to globalise and modularise one slice at the time, from front (Web and Mobile ) to back ( APIs, Services, Data Stores, Architecture )

In order to achieve this architectural design, we structured teams as described below.

Each one of the boxes is a team. We have different types of teams, with different objectives, type of people and skills. ( The picture below is not 100% up to date as the team’s objectives and names change over time)

The 3 major types of long running product teams are:

Channel teams own the coherence of the consumer, coding and testing of a specific channel.
iOS, Android, Web, Partner Centre are examples of channel teams.

Vertical teams own a specific vertical slice of the platform, from the APIs to the specific microsites and modules on the apps.
Vertical teams are full stack team inclusive of mobile resources.
Search, Menu, Post Order Experience are example of vertical teams.

Foundation teams own the coherence of the infrastructure or support teams.
Examples of this are the External API team, a small Architecture Team, etc…

We moved to this structure in January 2018 and we are starting to see the first results of vertical teams owning a full slice and starting the globalization and decoupling process, as well as channels team making good progress in modularising and globalising the UK & INTL apps.

As per my experience it will take about 12 to 18 months for the architecture to take the desired shape.

In conclusion, you can see how organizational structure and architecture go hand in hand.
When structuring your organisation, is best to know what business goals you want to achieve in the next 2 / 3 years, understand how your architecture will have to evolve to fulfill the business requirements, and then organise your teams in a way that maximise the chances of achieving both the desired architecture and the desired business goals.

(1): Conway’s law: “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”