Wie Continental Lotus Notes und Domino durch Low-Code ersetzte
Die meisten Leute wissen es kontinental für ihr Reifengeschäft. Aber der Automobilhersteller hat sich zu viel mehr entwickelt und bietet jetzt Telematik, Elektromotoren, automatisierte Fahrtechnologien und mehr an. Heute beschäftigt Continental über 241,000 Mitarbeiter an 573 Standorten weltweit.
Mit der Erweiterung seiner Produktlinie traf Continental die strategische Entscheidung, mehr als nur ein Hardware-Hersteller zu werden, indem es sich zu einem IT-Unternehmen entwickelte, das auch Software anbietet. Die Bereitstellung von Dienstleistungen für seine Kunden, die ihre Software und Hardware nutzen, wurde zu einem zentralen Ziel des Unternehmens. Zu diesem Zweck beschloss Continental, sich eingehend mit Ersetzung von Lotus Notes und Domino.
Treiber für den Wandel
Ein wichtiger Treiber für den Wandel bei Continental war die Notwendigkeit, sich schnell und innovativ an sich ständig verändernde Märkte und Umgebungen anzupassen. Nicht nur die Kunden von Continental ändern ihr Verhalten und ihre Interaktion mit Technologie, sondern auch die Erwartungen ihrer Mitarbeiter an die Entwicklung von Apps.
Bei Continental sehen immer mehr Menschen, die nach Technologien suchen, um Probleme innerhalb des Unternehmens zu lösen, und gleichzeitig wissen wollen, wie sie diese selbst lösen können. Die Unternehmenskultur bewegt sich in Richtung einer Selbstbedienungsumgebung, wenn es um die Nutzung, Nutzung und Entwicklung von Technologien geht.
Vor der Modernisierung der Prozesse benötigte Continental ein bis drei Jahre bis zur Markteinführung seiner Produkte – je nach Komplexität der Technologie. Diese Verzögerung war eine große Herausforderung und ermöglichte nicht die nötige Flexibilität, um sich schnell an Veränderungen anzupassen. Continental fehlten nicht nur die Tools für die Entwicklung von Unternehmensanwendungen und die Fähigkeit, sich an ständig wechselnde Umgebungen anzupassen, sondern es fehlte auch eine Kultur für den Umgang mit Unsicherheit und Softwaremängeln.
Ein zweiter Grund für die Veränderung war Continentals Abhängigkeit von Lotus Notes und Domino-Legacy-Anwendungen. Das IT-Team war für die Entwicklung, Wartung und Verbesserung von Hunderten von Anwendungen verantwortlich, die auf Domino liefen. Legacy-Modernisierung und ein Ersatz für Lotus Notes schien unvermeidlich.
Nach der erfolgreichen Migration von E-Mail- und Produktivitätstools zu Office 365 versuchten sie, Prozesse zu implementieren, die sowohl im Netzwerk als auch in der Unternehmenskultur für mehr Agilität sorgen und so letztlich die Entwicklungsgeschwindigkeit steigern. Dieses Projekt befasste sich mit dem Kultur- und Technologiewandel, hinterließ aber irgendwie eine Lücke für alle Domino-Anwendungen.
Diese Lücke und die Notwendigkeit, alle diese Anwendungen zu ersetzen, veranlassten Continental, nach Alternativen zu Lotus Notes und Domino zu suchen.
5 Gründe, Lotus Notes und Domino abzulösen
Fleischers Entscheidung, Lotus Notes und Domino zu ersetzen, hatte fünf Gründe:
1. Latenz und Bandbreite
Bei einer auf Domino ausgeführten Anwendung kam es an entfernten Standorten in Asien aufgrund des deutschen Hostings zu Latenzproblemen. Benutzer mussten separate Laptops und Geräte kaufen, da das Klicken auf eine Schaltfläche in der Anwendung etwa 10 Minuten dauerte.
Die Anwendung fror oft ein und die Mitarbeiter konnten nicht weiterarbeiten. Der gesamte Prozess wurde entweder verlangsamt oder ganz gestoppt, was zu großen Herausforderungen für das Unternehmen führte und Benutzererfahrung.
2. Wartbarkeit
Continental hat eine stetige Nachfrage nach neuen Funktionen, die sie implementieren möchten. Dennoch mit der Technische Schulden Durch die Domino-Anwendungen wurde es immer schwieriger, eine einfache Funktion hinzuzufügen.
Die Wartung und Verbesserung dieser Anwendungen wurde zu einer großen Herausforderung. Wenn sie eine Funktion hinzufügten, gingen trotz gründlicher Tests 10 weitere kaputt, ohne dass sie es wussten.
3. Wiederverwendbarkeit
Continental wollte die Geschwindigkeit von Software-Entwicklungsprojekten steigern, indem es wiederverwendbare Komponenten. Mit Domino und dem ganzen Einmalcode wurde es nahezu unmöglich, bereits erstellte Elemente wiederzuverwenden.
4. Qualität
Continental muss die Qualität der von ihnen erstellten Anwendungen sicherstellen. Dies war mit Domino nicht nur eine Herausforderung, sondern erforderte auch einen enormen Aufwand und Investitionen. Wenn einer Anwendung Funktionen hinzugefügt wurden, dauerte es mehr als ein Jahr, nur um diese Funktionen zu testen, Fehler zu identifizieren, zu beheben und dies zu wiederholen, bis die Qualität den Anforderungen entsprach.
5 Lagerung
Bei Domino handelt es sich nicht wirklich um eine Datenbank, und Continentals Zugriff auf den Speicherplatz innerhalb der Anwendungen nahm rasch ab.
Da in einer Anwendung über 10 Jahre lang Daten gesammelt wurden, stießen die Domino-Anwendungen schnell an ihre Grenzen. Die Zyklen zur Bereinigung der Datenbank wurden immer kürzer und das Unternehmen stand vor der Notwendigkeit, Daten zu archivieren und Speicherplatz freizugeben, was sich letztlich auf die Geschäftsprozesse von Continental auswirkte.
Domino war vielleicht eine akzeptable Lösung, als Continental noch ein reines Reifenherstellungsunternehmen war, doch als das Unternehmen wuchs, wurden die Probleme mit Domino zu erheblichen Hindernissen. Infolgedessen wurde das IT-Team von Continental – das nah am Geschäft – einen Plan zur Modernisierung aller Domino-Anwendungen des Unternehmens zusammenstellen.
Bewertung der Alternativen
Mit dem bestehenden Plan zur Modernisierung der Altsysteme stand das Unternehmen an der Schwelle zu tiefgreifenden Veränderungen – nicht nur in Bezug auf die Technologie, sondern auch in Bezug auf Denkweise und Kultur.
Bei der Evaluierung von Lösungen stellte die Unternehmens-IT fest, dass ihrem Technologie-Stack eine universelle Plattform fehlte, die es ermöglichte schnelle Markteinführung. Sie wussten, dass sie neben ihrem vorhandenen ERP/CRM, Office 365/Sharepoint, domänenspezifischen Apps und benutzerdefiniertem Code eine fünfte Säule brauchten.
Genauer gesagt wollte Continental eine Plattform, die:
- Ist einfach und macht Spaß zu bedienen und von Geschäftsbenutzern verstanden
- Ermöglicht Wiederverwendbarkeit mit gemeinsamen Protokollen und Strukturen
- Sorgt für Qualität des Ergebnisses
In seinem Vortrag bei einer kürzlich Mendix World, erläuterte Fleischer die verfügbaren Optionen und warum sie nicht passt zu Continental:
Einheitliche Lösungen
Nach umfangreichen Untersuchungen kam Continental zu dem Schluss, dass eine Technologielösung nicht für jede Anwendung geeignet ist, da viele Anwendungen unterschiedlich aufgebaut sind oder unterschiedlich verwendet werden.
Vorhandene Technologien wiederverwenden
Nachdem Continental erkannt hatte, dass ein Einheitsansatz nicht funktionieren würde, versuchte das Unternehmen, die Anwendungen und Technologien zu clustern. Dabei wurde klar, dass einige Anwendungsfälle eng mit ihren Datensystemen verknüpft waren, wie zum Beispiel SAP, wo es sinnvoll war, SAP als Backend und Fiori als Frontend zu verwenden.
Allerdings waren die Liefergeschwindigkeit und die Wartungskosten unerschwinglich. Wenn es sich nicht um einen zentralen SAP-Prozess handelt, passt es nicht gut zu SAP.
Kommerzielle Standardlösungen (COTS)
Einige Anwendungen eigneten sich besser für eine COTS-Lösung.
Zum Beispiel, wenn die Prozesse spezifisch für eine bestimmte Domäne oder einen bestimmten Geschäftsfall sind oder wenn sie eine komplexe Geschäftslogik und mehr Zeit für die Entwicklung erfordern. Mit einer COTS-Lösung könnte Continental genau das Produkt kaufen, das sie benötigen, anstatt selbst etwas zu entwickeln oder eine bereits vorhandene Technologie wiederzuverwenden.
Allerdings konnte keine einzelne Standardlösung ihre vielen Anforderungen und Anwendungsfälle erfüllen – selbst mit all den domänenspezifischen Anwendungen im Portfolio von Continental, die eine gemeinsame Sprache verwendeten.
Benutzerdefinierte Builds
Wenn alles schief geht, können Sie immer eine maßgeschneiderte Lösung haben mit .NET oder eine andere traditionelle Programmiersprache, richtig? Sicher, aber diese Option ist teuer und mit hohem Aufwand verbunden. Es ist keine Lösung, die es einem Unternehmen ermöglicht, Änderungen schnell umzusetzen. Wenn die IT benutzerdefinierten Code schreiben muss, werden Geschäftsbenutzer weiterhin vom Entwicklungsprozess ausgeschlossen und verstehen eine in .NET geschriebene Lösung nicht.
Landung mit Low-Code
Nach einer Marktanalyse und der Identifizierung von Produkten und Anbietern, die die technologische Lücke schließen könnten, wandte sich Continental an Low-Code-Entwicklung.
Die Anbieter wurden vor Ort eingeladen, um eine Anwendung zu entwickeln und verschiedene Technologien anhand ihrer Anforderungen zu testen. Continental bewertete die Low-Code-Anbieter nach den folgenden Kriterien:
- Einfache Konfiguration
- So werden Anwendungen erstellt
- Die Menge an benutzerdefiniertem Code oder Add-Ons, die erforderlich ist
- Wie das Datenmodell aufgebaut ist und wie die Geschäftslogik festgelegt wird
- Wie gut die Technologie die ursprünglichen Anforderungen rund um Benutzer- und Zugriffsverwaltung, Integrationen, Anforderungs- und Workflow-Management, Automatisierung, Suche sowie Überwachung und Berichterstellung abdeckt
Continental entschied sich Mendix weil die Low-Code-Plattform:
- Aktiviert Zusammenarbeit zwischen Business und IT
- Ermöglicht ihnen, Lösungen schnell erstellen und iterieren
- Ermöglicht Ersetzen Sie veraltete Prozesse durch anpassbare, automatisierte Workflows
Eine neue App in nur 12 Wochen
Continental begann mit der Neuentwicklung einer 300-stöckigen Anwendung, Electronic Capital Request, in nur 12 Wochen. Mendixdauerte ein erster Umbauprozess mehr als ein Jahr. Continental beschleunigte den Prozess nicht nur deutlich mit Mendix, sondern sie verbesserten auch das Erlebnis für Endverbraucher dramatisch. Nutzer.
Bei der App „Electronic Capital Request“ handelt es sich um ein Tool zum Anfordern und Genehmigen von Budgets, das von 10,000 Personen regelmäßig verwendet wird. Das bedeutet, dass mit dieser Anwendung jährlich mindestens 10,000 Anfragen gestellt, genehmigt und bearbeitet werden.
Jedes Jahr werden der App rund 20 Gigabyte an Dateianhängen hinzugefügt. Da die App auf der Domino-Architektur basiert, erreichte sie sehr schnell ihre Speichergrenze. Aber mit Mendix, die App ist grenzenlos.
Umstellung auf Agile
Schon früh in der Arbeit mit MendixContinental hatte erfahren, Agile Methodik ist der Schlüssel, um im Laufe der Zeit maximalen Wert zu schaffen. Der Erfolg von Continental bei diesem Projekt war ein Argument für die unternehmensweite Implementierung von Agile. Das Unternehmen sieht enormen Verbesserungsbedarf, insbesondere beim Rollout-Prozess, dessen Entwicklung länger dauerte als die App.
Continental bereitet sich auf diesen Wandel vor, indem es spezielle Projektteams einsetzt, Mendix Entwickler, um sicherzustellen, dass Geschwindigkeit und Qualität den Standards entsprechen.
Was hält die Zukunft bereit?
Die Entwicklung von Continental ist ein Beweis dafür, dass jedes Unternehmen ein Softwareunternehmen werden muss, um zu überleben und zu gedeihen, und sie planen, dies auch weiterhin zu tun. Skalierung.
Continental verfügt nun über ein Team von internen Mendix Entwickler, die jedes Jahr wachsen werden. Als agiles, auf Low-Code fokussiertes Team werden sie Teile von Anwendungen und ganze Anwendungen selbst erstellen und verwenden Mendix als Plattform für Geschäftsbenutzer, um anzugeben, was sie benötigen, bevor sie ein Projekt an die IT übergeben.
Dieser Blogbeitrag wurde ursprünglich am 10. Mai 2019 veröffentlicht und mit den aktuellsten Informationen aktualisiert.