Odyssee im Programmierraum?

Usecase veraltete Software

Ein typischer Fall aus der Praxis

Ein Unternehmen aus dem B2B-Bereich arbeitet mit einer monolithisch Softwarelandschaft. Jede kleinste Änderung zieht viele Probleme nach sich.

Beispiel: Durch neue Businessanforderungen müssen neue Features in das System eingebracht werden, was dazu führt, dass der gesamte Monolith ausgerollt werden muss. Dieser Entwicklungsprozess ist sehr zeitaufwändig und fehleranfällig, da an vielen Stellen etwas schief gehen könnte – und tatsächlich schiefgeht. Deshalb wird dieser Vorgang nicht so häufig ausführt, was zur Folge hat, dass neue Features nicht zeitnah eingeführt werden.

Hinzu kommt ein weiteres typisches Problem. Die IT-Abteilung hat viele Kopfmonopole. Viele Mitarbeiter wissen nichts von den Entwicklungsaktivitäten ihrer Kollegen. So entstehen Insellösungen und hohe Abhängigkeiten, die es schwer machen, die Softwarearchitektur schneller (performanter) und skalierbar zu gestalten. Die vorhandene Hardware und die Software können erhöhte Datensätze nicht bewältigen. Auch neue Compliance-Regeln sind mit Insellösungen nicht umsetzbar.

So findet Release42 maßgeschneiderte Lösungen

  1. In so einem typischen Fall sehen wir uns zunächst die vorhandene Softwarelandschaft an.
    1. Welche Komponenten sind im System vorhanden? Wie arbeiten diese zusammen? Wie hängen sie voneinander ab? Welcher Datendurchsatz erfolgt zu welchen Zeiten?
    2. Welche offensichtlichen Risiken sind sofort erkennbar – bei Lizenzen, Wartungen, Sicherheitsvorkehrungen und Compliance-Auflagen? Was ist bereits umgesetzt worden? Was fehlt noch?
    3. Wir prüfen, welche Komponenten im Gesamtsystem ausfallen könnten. Falls ein Teil ausfällt, sollte dieser Part in der Regel von einem anderen Part übernommen werden können. Wir ermitteln, wo es Mängel in den Redundanzen gibt und zeigen sämtliche Risiken zeigen auf.
  2. Das weitere Vorgehen muss zur Unternehmenskultur passen. Deshalb schauen wir uns die internen Aufstellungen und Gepflogenheiten an.
    1. Welche Mitarbeiter arbeiten vor Ort? Welche fachlichen Fähigkeiten sind vorhanden? Wie arbeiten die Kollegen zusammen?
    2. Oftmals kümmert sich jeder nur um seinen eigenen Bereich.
    3. Häufig arbeitet die interne IT-Abteilung gegen die Fachbereiche und umgekehrt.
    4. Erfreulich ist hingegen, wenn es im Unternehmen bereits Projektteams gibt, die an Lösungen arbeiten.
  3. Sobald die Geschäftsführung grünes Licht gibt, definieren wir, wie die Zielarchitektur aussehen soll.
    1. Hierzu erstellen wir zunächst einen Company Backlog, der die Arbeitsrückstände und bisherigen Prozesse illustriert.
    2. Dies erarbeiten wir am liebsten in Form eines Workshops gemeinsam mit den Mitarbeitern der Firma.
    3. Dann entwickeln wir Stories, die aufzeigen, was entwickelt werden muss und wie künftige Prozesse laufen sollen.
    4. Hierfür achten wir darauf, dass die Möglichkeiten von Cloud Services voll ausgenutzt werden.
    5. Selbstverständlich implementieren wir frühzeitig Kennzahlen (KPIs) und Monitoring-Maßnahmen, mit Hilfe derer Anwendungen überwacht und im Notfall korrigiert werden können.
    6. Wir achten stets auf eine einfache Wartung und flexible Anpassbarkeit. Es soll ja kein neuer Monolith entstehen.

Unsere Umsetzung

Unserer Erfahrung nach hat es sich bewährt, agile Projektteams nach dem Prinzip der DevOps zu bilden. In diesen Teams werden alle Personen vereint, die für das Projekt benötigt werden, d.h. Mitarbeiter des Kunden (Project Owner) und unsere Entwickler.

So schaffen wir maximale Transparenz auf allen Ebenen.

Wichtig ist, dass ein hoher Automatisierungsgrad für die Entwicklung und bei den Tests geschaffen wird. Das ist eine Grundvoraussetzung für schnelle Release-Zyklen und ein hohes Feature Output in hoher Qualität.

Wir versuchen, alles so schlank und agil wie möglich zu halten, damit die Firma künftig kurzfristig auf Veränderungen in den Geschäftsprozessen reagieren kann. Ziel ist, dem Kunden jederzeit auf Knopfdruck ein stabiles Release mit anschließendem Review zu ermöglichen, um im Nachgang zu reflektieren, was gut läuft und was verbessert werden muss. Diese agile Denk- und Arbeitsweise ist wichtig, um regelmäßig den IST-Zustand eines Unternehmens zu hinterfragen und optimieren zu können. So lässt sich frühzeitig eine solide Qualitätssicherung etablieren.