Wie mit der richtigen Plattform-Entwicklung echter Mehrwert bei Softwareprojekten erzielt werden kann
Software ist mehr als eine Frage der IT. Sie ist mittlerweile von strategischer Bedeutung für das gesamte Unternehmen. Zunehmend entscheidet die richtige Software-Entwicklungsstrategie nicht nur über das Schicksal eines einzelnen Softwareprojekts, sondern über den langfristigen Erfolg der gesamten Organisation. Technologie ist von der Peripherie ins Herzstück von Unternehmen gerückt. In der Analyse, der Implementierung und dem Betrieb von Applikationen sehen sich Unternehmen immer wieder mit ähnlichen Fragen und Abwägungen konfrontiert. Damit aus Herausforderungen keine Überforderung wird, sollten Unternehmen sieben entscheidende Kriterien beachten, mit deren Hilfe sie den passenden Ansatz zur Plattform-Entwicklung finden können.
1. Greenfield vs. Legacy
Unternehmen verfügen heute über gewachsene Systemlandschaften. Sie stehen oft vor der Wahl: Soll man eine Greenfield-Strategie verfolgen und eine neue Plattform „auf der grünen Wiese“ entwickeln? Oder ist es besser, eine Legacy-Strategie zu verfolgen und die Plattform direkt in die bestehende IT-Landschaft zu integrieren?
Bei einem Greenfield-Ansatz beginnt das Projekt praktisch bei null. Dies bietet die Möglichkeit, eine maßgeschneiderte Applikation zu entwickeln, die auf den aktuellen und zukünftigen Anforderungen des Unternehmens basiert. Sie ermöglicht maximale Flexibilität und Skalierbarkeit, da es keine Einschränkungen durch bestehende Systeme oder Technologien gibt. Der Greenfield-Ansatz ermöglicht zudem die Integration neuester Technologien und Innovationen, die beispielsweise die Customer Experience verbessern und Wettbewerbsvorteile bieten. Bei Greenfield-Projekten treten Herausforderungen insbesondere bei der Datenmigration auf, vor allem wenn große Mengen an Kundendaten und Transaktionshistorie aus bestehenden Systemen übertragen werden müssen.
Ein Legacy-Ansatz beinhaltet hingegen die Integration in oder den Ausbau von bestehenden Systemen und Technologien. Dies kann oft einen schnelleren Weg zur Markteinführung bieten, da auf bestehende Infrastrukturen aufgesetzt wird. Das kann jedoch Herausforderungen hinsichtlich Skalierbarkeit und Flexibilität bedeuten, besonders wenn die bestehende Infrastruktur technologisch in die Jahre gekommen ist und in zu großem Maße nicht mehr den neuen Anforderungen entspricht.
Die Entscheidung zwischen Greenfield und Legacy sollte daher sorgfältig auf der Grundlage von Faktoren wie den langfristigen Zielen des Unternehmens, den Kundenanforderungen, der verfügbaren Technologie und den Ressourcen sowie der Zeitleiste für die Markteinführung getroffen werden.
2. Weiterentwickeln vs. Austauschen
Damit einher geht eine weitere Schlüsselentscheidung: zwischen Weiterentwicklung und Optimierung einer bestehenden Plattform und dem potenziellen Wert und den Vorteilen einer neuen Plattform. Hierbei sollten Unternehmen die Gesamtkosten des Lebenszyklus (Total Cost of Ownership, TCO) gegenüber den erwarteten Geschäftsvorteilen einer neuen Plattform abwägen.
Die Performance und Zuverlässigkeit des bestehenden Systems ist ein entscheidender Faktor. Wenn die aktuelle Plattform ihre Aufgaben effizient und ohne Ausfallzeiten erfüllt, spricht dies eher dafür, das bestehende System weiterzuentwickeln. Andererseits kann ein neues System mehr Leistung und Zuverlässigkeit bedeuten. Wenn das bestehende System bereits veraltet ist oder technische Probleme aufweist, sollte über eine neue Plattform nachgedacht werden.
Anpassbarkeit und Flexibilität sind hier wichtig. Kann das aktuelle System leicht an neue Anforderungen und Änderungen angepasst werden? Ist es möglich, neue Funktionen hinzuzufügen oder bestehende zu optimieren? Wenn die Antwort auf diese Fragen „Ja“ lautet, könnte es sinnvoller sein, die bestehende Plattform weiterzuentwickeln. Andererseits könnte eine neue Plattform, die auf den neuesten Technologien basiert, eine höhere Anpassungsfähigkeit und Flexibilität bieten.
Letztendlich ist auch Sicherheit ein wichtiger Faktor. Alte Systeme können Sicherheitslücken aufweisen oder möglicherweise nicht die neuesten Sicherheitsstandards erfüllen. In diesem Fall könnte der Umstieg auf eine neue Plattform, die modernste Sicherheitsfunktionen bietet, der richtige Schritt sein.
3. Architektur: Microservices vs. Modular/Monolithisch
Microservices bieten die Möglichkeit, einzelne Dienste auf sehr granulare Teilfunktionen zu spezialisieren. Dies hat den Vorteil, dass sie, in sich geschlossen, einfacher zu verstehen und entwickeln sind. Andererseits führt dies jedoch zu einer erhöhten Komplexität und Fehleranfälligkeit, da mehr Services verwaltet und orchestriert werden müssen. Im Gegensatz dazu fassen modular/monolithische Architekturen Funktionen in größeren, integrierten Modulen zusammen, was die Handhabung vereinfacht. Diese Architekturen sind jedoch oft schwerer zu verstehen, da sie viele integrierte Funktionen enthalten.
In Bezug auf Agilität kann eine Microservice-Architektur es Entwicklerteams ermöglichen, schneller und flexibler auf Geschäftsanforderungen zu reagieren, da sie unabhängig voneinander arbeiten können – Arbeit kann besser verteilt werden. Bei einer monolithischen Architektur können Änderungen hingegen mehr Zeit in Anspruch nehmen und mehr koordinierten Aufwand erfordern, da Änderungen in einem Modul Auswirkungen auf das gesamte System haben können.
Eine Microservice-Architektur unterstützt auch die unabhängige Entwicklung und Bereitstellung von Diensten, was die Geschwindigkeit und Effizienz des Entwicklungsprozesses verbessern kann. In einer monolithischen Architektur sind Module in einer einzigen Codebase integriert. Allerdings können bei Microservices Datenintegritätsprobleme auftreten, da jeder Service seinen eigenen Datenbestand hat. Bei monolithischen Systemen wird die Datenintegrität häufig durch die Verwendung einer zentralen Datenquelle gewährleistet.
4. Programmiersprachen: Java, PHP, JS, C#, Python
Bezüglich der Auswahl von Programmiersprachen gilt das Prinzip „Fit for Purpose“. Je nach Projektanforderungen, vorhandenen Fähigkeiten und Ressourcen sowie der Development-Kultur im Unternehmen können unterschiedliche Programmiersprachen zum Einsatz kommen. Die Auswahl sollte auf der Grundlage einer sorgfältigen Bewertung des jeweiligen Anwendungsfalls, der vorhandenen Expertise im Unternehmen und Integrationsfähigkeit in die vorhandene Softwarelandschaft getroffen werden.
Java
Java ist eine vielseitige, objektorientierte Sprache, die für ihre Stabilität, Portabilität und Sicherheitsfunktionen bekannt ist. Sie eignet sich besonders für die Entwicklung von großen, komplexen Anwendungen v. a. im Enterprise-Bereich. Java wird oft für die Backend-Entwicklung verwendet und ist die Sprache hinter vielen Commerce-Plattformen und Frameworks
PHP
PHP ist eine serverseitige Skriptsprache, die speziell für die Webentwicklung konzipiert wurde. Sie wird häufig für das Development von Content-Management-Systemen und E-Commerce-Plattformen verwendet. PHP hat eine große Community und bietet eine Vielzahl von Frameworks wie Laravel, Symfony oder Spryker, die die Entwicklung vereinfachen können.
Javascript (JS)
JavaScript ist die führende Sprache für Webentwicklung auf Clientseite und ermöglicht interaktive und dynamische Webseiten. Mit Node.js kann JavaScript auch serverseitig eingesetzt werden, was die Entwicklung von Full-Stack-Anwendungen in einer einzigen Sprache ermöglicht. JS ist besonders beliebt bei Developern.
C#
C# ist eine objektorientierte Sprache, die von Microsoft entwickelt wurde und eng mit dem .NET-Framework verknüpft ist. Sie eignet sich für eine Vielzahl von Anwendungen, einschließlich Web- und Desktop-Applikationen, Cloud-Diensten und Spieleentwicklung.
Python
Python ist bekannt für seine Lesbarkeit und Einfachheit, was sie zu einer guten Wahl für Anfänger macht. Trotz ihrer Einfachheit besticht Python durch seine Vielseitigkeit: Sie wird in einer Vielzahl von Bereichen eingesetzt, von Web- und Desktop-Anwendungen bis hin zu Datenanalyse und maschinellem Lernen. Python hat eine aktive Community und eine umfangreiche Auswahl an Bibliotheken und Frameworks.
5. Internes vs. externes Development Team
Die Entscheidung zwischen einem internen und einem externen Development-Team sollte anhand von Kriterien wie Expertise, verfügbaren Ressourcen und Fähigkeiten sowie den Kosten und Risiken getroffen werden. Ein internes Team kann engere Kommunikationswege und ein tiefes Verständnis für das Geschäft und die Kultur des Unternehmens mitbringen. Theoretisch sind sie besser in der Lage, eng mit anderen Abteilungen zusammenzuarbeiten und Lösungen zu entwickeln, die auf die spezifischen Anforderungen des Unternehmens zugeschnitten sind. In der Praxis zeigt sich aber auch die Kehrseite: Interne Fachabteilungen sind – ob bewusst oder unbewusst – Silos, die den Informationsaustausch erschweren. Verantwortung nach außen zu verlagern, kann helfen, diese Silos aufzubrechen.
Ein externes Team hingegen bringt oft spezialisiertes Wissen und breite Erfahrung aus einer Vielzahl von Projekten und Branchen ein. Sie können neue Perspektiven und Best Practices aufzeigen, die Innovationen fördern und die Qualität der Applikation verbessern. Der frische Blick trägt dazu bei, bisher übersehene Herausforderungen zu identifizieren. Dennoch: Entscheidend sind das Anforderungsmanagement und die Verständigung über die Erwartungen, Ziele und Bedürfnisse des Projekts. Ein externes Team erfordert ein Mehr an Kommunikation, um das Risiko von Missverständnissen zu minimieren und sicherzustellen, dass alle Parteien dieselben Ziele verfolgen. Ebenso fallen Mehrkosten für externe Dienstleistung ins Gewicht.
Grundsätzlich gilt es für jedes Unternehmen, langfristig Ownership über die eigene IT aufzubauen. Selbst wenn externe Teams den Großteil der Umsetzung stemmen, muss das interne Team in der Lage sein, die Applikation über den Projektabschluss hinaus zu betreiben und kontinuierlich weiterzuentwickeln.
6. Development-Kultur: Agile Top-Down vs. Agile Holacracy
Die Art der Development-Kultur kann einen großen Einfluss auf die Geschwindigkeit und Qualität der Entwicklung haben. Je innovativer das Geschäftsmodell ist, desto agiler sollte das Team arbeiten und Anforderungen bearbeiten können.
Agile Top-Down Ansätze bieten mehr Kontrolle und Struktur, insbesondere weil Rollen und Aufgaben exakt verteilt sind. Es werden klare Anforderungen an die Entwicklung formuliert, die iterativ und inkrementell mit den Methoden agiler Softwareentwicklung umgesetzt werden. Die Mehrheit aller agilen Entwicklungsprojekte ist so aufgebaut, vor allem in eher hierarchisch geprägten Unternehmen – Agile Top-Down ist häufig ein guter Kompromiss zwischen Unternehmens- und agiler Development-Kultur.
Mehr Flexibilität bieten Modelle, wie “Agile Holacracy”. Hier sind die Teams selbstorganisiert, Rollen und Zuständigkeiten können sich immer wieder verändern. Das setzt ein großes Maß an Eigenverantwortung aller Beteiligten voraus – und natürlich auch die Fähigkeit, eigenständig zu agieren. Eine solche Umgebung fördert die Experimentierfreudigkeit und damit auch die Möglichkeit, laufend neue Fähigkeiten zu lernen.
7. Lifecycle Status Check: Analyse, Bewertung, Priorisierung und Optimierung
Software ist kein Gebäude aus Beton, das einmal gebaut für immer steht, sondern lebendige Ökosysteme. Status Checks über den gesamten Lifecycle einer Applikation hinweg sind essenziell, um kontinuierlich den größten Wert aus einer Plattform zu schöpfen. Im Zentrum steht ein Kreislauf: Analyse, Bewertung, Priorisierung und Optimierung. Applikationen erfordern eine regelmäßige Bewertung hinsichtlich Performance, Optimierungspotentialen und Risiken. Auf diese Weise wird sichergestellt, dass die Plattform technologisch immer auf dem neuesten Stand ist und den Anforderungen im Markt gerecht wird. Dabei stoßen Unternehmen häufig immer wieder auf dieselben Herausforderungen:
- Komplexität: Veraltete Austauschformate und limitierte Performance und Skalierbarkeit können eine effektive Handhabung von Plattformen unnötig komplex machen und so erschweren.
- Maintenance: Die Instandhaltung von veralteter Software kann hohe und zeitintensive Aufwände verursachen und so die Tech-Ressourcen des Unternehmens begrenzen.
- Integration: Komplexe, verflochtene und voneinander abhängige Integrationen sowie heterogene und fragmentierte Daten können die Effizienz und Effektivität von Applikationen einschränken.
- Upgrades: Eine hohe Anzahl und Frequenz von Updates, gepaart mit der Größe der Updates, kann für Unternehmen eine zusätzliche Herausforderung darstellen.
Verbesserungen sollten iterativ während des gesamten Lebenszyklus der Plattform implementiert werden. Dieser Modus der „kontinuierlichen Bewertung“ sorgt für eine ständige Überwachung und Anpassung, die es ermöglicht, proaktiv statt reaktiv zu handeln.
Die Umsetzung und der Betrieb von effektiven Applikationen und Plattformen ist ein dynamischer Prozess, der kontinuierlich Engagement, Bewertung und Verbesserung erfordert. Durch die Berücksichtigung der oben genannten sieben Kriterien lassen sich Plattformen entwickeln, betreiben und optimieren, die echten Wert für Unternehmen schaffen und ihren Kund:innen die bestmögliche Erfahrung bieten.
Über den Autor
Christopher Möhle ist Managing Director bei Turbine Kreuzberg und begleitet Unternehmen bei der Entwicklung von digitalen Produkt- und Serviceplattformen sowie individuellen Applikationen. Seine Schwerpunkte liegen in den Bereichen Technologie und Umsetzungsstrategie. Möhle leitet den Consulting-Bereich der Agentur
Über Turbine Kreuzberg
Turbine Kreuzberg ist ein Softwareunternehmen aus Berlin. Das Team von über 140 Technolog:innen arbeitet am Herzstück der digitalen Landschaften von Unternehmen: Turbine Kreuzberg entwickelt und betreibt digitale Commerce Plattformen und Enterprise Applikationen. Darüber hinaus modelliert Turbine Kreuzberg integrierte Technologie-Strategien passend zum jeweiligen Geschäftsmodell – von der Konzeption von System- und Softwarearchitekturen über das richtige Umsetzungsmodell bis hin zur frühzeitigen Evaluierung neu aufkommender technologischer Ansätze. Mehr Informationen unter turbinekreuzberg.com.