ArchitectureConference50min
System Drift and how to live with it
Microservices often drift from their intended design as services proliferate, boundaries blur, and temporary integrations become permanent. This talk explains system drift, why it happens, and how small, targeted interventions can guide architecture without relying on top-down redesigns.
talk.summaryAiDisclaimer
James LewisThoughtworks
talkDetail.whenAndWhere
Thursday, June 18, 14:35-15:25
Room 1
talks.roomOccupancytalks.noOccupancyInfo
Microservices changed how we think about software architecture. They gave us a language for decomposition, team ownership, and independent evolution. But they also exposed something we’re still struggling with:
Services proliferate. Boundaries blur. “Temporary” integrations become permanent. Architecture slowly drifts into something else; shaped less by intention and more by the interactions between teams, systems, and constraints. The problem isn’t microservices. It’s that we’re still treating complex systems as if they’re controllable.
System drift is the gradual, emergent evolution of a system away from its intended design, driven by local decisions, constraints, and feedback loops.
We’ll look at why systems drift, why some changes stick while others don’t, and how to make small, targeted interventions that move your architecture in a better direction - without relying on top-down redesigns. If you’ve built or operated microservices and found that the hard problems start after the architecture diagram is finished, this talk will give you a way to navigate what comes next.
Services proliferate. Boundaries blur. “Temporary” integrations become permanent. Architecture slowly drifts into something else; shaped less by intention and more by the interactions between teams, systems, and constraints. The problem isn’t microservices. It’s that we’re still treating complex systems as if they’re controllable.
System drift is the gradual, emergent evolution of a system away from its intended design, driven by local decisions, constraints, and feedback loops.
We’ll look at why systems drift, why some changes stick while others don’t, and how to make small, targeted interventions that move your architecture in a better direction - without relying on top-down redesigns. If you’ve built or operated microservices and found that the hard problems start after the architecture diagram is finished, this talk will give you a way to navigate what comes next.
James Lewis
James is a Distinguished Engineer at Thoughtworks based in the UK. He’s proud to have been a part of Thoughtworks’ journey for over twenty years and of its ongoing mission to deliver technical excellence for its clients around the world.
James, along with Martin Fowler, defined the new Microservices architectural style back in 2014. He is an internationally recognised expert on software architecture and design and on its intersection with organisational design and lean product development. As such he’s been a guest editor for IEEE Software, written articles, delivered training and spoken at more conferences than he can remember.
James, along with Martin Fowler, defined the new Microservices architectural style back in 2014. He is an internationally recognised expert on software architecture and design and on its intersection with organisational design and lean product development. As such he’s been a guest editor for IEEE Software, written articles, delivered training and spoken at more conferences than he can remember.