GuidesChangelogDiscussions
Log In
Guides

Designs

Designs turn architecture goals or recommendations into structured plans. They describe the current state, target state, key gaps, tradeoffs, and implementation path so teams can review and execute architecture changes with confidence.


Types of Designs

Designs vary in scope and complexity:

  • Feature Designs: Architecture plans for adding a new product capability or workflow
  • Modernization Designs: Plans for evolving legacy systems, replacing outdated components, or moving toward a target state
  • Migration Designs: Phased approaches for moving services, data, infrastructure, or workloads from one architecture to another
  • Optimization Designs: Proposals focused on improving cost, performance, reliability, scalability, security, or maintainability
  • Target-state Designs: Forward-looking architecture definitions for where a system should go next
  • Composite Designs: Larger architecture plans that decompose into smaller phases, workstreams, or implementation steps

Structure of a Design

Each Design contains several core components:

Problem and Goals

Defines the reason for the Design:

  • The business or technical problem being addressed
  • The desired outcomes
  • The goals, non-goals, and constraints
  • The scope of systems, teams, or workflows included

Current Architecture

Assesses the existing state:

  • Relevant systems, services, dependencies, and infrastructure
  • Current implementation patterns
  • Known risks, bottlenecks, limitations, or technical debt
  • Existing requirements or architecture decisions that must be preserved

Target Architecture

Defines the proposed future state:

  • The recommended architecture direction
  • New or changed components
  • Expected benefits from implementation
  • Technical rationale for the proposed approach

Gap Analysis

Evaluates the delta between current and target states:

  • Specific differences between the current and proposed architectures
  • Required changes to systems, integrations, data flows, or ownership
  • Technical and business impact of closing the gaps
  • Risks, dependencies, and assumptions that need review

Implementation Plan

Specifies how to move from current state to target state:

  • Recommended phases or sequencing
  • Required actions, such as add, replace, migrate, refactor, reuse, or retire components
  • Dependencies across systems, teams, or platforms
  • Validation steps and success criteria
  • Expected outcomes and measurable impact

Example Design

Design Area: Data Architecture

Design: Modernize analytics storage for append-only OLAP workloads

Problem and Goals: The current analytics workload relies on a general-purpose database that is not optimized for high-volume, append-only analytical queries. The goal is to improve query performance, reduce cost, and create a more scalable foundation for analytics-backed product features.

Current Architecture: The system currently stores analytical data in MongoDB. While MongoDB is a strong NoSQL database for many operational use cases, it is generally less efficient for append-only OLAP workloads because of higher lookup costs and more limited compression characteristics for large analytical datasets.

Target Architecture: Move append-only analytical workloads to a column-oriented DBMS. A column-oriented architecture is better suited for high-volume analytical queries, can improve compression, and can materially reduce cost and latency for analytics-heavy workloads.

Gap Analysis: The primary gap is between the operational data store currently being used and the analytical access patterns required by the product. Closing this gap requires separating OLAP-style workloads from the existing MongoDB implementation, defining the appropriate data ingestion path, and validating downstream analytics dependencies.

Implementation Plan: Introduce a column-oriented DBMS for append-only analytical data, migrate the relevant analytics workload in phases, validate query performance and cost improvements, and keep MongoDB for use cases where its document model remains appropriate. For high-volume append-only data, this Design could produce significant cost and performance improvements while preserving the parts of the current architecture that still fit their purpose.