senior-system-architecture

Original：🇺🇸 English

Translated

Guides senior system and solution architecture—cross-service boundaries, integration patterns, non-functional requirements (scale, reliability, security, cost), ADRs, C4-style modeling, architecture review, build-vs-buy, and phased migration (strangler, dual-write). Use when designing multi-service systems, evaluating platform or vendor choices, writing or reviewing architecture decision records, defining standards and principles, or assessing technical risk across domains—not for single-service RFCs and module design (senior-software-engineer), data platform or mesh decisions (data-architect), cloud landing zone, Well-Architected, and migration architecture (cloud-architect), cloud/IaC implementation (infrastructure-engineer, cloud-engineer), internal developer platform product (platform-engineer), or program tracking (technical-program-manager). For business strategy and cases, use business-consultant; for applied AI (RAG, agents, copilots), use applied-ai-architect-commercial-enterprise.

2installs

Sourcedaemon-blockint-tech/agentic-enteprises-skill

Added on2026-05-20

NPX Install

npx skill4agent add daemon-blockint-tech/agentic-enteprises-skill senior-system-architecture

SKILL.md Content

View Translation Comparison →

Senior System Architecture

When to Use

Define or review cross-service/system boundaries and contracts
Compare architectural options with explicit trade-offs and NFR impact
Author or review ADRs for decisions that are hard to reverse
Run architecture review before major launches or vendor commitments
Plan migration off legacy systems (strangler, parallel run, cutover)
Establish architecture principles, standards, and exception process

When NOT to Use

Single-team service RFC and implementation slices →
```
senior-software-engineer
```
Lakehouse, mesh, or enterprise data modeling →
```
data-architect
```
VPC, Kubernetes, Terraform, or CI/CD build →
```
infrastructure-engineer
```
,
```
devops
```
IDP, golden paths, Backstage →
```
platform-engineer
```
Milestones, RAID, steering status →
```
technical-program-manager
```
Release cutover tactics only →
```
deployment-strategist
```
Security control catalog and enterprise GRC →
```
cybersecurity
```
LLM/RAG system design →
```
ai-engineer
```
Business strategy, issue trees, steerCo cases →
```
business-consultant
```

Applied AI / LLM solution architecture →

applied-ai-architect-commercial-enterprise

Customer-facing solution design, RFP/RFI, PoC scope, deal integration →
```
solutions-architect
```

Related skills

Need	Skill
Service-level RFC and code review	`senior-software-engineer`
Data domain and governance architecture	`data-architect`
Cloud solution and migration architecture	`cloud-architect`
Enterprise cloud governance and landing zones	`enterprise-cloud-architect`
Cloud/network/IaC delivery	`infrastructure-engineer` , `cloud-engineer`
Platform-as-product and golden paths	`platform-engineer`
Multi-team launch coordination	`technical-program-manager`
Rollout and rollback planning	`deployment-strategist`
Security architecture and controls	`cybersecurity` , `information-security-engineer`
Requirements and business constraints	`business-analyst`
Strategy, business case, operating model	`business-consultant`
AI/LLM solution patterns	`ai-engineer`
Commercial/enterprise applied AI architecture	`applied-ai-architect-commercial-enterprise`
Customer deal solution, RFP, PoC handoff	`solutions-architect`

Core Workflows

1. Frame the decision

Capture before drawing boxes:

Business outcome and measurable success criteria
Constraints: budget, timeline, compliance, existing estate
Non-goals (explicit scope cuts)
Stakeholders and decision owner
Reversibility: one-way door vs two-way door

One-way doors require ADR + architecture review. Two-way doors can stay in team RFC.

2. Model the system (C4-lite)

Minimum views for reviewers:

Context — actors, external systems, trust zones
Containers — deployable units, data stores, queues, who owns each
Critical path — sequence diagram for highest-risk flows only

Label every arrow: sync/async, protocol, auth model, and failure behavior.

See
references/integration_patterns.md
.

3. Define NFRs and quality attributes

For each capability, specify targets (not vague "high availability"):

Attribute	Example target	Verification
Availability	99.9% monthly	SLO, error budget
Latency	p99 < 300ms read	Load test + prod SLO
Throughput	5k RPS peak	Capacity model
Durability	RPO 1h, RTO 4h	DR drill
Security	mTLS east-west, OIDC	Threat model link
Cost	<$X / 1M requests	FinOps estimate

See
references/nfr_quality_attributes.md
.

4. Evaluate options

Present at least two viable options plus "do nothing / minimal change":

Criterion	Weight	Option A	Option B
Time to value
Operational burden
Scalability headroom
Team skill fit
Vendor lock-in
Security/compliance fit

Recommend one; document rejected options and why.

See
references/adr_template.md
.

5. Architecture review

Before build or contract signature:

Problem and constraints restated in one paragraph
Diagrams current; contracts versioned (OpenAPI, event schema)
Failure modes: partial outage, dependency down, poison messages
Data: ownership, retention, PII, migration path
Observability: golden signals per container
Security: authz boundaries, secrets, blast radius
Rollout and rollback linked to
```
deployment-strategist
```
if multi-phase

See
references/architecture_review.md
.

6. Evolution and migration

For legacy replacement:

Identify capability slices that can move independently
Prefer strangler over big-bang when risk is high
Define parity criteria before cutover
Plan dual-write / dual-read duration and reconciliation
Deprecate old path with telemetry proving zero traffic

See
references/migration_evolution.md
.

When to load references

ADR format and bar →
```
references/adr_template.md
```
Review checklist →
```
references/architecture_review.md
```
Sync, events, sagas, APIs →
```
references/integration_patterns.md
```
SLOs, capacity, DR, cost →
```
references/nfr_quality_attributes.md
```
Strangler and cutover →
```
references/migration_evolution.md
```