CTO NEED TO KNOW Podcast

Legacy-Modernisierung: Shop-Monolithen knacken

Zu Gast: Peter Whitmore, Director Engineering Digital Business Platform, Phoenix Contact

Wie meistert man die Modernisierung von Bestandssystemen in einem global agierenden Unternehmen der Elektrotechnik- und Automatisierungsbranche? In dieser Folge gibt Peter Whitmore, Director Engineering Digital Business Platform bei Phoenix Contact, Einblicke in die Herausforderungen und Lösungsstrategien bei der umfassenden Überarbeitung der E-Commerce-Plattform eines führenden Entwicklers und Herstellers von elektrischer Verbindungs- und industrieller Automatisierungstechnik. Wir erfahren, welche Rolle Self-contained Systems, Cloud-Technologien und agile Methoden spielen und wie eine starke Unternehmenskultur den Wandel nicht nur unterstützt, sondern aktiv vorantreibt. Wie tragen externe Expertise und Teamdynamik zum Erfolg bei?
Weitere Episoden anhören

Shownotes & Links

In dieser Folge erfahren wir:

Transkript

Transkript ausklappen / einklappen

Stefan Paal: Hallo und herzlich willkommen zu einer neuen Episode des Podcasts CTO Need to Know. Heute wieder mit einer Folge zum Thema Legacy Modernization, also die Modernisierung vom Bestandssystem. Mein Name ist Stefan Pahl und ich bin Principal Consultant bei der Firma InnerQ. Ich bin seit über 35 Jahren in der Softwareentwicklung unterwegs, als Entwickler, Architekt und Berater. Unter anderem arbeite ich auch in Kundenprojekten immer wieder an der Modernisierung vom Bestandssystem.

In dem Podcast CTO Need to Know sprechen wir mit Entscheidern über ausgewählte Themen, um ihre Sicht auf die Herausforderungen, die Fragestellungen, aber auch die gemachten Erfahrungen aufzugreifen, die wir mit anderen Entscheidern teilen wollen. Ich freue mich über jeden Gast, den ich zum Gespräch begrüßen darf. Doch heute ist es ohne Übertreibung nochmal eine ganz besondere Freude und Ehre. Ich darf Peter Whitmore von Phoenix Contact begrüßen, den ich schon seit einigen Jahren aus der Zusammenarbeit bei der Modernisierung ihrer E-Commerce-Plattform kenne und persönlich sehr schätze. Peter, schön, dass du hier bist. Zuerst einmal die obligatorische Vorstellung. Wer bist du? Wer ist Phoenix Contact? Und was machst du da?

Peter Whitmore: Ja, danke Stefan für die Einladung, für die nette Begrüßung. Peter mein Name. Ich bin 54 Jahre alt, verheiratet, Kindern, aber das ist für heute nicht so relevant. Also ich arbeite seit über 26 Jahren nun im IT-Umfeld, Softwareentwickler angefangen, ein bisschen zur Teamlead, Entwicklungsleitung und inzwischen seit 2008 bei der Phoenix Contact. Jetzt als Leiter unserer Abteilung für unsere neue digitale Kundeninteraktionsplattform, CRISP, intern genannt. Und ja, das ist die Kurzfassung. Das ist jetzt so gerne als Langfassung.

Stefan: Ne, das passt schon mal. Ich fand das Wort Kundeninteraktionsplattform schon mal sehr gut. Hab ich auch noch nicht gehört, aber finde ich super. Wir starten immer diese Podcasts auch noch mal am Anfang. Bestandssystem, legacy systems. Was ist aus deiner Sicht ein Bestandssystem? Wie würdest du das definieren?

Peter: Also Bestand nach beständig ist etwas, was man ja auch schon auch länger schätzt und bewahrt und auch nutzt und hat auch einen Grund in der Organisation auch da zu sein mit sicherlich auch kritische Geschäftsprozesse unter anderem abgebildet dort. Also das wäre für mich so ein Bestandssystem. Also Beispiele im ERP Kontext oder in unserem Umfeld im Internet, also Shop, E-Commerce Umfeld und so weiter und so weiter.

Stefan: Hast du mal ein Beispiel, was bei euch bei Phoenix Contact so ein Bestandsystem ist, was 10, 15, 20 Jahre oder noch länger bei euch im Betrieb noch genutzt wird?

Peter: Ja, also wie viele Unternehmen benutzen wir auch System für Product Lifecycle Management, für Product Information Management, für ERP-Prozesse und wir haben schon ein System für Product Information Management, der schon mindestens 20, wenn nicht noch länger, im Unternehmen sein Daseinsberechtigung auch hat.

Stefan: Jetzt sind wir ja vor einigen Jahren zusammengekommen, habe ich ja vorhin schon in der Einladung gesagt, dass wir uns schon ein bisschen länger kennen und auch zusammengearbeitet haben. Und der Grund war ja, ihr habt eine E-Commerce-Plattform namens Jeevis damals betrieben und ich sag mal, das war auch so ein Bestandssystem, was ihr dann modernisieren wollt. Wofür stand Jeevis, was war da so das Merkmal von Jeevis und was waren so die Treiber, dass ihr überlegt habt zu modernisieren?

Peter: Also ich war ja beim Entstehen von GWIS nicht dabei. Ich bin ja nach zwei Jahren, nach dem ersten Pilot dazu gekommen und diese Abkürzung, weil es schon mittlerweile durch CRISP ersetzt wurde, ist mir nicht mehr so geläufig. Also GWIS Global Web International Information System oder International Sales oder irgendwas.

Stefan: Information System oder sowas. Okay. Und ihr habt das System damals gehabt und dann war aber irgendwann mal die Entscheidung oder der Drang, das Bedürfnis, die zu modernisieren.

Peter: Ja, vielleicht ein bisschen weiter ausgeholt. Also Phoenix Contact hat schon früher erkannt, dass E-Commerce auch wichtig ist. In 2002 hat man damit mit den ersten Internetauftritten an sich, aber auch schon Webshops und ähnliches angefangen, international in Verbindung mit Bahn, damals auf einen nicht mehr geläufigen alten E-Commerce-Plattformen aufgebaut, 22 Shops weltweit, ganz viele Webseiten.

Die wurde zwischen 2006 und 2012 durch diese vorher genannten GUS-Plattformen entstanden. Diese GUS-Plattform basierte auf einem IBM WebSphere Portal plus weitere IBM-Komponenten wie ein Business Process Management System etc. etc. Also ESB, Enterprise Service Bus, so wie man es so klassisch kennt. Und zu der Zeit war das genau die richtige Entscheidung. Das waren State-of-the-Art-Technologien. Das waren auch gute Plattformen, um da weiterzukommen.

Mit spätere, immer mehr zunehmende Anforderungen hat man aber festgestellt, wo die Engpässe sind in so einem monolithischen System. Die Geschwindigkeit, mit dem wir Veränderungen machen konnten, die Deployments, die alle drei Monate von Downtime, von über dem Tag und so weiter. Also wir waren offline und wir sind international unterwegs als Phoenix Contact. Das heißt, wir haben ja auch Tochtergesellschaften in sämtliche Länder, wo auch sonntags gearbeitet wird. Das heißt, welcher Tag wirst du? Vielleicht Samstag, vielleicht auch Sonntag, aber das sind ja auch die Abhängigkeiten dort.

Es war auch on-premise gerüstet, das heißt auch richtig zu der Zeit. Das gab ja nicht ganz Vielfalt an Cloud-Angeboten, wie es heute gibt, auch die Technologien im Cloud. Genau, diese damals Cloud-Wolke, was ist denn das? Irgendwie was abstraktes irgendwo im Himmel. Ob das jemals was wird, war meine Meinung damals. Auf jeden Fall, wo waren wir ja, genau.

Stefan: Dieses ominöse Cloud, ja.

Peter: Dann hieß es irgendwann mal, wir müssen auch mobilfähig werden, also bei Handys und Apps und so weiter, alles mögliche in 2015, 2016 rum, war das dann wichtig, ist auch nach wie vor wichtig. Dann haben wir uns das System angeguckt und haben gesagt, wenn wir das jetzt machen, mobilfähig machen, dann ist ein komplettes Rebuild notwendig.

Jetzt haben wir eigentlich die Chance nochmal zu gucken, machen wir jetzt ein Rebuild auf dem Bestandssystem oder suchen wir uns auch eine neue Basis, auf dem wir aufbauen können, die auch skalierbar sein wird, die auch schon vielleicht auch für die Zukunft auch nicht so starr im Konstrukt ist.

Und dann haben wir uns natürlich mit Themen wie Microservices und Micro-Frontends und geguckt, was macht denn Amazon, weil sie ja auch schon Vorbild waren etc. etc. etc. Und haben ja in Zusammenarbeit mit INNOQ nochmal das ganze Thema Self-Contained Systems uns angeschaut. Und gedacht, da könnte auch was dahinter stecken. Hat nochmal tiefer reingeguckt, ein paar Hackathons gemacht und geguckt, was wir da so machen können. Und überraschenderweise oder auch nicht, ich glaube durch Überzeugung und gute Arbeit, hat das Unternehmen uns vertraut, auf diesen Basis wirklich mal so eine Re-Platforming zu machen. Im ersten Instanz über mehrere Jahre letztendlich unsere Bestandslösung zu migrieren auf diesen neuen Basis. Und denn da wo wir heute sind, 22, waren wir damit fertig. Und wo wir heute stehen, ist wirklich mal diesen neuen Basis zu nutzen und auch die Vorteile davon zu einzusetzen.

Stefan: Ich wollte mal nochmal, du hast vorhin schon mal was dazu gesagt, dass ihr international aufgestellt seid. Da habe ich so ein bisschen, glaube ich, den Eindruck, dass man den Zuhörern auch nochmal ein bisschen erzählen sollte, was Phoenix Contact überhaupt macht. Also was produziert dir, was vertreibt dir, in wieviel Ländern, in wieviel so ein E-Commerce-Plattform, das hört sich auch sehr groß an, wieviel Sprachen muss man unterstützen, wieviel Produkte, also einfach mal so diese Zahlengerüste. Was kannst du darüber erzählen? Was darfst du auch erzählen? Das ist natürlich auch vielleicht das eine oder andere etwas, was man nicht in der Öffentlichkeit erzählen darf.

Peter: Ja, klar, ich hatte es in der Selbstvorstellung am Anfang auch vergessen zu erwähnen, das stimmt. Die Föhniskontakt an sich, das ist ein Unternehmen, die ist 100 Jahre alt geworden letztes Jahr. Also 23 in Essen gegründet, ist nach Blomberg, also Provinzstadt Blomberg. Das ist irgendwo im Nordosten Westen von Nordrhein-Westfalen, also knapp an der Grenze zur Niedersachsen. Ein Ort, wer sucht irgendwie auch eine Karte zwischen Paderborn und Hannover.

Stefan: Genau. Ja.

Peter: Kann man ja sagen, mittlerweile ist das Unternehmen 22.000, 23.000 Mitarbeiter groß, mit einem Umsatz über 3,3 Milliarden im Jahr. Im Standort Blomberg alleine haben wir einen sogenannten Twinsight, möchte ich auch nochmal nachschauen, aber ich glaube Richtung 10.000 Mitarbeiter und

Stefan: Okay.

Peter: Genau, was wir herstellen, also unser aktueller Target, Ziel, Corporate Strategy ist, in diese sogenannte All Electric Society einzuzahlen. Das heißt, unsere Vision oder unser Bild von der Welt in der Zukunft ist, dass es denn nichts ohne Strom gehen wird. Und unser Motto und unser Streben ist wirklich in dem Bereich Environmental Footprint und so weiter auch schon einen Beitrag zu leisten. Und wie wir das machen, ist mit unseren Komponenten. Das heißt, als Unternehmen und Lösungen natürlich.

Als Unternehmen haben wir ganz viel Komponenten, die in verschiedene Zwecken, verschiedene Lösungen, Applikationen eingesetzt werden, zum Beispiel im Schaltschrankbrauch, das sind irgendwelche Reihenklemmen, Safety Relays oder Produkte, die von so einer Umwandlung von AC-Strom in DC-Strom, auch von eben so einer Schaltschrank, also alles was man so in einer Schaltschrank finden könnte, außer vielleicht den Schaltschrank selbst, kann man ja von Vönix kaufen, da sind auch weniger weitere Einsatzfelder, also weniger zu offensichtliche Produkte. Wir haben ja auch einen Bereich, es geht um Start-ups, die wir New Business nennen und die investieren in neue Technologien und ein Beispiel

Davon wäre gegründet in 2017, wenn ich mich nicht lüge, muss man nochmal nachschauen, ist das Thema E-Mobility. Ich glaube, das war sogar 2015. Da haben wir auch alles mögliche an Lade. Technologie ist eine hundertprozentige Tochter von Phoenix. Alles, was um die Elektrofahrzeugwelt sich dreht, was wir anbieten können aus unserem Portfolio.

Stefan: Ich fand es ja damals, als ich zum ersten Mal zu euch gekommen bin, beeindruckend. Phoenix Contact ist ja so ein Hitten-Champion, also familiengeführt und weltweit unterwegs. Aber man kennt den Namen nicht unbedingt, wenn man jetzt nicht direkt mit den Komponenten zu tun hat. Aber jeder, der so einen Ladestecker vielleicht in die Hand nimmt, hat vielleicht was von Phoenix Contact in der Hand. Oder wenn man irgendwie eine Haus-Elektrik, eine Hausinstallation macht, bekommt man das auch.

Peter: Mhm.

Stefan: Ja, ich fand es auch beeindruckend, was du gesagt hast, in Blomberg, man kommt dahin, auf einmal, sie steht mal vor so einem riesigen Campus mit alles modernen und tollen Leuten, ja, würde man gar nicht vermuten. Du hattest ja vorhin schon gesagt, global unterwegs, wenn ich mich richtig erinnere, 50 Länder, kommt das hin, 20 Sprachen mit über 100.000 Produkten, also das ist eine Komplexität, das ist jetzt nicht

Stefan: der Fahrradshop um die Ecke, worüber wir jetzt gerade reden, so eine E-Commerce-Plattform mit einer komplexen Produktvielfalt, auch mit solchen Dingen wie Konfiguratoren, die das Ganze auch noch mal ein bisschen besonders machen, was ihr da auf der E-Commerce-Plattform habt. Länder, okay. Okay.

Peter: Genau, also 50 Webseiten haben wir. Mehr als 50 Gesellschaften oder Locations weltweit. Einige davon benutzen unser sogenannten PC-Portei, also unser Phoenix Contact weltweit, Webshop. Deswegen sind wir um die 50 Internetauftritte in 27 Sprachen, glaube ich, oder ähnliches. Muss ich aber auch nachschauen. Es wächst und verändert sich, wie es denn sein soll.

Stefan: Genau.

Peter: Und wir sind im B2B-Geschäft unterwegs. Das ist vielleicht auch nicht so deutlich geworden, als ich unser Portfolio besprochen habe. Das heißt, wir machen keinen direkten Vertrieb an Kunden. Das heißt, man kann es nicht zur Obi fahren und nochmal vom Regal noch reingeklemmt von uns kaufen. Was man machen kann, das ist natürlich bei Conrad Online, Föhniskontaktklemmen bestellen als Privatperson, aber das ist so nicht unser Geschäftsmodell. Unsere B2B-Plattform oder unsere digitalen Kanälen sind ja viele und wie viele andere Industrieunternehmen auch, haben wir ja nicht nur einen Webshop, wir haben ja auch eine ganze Menge Umsätze über EDI, OCI und solche andere Möglichkeiten, digitalisierten Möglichkeiten auch schon anbieten.

Allerdings machen wir ja auch im Webshop auch einen großen Anteil unserer Umsatz, oder wir sind sehr stolz über den Anteil vom Umsatz, die wir damit erwirtschaften als Team. Was aber schon angedeutet ist, unser Unternehmen bietet Komponenten an, ja, aber ich hätte es auch angedeutet, auch Lösungen, auch große Lösungen. Das heißt, wir haben ja auch Teams, die jemanden, also so eine Windfarm oder ähnliches, aufbauen möchte, die auch schon unterstützen, unsere Produktprofolie auch gut erklären können und da auch Lösungen mit unterstützen. Aber auch schon individuelle Lösungen, das heißt, Konfiguratoren hast du das genannt, also Systemen, die integriert sind in den klassischen, neuen deutschen Customer Journey, wo man auf Basis von so einer Basiskomponente, Basisprodukt, individuell anpassen kann, sei es jetzt aus den physischen und elektrischen Eigenschaften bis hin zu Farben und Beschriftung und so weiter und so weiter. Das ist auch wichtig für unsere Kunden.

Und was wir auch in dem Plattformkonzept damals gemacht haben, ist, dass möglich gemacht, dass weitere Lösungen integriert werden können, sei es durch Security-Aligner, also Single Sign-On-Ansätze, aber auch Look and Feel, aber auch wir haben eine Applikation, die von einem anderen Bereich entwickelt wird für Ingenieure, also die nehmen so eine Tragschiene und können diese Tragschiene mit Komponenten befühlen.

Und die können es direkt im Prinzip in den E-Commerce-Plattformen übertragen und dann kaufen. Also das wäre eigentlich das Ziel. Und weitere Lösungen natürlich.

Stefan: Okay, das heißt, ihr habt jetzt, wir haben jetzt mal ein bisschen das Setting angeschaut. Ihr seid ein großes Unternehmen mit vielen Produkten, mit einer Produktvielfalt, was die Konfigurierbarkeit angeht, mit der Komplexität auch durch die verschiedenen, durch die vielen Länder und Sprachen, die man da jetzt unterstützen muss. Jetzt habt ihr gesagt, Jeeves passt nicht mehr, auch mit dem Hintergrund, dass man auch vielleicht moderne Technologien einsetzen will, dass man moderne Plattformen, neue Plattformen anbinden möchte.

Das heißt, die Haupttreiber waren, dass man Innovationen vielleicht nicht mehr so in diese alten Plattformen einführen konnte, wie man das gewohnt war. Und ich kann mich noch erinnern, ganz am Anfang, ich habe ja viel mit den Entwicklern gesprochen. Die waren, glaube ich, auch nicht so begeistert davon, wie wartbar das alte System über die Zeit sich verändert hat, sag ich mal, sodass man da auch was Neues gesucht hat. Jetzt habt ihr euch für was Neues entschieden. Wie war nochmal euer Vorgehen? Ihr habt jetzt gesagt, gut, das Alte passt nicht mehr. Jetzt habt ihr vorhin schon mal angedeutet, ihr habt euch mal angeguckt, was andere Plattformen so machen.

Wie seid ihr denn zum Beispiel jetzt auf diese Idee Self-Contained Systems gekommen? Silver Bullet.

Peter: Also wir sind, hatte ich so eingerissen in der Herleitung, aber wir sind ja… Ja, damals war Microservice in allem, also das war ja das Thema, das war die Lösung für alles, das war die vermeintliche Lösung für alle Probleme. Und dann entstanden natürlich auch schöne Schaubilder wie von, ich glaube es war Netflix, wo man die Abhängigkeiten zwischen den verschiedenen Microservices dargestellt hat und diese Darstellung der Komplexität in so einer umfangreichen Lösungsumfeld mit vielen Microservices und so weiter. Sicherlich hat seine Daseinsberechnung sicherlich auch wichtig, aber wenn du ein komplexes System für B2B von alles mögliche am Marketing bis hin zu After Sales und alle möglichen Services abdecken willst und weiterentwickeln willst und du machst für jede Mikrokomponente einen Service und dann fängst du an, jeder Service ist irgendwie für alle anderen verfügbar und so weiter und so weiter. Dann kommst du in ein Umfeld rein, wo du die Komplexität nicht mehr beherrschen kannst.

So und suchten wir und dann war einer unserer Lead-Architekten.

Wenn du zuhörst, Michael Blank, er kannte INNOQ und hat gesagt, guck mal, die haben da so irgendein Konzept entwickelt, das vereinfacht das alles ein bisschen. Also macht das beherrschbarer. Das heißt, du teilst ein System in dein Domain auf und kapst die Komplexität von verschiedenen Domänen innerhalb eines sogenannten Self-Contain System. So, wir haben uns nochmal angeschaut und nochmal in, hatte ich auch vorhin, gesagt, so Hackathon-ähnliche Format, die Ansätze ausprobiert. Verschiedene, er hatte auch Micro-Frontends und so weiter auch verschiedene Strategien entwickelt, wie wir vielleicht eine Migration machen könnten und ja, ich weiß nicht, ob ich die Frage richtig beantworte, aber dann war für uns einfach diese Zwischenlösung

Eine mögliche Antwort auf diese Fragestellung, wie machen wir unser System so skalierbar, so veränderbar, ohne dass wir auf diesen Einschränkungen von das IT-Legacy-System uns einkaufen müssen, sprich nur noch Maintenance und drehst, kennt vielleicht auch jeder, der zuhörte, der das mal gemacht hat mit so einem großen monolithischen System, drehst du links an einer Schraube, fällt rechts alles runter und

Hier wollen wir sagen, okay, ist okay, wenn es links die Schraube dreht und links runterfällt. Aber rechts soll möglichst davon nichts merken. Und das haben wir auch geschafft mit so einem System.

Stefan: Ich habe dich vielleicht ein bisschen aufs Glatteis geführt mit der Frage, was ich so ein bisschen im Hinterkopf hatte. Was ich immer beeindruckend fand bei euch war, dass nicht die Technik im Vordergrund stand, sondern erst mal die Fachlichkeit, erst mal das, was man mit der Technik erreichen möchte. Er hat nicht gesagt, wir müssen einfach nur die Technik neu organisieren, sondern ihr habt euch von Anfang an auch über Customer Journal Gedanken gemacht, über die Domain Architektur, über die Fachlichkeit.

Peter: Hm.

Stefan: Und dieses Konzept einer neuen E-Commerce-Plattform habe ich immer wahrgenommen, ist ein Teil eurer Strategie. Ihr habt ja auch eine neue Abteilung, einen neuen Bereich gegründet, DXM. Wofür stand das DXM? Was ist so die Idee, wo diese Plattform dann eingebettet ist?

Peter: Die XM ist eine schöne Abkürzung, genauso wie unsere Crisp Continuously Relaunchable International Sales Platform. Die XM ist Digital Business Experience Management. Und wie das schon etnischerweise gesagt ist, fehlt vielleicht ein bisschen in der Erklärung die Domain, die wir gewählt haben worden. Die Domain entlang der Customer Journey von Explorer bis hin zu Customer und After Sales. Und die Schritte dazwischen. Das war unser Domainschnitt und wir haben Teams aufgebaut entlang dieser Domain, also mit Product Ownern, also Agilenteams, mit alles mögliche an Fähigkeiten, die so ein Team braucht, mit den Schwerpunkts aus dem Domain heraus. Für mich, also wir haben wirklich die Vorteile einer, viele Erfahrungen aus dem Agilium-Kontext noch einen Schritt reifer gemacht und wirklich cross-funktionalen Teams, die in der Lage waren, selbstständig an diesem, das war auch ein Vorteil vom SES, dass muss ich auch dazu, dass man ja auch wirklich um diesen System die Skills auch aufstellen kann, um diesen System selbstständig, eigenständig weiterzuentwickeln. Und was es auch noch für Vorteile gibt, Business-Kontext ist, wo sind mein Cash-Gaue, mein Produkt an langer Customer-Genie? Wo sind die Kunden eigentlich oder die Nutzenden unterwegs? Die sind ja bei uns als Beispiel hauptsächlich, kommen auf den Plattformen, gehen in den Suchlis rein, suchen irgendwas Produktspezifisches. Wir sind ja ein Produkthersteller und da muss man ja um das Thema Produkt, da können wir ja, das ist unser großer Fischnetz, wo alle möglichen Fischereien schwimmen können und da müssen wir auch schon möglichst viel machen, damit wir auch die Fische fangen und die auch weiterführen zum Kauf oder zum Weiterempfehlen usw.

Stefan: Schönes Bild.

Peter: Und das gibt uns so eine Möglichkeit entlang dieser Journey mit diesen Systemen dort zu investieren, dort zu skalieren, dort als technische Perspektive dort mehr CPU einzupacken, damit Performance auch hat versus vielleicht ein Download von irgendeiner Preisliste oder irgendein Brancheur oder sowas ähnliches.

Stefan: Wenn ich mit Kunden rede, dann berichte ich gerne über die Arbeit mit euch zusammen, weil ihr habt das SCS-Konzept wirklich wie aus dem Lehrbuch umgesetzt, weil das halt aus der Fachlichkeit getrieben ist, wenn man die Organisation mitnimmt. Und ich habe damals auch erlebt, dass DxM quasi so eine Art Start-up innerhalb von Phoenix Contact war. Was war denn das Besondere von diesem Start-up-Charakter von DxM innerhalb von Phoenix Contact? Du hast schon ein bisschen angesprochen mit agiler Arbeitsweise.

Peter: Das eine der Besonderheiten war sicherlich das, dass wir sehr flach strukturiert waren. Wir waren Teams aus verschiedenen Unternehmensbereichen, damals zumindest, und wurden aber als ein Team zusammengebracht. Also es gab nicht diese klassischen Organisationsgrenzen, Auftraggeber, Auftragnehmer, sondern wirklich ein

Stefan: Mhm.

Peter: Ihr seid jetzt verantwortlich dafür, diese neuen E-Commerce-Plattformen aufzubauen, als logisch virtuelles, zusammengehöriges Team. Aber die Arbeitsweisen im Agilen-Kontext, flache Strukturen, Entscheidungswege, schnell. Also alles, was man ja im Lehrbuch unter Vorteile von Agilen auch liest, haben wir versucht und auch zum großen Teil mit der Herausforderung, auf die ich gleich angehen würde, in so eine große Organisation zu stemmen. Also das war auch das, also wir haben ja auch ein anderes Gebäude angemietet für die Zeit, Industriestraße, also gut in Erinnerung geblieben, da waren wir auch, hat ja auch Nachteile gehabt, aber die Vorteile waren, wir waren als Einheit dort und wir haben auch

Stefan: Genau, das ist total toll. Kurze Wege und und und.

Peter: kurzer Wege und die Kommunikation war direkt und wir haben viel Consultants da gehabt und die haben wir auch Arbeitnehmerüberlassung konform integriert in unsere Arbeitsreisen. Und das war wirklich viel Besonderheit. Man muss ehrlich sagen, wir sind zurückgezogen in unser Campus und viele dieser

Stefan: Natürlich.

Peter: Werte, natürlich verliert man etwas an Werte, aber viele dieser Werte der Zusammenarbeit sind nach wie vor da. Wir haben uns als Organisation verändert. Es sind Leute gekommen, Leute gegangen. Wir sind nicht mehr so stark von Consultants abhängig wie früher. Man verliert auch etwas am Wissen, aber gewinnt man an Erfahrung. Und es ist auch so eine Sache, wo wir gehen, aber als Team.

Stefan: Mmh.

Peter: Die Welt geht ja auch so ein paar Krisen durch. Corona ist nur ein Beispiel davon. Wir als Team sind auch ins stürmige Gewässer gekommen, aber unser Schiff war immer sehr stabil unterwegs. Gewackelt immer, aber sehr stabil.

Stefan: Ich will noch ergänzen, man verliert nicht nur Consultants und Wissen, man verliert auch Menschen, weil ich glaube auch das macht etwas aus, wenn man zusammenarbeitet, dass Menschen miteinander zusammenarbeiten. Das habt ihr, glaube ich, ganz gut hinbekommen bei Fearless Contact. Also ich bin DxM in der Industriestraße, muss ich wirklich aus eigener Erfahrung nochmal sagen.

Und das, was ich halt auch mitnehme, ist das, was man so oft hört. Man muss die Organisation mitnehmen. Das war bei euch in der Industriestraße mit den ganzen engen Zusammenarbeiten, war das wirklich top. Also, dass die Leute da auch in ihrer Denkgewiese zusammenarbeiten, wie die Organisation sich aufstellt, mit Marginen zusammenarbeiten. Dass es nicht nur Technik ist, die man bei der Monetisierung betrachten muss, sondern auch Menschen. Weil am Ende arbeiten Menschen miteinander. Jetzt habe ich damals bei der, also bei dem Start haben wir ja SCS vorgestellt, die Domain Architektur. Dann hat man angefangen, recht pragmatisch. Also nicht irgendwie lange, drei Monate lang Konzept, sondern man hat einfach mal gestartet und ist darauf losgegangen. Jetzt haben wir ja zusammen gestartet mit so einer On-Premise Installation. Und irgendwann kam so mal die Idee, wir müssten in die Cloud. Woher kam das, dass man da in die Cloud wollte? Und wie war so die Erfahrung mit diesem Umstieg von On-Premise in die Cloud? Weil viele Firmen stehen ja auch vor der Entscheidung, wollen wir in die Cloud, was ich herausfahre, welche Fragestellungen geben sich da, wie seid ihr da mit oder wie seid ihr da drangegangen? Ja.

Peter: Gerne, aber erlaub mir einen Satz vorher zum Thema Organisation. Und zwar, ich glaube, das wird oft unterschätzt, dass ein erfolgreiches Projekt nicht nur technologisch getrieben sein kann oder auch organisationsgetrieben sein kann. Die müssen im Einklang miteinander arbeiten. Und für mich war wichtig, auch das Thema Organisation an das System anzupassen, statt das System an die Organisation anzupassen.

Stefan: Mhm. Ja, ja.

Peter: Das Inverted Conways und so weiter und so weiter. Ich glaube, da ist noch einiges am Potenzial da drin. Wenn man seine neuen Vorhaben nochmal nimmt, guck nicht, was habe ich heute und versuche ein System dahin zu bringen, sondern wo will ich sein, was ist für mich wichtig und die Organisation an dieses System anzupassen. Also es ist ein kleines Hobby von mir, zu gucken oder die beiden Dinge miteinander in Einklang zu bringen, Organisation und System, weil nur dort hast du die Potenziale, um da Effizienzsteigungen zu machen oder Kommunikationsverbesserungen beizuführen und so weiter. Wenn die beiden miteinander in Einklang gebracht werden in der Entwicklung, in der Konzeptphase und nicht als nach Betrachtung, sondern auch in der Auswahl von einer Lösung, einer Komplettlösung, einer Hybris oder so weiter. Sollte man wirklich mal sich anschauen, was bedeutet es für die Organisation, nicht nur während des Projekts, sondern auch im Nachgang. Das wollte ich einmal so mit reinwerfen. Das war auch ein Teil der Entscheidung, in Cloud zum Beispiel zu gehen. Also ich möchte gerne am liebsten sagen, es war alles meine Idee.

Stefan: Mmh.

Peter: Mein Beitrag war wirklich in unseren Prinzipien zu sagen cloud ready in der Entwicklung, weil als Industrieunternehmen in 2017, 2018 war man noch ein bisschen zurückhaltend, was das Thema Cloud angeht. Aber unser Unternehmensbereichsleiter für das Thema IT, Guido Küster, der hat mit uns in 2018, also uns heißt der Lars Keltmann, unser Cloud-Architekt, mit mir mal zusammengesessen und gesagt, okay, wir sind jetzt offen dafür, lass uns da mal AWS mal ausprobieren, als Teil der Cloud-Strategie, stand auch eine ganze Zeit ihre Cloud-Strategie und nehmt eurem Plattformen und bringt das in AWS rein. Wir haben ja begrüßt und zum Glück, wie gesagt, waren wir ja schon in 2017 beim Konzeptphase schon dabei und haben gesagt, jetzt muss Cloud ready, also Cloud first bei Design, bei Lösung, also Container, alles mögliche an Themen. Das war für uns gesetzt. Also wir wollten nicht wie klassisch entwickeln und sollten cloudworthy sein. Und das hat uns wirklich in den Karten gespielt in 2018. Es hieß machen Migration in der Cloud. Alles was wir dahin gemacht haben, also ein halbes Jahr Arbeit in der Entwicklung. Da haben wir in zwei drei Monaten alles mögliche in AWS migriert und haben seitdem alles in der Cloud genommen.

Stefan: Fand ich damals auch, ich hab das ja das hautnah mitbekommen, auch sehr beeindruckend, wenn die Entscheidung mal getroffen hat, wie schnell das auch gehen kann. Man denkt immer, das dauert lange und man muss da alles töten. Aber wenn man das mal getroffen hat und die Leute sich dransitzen, dann ist es gar nicht so eine riesen Aufgabe, mal von On-Premise, die schon da war, einfach in die, nicht einfach, aber in die Cloud umzuziehen. Und es hat, also so wie ich das mitbekommen habe, reibungslos funktioniert, weil die richtigen Leute an den richtigen Stellen, unter anderem auch der, der mir gerade gegen Besitz da ist und die Ideen da reingeworfen hat.

Eine Sache, die … Sorry, wolltest du noch was sagen? Ja. Genau, ja.

Peter: Ich muss dazu ergänzen, dass das Thema. Ja, ich stimme dir auch mit Einschränkungen zu. Was ich nicht stellen würde, ist, wenn ich glaube, ich baue mein Rechenzentrum in der Cloud auf. Also ich installiere überall, im AWS Kontext zu bleiben, überall EC2 Instanzen auf und dann installiere dort mein Oracle oder dort mein Middleware. Sondern was wir auch gemacht haben, ist neben den Prinzipien Cloud First, war auch Managed Service First. Das heißt, Cloud Anbieter haben Hunderte, wenn nicht Tausende von Menschen, die in dem Rechenzentrum stehen und auch Patches in irgendwelche Betriebssysteme einspielen, die Updates auf Postgres machen, die auch Container Engines, Kubernetes, ähnliche Umgebung auch betreiben.

Stefan: Mmh.

Peter: Ich habe mittlerweile fünf Leute im Ops-Kontext. Wenn ich alles mögliche auf EC2 installiert hätte, wäre ich genauso langsam, als wenn ich On-Premises gemacht hätte. Es ist immer dieser Mittelweg.

Stefan: Guter Hinweis, ja. Also ich glaube auch, dass es gibt ja so diese Fraktionen, die einmal sagen, wir wollen ein Menderlogin vermeiden und machen alles selber und wollen in der Lage sein, umzuziehen. Aber der Nachteil ist, dass man viele Vorteile, die man gerade durch den Weg in die Cloud bekommt, verliert, weil genau diese Managed Services, wenn ich gerade an dieses Thema Kafka denke, der Betrieb alleine, da braucht man schon Experten und wir haben ja auch eine Historie, was Kafka angeht. Das ist halt schon eine andere Nummer dann tatsächlich, wenn man das alles selber machen möchte.

Peter: Genau. Man hätte sonst RSS-Feeds nehmen können. Hat mir mittlerweile so ein Principal Consultant bei INNOQ erzählt. Zum Glück würde ich einfach jetzt behaupten, einfach mal in dem Fall gesagt, nicht schnell, sondern richtig. Und dann haben wir gesagt, was wollen wir in zwei Jahren mit so einem Bus-System auch mal, ein Messaging-System auch erreichen wollen. Wir wollen ja auch High Availability haben. Wir wollen auch

Stefan: Zum Beispiel.

Peter: Guaranteed Delivery, diese ganzen Dinge und auch nochmal neue Use Cases schnell mit aufnehmen, Integration und so weiter. Genau.

Stefan: Ja, das Wort, was da ja damals gefallen ist, ist diese Datendrehscheibe, die man da etablieren wollte, aber auch gerade die Anbindung vom Backendsystem, vom Headquarter, weil ihr seid ja in der Cloud, aber ein Teil der Systeme sind ja immer noch im Headquarter, also gerade so Produktinformationsmanagementsystem und so weiter. Man muss aber jetzt auch mal sozusagen zur Ehrenrettung der Beratung, dass auch diese Managed Services damals halt noch nicht existierten. Also wenn man Kafka, wir hatten ja auch überlegt, wie man das betreiben kann.

Und das war natürlich damals auch die Zeit, wo dieses MSK, also Managed Service Kafka, von AWS kam, was natürlich dann viele dieser Probleme obsolet gemacht hat. Aber ja, es ist ein Zeichen dafür, dass man auch selber überlegen muss, was man will und dementsprechend dann halt auch die Entscheidung trifft.

Ich habe noch ein anderes Thema, was ich auch sehr beeindruckend finde, gerade wenn es darum geht zu modernisieren, wenn man so diese alten Infrastrukturen aufbricht. Das, was du vorhin gesagt hast, Jeevis, das Vorgängersystem, alle drei Monate mal so ein Release und man muss dann irgendwie abstimmen, wann man das deployen darf bei vielen Ländern und so weiter. Ich kann mich noch erinnern an die Entscheidung von dir und auch diese Diskussion über Continuous Delivery. Wie war das damals so dieser Weg, dass man sich auch einmal traut, das automatisiert neue Versionen ausgerollt werden.

Peter: Das ist ja natürlich so ein Mindset-Thema, also wie viele andere. Es geht ja ein bisschen an den Punkt von vorhin rein, also das Thema Innovationsgeschwindigkeit.

Also so ein Google, ein Amazon, ein Microsoft mit ihren ganzen Kompetenzen, die sehen, Kafka kommt, das ist unabdingbar, die setzen Teams drauf, die haben ja eine Innovationsgeschwindigkeit, die wir niemals haben können, für solche Themen. Und das Make-and-Buy-Ansatz, die wir auch noch als Prinzipien haben, da gucken wir mal hin. Und was leitet man davon ab für unser Interim? Wir sagen auch, wir wollen Innovationsgeschwindigkeit haben, wir wollen Dinge ausprobieren, wir wollen auch Ineffizienzen und so weiter aus dem Weg räumen. Aber wir wollen an Qualität steigen. Das heißt, wir wollen ja auch nicht einerseits nicht ewig auf einer kleinen Feature warten oder eine Textänderung, weil ein Fehler im Text drin war. Also nicht drei Monate oder zwei, sondern sofort.

Aber wir wollen in dem Moment, wo eine neue Funktion oder Funktionsblock fertig ist, das zur Verfügung stellen. Und das machst du auch mit dem Self-Content System im Shopping-Kontext. Irgendwas Neues da ist, wird Shopping aktualisiert und braucht Details und alles Mögliche, was dazugehört. Wird nicht von betroffen, ist isoliert und so weiter. Auch wieder ein Vorteil der SES-Paradigma.

Stefan: Mhm.

Peter: Und diese Mehrwertdienste an den Kunden zu bringen, das ist eigentlich das, was du mit Continuousq Delivery erreichen kannst. On top hast du erste Insicht und du zwingst quasi die Organisation an Qualität zu denken, an richtige Meilensteine innerhalb der Pipeline zu arbeiten, damit auch Fehler vermieden werden, dass sie auch rechtzeitig erkannt werden, dass sie nicht deployed werden, also End-to-End-Testing.

Peter: Als ein Beispiel. Ja, genau. Das sind wir so. Gerne.

Stefan: und dass man das in die Build Pipelines direkt einbaut, dass dann diese Qualitätssicherung da quasi automatisiert abläuft und nicht jemand manuell testen muss irgendwie, ob der Knopf funktioniert, sondern dass man möglichst automatisierte Entwicklungsabläufe hat.

Du hast gerade eben gesagt, SCS, was dahintersteckt ist ja diese Modularisierung, dieses Mindset, dass ich eine Anwendung, auch wenn sie aus mehreren Teilen besteht, nur teilweise aktualisieren kann, weil sie halt ein Modul ist und es trotzdem noch funktionieren kann. Und ich fand, und das ist so ein bisschen das, was ich gerne mitgeben möchte, ich fand das beeindruckend damals. Es war so ein, ich will nicht sagen Misstrauen, aber so eine Skepsis, ob das wirklich funktioniert. Und ich kann mich erinnern an das Treffen, wo du gesagt hast, wir machen das jetzt.

Und wir haben es gemacht und es hat funktioniert. Und die Leute alle dann so, ja, es funktioniert. Also natürlich hat es hier in Damar geruckelt, aber das Prinzip hat funktioniert. Und es ist, glaube ich, auch so ein bisschen ein Learning. Man muss sich auch trauen, die Dinge einfach mal zu machen, weil man sonst das, was du vorhin gesagt hast, diese Innovationsgeschwindigkeit, dieses agile Arbeiten natürlich dann nicht so in dem Umfang umsetzen kann, wenn man das nicht tut.

Peter: Ich bin ja auch ein Verfechter und ich versuche das auch, wo es passt, nach dem Motto Ask for forgiveness rather than permission und ich glaube schon, dass das auch ein

Stefan: Ja. Ja.

Peter: Wenn man ja in diesem Kontext SES und die verschiedenen Unterkomponenten nochmal denkt, man reduziert die Risiken für einen bestimmten Deployment, um an dem Beispiel zu bleiben. Und wenn der Risiko auf ein Minimum reduziert ist und ich ein Risiko eingehe, das zu deployen, mit allen Qualitätssicherungsmaßnahmen und so weiter, dann entwickle ich auch ein Mindset von, ich kann Dinge ausprobieren, auch mit. Das ist auch so das Thema in dem SCS-Umfeld der Modularisierung. Es gibt sicherlich andere, ich will ja nicht nur Werbung für INNOQ machen, es gibt sicherlich auch andere Modelle. Also das kommt eigentlich aus dem Domain Driven Design Kontext. Aber die, genau, ich weiß gar nicht, ob ich da in dem Frage Kontext noch bin, aber die

Stefan: Weniger, ja.

Peter: Die Vorteile, alle Vorteile, die es damals wurde, als alles so das Hype oder modern oder ein Kollege hat ja irgendwas mit Entwickler Wet Dreams, glaube ich, auch gepflegt als Begriff. Sicherlich waren es teilweise, aber ich glaube, so ein gewisser Blick für das, was uns nach vorne bringt und auch nachhaltig unterstützt, das muss man in so einer Rolle haben, die ich wahrnehmen muss. Und manchmal einfach diese Raising eingehen und Dinge einfach mal machen.

Stefan: Genau, einfach mal sich trauen.

Peter: Und auch entscheiden und nicht jetzt lange Diskussionen mit sämtlichen, provozierend gesagt, Halbwissenden ständig haben, die auch genauso wenig Ahnung haben wie ich, einfach mal machen, manchmal, weil es richtig ist, weil es vielleicht auch best practice ist, weil es andere tausendmal gemacht haben und warum sollte es bei uns nicht funktionieren, mein Setzer haben. Genau.

Stefan: Das nächste Thema, das ich ansprechen möchte, ist, ihr habt euch ja am Anfang auch dazu entschieden, von außen nochmal Expertise reinzuholen. Entwickler, Beratungen, Architekten. Was war der Treiber dafür und was war so deine Idee, was das auch mit den eigenen Leuten macht? Stichwort gemischte Teams auch.

Peter: Also was wir damals war das so, dass wir glaube ich auch von den Mitarbeiterzeiten, eigentlich unsere Kollegen in den USA, wir hatten sieben oder acht eigene Entwickler und dass das ein riesen Projekt sein wird, wenn wir auch mal die Ziele für zeitliche Ziele noch einhalten wollen, war es auch klar, dass wir Unterstützung brauchen. Was wir damals auch sehr bewusst entschieden haben. Eine Entscheidungsfindung ist nicht alleine auf Lösungsanbieter nochmal zu fokussieren, sondern auch aus Beratungshäusern mit Kompetenzen, die zu uns passen, nämlich auch von der zwischenmenschlichen, aber auch schon von der technologischen. Dann haben wir ja gesagt, wir ergänzen unsere Teams kurzfristig mit sehr viel Know-how aus dem Beratungsumfeld.

Stefan: Mhm. Mhm.

Peter: Aber die lang bis mittelfristigen, die haben wir auch geschafft. Wir sind ja natürlich in einer Veränderungsphase, gerade nach dem großen Projekt, wo das noch stärker sich auszahlen muss in der nahen Zukunft, unser eigenes Wissen anzureichen. Aber auch Wissen zu teilen natürlich. Also wir haben ja viel gelernt und der eine Kollege, der Eduard, wir haben ja auch gesagt, dass wir uns auch mal dafür Sorge tragen, dass wir selber so wie INNOQ werden, um euch wieder zu loben. Genau, Philip, das ist ja schon mindestens ein Bier schuldig für diesen Spruch, aber die

Stefan: Das wird jetzt meinem Chef wieder wie Öl runtergehen

Peter: Ja, eine von den Treibern war wirklich das Wissen da rein zu wohnen, aber da kommt noch eine gewisse Erwartungshaltung. Das muss man auch klar sagen. Es läuft nicht immer reibungslos. Manchmal passen die Menschen nicht. Manchmal sind die auch von den Skills nicht das, was wir brauchen. Und dann muss man ja diese ehrliche Beziehung zueinander auch entwickelt haben, wo man sagt, nee, der Herr oder die, die muss man jetzt austauschen, passt nicht. Das ist auch so die Methode, die wir haben. Und auch die Vertrauensbasis, die man ja auch geschafft hat über die Jahre.

Stefan: Ja. Ja. Also das Learning, was ich da auch mitgenommen habe, was ich ja selber erfahren habe, ist, wie stark eure Leute davon profitiert haben, dass von außen Impulse reingekommen sind, Expertise, Erfahrungen, Leute, die das schon fünfmal gemacht haben und dann nicht fünfmal in die falsche Richtung laufen, sondern dass man direkt schon miteinander die Dinge tun konnte. Und ich finde es beeindruckend, du hast ein paar Namen genannt.

Wie über die Zeit, ich habe das ja zum Teil auch mitverfolgen können, wie über die Zeit die Leute immer mehr von diesem Wissen eingesaugt haben, weiterentwickelt haben, auch ihre eigenen Impulse, das finde ich also wirklich beeindruckend. Und das ist, glaube ich, so ein Learning, was auch für andere auch nochmal so man mitgeben möchte, dass man nicht einfach nur Lösungsanbieter reinholt, die etwas hinstellen und dann wieder gehen, sondern dass man dieses Miteinander in gemischten Teams, diesen Wissenstransfer, diesen Erfahrungsaustausch auch pflegen sollte, wenn man so eine Modernisierung macht.

Peter: Mhm.

Stefan: Also das finde ich auf jeden Fall eine meiner wertvollen Erinnerungen in der Zusammenarbeit, was das mit den Menschen gemacht hat, die zusammengearbeitet haben. Jetzt seid ihr in der Phase, wo die Plattform aufgebaut ist. Sie wird jetzt betrieben. Jetzt ist natürlich nicht mehr diese heiße Phase, wo man was aufbaut. Aber jetzt hat man so eine moderne Plattform.

Bleibt ihr jetzt stehen? Macht ihr weiter? In welche Richtung macht ihr weiter? Was sind so eure Ideen, wie diese Plattform vielleicht nicht wieder 20 Jahre oder vielleicht nicht über mehrere Jahre zum Bestandssystem wird, sondern vielleicht immer innovativ und modern bleibt?

Peter: Es ist für alle Projektleitenden, die da gerade zuhören, klar, wenn das Projekt fertig ist, dann hört es auf und alle gehen zurück an den Schreibtisch und machen Powerpoints. Ist natürlich nicht so. Es ist auch immer Teil des Konzepts und steckt in den Namen Continuous. Ich glaube, Phoenix ist auch ein sehr guter Arbeitgeber zum einen wegweisend oder auch nach vorne schaut. Und es ist auch klar, dass es eine dauerhafte Invest ist. Und unsere Backlogs sind voll. Wir haben ja auch genug an neuen Themen, die auch einen Mehrwert bringen würden für den Kunden, für den Anwender. Das ganze Thema rund um natürlich Self Service, also wirklich neue User zu gewinnen, die auch vielleicht für deutschen Kunden zuhören. Wir haben eine richtig coole Quotation Tool. Da musst du ja auch gar nicht telefonieren und irgendwelche Sachen mit irgendwelchen Menschen, da kann es auch selber machen, dann geht es auch deutlich schneller. Also wenn dadurch auch die Conversion Rates erhöht werden, danke.

Stefan: Ja. Ja.

Peter: Unter anderem, alles Automatisieren. Einiges, was man aus dem B2C Kontext kennt als Kunde, so eine Anstandung zum Beispiel zu starten und solche Dinge, das haben wir ja alles. Aber daraus wollen wir auch mehr machen wie Cross Selling Themen. Also es gibt ohne Ende Potenziale und das ist das Thema,

Es wird neue Trends geben, es wird neue AI, es ist in allem underem eine persönliche Perspektive darauf. Ich bin froh, dass erstmal diese GPT-Hype ein bisschen aufgeflacht ist, dass wir das sinnvoll und vernünftig angehen können, das ganze Thema. Und nicht versuchen, so schnell wie möglich, irgendwas mal zu machen.

Stefan: Ich wollte es gerade sagen. Okay.

Peter: Hätte Vorteile, aber auch Nachteile im B2B-Kontext, weißt du selber, du bist involviert im B2B-Kontext, da muss man darauf achten, welche Antworten, auf welche Fragen wir überhaupt noch eine Antwort liefern wollen. Und das braucht seine Zeit. Aber wir haben ein Plattform geschaffen, wenn wir die Entscheidung getroffen haben, wie es weitergeht. Das integrieren können, ohne dass wir jetzt neue Lösungsanbieter für eine komplett neue Plattform suchen müssen, für eine neue Mittelwelle suchen müssen, der zufälligerweise unsere Wahl von 2018 meinte, diese Innovation nicht mitmachen zu müssen. So, solche Sachen. Ich bin ein bisschen abgeschritten von der Frage, glaube ich.

Stefan: Ich finde das aber gut, weil das ja auch noch ein bisschen links und rechts ist. Weg ist noch mal ein bisschen erklärt, was ihr euch da als auch vorgenommen habt mit der Plattform. Wenn du jetzt zu den letzten Jahren zurückblickst, gibt es Entscheidungen, gibt es Wege, die ihr genommen habt, die du heute, also abgesehen von dem Kafka-Thema, die ihr heute vielleicht anders treffen würdet?

Peter: Meinst du, ob ich RSS wieder nehmen würde? Das sind so Mikroentscheidungen, die wir vielleicht noch nicht hier in der Frage beantworten sollen. Ich glaube, wir sind sehr optimistisch gestartet. Wir haben an uns eine Erwartungshaltung gestellt, dass wir in unserem

Stefan: Das würde ich jetzt hier nicht so, aber…

Peter: Wir haben ja den Begriff Bestand irgendwann mal am Anfang. Unsere Bestandlandschaft, so MVP-Startup ähnlich vorgehen können. Genau, wir dachten auch, wir machen so eine kleine Mikrosite für eine bestimmte Tochtergesellschaft und entwickeln das weiter für den Rest der Welt. Ist ja natürlich nicht so. Also, unsere Kunden sind auch eine bestimmte Qualität und Umfang an Funktion.

Stefan: Mhm.

Peter: gewohnt. Wir sind in sechs Monaten mit der ersten Version fertig und so weiter und so weiter. Wären wir ein Startup gewesen, hätten wir es auch geschafft. Wir sind aber kein Startup. Wir sind eine riesengroße Industrieunternehmen und unsere Kunden haben da berechtigterweise eine Erwartungseite. Die Entscheidungen würden wir vielleicht auch anders machen. Weitere Entscheidungen, ich glaube, die

Stefan: Ihr habt das Ziel ja erreicht, das Ziel, das ihr euch gesetzt habt, ihr seid ja auch, oder wir sind ja bei der Deadline quasi auch über die Ziellinie gegangen. Es wurde ja keine Big Bang Migration gemacht, sondern es wurde ja quasi schrittweise und alle Länder wurden schrittweise ausgerollt. Da sind wir jetzt nicht so sehr drauf eingegangen, aber dieses Ziel haben wir ja erreicht.

Peter: Also.

Stefan: Und ich kann mich noch erinnern an den Vortrag von Uli Becker, auch hier noch mal schöne Grüße an den Kollegen. Da stand er vorne und hat dann erzählt, du bist nicht der Kunde, ich bin nicht der Kunde, sondern die da draußen sind die Kunden. Und wir machen das hier nicht für uns, sondern wir machen das für die Kunden. Das, was du sagst. Also die Kunden haben eine Erwartungshaltung. Kannst du so einen Einblick geben, ob die neue Plattform, wie die neue Plattform angenommen wird, intern als auch extern, ist da das Gefühl, ja, das ist ein signifikanter Fortschritt gegenüber dem alten.

Peter: Wir sind ja in Deutschland, wenn ich sage, wird gelobt oder so. Genau, genau.

Stefan: Nicht geschimpft ist genug gelobt, genau. Das schneiden wir

Peter: Also, ich würde einfach sagen, ich persönlich bin super stolz auf das, was wir jetzt geschaffen haben. Jetzt nicht für den Kunden geschaffen haben. Ich glaube, wir haben hier ein super moderner Angebot an Funktionen, an Look und Feel und so weiter und so weiter. Und jetzt werde ich gerade gestört von hinten. Obwohl die Tür zu ist, kommt jemand mit meinem Kaffee um mein Brötchen rein, obwohl ich spreche. Liebe vollgemein meine Frau, jetzt muss man kurz

Stefan: Sie kann auch gerne reinkommen, da schneiden wir raus. Alles gut.

Peter: Komm rein. Hallo. Hallo. Ich mache gerade eine Aufnahme. Ich könnte dir erzählen, dass ich heute einen Podcast mache. Oh, das tut mir jetzt… Oh, ich dachte, du… Sorry, sorry, sorry. Das muss man jetzt gleich rausnehmen. Ich habe wieder die Westen. Alles gut. Lässt mir hier hin, bitte. Oh, es tut mir leid. Oder ich lasse es drinnen. Deswegen hatte ich die Tür zugemacht. Oh ja. Sorry. Viel Spaß noch.

Stefan: So ist das. Das sind die Outtakes, genau. Wir hätten vielleicht auch schon Schluss machen sollen. Vielleicht ist das das Zeichen. Da machen wir eine kurze Pause, damit der Kollege die Möglichkeit hat, zu schneiden. Du hast gerade erzählt, dass du denkst, dass das eine moderne Plattform ist, dass die Technologien, die jetzt eingesetzt werden, auch zukunftsträchtig sind, dass man damit weiter ausbauen kann und Dinge anbinden kann.

Peter: Das sind die Outtakes für… Genau. Nochmal die Frage.

Stefan: Wir sind jetzt schon ein bisschen mit der Zeit relativ am Ende. Ich würde noch eins wie bei den anderen Interviews auch mal noch mal so eine Frage stellen. Ich habe gerade eben gefragt, ob du was anderes machen würdest. Was würdest du denn entscheiden, die heute vor der Frage stehen, ob sie modernisieren wollen, die vielleicht eine ähnliche Situation wie ihr vor fünf Jahren hatte, so ein altes System, wo man sagt, man muss eigentlich was tun, aber man hat jetzt ein paar Randbedingungen, man kann das System nicht einfach abschalten, man hat Erwartungen von Kunden. Wenn die heute vor der Frage stehen, modernisieren, was würdest du ihnen raten?

Peter: Machs einfach, das glaube ich. Das einfachste, also auf dem einfachsten Level, machs einfach. Also zögere nicht. Die Entscheidung, die du heute triffst dazu, egal ob es jetzt so ein SES oder ein Hybris oder sonst was, Ansatz wäre. Es ist die richtige Entscheidung für deinen Kontext heute. Also zögere nicht zu lange mit der Entscheidung, sonst ist die Modellisierung von

Stefan: Mach’s einfach.

Peter: von heute, wenn du es heute nicht startest, in einem Jahr startest, dann hast du ein Jahr verpasst. Also das ist so das erste. Und was ich auch sagen würde ist Organisation.

Peter: Denkt an die Organisation, denkt nicht nur an ein System, wir sind ja oft aus vielen Zuhörenden, die sicherlich aus einem IT-Background haben. Einige davon sind sicherlich auch sehr bewusst, welchen Impakt so eine Organisation hat auf so ein Projekt. Genau, tapfer bleiben, mutig sein und einfach mal machen.

Stefan: Das, finde ich, beschreibt auch sehr gut, wie du die letzten fünf Jahre dieses Projekt zum Erfolg geführt hast. Das finde ich gut. Peter, wir kommen zum Schluss. Vielen Dank für deine Zeit. Vielen Dank auch für die Einblicke, wie die letzten Jahre bei euch in Ammonisieren gelaufen sind. Ich bedanke mich. Ich hoffe, dass wir uns bald wieder auch persönlich sehen und sage an der Stelle schönes Wochenende schon mal und vielen Dank auch an die Zuhörerinnen und Zuhörer, dass ihr euch eine Stunde lang das angehört habt. Vielen Dank. Tschüss, Peter.

Peter: Danke, Stefan.

Director Engineering Digital Business Platform

Peter verantwortet als Director Engineering Digital Business Platform die Entwicklung der E-Commerce-Plattform von Phoenix Contact.

Principal Consultant

Stefan arbeitet als Principal Consultant bei INNOQ Deutschland und besitzt mehr als 35 Jahre Erfahrung in der Software-Entwicklung. Sein aktueller Schwerpunkt liegt in dem Aufbau von web-basierten Anwendungssystemen. Der Einsatzbereich erstreckt sich über die Strategieberatung, die Systemkonzeption, den Architekturentwurf, die Softwareentwicklung bis zur Inbetriebnahme.