Application Design Framework (ADF)

Purpose

The Application Design Framework (ADF) reduces lead time by bridging product-to-engineering gaps.

Definitions

Application boundary ^[1]:

• A body of code that’s seen by developers as a single unit
• A group of functionality that business customers see as a single unit
• An initiative that those with the money see as a single budget

Architecture ^[2][3]:

• An architecture describes how components work together. How components communicate and interact is often the focus of architecture diagrams.

Component ^[4]:

• Software components are things that are independently replaceable and upgradeable.

Mindset

Application is an ownership boundary.

Application boundary should evolve with organizational and software changes.

Guidelines

ADF introduces the following guidelines along with related personas:

1. Capture use cases and features [Sales, Marketing, Product] to clarify problem and solution. Write a paragraph or press release/frequently asked questions (PR/FAQ) or pitch. Use domain storytelling and/or event storming to identify bounded contexts and stories.
2. Write stories and flows [Product, Engineering] to start conversation about requirements. Choose story syntax: 1/ User Story – “As a [type of user] I [want this thing] so that [I can accomplish this goal]” (e.g., “As a site visitor, I want to see new content when I come to the site, so I come back more often”) 2/ Job Story – “When [situation], I want to [motivation], so I can [expected outcome]” (e.g., “When it’s dinner time tonight, I want to have pizza so I can easily feed my friends”) 3/ Feature-Driven Development (FDD) – “[action] the [result] [by/for/of/to] a(n) [object]” (e.g., “Generate a unique identifier for a transaction”). Describe the flow (e.g., “Navigate to example.com”, “Sign-in”, “Open ‘My Files’ view”, “Select a file”, “Click on ‘Download’”, “Choose where to store the file”, “Click ‘Save’”).
3. Define requirements [Product, Engineering] to guide architectural decisions. Group requirements into business and technical categories. Prioritize architecturally significant requirements: business value/risk, stakeholder concern, quality level, external dependencies, cross-cutting, first-of-a-kind, source of problems on past projects. Consider operational excellence, security, reliability, performance efficiency and cost optimization ^[5].
4. Define architecture [Product, Engineering] to address requirements. Identify application boundaries by describing stories and flows on technical level. Identify application components by describing requirements on technical level. Choose technologies. Use the following “fracture planes” ^[6] to help decide on the boundaries: 1/ Profit and Loss Group 2/ Business Domain Bounded Context 3/ Regulatory Compliance 4/ Change Cadence 5/ Team Location 6/ Risk 7/ Performance Isolation 8/ Technology 9/ User Personas. Capture Architectural Decision Records (ADRs) including “why” behind decisions, options considered, trade-offs, and consequences. ADRs allow to evolve the architecture starting from known design considerations. Consider building proof of concept (POC) to validate the decisions.
5. Create one or more repositories and a single pipeline per application [Engineering] to reduce blast radius and increase delivery performance.
6. Structure resources configuration and business logic code by application component [Engineering] to align design with implementation, streamline onboarding, simplify operations, and ease evolution.

Examples

• High-level application design from use case to code
• Application boundary and deployment model evolution
• IAM Session Broker application

Templates

• Application

Related frameworks

• AWS Well-Architected Framework - apply architectural best practices for designing and operating reliable, secure, efficient, cost-effective, and sustainable systems.
• Operational Readiness Review - ensure a consistent review of operational readiness, with a specific focus on eliminating known, common causes of impact

Related guidance

• Awesome Architecture - concepts and foundations, followed by jobs-to-be-done

Ongoing research

• A mechanism for introducing ADF into organization (inputs, tools, adoption, inspection, iteration, outputs).
• Organizing ADF information for multiple use cases and applications.
• Using conditions of satisfaction (acceptance criteria) together with or instead of the requirements section.
• Linking architecrual decision records (ADRs) to requirements and stories (e.g., referencing the related requirement(s) and story(ies) in ADR context) to check impact of an architectural check during design phase.

References

1. Martin Fowler - ApplicationBoundary
2. AWS Well-Architected Framework - Definitions
3. Neal Ford and Mark Richards - Software Architecture: the Hard Parts
4. Martin Fowler - SoftwareComponent
5. AWS Well-Architected Framework - Pillars
6. Matthew Skelton - Designing organizations for responsiveness

This site is open source. Improve this page.