“Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure.”
Melvin Conway, April 1968
I’d risk the statement that a successful migration towards Microservices architecture depends more on the proper organization structure than any other factor. In my recent interview with Kelly Goetsch, we concluded that one of the key factors for changing eCommerce architecture is to have a project sponsor with a budget and vision, and then add the proper team structure. Only those factors combined will let you hit full speed.
We can add that successful architecture stands on three legs: a proper domain model, people, and operating model.
The structure of the people and teams, as well as the operating model, differs from company to company, product to product, and project to project. However, I really liked the observation, made by Sam Newman in his ‘Monolith to microservices’ book, that the best structure is the one which gives the team full ownership. Usually, this ownership means the independent deployability of the services the teams are working on.
“Adding more people will only continue to improve how quickly you can deliver, if the work itself can be partitioned into separate pieces of work with limited interactions between them.”
Sam Newman, Monolith to Microservices – after the “Mythical Man Month”
This means that, in order to achieve performance, the team has to have full competences—developers, design, DevOps—to build and ship new features to production. There is no need to communicate with different structures. Of course, the team needs to fulfill the API service contracts and interfaces. Other than that, they should be able to experiment and ship new features solely on their own.
Sounds like a piece of cake. However, it is easier said than done.
When a company operates on a certain scale, there is no golden rule on how to structure the services, and therefore the teams. No wonder, there is a lot of experimentation. Let me share just two interesting cases of dealing with this problem.
ASOS Team Structure
ASOS made a distinction between the Enterprise domain in which they usually try to “Buy” the solution on the market and the Digital Domain, where they predominantly “Build”. Building means fulfilling the customer’s needs as the digital domain is very much product- and client-centric.
The ASOS structure is divided into Digital Domains and Platforms. They’ve got 9 Digital Domains, 19 Platforms, and 35 Dev Teams. Domains are the organizational structure for managing the Platform teams. The Platform Teams are maintaining and building the collections of aligned services, being 100% responsible for the full lifecycle of those services.
Each Platform team is led by the Product manager supported by the Platform lead and the team of Product Designers, Architects, and Business Analysts. They’re creating the product vision and designing and maintaining the backlog that is then executed (implemented) by development teams. Development teams at ASOS consist of BAs, Data Analysts, developers, and QA so they can ship the new features solely on their own. [Source: Microservices architecture at ASOS].
If your company isn’t as big as ASOS size—including 19 platforms and 35 DevOps teams—you can still apply some of the lessons. I guess the two most important ones are:
- Have the product/business link/person within the team working on the particular microservice, as there are a lot of quick decisions to be made on a daily basis.
- Make sure development teams include everything required for your business domain to ship new features (usually devs, BA, QA, and UX).
MOVE structure by AboutYou
AboutYou is a pretty unique company. The unicorn eCommerce originated from Germany and, interestingly, is a headless, API-first eCommerce platform. With more than 130 developers, the question of the right structural fit obvious arose. They introduced the MOVE operating model as a response to this growth.
“We believe in small and fast teams. The number of people working cooperatively on the same project at the same time should not exceed 8. This makes the communication and development process more quick and efficient.”
Introducing MOVE
They resigned from having the traditional business units, rather focusing on the business/product domain. Each unit is a standalone product that is led by the technical and business leads, in order to balance the requirements. These units are representing specific domains like Checkout & Order Handling, Core Processes, and Mobile Apps. The teams work using SCRUM or Kanban to improve transparency and ensure continuous improvement of teamwork and processes.
Within the teams, there are one or more Circles with two predefined roles: Circle Manager (who’s in charge of gathering the business requirements) and the Lead developer (who is a go-to tech person within the circle). Interestingly, the circle structure and roles can be re-defined every 9 months and developers can even migrate between circles (they should, however, stay within a single circle for six months or until their individual skill-set is better for another Circle).
Wrap-up
The ability for the team to ship new features with minimal or no contact with the outside world seems like a good pattern for designing the team structure for a microservices-based project. I guess it’s important to avoid any form of over-engineering. It’s easy to forget that most of the successful microservices projects started as Monoliths. One of the key reasons is simplicity and performance.
Published June 2, 2020
