00:00:03 Modularisierung in IT und supply chains Einführung.
00:00:26 Physische supply chain Modularität.
00:02:31 Monolithische Strukturen früher IT-Systeme.
00:04:08 IT-Kontext monolithischer Systeme.
00:05:31 Einfluss des Internets auf modulare Softwaregestaltung.
00:08:02 Probleme in monolithischen Softwaresystemen.
00:08:48 Ineffizienzen monolithischer Systeme.
00:11:16 Übergang zu modularen Systemen: Beispiele.
00:13:34 Systemausfälle in modularen Anwendungen.
00:14:34 Redundanz, Betriebszeit in modularen Systemen.
00:16:00 Zuverlässigkeit großer Systeme, Scheitern von Softwareprojekten.
00:16:50 Lidls gescheitertes Software-Übergangsbeispiel.
00:18:09 “Fail fast”-Konzept in Softwareprojekten.
00:19:30 Verwaltung von Überschneidungen, Bedeutung von “glue” Software.
00:22:46 Vermeidung von Softwarekatastrophen.
Zusammenfassung
In der Lokad TV-Episode diskutiert Joannes Vermorel, der Gründer von Lokad, die Bedeutung von Modularisierung in der IT-Infrastruktur von Unternehmen und zieht einen Vergleich zur Anpassungsfähigkeit von supply chains. Er verweist auf die monolithischen IT-Systeme der 70er und 80er Jahre, die durch technologische Beschränkungen gekennzeichnet waren. Selbst mit dem Übergang zu vernetzten Systemen nach dem Aufkommen des Internets unterstreicht er die anhaltende Herausforderung für Unternehmen, ihre IT-Systeme zu modularisieren. Vermorel schlägt als mögliche Lösung eine Service Oriented Architecture (SOA) vor und betont die Notwendigkeit kleinerer, klar definierter Services. Er warnt davor, groß angelegte Projekte in Angriff zu nehmen, und befürwortet einen “fail fast”-Ansatz, wobei er die Wichtigkeit des Risikomanagements und einer schnellen Wiederherstellung im Falle von Ausfällen hervorhebt.
Erweiterte Zusammenfassung
In der aktuellen Episode von Lokad TV führt Moderator Kieran Chandler ein Gespräch mit Joannes Vermorel, dem Gründer von Lokad, über die Modularisierung in der IT-Infrastruktur von Unternehmen. Vermorel erläutert das Konzept der Modularisierung und zieht dabei vorwiegend Parallelen zu den supply chains in der physischen Welt, die er als die modularsten Erfindungen der Menschheit ansieht.
Er verwendet die Beispiele von Trucks, Paletten und Containern, um seine Argumente zur Modularität zu verdeutlichen. Vermorel hebt die inhärente Modularität physischer supply chains hervor, indem er auf die universelle Anwendbarkeit von Barcodes hinweist, die nahezu an allem angebracht werden können.
Obwohl physische supply chains eine klare Modularität aufweisen, stellt Vermorel fest, dass die IT-Infrastrukturen von Unternehmen oft nicht dieselbe Flexibilität besitzen. Er führt diesen Mangel an Modularität auf die frühen Phasen der IT-Entwicklung in den 1970er und 1980er Jahren zurück, als erste IT-Implementierungen und ERP Systeme aufgrund der technologischen Beschränkungen jener Zeit als eigenständige, monolithische Strukturen konzipiert wurden.
Vermorel definiert einen “Monolithen” im IT-Kontext als eine einheitliche Anwendung, die nicht in kleinere Teile zerlegt werden kann. Er erläutert, wie sich dieser monolithische Ansatz von der Modularität unterscheidet, die in physischen supply chains zu beobachten ist, bei denen verschiedene Komponenten nach Bedarf kombiniert oder getrennt werden können.
Trotz ihrer Komplexität erklärt Vermorel, dass die frühen Mainframes von Natur aus kohärent waren, da sie als eine Einheit mit zentralisierten Operationen funktionierten. Er weist darauf hin, dass diese Form des Systemdesigns für die heutige Generation, die an verteilte Systeme und netzwerkbasierte Anwendungen gewöhnt ist, veraltet erscheint, was einen bedeutenden Wandel in der IT-Infrastrukturentwicklung über die Jahre hinweg markiert.
Vermorel stellt fest, dass sich das Umfeld mit dem Aufkommen des Internets in den späten 90er Jahren zu verändern begann, was zur Entwicklung von Software führte, die aus isolierten, durch ein Netzwerk verbundenen Teilen besteht. Er bemerkt jedoch, dass viele Unternehmen weiterhin Schwierigkeiten mit der Modularisierung haben, obwohl der Wert modularer IT-Systeme theoretisch gut verstanden ist.
Er erklärt, wie viele Anbieter diese alten monolithischen Architekturen an Cloud- und Software-as-a-Service-(SaaS)-Modelle angepasst haben, was zu Systemen führte, die eine verbesserte Wartung bieten, jedoch die Modularität nicht erhöhen. Seiner Meinung nach verhindert dieser Mangel an Modularität, dass Unternehmen spezifische Funktionen isolieren und ändern können.
Um dieses Problem zu überwinden, schlägt Vermorel eine Service Oriented Architecture (SOA) vor, einen Ansatz, bei dem Fähigkeiten in kleinere, klar definierte “Bausteine” unterteilt werden. Er nennt Amazon als Beispiel für ein Unternehmen, das diesen modularen Ansatz frühzeitig erfolgreich umgesetzt hat.
Er befürwortet eine serviceorientierte Architektur mit APIs, die es ermöglichen, Daten zu exportieren und in verschiedenen Unternehmensbereichen zu nutzen. Obwohl er anerkennt, dass ein dezentralisierter Ansatz potenziell zu mehr Fehlerpunkten führen kann als ein monolithisches System, argumentiert Vermorel, dass diese Herausforderungen durch Redundanz und hochwertige Ingenieurskunst gemindert werden können.
Vermorel schätzt, dass zwischen einem Drittel und der Hälfte aller IT-Projekte im Bereich supply chain scheitern. Er verweist auf den Fall Lidl in Deutschland, das bei einem gescheiterten SAP-Übergang einen halben Milliarde Euro verloren hat. Er argumentiert, dass der Wechsel von kleinen zu großen Anbietern die Ausfallraten zwar leicht senkt, sie jedoch nicht eliminiert.
Hinsichtlich der Verwaltung mehrerer Anwendungen empfiehlt Vermorel, Anwendungen mit einem engen Anwendungsbereich auszuwählen, um Überschneidungen zu minimieren, und rät davon ab, große Frameworks von Anbietern zu kaufen. Um mehrere Apps effektiv zu verwalten, sagt er, sollten Unternehmen eine interne “glue” Lösung entwickeln, die diese Anwendungen miteinander verbindet, unterstützt durch eine serviceorientierte Architektur.
Abschließend gibt Vermorel Ratschläge, wie man Katastrophen wie den gescheiterten SAP-Übergang von Lidl vermeiden kann. Er betont, in Begriffen des Risikomanagements zu denken und einen “fail fast”-Ansatz zu verfolgen. Er rät davon ab, im Projektmanagement auf Wunschdenken zu setzen, und unterstreicht die Bedeutung, für mögliche Ausfälle zu planen und Wege zu finden, schnell zu regenerieren.
Gesamtes Transkript
Kieran Chandler: Hallo und willkommen zurück zu einer weiteren Episode von Lokad TV. Diese Woche werden wir über Modularisierung sprechen, den Prozess der Unterteilung der Computerprozesse unseres Unternehmens von einem eigenständigen System in eine Anzahl anderer Teilprogramme oder sogar Apps. Wie immer werde ich von Joannes Vermorel begleitet. Also, Joannes, welchen Teil der Geschäftsprozesse wollen wir heute modularer gestalten?
Joannes Vermorel: Heute konzentrieren wir uns insbesondere auf die IT-Infrastruktur und die anwendungsbezogene Landschaft Ihres Unternehmens. Modularisierung ist interessant. Wenn man an die physische Welt denkt, wird deutlich, dass supply chains unglaublich modular sind. Sie gehören wahrscheinlich zu den modularsten Erfindungen, die die Menschheit je gemacht hat. Mit modular meine ich, dass wenn man Waren auf Straßen transportieren möchte, man Trucks einsetzen kann. Trucks sind unglaublich modular, da man so ziemlich alles, was nicht die Kapazität eines Trucks überschreitet, darin unterbringen kann, und ein Truck auf jeder Straße fahren kann, von einem Ort zum anderen. Wenn Sie zusätzliche Trucks benötigen, können Sie nahezu jeden beliebigen Truck verwenden, und sie können Ihrer supply chain zusätzliche Transportkapazitäten verleihen.
Das Gleiche gilt für Paletten und Container. Man kann fast alles auf eine Palette oder in einen Container legen, solange es nicht die Kapazität überschreitet. Ein Container ist äußerst modular. Man kann ihn von einem Frachtschiff auf einen Truck umladen. All diese Elemente sind unglaublich modular. Auf nahezu alles, das nicht zu klein ist, kann man einen Barcode anbringen. Es ist eine unglaublich moderne Erfindung. Wenn Sie etwas wie einen Diamanten haben, würden Sie ihn wahrscheinlich in eine Schachtel legen und den Barcode dann auf die Schachtel aufbringen. All diese einfachen Elemente lassen sich beliebig kombinieren, fast unendlich. Es ist sehr Lego-ähnlich; einfache Teile, die in unglaublich vielfältiger Weise kombiniert werden können. Das ist die physische supply chain, die unglaublich modular ist.
Interessanterweise betritt man jedoch in der IT-Welt eine völlig andere Perspektive, in der Modularisierung häufig verloren geht. Ich denke, dass der Ursprung davon in den frühen 70er oder 80er Jahren liegt, als Unternehmen begannen, ihre ersten Computersysteme und erste ERP-Implementierungen einzuführen.
Kieran Chandler: Also sagst du, dass diese ersten Implementierungen, diese anfänglichen IT-Systeme, da sie sehr einheitlich waren, immer noch mit diesem Ansatz arbeiten. Ist das, was du sagen willst?
Joannes Vermorel: Ja, in der Tat. Wenn man an die IT oder Software der 70er, 80er oder sogar der frühen 90er denkt, war es wie Raketenwissenschaft, irgendetwas über das Netzwerk zu betreiben. Es war möglich, aber es war ein ingenieurtechnischer Albtraum. Es war viel einfacher zu sagen, wir nehmen eine große Maschine, idealerweise einen IBM-Mainframe jener Zeit, und legen all unsere Logik auf diese Maschine. Dann benutzt jeder ein Terminal, das mit dieser Maschine verbunden ist, und all die Logik läuft als Monolith auf dieser Maschine.
Kieran Chandler: Was meinst du mit Monolith?
Joannes Vermorel: Mit einem Monolith meine ich, dass es wie eine Anwendung ist, die ein Ganzes bildet. Sie kann nicht auseinander genommen werden. Sie muss zusammengehören, andernfalls ist sie nichts.
Kieran Chandler: Ich fürchte, ich gehöre ein wenig zur Millennial-Generation, sodass diese Art von Idee vielleicht vor meiner Zeit liegt. Aber im Grunde sagen wir, dass alles mit einer einzigen Maschine verbunden wird, richtig? Und dann verbinden wir uns alle und arbeiten von dort aus?
Joannes Vermorel: Genau. Mainframes waren relativ komplexe Hardware, also auch wenn es nur eine Maschine war.
Kieran Chandler: Wir sprechen meist über ERPs, also Enterprise Resource Management-Systeme. Diese Systeme sind typischerweise darauf ausgelegt, erweiterbar zu sein, sodass zusätzliche Funktionen und Features hinzugefügt werden können. Sie sind jedoch nicht modular, was bedeutet, dass man diese Funktionen nicht trennen kann, um sie vollständig zu isolieren.
Joannes Vermorel: Das Interessante ist, dass sich vermutlich das Internet wirklich verändert hat. Ich spreche nicht von der Erfindung des Internets, sondern von der Tatsache, dass in den späten 90er Jahren, als das Internet sehr populär wurde, die Leute anfingen, darüber nachzudenken, wie man Software so gestalten kann, dass man die Teile isoliert, mit dem Netzwerk in der Mitte. Auf diese Weise wird der Workflow kein ingenieurtechnischer Albtraum. Davor, wenn man nicht wusste, wie man ein komplexes Softwaresystem aus vielen Teilen baut, war ein Netzwerk in der Mitte ein Ingenieur-Albtraum. Dieses Know-how, diese Kultur und diese Tools entstanden größtenteils als Nebenprodukt der Einführung des Internets durch die breite Öffentlichkeit.
Kieran Chandler: Das Internet gibt es jetzt schon lange, also warum reden wir immer noch über Modularisierung? Warum verhalten sich diese Softwaresysteme immer noch so, als wären sie einheitlich aufgebaut?
Joannes Vermorel: Derzeit lautet meine Diagnose, dass in einem durchschnittlichen Unternehmen, das eine komplexe supply chain betreibt oder ein multinationales Unternehmen mit vielen Standorten, alles Physische unglaublich modular ist. Wenn man jedoch die IT betrachtet, ist sie völlig monolithisch. Ich glaube, dass Unternehmen und der Markt im Allgemeinen immer noch Schwierigkeiten haben, den Wert von etwas zu schätzen, das in der IT extrem modular ist. Im physischen Bereich ist das ziemlich offensichtlich, und supply chains verbessern ihre Modularität weiterhin. Im Hinblick auf die Anwendungslandschaft ist es jedoch abstrakter und schwieriger, die Modularität zu erkennen.
Viele Anbieter haben alte monolithische Architekturen genommen, sie leicht in Richtung SaaS und Cloud aufgerüstet, aber einfach kopiert und eingefügt. Es ist im Grunde genommen dieselbe Architektur, die man in den 90er Jahren auf einem IBM-Mainframe hatte, bei der man sich schlicht dazu entschied, anstatt eine Maschine am Firmenhauptsitz zu haben, die das System betreibt, diese an einen Softwareanbieter auszulagern, der als SaaS operiert. Aber wenn der SaaS-Anbieter nur einen Monolithen hat, den er auf einer Maschine betreibt, die weit vom Hauptsitz entfernt ist, mit nur etwas Netzwerk und einer Web-Benutzeroberfläche dazwischen, trägt das in puncto Modernisierung nichts bei. Es erleichtert nur die Wartung. Aber wenn man die Funktionen auseinandernehmen möchte, steht man immer noch vor einem Monolithen, in dem solche Fähigkeiten nicht realisierbar sind.
Kieran Chandler: Was ist das Problem mit diesem monolithischen Ansatz? Wie wirkt er sich in der realen Welt auf Unternehmen aus?
Joannes Vermorel: Stellen Sie sich einfach das physische Äquivalent eines Mangels an Modularisierung vor. Stellen Sie sich vor, dass in Ihrer supply chain, wann immer Sie einen Truck austauschen möchten, alle ausgetauscht werden müssen. Zum Beispiel, wenn Sie von einem Truck auf einen anderen wechseln, benötigen Sie eine andere Art von Benzin. Alle Ihre Tankstellen müssten also angepasst werden, was bedeuten würde, dass Sie Tanks haben, die Benzin enthalten, wobei Sie einen zweiten Kraftstofftyp benötigen. Das wäre immens.
Der Schmerz, verstehen Sie, ist vergleichbar mit der Situation in der Software. Wenn es an Modernisierung mangelt, ist es so, als ob man ein Teil austauscht und dann alle austauschen muss. Wenn Sie einen Truck wechseln, müssen Sie die gesamte Flotte umstellen. Stellen Sie sich vor, Sie ändern die Regale eines Lagers und müssten dann alle Regale in allen anderen Lagern ändern, da sie sonst nicht kompatibel wären. Dann wird Ihnen klar, okay, vielleicht kann ich meine Truck-Flotte auf Elektro-Trucks umrüsten, aber das wäre ein massiver strategischer Schritt und sehr kompliziert. Sie würden immer noch etwas Relativ-Modulares bevorzugen, bei dem Elektro-Trucks und Verbrennungstrucks lange Zeit harmonisch koexistieren können. Wenn es an Modernisierung mangelt, bedeutet das, dass Sie nicht einige Teile Ihrer supply chain ändern können, ohne alles zu verändern.
Das häufigste anekdotische Beispiel für diesen Mangel an Modernisierung ist, dass es für Unternehmen physisch möglich wäre, innerhalb eines Tages ein Lager zu verlagern, indem sie einfach die in Lager A befindlichen Gegenstände auf die Regale von Lager B umstellen. Aber die Migration der Software, die mit Lager A verbunden war, sodass alles weiß, dass alle Gegenstände im System von Lager B erfasst sind, würde etwa sechs Monate dauern.
Kieran Chandler: Das ist interessant. Wie gehen große Unternehmen vor, wenn sie in diesem monolithischen System existieren? Wie migrieren sie zu einem modulareren System?
Joannes Vermorel: Ich denke, wir kehren zu einem der Unternehmen zurück, die wir in fast jeder Episode erwähnt haben, wie Amazon. Sie sind nicht die Einzigen, die einen extrem modularen Ansatz eingeführt haben. In Deutschland hat Zalando – wie man in den Blogs verfolgen kann – nun ebenfalls einen sehr modularen Ansatz vollständig übernommen, und das Schlüsselwort in der IT, wenn man diese Modularität erreichen möchte, ist wahrscheinlich Service Oriented Architecture, SOA.
Service Oriented Architecture bedeutet im Grunde, dass man Fähigkeiten in Blöcke isolieren möchte, die selbst wie kleine Monolithen sind, aber viel kleiner, und die sehr präzise darauf ausgelegt sind, eine Sache zu tun und diese gut zu erfüllen. Und man verbindet all diese Komponenten über die Service Oriented Architecture, was bedeutet, dass jeder einzelne Dienst – im Sinne einer App, die eine Sache tut und das gut – APIs bereitstellt, sodass er sehr einfach in die Anwendungslandschaft integriert werden kann. Er ist so konzipiert, dass er programmatisch leicht in jede beliebige Anwendungslandschaft eingesteckt werden kann, ohne nahezu irgendwelche Annahmen darüber zu machen, wie die anderen Teile der Anwendungslandschaft aussehen.
Jeff Bezos von Amazon veröffentlichte, glaube ich, im Jahr 2002 ein sehr berühmtes Memo, in dem er all seinen Teams sagte, dass jede einzelne Abteilung eine serviceorientierte Architektur mit APIs haben muss, damit die Daten, die man in seinem Silo hat, exportiert und in jeder anderen Abteilung des Unternehmens genutzt werden können und wir programmatisch mit dem interagieren können, was auch immer gebaut wird.
Kieran Chandler: Das Problem, das ich sehe, ist, dass man letztendlich von vielen kleineren Apps, kleineren Programmen, kleineren Unternehmen abhängig wird. Führt das nicht zu viel mehr Einzelfehlerpunkten? Während man bei einem monolithischen Ansatz auf ein solides, großes Unternehmen, ein großes ERP-System, das immer läuft, setzen kann und mehr Vertrauen in dieses hat.
Joannes Vermorel: Das ist wahr, und bis zu einem gewissen Grad ist das eine der Herausforderungen eines verteilten Systems. Wenn Ihre Hardware zu 1 % ausfällt, dann bedeutet das, wenn Sie einen Mainframe haben.
Kieran Chandler: Du hast erwähnt, dass die Software dreimal im Jahr ausfallen kann. Wenn du 10 Apps hast, von denen jede an einem beliebigen Tag mit einer Ein-Prozent-Wahrscheinlichkeit ausfällt, bedeutet das, dass ungefähr alle 10 Tage etwas in deinem Netzwerk ausfällt. Das ist in der Tat eine Herausforderung. Welche Lösungen würdest du für diese Situation vorschlagen?
Joannes Vermorel: Redundanz ist das Erste, was einem einfällt, aber ich möchte die Auswirkungen im Hinblick auf verteiltes Rechnen diskutieren, und vielleicht können wir dann über kleine versus große Unternehmen und die Unterschiede bei den Anbietern sprechen. Aus der Sicht des verteilten Rechnens besteht das Ziel darin, sicherzustellen, dass jeder einzelne Block hoch redundant ist. Das ist das Wesen des Cloud Computing. Man möchte eine stark redundante Software haben, damit die Betriebszeit sehr hoch ist.
Die gute Nachricht ist, dass es viel einfacher ist, eine sehr hohe Betriebszeit mit einer kleinen, einfachen App zu erreichen, da deine Apps kleiner und einfacher sind, als mit einer sehr komplexen App. Es gibt viele Komponentendienste im Internet, die buchstäblich immer verfügbar sind. Google Mail zum Beispiel ist buchstäblich immer verfügbar. Die Webseite von Yahoo ist im Grunde immer verfügbar. Auch Facebook ist immer verfügbar. Daher ist es möglich, diese „Always-on“-Eigenschaften für deine Apps zu entwickeln, was die Zuverlässigkeit deines Systems als Ganzes verbessert.
Kieran Chandler: Wie sieht es aus mit dem Übergang von einem großen Anbieter zu vielen kleinen Anbietern?
Joannes Vermorel: Die Realität ist, dass die Ausfallraten in der Software hoch sind. Die Leute realisieren nicht, dass Softwareinitiativen vielleicht in der Hälfte der Fälle scheitern. Meine Schätzung wäre, dass zwischen einem Drittel und der Hälfte aller supply chain IT-Projekte bei Unternehmen nahezu jeder Größe scheitern. Vor ein paar Wochen hat Lidl in Deutschland im Grunde eine halbe Milliarde Euro bei einer fehlgeschlagenen SAP-Transition verloren. Es war ein siebenjähriges Projekt, das in einem Scheitern endete, und letztendlich haben sie aufgegeben. Aber das ist nicht das einzige Beispiel; das passiert ziemlich häufig.
Große Anbieter haben wahrscheinlich eine bessere Erfolgsquote, aber wenn man mit groben Zahlen rechnet, spricht man davon, von einem kleinen Anbieter mit einer 50%igen Ausfallrate – was ziemlich schlecht ist – zu einem großen Anbieter mit einer 30%igen Ausfallrate zu wechseln. Wenn man also von einem kleinen zu einem großen Unternehmen übergeht, sinkt das Risiko leicht, aber nur ein wenig.
Wenn du dich für einen stark modularen Ansatz entscheidest, ja, werden viele Dinge scheitern, aber du hast die Möglichkeit, es erneut zu versuchen und so lange zu wiederholen, bis du erfolgreich bist. Jede Komponente hat die Chance zu scheitern, aber da der Umfang einfacher ist und die App selbst kleiner, kannst du schnell scheitern und es erneut versuchen.
Das Besondere am Lidl-Ansatz ist, dass ich mir ziemlich sicher bin, dass sie ursprünglich keine siebenjährige Migration geplant hatten. Es war vermutlich eine zweijährige Migration, die sich auf drei, dann vier und so weiter ausweitete, weil sie scheiterten, wiederholten und erneut scheiterten. Nach sieben Jahren beschlossen sie schließlich aufzugeben, wahrscheinlich weil alle jegliche Hoffnung auf Erfolg des Projekts verloren hatten.
Kieran Chandler: Wenn wir uns also darauf einigen, dass diese Apps, sobald man die Richtige findet und vielleicht ein wenig iteriert, zuverlässig sein können… Sie scheinen zu funktionieren und verrichten die gleiche Arbeit wie ein größeres System. Wie sieht es mit den Schnittstellen zwischen diesen Apps aus? Denn oft ist es so, dass eine App etwas anderes gut macht und es möglicherweise zu Überschneidungen und Konflikten innerhalb des Systems kommt. Wie geht man damit um?
Joannes Vermorel: Zuerst, wenn du die Zusammensetzung deiner Applikationslandschaft wählst, solltest du wirklich Apps auswählen, die einen engen Anwendungsbereich haben. Dieser Ansatz widerspricht vollkommen dem, was die meisten Request for Proposals (RFPs) machen. Wenn Unternehmen versuchen, ein Stück Software zu erwerben, setzen sie oft auf eine RFP und wollen alles – alle Funktionen, alle Spielereien. Aber das ist genau das Gegenteil dessen, was du anstreben solltest. Du willst etwas, das extrem eng gefasst ist, sodass du von vornherein Überschneidungen minimierst.
Wenn du große Frameworks kaufst, ist es ein Rezept für Überschneidungen. Enterprise-Anbieter sind daran interessiert, dir große Frameworks zu verkaufen, weil sie diese mit vielen Funktionen erweitern können. Sie verkaufen dir etwas, und dann verkaufen sie dir die Add-ons darauf. Daher würde ich Leuten, die große supply chains betreiben, raten, sehr vorsichtig zu sein, wenn man dir eine Plattform anbietet.
Eine Plattform ist gut, aber zwei Plattformen können ein Alptraum sein. Sobald du mehrere Anbieter hast, die dir Plattformen verkaufen, landest du in einem Meer von Überschneidungen. Die Lösung besteht darin, die Zusammensetzung deiner Komponenten sorgfältig auszuwählen.
Was den “Klebstoff” betrifft, so ist es in der Regel etwas, das du intern entwickeln möchtest. Das mag gegen die Intuition gehen, warum man irgendeine Art von Software selbst entwickeln sollte. Die Antwort lautet, dass, wenn du ein Unternehmen einer bestimmten Größe bist, deine Applikationslandschaft völlig einzigartig für dich ist.
Selbst wenn du alle Standard-Apps verwendest, wirst du mehrere Apps benötigen. Es gibt heutzutage keine ERP, die E-Mails, Videokonferenzen und dergleichen erledigen kann. Du kannst nicht jede einzelne Softwarefunktion, die du benötigst, in einer App unterbringen. Du wirst wahrscheinlich wie alle anderen Microsoft Excel verwenden, also benötigst du einen Ort, um Dateien zu speichern und so weiter.
Es ist unrealistisch zu behaupten, dass wir nur ein Stück Software haben. Jedes Unternehmen von bedeutender Größe wird ohnehin eine Sammlung von Software sein. Das genaue Rezept, also die Liste der Software, die dein Unternehmen buchstäblich betreibt, wird ohnehin völlig einzigartig für dich sein. Kein anderes Unternehmen ist genau wie deins organisiert.
Kieran Chandler: Es ist völlig einzigartig, das ist deine DNA. Du kannst diesen Klebstoff haben, den du intern implementierst. Das ist der ganze Punkt der serviceorientierten Architektur – diesen Klebstoff so einfach und schlank wie möglich zu implementieren, damit du ein sehr schlankes IT-Team haben kannst, das nur minimale Anstrengungen aufwenden muss, um diese kundenspezifische Software zu entwickeln, die die Dinge nur zusammenfügt. Also, um es zusammenzufassen: Wenn ich ein CEO bin, wie vermeide ich ein weiteres Lidl-typisches Desaster?
Joannes Vermorel: Zunächst denke ich, dass es wesentlich ist, an Risiken zu denken, anstatt das Risiko zu minimieren. Das Lidl-typische Desaster entstand, weil die Leute sagten: “Wir wollen keinerlei Risiko eingehen”, und sich deshalb für den größten Anbieter da draußen entschieden und versucht haben, das Produkt zu bekommen, das alles kann. Im Wesentlichen ist es der Ansatz, bei dem man sagt, wir wollen etwas, das von vornherein korrekt konzipiert ist, und wir wollen etwas einführen, das das ganze Unternehmen auf einmal aufrüstet. Das ist die schlechteste Art von Ansatz in Bezug auf Risikomanagement.
Du musst vollkommen das Gegenteil denken, nämlich: “Wie kann ich etwas haben, das schnell scheitert, wenn es scheitern muss?” Siehst du, das Problem mit dem Risiko ist, dass du bei einem riesigen Projekt lange nicht weißt, ob du gescheitert bist oder nicht. Was du willst, ist etwas, das mehr “fail fast” ist, bei dem du erkennst, wenn du gescheitert bist, und das Scheitern in kleinem Maßstab erfolgt. Und falls du einen Ersatz brauchst, hast du einen handhabbaren Umfang, und das erreichst du mit vielen kleinen Bausteinen.
Betrachte es also nicht als Risikovermeidung. Ich sage, dass der Wechsel von einem großen Anbieter zu einem kleinen Anbieter das Risiko von einer 50%igen Ausfallwahrscheinlichkeit auf 50% erhöhen könnte. Letztendlich, wenn eine 30%ige Ausfallwahrscheinlichkeit bedeutet, dass dein Unternehmen bankrottgeht oder dass die supply chain zum Stillstand kommt, ist es kein Risiko, das du eingehen kannst. Daher musst du ohnehin mit Ausfällen planen.
Meiner Meinung nach, da ein hohes Maß an Risiko unvermeidbar ist, solltest du direkt einen Plan für Ausfälle anstreben. Versuche, kleine, schnelle und gut abgegrenzte Ausfälle zu haben, damit du iterieren kannst, anstatt zu sagen, wir machen alles beim ersten Mal richtig – was Wunschdenken ist. Und dann begibst du dich auf eine Reise, die wahrscheinlich sieben Jahre dauert, um am Ende eine halbe Milliarde Euro zu verlieren. Das ist die Art von Wunschdenken im Projektmanagement.
Kieran Chandler: Großartig, das gefällt mir. Der Lokad-Tipp des Tages: Wenn du scheiterst, dann scheitere schnell. Hervorragend. Das war alles für diese Woche. Wir sind nächste Woche wieder mit einer weiteren Episode zurück. Bis dahin, danke fürs Zuschauen.
