Application Design Framework (ADF)

Introduction

Application design phase often stretches into weeks, with non–value-added rework compounding delays. The design process requires integrating multiple use cases into a cohesive system architecture. While designing individual use cases is usually straightforward, combining them introduces exponential architectural complexity. The resulting cognitive load makes it difficult to reconcile conflicting requirements and maintain alignment between use cases and the overall architecture. Without a clear way to sustain this alignment, design cycles expand, requirements are missed, and rework follows.

The Application Design Framework (ADF) helps maintain tight alignment between use cases and architecture through proven, prescriptive guidelines. With ADF, teams can shorten the design phase from weeks to days and avoid non–value-added rework–shipping the right solution faster.

Tenets

1. Use case-driven. Every decision should be guided by the use case. If it doesn’t serve one, it’s out of scope.
2. Traceability matters. Every use case should map to architecture, and architecture to code. Anyone should be able to follow the thread.
3. Architecture first, technology second. Architecture satisfies business and technical requirements; technology implements them. Separate architecture and technology decisions to reduce cognitive load.

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 may change over time.

Guidelines

Describe use case (Sales, Marketing, Product) to clarify the problem and define business requirements.

• Answer the 5 customer questions ^[5]: 1/ who is the customer and what insights do we have about them? 2/ what is the prevailing customer problem/opportunity? what data informed this? 3/ what is the solution? why is it the right solution to address the customer need versus other alternatives? 4/ how would we describe the end-to-end customer experience (business flows)? what is the most important customer benefit? 5/ how will we define and measure success?
• Describe business flows using domain storytelling, story maps, or event storming.
• Consider writing press release/frequently asked questions (PR/FAQ) narrative (example) or pitch.
• Identify bounded contexts and external dependencies.
• Document business requirements using EARS patterns: “while [optional pre-condition], when [optional trigger], the [system name] shall [system response]” (e.g., “while the user is signed-in, when the user asks to change the password, the application shall re-authenticate the user”).

Define architecture (Product, Engineering) to address business and define technical requirements.

• Define technical flows (e.g., load balancer → API → database) based on business flows.
• Consider the following integration dimensions ^[7]: 1/ service discovery (e.g., IP addresses, DNS) 2/ data format (e.g., binary, XML, JSON, protobuf, Avro) 3/ interaction type (e.g., sync, async) 4/ interaction style (e.g., messaging, RPC, query, GraphQL).
• Identify application boundaries and components. Use “fracture planes” ^[8] to help decide on application 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.
• Review decisions based on the following pillars ^[9]: 1/ operational excellence 2/ security 3/ reliability 4/ performance efficiency 5/ cost optimization.
• Document decisions using architectural decision records (ADRs).
• Document technical requirements using EARS patterns: “while [optional pre-condition], when [optional trigger], the [system name] shall [system response]” (e.g., “while the deployment pipeline is running, when there is a change to the pipeline structure, the pipeline shall stop and restart with the new structure”).

Choose technologies (Engineering) to address technical requirements.

• Consider building proof of concept (POC) for new technologies to validate feasibility.
• Review decisions based on the following pillars ^[9]: 1/ operational excellence 2/ security 3/ reliability 4/ performance efficiency 5/ cost optimization.
• Document decisions using architectural decision records (ADRs).

Write code (Engineering) to implement business and technical requirements.

• Create one or more repositories and a single pipeline per application to reduce blast radius and increase delivery performance.
• Organize resources configuration and business logic code by application components to align architecture with code.

Examples

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

Templates

• Standard (Markdown)
• Standard (Word)

Related frameworks

• AWS Well-Architected Framework - apply architectural best practices for designing and operating reliable, secure, efficient, cost-effective, and sustainable systems.
• Google Cloud Architecture Framework - recommendations to help architects, developers, administrators, and other cloud practitioners design and operate a cloud topology that’s secure, efficient, resilient, high-performing, and cost-effective.
• Azure Well-Architected Framework - a set of quality-driven tenets, architectural decision points, and review tools intended to help solution architects build a technical foundation for their workloads.
• 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.
• AWS Decision Guides - choose AWS services that might be right for you and your use cases.
• Azure Decision Guides - choose Azure services that might be right for you and your use cases.

Ongoing research

• Backlog planning - from use cases and architecture to code:
  • Stories break down into tasks. Requirements are inputs to tasks. Conditions of satisfaction (acceptance criteria) are the tasks outputs. Map flows to stories and requirements to tasks for traceability.
  • Consider the following story types ^[6]: 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 – “[action] the [result] [by/for/of/to] a(n) [object]” (e.g., “generate a unique identifier for a transaction”).
• A mechanism for introducing ADF into organization (inputs, tools, adoption, inspection, iteration, outputs).
• Organizing ADF information for multiple use cases and applications.

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. Giulia Rossi and Dave Brown - Working backwards: Amazon’s approach to innovation
6. Martin Fowler - User Story
7. Gregor Hohpe - The Many Facets of Coupling
8. Matthew Skelton and Manuel Pais - Team Topologies
9. AWS Well-Architected Framework - Pillars

This site is open source. Improve this page.