Pattern Catalogue 2.0 Harmonisation

[russelltrow]

Context

During the catalogue restructuring, several groups of patterns were identified that overlap significantly or are too narrowly scoped. The team agreed to merge these into broader, higher-level patterns and to broaden overly specific patterns rather than simply removing them.

Following the Patterns 2.0 launch, the team agreed to extend this work into a full catalogue quality review — auditing all existing patterns for overlap, duplication, staleness, and consistency against the current pattern template. Paula raised that teams she works with get overwhelmed when directed to the catalogue without a clear sense of what to prioritise, and that the reorganisation surfaced more consolidation opportunities beyond the initially identified set.

A full categorisation review has now been completed. The tables below capture all proposed changes to existing patterns, and the new patterns that should replace them where applicable.

---

Existing patterns: proposed changes

Delete

UID	Pattern	Reason
arch-9	Use a service mesh only if needed	Too specific

Remove or consolidate (potential duplicate)

UID	Pattern	Reason
req-1	Enable text compression	Already covered by a general "Compress data" pattern

Rename

UID	Pattern	Proposed new name
req-2	Keep request counts low	Reduce unnecessary file loading in a HTML request

Update content (outdated or needs improvement)

UID	Pattern	Notes
arch-11	Serve images in modern formats	Needs updating
dev-4	Encrypt what is necessary	Needs updating and rephrasing
arch-10	Match your service level objectives to business needs	Needs rephrasing to connect to requirements phase
ops-13	Compress transmitted data	Update content
ops-14	Reduce transmitted data	Update content
ops-10	Time-shift Kubernetes cron jobs	Rewrite as a more general "time-shift cron jobs" pattern

Replace with consolidated patterns

UID	Existing pattern	Replaces with
dev-5	Scale infrastructure with user load	Dynamic scaling based on demand
dev-7	Scale Kubernetes workloads based on relevant demand metrics	Dynamic scaling based on demand
dev-10	Evaluate other CPU architectures	Adopt energy-efficient processor architectures
dev-14	Use cloud native processor VMs	Adopt energy-efficient processor architectures
dev-15	Delete unused storage resources	Optimise storage utilization
ops-1	Set storage retention policies	Optimise storage utilization
ops-2	Optimize average CPU utilization	Optimize CPU utilization
ops-3	Optimize peak CPU utilization	Optimize CPU utilization
ops-4	Deprecate GIFs for animated content	Optimize image delivery
ops-5	Match utilization requirements of virtual machines (VMs)	Right-size compute resources
ops-6	Match utilization requirements with pre-configured servers	Right-size compute resources
ops-7	Scale down applications when not in use	Scale down applications when not in use (generalised)
ops-8	Scale down Kubernetes applications when not in use	Scale down applications when not in use (generalised)

---

New patterns to create

The following new patterns are proposed, either as consolidations of the above or as net-new additions identified during the categorisation review.

Consolidation patterns (replace existing)

Pattern	Category	Description
Adopt energy-efficient processor architectures	Architecture	Merged from: Evaluate other CPU architectures + Use cloud native processor VMs
Minimize transmitted data size	Development	Merged from: Compress transmitted data + Reduce transmitted data
Optimize image delivery	Development	Merged from: Deprecate GIFs for animated content + Serve images in modern formats
Dynamic scaling based on demand	Operations	Merged from: Scale infrastructure with user load + Scale Kubernetes workloads based on relevant demand metrics
Scale down applications when not in use	Operations	Generalised from: Scale down applications when not in use + Scale down Kubernetes applications when not in use
Optimize CPU utilization	Operations	Merged from: Optimize average CPU utilization + Optimize peak CPU utilization
Optimise storage utilization	Operations	Merged from: Delete unused storage resources + Set storage retention policies
Right-size compute resources	Operations	Merged from: Match utilization requirements of VMs + Match utilization requirements with pre-configured servers

Net-new patterns

Pattern	Category	Description
AI Training Efficiency	Architecture (TBC)	📌 Description to be defined
Inference Optimization	Architecture (TBC)	📌 Description to be defined
Carbon-Aware AI Scheduling	Architecture (TBC)	📌 Description to be defined
Choose a sustainable hosting provider	Architecture	Prioritize data centers using clean energy on-premises or via their utility, over those relying solely on renewable energy contracts
Monitoring and benchmarking	Architecture	Continuously monitor and benchmark environmental impact from the start; use results to manage impact across releases
Include the Planet in your Brief	Requirements	Set environmental and emission reduction goals linked to OKRs; connect to business and user opportunities
Remove non-essential features from scope	Requirements	Validate user needs, prioritise stories, define MVP, regularly review feature relevance
Prioritize Longevity & Maintainability	Architecture	Design for longevity using robust, well-documented, modular technologies
Prioritize a mobile-first approach	Design	Validate user journeys, develop mobile-specific content, remove non-essential features, optimize multimedia

---

What needs to happen

• Raise individual PRs for each proposed merge/consolidation in the tables above
• Each PR should show the original patterns and the proposed replacement
• At least one subject matter expert should review each merge to ensure no important guidance is lost (Liya's request)
• For overly specific patterns: attempt to broaden the wording first before proposing removal
• Team to review and approve PRs asynchronously
• Generate drafts for net-new patterns using the green software pattern skill
• Confirm category and description for the three AI patterns (AI Training Efficiency, Inference Optimization, Carbon-Aware AI Scheduling) — engage Green AI Committee
• Audit any remaining patterns not listed above for template consistency and content quality
• Document a lightweight ongoing process for pattern quality review

Acceptance criteria

• All patterns in the change tables above have been actioned (deleted, renamed, updated, or replaced)
• All consolidation patterns have been drafted and reviewed by at least one SME before merging
• No patterns removed without an attempt to broaden them first
• All new patterns generated via the skill and reviewed through the standard workflow
• All three AI net-new patterns (Training Efficiency, Inference Optimization, Carbon-Aware AI Scheduling) have confirmed descriptions and categories
• Remaining patterns not listed above reviewed for template consistency
• A documented process exists for ongoing pattern quality review

Dependencies

• Green software pattern skill (for generating new pattern drafts)
• Green AI Committee input on the three AI net-new patterns
• Reviewer capacity (Liya / Franzi)
• Backlog pattern proposals triage (#) — consolidation decisions should account for incoming generated patterns to avoid creating new overlaps