Derek Comartin, a Microsoft MVP and distributed systems architect, discusses breaking up monoliths, defining service boundaries, responsibilities and contracts in software delivery, benefits of asynchronous messaging, leveraging technologies, and the importance of context and boundaries in software architecture.

Adam welcomes Dr. Mik Kersten to the show. Dr. Mik Kersten is the author of the best selling book "Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework". This is a follow up to the earlier "Four Types of Work" episode.Adam & Mik cover the Flow Framework's origin story, the relation between The Flow Framework and DevOps, the importance of structure & dynamics, and why organizing for fast flow is the prime directive.Adam Hawkins' LinksSmall Batches #9: The Four Types of WorkThe Flow FrameworkMik Kersten's LinksMik Plus One PodcastProject to Product BookHow Value Stream Networks Will Transform IT & Business (Presented at DOES18) ★ Support this podcast on Patreon ★

Adam welcomes Joe Kutner to the show. Joe is a Software Architect at Salesforce Heroku. He's been writing and speaking about the 12 factor app for years and continually evaluating the practices at Salesforce Heroku.Adam & Joe discuss the misconceptions of the 12 factor app and the gaps between the 12 factor app and continuous delivery requirements. This is really a follow up discussion to the earlier episodes on the 12.1 Factor app.Joe Kutner's LinksCloud Native Build PacksAdam Hawkins' LinksSmall Batches #5: The 12 Factor AppThe 12.1 Factor App: ConfigThe 12.1 Factor App: LogsThe 12.1 Factor App: Dev-Prod Parity ★ Support this podcast on Patreon ★

Jason's testing courseJason's websiteJason on twitterJason's podcast: Rails with JasonMy review of AccelerateThe DORA Report ★ Support this podcast on Patreon ★

Today I’m covering the 2019 book "Team Topologies: Organizing Business & Technology Teams for Fast Flow" written by Matthew Skelton & Manuel Pais.Let me read off their official bio:Matthew Skelton and Manuel Pais - co-authors of the book Team Topologies - have worked together on organisation design for modern software systems with many clients around the world. Their training sessions on Organisation Design for Modern Software Systems have helped numerous organizations to re-think their approach to team intercommunication and software architecture, improving flow and the effectiveness of software delivery.So I’m stoked to finally discuss Team Topologies on Small Batches. This book has come up so many times in my work as an SRE at Skillshare and tangentially related to everything I’ve discussed on Small Batches to date. This is because team architecture and software architecture are directly related to software delivery performance.That’s particularly why I enjoyed Team Topologies so much because it’s truly a book about high velocity software delivery. In fact it’s right there smack in the title. Plus it provides a language to discuss this facet of software delivery.You’ve likely encountered some of these concepts before, so this time around it may just be a new language.I’ll share a personal anecdote from earlier in my career to set the stage for this episode. Roughly fives years ago I lead the platform team through a complete ground up rewrite at a previous company. We were divided into technology teams: The web, mobile, and platform team. Given these boundaries each of respective team lead set out to create their internal architecture. Nothing to see here: just Conway’s law in action. It worked well here because we had isomorphic technology and team architecture. Then something happened out of the blue shortly after the rewrite completed. The organization went through a total re-org that changed the team structure, their responsibilities and how they interacted without doing anything to address the underlying technical architecture. This created confusing boundaries, ownership responsibilities, and left so called "independent feature teams" at the mercy of the small number of capable backend engineers capable of working across the various internal services. These problems could have been avoided with some foresight and planning. Plus it’s especially bothersome because the entire engineering team had just finished a ground up rewrite that architected a system to support an entirely different team topology! If there was ever a time for a reverse Conway maneuver that was not it.This example speaks to the importance of Conway’s law and how team and software architecture fit together to create fast flow or on the other hand just inhibit it.Team Topologies provides a framework that avoids this problem from the outset by optimizing for fast flow.LinksSmall Batches #34: Team Topologies with Matthew Skelton@Manuelpaisable@MatthewPSkeltonBuy Team TopologiesMonoliths vs Microservices is Missing the Point—Start with Team Cognitive Load @ DOES Europe 2019Team Topologies PostersTeam Topologies on Mik Plus OneTeam Topologies at Parts Unlimited w/Manuel PaisThe Idealcast # 5: The Pursuit of Perfection: Dominant Architectures, Structure, and Dynamics: A Conversation With Dr. Steve Spear ★ Support this podcast on Patreon ★

This is a special episode of Small Batches. I interview Dave Farley in this episode.Dave, along with Jez Humble, is the co-author of "Continuous Delivery" published in 2010. The book introduced the ideas that grew into DevOps. So, no surprise that DevOps and continuous delivery are the same most people. Together Dave and Jez introduced continuous delivery to the world. The practices and ideas still hold true ten years on.Time and research have demonstrated that continuous delivery is the most effective way to develop software. If you’ve read Accelerate then you know what I’m talking about. That’s partially why am so passionate about it and that doesn’t even account for the fun I have working in that environment.Dave and I talked about different aspects of continuous delivery beginning with the difference between software development and software engineering. Or as Dave put’s it: scientific rationalism.We also speak about the connection from delivery, feedback, and experimentation. Or, as he put’s it: "just doing engineering".He also shared why he doesn’t like the term DevOps. I gotta say I tend agree with him after hearing his reasoning. Lastly I get his view on the Preflight Checks I mentioned in an early episode of this podcast. Go to smallbatches.fm/11 for that episode.Now I give you my conversation with Dave Farley.You can find Dave at:The Continuous Delivery bookHis YouTube channelHis blogHis consulting servicesOn Twitter ★ Support this podcast on Patreon ★

The Phoenix ProjectThe Unicorn Project ★ Support this podcast on Patreon ★

If you enjoyed this format then tweet me @adman65 or @smallbatchesfm. ★ Support this podcast on Patreon ★

Start HereSLOs defined from the Google Site Reliability Engineering BookImplementing SLOs from the Google Site Reliability Engineering WorkbookThe Art of SLOs workshop by GoogleFreebiesMastering the Third Way of DevOps use the Toyota Kata for continuous improvementFree DevOps Course much more detailed than what we can cover in the podcastResourcesMy Review & Analysis on The DevOps HandbookMy Review & Analysis on AccelerateSoftware Development in 3 Principles & 4 MetricsBooksThe DevOps Handbook by Gene Kim, Jez Humble, John Willis, Patrick DeboisAccelerate by Nicole Forsgren, Jez Humble, Gene Kim ★ Support this podcast on Patreon ★

FreebiesMastering the Third Way of DevOps use the Toyota Kata for continuous improvementFree DevOps Course much more detailed than what we can cover in the podcastResourcesTranscriptMy Review & Analysis on The DevOps HandbookMy Review & Analysis on AccelerateSoftware Development in 3 Principles & 4 MetricsBooksThe DevOps Handbook by Gene Kim, Jez Humble, John Willis, Patrick DeboisAccelerate by Nicole Forsgren, Jez Humble, Gene Kim ★ Support this podcast on Patreon ★