Here are some questions you might find useful when running a self-assessment with your team against these principles.
- 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?
- 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?
- 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?
- Are you leveraging the services in the cloud?
- Did you intend it to be in the cloud from the start?
- Can you release straight to Production?
- 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?
- 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?
Automate By Default
- Are you using a CI tool?
- What manual gates are in place?
Get Feedback Early and Often
- Are you practicing Continuous Delivery?
- Could you do daily releases?
- Are you using trunk based development with feature flags as necessary?
- Are branches short-lived?
- If a new person joins, can they get up to speed quickly?
- Can code be safely refactored due to good test coverage?