Adam Mullen & John Collins

Monoliths: A love story

Your architecture mirrors your organization. To fix your code, you must first fix how your teams collaborate.

Monoliths: A love story
#1about 4 minutes

The challenges of scaling a monolithic architecture

Rapid team growth in a single codebase leads to development friction, increased complexity, and slower delivery times.

#2about 4 minutes

The problems with a growing monolithic codebase

As a monolith grows, development slows down due to the need for extensive communication and alignment across many teams.

#3about 4 minutes

Why strict code ownership is a flawed solution

Assigning strict code ownership creates walled gardens, knowledge silos, and dependencies that hinder collaboration and slow down development.

#4about 4 minutes

How engineering culture shapes system architecture

According to Conway's Law, your organization's communication patterns will ultimately determine your software architecture, making cultural change a prerequisite for technical change.

#5about 4 minutes

Shifting from code ownership to inner sourcing

Move from a mindset of protective ownership to one of collective maintenance by allowing people to go to the work and adopting an inner-sourcing model.

#6about 4 minutes

Scoping change initiatives for maximum impact

Choose meaningful, visible projects that can be completed within a few sprints to ensure they are large enough to matter but small enough to manage risk.

#7about 3 minutes

Applying the scientific method to organizational change

Treat improvements as experiments by forming a clear hypothesis, testing it, analyzing the resulting data, and iterating based on what you learn.

#8about 4 minutes

Practical tips for implementing sustainable changes

Ensure success by making small, iterative changes, prioritizing easy rollbacks, and investing in documentation and code quality to support future work.

#9about 3 minutes

Focusing on modularity over architectural labels

Instead of debating monoliths versus microservices, focus on decoupling code and improving team collaboration to build a more modular and maintainable system.

#10about 3 minutes

Q&A: Documentation, team size, and onboarding

The discussion covers managing documentation through the definition of done, the ideal team size of four to six engineers, and using a buddy system for onboarding.

Related jobs
Jobs that call for the skills explored in this talk.

Matching moments

The flawed debate between monoliths and microservices
02:34 MIN

The flawed debate between monoliths and microservices

Microservices? Monoliths? An Annoying Discussion!

Challenges of modernizing and scaling monolithic frontends
03:07 MIN

Challenges of modernizing and scaling monolithic frontends

Web-Fragments: incremental micro-frontends migration approach for enterprise

Transforming technology and internal ways of working
02:46 MIN

Transforming technology and internal ways of working

IKEA Story: Transforming an Iconic Retail Brand

Why traditional monoliths get a bad reputation
01:55 MIN

Why traditional monoliths get a bad reputation

Modulith Instead of Monolith - Pragmatically Towards Microservices

Tracing the architectural shift to micro frontends
02:15 MIN

Tracing the architectural shift to micro frontends

Front-End Micro Apps

Q&A on shared systems and scaling productivity
05:52 MIN

Q&A on shared systems and scaling productivity

Forget Developer Platforms, Think Developer Productivity!

Q&A: When to build a monolith application
00:50 MIN

Q&A: When to build a monolith application

Strategies to accelerate SaaS Application Development

Amazon's early monolith and database scaling challenges
08:41 MIN

Amazon's early monolith and database scaling challenges

Building Systems that Last

Featured Partners

Related Videos

See all videos
It’s all about the domain, honey ! Experiences from 15 years of Domain-Driven Design
43:13

It’s all about the domain, honey ! Experiences from 15 years of Domain-Driven Design

Carola Lilienthal

Move fast with Software Architecture
42:02

Move fast with Software Architecture

Simon Lasselsberger

We (don't) need a software architect!?!
24:52

We (don't) need a software architect!?!

Hendrik Lösch

The Rise of Reactive Microservices
46:24

The Rise of Reactive Microservices

David Leitner

Why you shouldn’t build a microservice architecture
27:32

Why you shouldn’t build a microservice architecture

Michael Eisenbart

Building high performance and scalable architectures for enterprises
58:23

Building high performance and scalable architectures for enterprises

Luka Samaržija & Ivan Sokol

Microfrontends at Scale
43:20

Microfrontends at Scale

Josh Goldberg

Microservices? Monoliths? An Annoying Discussion!
25:05

Microservices? Monoliths? An Annoying Discussion!

Eberhard Wolff

Related Articles

View all articles
Benedikt Bischof
Why You Shouldn’t Build a Microservice Architecture
Welcome to this issue of the WeAreDevelopers Live Talk series. This article recaps an interesting talk by Michael Eisenbart who talks about the pros and cons of microservice architecture.‍About the speaker:‍Michael has been working for Bosch as a sof...
Why You Shouldn’t Build a Microservice Architecture
Eli McGarvie
Stop Wasting Time: How to Lead a Stand-Up Meeting & Get Results
We all know the feeling: your stand-up meeting starts… and the energy in the room slowly deflates. Eyes glaze over, minds wander. Maybe you can even see their attention drop on smartphones or laptops.Within minutes or even seconds, instead of a quick...
Stop Wasting Time: How to Lead a Stand-Up Meeting & Get Results

From learning to earning

Jobs that call for the skills explored in this talk.