Das Ende der monolithischen Unternehmens-Software

Development Geschrieben von Alexander Onea

Seit Einführung der diversen App Stores in den letzten Jahren unter dem Motto „There’s an app for that“ ist in 2015 auch in Unternehmen endgültig klar, dass die eierlegende Wollmillch-„Unternehmens-Applikation“ tot ist und dem Einzug von vielen, spezialisierten Einzelsystemen gewichen ist.

Alexander Onea

Das Ende der monolithischen Unternehmens-Software

Signifikante Vorteile

Gegenüber monolithischen Systemen haben voneinander unabhängige Apps signifikante Vorteile. Wenn es für jeden Prozess das spezialisierte Werkzeug gibt, welches fokussiert die Abbildung eines bestimmten Anwendungsfalls erlaubt, lässt sich der Umfang genau definieren, testen und umsetzen.

Durch die insgesamt geringere Komplexität (eine fokussierte Applikation bildet typischerweise weniger Use Cases ab) kann man die Updatehäufigkeit schneller dem Bedarf anpassen.
Der Betrieb von mehreren voneinander unabhängigen Applikationen wirken sich Ausfälle erheblich weniger stark auf den Betrieb aus, denn sie betreffen typischerweise nicht das gesamte Unternehmen sondern lediglich die Nutzer, die direkt mit der ausgefallenen Applikation zu tun haben.

Neue Möglichkeiten

Durch die heutige Tool-Landschaft ergeben sich neue Möglichkeiten im Umgang mit Applikationen: Vom erleichterten Evaluationsprozess bei Make- or Buy-Entscheidungen bis zum günstigen Parallelbetrieb ähnlicher Systeme, um zum Schluss das bessere System zu behalten.

Folgen

Wartung und Pflege vieler verschiedener Applikationen birgt allerdings auch Herausforderungen. Statt eines Backups sind jetzt intelligente Systeme notwendig, die für jedes benutzte System Backups ermöglichen.
Wo früher ein Datenbanksystem vorhanden war, sind es jetzt hunderte. An allen Stellen, an denen sich ein Prozess über verschiedene Applikationen und Prozesse verteilt, stehen wir in der Pflicht, dafür zu sorgen, dass unsere Nutzer die wichtigen Daten nicht mehrfach eingeben müssen.

Wenn es um Datensicherheit und Datenschutz geht, gehört es immer mehr zu unserer Pflicht, die einzelnen Sytsteme stark zu kontrollieren, und jeweils zu prüfen und nachzuvollziehen, welche Informationen zu welchem Zeitpunkt wie lange in welchem System vorhanden sind. Durch die hohe Anzahl an Schnittstellen zwischen den Systemen steigt die Wahrscheinlichkeit, dass „irgendwas“ schief läuft. Unser Ziel ist es immer, möglichst schnell Probleme festzustellen und zu beheben.

Wie wir damit umgehen

Wir betrachten die verschiedenen Applikationen als Netz von Komponenten. Diese Einzelkomponenten können über wohldefinierte Schnittstellen miteinander verbunden werden.
Indem wir sicherstellen, dass der Datenaustausch regelmäßig und konsistent stattfindet, können wir vermeiden, dass unsere Nutzer ihre Daten mehrfach eintragen müssen.
Allerdings ist das Datenflussmanagement keine triviale Aktivität. Für jeden Datensatz muss sichergestellt werden, dass der Umgang mit Erstellung, Update und Löschung gewährleistet ist.
Als Tool für das zeit- und ereignisgetriebene Steuern von Datenmanagement-Jobs setzen wir aktuell Jenkins ein. Dies gibt uns die Möglichkeit, für einzelne Prozesse Pipelines zu verwenden, die sich einzeln modellieren lassen. So haben wir die Möglichkeit, an einer Stelle die einzelnen Prozesse zu verwalten und über mehrere Tage und Wochen hinweg das Vehalten der Applikationen zu überwachen und zu loggen.
Durch die Implementierung von Continuous Delivery-Prozessen für alle unsere Softwarekomponenten behalten wir uns die Möglichkeit, Updates so häufig wie nötig einzuspielen, manchmal mit mehreren Updates am Tag.

Wir stellen sicher, dass alle Schnittstellen ähnlichen Standards genügen: IP-basierte Firewalls, SSL only für jeden Datentransfer und rollenbasierte Authentifizierung und Autorisierung für automatisierte Datenzugriffe.
Dadurch können wir an jeder Stelle nachvollziehen, welche Daten wann wohin fließen.

Dies gibt uns jetzt auch die neue Möglichkeit, überall wo es notwendig ist, einerseits unsere Kunden und andererseits unsere Zulieferer und Freelancer in die Prozesse einzubeziehen und ihnen Zugriff auf unsere Apps zu geben.

Wenn Sie auf der Suche nach einer App sind, die ein bestimmtes Problem löst, haben wir – anders als früher – die Möglichkeit zu sagen: „There’s an app for that“.