-
Notifications
You must be signed in to change notification settings - Fork 44
Patterns Analysis ‐ August 2026 ‐ Architecture
| # | Pattern | Passes | Fails (principle #) | Recommendation |
|---|---|---|---|---|
| 1 | choose-region-closest-to-users | 8 | 5, 8, 10 | Minor revision |
| 2 | containerize-your-workload-where-applicable | 7 | 2, 5, 10, 11 | Revision |
| 3 | efficient-hardware-ai-workloads | 9 | 8, 11 | Near-ready / consolidation discussion |
| 4 | evaluate-using-a-service-mesh | 4 | 1, 4, 5, 7, 8, 9, 10 | Revision (assessed in detail earlier) |
| 5 | implement-stateless-design | 8 | 5, 9, 10 | Revision |
| 6 | on-demand-execution-ai-agent-workloads | 9 | 6, 11 | Near-ready / consolidation discussion |
| 7 | queue-non-urgent-requests | 8 | 5, 10, 11 | Revision + consolidation |
| 8 | reduce-network-traversal-between-VMs | 4 | 1, 2, 5, 6, 7, 8, 10 | Substantial revision |
| 9 | run-ai-models-edge | 10 | 6 | Publication ready (minor trim) |
| 10 | scale-logical-components-independently | 8 | 5, 10, 11 | Revision + consolidation |
| 11 | serverless-model-development | 5 | 1, 5, 7, 8, 10, 11 | Consolidate into #6 |
| 12 | energy-efficent-framework | 4 | 1, 5, 6, 7, 8, 9, 10 | Substantial revision |
| 13 | energy-efficent-models | 4 | 1, 2, 5, 7, 8, 9, 10 | Substantial revision |
| 14 | evaluate-other-cpu-architectures | 6 | 5, 7, 9, 10, 11 | Revision + consolidation |
| 15 | use-energy-efficient-hardware | 3 | 2, 4, 5, 7, 8, 9, 10, 11 | Substantial revision or consolidation |
| 16 | use-serverless | 6 | 5, 7, 8, 10, 11 | Revision + consolidation |
Principle key: 1 Fewer/Better/Broader · 2 Patterns not Practices · 3 Honour Framing · 4 Action-on-Resource · 5 Complete Sections · 6 Conciseness · 7 Decision Confidence · 8 Testable Assumptions · 9 Real Considerations · 10 Trade-off Visibility · 11 No Duplication
1. Missing Cost Impact is nearly universal. 13 of 16 patterns fail Principle 5/10 on this alone. The only three with a complete Cost Impact section are the three modern AI patterns submitted by Naveen Balani (#3, #6, #9) — all undated, all correctly tagged category: Architecture in front matter. Every other pattern (2022–2024 vintage, front matter says category: cloud or category: ai — not a valid category value) lacks it. This strongly suggests Cost Impact was only enforced starting with the newer submission batch — worth raising with whoever maintains the review checklist, since it's not a per-pattern authoring lapse but a category-wide historical gap.
2. Three real duplication clusters, all worth a team decision before further per-pattern editing:
-
Serverless/on-demand execution: #11 (
serverless-model-development) is very likely superseded by #6 (on-demand-execution-ai-agent-workloads), which covers the same ground more thoroughly and completely. #16 (use-serverless) is the general/umbrella version of the same idea. Recommend consolidating #11 into #6, and deciding whether #16 becomes a "general case" pattern that #6 links to, or is folded in as a section. -
CPU/hardware architecture selection: #14 (
evaluate-other-cpu-architectures) and #15 (use-cloud-native-processor-VMs) are the same recommendation at two altitudes (general vs. ARM-specific), and #3 (efficient-hardware-ai-workloads) is the AI-specific version of the same underlying idea. Recommend consolidating #14 and #15 at minimum; #3 can likely stay separate given its AI-specific depth. -
Peak-demand flattening (confirmed in the earlier Requirements review): #7 (
queue-non-urgent-requests) here overlaps withoptimize-peak-cpu-utilization(Operations) andshed-lower-priority-traffic(Requirements). Same recommendation as before — resolve via a merge discussion. - Additionally, #2 (
containerize-your-workload) and #10 (scale-logical-components-independently) are complementary enough that a straight merge isn't obviously right, but #2's own text points readers to #10 — worth at least an explicit cross-reference if not a merge.
3. Two patterns are essentially stubs. #12 (energy-efficent-framework) and #13 (energy-efficent-models) both have literal None for Assumptions and Considerations — not vague, but absent. These are the weakest patterns in the entire review across both categories assessed so far and should be prioritized for rework or removal ahead of the others.
4. Two patterns violate "Patterns, not Practices" via vendor-specificity rather than framework/code-level detail — #8 (reduce-network-traversal-between-VMs) embeds bare vendor console-feature URLs as its Solution, and #15 (use-cloud-native-processor-VMs) is written as a buyer's guide to a specific 2022-era chip family. This is a slightly different flavor of Principle 2 violation than seen in the Requirements category (there it was mostly vague language; here it's over-specific, time-bound vendor detail) — worth naming as its own failure pattern when briefing authors.
5. Best patterns in the category: run-ai-models-edge (10/11, essentially publication-ready) and efficient-hardware-ai-workloads (9/11) — both from the same recent AI-focused submission batch, both demonstrate what a complete Cost Impact and honest Considerations section should look like for the rest of the catalogue to emulate.
Fails:
- 5 — No Cost Impact section.
- 8 — Assumptions (lines 32–33) is a narrative hypothetical ("Suppose we choose a region that is further away... A better solution would be...") not a stated, checkable condition.
- 10 — Cost content exists but is misplaced/unquantified in Considerations ("may reduce cloud bills") rather than a real Cost Impact treatment (no egress-cost or latency-vs-cost discussion).
Passes: 1, 2, 3, 4, 6, 7, 9, 11 — clean Action-on-Resource title, concrete Solution, and a genuinely useful Consideration (feature-availability workaround overhead in the closer region).
Fails:
- 2 — Solution says compliance can be achieved "using tools for generating Dockerfiles and Kubernetes manifests" — names specific implementation artifacts, not pattern-level guidance.
- 5 — No Cost Impact (container orchestration/tooling cost never discussed).
- 10 — Same gap; K8s cluster management overhead — a well-known real cost — goes unmentioned.
-
11 — Its own Considerations says "Consider modernizing your applications into micro-service architectures that allow independent sizing and scaling of their logical components" — this is literally the subject of pattern #10 (
scale-logical-components-independently). The two should at least cross-reference, if not partially merge.
Passes: 1, 3, 4, 6, 7, 8, 9.
Fails:
- 8 — "Suitable hardware options are available for the workload" / "Performance benchmarks reflect real-world usage" are close to universal truisms rather than a sharp, pattern-specific gating condition.
- 11 — Overlaps with #14 and #15 (all three are "choose more efficient CPU/hardware" at different altitudes: AI-specific / general CPU / specific ARM VM family).
Passes: 1, 2, 3, 4, 5, 6, 7, 9, 10 — this is the strongest-structured pattern in the batch: full Cost Impact with 5 honest trade-off bullets, 4 genuine Considerations, 5 references.
Assessed in full detail earlier this conversation — Fails: 1, 4, 5, 7, 8, 9, 10 (7 of 11), most notably an Assumption ("does not have compliance requirements") that is verbatim the skill's own textbook bad example. Passes: 2, 3, 6, 11. Recommendation stands: Revision.
Fails:
- 5 — No Cost Impact and no References section at all (the 12factor.net link is dropped inline in Considerations, not a References list).
- 9 — Sole "Consideration" is "Follow the 12-factor app methodology" — a link to an external methodology, not an actual trade-off or complication (doesn't mention the real friction: externalizing state adds network calls, cache-consistency complexity, and shifts resource cost onto the external store).
- 10 — No Cost Impact; the pattern never acknowledges that externalizing state to a NoSQL DB/cache doesn't eliminate cost, it moves it.
Passes: 1, 2, 3, 4, 6, 7, 8, 11 — clean title, testable-enough assumption ("application design supports externalization of state").
Fails:
- 6 — 8 Solution bullets + 6 Considerations pushes past "three strong points" into exhaustive territory; several bullets restate the same idea (trigger conditionally / avoid always-on / dynamic scaling).
-
11 — Its own first Solution bullet — "Use serverless or event-driven platforms to execute workloads only when triggered" — is near-verbatim the subject of both #11 (
serverless-model-development) and #16 (use-serverless). Three patterns, one core idea, at three altitudes.
Passes: 1, 2, 3, 4, 5, 7, 8, 9, 10 — genuinely excellent Cost Impact (names cold-start/provisioned-concurrency trade-offs explicitly) and honest Considerations.
Fails:
- 5 — No Cost Impact (message-queue infrastructure has a real, well-known operational cost never quantified).
- 10 — Same gap; "additional overheads" in Considerations is the only nod to cost, unquantified.
-
11 — Confirmed duplication cluster (established in the Requirements-category review):
optimize-peak-cpu-utilization.md(Operations) explicitly lists "queuing non-urgent requests" as an example technique in its own Solution, andshed-lower-priority-traffic.md(Requirements) covers the same "flatten peak demand" goal via a sibling tactic.
Passes: 1, 2, 3, 4, 6, 7, 8, 9 — actually one of the more honest legacy patterns: Assumptions genuinely gates on async-tolerant components, Considerations names real decoupling/operational-overhead complexity.
Fails:
- 1 — Description is one sentence, Solution is one sentence plus three bare links; doesn't clear the "genuinely useful on its own" bar.
- 2 — Solution embeds bare vendor documentation URLs (AWS placement groups, GCP instance placement, Azure VM affinity) as the guidance — implementation-practice detail standing in for pattern-level direction.
- 5 — No Cost Impact, and no References section — the three vendor links live inside Solution instead.
- 6 — The apparent "conciseness" here is thinness, not editorial discipline — there's nothing to distill.
- 7 — "Choose the VM placement that is best for your workload" never says what "best" means or what to weigh (latency vs. redundancy vs. carbon).
- 8 — "VM placement options provided by cloud providers are adequate for this workload" — "adequate" is unquantified and untestable.
Passes: 3, 4, 9 (the multi-AZ-tradeoff Consideration is genuinely good — one of the most honest single sentences in the batch), 11.
Fails:
- 6 — 7 Solution bullets + 5 Considerations, similar over-length issue to #6 (same authoring pattern/template).
Passes: everything else, including a standout Considerations section that explicitly counters the naive "edge = greener" assumption ("Embodied emissions of edge devices must be accounted for") and an honest Cost Impact ("Cloud cost savings offset by edge device and management overhead"). This is the best pattern in the Architecture category — genuinely close to publication-ready, and notably the only one of the three "AI architecture trio" (with #6 and #3) that isn't caught in a duplication cluster, since it addresses a distinct decision axis (where inference runs, vs. what hardware or when).
Fails:
- 5 — No Cost Impact, and no References section at all.
- 10 — Microservice decomposition carries substantial, well-known operational/tooling cost (observability, service mesh, engineering complexity) — entirely unaddressed.
-
11 — Overlaps with #2 (
containerize-your-workload), which explicitly points here in its own Considerations, and loosely with #4 (evaluate-using-a-service-mesh).
Passes: 1, 2, 3, 4, 6, 7, 8, 9 — actually has the best Considerations section in the whole category: it names microservice framework overhead (messaging, tracing, security) and over-decomposition/communication overhead as real, specific trade-offs, even suggesting gRPC over HTTP as a mitigation.
Fails:
- 1 — Thin overall, and its own sibling pattern (#6) covers the same ground far more thoroughly.
- 5 — No Cost Impact, and Assumptions literally reads "None" (line 39) — a required section reduced to a null placeholder.
- 7 — With zero Assumptions, there's no gating criteria for when this does or doesn't apply.
-
8 — Evidence:
## Assumptions/None. The most extreme version of this failure mode in the review. - 10 — No Cost Impact, conspicuous given #6 covers the identical territory (serverless/on-demand AI execution) with a full, honest Cost Impact section.
- 11 — Evidence: compare this pattern's Solution — "Adopt a serverless architecture for maximum resource utilization for your entire AI/ML model development process... resources are launched only when required" — against #6's Solution — "Use serverless or event-driven platforms to execute workloads only when triggered... Design agent workflows to run only when required." Same idea; #6 is newer, broader (covers agentic workflows, not just training pipelines), and structurally complete where this one is not.
Passes: 2, 3, 4, 6, 9.
Recommendation: Consolidate into #6 rather than revise standalone — this pattern reads as superseded by on-demand-execution-ai-agent-workloads.md.
Fails:
- 1 — One-sentence Solution, "None" for Assumptions and Considerations.
-
5 — Three of seven required sections effectively absent (
Cost Impactmissing;Assumptions: None;Considerations: None). - 6 — Thinness, not discipline.
- 7 — The Description's own insight — "AI/ML frameworks built on languages like C/C++ are more energy efficient" — never makes it into the Solution, which just says "evaluate and select" with zero criteria.
- 8, 9 — Evidence: explicit "None" for both.
- 10 — No Cost Impact; framework migration/porting cost (a substantial real cost) unmentioned.
Passes: 2, 3, 4, 11.
Recommendation: This is one of the weakest patterns in the entire catalogue — essentially a title and one sentence.
Fails:
- 1 — "None"/"None" again, though the Solution itself has real content (see below).
- 2 — Solution names specific, dated products with specific benchmarked percentages ("DistilBERT... 60% faster... 97% of BERT's performance," "GPT-Neo 125M... vs GPT-J 6B or GPT-Neo 2.7B"). This is a buyer's-guide / product-recommendation, not a durable pattern — these 2020-era models will keep aging out, unlike a framing such as "prefer distilled/smaller model variants that preserve most of the larger model's accuracy."
-
5 — No Cost Impact;
Assumptions: None;Considerations: None. - 7, 8, 9 — Same "None/None" evidence as #12.
- 10 — No Cost Impact, and no acknowledgment of the accuracy-vs-efficiency trade-off its own cited stats imply (a 3% BERT performance gap matters for some use cases and not others — never discussed).
Passes: 3, 4, 6, 11.
Recommendation: Same severity as #12, plus a durability problem from naming specific aging models.
Fails:
- 5 — No Cost Impact.
- 7 — "Other CPU architectures... should be evaluated... with energy efficiency and execution performance in mind" gives no criteria for how to evaluate or what workload traits favor a switch.
- 9 — Sole Consideration ("also consider specialized accelerators") is a see-also pointer, not a complication — no mention of the real friction (recompilation, native-library/dependency incompatibility, performance regressions).
- 10 — No Cost Impact; porting/testing cost for an architecture migration goes unmentioned.
-
11 — Overlaps heavily with #15 (
use-energy-efficient-hardware, i.e., "use ARM-based cloud-native VMs") — the general pattern and its vendor-specific instance, split into two separate patterns by two different authors.
Passes: 1, 2, 3, 4, 6, 8 — the assumption here ("framework can be executed on other CPU architectures and is optimized for it") is at least a real, checkable gate, unlike #15's version of essentially the same idea.
Fails:
- 2 — Solution links directly to a vendor marketing article (Ampere) and Considerations embeds two more vendor SKU-announcement links in place of prose — this reads as a buyer's guide to specific 2022-era cloud SKUs, not a durable pattern.
- 4 — Title "cloud native processor VMs" borrows Ampere's own marketing term rather than a self-descriptive resource name (a reader unfamiliar with the term won't know this means "ARM-based, low-power server CPUs").
- 5 — No Cost Impact.
- 7 — Assumption ("cloud provider offers VM SKUs based on efficient hardware") is close to tautological given the Solution already asserts this; unlike #14's sibling assumption, it says nothing about the reader's own workload's compatibility with the architecture.
- 8 — Same evidence as above — doesn't gate on anything specific to the reader.
- 9 — Considerations is a cost claim plus two bare vendor links — no discussion of the real complication (ARM/Ampere compatibility: native libraries, container base images, recompilation) that #14 at least gestures toward.
- 10 — No Cost Impact; the cost claim present ("tend to be cost effective as well") is a single unquantified sentence.
- 11 — Same duplication as #14, from the other direction — this is the narrower, vendor-specific instance of that pattern's general claim.
Passes: 1, 3, 6.
Recommendation: Weakest pattern in the technology-selection folder — recommend either a substantial rewrite (generic architecture-class framing, vendor examples moved to a Considerations footnote) or consolidation with #14.
Fails:
- 5 — No Cost Impact, despite its own AI-specific siblings (#6, #11) demonstrating exactly what a complete Cost Impact section for this exact topic looks like.
- 7 — "Evaluate serverless based on your application requirements" gives no criteria (request-volume pattern, latency sensitivity, execution-duration limits) for making that evaluation.
- 8 — "There is an assumption that the application can benefit from serverless architectures" is circular — it assumes the pattern will work in order to justify applying it.
- 10 — SCI Impact gestures at the cold-start-vs-intensity trade-off but doesn't quantify it, and there's no Cost Impact section at all.
- 11 — This is the general/umbrella version of the same core idea covered by #11 (AI/ML-specific) and #6 (AI-agent-specific) — three patterns, one theme, three altitudes. The strongest three-way duplication cluster in the whole category.
Passes: 1, 2, 3, 4, 6, 9 (cold-start and architecture-redesign considerations are genuine).