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.

Microservices Architecture for eCommerce eBook. Download for free >

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).
Make eCommerce ready for changes with microservices architecture  data-src=

Piotr Karwatka

CTO at Divante eCommerce Technology Company. Open-source enthusiast and life-long builder. Co-founder of Vue Storefront and Open Loyalty. Now gathering engaged communities around new technologies. | LinkedIn | Twitter

Share your comment