7–9 November 2016: Conference & Tutorials
9–10 November 2016: Training
Amsterdam, The Netherlands

How to break apart a monolithic system safely without destroying your team

Matthew Skelton (Skelton Thatcher Consulting)
11:50–12:30 Monday, 7/11/2016
Average rating: ****.
(4.69, 16 ratings)

Prerequisite knowledge

  • A basic understanding of Conway's law (useful but not required)
  • A working knowledge of version control history with Git

What you'll learn

  • Learn some team-first heuristics to use when decomposing large or monolithic software into smaller pieces


Back in 2004, the wisdom was to build monolithic Java applications. However, skilled teams are increasingly finding that small, loosely-coupled services provide a good degree of isolation between system contexts in the face of rapid change, and this flexibility to mutate the system by regular isolated deployments seems to match a very human cognitive timeframe (hours or days between changes rather than weeks or months).

But how do we set about safely decomposing a monolithic (or just large) component into smaller, decoupled bits? There are several technical practices to help at a lower level, especially those articulated by Michael Feathers in his classic book Working Effectively with Legacy Code. However, as Sam Newman argues in Building Microservices, we must consider aspects other than pure code if we are to make the new system responsive to business demands, including the nature and composition of the software team itself.

An effective software team has at most around nine people, thereby fundamentally limiting the size of software that team can collectively comprehend and “own.” A larger team struggles to work with the domain; split the work across more than one team and “rot” can quickly set in as teams lose a sense of ownership over the code. Since according to Conway’s law, our software takes the shape of underlying team communication patterns, we need to ensure that teams have “just the right amount” of communication between them, reflecting the natural communication needed between components or contexts. This means that a product team can take on more than one bounded context but only such contexts that do not naturally communicate (much). Contexts that communicate are likely to merge together if the same team develops them.

Drawing on insights informed by his work on the DevOps Team Topologies and with a variety of organizations including a global publishing organization, software vendors with blue-chip clients, a global technology company specializing in telecoms, several organizations in the financial services sector in the UK, an international commodities trading organization, and a major UK broadcaster, Matthew Skelton explains how to infer some useful heuristics for evolving from a monolithic architecture to a set of more loosely coupled services by starting with the needs of the team. Matthew addresses some very real dangers of moving away from a monolith, including reduced domain consistency (UX, architecture, and data), data duplication, additional operational complexity due to distributed system, and degraded UX across the product and explains how modern logging and metrics tooling can help instrument the monolith before (or during) the decomposition into smaller services, helping us to understand how it really works and providing a valuable source of validation for the new services.

Photo of Matthew Skelton

Matthew Skelton

Skelton Thatcher Consulting

Matthew Skelton is a cofounder and principal consultant at Skelton Thatcher Consulting, where he specializes in helping organizations adopt and sustain good practices for building and operating software systems, such as continuous delivery, DevOps, aspects of ITIL, and software operability. Matthew has been building, deploying, and operating commercial software systems since 1998. He curates the well-known DevOps Team Topologies Patterns and is coauthor of Database Lifecycle Management (Redgate) and Continuous Delivery with Windows and .NET (O’Reilly).

Comments on this page are now closed.


Picture of Erich Ackermann
Erich Ackermann
14/11/2016 14:57 CET

Hi Matthew,
great – many thanks for sharing the slides and for the great talk!

Picture of Matthew Skelton
Matthew Skelton
14/11/2016 14:32 CET

Hi Erich,

Thanks for the feedback – I’m glad the presentation was useful.

The slides from the session are now online here:


Picture of Erich Ackermann
Erich Ackermann
14/11/2016 13:40 CET

Hi Matthew,
it was a really good and interesting presentation in Amsterdam. As I’m deeper interested(involved in this topic: are you going to publish your slides? I’d be very interested in getting access to them.
Best regards, Erich