03Interne Plattform · Full Stack

Ressourcen- und Standortplattform

Eine rollenbasierte Cloud-Plattform verbindet zentrale Standort- und Leistungsdaten mit Suche, Kartenansicht, Routenplanung, Fahrzeitvergleich und kontrollierter dezentraler Datenpflege.

Zeitraum
2026
Status
Anonymisierte Fallstudie
Meine Rolle
End-to-End-Entwicklung und Cloud-Architektur

01 — Ausgangslage

Problem & Kontext

Standort-, Gesellschafts- und Leistungsdaten sollten nicht nur zentral gepflegt, sondern für operative Entscheidungen direkt nutzbar werden. Eine reine Listen- oder Kartensuche beantwortet jedoch nicht zuverlässig, welcher passende Standort für eine konkrete Ausgangsadresse tatsächlich am schnellsten erreichbar ist.

Die Plattform verbindet strukturierte Stammdaten mit Suche, Rollen, Karten- und Routing-Funktionen. Fachlich zugeordnete Bearbeiter pflegen ihre Bereiche dezentral, während zentrale Administration und kontrollierte Importprozesse für einheitliche Daten sorgen.

Professionelle Rahmenbedingungen

  • Berechtigungen müssen neben allgemeinen Rollen auch die konkrete Zuordnung zu einer Gesellschaft berücksichtigen.
  • Fahrzeitbasierte Suchen über viele Start- und Zielpunkte dürfen externe Routing-Dienste nicht unkontrolliert belasten.
  • Größere Datenimporte brauchen Vorschau, Nachvollziehbarkeit und einen kontrollierten Übergang in den produktiven Datenbestand.
  • Karten-, Routing- und Importfunktionen mussten in klar getrennten, testbaren Komponenten zusammenspielen.

02 — Verantwortung

Meine Rolle

Ich habe die Plattform end-to-end konzipiert und umgesetzt: Benutzeroberfläche, Backend, Datenmodell und APIs, Karten- und Routing-Integration sowie Tests, Azure-Infrastruktur und Delivery.

  1. 01Konzeption und Umsetzung der Full-Stack- und Cloud-Architektur
  2. 02Entwurf von Autorisierung, Datenmodell, API-Grenzen und Integrationen
  3. 03Konzeption und Umsetzung von Routenplanung und fahrzeitbasierter Standortauswahl
  4. 04Tests für Berechtigungen, asynchrone Abläufe, Mapping und Fehlerfälle
  5. 05Azure-Infrastruktur, lokale Entwicklungsumgebung und Delivery-Prozess

03 — Umsetzung

Ansatz & Entscheidungen

Frontend, Backend, Datenzugriff und Infrastruktur erhielten klarere Grenzen. Besonders die Standortauswahl wurde als zweistufiger Prozess modelliert: Eine günstige geografische Vorauswahl reduziert zunächst die Kandidaten, bevor tatsächliche Fahrzeiten über eine Routing-Matrix verglichen werden.

D01

Fahrzeit statt Luftlinie

Die endgültige Reihenfolge geeigneter Standorte basiert auf realer Fahrzeit und Distanz. Eine Luftlinienberechnung dient nur zur effizienten Vorauswahl und wird transparent als Vergleichswert behandelt.

D02

Begrenzte externe Parallelität

Routing-Matrix-Aufrufe werden gebündelt, dedupliziert und in ihrer Parallelität begrenzt. Caching und kontrollierte Fehlerpfade reduzieren Kosten und verhindern, dass einzelne Ausfälle die gesamte Suche unbrauchbar machen.

D03

Serverseitige Gesellschaftsgrenzen

Token, Rolle und konkrete Gesellschaftszuordnung werden im Backend validiert. Die Oberfläche unterstützt die Arbeitsbereiche, ist aber nicht die Sicherheitsgrenze.

D04

Überprüfbare Importe

Excel-Daten werden zunächst validiert und als Vorschau aufbereitet. Erst danach startet ein asynchroner, statusbehafteter Import über Storage und Queue-Verarbeitung.

04 — Technologie

Technischer Rahmen

  • Vue 3
  • TypeScript
  • C#
  • .NET
  • Azure Functions
  • PostgreSQL
  • Microsoft Entra ID
  • Azure Maps
  • Bicep
  • Azure DevOps

05 — Rückblick

Ergebnis & Erkenntnisse

Aus den fachlichen Anforderungen entstand eine rollenbasierte, testbare Cloud-Anwendung. Integrierte Routenplanung und fahrzeitbasierte Standortauswahl machen vorhandene Standort- und Leistungsdaten direkt für operative Entscheidungen nutzbar.

Suche, Kartenansicht und Routenberechnung greifen auf denselben gepflegten Datenbestand zurück, während Bearbeitung und zentrale Administration klar getrennt bleiben.

  • L01Die nächstgelegene Ressource ist eine Routing-Frage; Luftlinie allein ist für operative Auswahl häufig irreführend.
  • L02Externe Karten- und Routing-Dienste brauchen Batching, Begrenzung, Caching und explizite Fehlerstrategien.
  • L03Dezentrale Datenpflege funktioniert nur mit serverseitig durchgesetzten fachlichen Zuständigkeitsgrenzen.
  • L04Fachliche Suche, Datenpflege und Routing profitieren von einer gemeinsamen Architektur statt getrennter Einzellösungen.