Technical Debt Reduzieren

Die Modernisierung von Digitalen Diensten oder der darunter liegenden Platform ist ein Thema, dass viele Firmen betrifft. Wie entscheidet man, was man und wann man hier investieren sollte? Denn dabei riskiert man immer Kunden zu verlieren, da sich die Feature Roadmap verzögern wird - teilweise deutlich. 

Vielleicht fragen Sie sich?

  • Sind wir auf einer veralteten Architektur?

  • Leidet unser Entwicklungsgeschwindigkeit?

  • Ist unsere Qualität gefährdet?

  • "Ich kann das Wort "Refactoring" nicht mehr hören" !?

Projektanspruch

Ein digitaler Dienst oder Plattform befindet sich in der Sackgasse. Große Investitionen sind notwendig.

Wie transformiere ich den Technologie um wieder handlungsfähig zu werden?

Ergebnisse:

  • Realistische Aufwandsabschätzung

  • Build-vs-Buy-Entscheidung

  • Umsetzungsplanung

Methoden:

  • Best-Practice Prozesse

  • Cloud/OnPremise, IoT, KI

  • Technologieauswahl

Viele Unternehmen häufen technischen Modernisierungsbedarf über Jahre an, anstatt kontinuierlich in die Architektur und eine moderne Entwicklungs- und Betriebslandschaft zu investieren. 

Was können Ursachen sein? Einblicke aus der Praxis…

Der Digitale Dienst ist ein beinahe unwartbarer Monolit 

Der Vertrieb macht Druck. Neue Features werden benötigt, um das Produkt am Markt erfolgreich zu machen. 

Dabei wird die benötigte Investition in eine verbesserte Architektur immer wieder zurück gestellt. 

Ergebnis: Das Produkt wird mit der veralteten Architektur immer weiter erweitert. Der benötigte Umbauaufwand wird immer höher. Zusätzlich sinkt die Entwicklungsgeschwindigkeit immer weiter, da es immer komplizierter wird, das Produkt zu erweitern und zu warten. 

Die Aufwände für das Beheben des Technical Debt sind zu hoch

Das Entwicklungsteam wird gefragt, den Aufwand für die benötigte Investition in die Technologie abzuschätzen. Dem Management erscheint dies zu hoch. Also wird das Team gebeten, einen günstigeren Weg zu finden oder niedriger zu schätzen. 

Neue Pläne werden zwar vorgelegt, aber nicht begonnen, da das Team nicht wirklich dahinter steht und immer neue Hindernisse auftauchen. Solange wird weiter an neuen Features gearbeitet. 

"Not invented here"

Die benötigte Investition wird nur aus dem Blickwinkel einer Eigenentwicklung geplant (vielleicht mit Open Source-Komponenten). Eine Build-vs-Buy Entscheidung wird nicht objektiv getroffen, da Fremd-Komponenten nicht vertraut wird und die Einarbeitung in diese Überschätzt wird - im Vergleich zum Unterschätzen des Einarbeitungsaufwands in Open Source. 

Die Lösung erarbeiten

Die Reduzierung von von großem Technical Debt ist keine triviale Situation. Feature-Entwicklung einstellen oder parallel auch die Feature-Roadmap abarbeiten?

Wie gelingt dies? Einblicke in Lösungsstrategien

Die richtige Balance finden 

Um ein Produkt nachhaltig über Jahre so weiterzuentwickeln, dass es zu keinem zu hohem Technical Debt kommt, muss das gesamte Team die Balance zwischen Feature Entwicklung und technologischem Investment beherrschen. 

Hierfür gibt es mehrere Methoden, die die DVC-Partners© den Teams weitergeben können. 

Grundlegend ist die enge Zusammenarbeit von Produktmanagement, Product Ownern und Architekten, die gemeinsam den Backlog priorisieren, damit die technischen Nöte des Entwicklungsteams gehört und umgesetzt werden. 

Dr. Liebau hat diesen Prozess mehrfach erfolgreich verantwortet und auch die Teams erfolgreich gecoacht, damit sie weiterhin selbstständig nachhaltig arbeiten. 

Eine ehrliche Aufwands-abschätzung

Die Aufwandsschätzung der benötigten technischen Investition wird häufig auch als politisches Thema wahrgenommen. Damit kommt es häufig zu verfälschten Ergebnissen.

Wichtig ist eine vertrauensvolle Diskussion mit den verantwortlichen Architekten und Experten, um auch Alternativen zu suchen und diese zu bewerten. Durch langjährige ganzheitliche Produktverantwortung haben DVC-Partners© die technische Expertise und Erfahrung, diese Diskussion mit den Teams zu führen. 

Objektive Build-vs-Buy Entscheidung

Dr. Liebau hat bereits mit vielen Entwicklungsteams zusammengearbeitet. Gerade diese vertrauen häufig mehr den eigenen Fähigkeiten als externen Komponenten. 

Dr. Liebau hilft zunächst objektiv die Frage zu stellen, was der wirkliche Mehrwert ist, der dem Kunden geschaffen werden soll.

Als zweites, mit welchen darunter liegenden abstrakten digitalen Diensten man diesen technisch erzeugt. 

Damit hilft Dr. Liebau bei der objektiven Build-or-Buy Entscheidung. 

So hat Dr. Liebau es z.B. bei FactoryPal geschafft, innerhalb von nur wenigen Monaten mit einem kleinen Team einen komplett neuen, flexiblen Analyse-Dienst auf Basis von IT und OT Daten Multi-Tenant zu liefern. 

Wie bauen wir erfolgreich um?

Auch muss ein Umbau nicht immer in einem großen Schritt passieren. Welcher Schritt schafft den größten Mehrwert für das Entwicklungsteam?

Dr. Liebau hatte z.B. folgenden Umbau erfolgreich gemanagt: Die Altarchitektur stammte noch aus der PoC-Phase des Produkts. Nun wurde auf eine Micro-Service-basierte Architektur umgebaut, die skalierbar und erweiterbar ist und mit der die Entwicklungsaufwände für neue Features deutlich gesunken sind. Dabei wurden die Kunden-erwartungen so gemanagt, dass alle Kunden gehalten wurden.

Zusätzliche Hilfe holen

Um den Umbau zu stemmen, könnte auch externe Unterstützung gesucht werden: Consulting-Firmen oder Freelancer. Doch häufig wollen die Teams keine Hilfe. Warum? Wie kann man sie doch überzeugen?

Wie stellt man hier den Erfolg sicher? Die Kosten sind hoch. 

Es gibt verschiedene Optionen und Aspekte zu bedenken: Lokation, Skill-Set, Seniorität, Rollen.

Wie stelle ich sicher, dass die Hilfe auch möglichst schnell produktiv wird? 

Dr. Liebau solche Situationen mehrfach erfolgreich gemanagt, aber auch aus anfänglichen Fehlschlägen gelernt. 

Eine Migration muss funktionieren!

Falls doch ein großer Umbau durchgeführt wird, kommt der Zeitpunkt der Kundenmigration. Eine "Operation am offenen Herzen", bei der nichts schief gehen darf.

Dr. Liebau Erfahrung mit solchen Situationen und helfen diesen Prozess erfolgreich zu managen. So hat Dr. Liebau z.B. bei SAP die Migration der IoT Daten von einer SAP-Datenbank auf den neu entwickelten Big-Data-Stack erfolgreich gemanagt.

Das können Sie erwarten

  • Technische Statusanalyse des Produkts

  • Vorschläge zur architektonischen Umsetzung der Modernisierung

  • Realistische Einschätzung des Aufwands der Modernisierung

  • Coaching der Product-Owner bezüglich nachhaltiger Backlog-Priorisierung

  • Coaching des Produktmanagement-Teams bezüglich langfristig und nachhaltiger Produktplanung

  • Planung und Durchführung von kritischen Systemmigrationen