Tech Health Scoring

The 10 engineering strategy dimensions behind the score — open one to see the checklist a team actually answers

Depth varies by dimension — these are the questions as the organisation actually uses them.

• Build it well, run it well Code quality and operational ownership are one discipline, not two.
  7 questions

  • We have wanted observability, logging, monitoring
  • We can independently deploy it to production
  • Autoscaling enabled?
  • Lead Time for Changes
  • Deployment Frequency
  • Failure Rate
  • Mean Time to Restore Services
• A set of few, intentional tools Deliberate technology choices over a sprawl of one-off frameworks.
  2 questions

  • Do we have any unwanted technologies?
  • Have alternative (off the shelf or open-source) solutions been considered?
• AWS Native over Cloud Native Lean on managed platform primitives instead of reinventing infrastructure.
  1 question

  • Are we using AWS alternatives when available and suitable?
• Democratize the data Data is accessible and usable across teams, not siloed behind one owner.
  2 questions

  • Is the data available to be consumed by others?
  • Can the data be understood by the consumer?
• Event-driven architecture Systems react to events rather than polling or tight coupling.
  4 questions

  • Are events published?
  • Are we publishing events that tell the world what we are doing (transparency)?
  • Do the events tell the story of the producer's domain?
  • Are event schemas available for consumers?
• Composable building blocks Shared, reusable components over bespoke solutions per team.
  3 questions

  • Does the solution have clearly defined inputs and outputs?
  • Is the solution documented in a way that a new engineer can get an overview of the solution?
  • Does the solution have a clear purpose, that can be understood by developers?
• Secure Security is a design constraint from the start, not a later audit.
  9 questions

  • Requirement for all services: we have enabled m2m authentication
  • Are we following our secure engineering policy?
  • Have we done a security assessment of the solution?
  • We are using recommended deployment modules
  • Have we done a risk assessment of the solution, at the frequency specified in our secure system development policy?
  • Are databases configured in accordance with policy?
  • Are we patching the system according to the secure development policy?
  • Is data access following least-privilege principle?
  • Are we compliant with our audit logging principles?
• Each product has a clear contract with the outside world Consumers can rely on a stable, discoverable interface without asking the owning team.
  3 questions

  • Is the product's interface (API, events, schema) explicitly versioned?
  • Is a breaking change communicated to consumers before it ships?
  • Can a consumer discover the contract without asking the owning team?

  Snowberry-authored — no source questions existed for this dimension.

• Knowledge level in team The team understands the systems it runs, not just the code it wrote.
  2 questions

  • Multiple members of the team are able to make changes in the system and deploy them
  • Multiple members of the team understand the system and how it impacts the outside world
• Well-defined metrics that show we are successful Success is measured against a defined product metric, not assumed.
  1 question

  • Do we have product metrics defined to tell if the solution is performing according to its purpose?