© Stmool/Shutterstock.com
Kolumne: Stropek as a Service

Kolumne: Stropek as a Service


Entwicklerinnen und Entwickler lieben Abstraktionsschichten. Schnittstellen und abstrakte Basisklassen, Dependency Injection, Factories – diese Liste an Mechanismen zur Entkopplung von Komponenten und zum Abstrahieren von konkreten Implementierungen könnte man lange fortsetzen. Wie bei Zwiebeln stapeln sich Schichten über Schichten, damit alles im Fall des Falles ausgetauscht werden kann. Anstatt aber mein Softwarearchitektenherz höher schlagen zu lassen, bringen mich solche Zwiebeln oft zum Heulen. Wir vergessen bei der Softwareentwicklung manchmal, dass der Aufbau des Codes auch zur Größe und Komplexität des Projekts passen muss. In dieser Ausgabe meiner Kolumne möchte ich zum Hinterfragen von Abstraktionsschichten anregen. Starten wir, indem wir einige Gründe für die vielen Abstraktionsschichten beleuchten.

Lock-in-Effekt

Jeder, der längere Zeit in der Softwareentwicklung tätig war, kann Geschichten davon erzählen, wie Bibliotheken, Frameworks, Programmiersprachen oder Tools, die man tief in die eigene Lösung integriert hatte, einen mehr oder weniger schnellen Tod gestorben sind. Plötzlich saß man da mit einer Menge Code, in den die nicht mehr gewartete Komponente fest verwoben war. Die Alternativen in so einer Situation sind alle unangenehm. Ausbauen bedeutet eine Menge Arbeit, ohne dass die Kunden funktional einen Vorteil sehen. Nichts tun klappt vielleicht eine gewisse Zeit, ist aber keine Dauerlösung.

In Zeiten von Cloud und PaaS ist die Lage noch verzwickter. Wenn der Anbieter eines Service entscheidet, ihn einzustellen, kann man nicht auf Zeit spielen. Der Service wird irgendwann einfach verschwinden und die eigene SaaS-Lösung mit in die Tiefe reißen. Im Gespräch mit Entscheidungsträgern wird auch häufig die Angst vor Preisänderungen bei Cloud-Services als Grund genannt, warum man immer bereit für einen Wechsel sein sollte.

Es ist die Angst vor dem Lock-in-Effekt, der dazu führt, dass wir Software so schreiben wollen, dass wir Komponenten leicht austauschen können. Wenn es zum Fall der Fälle kommt, soll uns der Wechsel keine große Mühe machen – das wäre zumindest der Plan …

Isolieren von Änderungen

Manche Teams versuchen, sich durch Abstraktionsschichten vor Änderungen in der eigenen Software zu schützen. Das Ziel ist, dass man Module austauschen oder überarbeiten kann, ohne den Rest der Software anfassen zu müssen. Das soll den Aufwand für das Testen und das Risiko des Einschleichens von Fehlern reduzieren.

In der Cloud geht man noch einen Schri...

Exklusives Abo-Special

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang