Design Document as a Service
In vielen Projekten steht die Technologie fest, bevor Anforderungen und Kosten bekannt sind. Wir drehen die Reihenfolge um: erst der Umsetzungsplan mit Architektur, Zeitplan und verbindlichem Preis, dann der Code.
Wer ein Haus baut, hat Vorstellungen, Wünsche und ein Budget. Was häufig fehlt, sind der Praxischeck und ein konkreter Plan, wie man bestmöglich zum Ziel kommt.
Denn nicht jede gute Idee lässt sich auch sinnvoll umsetzen. Manches ist technisch nicht machbar, manches unnötig teuer, und manches lässt sich auf einem anderen Weg deutlich besser lösen. Genau das leistet ein Architekturbüro. Es prüft die Ideen, wägt Varianten ab und macht daraus einen belastbaren Plan.
Fragen tauchen dann erst spät auf, oft zu spät:
- Betriebsumgebung, Releasezyklus und SLAs
- Kritische User Journeys und erwartete Latenzen
- Integration in Bestandssysteme
Und das sind nur einige Beispiele.
In komplexen Softwareprojekten fehlt genau dieser Schritt erstaunlich oft. Die Technologieentscheidung steht schon fest, bevor Anforderungen, Abhängigkeiten und Kosten überhaupt bekannt sind. Gebaut wird sofort, geplant wird agil nebenbei.
Das Architekturbüro für Ihr Softwareprojekt
Posedio übernimmt genau diese Rolle. Wir bringen unsere Erfahrung aus vielen komplexen Softwareprojekten ein und suchen anbieterneutral die beste und effizienteste Lösung für genau Ihre Anforderungen.
Dazu setzt sich unser Architekturteam mit Ihnen zusammen, versteht Ihre Anforderungen und entwirft daraus einen konkreten Umsetzungsplan. Bei uns heißt dieser Plan Design Document. Er bildet die Grundlage für alles, was danach entwickelt wird. Er beschreibt den goldenen Pfad durch Ihr Softwareprojekt, die eingesetzten Technologien, die Architekturentscheidungen sowie einen transparenten Rahmen für Kosten, Ressourcen und Zeitplan.
Er ist kein statisches Pflichtenheft, das für die gesamte Projektlaufzeit festgeschrieben wird. Anforderungen verändern sich, Annahmen erweisen sich als falsch, und aus der Umsetzung kommen neue Erkenntnisse zurück. Daher wächst das Dokument mit dem Projekt.
Änderungen sind günstiger, weil die Architektur sie von Anfang an vorsieht. Das Zielbild steht, die Abhängigkeiten sind bekannt, und die getroffenen Kompromisse sind bewusst gewählt und nachvollziehbar dokumentiert. Damit sinkt das Risiko fundamentaler Kurskorrekturen, die eine Neuentwicklung ganzer Komponenten nach sich ziehen oder aufwendige Umwege um einmal getroffene Fehlentscheidungen erzwingen.
Sie bekommen einen vollständigen Umsetzungsplan für Ihr Softwareprojekt, mit transparenten Kosten und Ressourcen auf Basis Ihrer verbindlichen Anforderungen.
So entsteht Ihr Design Document
Fünf Schritte, von der ersten gemeinsamen Sitzung bis zur freigegebenen Fassung.
- 01
Workshop
Gemeinsam mit Ihnen erheben wir die Anforderungen und erarbeiten erste Lösungsansätze.
- 02
Stop or Go
Ein kurzer Entscheidungspunkt. Beide Seiten prüfen, ob eine Zusammenarbeit sinnvoll ist. Sie oder wir können das Vorhaben hier beenden.
- 03
Erste Fassung
Wir bringen die Erkenntnisse aus dem Workshop in eine erste Version des Design Documents.
- 04
Abstimmung
In einem gemeinsamen Termin gehen wir das Dokument durch und nehmen Ihr Feedback auf.
- 05
Freigabe
Die überarbeitete Fassung wird von Ihnen und von uns freigegeben.
Was ein Design Document kostet
| Leistung | Preis |
|---|---|
| Erstellung des Design Documents | 3.000 Euro netto |
| Workshop, Ausarbeitung, Abstimmungstermin und finale Fassung | enthalten |
| Bei Beauftragung der Umsetzung durch Posedio | kostenfrei |
| Was Sie sich an Fehlentscheidungen und Umbauten ersparen | unbezahlbar |
Entscheiden Sie sich für die Umsetzung mit uns, entfallen die Kosten für das Design Document vollständig.
Das Design Document gehört Ihnen
Sie können es mit uns umsetzen, mit Ihrem bestehenden Dienstleister oder mit Ihrem eigenen Team. Es ist ausdrücklich keine Vorentscheidung für Posedio, und umgekehrt übernehmen wir auch nicht automatisch jedes Projekt. Genau das macht unsere Einschätzung unabhängig.
Häufige Fragen
Was kostet ein Design Document?
3.000 Euro netto. Entscheiden Sie sich für die Umsetzung mit Posedio, entfallen die Kosten vollständig.
Was ist im Preis enthalten?
Workshop, Ausarbeitung, Abstimmungstermin und die finale Fassung. Für Abstimmungsrunden entstehen keine Zusatzkosten.
Muss ich die Umsetzung bei Posedio beauftragen?
Nein. Sie können das Design Document mit uns, mit Ihrem bestehenden Dienstleister oder mit Ihrem eigenen Team umsetzen. Es ist ausdrücklich keine Vorentscheidung für Posedio.
Was enthält ein Design Document?
Ein vollwertiges Umsetzungskonzept mit Architektur und Tech-Stack, einen Zeitplan mit Phasen, einen verbindlichen Preis sowie benannte und bewertete Risiken.
Wie läuft die Erstellung ab?
Wir verstehen zuerst Ihre Problemstellung, in einem Erstgespräch oder Workshop. Passt die Aufgabenstellung zu unserer Kompetenz, arbeiten wir aus dem gesamten Lösungsraum die für Sie passende Lösung heraus und halten verworfene Alternativen samt Begründung fest. Den Entwurf verfeinern wir gemeinsam, bis das Gesamtkonzept schlüssig ist und von Ihnen freigegeben wird.
Wie lange dauert die Erstellung?
Die reine Bearbeitungszeit liegt üblicherweise bei ein bis zwei Arbeitswochen, vorausgesetzt wir bekommen zeitnah Zugang zu Ihren fachlichen Ansprechpartnern und Rückmeldung zu unseren Entwürfen. Bei komplexeren Vorhaben oder vielen beteiligten Stakeholdern kann es länger dauern. Nach dem Erstgespräch können wir Ihnen die Dauer verlässlich zusagen.
Was passiert, wenn wir nach dem Workshop nicht zusammenpassen?
Nach dem Workshop gibt es einen Entscheidungspunkt. Beide Seiten prüfen, ob die Zusammenarbeit sinnvoll ist — Sie oder wir können das Vorhaben dort beenden.
Ist ein Design Document dasselbe wie ein Pflichtenheft?
Nein. Unser Design Document beantwortet nicht nur, was wir bauen, sondern warum. Es erörtert den Kontext, macht Alternativen und deren Konsequenzen sichtbar und dient Ihnen damit als Entscheidungsgrundlage. Die wesentlichen Rahmenbedingungen, also Architektur, Technologiestack, Meilensteine, Risiken und Kosten, legen wir verbindlich fest. Neue Erkenntnisse arbeiten wir über ein nachvollziehbares Change Management ein. Die Abnahmekriterien werden separat im Vertrag geregelt.
Ihr Design Document beginnt mit einem Gespräch
Wir besprechen Ihr Vorhaben und klären gemeinsam, ob ein Design Document der richtige nächste Schritt ist.
Design Document anfragenSo sieht ein Design Document aus
- Kunde
- Muster Handel GmbH
- Verfasst von
- Posedio
- Version
- 1.0
- Status
- FREIGEGEBEN
- Umfang
- ~15 Wochen
- Vertraulichkeit
- Vertraulich
Überblick
Muster Handel betreibt ihre Auftragsabwicklung auf einem zwölf Jahre alten, lizenzpflichtigen On-Premise-System. Ziel des Projekts ist die Ablösung durch eine cloud-native, offene Plattform, die zu Saisonspitzen elastisch skaliert, hochverfügbar ist und keine Lizenzkosten mehr verursacht.
Stakeholder: E-Commerce-Leitung (Sponsor), IT-Betrieb, Kundenservice und Logistik. Nutzen: wegfallende Lizenzkosten, höhere Verfügbarkeit an Aktionstagen und deutlich kürzere Änderungszyklen.
Grobe Timeline: rund 15 Wochen bis Go-Live, anschließend Übergabe an das interne Team.
Die Anforderungen
2.1 Geschäftsanforderungen
Ziel — Was wollen wir erreichen? Eine zentrale Plattform, die Aufträge annimmt, den Lagerbestand abgleicht, den Versand steuert und Kunden über den Status informiert. Self-Service-Dashboards für den Kundenservice inklusive.
Hintergrund — Warum wird das gebraucht? Das Altsystem verursacht rund 120.000 € Lizenzkosten pro Jahr, fällt an Aktionstagen unter Last aus und lässt Änderungen nur über wochenlange Herstellerzyklen zu.
Kontext — Wer nutzt es und wie? Etwa 150 interne Nutzer aus Kundenservice und Logistik, rund 50.000 Bestellungen pro Tag mit bis zu fünffachen Spitzen an Aktionstagen.
2.2 Erforderlicher Reifegrad
Der Reifegrad legt zwei Dinge vorab fest: für welchen Nutzerkreis die Lösung gebaut wird und welchen Qualitätsanspruch der Code erfüllen muss.
Funktional
Aufsteigend nach Anspruch, festgelegt wird eine Stufe.
Begründung: Der Kundenservice arbeitet täglich damit und Endkunden sehen ihren Bestellstatus nach dem Login. Die Lösung muss produktreif sein, aber nicht für anonyme Zugriffe aus dem offenen Netz ausgelegt.
Code Maturity
| Lösung | Angestrebte Qualität |
|---|---|
| Muss einfach funktionieren | Quick wins ohne Rücksicht |
| Schnelle erste Version, später erweiterbar | Quick wins mit etwas Weitblick |
| Produkt mit langer Lebensdauer | Erweiterbar und wartbar durch uns |
| Code wird an den Kunden übergeben ✓ | 100 % wart- und erweiterbar |
2.3 Nichtfunktionale Anforderungen
Was ein System leisten soll, ist nur die halbe Anforderung. Wie gut es das leisten soll, prägt die Architektur mindestens genauso stark. Wir erfassen und priorisieren daher die wesentlichen Qualitätsziele und nutzen ISO/IEC 25010:2023 als Checkliste und Referenz. So vermeiden wir teure Fehlentscheidungen und dimensionieren das System genau richtig: weder overengineered noch unterdimensioniert.
Sie entscheiden, worauf es ankommt. Qualitätsanforderungen stehen häufig im Konflikt zueinander: mehr Sicherheit kostet Geschwindigkeit, mehr Flexibilität kostet Wartbarkeit. Die Priorisierung legt vorab fest, welche Seite im Zweifelsfall gewinnt.
2.4 Risikobewertung
| Risiko | Auswirkung | Wahrscheinlichkeit | Mitigation | Verantwortlich |
|---|---|---|---|---|
| Datenmigration aus Altsystem unvollständig dokumentiert | HOCH | NORMAL | Migrations-PoC & Datenaudit bereits in Phase 0 | Posedio |
| Fachbereich für Anforderungsklärung schwer verfügbar | NORMAL | WAHRSCHEINLICH | Feste Workshop-Slots, benannter Product Owner | Muster Handel |
| Cutover fällt in einen Aktionstag | HOCH | UNWAHRSCHEINLICH | Cutover außerhalb Peak, getesteter Rollback-Plan | gemeinsam |
| Ressourcenengpass auf Kundenseite, insbesondere Fachpersonal im Netzwerkteam | HOCH | WAHRSCHEINLICH | Bedarf früh und mit konkretem Zeitfenster anfragen, Priorisierung durch die Geschäftsführung einräumen lassen, Sichtbarkeit im Projekt herstellen und den persönlichen Kontakt zum Team halten | Muster Handel und Posedio |
| Abteilungen, die durch die Lösung Aufgaben oder Zuständigkeiten abgeben, tragen die Umsetzung nicht mit | NORMAL | NORMAL | Betroffene früh in Workshops einbinden, Nutzen je Stakeholder explizit adressieren, Sponsor aktiv einsetzen | Sponsor Muster Handel |
| Denial-of-Service-Angriffe auf öffentlich erreichbare Endpunkte führen zum Ausfall der Anwendung | HOCH | WAHRSCHEINLICH | Rate Limiting und WAF am Gateway, Autoscaling und Lastgrenzen definieren, Lasttests gegen die vereinbarten Kapazitätsziele, Notfallprozess für den Angriffsfall | Architektur Posedio |
| Kompromittierte Zugangsdaten oder zu weit gefasste Berechtigungen ermöglichen unbefugten Zugriff auf Daten | HOCH | NORMAL | Zentrale Identitätsverwaltung mit MFA, Least Privilege und regelmäßige Rezertifizierung, Secrets ausschließlich im Secret Store, Zugriffe protokollieren und auswerten | Security Officer Muster Handel |
| Verwundbare Abhängigkeiten in Bibliotheken oder Containerimages gelangen unbemerkt in Produktion | HOCH | WAHRSCHEINLICH | Automatisiertes Dependency- und Image-Scanning in der Pipeline, Build bricht ab definierter Schwere ab, Softwareinventar pflegen, definierter Patchprozess mit Reaktionszeiten | Betrieb und SRE Posedio |
Geplanter Zeitplan
Arbeitspakete, gebündelt in fünf Phasen über 15 Wochen. Der Go-Live ist eine harte Deadline.
| Phase | Arbeitspaket | Intervall |
|---|---|---|
| P1 Design & Setup | Design Doc, Umgebungen, IaC-Grundgerüst | W1–2 |
| P2 Plattform-Fundament | CI/CD, Cluster, Observability-Stack | W3–5 |
| P3 Kernservices | Orders, Inventory, Shipping | W6–10 |
| P4 Migration & Cutover | Datenmigration, Go-Live (harte Deadline) | W11–13 |
| P5 Hypercare & Übergabe | Stabilisierung, SRE-Handover, Wissenstransfer | W14–15 |
Die Lösung
4.1 Umsetzung
Event-getriebene Services für Orders, Inventory und Shipping hinter einem zentralen API-Gateway. Der Kundenservice erhält Self-Service-Dashboards, Endkunden automatische Statusbenachrichtigungen. Der produktreife Kern entsteht bis P3, weitere Funktionen folgen iterativ.
4.2 Architektur
Cloud-native auf Kubernetes, vollständig als Infrastructure as Code. Lose gekoppelte Services über einen Event-Bus, managed PostgreSQL als Datenbank, Observability quer über alles.
Den Kern des Plans bilden die Architektur- und Ablaufdiagramme. Sie zeigen, welche Komponenten neu entstehen und welche zugekauft oder aus dem Open Source Umfeld übernommen werden, wie sich die Lösung in die Bestandssysteme einfügt, über welche Schnittstellen sie angebunden wird und was an Vorkehrungen nötig ist, etwa für Business Continuity oder rechtliche Anforderungen. Ziel ist ein System, das alle Anforderungen erfüllt und dabei so einfach wie möglich zu entwickeln und zu betreiben ist.
4.3 Tech-Stack
| Technologie | Wofür | Warum diese Wahl |
|---|---|---|
| Kubernetes | Orchestrierung | Offen und portabel statt proprietärer PaaS-Bindung |
| Terraform | Infrastructure as Code | Reproduzierbar, versioniert, überprüfbar |
| PostgreSQL | Datenbank | Bewährt und lizenzfrei — ersetzt teure DB-Lizenzen |
| Kafka / NATS | Event-Backbone | Entkoppelte, skalierbare Services |
| OpenTelemetry · Prometheus · Grafana | Observability | Offener Standard statt teurem APM-Lizenzmodell |
| Keycloak | IAM / Login | Open-Source-Identitätsmanagement, kein Vendor-Lock-in |
4.4 Kostenbetrachtung
Alternative (Lift-and-Shift des Lizenzprodukts in die Cloud) wäre in der Umsetzung günstiger, hält aber die Lizenzkosten und die Herstellerabhängigkeit dauerhaft. Empfehlung: der offene Neubau — höhere Einmalinvestition, klar niedrigere laufende Kosten.
Glossar
| Abkürzung | Beschreibung |
|---|---|
| NFR | Nonfunctional Requirement — Qualitätsanforderung wie Verfügbarkeit oder Sicherheit |
| IaC | Infrastructure as Code — Infrastruktur deklarativ und versioniert beschrieben |
| SLO | Service Level Objective — messbares Ziel für Verfügbarkeit oder Latenz |
| Cutover | Umschaltung vom Alt- auf das neue System |
| Hypercare | Intensiv begleitete Stabilisierungsphase direkt nach Go-Live |
Änderungshistorie
| Datum | Geändert von | Kommentar |
|---|---|---|
| 2026-02-10 | Posedio | Erstentwurf nach Workshop |
| 2026-02-24 | Posedio | NFR-Priorisierung & Risiken mit Fachbereich abgestimmt |
| 2026-03-03 | Muster Handel | Freigabe v1.0 |
Sprechen wir über Ihr Vorhaben
Vermeiden Sie teure Fehlentscheidungen und schwierige Kompromisse und finden Sie eine zukunftssichere Lösung für Ihr IT-Vorhaben. Fragen Sie noch heute Ihr Design Document an.
Design Document anfragen