API-first-Architektur: Kanzleisoftware, die zusammenarbeitet

In vielen Kanzleien beginnt ein neues Mandat damit, dass dieselbe Adresse in fünf Programme getippt wird, einmal für jede Anwendung. Das beA, die Buchhaltung und das E-Mail-Programm funktionieren jedes für sich, doch keiner weiß, was das andere bereits erfasst hat. Also überträgt jemand die Daten von Hand aus einem Fenster in das nächste, ein Aufwand, der auf keiner Rechnung steht und trotzdem täglich Zeit kostet. Ob eine Kanzleisoftware solche Wege abnimmt oder erzwingt, hängt an ihrem Aufbau, genauer an der API-first-Architektur. Was hinter diesem Begriff steckt und warum er über Ihren Arbeitstag entscheidet, zeigt sich am besten am Problem, das er löst.

Was eine API-first-Architektur konkret bedeutet

Stellen Sie sich zwei Kolleg:innen vor, die nebeneinander arbeiten, aber kein gemeinsames Wort sprechen. Jede Information muss übersetzt, aufgeschrieben und weitergereicht werden. Genau so verhalten sich die meisten Kanzleiprogramme zueinander. Eine Schnittstelle ist die gemeinsame Sprache, die dieses Übersetzen überflüssig macht: eine feste Vereinbarung, über die zwei Programme automatisch Daten austauschen. In der Fachsprache heißt sie API.

Der Zusatz „first" verrät, wann diese gemeinsame Sprache eingebaut wurde. Bei vielen Systemen kam es erst spät dazu, als Anbau, der nur das Nötigste sein kann. Eine API-first-Architektur beginnt am anderen Ende: Die Verbindung ist von der ersten Stunde an Teil des Systems, offen und dokumentiert. Der Unterschied bleibt unsichtbar, bis Sie ein neues Werkzeug anschließen wollen. Dann zeigt er sich sofort. Zum einen dauert es Tage, zum anderen wird ein monatelanges Projekt daraus, wenn es überhaupt gelingt.

Für die Auswahl einer Kanzleisoftware genügt deshalb eine einzige Frage: Spricht dieses System die Sprache der Programme, die wir schon nutzen? Ein Programm, das sich abschottet, gibt die Arbeit an die Menschen zurück, die sie eigentlich entlasten sollen.

Ein Beispiel aus dem Kanzleialltag

Am einfachsten wird das an einem gewöhnlichen Vorgang deutlich. Nehmen wir eine neue Mandantin, die in einer mietrechtlichen Sache anruft.

Ohne Verbindung zwischen den Programmen sieht der Ablauf so aus: Die Kollegin am Telefon notiert Namen und Anliegen zunächst in einer E-Mail an sich selbst. Später legt sie in der Kanzleisoftware eine Akte an und tippt die Kontaktdaten erneut ein. Für die Vergütungsvereinbarung öffnet sie die Buchhaltung und erfasst dieselbe Adresse ein drittes Mal. Der erste Schriftsatz entsteht in einer Vorlage, in die Aktenzeichen und Anschrift von Hand übernommen werden, und für den Versand wandert alles noch in das beA. Am Ende sind es fünf Programme, in die dieselben Angaben fünfmal eingegeben wurden.

Mit einer API-first-Architektur läuft derselbe Vorgang anders. Sobald die Akte einmal angelegt ist, kennen die verbundenen Programme die Mandatsdaten bereits:

• Eine eingehende E-Mail aus Microsoft Outlook wird automatisch der richtigen Akte zugeordnet, statt in einem allgemeinen Postfach zu versanden.
• Ein Anruf über die Telefonanlage zeigt direkt, zu welchem Vorgang die Nummer gehört, und das Gesprächsprotokoll landet an der passenden Stelle.
• Die Vergütungsdaten stehen der Buchhaltung und dem Austausch mit der Steuerberatung ohne erneute Eingabe zur Verfügung.
• Ein Schriftsatz lässt sich über das beA direkt aus der Akte versenden, ohne ein zweites Fenster zu öffnen.
• Ein KI-Werkzeug zur Vertragsprüfung erhält den relevanten Vertrag und legt sein Ergebnis wieder im selben Vorgang ab.

Der Gewinn ist keine Frage der Bequemlichkeit. Dieselbe Adresse, die zuvor fünfmal getippt wurde, wird nun einmal erfasst und überall genutzt. Ändert sich später die Anschrift der Mandantin, genügt eine Korrektur an einer Stelle, und alle verbundenen Programme arbeiten mit dem aktuellen Stand.

Warum Kanzleien ohne API-first-Architektur an Grenzen stoßen

Keine Kanzlei kommt mit einem einzigen Programm aus. Für die Kommunikation gibt es E-Mail und Telefonie, für die Zahlen die Buchhaltung, für den Schriftverkehr mit Gerichten das beA, dazu kommen zunehmend Werkzeuge mit künstlicher Intelligenz für Recherche oder Vertragsprüfung. Jedes davon löst seine Aufgabe für sich genommen gut.

Der Bestand wächst über Jahre. Ein Werkzeug kommt hinzu, weil ein konkretes Bedürfnis entsteht, das nächste, weil eine neue Anforderung auftaucht. Jede einzelne Entscheidung ergibt für sich Sinn. Das eigentliche Problem liegt in den Übergängen. In der Praxis zeigt sich, dass die Lösungen wie getrennte Inseln nebeneinander stehen. Wer eine neue Akte anlegt, trägt dieselben Mandantendaten oft mehrfach ein, einmal in der Kanzleisoftware, dann in der Buchhaltung und noch einmal in der Vorlage für den ersten Schriftsatz. Fehlt eine gemeinsame Sprache zwischen den Systemen, bleibt diese Handarbeit die Regel.

Wie iusta die API-first-Architektur umsetzt

iusta ist als cloud-native Plattform gebaut, deren offener und dokumentierter Zugang von Beginn an Teil des Systems ist. Über eine sogenannte REST-API, also die zuvor beschriebene standardisierte Verbindung, lassen sich die Programme anschließen, mit denen eine Kanzlei ohnehin arbeitet. Dazu zählen Telefonie und E-Mail, die Buchhaltung, das beA sowie Werkzeuge mit künstlicher Intelligenz und einzelne Fachanwendungen.

Weil der Betrieb in der Cloud liegt, entfallen der eigene Server, die Terminalsitzung und das nächtliche Wartungsfenster. Updates und Sicherungen laufen im Hintergrund, sodass die Kanzlei sich nicht um die Technik dahinter kümmern muss. Die Abläufe lassen sich konfigurieren und die Fallakte an die Arbeitsweise der Kanzlei anpassen, damit die Software dem vorhandenen Vorgehen folgt, statt ein starres Schema aufzuzwingen.

Bei der Einrichtung begleiten Legal Engineers die Kanzlei, richten die Verbindungen gemeinsam ein und bleiben auch im laufenden Betrieb ansprechbar. In der Praxis entscheidet dieser Schritt darüber, ob eine offene Schnittstelle nur auf dem Papier steht oder im Alltag tatsächlich Arbeit abnimmt.

Screenshot iusta:

Was sich mit einer vernetzten Anwaltssoftware ändert

Ist die Verbindung einmal da, verschiebt sich der Alltag deutlich. Eine Mandatsinformation geben Sie ein einziges Mal ein und finden sie überall wieder, wo Sie sie brauchen. Der Schriftverkehr über das beA läuft direkt aus der Akte heraus, ein Beleg wandert ohne Umweg in die Buchhaltung, ein Rechercheergebnis aus einem KI-Werkzeug landet an der richtigen Stelle im Vorgang.

Der zweite Effekt betrifft die Zukunft der Kanzlei. Ändern sich die Anforderungen, etwa durch eine neue gesetzliche Vorgabe oder ein neues Werkzeug am Markt, lässt sich die passende Lösung ergänzen, ohne den bestehenden Ablauf umzubauen. So bleibt die Kanzlei unabhängig von dem, was ein einzelner Anbieter auf seinem Fahrplan vorsieht. Wer die eigenen Kanzleiabläufe automatisieren möchte, braucht dafür ohnehin ein System, das sich verbinden lässt, denn jede Automatisierung endet dort, wo eine Software von der nächsten nichts mehr erfährt.

Auch das beA gehört in dieses Bild. Seit dem 1. Januar 2022 gilt für Anwält:innen die aktive Nutzungspflicht, Schriftsätze an Gerichte also auf elektronischem Weg zu übermitteln. Eine saubere Anbindung an das beA sorgt dafür, dass diese Pflichten im normalen Arbeitsablauf aufgeht, statt als zusätzliches Fenster gesondert bedient zu werden.

Fazit

Am Ende zählt weniger der Begriff API-first-Architektur als seine Folge für Ihren Arbeitstag. Eine gute Kanzleisoftware erkennen Sie daran, dass sie sich in die Programme einfügt, mit denen Sie ohnehin arbeiten, und Ihnen die stillen Übertragungswege abnimmt. Wenn die Auswahl einer neuen Lösung ansteht, lohnt die Frage, wie offen sie sich mit Ihrer übrigen Arbeitsumgebung verbindet. Die cloud-native Kanzleisoftware von iusta ist auf genau diese Offenheit ausgelegt, damit mehr Zeit für die juristische Arbeit bleibt.