Katalog
concept#Architektur#Software Engineering#Produkt

Conceptual Design

Abstrakte Erarbeitung von Modellen und Kernentscheidungen, die Architektur- und Lösungsentwürfe leiten.

Conceptual Design beschreibt die systematische Erarbeitung abstrakter Modelle und Kernentscheidungen, die das spätere Architektur- und Lösungsdesign leiten.
Etabliert
Mittel

Klassifikation

  • Mittel
  • Technisch
  • Architektur
  • Fortgeschritten

Technischer Kontext

Architektur-Repository oder EntscheidungsdatenbankModellierungs- und Kollaborationstools (z. B. Structurizr)Anforderungsmanagement-Tools

Prinzipien & Ziele

Trenne Verantwortlichkeiten klar auf Domänenebene.Mach Annahmen explizit und dokumentiere Grenzen.Bevorzuge Einfachheit und evolvierbare Strukturen.
Erkundung
Unternehmen, Domäne, Team

Use Cases & Szenarien

Kompromisse

  • Falsche oder ungetestete Annahmen führen zu Fehlinvestitionen.
  • Übermäßige Vereinfachung verschleiert technische Komplexität.
  • Mangelnde Stakeholder-Einbindung verhindert Akzeptanz.
  • Explizite Dokumentation von Annahmen und Grenzen.
  • Iterative Validierung mit Prototypen oder Testszenarien.
  • Frühe und regelmäßige Einbindung relevanter Stakeholder.

I/O & Ressourcen

  • Geschäftsziele und Nutzerbedürfnisse
  • Technische Rahmenbedingungen und Restriktionen
  • Bestehende Architektur- und Domänenwissen
  • Abstraktes Architekturmodell
  • Entscheidungsdokumente mit Annahmen und Trade-offs
  • Validierungsplan für Annahmen

Beschreibung

Conceptual Design beschreibt die systematische Erarbeitung abstrakter Modelle und Kernentscheidungen, die das spätere Architektur- und Lösungsdesign leiten. Es definiert Hauptkomponenten, Schnittstellen, Verantwortlichkeiten und Qualitätsziele, um Konsistenz zwischen Stakeholdern zu gewährleisten. Conceptual Design ist technologie-agnostisch und fokussiert auf Zweck, Grenzen und zentrale Annahmen.

  • Erhöhte Stakeholder-Abstimmung durch ein gemeinsames Modell.
  • Frühe Identifikation von Risiken und Schnittstellen.
  • Reduzierte Fehlentwicklungen in späteren Phasen.

  • Keine fertigen Implementierungsdetails oder Code.
  • Kann bei zu hoher Abstraktion praktische Hinweise vermissen lassen.
  • Erfordert regelmäßige Validierung gegen reale Annahmen.

  • Anzahl der offenen Annahmen

    Zählt nicht validierte Annahmen im konzeptionellen Modell.

  • Stakeholder-Abstimmungsgrad

    Messung der Zustimmung relevanter Stakeholder zum Modell.

  • Zeit bis zur Operationalisierung

    Dauer von Konzeptabschluss bis zur konkreten Implementierungsplanung.

E-Commerce-Plattform: Domain-Partitionierung

Konzeptuelles Modell trennte Katalog, Bestellungen und Zahlungen, um autonome Teams zu ermöglichen.

IoT-System: Edge vs Cloud Verantwortung

Conceptual Design legte fest, welche Logik am Edge verbleibt und welche im Cloud-Backend verarbeitet wird.

FinTech: Sicherheits- und Compliance-Boundaries

Modell definierte klare Zonen für sensible Daten und Compliance-relevante Prozesse.

1

Stakeholder-Workshop zur Ziel- und Annahmenklärung durchführen.

2

Kernkomponenten und Schnittstellen abstrakt identifizieren und skizzieren.

3

Qualitätsziele priorisieren und notwendige Trade-offs dokumentieren.

4

Validierungsplan erstellen und Hypothesen testen.

⚠️ Technische Schulden & Engpässe

  • Ungeprüfte Annahmen erzeugen spätere Architekturkorrekturen.
  • Fehlende Schnittstellenvereinbarungen erhöhen Integrationsaufwand.
  • Nicht dokumentierte Kompromisse erschweren Wartung.
Kommunikation zwischen DomänenUnklare VerantwortlichkeitenTechnologische Abhängigkeiten
  • Konzept wird als Implementierungsanleitung missverstanden.
  • Abstraktes Modell wird nie gegen reale Daten verifiziert.
  • Konzept wird starr übernommen, ohne Anpassung an Kontext.
  • Verlust an Praxisrelevanz durch zu starke Abstraktion.
  • Unklare Grenzen führen zu Verantwortungsdiffusion.
  • Ignorieren nicht-funktionaler Anforderungen in frühen Phasen.
Domänenmodellierung und ArchitekturdenkenModeration und Stakeholder-ManagementErfahrung mit Qualitätsanforderungen
Skalierbarkeit der KernkomponentenSicherheits- und Compliance-AnforderungenInteroperabilität mit bestehenden Systemen
  • Budget- und Zeitlimits
  • Regulatorische Vorgaben
  • Vorhandene technische Infrastruktur