Enterprise Architecture Standards

Enterprise Architecture & Engineering Standards

Why this exists

Most systems don't fail because nobody knew the right pattern — they fail because the right pattern wasn't applied consistently under deadline pressure. This skill makes architectural rigor the default rather than something bolted on after a system already has scaling problems, data integrity bugs, or an unmaintainable service boundary. It complements (doesn't replace) bdd-comprehensive-testing and owasp-secure-coding-bdd: those cover behavior verification and security; this one covers whether the system is actually well-designed — the right shape, the right data model, the right resilience posture, the right performance characteristics — before those tests even get written.

The workflow

Step 1: Classify what's being built

Different work calls for different reference files. Identify which of these apply — most substantial tasks touch more than one:

• New service or system boundary (a new microservice, a new bounded context, splitting a monolith) → references/software-architecture-styles.md + references/microservices-patterns.md
• Database schema, data model, or persistence choice (new tables, new data store, migration, sharding) → references/database-architecture.md
• Any non-trivial function, class, or module (the actual code, regardless of scale) → references/coding-principles.md
• Service-to-service communication, external integration, or public/internal API → references/api-integration-design.md
• Anything that can fail, time out, or cascade (calls to other services, databases, queues) → references/resilience-reliability-patterns.md
• Anything with a load, latency, or scale requirement, or that touches a hot path → references/performance-scalability.md
• Anything that needs to be operated, monitored, or debugged in production → references/observability-operations.md
• Any significant design decision, tradeoff, or standard that should outlive this conversation → references/enterprise-governance-standards.md

Read only the reference files relevant to the task — don't load all nine for a one-line bug fix.

Step 2: Make the architecture decision explicit before writing code

For anything beyond a trivial change, briefly state (to yourself and, for significant decisions, to the user):

• What are the 2-3 realistic options?
• What does each trade off (complexity vs. flexibility, consistency vs. availability, latency vs. throughput, cost vs. resilience)?
• Which one fits this system's actual current scale and team size — not the scale it might have in five years. Over-engineering (premature microservices, premature sharding, speculative abstraction layers) is as much a violation of sound architecture as under-engineering. Match the solution to the problem's actual current and near-term requirements.

For decisions with real long-term consequences (a new service boundary, a database technology choice, an API contract other teams will depend on), write this down as a lightweight Architecture Decision Record — see references/enterprise-governance-standards.md for the format — rather than letting the reasoning live only in chat history.

Step 3: Apply the relevant principles as you build, not as an afterthought

Each reference file gives concrete, actionable guidance — not just naming patterns, but when to use them and when NOT to (most of these files spend real space on anti-patterns and misuse, because knowing when not to apply a pattern is the actual senior-engineer skill; "microservices everywhere" and "normalize everything to 3NF always" are both common ways teams over-apply a real principle past the point it helps). Apply this while writing the implementation, the same way owasp-secure-coding-bdd changes the implementation rather than only the tests.

Step 4: Cross-check against the other engineering skills

• Every service/endpoint/schema this skill touches should still get full happy/non-happy-path BDD coverage from bdd-comprehensive-testing, stored in the same permanent feature-file index.
• Every service/endpoint touching auth, data, input, or permissions should still get the owasp-secure-coding-bdd threat-modeling pass, including its mandatory lockout-prevention step for any permission/access/deletion change (schema migrations that drop columns/tables, and IAM/role changes for new services, both qualify).
• These three skills are meant to run together on real feature work, not in isolation — architecture soundness, behavioral correctness, and security are three different questions about the same code.

Step 5: Don't let "enterprise" become "over-engineered"

A recurring failure mode at the opposite extreme from sloppiness is architecture astronautics — introducing a message bus, a microservice, a generic plugin framework, or a distributed cache for a problem that a single well-structured module and a database index would solve better and more cheaply. When applying these principles, always check: does this system's actual current scale, team size, and change-rate justify this complexity? State the justification, don't just apply the pattern because it's "best practice" in the abstract. Simplicity that meets the actual requirement is itself a core enterprise architecture principle, not a shortcut around one.

Reference file index