Viele Unternehmen starten mit einem Portal aus einem nachvollziehbaren Grund: Kunden, Partner oder Außendienst sollen Vorgänge selbst anstoßen, Dokumente abrufen, Bestellungen verfolgen oder Störungen melden. Im ersten Schritt wirkt das wie ein reines Frontend-Projekt. In der Realität entscheidet der Erfolg jedoch nicht am Web-UI, sondern an der Frage, ob Portal, Desktop-Client und Backoffice auf derselben fachlichen Wahrheit arbeiten.
Sobald Portalzugriffe auf die gleiche Datenbasis treffen wie eine gewachsene Desktop-Anwendung, entstehen typische Spannungen: unterschiedliche Rechtekonzepte, konkurrierende „führende“ Daten, abweichende Validierungen, Medienbrüche bei Freigaben oder ein uneinheitliches Verständnis von Status und Versionen. Wenn diese Themen nicht sauber gelöst werden, baut man ungewollt ein paralleles Zweitsystem – mit doppelter Pflege, widersprüchlichen Prozessen und immer höheren Betriebskosten.
Dieser Beitrag beschreibt, wie Unternehmen Portale, Desktop und Daten sauber zusammenbringen: über eine klare Schichtenarchitektur, belastbare REST-Services, konsistente Datenmodelle, nachvollziehbare Prozesse und einen pragmatischen Modernisierungspfad für Bestandssoftware (häufig Delphi-basiert). Ziel ist eine Architektur, die heute funktioniert und morgen erweiterbar bleibt – ohne Aktionismus und ohne „Big Bang“.
Warum „Portal neben Desktop“ selten funktioniert
Ein Portal entfaltet seinen Nutzen erst, wenn es integraler Bestandteil der Fachanwendung wird. „Nebenher“ bedeutet in der Praxis meist: separate Validierungen, separate Benutzerverwaltung, separate Statuslogik und oft auch ein separates Reporting. Das fällt am Anfang kaum auf, wird aber mit jeder Erweiterung teurer.
Typische Symptome einer Parallelwelt
- Widersprüchliche Daten: Stammdaten werden im Portal anders gepflegt als im Desktop. Die Frage „welches Feld ist führend?“ wird nicht beantwortet, sondern umgangen.
- Unterschiedliche Geschäftsregeln: Der Desktop prüft mehr (oder anderes) als das Portal. Fehler tauchen erst in nachgelagerten Prozessen auf.
- Freigaben per Medienbruch: Portal stößt einen Vorgang an, aber Freigabe läuft per E-Mail oder manuell im Desktop – ohne Audit-Trail.
- Schnittstellen wachsen unkontrolliert: Statt einer stabilen API entstehen punktuelle Exporte/Importe oder „Spezialendpunkte“ pro Portalmaske.
- Versionsprobleme: Portal und Desktop erwarten unterschiedliche Datenstrukturen; Releases müssen synchronisiert werden, ohne dass es eine klare Kompatibilitätsstrategie gibt.
Die zentrale Ursache: Fachlogik sitzt im falschen Layer
In vielen Bestandsanwendungen steckt fachliche Logik im Desktop-Client: Validierungen, Statuswechsel, Berechnungen, Plausibilitäten. Ein Portal, das direkt auf die Datenbank zugreift oder Logik neu implementiert, kann damit nicht konsistent sein. Die Lösung ist nicht „mehr Abstimmung“, sondern eine technische und fachliche Entkopplung: Fachlogik muss in einen zentralen Service-Layer, den Desktop und Portal gleichermaßen nutzen.
Zielbild: Ein System, mehrere Clients
Wenn Unternehmen Portale und Desktop verbinden, ist das eigentliche Ziel nicht „Web statt Desktop“, sondern ein gemeinsames System, das über mehrere Oberflächen bedient werden kann. Der Desktop bleibt dort stark, wo komplexe Workflows, hohe Datenmengen, spezielle Geräteanbindung oder power-user-lastige Bedienkonzepte gefragt sind. Das Portal ist stark für Self-Service, 24/7-Zugriff, Rollen außerhalb des Unternehmens und einfache, geführte Prozesse.
Einheitliche Bausteine
Ein tragfähiges Zielbild nutzt gemeinsame Kernkomponenten:
- Zentrales Datenmodell (mit klaren Ownership-Regeln: welche Entität wird wo gepflegt?).
- Gemeinsame Fachlogik (z. B. in REST-Services), nicht doppelt in Portal und Desktop.
- Einheitliches Rechte- und Rollenmodell (RBAC/ABAC je nach Komplexität).
- Nachvollziehbarkeit (Audit-Logging, Status-Historien, „wer hat was wann warum geändert“).
- Versionierbare APIs (Kompatibilitätsregeln, Deprecation, Migrationspfade).
Architekturgrundlagen: Layer-3 statt „direkt in die Datenbank“
Für die Verbindung von Portal und Desktop hat sich eine Layer-3 Architektur bewährt: Präsentation (Portal/Client), Fachlogik (Services) und Datenzugriff (persistente Schicht). Wichtig ist die Disziplin, dass Clients nicht an der Fachlogik vorbei direkt auf Tabellen zugreifen. Das gilt auch (und gerade) dann, wenn der Desktop historisch „alles selbst“ gemacht hat.
Schicht 1: Clients (Portal, Desktop, ggf. Mobile)
Clients sollen Oberfläche, Interaktion und lokale Anforderungen abdecken: Validierungen für bessere Usability sind sinnvoll, aber sie ersetzen keine serverseitige Regelprüfung. Für Delphi-Bestandssoftware ist das häufig der Punkt, an dem man von einem monolithischen VCL-Client schrittweise zu einem Client wird, der Services konsumiert. Bei Multiplattform-Anforderungen kann ein Teil des Funktionsumfangs auch in neuen Clients entstehen, während der Kern stabil bleibt.
Schicht 2: Service-Layer (REST-Server, Hintergrunddienste)
Der Service-Layer ist die fachliche Mitte: Authentifizierung, Autorisierung, Fachregeln, Transaktionen, Statuswechsel, Dokumentprozesse, Idempotenz, Nebenläufigkeit. Hier entscheidet sich, ob Portal und Desktop wirklich zusammenarbeiten oder nur denselben Datenbankserver teilen. Ein sauberer REST-Server ist dabei nicht „ein paar Endpunkte“, sondern eine konsistente API mit klarer Domänensprache.
Schicht 3: Datenzugriff (SQL, Treiber, Migrationen)
Die Datenzugriffsschicht kapselt Datenbankdetails: SQL-Dialekte, Transaktionen, Stored Procedures, Indizes, Migrationen. Gerade bei Delphi-Systemen mit Historie ist hier oft eine Modernisierung nötig: Weg von der Borland BDE hin zu modernen Treibern und einem konsistenten Zugriff, zum Beispiel über BDE-Ablosung mit nativer Anbindung. Nur so bekommt man Stabilität im Deployment, klare Transaktionsgrenzen und eine Datenbasis, die Portal-lastige Zugriffsmuster (viele kurze Requests) zuverlässig trägt.
REST-API als verbindendes Element – aber richtig
Eine REST-API ist der natürliche Knotenpunkt, um Portal, Desktop und Services zu verbinden. Entscheidend ist, sie so zu schneiden, dass sie Prozesse abbildet – nicht nur Tabellen.
Ressourcen vs. Aktionen: Domänenlogik sichtbar machen
Viele APIs starten „CRUD-nah“. Das ist für einfache Stammdaten akzeptabel, scheitert aber bei Vorgängen mit Status, Freigaben, Berechnungen oder Nebenwirkungen. Dann sind explizite Aktionen sinnvoll, zum Beispiel:
- /orders/{id}/approve statt „Status=Approved“ per Update
- /tickets/{id}/assign mit Prüfungen, Berechtigungen, Historie
- /documents/{id}/publish mit Versionierung und Freigabeprozess
Damit wird das System verständlicher, testbarer und konsistenter zwischen Portal und Desktop.
Transaktionen, Nebenläufigkeit und Idempotenz
Portalzugriffe sind typischerweise kurz, häufig und parallel. Daraus folgen drei Pflichten:
- Saubere Transaktionsgrenzen: Jede fachliche Operation muss atomar sein, inklusive Protokollierung und Statuswechsel.
- Optimistic Concurrency: ETag/RowVersion oder ähnliche Mechanismen verhindern, dass Änderungen still überschrieben werden. Desktop und Portal sollen Konflikte erkennen und gezielt lösen.
- Idempotente Endpunkte: Insbesondere bei „Submit“-Aktionen (z. B. Bestellungen) müssen Wiederholungen durch Netzwerkprobleme sicher sein.
API-Versionierung ohne Release-Zwang
Wenn Portal und Desktop aus unterschiedlichen Release-Zyklen kommen, braucht die API eine klare Kompatibilitätsstrategie. Praxisnah ist eine versionsfähige API (z. B. /v1/…), ergänzt um Regeln: Erweiterungen sind abwärtskompatibel (neue Felder optional), Breaking Changes werden über neue Versionen eingeführt, alte Versionen bekommen Deprecation-Fristen. Damit bleibt der Desktop nicht bei jeder Portaländerung stehen – und umgekehrt.
Rechte, Rollen und Mandantenfähigkeit: Ein Modell, mehrere Perspektiven
Portale bringen neue Nutzergruppen: Kunden, Partner, Subunternehmer, Auditoren. Desktop-Anwendungen sind oft auf interne Rollen ausgelegt. „Einfach dieselben Rechte“ funktioniert selten. Ziel ist ein einheitliches Modell, das beide Welten abdeckt.
RBAC als Basis, ABAC wo nötig
Für viele B2B-Systeme reicht RBAC (Role-Based Access Control): Rollen definieren, welche Aktionen und Datenbereiche sichtbar sind. Komplexer wird es, wenn Rechte von Kontext abhängen (Mandant, Standort, Vertragsbeziehung, Projektzuordnung). Dann ergänzt ABAC (Attribute-Based Access Control) das Modell: Entscheidungen hängen von Attributen am Nutzer und an der Ressource ab.
Mandantenfähigkeit sauber definieren
Mandantenfähigkeit ist nicht nur „MandantID in jeder Tabelle“. Relevant sind:
- Datenisolation: Wer darf welche Entitäten sehen? Wie werden Querverbindungen verhindert?
- Konfiguration pro Mandant: Workflows, Pflichtfelder, Dokumenttemplates, Schnittstellen.
- Audit und Export: Nachvollziehbarkeit und Datenbereitstellung pro Mandant (z. B. für Prüfungen).
Gerade in gewachsenen Datenmodellen lohnt es sich, Mandantenfähigkeit als eigenes Arbeitspaket zu behandeln, bevor Portal-Features „oben drauf“ gebaut werden.
SSO und Identity: Nicht im Portal isolieren
Ein häufiger Fehler ist eine separate Benutzerverwaltung im Portal, während der Desktop weiterhin „lokal“ oder über andere Mechanismen authentifiziert. Besser ist eine zentrale Identity-Strategie: interne Nutzer über Unternehmens-SSO (z. B. Entra ID/AD), externe Nutzer über getrennte Policies, aber in einer gemeinsamen Identitätsdomäne. Wichtig ist dabei nicht ein bestimmter Anbieter, sondern die klare Trennung von Authentifizierung (wer bist du?) und Autorisierung (was darfst du?).
Datenqualität und „führende Daten“: Governance statt Bauchgefühl
Wenn Portal und Desktop dieselben Entitäten bearbeiten, muss klar sein, wer welche Daten führt. Ohne diese Governance entstehen stille Inkonsistenzen. Eine einfache, aber wirksame Methode ist eine Ownership-Matrix:
- Entität (z. B. Kunde, Vertrag, Artikel, Ticket)
- Führendes System (Portal, Desktop, ERP, CRM)
- Schreibrechte (wer darf erstellen/ändern?)
- Synchronisation (Push, Pull, Ereignisse, Zeitfenster)
- Validierungsregeln (wo serverseitig zentral geprüft?)
Events und Nachverarbeitung statt Direktkopien
Viele Prozesse brauchen Nachverarbeitung: Dokument erzeugen, E-Mail auslösen, Daten an ERP übertragen, PDF signieren, Index in DMS schreiben. Das sollte nicht als „Portal macht es direkt“ umgesetzt werden, sondern als Service-Workflow. In der Praxis sind robuste Hintergrunddienste (Windows Services oder Linux-Services) oft die richtige Ergänzung zum REST-Server: Der API-Call stößt an, ein Worker arbeitet zuverlässig ab, mit Retry-Strategie und Protokoll.
Delphi-Desktop und Portal: Modernisieren ohne Neuanfang
In vielen Unternehmen ist Delphi nicht „Altlast“, sondern produktive Basis kritischer Fachprozesse. Die Herausforderung liegt meist weniger im Compiler als in Struktur, Datenzugriff und Deployment. Ein Portal-Projekt ist häufig der richtige Zeitpunkt, die Desktop-Anwendung so umzubauen, dass sie Service-orientiert wird.
Schrittweiser Umbau: Strangler-Pattern für Fachlogik
Statt alles neu zu schreiben, wird Fachlogik iterativ aus dem Client herausgelöst:
- Phase 1: API für ausgewählte Kernfälle (z. B. Ticket anlegen, Auftrag freigeben). Desktop nutzt die API parallel zum bestehenden Weg.
- Phase 2: Mehr Prozesse wandern in den Service-Layer; Desktop wird zunehmend „UI + Offline-nahe Funktionen“.
- Phase 3: Alte direkte DB-Zugriffe werden reduziert; Datenzugriff und Validierungen sind zentral.
Das Ergebnis ist nicht zwingend „Web ersetzt Desktop“, sondern ein System, das beides kontrolliert bedient.
BDE-Ablösung und FireDAC: Grundlage für stabile Services
Wenn im Bestand noch BDE-basierter Datenzugriff existiert, ist das beim Portal-Ausbau ein Risikofaktor: Deployment, Treiberverfügbarkeit, 64-Bit/ARM64-Pfade und Fehlersuche werden unnötig schwierig. Eine BDE-Ablösung mit BDE-Ablosung mit nativer Anbindung (oder vergleichbar nativen Zugriffswegen) schafft:
- Klare Transaktionen für API-Operationen
- Bessere Performance unter parallelen Portalzugriffen
- Sauberere Migration auf MariaDB, PostgreSQL oder SQL Server
- Stabileres Deployment in heterogenen Umgebungen
Multiplattform und Betrieb: Desktop, Services, ARM64
Viele Unternehmen planen heute heterogener: Windows-Clients, vereinzelt macOS, Serverbetrieb auf Linux, und mittelfristig Windows 11 ARM64 im Client-Umfeld. Das beeinflusst Entscheidungen früh:
- Native Abhängigkeiten (Treiber, COM, Reporting-Komponenten) müssen auf ihre Plattformfähigkeit geprüft werden.
- Service-Betrieb (Linux-Services) kann für Integrationen und Worker-Jobs sinnvoll sein, während der Desktop weiterhin Windows-fokussiert bleibt.
- API-First reduziert Plattformkopplung: Neue Clients sprechen dieselbe Schnittstelle.
Integrationen: ERP, DMS, CRM – sauber über Schnittstellen statt Datenkopien
Portale sind selten allein. Häufig müssen sie ERP-Aufträge anlegen, CRM-Accounts lesen, Dokumente in ein DMS schreiben oder Versanddaten von Logistikdienstleistern abrufen. Je mehr Systeme beteiligt sind, desto wichtiger ist ein klarer Integrationsstil.
Schnittstellen-Governance
Wichtige Fragen, die vor Implementierung entschieden werden sollten:
- Welche Quelle ist führend? (ERP führt Preise, CRM führt Ansprechpartner etc.)
- Synchron oder asynchron? (Echtzeit für Validierung, asynchron für Übernahmen)
- Fehlerbehandlung: Was passiert bei Teilausfällen? Gibt es Warteschlangen, Retry, Dead-Letter?
- Protokollierung: Welche Daten werden revisionssicher nachvollziehbar gespeichert?
Dokumente, Reporting und PDF-Workflows
Ein Portal erzeugt oft Dokumentdruck und Downloadbereiche: Lieferscheine, Rechnungen, Protokolle, Zertifikate, Bestätigungen. Technisch ist das mehr als „PDF generieren“: Versionierung, Freigabe, Nachvollziehbarkeit, Zugriffsrechte und Aufbewahrungsfristen spielen hinein. Bewährt hat sich ein Dokumentservice, der Metadaten (Version, Status, Sichtbarkeit) verwaltet und die Erzeugung (Rendering) kontrolliert ausführt – statt im Portal-Frontend „irgendwo“ PDFs zu bauen.
Betrieb und Sicherheit: Was im Alltag zählt
Wenn Portal und Desktop an einem Kernsystem hängen, steigt die betriebliche Relevanz. Die Architektur muss daher nicht nur funktional, sondern auch betreibbar sein.
Logging, Monitoring, Audit
Für B2B-Fachsysteme sind drei Ebenen wichtig:
- Technisches Logging (Request-IDs, Fehler, Laufzeiten)
- Business-Logging (Statuswechsel, Freigaben, relevante Entscheidungen)
- Audit-Trail (wer hat welche Daten geändert, inkl. Vorher/Nachher je nach Bedarf)
Ein Portal ohne belastbaren Audit-Trail erzeugt früher oder später Diskussionen mit Fachbereichen, Revision oder Kunden – besonders bei Freigaben und Vertragsdaten.
Rate Limiting und Schutz vor Missbrauch
Portale sind öffentlich(er) als Desktop-Anwendungen. Selbst wenn nur Kunden zugreifen, muss das System mit fehlerhaften Clients, unabsichtlicher Last oder automatisierten Zugriffen umgehen. Rate Limiting, sinnvolle Payload-Limits, Upload-Validierung und klare Timeouts schützen nicht „nur vor Angreifern“, sondern vor Instabilität im Alltag.
Datenbank-Performance unter Portal-Last
Portalzugriffe erzeugen häufig viele kleine Lesezugriffe, Filter, Paginierung und Suche. Häufige Fallen sind fehlende Indizes, zu breite SELECTs, „N+1“-Abfragen oder unklare Sortierungen. Der Datenzugriff sollte deshalb konsequent auf:
- paginierte Listen (serverseitig, stabil sortiert)
- gezielte Projektionen (nur benötigte Felder)
- Filter mit Indizes (insbesondere Mandant, Status, Datum)
- Cache-Strategien (für Stammdaten, wo fachlich erlaubt)
ausgelegt werden.
Ein pragmatischer Fahrplan für Unternehmen
„Portale, Desktop und Daten sauber zusammenbringen“ ist ein Programm, kein einzelnes Ticket. Gleichzeitig muss es in überschaubaren Schritten passieren, damit Fachbereiche schnell Nutzen sehen. Ein bewährter Ablauf sieht so aus:
1) Ist-Aufnahme: Daten, Prozesse, Schmerzpunkte
Welche Entitäten sind kritisch? Wo entstehen Konflikte? Welche Rollen brauchen Zugriff? Welche Integrationen sind Pflicht? Ergebnis sollte eine priorisierte Liste fachlicher Kernprozesse sein, nicht nur eine UI-Wunschliste.
2) Zielarchitektur: Service-Layer und Rechtekonzept festziehen
Bevor das Portal „schön“ wird, muss feststehen, wie Auth/Autorisierung, Transaktionen, Audit und Versionierung gelöst werden. Das sind die Leitplanken, die spätere Kosten massiv beeinflussen.
3) Pilotprozess: Ein Ende-zu-Ende-Flow
Ein sinnvoller Pilot ist ein Prozess, der Portal, Service, Daten und ggf. Dokumente berührt (z. B. Ticket anlegen inkl. Anhang und interner Bearbeitung). Damit prüft man Architektur und Betrieb in realen Bedingungen.
4) Ausbau: Prozessfamilien statt Einzelfunktionen
Danach werden nicht einzelne Masken umgesetzt, sondern zusammenhängende Prozessketten: z. B. „Anfrage → Angebot → Freigabe → Auftrag“ oder „Störung → Analyse → Rückmeldung → Abschluss“. Das reduziert Schnittstellenwildwuchs und erhöht Konsistenz.
5) Modernisierung des Desktops: Schrittweise, messbar
Parallel wird der Desktop so umgebaut, dass er dieselbe Service-Logik nutzt. Das reduziert Doppelimplementierung und macht den Betrieb einfacher, weil es eine fachliche Quelle gibt.
Fazit: Konsistenz ist das eigentliche Portal-Feature
Ein Portal ist nicht „ein weiterer Zugang“ zur Datenbank, sondern ein zusätzlicher Client für dasselbe System. Wer Portale und Desktop verbinden will, muss Fachlogik, Rechte, Datenmodelle und Betrieb konsequent zentralisieren: über eine Layer-3 Architektur, einen robusten REST-Server, klare Ownership-Regeln für Daten und eine Modernisierungsstrategie, die Bestandssoftware nicht abwertet, sondern strukturell verbessert. Das Ergebnis ist weniger Reibung im Alltag, bessere Erweiterbarkeit und eine Plattform, die neue Kanäle (Partner, Mobile, Services) ohne Architekturbruch aufnehmen kann.
Wenn Sie klären möchten, wie sich ein Portal sauber an Ihre bestehende Desktop- und Datenlandschaft anbinden lässt (inklusive REST-API, Rollenmodell, Datenzugriff und schrittweiser Modernisierung), sprechen Sie mit uns: https://net-base-software-gmbh.de/kontakt/