„Share and conquer!“ – IT-Trends für die „sharing economy“
„Das Internet, unendliche Weiten. Wir schreiben das Jahr 2018. Dies sind die Abenteuer des Projekts ‚Lets Share IT‘, das mit seiner 400 Mann starken Besatzung 5 Jahre unterwegs ist, um fremde Technologien zu erforschen, neue Märkte und neue Services…“
Können Sie sich vorstellen, dass eine Digitalisierungs-Erfolgsgeschichte so beginnt? Ich nicht.
Panta rhei
Wenn Sie das Zitat, das ich in der Einleitung paraphrasiere, sofort erkannt haben, durften Sie vielleicht wie ich als Kind in den 70ern nach dem samstäglichen Wannenbad „Raumschiff Enterprise“ sehen (den jüngeren sei gesagt: damals gab es ja nicht nur kein Netflix oder YouTube, sondern nicht mal Privatfernsehen – um nicht zu sagen: „wir hatten ja nichts nach dem Krieg“ ;-) ). In diesem Fall haben Sie im Laufe Ihres Lebens vermutlich nicht nur einige Projekte erlebt, wie ich sie karikierte, sondern haben auch im eigenen Alltag den ungeheuren Wandel der letzten 3 Jahrzehnte erfahren: PC-Revolution, Internet, Mobiltelefonie, Smartphones, zuletzt IoT.
In meinem Beitrag „Auf zu neuen Ufern“ beschreibe ich, dass Disruptionen sich oft nicht auf Technologien beschränken, sondern Wechselwirkung mit kulturellen Aspekten haben. Gesellschaftlich und volkswirtschaftlich hat ein massives Umdenken stattgefunden, das allgemein mit dem Begriff „sharing economy“ umschrieben wird. Besonders die junge Generation der „digital natives“ ist in eine Welt hinein gewachsen, in der Vernetzen und Teilen für sie normal sind, während es für uns Ältere noch vergleichsweise ungewohnte, wenn nicht beunruhigende Konzepte sind.
Diese Haltungen und Werte haben sich auch massiv auf IT-Projekte ausgewirkt: Im vorigen Jahrhundert (mein Gott, wie das klingt …) war umfangreiche Software noch ein großes Investitionsvorhaben: Langlaufend, überorganisiert („Wasserfall“), teuer (auch weil Symptome wie „Heldenprogrammierer“ normal waren; Leute, die sich selbst zu unentbehrlichen Kopfmonopole machten). Auch ein hoher Grad an Scheitern von Projekten war üblich und quasi immanent akzeptiert. Es ist verständlich, dass vor diesem Hintergrund niemand anzweifelte, dass man für das Nutzungsrecht an einem so teuren Investitionsgut wie Software horrende Lizenzen zu zahlen hatte.
Das alles ist schon lange infrage zu stellen. Und jeder, der mit Software zu tun hat, sollte das tun.
Urknall des Teilens
Anfang der 1990er erschien das Internet. Befeuert durch den Wunsch nach akademischem Austausch schuf es schnell weltweite Kommunikationsstandards und veränderte dabei Zusammenarbeit und Wissensaustausch stärker als jede Kulturtechnik (inklusive dem Buchdruck) zuvor. Konkretes Beispiel, das jeder schon erlebt haben dürfte: Statt bei Problemen Handbücher zu durchwühlen oder einen zufällig kundigen Kollegen zu suchen, bekommt man heute ganz selbstverständlich im Netz Hilfe – und zwar oft in Minuten und in professioneller Qualität. Ich habe vor kurzem den Federzug meiner Spülmaschine repariert. Hätte ich früher nicht mal im Traum dran gedacht.
Folgerichtig hat sich vor allem jene Profession diese Möglichkeiten zu eigen gemacht und sie ausgebaut, die damit ohnehin eng verwachsen ist: Die Softwareentwicklung.
Ermöglicht durch die neuen technischen Möglichkeiten und in Wechselwirkung mit ihnen traten zwei Ideen ihren Siegeszug an: die agile Softwareentwicklung und die Open-Source-Software-Bewegung.
Geteiltes Wissen ist explodierendes Wissen
Von individuellen Ausnahmen abgesehen gilt: Menschen kommunizieren gerne. Sie lieben es, Probleme zu lösen. Und sie genießen die Anerkennung in der Horde. Das gilt für Softwareentwickler im besonderen Maße, die ja nicht von ungefähr einen Beruf gewählt haben, bei dem man einer Maschine ständig Lösungen kniffliger Probleme beibringt. Ihr Können wollen sie so häufig wie möglich beweisen, am liebsten in enger Zusammenarbeit mit Leuten, die es schätzen können. Und apropos Zusammenarbeit: Nicht erst seit der agilen Entwicklung muss das Klischee des lichtscheuen, sich von Cola und Pizza ernährenden Nerds revidiert werden: In kaum einem Beruf wird bei der Arbeit mehr gelacht und lösungsorientiert kommuniziert als bei Softwareentwicklern.
Es ist kein Wunder, dass viele professionelle Softwarefirmen die darin liegenden Produktivitätsvorteile erkannt haben und ihren Teams entsprechende Rahmenbedingungen und Freiheiten geben. Das umfasst auch die Akzeptanz und Förderung von Open-Source-Software. Einige Unternehmen stellen ihre eigenen Softwareinvestitionen als Open-Source zur Verfügung, viele finanzieren Open-Source-Projekte, in dem sie Mitarbeiter dafür frei bzw. zur Verfügung stellen. Wie ernst es den Unternehmen mit dieser Kultur ist, lässt sich an der problemlosen Zusammenarbeit großer Mitbewerber erkennen: Als Google bei der Arbeit am Webclient-Framework Angular eine eigene Javascript-Transpilersprache entwickelte und feststellte, dass Microsoft mit seinem Typescript-Projekt schon weiter war, hat man ganz einfach die Arbeit der Projekte konsolidiert. Und das ist nur eins von vielen Beispielen, dass die Riesen der Branche vorleben, was sinnvoll ist.
Die großen und kleinen Player des Internet beteiligen sich an Open-Source aber nicht (nur), weil sie Altruisten sind, sondern weil sie wissen bzw. erfahren, dass transparente Zusammenarbeit die Branche als Ganzes stark macht und schneller voranbringt. Dieser Erkenntnis haben wir einen ungebremst riesigen Innovationsschub zu verdanken, dem einzelne Firmen mit abgeschlossener Produktentwicklung nichts entgegenzusetzen haben.
Hüter des verlorenen Schatzes: Die Enterprise-IT
Die dynamische Entwicklungswelt der großen und kleinen Internet-Player ermöglicht deren geschäftliche Agilität. Die Geschäftsmodelle im Internet beruhen auf dem Erheben von Daten, Verdichten und Versilbern von Informationen und der Integration der ganzen Welt. Die dargelegte Arbeitsweise ist für diese Unternehmen die wirtschaftlich sinnvollste – davon abgesehen, dass die meisten Internet Player im Gegensatz zu Firmen der Vor-Internet-Ära ja nie anders gearbeitet haben.
Anders sieht es aus, wenn man in typische IT-Abteilungen oder Softwareprojekte etablierter Nicht-Internet-Firmen schaut. Dort findet man häufig mehrere der folgenden Symptome:
- Eine überhaupt nicht oder nur bedingt agile Arbeitsweise (echte Agilität fängt wohlgemerkt nicht erst im Entwicklungsteam an)
- Ein viel zu geringer Automatisierungsgrad in den Prozessen
- Vergleichsweise hohe Aufwände mit Betreuung, Wartung und Integration der sogenannten Legacy bei gleichzeitigem Unvermögen diese zügig abzulösen
- Know-How-Rückstand von nicht selten 5–15 Jahren (bei Entscheidern häufig sogar weit darüber!); das betrifft nicht nur fehlende Kenntnis moderner Integrationstechnologien, sondern auch das Auslassen von Produktivitätspotenzialen
- Relativ hohe Fehlerquoten bei gleichzeitig nicht ausgeprägter Fehlerkultur
- Tendenz (vor allem bei Entscheidern), Open-Source-Software gering zu schätzen und „sicherheitshalber“ auf kommerzielle Produkte zu setzen
- … Ihnen fällt sicher auch noch was ein
Diese Liste ließe sich beliebig fortsetzen. Ich denke, Sie haben die Tendenz verstanden.
Von Kunden höre ich mitunter „Wir sind bisher ein XYZ (Unternehmen der jeweiligen Branche). Und jetzt müssen wir plötzlich Softwarelösungen anbieten. Davon haben wir keine Ahnung“. Dieses Problembewusstsein ist schon mal viel wert. Es ist bei Mittelständlern ausgeprägter als bei Konzernen…
Sehen wir den Tatsachen ins Auge: Viele Unternehmen, die mit Produkten oder Dienstleistungen ihr Geld verdienen, haben IT und Software vor allem für die Optimierung der eigenen Geschäftsprozesse verwendet, kamen aber schon damit kaum den Anforderungen hinterher. Ein klassischer Managementfehler ist auch heute noch, IT(-Abteilungen) eher als Kostenfaktor denn als Chance zu sehen. Oder kennen Sie ein Unternehmen, in dem die Mitarbeiter durch die eigenen IT-Systeme nahtlos unterstützt werden und nicht auf sie schimpfen?
„Wenn das sie Lösung ist, will ich mein Problem zurück“
Was ist die Erwartung, wenn im Rahmen der Digitalisierung diese Unternehmen nun plötzlich Lösungen entwickeln, bei denen Software und Integration im Mittelpunkt steht und den Hauptteil der Wertschöfpung erbringen sollen? Wenn IT-Abteilungen, die so aufgestellt sind wie oben beschrieben, Digitalisierungsprojekte durchführen sollen, ist das eigentlich zum Scheitern verurteilt. Das gleiche gilt übrigens für viele Softwarehäuser, die von Unternehmen beauftragt werden.
Der Grund ist nicht etwa, dass unbegabtere Experten am Werk sind, sondern dass diese Organisationen für ganz andere Aufgaben spezialisiert wurden, nämlich für Unternehmenssoftware. Sie werden jede Lösung, die sie angehen sollen, wie eine Enterprise-IT-Lösung denken, wodurch sie von Vornherein nicht wettbewerbsfähig ist, denn solche Lösungen werden von den Anwendern mit denen der Großen (Google, Amazon und Co.) verglichen und nicht mit den (oft suboptimalen) Anwendungen, die sie von der eigenen Arbeit kennen.
Das ist übrigens ein Problem, das nicht nur IT-Abteilungen haben. In meinem Beitrag „Customer Journeys statt Featuritis“ habe ich am Beispiel der Autoindustrie aufgezeigt, dass eine gewachsene Entwicklungsorganisation nahezu dazu verdammt ist, immer gleichartige Lösungen zu entwickeln. Nur wenn man sich dieses Problems bewusst ist, kann man eine sinnvolle Transformation anstreben. Wenn man es ignoriert, ist die Chance hoch, viel Geld, Zeit und Energie zu verschwenden.
If you want to share IT, you’ve got to mean IT
Wie sieht so eine Transformation aus, wenn es um Digitalisierung für die „sharing economy“ geht? Zur Erläuterung: Damit meine ich Softwarelösungen, die nicht nur der internen Prozessoptimierung dienen, sondern die auf den gängigen Plattformen massiv nach außen drängen und den Kunden einen Mehrwert anbieten, sich dabei aber nahtlos in seine sonstige digitale Landschaft integrieren.
Da solche Lösungen relevant anders sind als z.B. eine interne ERP-Lösung, muss man anders an sie heran gehen, wenn man Erfolg haben will:
- Orientieren Sie sich an den Richtigen. Nehmen Sie an, Sie wollen einen Sport wettkampfreif betreiben. An wem würden Sie sich eher orientieren? An Leistungssportlern in der jeweiligen Sportart oder an Sportartikelherstellern, bei denen Sie hochwertige Bekleidung kaufen können? Ebenso sollten Sie sich bei Digitalisierung eher dafür interessieren, was bei den großen und kleinen Playern im Internet gut (oder auch schlecht) funktioniert hat, als was Ihnen der Anbieter ihres kommerziellen IT-Systems erzählt. Denn letzterer wird sie tendenziell eher weiter in ein „vendor-lock in“ locken wollen, Ihnen aber sicher keine Dinge nahelegen, die für seine Produkte problematisch sind, auch wenn sie objektiv die beste Lösung wären. Bei den anderen liegt aber kein kommerzielles Interesse vor (außer dass die Digitalisierung insgesamt vorangeht), und das Internet ist eine riesige Fundgrube von Einführungen, success-stories, aber auch gewogenen Erfahrungsberichten für verschiedene Technologien – dabei denke ich nicht an Whitepapers oder offizielle Produktvideos, sondern an die Unmengen an Konferenzbeiträgen, Blogs u.ä., die zu verschiedensten Technologien frei verfügbar sind.
- Erkennen Sie die wesentlichen Trends. Damit meine ich nicht das Mode-Framework der Woche, sondern wirkliche langfristige Trends, die im Sinne der technologischen Evolution schlüssig sind und auf absehbare Zeit keine Sackgasse darstellen (einfaches Beispiel: REST über https mt JSON zeichnete sich schon früh als langfristig tragfähige Kommunikationsarchitektur ab, wenn man davon abweichende gar proprietäre Mechanismen einsetzt, sollte ma extrem gute Gründe haben). Weiter unten habe ich Ihnen einige Trends aufgezählt, die ich für aktuell relevant halte. Welche Trends für Sie bzw. Ihre Lösung relevant sind, können Sie nur selbst entscheiden. Wichtig erscheint mir hier eine mittelfristige Strategie für Ihre digitalen Produkte
- Probieren Sie Technologien aus bzw. schaffen Sie Ihren Mitartbeitern dafür Raum und Anreiz. Nur auf der Basis eigener Experimente entsteht das Wissen, das als Entscheidungsgrundlage dient. Zeitmangel darf dafür keine Ausrede sein. Heutzutage lässt sich eine neue Technologie in wenigen Stunden spielerisch erkunden und ggf. in wenigen Tagen in richtigen Spikes für das eigene Vorhaben auf den Prüfstand stellen. Es ist besser, auf diese Weise verschiedene Alternativen erproben, als Monate lang in eine falsche Richtung zu entwickeln, was leider immer noch viel zu viele Projekte machen
- Seien Sie mutig. Gerade in einer Zeit ständigen Wandels droht „analysis paralysis“. Aber irgendwann muss man anfangen. Eines meiner englischen Lieblingsattribute ist „opionionated“. Wenn Sie aufgrund der Schritte 1–3 zu einem Ansatz gekommen sind, den Sie begründbar für tragfähig halten, kämpfen Sie für seine Umsetzung, auch wenn man Sie als voreingenommen oder gar borniert halten mag
Wie jeder Veränderungsprozess ist das kein Selbstläufer und nicht vergnügungssteuerpflichtig, wie ich auch schon am eigenen Leibe erfahren durfte. Aber wenn es schon daran scheitert, sollten Sie besser keine Digitalisierungslösungen entwickeln und bei Ihrem bisherigen Geschäft bleiben.
Trends für Digitalisierungslösungen
Abschließend möchte ich Ihnen wie versprochen einige Trends aufzählen, von denen ich glaube, dass man sie berücksichtigen, zumindest aber kennen sollte, wenn man mittelfristig konkurrenzfähige Lösungen entwickeln möchte. Für Leser, die sich bereits sehr gut im Umfeld dieser Technologien auskennen, mag diese Liste trivial, ja wie eine Art Kanon, erscheinen. Aber ich stelle bei Gespächen mit IT-Experten, die zu lange in abgeschlossenen Kontexten gearbeitet haben, immer wieder fest, dass sie sehr häufig viele dieser Konzepte noch nicht einmal namentlich kennen geschweige denn anwenden könnten. Und dieser Beitrag dient ja vor allem dazu, solche Leser zum Erkennen und Schließen dieser Lücken zu ermutigen, bevor sie Digitalisierung mit nicht tragfähigen Technologien beginnen.
Bitte beachten Sie, dass diese Liste weder Anspruch auf Vollständigkeit noch eine allgemeingültige Priorisierung o.ä. legt:
- Reaktive Systeme: Darunter versteht man eine Bündelung bestimmter Eigenschaften, die dem Kunden auch bei wechselnder Last oder technischen Problemen einen gleichmäßig hohen Quality of service bieten. Unerlässlich für eine gute UX (User Experience). Vergessen Sie nie, dass Sie von Endkunden mit Google und Co. verglichen werden (s. hierzu auch https://www.reactivemanifesto.org/de)
- Nebenläufigkeit: Jedes System muss heute in der Lage sein, seine Arbeit effizient zu parallelisieren, um die aktuellen und kommenden Multi-Core-Prozessoren optimal auszunutzen. Ungeeignet ist programmiertes Multithreading während des hohen Laufzeit-Overheads, der unverhältnismäßigen Aufwände, des zu geringen Abstraktionsgrades und nicht gewährleistender Korrektheit. Setzen Sie statt dessen auf Implementierungen des Aktormodells wie Akka oder am besten gleich Erlang/Elixir, die auch weitere Vorteile wie strikte Isolation bringen
- Verteilung: Zur Erhöhung der Ausfallsicherheit (Redundanz) und Skalierbarkeit ist Verteilung eines Softwaresystems auf mehrere Rechnerknoten schon seit den ersten Cluster-Lösungen eine gängige Taktik. Durch die Cloud, mobile Devices und IoT wird sich diese Notwendigkeit verteilter Systeme massiv verschärfen. Dabei sollte man konzeptionell grundsätzlich zwei Ansätze unterscheiden. Bei einer Service-Architektur handelt es sich streng genommen nicht um Verteilung, sondern um die Kommunikaton zwischen konzeptionell schon im Entwurf getrennten Laufzeitsystemen. Besser ist die native Unterstützung von Verteilung eines Gesamtsystems, wie Sie z.B. Aktorsysteme mit dem Feature location transparency bieten, da das Verteilung ohne nennenswerten Overhead zur Entwicklungs- und Laufzeit bietet
- Asynchrone / Ereignisbasierte Kommunikation: In der verteilten, nebenläufigen Welt moderner Systeme hat das synchrone Modell eines linearen Kontrollflusses ausgedient und ist durch asynchrone Kommunikation ersetzt worden, in der Prozesse nur über den Versand von Nachrichten oder Ereignissen miteinander kommunizieren, nicht mehr über einen Callstack. Den Ereignissen kommt dabei im Entwurf eine besondere Bedeutung für einen flexiblen Entwurf zu, weil es der Realität näher kommt, dass Systeme (wie biologische Organismen, Maschinen oder Organisationseinheiten wie Unternehmen, Abteilungen u.ä.) auf Ereignisse reagieren und selber welche auslösen, statt einander „aufzurufen“
- Server-Sent Events (SSE): Für viele Anwendungsfälle ist der klassische Request-Response-Mechanismus von http noch ausreichend, zumal er modernen WebApps für den Benutzer unbemerkt und ohne „Seite neu laden“ funktioniert. Aber je dynamischer und vernetzter unsere Welt und je höher die Kommunikationsdichte wird, umso mehr wird es sich durchsetzen, dass Clients sich bei Diensten anmelden und von dort automatisch über relevante Events informiert werden. In Chatrooms und Online-Spielen ist das schon lange state-of-the-art. Je nach Anwendungsfall ist hier vor allem auf die Leistungsfähigkeit zu achten. Für die Channels des aktuell leistungsstärksten Webserver-Frameworks Phoenix wurden schon 2 Mio. aktive Sockets auf einem einzelnen Server erreicht.
- Funktionale Programmierung: Ein Programmierparadigma, das den Anforderungen unserer Zeit gerechter wird als die objektorierte Programmierung, da es auf die größte Fehlerquelle beim Programmieren (veränderliche Zustände) konsequent verzichtet und mit vielen der Mathematik entlehnten Konzepten eine sehr hohe Ausdrucksmächtigekeit besitzt. Allein durch die Einführung von FP lässt sich die Produktivität der Softwareentwicklung sehr deutlich und vor allem nachhaltig steigern. Siehe hierzu auch meinen Beitrag „Einfach, sicher, produktiv: Funktionale Programmierung“.
- Aktorsysteme: Darunter versteht man Systeme, die zur Laufzeit aus sehr vielen unabhängigen und voneinander komplett isolierten Software-Agenten bestehen, die nur mithilfe von Nachrichten miteinander kommunizieren können. Bekannt wurde dieses Modell auch durch die „Let it crash!“-Philosophie: Da Fehler eh nie vollständig zu vermeiden sind, werden die Aktoren in sogenannten Supervision trees hierarchisch überwacht und bei Abstürzen einfach neu gestartet. Aktorsysteme erlauben sehr komplexe, dynamische, verteilte Systeme, die dank dieser Grundprinzipien sehr leicht zu beschreiben und extrem stabil laufen. Eine bekannte Implementierung ist Akka (für Java und Scala). Aber der schlachterprobte Platzhirsch ist das aus der Telekommunikation stammende legendär leistungsfähige und resiliente Erlang. Dieses ist besonders interessant geworden, seit es mit Elixir eine extrem moderne Entwicklungsplattform erhalten hat, s. meinen Beitrag „Elixir: Zaubertrank für Digitalisierung?“.
- Persistente Streams: In einer asynchronen, verteilten Systemwelt, in der eine Transaktionssteuerung erheblich erschwert ist, sind hochskalierbare, verteilte, persistente Streams wie Apache Kafka an die Stelle zentraler transaktionaler Datenbanken getreten. Sie haben auch den Vorteil, dass sie den nahtlosen Übergang zu Realtime Data Analytics-Lösungen wie Spark erlauben
- Alternative Persistenzmechanismen: Aber natürlich werden Daten auch noch innerhalb von Systemen bzw. Services gehalten. Für viele Use Cases sind dabei die guten alten relationalen Datenbanken immer noch ein probates Mittel. Allerdings sollten moderne Entwicklungsteams auch die zahlreichen Alternativen kennen, die meistens unter dem Begriff NoSQL (für not only SQL) stehen und ganz spezifiche Stärken für besondere Zwecke haben (z.B. Graphdatenbanken für das Speichern und Durchsuchen von Netzwerken). Erwähnenswert sind auch die Patterns Event Sourcing und CQRS (Command and Query responsibility segregation), die ganz spezifische Stärken wie Wiederherstellbarkeit beliebiger Zustände und integriertes Audit log bieten
- Paketierung und Verteilung: Manuelles Aufsetzen von Servern und Deployen von Systemen erzeugte früher erhebliche Aufwände und Inkonsistenzrisiken. Mit Quasistandards wie Docker lassen sich heute Laufzeitsysteme deklarativ definieren (Configuration-as-Code) und effizient als Laufzeitcontainer verteilen und starten
- Automatisierung aller regelmäßig wiederholten Vorgänge (Erstellen, Testen, Ausliefern, Überwachen der Software), auch bekannt als CI/CD-Pipeline, ist ein Muss, wenn Sie eine kurze Time-to-market mit Qualität verbinden wollen – übrigens auch schon, damit sie im Falle einer fehlerhaften Auslieferung schnell und sicher eine Korrektur ausrollen können, ohne im Eifer des Gefechts das Problem zu vergrößern
- Open Source: Ich habe eingangs dargelegt, dass Open Source Software (OSS) heute ein Standard ist, dem sich alle kaum ein namhafter Player entzieht. Ich werde mir nicht die Mühe machen, die diversen Vorteile aufzuzählen, die sollte man am besten selbst erleben. Die einzige Gefahr, die ich bei OSS sehe, ist ggf. auf das falsche, sprich ein totes Pferd zu setzen (das kann einem aber bei COTS, commercial-of-the-shelf, auch passieren). Gerade bei OSS gilt: Probieren Sie viel aus, das geht dank GitHub und Co. schnell und kostet nichts. Vergewissern Sie sich aber vor einem ernsthaften Einsatz immer, dass das jeweilige Projekt aktiv ist oder (in Ausnahmefällen) dass sie es selbst weiter betreuen könnten. Und: wenn Sie selbst ein relevant neuartiges Grundlagenproblem lösen oder gelöst haben, geben Sie es an die Community zurück, damit andere avon profitieren oder dazu beitragen können
Auch diese Liste ließe sich vermutlich noch fortsetzen.
Zusammenfassung und Empfehlung
Offensichtlich ist das Format eines solchen Beitrags selbst dann zu kurz, wenn man diese komplexen IT-strategische Erwägungen nur anreißt. Wie schon bei meinen im Text verknüpften anderen Beiträgen zu Transformation habe ich versucht deutlich zu machen, dass Veränderungen stattgefunden haben, denen man sich stellen muss.
Um die Jahrtausendwende erzielte in Folge der PC-Revolution die Enterprise-IT einen Durchbruch mit Application-Server-basierten Lösungen. Die damaligen Trends zur Optimierung und Flexibilisierung der IT hießen z.B. EAI (Enterprise Application Integration) und SOA(Service Oriented Architecture). Wer damals nur auf dem Wissensstand der Großrechner und COBOL-Ära agierte, war nicht mehr wettbewerbsfähig.
In den letzten 20 Jahren haben wir einen riesigen Innovationsschub um hochleistungsfähige Internetlösungen und Mobile Devices erlebt. Wer in diesem Markt Fuß fassen will, sollte es wiederum nicht (nur) mit dem Know-How von Enterprise-IT machen (dass Sie dieses Know-How brauchen, um ggf. Ihre mittlerweile zur Legacy gewordenen Backend-Prozesse an Ihre Digitalisierungslösungen anzubinden, steht auf einem anderen Blatt; auch damals werkelte hinter modernen Enterprise Services oft eine COBOL-Legacy).
Ich habe die Befürchtung dargelegt, dass Digitalisierungsprojekte zum Scheitern verurteilt sind, wenn sie auf einem zu großen Know-How-Rückstand begonnen werden. Aber natürlich ist das etwas, was Sie für Ihre konkrete Situation beurteilen müssen.
Sollten Sie bei den meisten der dargestellten Trends gedacht haben, „Machen wir schon oder können wir bei Bedarf schnell integrieren“, freut es mich für Sie. Mitunter kann man auch auf bereits etablierten Umgebungen neue Techniken und Produktivitätsschübe integrieren, indem man z.B. nach und nach funktionale Programmierung einführt (auf Java-Systemen eher mit Scala als mit Java 8, auf .NET mit F#).
Wenn Sie aber das Gefühl haben, zu weit weg zu sein von diesen ganzen Themen, empfehle ich: Versuchen Sie nicht, die Paradigmenwechsel in Ihre Legacy-Techniken und ‑Teams hinein zu quetschen, sondern nutzen Sie die Chance für einen parallelen Neuanfang, der dafür umso radikaler sein kann. Das ist eine riesige Chance: Wenn man auf diese Weise unbelastet Digitalisierungslösnungen in einer ohnehin neuen Umgebung beginnen kann, wäre mein Tip (den Sie aber bitte wie den gesamten Beitrag cum grano salis nehmen), auf Elixir zu setzen, das auf dem Rücken von Erlang gerade zu einem regelrechten Siegeszug ansetzt.
Wir leben in spannenden Zeiten. „Software is eating the world“, hat Marc Andresen festgestellt. Damit Sie ein großes Stück vom Kuchen abbekommen, sollten Sie die Möglichkeiten nutzen, Softwareentwickler heutzutage um Größenordnungen produktiver, effizienter, selbstwirksamer machen als die Generationen Ihrer Vorgänger (und das ist durchaus relevant: wenn ich heute mal persönlich entwickle, schätze ich meine Produktivität im Vergleich zu meinen Anfängen in dern 80ern, um bestimmt Faktor 20–50 höher; das ist schwer zu schätzen, weil wir uns seinerzeit nicht ansatzweise an so komplexe Systeme gewagt hätten; ich weiß es gibt da draußen Menschen, die immer noch so programmieren).
Ich begleite Sie gerne auf diesem Wege, wenn Sie Architekturberatung, Workshops, Coachings, Reviews o.ä. benötigen. Aber auch über allgemeinen Erfahrungsaustausch freue ich mich. Sprechen Sie mich jederzeit an.
Let’s code, have fun and change the world!