Self-Assessment

We encourage our teams to reflect on how they are performing against these principles - typically through a dedicated retro.

Here are some questions you might find useful when running a self-assessment with your team against these principles. If you have ideas for additional questions, then please do contribute.

---

Build Differentiators

• Do you consider this when choosing the technology?
• Google Cloud Datastore or Elasticsearch are examples of “buy”
• Do you reinvent the wheel, building systems already out there?

Design for Emergent Reuse

• If there are lots of different components do you take into account the pace of change of the components?
• Do you over-engineer your solutions?
• Do you reuse for the sake of it?
• Is your system going to be around for a long time?

Evolutionary Systems

• If you change your system is it an isolated change with regard to other systems?
• How many people does it take to release?
• How often can you release?
• Can Ops release during the day?
• How many requirements do you put into one iteration?
• How future proof is it for requirements that may not exist?

Scale Horizontally

• State cannot be stored in-memory but rather must be persisted to the client or a shared datastore.
• It is not always possible to scale horizontally e.g. for traditional relational databases, increased performance is often achieved through better hardware or higher specifications
• Services should strive to be idempotent

Small and Simple

• How long do your tests take?
• Can you describe your components?
• Can you test your components independently?
• Can you deploy components independently?

Smarts in the Nodes, not the Network

• Do you have business logic in your integration layer?
• Do you apply business rules in your data transformations?
• If there is business logic is it for your own system’s consumption?

Cloud Native

• Are you leveraging the services in the cloud?
• Did you intend it to be in the cloud from the start?

Production Ready

• Do you understand your failure modes?
• Do you understand how monitoring helps you understand your failure modes?
• How close is the system to its limit?
• Are there circuit breakers?
• Are there rolling deployments, eg kubernetes?
• Do you have dashboards, golden signals, engineering metrics for traffic and resilience?

Keep Pace with Technological Change

• What technology is the team using?
• Is it up to date?
• Is it well supported?
• Is it current?
• How often is it upgraded and patched?
• Are the team interested in this area?
• Is the software on its way out?

Model the Business Domain

• Does it use DDD (Domain driven design)?
• Could a business person understand the language used in your code?
• How well do you own your domain?
• Are there changes not owned by your team?

Secure by Design

• Have you considered access control?

Consistent Environments

• Are you using infrastructure as code? Examples are terraform or puppet.
• Have you got any processes in keeping data up to date?
• Are there lots of manual processes?

Continuous Delivery

• Are you doing it? Are you using a CI tool?
• What manual gates are in place?
• Can you release straight to Production?
• Are you using trunk based development with feature flags as necessary?
• Are branches short-lived?

Get Feedback Early and Often

• Could you do daily releases?

Understandability

• If a new person joins, can they get up to speed quickly?
• Can code be safely refactored due to good test coverage?