Unsere Architekturprinzipien

Wir stellen die richtigen Fragen, bevor die falschen Antworten gebaut werden

Architektur beginnt mit der richtigen Frage, nicht mit der nächsten Technologie. Ausgangspunkt ist häufig eine Digitalstrategie, aber ohne eine daraus abgeleitete Zielarchitektur entsteht keine vernetzte IT-Landschaft. Die Folge: Mehrere Projekte haben, jedes für sich genommen, vernünftige Architekturentscheidungen getroffen, die sich jetzt nicht mehr zusammenführen lassen.

Das Muster dahinter ist fast immer dasselbe: Fachliche, technische, organisatorische und betriebliche Entscheidungen wurden getrennt getroffen, statt gemeinsam gedacht zu werden. Was daraus entsteht, kennt jede Behörde: widersprüchliche Anforderungen, schwer integrierbare Lösungen, steigende Betriebs- und Lizenzkosten.

Deshalb verstehen wir uns als der ruhige Kopf im Raum, der vorher die richtigen Fragen stellt. Wie bei einem Gebäude gilt: Ein Haus beginnt mit der Planung des Grundrisses, nicht mit der Auswahl der Farbe der Fassade. Genau deshalb prüfen wir auch bei einer Ausschreibung zuerst, ob die technischen Leitplanken definiert sind. Bei laufenden Projekten mit Integrationsproblemen schauen wir zuerst auf die Tragfähigkeit der getroffenen Entscheidungen, bevor wir die Fassade verbessern.

Architekturberatung ibetrachten wir deshalb nie isoliert. Wir verbinden sie mit Softwareentwicklung, Fachlichkeit, Integration, DevOps, Qualitätssicherung und Support, damit Entscheidungen nicht auf dem Papier stehen bleiben, sondern bis in Umsetzung und Betrieb tatsächlich getragen werden. Dabei beraten wir unabhängig und kompetent und bekennen uns klar zu offenen Standards und zum Deutschland-Stack.

Fünf Prinzipien für tragfähige Lösungen

Egal ob Registeranbindung, Fachverfahren oder Prozessautomatisierung: Jede Lösung, die publicplan entwickelt oder begleitet, folgt denselben fünf Grundsätzen. Sie sind fest in unsere Methoden und Arbeitsweisen integriert. An ihnen messen wir die Wirksamkeit unserer Architekturentscheidungen, auch wenn das im Einzelfall bedeutet, eine bequemere, aber weniger tragfähige Lösung abzulehnen.

1. API-First

Schnittstellen werden vor der Implementierung fachlich und technisch entworfen und als eigenständige Bestandteile der Lösung behandelt. Das heißt wir schauen zuerst mit dem Fachbereich und der IT-Abteilung auf die Prozesse und die vorhandene IT-Landschaft, um alle notwendigen Schnittstellen zu identifizieren. Dafür erhalten alle relevanten Komponenten offene, dokumentierte Schnittstellen, über die sich Systeme anderer Behörden oder Dienstleister anbinden lassen, ohne dass dafür Kenntnisse des Quellcodes erforderlich sind. Das ist die Grundlage dafür, dass Lösungen später nachnutzbar sind und keine isolierten Inseln bilden.

1. API-First

Schnittstellen werden von Anfang an mitgedacht. Das heißt wir schauen zuerst mit dem Fachbereich und der IT-Abteilung auf die Prozesse und die vorhandene IT-Landschaft, um alle notwendigen Schnittstellen zu identifizieren. Dazu erhält jede Komponente offene, dokumentierte Schnittstellen, über die andere Systeme, Behörden oder Dienstleister angebunden werden können, ohne den Quellcode zu kennen. Das ist die Grundlage dafür, dass Lösungen später nachnutzbar sind und keine isolierten Inseln bilden.

3. Wiederverwendbarkeit

Wir entwickeln Lösungen so, dass Komponenten, Konzepte und Schnittstellen möglichst wiederverwendet und auch von anderen Dienstleistern weitergeführt werden können. Dafür setzen wir auf offene Standards und nachvollziehbare Dokumentation. Open-Source-Technologien beziehen wir ein, wenn ihr Einsatz fachlich, rechtlich und wirtschaftlich sinnvoll ist. So schaffen wir die technische Grundlage für das, was wir an anderer Stelle „Open Exit“ nennen: Ihre Verwaltung bleibt handlungsfähig und vermeidet unnötige Abhängigkeiten von einzelnen Anbietern.

4. DevSecOps

Sicherheit ist über den gesamten Lebenszyklus in Prozesse, Werkzeuge und Verantwortlichkeiten integriert – von der Konzeption über die Entwicklung bis zum Betrieb. Sie ist kein einmaliger Prüfschritt kurz vor dem Go-live. Das verbessert die Sicherheit der Lösung durchgängig, weil Schwachstellen früh auffallen, wenn sie noch mit vertretbarem Aufwand behoben werden können.

5. Zero-Trust

Kein Zugriff gilt allein aufgrund seiner Herkunft oder seiner Position im Netzwerk als vertrauenswürdig. Jede Komponente authentifiziert und autorisiert Zugriffe nach dem Prinzip der geringsten Rechte – auch innerhalb der eigenen Systemlandschaft. Das ist besonders bei föderal verteilten Systemen mit vielen Beteiligten relevant, bei denen die Netzwerkposition allein kein Vertrauenskriterium sein darf.

Wo diese Prinzipien konkret wirken

Diese fünf Prinzipien sind kein separates Leistungsangebot. Sie prägen alle Lösungen, die wir entwickeln oder begleiten. Besonders sichtbar werden sie in diesen Bereichen unseres Portfolios:

Häufig gestellte Fragen

Sprechen wir über Ihr Vorhaben

30 Minuten, unverbindlich

Erstgespräch vereinbaren

Zum Kalender

Nachricht schreiben