Die Softwarearchitektur beschreibt die grundsätzliche Struktur eines Softwaresystems. Ähnlich wie beim Bau eines Hauses wollen wir auch bei der Architektur der Matching-Plattform nichts dem Zufall überlassen. Eine Schichtenarchitektur bietet uns die nötige Flexibilität.

Wenn ein Kleinkind einen Turm aus Bauklötzen stapelt, dann geht dem selten eine große Planung voraus. Das Kind legt einfach los und setzt Stein auf Stein – solange bis der Turm einstürzt. Vielleicht wird der kleinste Stein oder der Klotz mit dem orangenen Muster, das an Ziegelsteine erinnert, ganz oben aufgesetzt, vielleicht aber auch nicht. Anders gehen da die Älteren vor, wenn sie Spieltürme bauen oder gar richtige (Wohn-)Häuser errichten. Eine durchdachte Planung vor der Umsetzung ist hier die Regel.

Ähnlich verhält es sich mit Softwareprodukten. Es gibt solche, die ohne Vorabplanung entstanden und gewachsen sind. Es gibt aber auch solche, bei denen die Architektur zunächst einen gründlichen Abwägungs- und Entscheidungsprozess durchlaufen hat. – Moment, Architektur? Ja! Neben dem Bauwesen wird der Begriff auch im Bereich der Softwareentwicklung verwendet.

Die Softwarearchitektur sagt aus, welche Bestandteile ein System besitzt und wie diese zueinander angeordnet sind.¹ Eine sorgsame Überlegung vorab erspart aufwendige Anpassungen hinterher. Dabei muss beachtet werden, dass die Softwarearchitektur einen hohen Einfluss auf nicht-funktionale bzw. Qualitätsmerkmale einer Software hat², also z.B. auf Sicherheit und Wartbarkeit. In der Literatur findet man zudem verschiedene Prinzipien, die für den Entwurf einer Softwarearchitektur herangezogen werden können.³

Bei MPASS haben wir uns an einem bewährten Architekturmuster orientiert. Architekturmuster sind so etwas wie Vorlagen, die den Stil der Architektur darstellen⁴. Wir greifen für die Matching-Plattform auf ein Schichten-Muster⁵ zurück, das eine hierarchische Architektur beschreibt. Softwarefunktionalitäten werden hier also getrennt voneinander auf mehreren Ebenen bzw. Schichten implementiert, was Vorteile, aber auch Nachteile mit sich bringt.

Aber zunächst wollen wir die einzelnen Schichten der Softwarearchitektur bei MPASS erläutern und fangen dabei ganz unten an: Die erste Schicht ist die Datenhaltungsschicht. Hier werden alle Daten von Hochschulen, Ansprechpersonen, Projekten usw. in einer Datenbank abgelegt. Wie dies geschieht, nämlich mittels Graphen, das haben wir bereits in einem anderen Blogbeitrag gezeigt.

Auf die Datenhaltungsschicht folgt die Anwendungsschicht (auch Geschäftslogik). Sie dient als Schnittstelle zum systematischen Abruf der Daten. Mittels Algorithmen werden hier die entsprechenden Empfehlungen für Nutzerinnen und Nutzer aus der Datenbank generiert.

Ganz oben befindet sich die Präsentationsschicht. Sie greift auf die Dienste (und Ergebnisse) der Anwendungsschicht zurück und sorgt dafür, dass die Daten für Nutzerinnen und Nutzer ansprechend dargestellt werden. Dies geschieht mit einer grafischen Webschnittstelle. Es wird also eine Webseite geschaffen, die Nutzerinnen und Nutzer dann in ihrem Internetbrowser aufrufen können.

Was bringt uns in MPASS nun aber eine Schichtenarchitektur? Zum einen können die Schichten unabhängig voneinander entwickelt werden. Das ist hilfreich, wenn z.B. unser Entwickler und studentische Hilfskräfte an unterschiedlichen Stellen im System arbeiten. Zum anderen – und das ist der wichtigste Aspekt – sind einzelne Softwarekomponenten unabhängig voneinander anpassbar und austauschbar.⁶ 

Ein Beispiel könnte die Anpassung der Präsentation sein. Stellen wir uns vor, eine Hochschule würde die Matching-Plattform (oder einen Teilbereich davon) zusätzlich auf ihrer Hochschulwebseite integrieren wollen. Dann wäre es theoretisch möglich, dass die Inhalte der Matching-Plattform hier entsprechend dem Corporate Design der Hochschule dargestellt werden. Weiterhin wäre es denkbar, die Inhalte der Matching-Plattform neben der Webseite auch in einer App zu präsentieren. Diese greift dann ebenfalls auf die vorhandene Datenhaltungs- sowie die Anwendungsschicht zu.

Natürlich existieren auch Nachteile in Verbindung mit einer Schichtenarchitektur. Neben einem erhöhtem Entwicklungsaufwand müssen Daten über mehrere Schichten überführt und manche Änderungen in allen Schichten vorgenommen werden.⁷ Dennoch ist für uns die Schichtenarchitektur die beste Wahl für die Matching-Plattform. Gehören doch Anpassbarkeit und Skalierbarkeit zu den wesentlichen Erfolgsfaktoren für die Verstetigung eines Softwaresystems.⁸ Und da noch nicht feststeht, in welcher Form die Matching-Plattform nach Projektende fortgeführt wird, bietet die gewählte Schichtenarchitektur genügend Flexibilität.

¹ vgl. Balzert, Helmut (2011): Lehrbuch der Softwaretechnik. Entwurf, Implementierung, Installation und Betrieb. 3. Aufl. (Lehrbücher der Informatik): Spektrum Akademischer Verlag. Heidelberg, S. 23, 580.
² vgl. Hasselbring, Wilhelm (2006): Software-Architektur. In: Informatik Spektrum, 29. Jg., Nr. 1, S. 48-52, S. 48.
³ vgl. Balzert, Helmut (2009): Lehrbuch der Softwaretechnik: Basiskonzepte und Requirements Engineering, 3. Aufl. (Lehrbücher der Informatik): Spektrum Akademischer Verlag. Heidelberg, S. 25ff.
⁴ vgl. Hasselbring (2006), S. 48.
⁵ vgl. Balzert (2011), S. 46; Buschmann, Frank/Meunier, Regine/Rohnert, Hans/Sommerlad, Peter/Stal, Michael (1996): Pattern-Oriented Software Architecture. A System of Patterns, 1. Aufl.: John Wiley & Sons. New York.
⁶ vgl. Balzert (2011), S. 46f., 53.
⁷ vgl. Balzert (2011), S. 53.
⁸ vgl. Markus, M. Lynne/Tanis, Cornelis (2000): The Enterprise System Experience—From Adoption to Success, In: Zmud, R. W. (Hrsg.): Framing the Domains of IT Research: Projecting the Future through the past, Cincinnati: Pinnaflex Educational Resources Inc., S. 173–207, S. 191ff.; Singh, Shikha/Misra, S. C. (2018): Success Determinants to Product Lifecycle Management (PLM) performance, In: 5th International Conference on Industrial Engineering and Applications (ICIEA), 2018, S. 386-390, S. 386ff.