AWS re:Invent 2025 - Capability-first architecture: Bridging business intent to technology (ARC202)

Capability-first Architecture: Bridging Business Intent to Technology

The Need for Evolvable Architectures

• Technology choices and architectural patterns have exploded, leading to "choice paralysis" for businesses
• Businesses are struggling to translate business intent into effective technology choices and solutions
• There is a need to shift from technology-centric to capability-centric architecture

Lessons from Evolutionary Biology

• Architectural adaptability is key - evolution happens incrementally, not overnight
• Technical debt is the "cost of evolution" that must be measured and managed proactively
• The "locus of evolution" should be capabilities, not just technology choices

The Capability Framework

Defining Capabilities

• Capabilities represent logical subunits of a workload with well-defined business intent
• Capabilities can be identified using techniques like business ownership, domain-driven design, functional cohesion, and distinguishing traits

Capability Composition

• Capabilities are defined by two factors: functional requirements and non-functional requirements (NFRs)
• NFRs should be elevated to "first-class status" alongside functional requirements
• Architectural characteristics are the critical, non-negotiable NFRs that define a capability

Aligning Capabilities and AWS Services

• AWS services exhibit specific architectural characteristics (e.g. scalability, performance, simplicity)
• Matching a capability's characteristics to the right AWS service enables optimal technology choices

Constraints and Architectural Decision Records (ADRs)

• Constraints (budget, skills, timelines, etc.) can be beneficial by encouraging creativity and frugality
• Artificial constraints like enterprise guidelines should be evaluated against the capability framework
• ADRs provide a lightweight, standardized way to document architectural decisions, trade-offs, and consequences

Applying the Framework

• Start with capabilities, not technologies
• Identify the critical architectural characteristics for each capability
• Shortlist technology options that align with the capability characteristics and constraints
• Continuously evolve the architecture through incremental changes and proactive management of technical debt

Key Takeaways

• Treat architectures as living, evolvable systems anchored around capabilities, not just technologies
• Elevate non-functional requirements to be first-class citizens alongside functional requirements
• Use the capability framework to make intentional, well-documented technology choices
• Leverage AWS services that align with the architectural characteristics of your capabilities
• Embrace constraints as opportunities for creativity and frugality, not just limitations

Real-world Examples

• E-commerce product catalog capability: Optimized for scalability, reliability, and performance using ECS, DynamoDB, and S3
• Recommendation engine capability: Optimized for cost-effectiveness, maintainability, and agility using Amazon Bedrock