Posted on

Measure Lead Time for the Business

When teams adopting DevOps ask me, “What should we measure to know that we’re improving?” I have reflexively rattled off the metrics from Accelerate.

  • Throughput
    • Deployment frequency (frequency an app is released)
    • Lead Time (time from code commit to working in prod)
  • Stability
    • Change failure rate (changes requiring a subsequent fix or causing outage)
    • Time to restore (typical restoration time when an outage occurs)

These broadly make sense and point to a high degree of automated deployment, testing, and robust monitoring. These tenants of DevOps have been helpful. The State of DevOps Report shows that strong performers in these areas outperform their competition in the market. The reality of that is something I have wagered on and won. 

Posted on

Know the Business Case for Rearchitecting

Today, it’s pretty normal to write new applications in a “cloud-native” way. Whether we deliver to a public cloud or use a container fabric behind the firewall, we commonly work with microservices or serverless. A data store is as likely to be block storage or Mongo as it is a traditional database. This makes sense. Small components match well with DevOps teams operating independently (see Conway). In general, modern architecture, infrastructure, and delivery approaches support more frequent releases and more resiliency in production. All good things.

However, most apps are not new. A typical enterprise can have many hundreds to a couple of thousand existing applications. Do they sit as they are until replaced? Do we rearchitect them all? Will some move? And if so, which?