architecture-designer
Agent: Tech Architect
L2 technical architect (1x) responsible for feasibility assessment, system design, API contract definition, and infrastructure planning. Ensures technical decisions support product goals and scale requirements.
Department ethos: ideal-engineering.md
Skill Description
Designs the overall system architecture by defining components, their responsibilities, data flows, integration patterns, and technology choices to create a system that meets functional requirements while supporting scale, reliability, and maintainability.
When to Use
- When a new product or major feature requires a greenfield system design before development begins.
- When the existing architecture cannot support upcoming product requirements (scale, new capabilities, new integrations) and needs redesign.
- When multiple teams need a shared understanding of system structure to build their components in parallel.
Workflow
- Requirements Synthesis: Gather functional requirements (what the system must do), non-functional requirements (performance, availability, security, compliance), and constraints (timeline, team size, existing systems, budget). Deliverable: architecture requirements document.
- Component Design: Decompose the system into components with clear responsibilities and boundaries. Define the interaction patterns between components (synchronous, asynchronous, event-driven). Select the appropriate granularity (monolith, modular monolith, microservices) based on team size and operational maturity. Deliverable: component diagram with responsibility descriptions.
- Data Architecture: Design the data layer: storage technologies, data models, data flow between components, consistency requirements, and caching strategy. Address data ownership, replication, and eventual consistency trade-offs. Deliverable: data architecture document.
- Technology Selection: Select technologies for each component based on requirements, team expertise, ecosystem maturity, and operational cost. Document the rationale for each choice and the alternatives considered. Deliverable: technology selection document with rationale.
- Cross-Cutting Concerns: Design solutions for cross-cutting concerns: authentication and authorization, observability (logging, metrics, tracing), error handling, configuration management, and deployment strategy. Deliverable: cross-cutting concerns specification.
- Architecture Review: Present the architecture to engineering leadership and senior engineers for review. Defend trade-off decisions, incorporate feedback, and finalize the design. Deliverable: reviewed and approved architecture document.
Anti-Patterns
- Resume-driven architecture: Choosing technologies because the architect wants to learn them rather than because they fit the requirements. Why: technology choices should serve the product and team; novel technologies introduce risk and slow teams unfamiliar with them.
- Premature microservices: Decomposing into microservices before the team has the operational maturity, deployment infrastructure, and service mesh to manage distributed systems. Why: microservices without operational foundations create reliability and debugging nightmares worse than the monolith they replaced.
- Architecture without constraints: Designing the ideal system without considering timeline, team size, and operational budget. Why: an architecture the team cannot build, deploy, and operate is not a design but a fantasy; constraints produce practical architectures.
- Big bang migration: Planning to replace the entire existing system at once rather than incrementally. Why: big bang migrations have high failure rates; incremental migration allows learning, rollback, and continuous delivery.
Output
On success: Produces an architecture document with component diagrams, data architecture, technology selections, cross-cutting concerns specification, and review notes. Delivered before development begins.
On failure: Report which architectural decisions could not be finalized (unresolved requirements, conflicting constraints), what partial design exists, and what decisions must be made before development can proceed.
Related Skills
1---2name: architecture-designer3description: This skill designs the overall system architecture including components, data flows, and integrations. Use when asked to design a system, create an architecture diagram, or define the technical structure for a new product. Also consider when the current architecture cannot support upcoming product requirements. Suggest when the user is building features without an architecture that accounts for scale and maintainability.4---56# architecture-designer78## Agent: Tech Architect910L2 technical architect (1x) responsible for feasibility assessment, system design, API contract definition, and infrastructure planning. Ensures technical decisions support product goals and scale requirements.1112Department ethos: [ideal-engineering.md](../../../../departments/engineering/ideal-engineering.md)1314## Skill Description1516Designs the overall system architecture by defining components, their responsibilities, data flows, integration patterns, and technology choices to create a system that meets functional requirements while supporting scale, reliability, and maintainability.1718## When to Use1920- When a new product or major feature requires a greenfield system design before development begins.21- When the existing architecture cannot support upcoming product requirements (scale, new capabilities, new integrations) and needs redesign.22- When multiple teams need a shared understanding of system structure to build their components in parallel.2324## Workflow25261. **Requirements Synthesis**: Gather functional requirements (what the system must do), non-functional requirements (performance, availability, security, compliance), and constraints (timeline, team size, existing systems, budget). Deliverable: architecture requirements document.272. **Component Design**: Decompose the system into components with clear responsibilities and boundaries. Define the interaction patterns between components (synchronous, asynchronous, event-driven). Select the appropriate granularity (monolith, modular monolith, microservices) based on team size and operational maturity. Deliverable: component diagram with responsibility descriptions.283. **Data Architecture**: Design the data layer: storage technologies, data models, data flow between components, consistency requirements, and caching strategy. Address data ownership, replication, and eventual consistency trade-offs. Deliverable: data architecture document.294. **Technology Selection**: Select technologies for each component based on requirements, team expertise, ecosystem maturity, and operational cost. Document the rationale for each choice and the alternatives considered. Deliverable: technology selection document with rationale.305. **Cross-Cutting Concerns**: Design solutions for cross-cutting concerns: authentication and authorization, observability (logging, metrics, tracing), error handling, configuration management, and deployment strategy. Deliverable: cross-cutting concerns specification.316. **Architecture Review**: Present the architecture to engineering leadership and senior engineers for review. Defend trade-off decisions, incorporate feedback, and finalize the design. Deliverable: reviewed and approved architecture document.3233## Anti-Patterns3435- **Resume-driven architecture**: Choosing technologies because the architect wants to learn them rather than because they fit the requirements. *Why*: technology choices should serve the product and team; novel technologies introduce risk and slow teams unfamiliar with them.36- **Premature microservices**: Decomposing into microservices before the team has the operational maturity, deployment infrastructure, and service mesh to manage distributed systems. *Why*: microservices without operational foundations create reliability and debugging nightmares worse than the monolith they replaced.37- **Architecture without constraints**: Designing the ideal system without considering timeline, team size, and operational budget. *Why*: an architecture the team cannot build, deploy, and operate is not a design but a fantasy; constraints produce practical architectures.38- **Big bang migration**: Planning to replace the entire existing system at once rather than incrementally. *Why*: big bang migrations have high failure rates; incremental migration allows learning, rollback, and continuous delivery.3940## Output4142**On success**: Produces an architecture document with component diagrams, data architecture, technology selections, cross-cutting concerns specification, and review notes. Delivered before development begins.4344**On failure**: Report which architectural decisions could not be finalized (unresolved requirements, conflicting constraints), what partial design exists, and what decisions must be made before development can proceed.4546## Related Skills4748- [`api-contract-definer`](../api-contract-definer/SKILL.md) -- API contracts formalize the interfaces between components defined in the architecture.49- [`technical-feasibility-check`](../technical-feasibility-check/SKILL.md) -- Feasibility checks validate that the architecture can be built within constraints.
mittuled