Gespräch vereinbaren

Für Softwareanbieter

Ihre Fachanwendung, in jedem Dorf

Vicus ist die App, in der Bürgerinnen und Bürger ihren Ort erledigen. Wer dahinter die Fachlichkeit liefert, entscheidet die Gemeinde — Fachbereich für Fachbereich. Binden Sie Ihre Software an, und Sie sind einer der Anbieter, unter denen sie wählt.

Das Angebot: Sie bauen nur Ihre Fachlichkeit

Vicus ist keine Konkurrenz zu Ihrer Fachsoftware — Vicus ist ihr Weg zu den Menschen. Die Plattform bringt die gesamte bürgerseitige Hälfte mit, an der Fachanwendungen sonst jahrelang bauen. Sie bringen das mit, was Sie ohnehin am besten können.

  • Zugang zu Gemeinden und Vereinen. Ihre Anwendung wird als wählbarer Anbieter eines Fachbereichs geführt. Eine Gemeinde, die Vicus einführt, entscheidet für jeden Bereich, wessen Software dahintersteht — und findet dort Ihren Namen.
  • Eine fertige Bürgeroberfläche. App und Web sind gebaut, gestaltet und barrierearm. Sie liefern strukturierte Fachdaten und zulässige Aktionen, Vicus zeichnet daraus die Oberfläche. Kein zweites Frontend, kein eigenes Designsystem, keine Store-Pflege.
  • Identität und Rechte. Wer ist das, wohnt die Person hier, ist sie Mitglied, darf sie das sehen? Vicus beantwortet das für Sie — mit einer geprüften Bürgeridentität und Zielgruppen, die Sie nur noch abfragen.
  • Benachrichtigungen. Push, Mail, Hinweis in der App: Ihre Fachereignisse erreichen genau die richtigen Menschen, über einen Transport, den die Plattform betreibt.
  • Dokumentenzustellung. Bescheide, Verträge, Rechnungen, Anhänge — hochladen, zustellen, abrufen. Aufbewahrung, Zugriffsschutz und Nachweis liegen bei der Plattform.
  • Ein Ort, an dem Sie gefunden werden. Der öffentliche Kalender und Feed des Ortes sammelt quellenübergreifend, was passiert. Was Ihre Anwendung veröffentlicht, steht dort neben allem anderen aus dem Dorf.

Unterm Strich: Ein Provider für Vicus ist ein kleiner Dienst. Sieben Operationen über HTTP, eine eigene Datenbank, Ihre Fachlogik. Die Referenzimplementierung kommt mit vier Tabellen und einer Controller-Klasse aus. Was darüber hinausgeht, ist Ihr Produkt — nicht Ihre Integrationsarbeit.

Was Sie mitbringen

Drei Dinge entscheiden, ob eine Anbindung für Sie leicht wird. Wenn Ihre Anwendung sie erfüllt, ist der Rest Handwerk.

  • Einen abgegrenzten Fachbereich. Gebäude- und Raumverwaltung, Veranstaltungen, Vereinsverwaltung, Ratsinformation, Nachbarschaftsdienste: Ihre Anwendung deckt einen dieser Bereiche mit eigenen Objekten und eigenen Abläufen ab. Genau so ist der Katalog geschnitten, und genau so wählt eine Gemeinde aus.
  • Eine eigene Mitarbeiteroberfläche. Ihre Kundinnen und Kunden arbeiten weiter in Ihrer Anwendung — mit Ihrem Funktionsumfang, Ihrem Bedienkonzept, Ihrer Marke. Vicus ist die Seite der Bürgerinnen und Bürger, Ihre Software bleibt die Seite der Verwaltung. Zwei Oberflächen, die sich nicht ins Gehege kommen.
  • Mandantentrennung. Ihre Anwendung kann je Gemeinde und je Verein einen sauber getrennten Mandanten führen. Eine Anbindung gilt immer für genau ein Paar aus Institution und Fachbereich — damit wächst Ihre Reichweite Ort für Ort, ohne dass Daten sich je vermischen.

Dazu kommt ein kurzes Bedrohungsmodell: fünf Abschnitte dazu, welche Daten Sie halten, was bei einer Kompromittierung passiert und was Sie melden. Eine Vorlage liegt im SDK bei. Gemeinden lesen so etwas — es ist eher ein Verkaufsargument als eine Pflichtübung.

In sechs Schritten angebunden

Der Weg ist kurz und in dieser Reihenfolge zu gehen. Jeder Schritt hat ein klares Ergebnis — und einen konkreten Nutzen für Sie.

  1. Fachbereich klären

    Wir legen gemeinsam fest, welchen Fachbereich Sie abdecken und welche Funktionsprofile Sie mitbringen. Ihr Gewinn: Sie wissen nach einem Gespräch genau, was zu bauen ist — und was Sie schon haben.

  2. Verträge beziehen

    Sie erhalten das versionierte Vertragsbündel mit Schemata und Testvektoren, gegen das alles validiert wird. Ihr Gewinn: keine Rätselraten über Formate, sondern maschinenlesbare Wahrheit vom ersten Tag an.

  3. Manifest beschreiben

    In einer Datei sagen Sie, welchen Fachbereich Sie in welchen Versionen bedienen und welche Plattformdienste Sie beziehen. Ihr Gewinn: Ihre Anbindung ist damit dokumentiert, prüfbar und in Sekunden validiert.

  4. Protokoll implementieren

    Sieben Operationen, erzeugt aus einer OpenAPI-Beschreibung — in Ihrer Sprache, Ihrem Framework, ohne fremde Bibliothek im Produktivcode. Ihr Gewinn: eine überschaubare Aufgabe für ein kleines Team, keine Plattform-Ehe.

  5. Konformität nachweisen

    Zwölf benannte Prüffälle laufen als Blackbox über HTTP gegen Ihren Dienst, dazu kommt eine signierte Manifestprüfung. Ihr Gewinn: ein Nachweis, den Sie jeder Gemeinde vorlegen können — und der Ihnen selbst zeigt, dass es hält.

  6. Freischalten

    Pairing per Einmalcode, ein Prüflauf der Migration mit Bericht, dann der kontrollierte Wechsel der Datenhoheit in klar getrennten Phasen. Ihr Gewinn: eine Umstellung ohne Doppelpflege — und bis zum letzten Schritt jederzeit abbrechbar.

Eine Datei beschreibt Ihre ganze Anbindung

Eine Datei beschreibt Ihre gesamte Anbindung. Sie ist der Vertrag zwischen Ihrer Anwendung und der Plattform — und sie ist kurz genug, um sie an einem Vormittag zu schreiben.

Feld Was es sagt
providerId Die stabile Kennung Ihrer Anwendung.
operator Wer den Dienst betreibt — Ihr Haus, namentlich.
adapterVersion Die Version Ihrer Anbindung. Sie können unabhängig von der Plattform ausliefern.
capabilities Welchen Fachbereich Sie in welchem Versionsbereich bedienen, mit Ihren Funktionsprofilen.
requiredPlatformContracts Welche Plattformdienste Sie nutzen — mit Zweck und Datenkategorien. Ihre Datenschutzdokumentation schreibt sich hier fast von selbst.
manifestDigest und signature Prüfsumme und Signatur über die ausgelieferten Bytes. Damit steht fest, dass genau Ihre Fassung läuft.
threatModel Ihr kurzes Bedrohungsmodell nach fester Gliederung.

Kompatibilität geben Sie nie als einzelne Version an, sondern als Bereich. Das ist der Grund, warum Plattform und Anbindung getrennt weiterentwickelt werden können: Sie liefern in Ihrem Takt aus, ohne auf ein Plattformrelease zu warten.

Sieben Operationen — mehr müssen Sie nicht bauen

Das Provider-Protokoll ist eine OpenAPI-Beschreibung. Server und Client entstehen aus derselben Datei, Sie implementieren die erzeugten Schnittstellen. Mehr als diese sieben Operationen gibt es nicht.

Operation Aufgabe
discover Erkennung: Wer sind Sie, welche Fachbereiche und Versionen bedienen Sie.
health Zustand, auf drei Werte geschlossen: SERVING, DEGRADED, NOT_SERVING.
completePairing Pairing: Ihr Dienst wird per Einmalcode an eine Institution gebunden.
query Abfragen: Katalog, Verfügbarkeit, Vorgänge — live aus Ihrer Datenhaltung.
command Kommandos: Anfrage, Buchung, Änderung. Werden angenommen und mit Idempotenzschlüssel wiederholbar ausgeführt.
operationStatus Vorgangsstatus: ACCEPTED, IN_PROGRESS, SUCCEEDED, FAILED, EXPIRED_UNKNOWN.
readEvents Ereignisse: Seiten über einen opaken, monoton wachsenden Cursor — nach einem Abbruch wird verlustfrei weitergelesen.

Zwei Entscheidungen darin ersparen Ihnen später viel Arbeit. Erstens werden Kommandos angenommen, nicht sofort angewendet; das Ergebnis lesen Sie getrennt. Damit blockiert kein Bürgerklick auf einen langsamen Fachvorgang. Zweitens sind Fehler ein geschlossener Satz benannter Codes — unter anderem SCOPE_NOT_BOUND, CONFLICT, RATE_LIMITED, UNAVAILABLE. Der Aufrufer entscheidet allein daraus über Wiederholen oder Abbrechen. Freitext als Steuerinformation gibt es nicht, also auch keine Fehlerbehandlung, die an einer geänderten Meldung zerbricht.

Was wir Ihnen abnehmen

Zehn versionierte Plattformdienste stehen bereit. Sie fordern im Manifest genau die an, die Sie brauchen — jede einzelne davon ist Entwicklungszeit, die Sie nicht bezahlen, und Betriebsverantwortung, die Sie nicht tragen.

Dienst Was Sie dadurch nicht bauen
platform.identity Bürgeridentität, Anmeldung, Zuordnung von Personen zu Vorgängen.
platform.institution Das Verzeichnis der Gemeinden, Vereine, Sparten und Teams samt Hierarchie.
platform.audience Zielgruppen. Sie fragen „darf diese Person das sehen?“ und bekommen eine Antwort.
platform.entitlement Mitgliedschafts- und Berechtigungsnachweise — als Ja/Nein mit Ablauf, statt als Mitgliederliste in Ihrer Datenbank.
platform.consent Einwilligungen, Freigabenachweise, Widerruf. Die Nachweiskette bleibt bei der Plattform.
platform.notification Push, Mail und In-App-Hinweise an Bürgerinnen und Bürger.
platform.documents Dokumente zustellen, hoch- und herunterladen — mit Ablage und Zugriffsschutz.
platform.navigation Die Bürgeroberfläche und ihre Abläufe. Sie bestätigen nur, welche Sie unterstützen.
platform.audit Ein auswertbares Protokoll aller Zugriffe — die Antwort auf jede Prüferfrage.
platform.feed Den öffentlichen, quellenübergreifenden Kalender und Feed des Ortes.

Jeder Zugriff läuft über eine einzige Fassade, die Route und Bewilligung frisch prüft. Für Sie heißt das: Ein Dienst, den Sie im Manifest angefordert haben, funktioniert — und einer, den Sie nicht angefordert haben, kann Ihnen auch nicht versehentlich Daten liefern, für die Sie geradestehen müssten.

Klare Verantwortung

Je Fachbereich und Institution gibt es genau ein schreibendes System. Das ist das tragende Prinzip der Plattform, und es arbeitet für Sie.

  • Keine Datenkonflikte. Solange Sie der Schreiber sind, schreibt niemand sonst in diesen Bereich. Kein Abgleich, keine Doppelpflege, keine Frage, welcher Termin nun gilt.
  • Klare Zuständigkeit. Vicus legt keine dauerhafte Kopie Ihrer Fachdaten an. Ansichten werden live bei Ihnen geladen. Was Ihre Anwendung anzeigt, ist der Stand Ihrer Anwendung — es gibt keinen zweiten, veralteten Bestand, für den Sie sich rechtfertigen müssen.
  • Kein Streit um Hoheit. Die Übernahme läuft in klar getrennten Phasen mit Prüflauf, Bericht und einem definierten Punkt, ab dem umgeschaltet ist. Ein Fencing-Token sorgt dafür, dass danach kein alter Schreiber mehr durchkommt — auch nicht versehentlich.
  • Vicus ist der Bürgerkanal, Sie bleiben der Fachbetrieb. Für den gebundenen Bereich führt genau ein öffentlicher Weg zu den Daten: die Dorfapp. Das ist der Grund, warum eine Gemeinde die Datenhoheit überhaupt weitergibt — Bürgerinnen und Bürger sollen eine Anlaufstelle haben und nicht sechs Portale. Sie gewinnen dabei mehr, als Sie abgeben: Ihre Fachlichkeit erreicht jeden im Ort, ohne dass Sie je ein Bürgerportal bewerben müssten.
  • Der Rückweg ist eingebaut. Eine Anbindung lässt sich mit signiertem Voll-Export und objektgenauem Bericht wieder lösen. Das nimmt jeder Gemeinde die Angst vor der Entscheidung — und macht Ihr Angebot leichter verkäuflich.

Nächster Schritt

Schreiben Sie uns, was Ihre Anwendung kann. Ein technisches Gespräch klärt in einer Stunde, welchen Fachbereich Sie besetzen, was Sie schon mitbringen und wie kurz der Weg zur ersten Gemeinde ist. Ein Formular gibt es nicht — eine Mail genügt.

Hilfreich für den Einstieg sind vier Angaben:

  1. Welchen Fachbereich Ihre Anwendung abdeckt und für welche Institutionstypen.
  2. Welche Funktionen Sie heute schon haben.
  3. Ob Ihr System je Institution einen eigenen Mandanten führt.
  4. Ob Sie eigene öffentliche Bürgerseiten betreiben — und welche.

Anbindung anfragen Vicus für Firmen