Becoming a high-performance organization

(and how to stay one)

Becoming a high-performance organization

"The top tips version"

Schedule

  1. Intro - 1 min
  2. Definition of high-performance - 4 mins
  3. 6 tips for operational performance - 15 mins
  4. Q & A - 10mins

What is a high performance organization

And does it really matter?

Definition of high performance

A high-performance organization

↕↕↕

A learning organization which relentlessly delivers value to its customers

Definition of high performance

High-performers vs low performers

  • 46 times more frequent code deployments
  • 440 times faster lead time from commit to deployment
  • 170 times faster mean time to recovery from downtime
  • 5 times lower change failure rates

Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations - 2018

Definition of high performance

Impact on organizational performance

State of DevOps report 2014

Definition of high performance

Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations - 2018

Definition of high performance

Our experience:

Before After
Deployment 1-2 times per sprint ~10 times per day
Work lead time 3-4 weeks 4-5 days
deployment lead time 5 days ~15 minutes

6 tips to achieve operational performance

Op performance tips

Tip #1: How to avoid Monoliths

  • A modular monolith is probably OK
  • Use DDD
  • Use Context mapping
  • Use EventStorming
Op performance tips

It is not the domain expert’s knowledge that goes into production, it is the developer’s assumption of that knowledge that goes into production

Alberto Brandolini

Op performance tips

Tip #2: Avoid persistence ↔ domain model impedence

  • Use event-sourcing
  • Use your SME's to build your models
  • Use Event Storming or Event Modeling
Op performance tips

Tip #3: Reduce coupling

  • Use Event Driven Architecture
  • Apply reactive principles
  • Prefer choerography...
  • ...or share-nothing
Op performance tips

Tip #4: Have meaningful test coverage

  • Use onion architecture → domain is dependency-free
  • Use quick-feedback tests to validate domain
  • Use contract tests to test public data contract versions
  • Small number of end-to-end tests
Op performance tips

Tip #5: How to reduce development-time dependencies

  • Bounded Contexts (Event Storming, Context Mapping)
  • Structure teams around BC's
  • Event Driven Architecture
  • More stable service owns the contract
Op performance tips

Tip #6: How to reduce rework and waste

  • Adopt an improvement budget
  • Cross-functional teams
  • Swarm / pair (one-piece flow)
  • Pull-based system for development (with WIP)
  • Carefully consider all alternatives
Op performance tips

Reference material:

Process Architecture People
height:160px height:160px height:160px height:160px height:160px height:160px height:160px height:160px height:160px

Thank you

Savvas Kleanthous

You can find this presentation here: https://skleanthous.github.io/presentations/

Twitter:
More to come. Follow me on Twitter for more details.

• This includes distributed monolits • DDD helps you identify Bounded Contexts: domain (think business departments) boundaries and model them in code, encapsulating complexity • Event Storming builds on top of that and further helps identify contexts and discover business processes • Context mapping will help you model the integration between BC's • The above are the only really safe way to do microservices. You may succeed outside of DDD / Event Storming, but you're taking a bet HELPS: by keeping amount of time needed to introduce changes small by encapsulating changes

HELPS: Helps guarantee the information is there when you need it HELPS: Maintening the solution and adding features to domain is FAR easier

HELPS: Changes do not cascade HELPS: Adding features keeps taking the same amount of time as time goes by1

HELPS: decrease deployment lead time • OBVIOUSLY: you need rock-solid CI / CD

HELPS: Reduced lead times because one team does not have to wait for another team • Event driven architectures help reduce development time dependencies due to NO behavioural coupling

HELPS: Time taken in rework or waste, is time which isn't used in delivering value All of above help with both waste and rework.