30 Jahre in der IT — Vom C64 zum Cloud-Monolithen

Neulich hat mich jemand gefragt, wie lange ich schon "was mit Computern" mache. Die ehrliche Antwort: über 30 Jahre. Die erschreckende Antwort: Es fühlt sich nicht so an. Die Zeit zwischen dem ersten POKE 53280,0 auf dem C64 und dem heutigen kubectl get pods ist irgendwie gleichzeitig eine Ewigkeit und ein Wimpernschlag.

Das hier ist kein "Wie toll ich bin"-Artikel. Es ist eher ein Rückblick darauf, wie sich diese Branche verändert hat, wie ich mich mit ihr verändert habe — und was dabei auf der Strecke geblieben ist. Und vielleicht auch ein bisschen eine Warnung: Wer in die IT geht, sollte wissen, dass der Wandel nicht die Ausnahme ist, sondern der Normalzustand. Denn in 30 Jahren habe ich eines gelernt: Jede neue Technologie durchläuft denselben Zyklus — erst der Hype, dann die Ernüchterung, und irgendwann kristallisiert sich heraus, wofür man sie wirklich sinnvoll einsetzen kann. Dieses Muster hat sich nie geändert. Die Technologie ist jedes Mal eine andere. Das Muster nicht.

Die Anfänge: Assembler, Sprites und die Hardware-Revolution

Angefangen hat alles mit dem C64. Wie bei so vielen aus meiner Generation. Erst BASIC, dann relativ schnell Assembler — weil BASIC einfach zu langsam war für das, was ich machen wollte. Sprites bewegen, Rastereffekte, SID-Sounds. Wer auf dem C64 Assembler programmiert hat, der hat Respekt vor Hardware gelernt. Jedes Byte zählte, jeder Taktzyklus war relevant.

Dann kam der Amiga. Und damit eine völlig neue Welt: Multitasking, 4096 Farben, Paula und Agnus als Custom-Chips. Auch hier war Assembler meine Sprache der Wahl. Der 68000er war ein Traum im Vergleich zum 6510 — richtige 32-Bit-Register, vernünftiger Befehlssatz. Ich habe damals Dinge programmiert, die ich heute nicht mehr nachvollziehen kann. Nicht weil sie so genial waren, sondern weil ich keine Ahnung mehr habe, wie ich das ohne Debugger, ohne Stack Overflow, ohne Google hinbekommen habe.

Schon damals wurde eines klar: Hardware-Generationen überschlugen sich. Der C64, der Amiga, der Atari ST — jede Plattform war ein kleines Universum. Und jedes dieser Universen konnte über Nacht verschwinden.

Escom, der PC und das Tempo des Wahnsinns

1994 jobbte ich bei Escom — dem Computer-Discounter, den heute keiner mehr kennt. Dort erlebte ich die erste wirklich verrückte Technologie-Revolution hautnah: die PC-Hardware. Ich hatte das Gefühl, wöchentlich meinen PC updaten zu können — und trotzdem war er schon wieder veraltet. Die Generationen überschlugen sich: 286er, 386er, 486er. 33 MHz, 66 MHz, DX/2, DX/4, Pentium, Pentium II. Dazu der Prozessorenkrieg: AMD gegen Intel — Ding, Ding, Knockout AMD. (Dass sie jetzt wieder da sind und Intel ins Wanken bringen, hätte damals keiner gedacht.)

Parallel dazu begann die erste große Schlacht der Betriebssysteme. DOS, DR-DOS, Linux, später Windows. Und dann der große Kampf: Windows 95 gegen IBM OS/2. OS/2 war meiner Meinung nach das eindeutig bessere Betriebssystem. Es hat trotzdem verloren — aus Dummheit von IBM, wenn man mich fragt. Manchmal setzt sich nicht das Bessere durch — ein Muster, das mir noch öfter begegnen sollte.

Bei Escom bekam ich auch ein Jobangebot, das ich ablehnte: Studium sausen lassen und bei einer Firma anfangen, die Online-Spiele erfinden wollte. Die redeten von "hunderten oder sogar tausenden" Spielern, die gleichzeitig online spielen sollten. Ich konnte mir beim besten Willen nicht vorstellen, wie das gehen sollte. Mal abgesehen davon, dass ich unbedingt mein Studium abschließen wollte, damit ich irgendwas in der Hand habe. Ob das die Firma war, aus der später ein großer MMO-Anbieter wurde? Keine Ahnung. Aber die Vorstellung war für mich damals schlicht absurd.

Das Studium, der MFC-Schock und die Online-Revolution

Der Wechsel zum PC war unvermeidlich. Der Amiga starb langsam, und die PC-Welt explodierte. Also C und C++. Das war in Ordnung — systemnahe Programmierung, Pointer-Arithmetik, Speicherverwaltung von Hand. Nichts, was man nicht vom Assembler kannte, nur eben auf einem höheren Abstraktionslevel.

Und dann kam der Moment, der meine Karriere verändert hat. Während des Studiums Mitte der 90er wollte ich die Microsoft Foundation Classes (MFC) lernen. DAS war damals der Weg, Windows-Anwendungen zu bauen. Also habe ich mir den Quellcode angeschaut.

Ich habe mich erschreckt.

Nicht weil es komplex war — Komplexität kannte ich. Sondern weil es sich falsch anfühlte. Hässlich. Verkrampft. Ein Framework, das gegen die Sprache arbeitete statt mit ihr. Das war der Moment, in dem ich beschlossen habe: Nein. Nicht mit mir. Nicht Windows. Nicht MFC.

Stattdessen: Linux und Java. Und das war, rückblickend, eine der besten Entscheidungen meiner Laufbahn.

Während des Studiums erlebte ich auch die Geburt des Internets hautnah. Meine ersten Gehversuche online waren DialUp in BBS-Systeme mit 300 Baud. Später 2400 Baud — das war die Zukunft. Kann man sich heute nicht mehr vorstellen. Dann Datex-P, Telnet, FTP, Finger, Gopher als Vorgänger von HTML. Und ich schaue mir die ersten HTML-Seiten an und denke: "Das wird sich nicht durchsetzen. Viel zu grafiklastig, das dauert zu lang zum Laden."

Mein Gott, lag ich falsch.

Heute nimmt jeder WiFi für selbstverständlich. Mann — was hätten wir in den 80ern dafür gegeben.

Die wilden Jahre: Consulting, Hypes und 300 Tage unterwegs

Noch während des Studiums habe ich angefangen, professionell zu arbeiten. "SBC — Stephan Bösebeck Consulting" klang seriöser als "Student, der Java kann". Von Escom war ich in die Consulting-Schiene gerutscht.

Die Zeit als Freiberufler war intensiv. Bis zu 300 Tage im Jahr unterwegs. Ich habe Zertifizierungen gesammelt wie andere Leute Briefmarken: Certified Java Trainer, IBM Certified Trainer, und gefühlt hundert weitere. Nicht aus Sammelwut, sondern weil man als Einzelkämpfer Zertifikate brauchte, um überhaupt in Projekte zu kommen.

Die Projekte selbst waren oft klein oder kleinst. Aber die Namen waren groß: HP, IBM, Sun. Dazu Trainings für Ausbildungsfirmen wie Integrata. Ich war gleichzeitig Entwickler, Trainer und echter Berater — einer, der nicht nur PowerPoints geschoben hat, sondern wirklich technisch beraten hat.

In diese Zeit fiel auch die Hochphase der Tech-Hypes. Als XML aufkam, wollten plötzlich alle irgendwie spitze Klammern irgendwo einsetzen. Das war das Buzzword, das kaum jemand wirklich verstanden hat, aber die unmöglichsten Blüten hervorgebracht hat: XML-Datenbanken zum Beispiel. Ich kann mich an einen Vertriebler erinnern, der den CEO einer Firma, die ich beraten habe, überzeugen wollte mit den Worten: "Dann können Sie ISDN und XML." Das hatte überhaupt nichts mit dem Produkt zu tun. Und was soll es überhaupt heißen, wenn eine Online-Plattform "XML kann"? Völliger Blödsinn. Zum Glück kam der Vertrag nicht zustande.

Oder PDAs. Der Palm Pilot — ich fand das Ding damals großartig. Jeder hatte einen, jeder wollte einen. Ich habe sogar einen Open-Source-Java-Treiber geschrieben, um meinen Linux-Kalender mit dem Palm Pilot zu synchronisieren. Mein schöner Treiber wurde obsolet, als die Funktionen komplett in die Telefone wanderten — erst der Nokia Navigator, dann dieses Windows-basierte Ding von der Telekom, und schließlich das iPhone. Aber dazu komme ich noch.

Parallel dazu haben wir während des Studiums mit Freunden eine lockere GbR gegründet: Designer, IT-Admin, Softwareentwickler, Vertriebler. Zusammen haben wir unter anderem die Technik für ein Internetcafé aufgebaut — inklusive Abrechnungssystem für Billardtische und Internetnutzung. Das musste ich in Perl schreiben, weil die Maschinen für Java zu langsam waren und die Zeiten nicht richtig berechnen konnten. Dabei habe ich sogar Bugs in Perl gefunden und an die Community gemeldet. Solche Projekte vergisst man nicht.

Und dann die Browser-Kriege: Netscape gegen Microsoft. Microsoft hat versucht, alles mit Geld zu erschlagen. Ich mochte diese Politik damals schon nicht, aber so funktionierte deren Geschäftsmodell halt. Netscape ging K.O. — so richtig. Danach Microsoft gegen Sun mit Java versus C#. Auch ein ungleicher Kampf. Sun hat unterm Strich verloren, weil jetzt dieses C# rumgeistert. Java blieb ewig hängen, es kam keine Entwicklung mehr. Dann kam Oracle — und seitdem tut sich wieder was. Man muss Oracle nicht mögen, aber sie haben Java wiederbelebt.

In diesen Jahren waren viele interessante Anekdoten dabei, einige davon eher skurril, wie die Geschichte von einem, der mich zum Ausstatten einer Online-Video-Plattform einkaufen wollte (wollte Hardware im 5-stelligen Bereich von mir kaufen), dann aber absprang, weil er in Deutschland keine Porno-Seiten betreiben durfte. Er ging dann in die Niederlande und ich ging leer aus.

Und die skurrile Geschichte, als ich für irgendeine Armee (Jugoslawien? Serbien? Ich weiß nicht mehr) eine Software geschrieben habe, um die Körpermaße für die Anfertigung der Uniformen zu speichern... Wenn ich die Zahlen verdreht hätte, wäre mir das sicher nicht gut bekommen.

Und die Geschichte von dem Kunden, der bei jedem Release etwas zu verbessern wusste, und zielstrebig immer etwas genommen hat, was extrem viel Zeit gekostet hat. Bis wir absichtlich kleine Fehler eingebaut haben, die etwas offensichtlicher waren. Das hat der Kunde bemerkt, wir so: "Uiiii... die Farbe von dem Button ändern ist aber hakelig..." — "Das ist mir egal, machen Sie das." Und natürlich machten wir das. Der Kunde war glücklich, er konnte was "verbessern", und wir auch, weil wir nicht unnötig beschäftigt wurden.

Ich glaube, auch da habe ich eine "Fake Progress Bar" eingebaut. Der Kunde beschwerte sich, dass die SQL-Anfragen zu lange dauern. Damals war alles etwas langsamer und ja, es dauerte. Nach 5 Sekunden hat er sich beschwert, bei mir, per Telefon. Also habe ich eine Fake Progress Bar bei jeder SQL-Anfrage angezeigt. Die sprang halt irgendwann auf 100, wenn das Ergebnis da war, aber eben nicht vorher. Da bewegte sie sich langsam auf die 100% zu — erreichte sie aber nie. Wie gesagt, sonst ruft er an, wenn die Query länger als 5 Sekunden braucht. Dann bekomme ich einen Anruf, dass die Query jetzt schon "40 Minuten braucht und immer noch nicht bei 100%" ist — ich hatte einen NullPointer. Schnell korrigiert und wieder ein Kunde glücklich...

Oder eben ärgerliche Geschichten, wie die Geschichte von einer Arztpraxis, die Ende der 90er mit einem AS/400-Host und seriellen Terminals ausgestattet wurde und dafür auch mehrere zigtausend DM zahlen musste. Das ging vor Gericht, da durfte ich auch aussagen. Die wurden total über den Tisch gezogen.

Es gab so viele schwarze Schafe in meiner "Zunft", das war gruselig. Und ich habe im Scherz zu einem Kumpel gesagt: "Bei jeder Ausschreibung, die bisher kam, hätte ich es auch immer für die Hälfte gemacht und wäre reich gewesen." Aber das war zu unseriös, damit bekommt man keine Aufträge.

Um 2000 herum hatte ich mein Studium erfolgreich abgeschlossen. Meine Zeit in Passau endete dann auch in den frühen 2000ern, nicht unbedingt schön — denn meine mit Freunden gegründete GbR zerfiel sehr unschön, und am Ende mit Hilfe von Gerichten. Da musste ich als Zeuge aussagen und durfte einige meiner Freunde als Lügner überführen. War nicht schön.

Ich bin dann nach München umgezogen. Irgendwann machte es keinen Sinn mehr, für jedes Projekt nach München zu fahren. Die Firmen übernahmen irgendwann die Hotels nicht mehr. Da hätte ich es eigentlich ahnen müssen...

Der Knall: Dotcom-Blase und die erste große Disruption

Dann platzte die Dotcom-Blase. Für mich als Einzelkämpfer bedeutete das: 80 Prozent Umsatzeinbußen. Von heute auf morgen. Die Projekte waren weg, die Budgets eingefroren, und plötzlich war "Freiberufler" kein cooles Lifestyle-Label mehr, sondern ein Risikofaktor.

Das war die erste richtig destruktive Disruption, die mich persönlich traf. Nicht eine Technologie, die sich veränderte — sondern ein ganzes Geschäftsmodell, das über Nacht implodierte. Die Technik war noch da, die Fähigkeiten waren noch da. Aber die Aufträge nicht.

Ich musste mich also schnellstens umorientieren. Dummerweise (oder zum Glück) hatte das Finanzamt keinerlei Skrupel, mir klarzumachen, dass auch wenn ich keine Umsätze mehr habe, ich dennoch die Steuern zu bezahlen habe. Das hat mich fast ruiniert. Es gab Zeiten, da konnte ich entweder essen oder das Geld für Sprit ausgeben, um zum Kunden zu fahren. Das war eine lehrreiche Zeit.

In dieser Zeit hatte ich auch noch ein KFZ-Problem, das man sich kaum vorstellen kann. Ich hatte einen Toyota Corolla — und ich hatte ein Montagsauto erwischt. Der war in den zwei Jahren, die ich ihn hatte, bestimmt 15-mal in der Werkstatt. Problem: Die Werkstatt war in Passau und die mussten die Garantieaufträge damals erledigen. Ich hatte also wenige Aufträge und ein kaputtes Auto, das ich auf gar keinen Fall außerhalb der Garantie weiter behalten wollte — das hätte ich nie im Leben bezahlen können. Zu den schon bestehenden fehlenden Umsätzen kamen dann auch noch die Verluste vom Verkauf dieses Montagsautos hinzu. Das war ein Tiefpunkt.

Softlab, VMware, das iPhone und der Vista-Schock

Ich war gerade nach München gezogen und da ich eh keine Wahl hatte (Dotcom-Blase geplatzt) habe ich mich fest anstellen lassen. Bei Softlab — damals eine Tochter von BMW. Der Kulturschock war interessant: Das Konzept "Urlaub" war für mich neu. Nicht arbeiten und trotzdem bezahlt werden? Als Freiberufler undenkbar. Ich musste das erst lernen.

Bei Softlab war ich zuerst Softwareentwickler, dann Technischer Projektleiter. Zwei Jahre, verschiedene Projekte für BMW, MAN und andere. Solide Arbeit, gutes Team, viel gelernt über das Arbeiten in größeren Strukturen.

Bei Softlab kam ich das erste Mal so richtig mit Typen in Kontakt, die sich als was Besseres sahen, denn sie waren ja "Architekten". Die Gespräche waren entsprechend. Die waren ernsthaft der Meinung, die nächste disruptive Technologie wären Enterprise Java Beans, denn damit könne man "Software ja aus Beans zusammenstecken". Was überhaupt nicht funktioniert hat. Dieses "Programming by Skeleton" oder dann auch der ganze UML-Hype funktionierte auf dem Papier ganz gut, aber in Realität konnte es einfach nicht mithalten. Viel zu sperrig. Und EJB war aus einem anderen Grund "disruptiv" — viele sind auf EJB aufgesprungen, aber die Performance war nie da. Diese ganzen Beans, diese ganze Technologie war schwer zu nutzen und hat sicher einige Firmen in den Ruin getrieben. Und dazu geführt, dass die guten alten IBM-Hosts à la AS/400 ein viel zu langes Leben hatten.

In diese Zeit fiel auch der Beginn einer leisen Revolution: VMware brachte die erste wirklich brauchbare Virtualisierungssoftware auf den Markt. Wir wussten anfangs gar nicht so recht, was man damit anstellen sollte. Mehrere Betriebssysteme auf einer Maschine? Klang nach Spielerei. Heute ist Virtualisierung die Grundlage von allem — Cloud, Container, die gesamte moderne Infrastruktur. Aber damals? Damals war das ein nettes Gadget.

Und dann passierte etwas, das die Branche auf den Kopf stellte: Apple brachte das iPhone heraus. Das erste Handy, das ich bekam, war noch ein Nokia — SMS schreiben auf einer Zahlentastatur, und man war erreichbar. Überall! Revolution! Aber das iPhone? Das habe ich links liegen lassen. Kein Keyboard — wie soll man damit arbeiten? Ich Depp. Keine vier Jahre später gab es kein einziges relevantes Telefon mit Tastatur mehr auf dem Markt. Das ist die Definition von Disruption: Wenn die Technologie, die du für unverzichtbar hältst, einfach verschwindet — und keiner vermisst sie.

Etwa zur gleichen Zeit hatte Microsoft ein besonderes Kunststück vollbracht: Windows Vista. Und Apple hatte endlich ein brauchbares Betriebssystem. Ich fand Apple als Firma immer schon interessant, aber vor Mac OS X war das für einen Techie kaum sinnvoll nutzbar. Multitasking? Fehlanzeige. Das klassische Mac OS war gruselig hinter der Zeit. Aber mit OS X hatten sie plötzlich ein Unix mit einer stabilen, schönen Oberfläche. Kein ewiges Rumgebastele mehr, um die Oberfläche anzupassen oder am Laufen zu halten — wer Linux auf dem Desktop kannte, weiß wovon ich rede.

Vista gab mir dann den entscheidenden Tritt: Ich stieg um. MacBook und dann doch ein iPhone dazu. Und es war großartig. Windows war plötzlich unnötig geworden. Der Mac war Linux mit endlich stabiler Oberfläche. Das iPhone ein Computer in der Hosentasche mit einem echten Browser. Beides zusammen veränderte alles — wie wir Software bauen, wie wir Interfaces denken, wie wir kommunizieren. Vielleicht die wichtigste Disruption meiner gesamten Karriere.

Während ich auf meinen Mac wartete, belauschte ich in der Kaffeeküche ein Gespräch zweier Kollegen. Beide hatten sich zufällig den gleichen neuen Gaming-PC zugelegt — teuer, high-end. Das Gespräch ging ungefähr so:

"Der ist super schnell, ich find den toll." — "Ja, genau. Alles läuft klasse." — "Ja... passiert es bei dir auch, dass man Audio-CDs nicht abspielen kann?" — "Ja, aber das ist kein Problem, ich hab noch einen anderen PC." — "Stimmt. Hast du Bluescreens beim Zugriff auf DVDs?" — (lacht) "Ja, hab ich auch. Aber der PC ist super." — "Und Linux konnte ich nicht starten." — "Ja, die Spielerei braucht man nicht. Aber der PC ist super."

Es kamen dann noch diverse Variationen: A sagt, der PC stürzt ab bei Operation X. B antwortet: "Ja, hab ich auch — aber der ist super." Irgendwann bin ich dazwischen gegangen und habe gefragt, ob mir das nur auffällt, weil ich mir gerade einen Mac bestellt habe, oder ob die beiden völlig verblödet sind. Ein PC, auf dem nichts richtig funktioniert — aber er ist super. Das fasste für mich den Zustand von Windows ziemlich gut zusammen.

Das Lustige daran: Ich habe den Mac auch einigen meiner PC-Admin-Kunden empfohlen. Ausnahmslos alle haben sich danach nicht mehr gemeldet. Die meisten, weil sie tatsächlich auf den Mac umgestiegen sind und meine Hilfe schlicht nicht mehr brauchten. Und einige wenige, weil ihnen die Bluescreens von Windows offenbar so ans Herz gewachsen waren, dass sie mich nach der Mac-Empfehlung nicht mehr für fähig — oder würdig — erachteten. So oder so: Kundenverlust durch zu gute Beratung. Das muss man auch erst mal schaffen.

Der Manager-Ausflug: Acronis und die weite Welt

Dann wurde ich mehr oder weniger abgeworben. Durch meine Trainingserfahrung landete ich als "Manager Training & Certification EMEA" bei Acronis. Eine komplett andere Welt: Ich war zuständig für den gesamten EMEA-Raum, bin viel gereist, kam bis nach Singapur. Spannend? Absolut.

Aber — und das ist ein großes Aber — ich bin kein reiner Manager. Die Technik hat mir gefehlt. Meetings, Budgets und Strategiepapiere sind wichtig, aber sie ersetzen nicht das Gefühl, ein Problem mit Code zu lösen. Nach etwa zwei Jahren wusste ich: Ich muss zurück in die Technik.

In diese Zeit fiel auch mein Motorradunfall, der mich unter anderem dazu gebracht hat, auf Split-Keyboards umzusteigen. Aber das ist eine andere Geschichte.

Zurück im Code: HolidayInsider und das Client-Server-Pendel

Also: Vom Manager zurück zum Senior Software Developer. Bei der HolidayInsider AG. Das war eine bewusste Entscheidung und eine der besten meiner Karriere.

HolidayInsider war Startup-Feeling pur. Wir haben zu fünft in der Entwicklung angefangen und waren am Ende mit Werkstudenten fast 20 Leute. Fünf Jahre, in denen ich unglaublich viel gelernt habe. Nicht nur technisch, sondern auch darüber, wie man ein Team aufbaut, wie man Prozesse einführt, ohne die Agilität zu verlieren, und wie man mit extremem Wachstum umgeht.

Technisch beobachtete ich in dieser Zeit ein Pendel, das ich mittlerweile gut kannte: das ewige Hin und Her zwischen Client und Server. Fat Clients, Thin Clients, Poor Clients, Rich Clients. Lokale Berechnung, zentrale Berechnung. In 30 Jahren ist dieses Pendel bestimmt zehnmal hin- und hergeschwungen: "Wir müssen alles auf dem Server bereitstellen, der Client zeigt nur an. Server-Ressourcen sind billiger!" — Zwei Jahre später: "Die Clients haben 100 TFLOPS ungenutzte Ressourcen, wir müssen die nutzen! Lokal ist super!" — Und wieder zurück. Immer das Gleiche. Nur mit anderen Buzzwords.

Dann kam die Übernahme durch HRS. Und mit ihr der Kulturclash, den jeder kennt, der schon mal erlebt hat, wie ein Startup von einem Konzern geschluckt wird. Unterschiedliche Geschwindigkeiten, unterschiedliche Prioritäten, unterschiedliche Vorstellungen davon, wie Software entwickelt wird. Es lief nicht gut.

Die schwierige Phase: SimpleSystems

Nach HolidayInsider wechselte ich zu SimpleSystems. Auch ein Startup, auch mit dem Anspruch, etwas aufzubauen. Leider hat es mit dem Chef nicht funktioniert. Wir haben uns einfach nicht verstanden — unterschiedliche Vorstellungen, unterschiedliche Kommunikationsstile. Das war stressig und unschön.

Was mich besonders belastet hat: Einige Entwickler, die mit mir von HolidayInsider gewechselt hatten, hatten dadurch ebenfalls ein schweres Leben und haben am Ende auch gekündigt. Das trägt man mit sich. Als Mensch, der andere mitgezogen hat, fühlt man sich verantwortlich — auch wenn die Entscheidung letztlich jeder selbst getroffen hat.

Nicht jede Station in einer Karriere ist ein Highlight. Manche sind Lehrstunden. SimpleSystems war eine.

Angekommen: GBI Genios, der Monolith und die Container-Welt

Dann kam GBI Genios. Und hier bin ich jetzt seit über acht Jahren — die längste Station meiner gesamten Karriere.

GBI Genios Deutsche Wirtschaftsdatenbank ist ein Joint Venture von FAZ und Handelsblatt. Wir haben über eine Milliarde Dokumente im Index — Presse-Erzeugnisse, Fachzeitschriften, Wirtschaftsinformationen — die alle in Sekundenbruchteilen durchsuchbar sind. Dazu kommen Daten vom Bundesanzeiger und anderen Wirtschaftsquellen. Das Besondere: Presse- und Fachpresse-Artikel werden mit Firmendaten getaggt, sodass man Berichterstattung mit Wirtschaftsdaten verknüpfen kann — daher "Wirtschaftsdatenbank". Kunden können einzelne Artikel kaufen, statt ganze Zeitschriften zu abonnieren. Drumherum haben wir diverse Business-Cases gebaut, zum Beispiel die FAZ-Archiv-Seiten.

Ich bin hier als "Leiter Engineering & IT" tätig — quasi CTO auf Deutsch. Und zum ersten Mal in meiner Karriere habe ich das Gefühl, dass beides zusammenkommt: die Management-Erfahrung aus der Acronis-Zeit und die technische Tiefe aus all den Jahren als Entwickler.

Die technische Realität ist dabei durchaus... herausfordernd. Wir arbeiten mit einem Monolithen, der noch auf JDK 1.8 und Grails 3 läuft. Die Modernisierung — Aufbrechen in Microservices, Update auf aktuelle Java-Versionen, alles wartbarer machen — ist ein Marathon, kein Sprint. Aber genau solche Aufgaben finde ich mittlerweile spannender als auf der grünen Wiese etwas Neues zu bauen. Einen laufenden Motor im Flug umbauen — das hat seinen eigenen Reiz.

Und während wir den Monolithen modernisieren, tobt draußen die nächste Revolution: Docker, Kubernetes, Container im Allgemeinen. Docker spinnt die Virtualisierung weiter, mit Containern und deren "Beschreibung" im Dockerfile. Für mich persönlich: total überflüssig. Ich kann Linux bedienen, einen LXC-Container auch automatisiert einrichten — Docker ist für mich eine zusätzliche Schicht, um nicht zu sagen Black Box. Aber ich verstehe den Grund für den Hype: Bequemlichkeit. Das ist OK, wenn auch meiner Meinung nach überbewertet. Kubernetes treibt es mit der Orchestrierung dann auf die Spitze. Das hat alles seine Daseinsberechtigung — auch wenn ich mich damit nicht so recht anfreunden kann. Persönliche Unzulänglichkeit, denke ich.

Aber genau das ist der Punkt: Wenn man das lange genug beobachtet hat, entwickelt man einen gewissen Gleichmut gegenüber dem neuesten heißen Trend. Nicht Zynismus — ich bin immer noch neugierig, immer noch begeisterungsfähig. Aber man lernt, zwischen echtem Fortschritt und dem nächsten Hype-Zyklus zu unterscheiden. Und man muss auch ehrlich genug sein, um zu sagen: Das ist nicht meins — ohne gleich zu behaupten, es sei schlecht.

Nebenbei habe ich auch eigene Open-Source-Projekte: Morphium, ein MongoDB-Treiber und ORM für Java, den wir auch produktiv bei Genios einsetzen. Und jblog2, die Blog-Software auf der dieser Artikel hier läuft. Solche Projekte halten mich technisch am Ball — aber dazu mehr in einem separaten Artikel.

Mittendrin in der nächsten Revolution: KI

Ich war ehrlich gesagt der Meinung, dass ich keinen so destruktiven Wandel mehr erleben würde. Keinen Umbruch mehr wie den Wechsel von Offline zu Online, oder von PCs zu Smartphones. Das war naiv.

Denn jetzt bin ich wieder mittendrin. Die KI-Revolution ist eine echte: destruktiv, sie wird viele Geschäftsfelder verändern und einige obsolet machen. Wer nicht aufpasst, wird überholt. Das habe ich ein paar Mal mitgemacht. Es lässt mich nicht kalt, aber ich bin auch nicht so besorgt wie vielleicht manch anderer. Man entwickelt über die Jahre ein Gespür dafür, wo echter Wandel stattfindet und wo nur der nächste Hype-Zyklus durchläuft. Bei KI bin ich mir ziemlich sicher: Das ist kein Hype, der wieder verschwindet. Das verändert grundlegend, wie wir Software entwickeln, wie wir Informationen verarbeiten, wie wir arbeiten.

Aber — und das sage ich als jemand, der 300-Baud-Modems, den Dotcom-Crash, den Tod von Sun Microsystems und Windows Vista überlebt hat — es wird auch hier einen Hype-Peak geben, gefolgt von Ernüchterung, gefolgt von dem Moment, in dem sich herauskristallisiert, was KI wirklich kann und was nicht. Dieses Muster hat sich in 30 Jahren nie geändert.

Was bleibt

Wenn ich auf 30 Jahre zurückblicke, sehe ich: Hardware-Generationen, die sich überschlugen. Betriebssysteme, die gegeneinander kämpften. Browser-Kriege. Die Geburt des Internets. Das mobile Zeitalter. Cloud Computing. Und jetzt KI. Jede einzelne davon hat die Branche umgekrempelt, Firmen vernichtet und neue geschaffen. Assembler, C, C++, Java, JavaScript, Go, Rust, Kotlin. Client-Server, Web, SOA, Microservices, Serverless. Wasserfall, Agile, DevOps, Platform Engineering. Das Muster ist immer das gleiche: Eine Technologie kommt, wird gehypt, reift, wird zum Standard, wird langweilig, wird abgelöst.

Was bleibt? Die Grundlagen. Algorithmisches Denken. Die Fähigkeit, ein Problem zu zerlegen. Verständnis dafür, was unter der Haube passiert — auch wenn man heute nicht mehr jeden Taktzyklus zählen muss. Und vor allem: Die Bereitschaft, immer wieder Neues zu lernen. Wer in dieser Branche stehen bleibt, fällt zurück. Nicht in Monaten, aber in Jahren.

Ich habe das Gefühl, dass meine Generation — Gen X — dadurch anders geprägt ist. Wir haben so viele Revolutionen mitgemacht, dass uns so leicht nichts mehr aus der Fassung bringt. Inklusive diverser Weltuntergänge — der aktuelle mit dem Klimawandel ist gefühlt mein fünfter. Das soll ihn nicht kleinreden. Aber es erklärt vielleicht, warum wir manchmal gelassener reagieren, als jüngere Generationen es von uns erwarten.

Ich habe Technologien kommen und gehen sehen. Ich habe Firmen kommen und gehen sehen — Escom, Sun Microsystems, sogar Teile des Amiga-Ökosystems. Was überlebt, sind nicht die Technologien. Es sind die Menschen, die sich anpassen können.

30 Jahre IT, und ich bin immer noch da. Nicht weil alles immer toll war — SimpleSystems war es nicht, die Dotcom-Blase war es nicht, und der Monolith bei Genios ist es auch nicht immer. Sondern weil diese Branche etwas hat, das ich nirgendwo sonst finde: Das Gefühl, jeden Tag etwas bauen zu können. Etwas, das vorher nicht da war. Etwas, das funktioniert.

Oder manchmal auch nicht funktioniert. Aber auch dafür gibt es ja Logs.

Im nächsten Artikel geht es darum, wie man als Engineering-Leiter technisch am Ball bleibt — und warum das kein Selbstläufer ist.