Tweet
Tweet

Slide 1

Slide 1 text

The Platform as a point of failure for Product Operating Model transitions Val Yonchev

Slide 2

Slide 2 text

Team what? https://teamtopologies.com/

Slide 3

Slide 3 text

Words of Caution Photo by Maria Freyenbacher on Unsplash

Slide 4

Slide 4 text

Challenges in transition: What is a Product? Photo by Giorgio Trovato on Unsplash Photo by Trew on Unsplash

Slide 5

Slide 5 text

Challenges in transition: Too little Products - Too many Products Photo by Giorgio Trovato on Unsplash Photo by Trew on Unsplash

Slide 6

Slide 6 text

Challenges in transition: What is really a value stream?

Slide 7

Slide 7 text

Think Mars Photo by Kabo on Unsplash

Slide 8

Slide 8 text

Think Mars Inc. Photo by Behnam Norouzi on Unsplash Photo by Kabo on Unsplash

Slide 9

Slide 9 text

Think Automotive

Slide 10

Slide 10 text

Challenges in transition: Technology is NOT part of our products Photo by Markus Spiske on Unsplash

Slide 11

Slide 11 text

Challenges in transition: Poor understanding of Value Chains Wardley Mapping starts with the Customer, her needs. Then helps define boundaries as well as what to build, what to buy

Slide 12

Slide 12 text

Challenges in transition: Value Streams & Customer Journeys Event Storming (light DDD) helps understand the Customer journey and how systems are designed to support it

Slide 13

Slide 13 text

Challenges in transition: Internal platforms are NOT products

Slide 14

Slide 14 text

Challenges in transition: Let's talk Platforms Photo by Tomas Anton Escobar on Unsplash Photo by Arif Riyanto on Unsplash Photo by Massimo Botturi on Unsplash Photo by Kevin Harris on Unsplash Photo by Nathan Cima on Unsplash Photo by Tolu Akinyemi 󰐕 on Unsplash

Slide 15

Slide 15 text

Platform Fail: We need one, right?! Platform Engineering

Slide 16

Slide 16 text

Platform Fail: No money left for platforms Photo by Towfiqu barbhuiya on Unsplash

Slide 17

Slide 17 text

Platform Fail: The Christmas Tree platform Photo by Arkadiusz Radek on Unsplash

Slide 18

Slide 18 text

Platform Fail: The forcing factor Photo by Brad Helmink on Unsplash

Slide 19

Slide 19 text

Platform Fail: What do we optimize for? Photo by Julian Hochgesang on Unsplash

Slide 20

Slide 20 text

Let's talk Platforms Photo by Tomas Anton Escobar on Unsplash Photo by Arif Riyanto on Unsplash Photo by Massimo Botturi on Unsplash Photo by Kevin Harris on Unsplash Photo by Nathan Cima on Unsplash Photo by Tolu Akinyemi 󰐕 on Unsplash

Slide 21

Slide 21 text

package Platform Engineering import "Team Topologies" type Principles interface

Slide 22

Slide 22 text

Principle: Treat the Platform as a Product Photo by Giorgio Trovato on Unsplash Photo by Trew on Unsplash

Slide 23

Slide 23 text

Accelerate the flow of value AND Reduce cognitive load within the whole system AND Enable substantial autonomy of teams consuming them

Slide 24

Slide 24 text

Principle: Platform accelerates Flow of Value (+autonomy) MBPM = Metric-Based Process Mapping

Slide 25

Slide 25 text

Principle: Platform reduces cognitive load

Slide 26

Slide 26 text

Principle: Enable a composable approach - reusable components and services Photo by FORTYTWO on Unsplash

Slide 27

Slide 27 text

Principle: Cognitive load drives decisions (team-of-teams & boundaries design) Buy these (replace own developed) Build these (replace own developed)

Slide 28

Slide 28 text

Principle: Cognitive load drives decisions (team-of-teams & boundaries design)

Slide 29

Slide 29 text

https://teamtopologies.com/ish Principle: Cognitive load drives decisions (team-of-teams & boundaries design) If DDD is scary, start with Independent Service Heuristics

Slide 30

Slide 30 text

Principle: Use fracture planes to divide complexity Business domain Regulatory Compliance Change Cadence Technology Risk Performance Isolation User Personas/Journeys Team Location Photo by Elizabeth George on Unsplash

Slide 31

Slide 31 text

For your information, there's a lot more to Ogres than people think… Ogres are like onions. Onions have layers. Ogres have layers... Platforms Platforms Platforms

Slide 32

Slide 32 text

Principle: Platform teams have cognitive load and needs too

Slide 33

Slide 33 text

Principle: Platforms serve real needs of real customers ● Who is the customer? ● What does she need? ● What job does your product do for her? ● Can one product serve several different customers OR do they have different jobs to be done?

Slide 34

Slide 34 text

Principle: Team is the smallest unit of delivery (and measurement) DevelopMENT Experience DevelopER Experience X

Slide 35

Slide 35 text

Principle: Design for Development Degrees of Freedom "Black box" Services Modifiable Services Configurable Services “I love that everything just works!” “The platform lets me experiment and innovate, and I can contribute my enhancements back to improve it.” “ I can tweak things the way I need them.”

Slide 36

Slide 36 text

● Build/serve for one group at a time ● Collaboration interaction pattern precedes X-as-a-Service Principle: Start with one team, build the Thinnest Viable Platform

Slide 37

Slide 37 text

Principle: Competition drives progress ● Competition drives progress ● Product use is optional ● Technology evolve and sometimes you need to switch from in-house to commodity Photo by Shiwa ID on Unsplash Photo by Denis Cherkashin on Unsplash

Slide 38

Slide 38 text

Principle: Platforms Products are never intuitive or easy enough X

Slide 39

Slide 39 text

Principle: Teams communicate through Team APIs Team API Service API https://github.com/TeamTopologies/Team-API-template

Slide 40

Slide 40 text

Principle: Consider the whole system (Fast Flow Of Value) People (Teams) Tech (Architecture) Process (SDLC)

Slide 41

Slide 41 text

It is a journey. Iterate! Photo by Anshu A on Unsplash Photo by Nadya Spetnitskaya on Unsplash

Slide 42

Slide 42 text

Thank you for listening! [email protected] linkedin.com/in/valyonchev Let's talk. Book time with Val

Slide 43

Slide 43 text

https://teamtopologies.com/platform-manifesto