Anforderung ‐ Externer Anbieter als Datenquelle

Grundlagen

Der aktuelle Stand unserer Anwendung sieht lediglich eine externe Anbindung zu einer Wetter API vor. Daten wie Stundenpläne, Noten, Mensapläne etc. werden in unserem Backend erstellt, in unserer Datenbank gespeichert und werden von unserem Backend ebenfalls dem Frontend zur Verfügung gestellt. Dadurch haben wir eine vollständige Kontrolle über unsere Daten und sind auf keinen externen Anbieter angewiesen.

Neue Anforderung

Die neue Anforderung sieht jedoch einige Änderungen vor. Es soll ein externer Partner angebunden werden, der Daten wie Stundenpläne, Mensapläne etc. zur Verfügung stellt, auf das sich unser Backend beziehen soll. Dies würde einige Änderungen in unserer Architektur vorsehen, die hier besprochen und evaluiert werden.

Stundenpläne

Bei den Stundenplänen ist es wichtig zu wissen, ob diese vom externen Partner lediglich einmal pro Jahr (z.B. kurz vor Schuljahrbeginn) erstellt werden und dann nichtmehr verändert werden, oder ob diese auch während des Schuljahres gepflegt werden. Bei ersterem müsste sich unser Backend einmal pro Schuljahr die Stundenpläne ziehen und dann wieder auf unserer Datenbank speichern. Dadurch sparen wir uns das erstellen, kümmern uns aber immernoch selbstständig um die Aktualität bei Ausfällen von Lehrern oder Stunden generell. Bei letzterem könnte man sich sogar überlegen, das Backend bei dem Teil der Anwedung vollständig zu überbrücken. Wenn die Datenformate passen und der externe Partner vernünftige Schnittstellen bietet, könnte unser Frontend direkt auf diese zugreifen. In diesem Fall ist aber auch notwendig zu wissen, wie und wo Daten über Lehrer und Kurse gespeichert sind. Sind diese nicht beim externen Partner gespeichert, ist hier widerum eine Backend Komponente notwendig, die die Stundenpläne vom externen Partner mit den Daten der Lehrer und Schüler von unserer Datenbank verknüpft und dem Frontend vernünftig aufbereitet.

Zum jetzigen Zeitpunkt wäre das eine Veränderung, die auf jedenfall möglich ist und lediglich ein wenig Anpassung an unserer Architektur erfordert. Das liegt vorallem daran, dass die Idee unserer Anwendung ist, Stundenpläne zwar bei uns zu Speichern und zu pflegen, allerdings ist bei uns keine Methode vorgesehen, die Stundenpläne automatisch erstellen lässt. Für diesen Schritt würde bei produktiver Nutzung ein anderes Tool verwendet werden, wie zum Beispiel ein externer Partner.

Schüler- und Lehrerdaten

Wichtige Daten über Schüler und Lehrer werden bei uns ebenfalls im Backend gepflegt und auf unserer Datenbank gespeichert. Hier kommt es darauf an, wie viele Daten von Schülern und Lehrern gespeichert werden. Hierfür unterscheiden wir zwei unterschiedliche Fälle.

Fall 1: Daten von Schülern/Lehrern ohne weitere Informationen werden von einem externen Anbieter übernommen

Dieser Ansatz ist nicht sehr sinnvoll, wenn Daten für Schüler und Lehrer bei einem externen Anbieter liegen, können Verbindungen zu restlichen Daten schwer erstellt werden. Um dies weiter zu gewährleisten wäre trotzdem eine Entität notwendig, um einem Schüler seine Klasse, und damit verbundene Daten, anzeigen zu können. Wenn eine Entität für den Schüler existiert, können Daten auch direkt dort gespeichert werden. Eine extra Verbindung zu einem Dienst würde die Architektur nur verkomplizieren und die Wartung des Produkts aufwändiger gestalten (falls der Anbieter Änderungen an am Service vornimmt), bzw. vielleicht sogar gefährden, falls der Service nicht mehr angeboten wird.

Fall 2: Daten von Schülern/Lehrern und auch deren zugehörigen Daten (Klasse, Jahrgang) werden von einem externen Anbieter übernommen

Wenn Daten über Jahrgänge, Klassen, Schüler und Lehrer an einen externen Service abgegeben werden, müssten auch hier zwei Entitäten für Lehrer und Schüler erstellt werden, um nötige Verbindungen zu erstellen, für u.a. den Stundenplan oder Noten. Jedoch würden dann andere Entitäten eingespart werden, was die Architektur vereinfachen würde.

Noten

Die Noten, bzw. die Bewertungen der Schüler durch Lehrer generell ist eine kritische Komponente. Hier muss vorallem der Datenschutz gewährleistet werden. Wenn die Daten von Lehrern und Schülern schon beim externen Partner gespeichert werden, könnten wir evaluieren, auch Noten bei diesem Partner zu speichern. Eine Speicherung von Noten auf unserer Datenbank wäre aber auch möglich, wenn Lehrer und Schülerdaten nicht direkt bei uns gespeichert werden. Hier würden wir es bevorzugen, Noten selber zu speichern, um selbstständig Kontrolle über diese Daten zu behalten. Sollten wir uns jedoch dazu entscheiden, die Noten ebenfalls beim externen Partner zu pflegen, kann auch hier überprüft werden, ob unsere Backend Komponente vollständig entfernt werden kann.

Mensaplan

Die wahrscheinlich einfachste Änderung ist der Teil des Mensaplans. Da dies keine sensiblen Daten sind, muss hier nicht viel beim Datenschutz beachtet werden. Wie auch bei den anderen Komponenten muss bewertet werden, in welcher Art und Weise der Mensaplan zur Verfügung gestellt wird. Passen die Schnittstellen, kann unsere Backend Komponente vollständig weggelassen werden und unser Frontend könnte sich den Mensaplan direkt vom externen Partner ziehen. Eine separate Speicherung des Mensaplans auf unserer Datenbank wäre dadurch nichtmehr notwendig, was unsere Architektur vereinfachen würde.

Zusammenfassung

Es sollte jeder Teil unserer Anwendung betrachtet und bewertet werden. Gerade bei sensiblen Daten über Lehrer und Schüler muss genauer hingeguckt werden. Je nach Ausmaß der Funktionalitäten unseres externen Partners könnten jedoch einige Teile unseres Backends entfernt werden, was unsere Architektur erheblich verkleinern würde. Zum jetzigen Zeitpunkt wäre dies eine deutliche Vereinfachung des Implementationsaufwands im Backend. Für das Frontend würde sich lediglich die Quelle der Daten verändern. Es sollte aber trotzdem in Betracht gezogen werden, ob ein eigenes Backend als "Zwischenkomponente" sinnvoll wäre. Diese könnten dann die Daten des externen Partners vernünftig aufbereiten und unserem Frontend passend zur Verfügung stellen.

Notwendige Aufgaben

• Bewertung der Schnittstellen des externen Anbieters
• Bewertung des Umfangs des externen Anbieters
• Anpassung der Architektur durch z.B. Entfernen eigener Komponenten
• Im Falle einer guten und vollständigen Funktionalität des externen Partners: Evaluierung der Notwendigkeit einer eigenen Datenbank