Architekturleitlinien, die Entscheidungen tragen
Architekturleitlinien sind nur so gut wie die Entscheidungen, die man mit ihnen begründen kann. Wir formulieren sie so, dass sie bei der nächsten Beschaffung oder Eigenentwicklung eine klare Antwort geben:
| Leitlinie | Im Alltag heißt das |
|---|---|
| Daten vor Anwendungen | Jede neue Lösung legt offen, welche Daten sie erzeugt und nutzt, und liefert sie über eine dokumentierte Schnittstelle aus – nicht nur als Export. |
| Services und Workflows statt Insellösungen | Bevor etwas Neues entsteht, wird geprüft, ob ein vorhandener Dienst erweitert werden kann. Doppelte Stammdaten sind ein Warnsignal. |
| Standardisierte Schnittstellen | REST mit OpenAPI-Beschreibung, Ereignisse statt nächtlicher Dateiabgleiche, Fachstandards wo vorhanden: OParl, XÖV, FIT-Connect, OGC SensorThings, DCAT-AP.de. |
| Cloud first, nicht Cloud only | Je Anwendung wird entschieden, wo sie läuft – nach Datenkategorie, Kosten, Abhängigkeit und Ausstiegsmöglichkeit. Eine Exit-Strategie gehört zu jedem Vertrag. |
| Identität einmal | Mitarbeitende melden sich überall mit demselben Konto an (Single Sign-on), Bürger*innen über die BundID bzw. das Nutzerkonto des Landes. |
| Barrierefreiheit und Datenschutz im Entwurf | Beides wird in der Architektur entschieden, nicht in der Abnahme. Datenflüsse sind dokumentiert, bevor personenbezogene Daten fließen. |
Datenverantwortung klären
Die häufigste Ursache für Insellösungen ist nicht Technik, sondern ungeklärte Zuständigkeit: Wem gehören die Straßendaten, die Gremiendaten, die Daten des Bürgerservice? Wir helfen, für die wichtigsten Datenbestände Verantwortliche festzulegen und ein schlankes Datenverzeichnis anzulegen.
- Datenverantwortliche je Bestand (fachlich) und Datenpflege (technisch)
- Datenkatalog mit Beschreibung, Aktualität, Lizenz und Schutzbedarf – maschinenlesbar nach DCAT-AP.de
- Klassifizierung: offen, intern, vertraulich, personenbezogen
- Regeln, welche Daten als Open Data veröffentlicht werden – und welche bewusst nicht
Schnittstellen statt Exportdateien
Wo Fachverfahren keine brauchbare Schnittstelle haben, muss man sie nicht sofort ersetzen. Oft reicht ein Adapter, der vorhandene Daten in einen offenen Standard übersetzt – der eigentliche Wechsel kann dann zu einem Zeitpunkt kommen, an dem der Vertrag ohnehin endet.
So sieht das bei uns aus
Unsere RIS-Brücke (öffnet in neuem Fenster) liest Sitzungen und Dokumente aus Ratsinformationssystemen über OParl. Wo die OParl-Schnittstelle nicht zur Verfügung steht, übernimmt ein Adapter für die öffentliche HTML-Ansicht. Für die Anwendung dahinter macht das keinen Unterschied.
Die Ratssitzungs-Seite führt auf dieselbe Weise Termin, Tagesordnung, Vorlagen und Beschlüsse aus zwei Quellen zusammen – ohne dass jemand etwas abtippt.
Urbane Datenplattform: klein anfangen
Eine urbane Datenplattform muss nicht mit einer Großbeschaffung beginnen. Für den Anfang genügen ein Datenkatalog, ein API-Gateway mit einheitlicher Anmeldung und eine Handvoll gut beschriebener Datensätze, die tatsächlich genutzt werden. Die Referenzarchitektur der DIN SPEC 91357 hilft, die Bausteine sauber zu schneiden, damit später erweitert werden kann, ohne neu anzufangen.
Was Sie am Ende in der Hand haben
- Zielarchitektur auf einer Seite – für Leitung und Gremien verständlich
- Architekturleitlinien mit Begründung und Beispielen
- Schnittstellenstandards und eine Vorlage für Ausschreibungen („Muss-Kriterien Schnittstelle“)
- Erste Fassung des Datenkatalogs mit Verantwortlichen
- Liste der größten Abhängigkeiten mit Vertragslaufzeiten und Ausstiegsoptionen