Strategie
Geschäftsziele und ein Transformationsfahrplan — die Richtung, in die sich die Organisation bewegen muss, und warum.
Strategie & Architektur · Schritt 02 · Wie wir arbeiten
Vom validierten Problem zur technischen Ausrichtung.
Strategie und Architektur beginnen nicht als Ansammlung bevorzugter Technologien. Sie entstehen aus einem begründbaren Verständnis dessen, was das System leisten muss, unter welchen Randbedingungen, für welche Stakeholder und anhand welcher messbaren Ergebnisse.
In dieser Phase werden die Ergebnisse von Research & Discovery in eine technisch ausgearbeitete Systemrichtung überführt — Anforderungen, Einschränkungen und Erfolgskriterien werden zu Architekturentscheidungen, nicht umgekehrt.
Strategie · Architektur · Datenentwurf · Sicherheit durch Design · Technologieauswahl
Warum Architektur auf Discovery folgt
Hier beginnt nichts bei Null.
Jeder Input für diese Phase wurde während Research & Discovery erzeugt — nicht angenommen und nicht erfunden, um eine bevorzugte Technologie zu rechtfertigen.
Anforderungen
Funktionale, technische, operative und Governance-Anforderungen, die während der Discovery identifiziert wurden.
Einschränkungen & Risiken
Technische, budgetäre, regulatorische und organisatorische Einschränkungen sowie bekannte Risiken und Annahmen.
Erfolgskriterien
Ausgangswerte, Ziele und messbare Nachweise, die eine Verbesserung belegen würden.
Architekturentscheidungen lassen sich auf eine validierte Problemdefinition zurückführen — nicht auf die Präferenz für einen bestimmten Anbieter oder ein Framework.
Strategie vor Architektur
Zwei verschiedene Fragen, in der richtigen Reihenfolge beantwortet.
Strategie und Architektur werden oft synonym verwendet, beantworten jedoch unterschiedliche Fragen. Die Strategie fragt, in welche Richtung sich das Unternehmen bewegen sollte. Die Architektur fragt, wie diese Richtung umgesetzt wird.
Architektur
Intelligent, skalierbar, sicher und zukunftsfähig — die technische Struktur, die diese Richtung in ein tatsächlich realisierbares und betreibbares System verwandelt.
Architekturprinzipien
Die Prinzipien, die jede Entscheidung leiten.
Jede Architekturentscheidung bei OpenQCore wird anhand desselben Prinzipsatzes bewertet, unabhängig von Branche oder Projekt.
Skalierbarkeit
Das System sollte mit der Nachfrage wachsen, ohne bei jeder Wachstumsstufe neu gestaltet werden zu müssen.
Sicherheit durch Design
Sicherheitskontrollen sind von Anfang an in die Architektur integriert, nicht nachträglich aufgesetzt.
Modularität
Komponenten können unabhängig voneinander ersetzt, aktualisiert oder erweitert werden.
Interoperabilität
Die Architektur verbindet sich nahtlos mit bestehenden und zukünftigen externen Systemen.
Beobachtbarkeit
Das Verhalten, die Leistung und Fehler des Systems sind im Betrieb sichtbar und verständlich.
Kosteneffizienz
Architekturentscheidungen berücksichtigen die gesamten Betriebskosten, nicht nur die anfänglichen Baukosten.
Zukunftsfähigkeit
Die Architektur kann sich ändernde Anforderungen aufnehmen, ohne einen vollständigen Neuaufbau zu erfordern.
Von Anforderungen zur Referenzarchitektur
Ergebnisse der Discovery werden zu Eingaben für die Architektur.
Anforderungen, Einschränkungen und Risiken sowie Erfolgskriterien aus der Discovery-Phase laufen in konkrete Architekturentscheidungen zusammen — die sich dann zu einer Referenzarchitektur für das Projekt zusammensetzen.
Referenzarchitektur
Eine in Schichten aufgebaute Struktur, keine auf Annahmen beruhende.
Die Referenzarchitektur von OpenQCore trennt Verantwortlichkeiten in verschiedene Ebenen — Schnittstellen, die Intelligenz- und Anwendungsschicht, die Datenschicht und die zugrunde liegende Infrastruktur — wobei Sicherheit, Governance, Beobachtbarkeit und Skalierbarkeit als bereichsübergreifende Anliegen behandelt werden, nicht als nachträgliche Gedanken.
Datenstrategie & Governance-by-Design
Governance gehört in den Entwurf.
Datenstrategie, Sicherheits- und Compliance-Anforderungen werden von Anfang an in die Architektur eingebaut — nicht nachträglich hinzugefügt, wenn das System bereits aufgebaut ist.
Ein System, dem Governance später hinzugefügt werden muss, wurde beim ersten Mal nicht richtig entworfen.
Rahmenwerk für die Technologieauswahl
Technologie folgt den Anforderungen, nicht umgekehrt.
OpenQCore bewertet potenzielle Technologien anhand expliziter Kriterien, anstatt sich auf das zu verlassen, was populär oder vertraut ist.
Zweckmäßigkeit
Löst die Technologie tatsächlich das in der Discovery-Phase definierte Problem?
Gesamtkosten (Total Cost of Ownership)
Was kostet es, die Technologie über die Zeit zu betreiben, zu warten und zu skalieren — nicht nur sie zu übernehmen?
Risiko der Anbieterbindung
Wie schwierig wäre es später, von dieser Technologie weg zu migrieren?
Fähigkeiten des Teams
Kann die Technologie von den Teams betrieben und gewartet werden, die dafür verantwortlich sein werden?
Langfristige Wartbarkeit
Wird die Technologie über die erwartete Lebensdauer des Systems hinweg weiterhin unterstützbar und aktualisierbar bleiben?
Wie in der Discovery-Phase ist die Antwort nicht automatisch vorbestimmt — Belege und Anforderungen entscheiden, welche Technologie, falls überhaupt, geeignet ist.
Risikobewusste Architekturentscheidungen
Jede Entscheidung wird dokumentiert, nicht angenommen.
Architekturentscheidungen beinhalten Abwägungen. OpenQCore dokumentiert die Begründungen für wesentliche Entscheidungen als Architecture Decision Records (ADRs), sodass die Gründe lange nach der Entscheidung sichtbar bleiben.
Eine dokumentierte Abwägung kann erneut betrachtet werden, wenn sich die Bedingungen ändern. Eine undokumentierte wird einfach vergessen.
Was diese Phase hervorbringt
Entscheidungen, die den Aufbau leiten.
Referenzarchitektur-Dokument
Die Schichtenarchitektur, ihre Komponenten und wie sie miteinander verbunden sind.
Entscheidung zum Technologie-Stack
Die ausgewählten Technologien und die Bewertung, die jeder Auswahl zugrunde liegt.
Datenarchitektur-Blueprint
Wie Daten strukturiert, gespeichert, gesichert und im gesamten System zugänglich gemacht werden.
Sicherheits- und Compliance-Modell
Die in die Architektur eingebauten Sicherheitskontrollen und das Compliance-Niveau.
Plan für Skalierbarkeit und Kapazität
Wie das System voraussichtlich wachsen wird und welche Anforderungen dieses Wachstum stellt.
Aufzeichnungen zu Architekturentscheidungen
Die dokumentierte Begründung, die Abwägungen und die Folgen hinter wichtigen Entscheidungen.
Von Architektur zum Lösungsdesign
Eine Richtung, noch kein fertiges Produkt.
Strategie & Architektur legt fest, wie das System strukturiert sein soll. Die nächste Phase verwandelt diese Struktur in ein konkretes Lösungsdesign — die spezifischen Systeme, Workflows und Schnittstellen, die gebaut werden sollen.
Schritt 03
Lösungsdesign
Eine entwickelte Richtung in eine konkrete, umsetzbare Lösung verwandeln.