Catalog
concept#Architecture#Software Engineering#Product

Conceptual Design

Abstract development of models and core decisions that guide architecture and solution designs.

Conceptual design describes the systematic creation of abstract models and core decisions that guide subsequent architecture and solution design.
Established
Medium

Classification

  • Medium
  • Technical
  • Architectural
  • Intermediate

Technical context

Architecture repository or decision databaseModeling and collaboration tools (e.g., Structurizr)Requirements management tools

Principles & goals

Separate responsibilities clearly at the domain level.Make assumptions explicit and document boundaries.Favor simplicity and evolvable structures.
Discovery
Enterprise, Domain, Team

Use cases & scenarios

Compromises

  • Wrong or untested assumptions lead to misinvestment.
  • Excessive simplification obscures technical complexity.
  • Lack of stakeholder involvement prevents acceptance.
  • Explicit documentation of assumptions and boundaries.
  • Iterative validation with prototypes or test scenarios.
  • Early and regular involvement of relevant stakeholders.

I/O & resources

  • Business goals and user needs
  • Technical constraints and boundaries
  • Existing architecture and domain knowledge
  • Abstract architecture model
  • Decision documents with assumptions and trade-offs
  • Validation plan for assumptions

Description

Conceptual design describes the systematic creation of abstract models and core decisions that guide subsequent architecture and solution design. It defines major components, interfaces, responsibilities, and quality goals to ensure alignment among stakeholders. Conceptual design is technology-agnostic and focuses on purpose, scope, and key assumptions.

✔

  • Increased stakeholder alignment through a shared model.
  • Early identification of risks and interfaces.
  • Reduced misdevelopment in later phases.

✖

  • No ready implementation details or code.
  • May miss practical guidance if overly abstract.
  • Requires regular validation against real assumptions.

  • Number of open assumptions

    Counts unvalidated assumptions in the conceptual model.

  • Stakeholder alignment level

    Measure of relevant stakeholders' agreement with the model.

  • Time to operationalization

    Time from concept completion to concrete implementation planning.

E-commerce platform: domain partitioning

Conceptual model separated catalog, orders and payments to enable autonomous teams.

IoT system: edge vs cloud responsibilities

Conceptual design specified which logic stays on the edge and which is processed in the cloud backend.

FinTech: security and compliance boundaries

Model defined clear zones for sensitive data and compliance-relevant processes.

1

Conduct stakeholder workshop to clarify goals and assumptions.

2

Identify and sketch core components and interfaces abstractly.

3

Prioritize quality goals and document necessary trade-offs.

4

Create validation plan and test hypotheses.

⚠️ Technical debt & bottlenecks

  • Unchecked assumptions cause later architectural rework.
  • Missing interface agreements increase integration effort.
  • Undocumented compromises hinder maintenance.
Cross-domain communicationUnclear responsibilitiesTechnological dependencies
  • Concept mistaken for implementation instructions.
  • Abstract model never verified against real data.
  • Concept rigidly adopted without adapting to context.
  • Loss of practical relevance through excessive abstraction.
  • Unclear boundaries lead to diffusion of responsibility.
  • Ignoring non-functional requirements in early phases.
Domain modeling and architectural thinkingFacilitation and stakeholder managementExperience with quality requirements
Scalability of core componentsSecurity and compliance requirementsInteroperability with existing systems
  • • Budget and time limits
  • • Regulatory constraints
  • • Existing technical infrastructure