25.11.2025
Von Peter Hecker, Inhaber von HECKER CONSULTINGWas COBOL ist, wo es läuft und was COBOL-Programmierer den ganzen Tag tun: Aufgaben, Gehalt, Modernisierung mit KI und Einstiegswege im Realitätscheck.
„COBOL gibt es noch?“ Diese Frage kommt fast immer, wenn das Gespräch auf Programmiersprachen fällt. Die meisten Menschen halten COBOL für einen digitalen Dinosaurier: verstaubte Rechenzentren, grüne Schrift auf schwarzem Bildschirm und Programmierer, die ihre letzten Arbeitsjahre absitzen.
Die Wirklichkeit sieht anders aus. Wenn Sie heute Geld überweisen, eine Versicherungsprämie abgebucht bekommen oder einen Rentenbescheid erhalten, ist die Wahrscheinlichkeit hoch, dass irgendwo im Hintergrund ein COBOL-Programm mitgerechnet hat. Die Sprache ist unsichtbar – aber sie trägt erstaunlich viel.
Wer verstehen will, wie der Beruf aussieht, braucht zweierlei: ein paar nüchterne Fakten zur Sprache und einen Blick in den Arbeitsalltag. Beides folgt hier – erst die Grundlagen, dann eine Woche mit Jan, einem COBOL-Entwickler bei einem großen Versicherer, danach Gehalt, Zukunftsaussichten und Einstiegswege.
COBOL steht für „Common Business Oriented Language“, also etwa „allgemeine, geschäftsorientierte Sprache“. Sie entstand Ende der 1950er-Jahre auf Initiative des US-Verteidigungsministeriums; ein Ausschuss aus Herstellern und Anwendern legte 1960 die erste Fassung vor. Die Computerpionierin Grace Hopper prägte mit ihren Vorarbeiten die Idee dahinter: Programme sollten sich lesen lassen wie englische Sätze, damit auch Fachleute aus Buchhaltung und Verwaltung verstehen, was der Rechner tut.
Diese Herkunft sieht man der Sprache bis heute an. Ein COBOL-Programm ist in Abschnitte gegliedert – sogenannte Divisions – für Beschreibung, Umgebung, Daten und Ablauf. Anweisungen heißen ADD, MOVE oder COMPUTE, Variablen tragen lange, sprechende Namen. Ihre Stärke ist das, wofür sie gebaut wurde: große Mengen gleichartiger Datensätze zuverlässig verarbeiten und mit Geldbeträgen exakt rechnen. Für Geldbeträge rechnet COBOL mit Dezimalzahlen mit fester Zahl von Nachkommastellen, wie ein Mensch auf dem Papier – ohne die Rundungsfehler, die bei binären Gleitkommazahlen in vielen anderen Sprachen entstehen können. Für Zinsen, Prämien und Renten ist das kein Detail, sondern Pflicht.
Eine Museumssprache ist COBOL dabei nicht. Die Norm wurde mehrfach erweitert, unter anderem um objektorientierte Elemente (2002), zuletzt erschien eine überarbeitete ISO-Norm im Jahr 2023.
Wie viel COBOL es weltweit gibt, weiß niemand genau. Häufig zitiert wird eine Übersicht der Nachrichtenagentur Reuters aus dem Jahr 2017: Danach waren rund 220 Milliarden Zeilen COBOL-Code im Einsatz, und über COBOL-Systeme liefen Geschäfte im Wert von rund drei Billionen US-Dollar – pro Tag. Solche Zahlen sind Schätzungen und eher als Größenordnung zu verstehen. Sie machen aber deutlich, warum sich die Sprache nicht einfach abschalten lässt.
Wie gefragt das Wissen ist, zeigte sich im Frühjahr 2020: Als in der Corona-Pandemie die Anträge auf Arbeitslosengeld in den USA in die Höhe schnellten, kamen die COBOL-Systeme mehrerer Bundesstaaten nicht hinterher. Der Gouverneur von New Jersey bat öffentlich um Freiwillige mit COBOL-Kenntnissen. Das Problem war weniger die Sprache selbst als fehlende Leute, die die Systeme kannten.
Um den Beruf greifbar zu machen, begleiten wir Jan eine Woche lang. Vorweg ein Hinweis: Die geschilderte Woche ist eine verdichtete, teils fiktive Darstellung. Sie beruht auf persönlichen Erfahrungen und vielen Gesprächen mit Menschen, die im Mainframe-Umfeld arbeiten; Jan steht stellvertretend für sie, Zahlen aus seinem Team sind Beispiele.
Jan ist 42 Jahre alt und programmiert COBOL für einen großen Versicherungskonzern. Sein Arbeitsplatz ist kein Start-up mit Tischkicker und Obstkorb, sondern ein Bürogebäude, das aussieht, als hätte der Architekt 1985 sein letztes Projekt abgeliefert: solide Einzelbüros, funktionale Schreibtische.
„Die Leute sind immer überrascht, dass es uns überhaupt gibt“, sagt Jan. „Sie denken, wir seien Relikte aus einer anderen Zeit. Dabei pflege ich Systeme, über die jedes Jahr Milliarden an Prämien und Leistungen laufen.“
Daily Stand-up, also die kurze tägliche Abstimmung im Team. Acht Entwickler, Altersspanne zwischen 38 und 61 Jahren. Alle tragen Business Casual – Hemd und Stoffhose scheinen hier zum guten Ton zu gehören. Das Meeting dauert zwölf Minuten. Jeder sagt, was gestern erledigt wurde, woran heute gearbeitet wird und ob es Probleme gibt. Fertig.
Jans Beitrag: „Batch-Job für Policenverlängerungen getestet und abgeschlossen. Heute starte ich mit dem Prämienberechnungsmodul. Keine Blocker.“
„Wir sind hier, um zu arbeiten, nicht um uns zu präsentieren“, erklärt Jan später. „Durch unsere Systeme laufen jeden Tag Millionen. Da bleibt keine Zeit für lange Geschichten über das Wochenende.“
Wer grüne Schrift auf schwarzem Bildschirm erwartet, wird enttäuscht. Auf Jans Rechner läuft eine moderne Entwicklungsumgebung: Visual Studio Code mit Erweiterungen für COBOL und z/OS, angebunden an den Entwicklungs-Mainframe. Syntaxhervorhebung, Code-Vervollständigung, Fehlersuche – dieselben Annehmlichkeiten, die Java- oder Python-Entwickler kennen. Klassische Terminal-Oberflächen gibt es noch, sie sind aber nur ein Werkzeug unter vielen.
„Die Vorstellung von Lochkarten ist ungefähr so realistisch wie die Annahme, dass alle Journalisten noch auf Schreibmaschinen tippen“, sagt Jan trocken. „Wir haben Git für die Versionsverwaltung, automatisierte Build- und Test-Pipelines und Code-Reviews. Wir arbeiten nach modernen Standards, nur eben in COBOL.“
Auch die Sprache selbst überrascht. Die Variablennamen sind ausführlich, die Logik ist geradlinig, clevere Abkürzungen gibt es kaum.
„Vergleichen Sie das mal mit manchem JavaScript-Code“, sagt Jan. „Dreifach verschachtelte Bedingungen in einer Zeile, Variablen namens x und y. COBOL lässt Sie nicht clever sein. Es zwingt Sie, klar zu sein.“
Das Testteam meldet sich: Ein Batch-Job für Policenverlängerungen berechnet die Prämie in einem bestimmten Sonderfall falsch. Jan öffnet den Code, findet nach wenigen Minuten eine fehlende Bedingungsprüfung, behebt sie, schreibt einen Testfall dazu und spielt den Fix in die Entwicklungsumgebung ein. Gesamtzeit: 22 Minuten.
„COBOL ist nicht schwer zu lesen oder zu warten, wenn man weiß, was man tut“, sagt Jan. „Das Problem ist: Kaum jemand lernt es noch.“
Eine Änderungsanfrage aus dem Fachbereich: eine neue Rabattstufe für einen bestimmten Policentyp. Klingt nach einer zusätzlichen Bedingung und einer angepassten Formel. Tatsächlich muss Jan Jahrzehnte angesammelter Geschäftsregeln im Blick haben.
„Sehen Sie diesen Abschnitt?“ Er zeigt auf einen Codeblock. „Der behandelt Policen, die vor 2003 abgeschlossen wurden, anders – wegen einer Regeländerung damals. Dieser hier behandelt länderübergreifende Verträge. Der nächste Gruppen- gegenüber Einzelpolicen. Und dann Verlängerungsrabatte gegenüber Neukundenrabatten.“
„Der wahre Wert liegt nicht in der COBOL-Syntax“, sagt Jan. „Ein ordentlicher Programmierer lernt die Sprache in wenigen Wochen. Der Wert liegt im Verständnis dieser Geschäftsregeln. Ich weiß, warum dieser Code existiert und was passiert, wenn man ihn ändert.“
Und wenn er in Rente geht? Jan seufzt. „Das ist die eigentliche Frage. Die Firma dokumentiert, so gut es geht. Aber man kann nicht dokumentieren, welches Telefonat ich vor drei Jahren mit der Compliance-Abteilung hatte, die mir erklärt hat, warum wir etwas genau so berechnen.“ Das Kernproblem ist also nicht COBOL als Sprache, sondern der drohende Verlust von Wissen, das nur in wenigen Köpfen steckt.
Jan zeigt den Zeitplan der Stapelverarbeitung – den Teil der Arbeit, den außerhalb des Rechenzentrums kaum jemand sieht. Jede Nacht, wenn der Geschäftsbetrieb ruht, starten Dutzende Batch-Jobs. Sie verbuchen die Vorgänge des Tages, aktualisieren Vertragsdaten, berechnen Prämien, erzeugen Berichte und bereiten alles für den nächsten Morgen vor. In Jans Team sind es rund eine halbe Million Vorgänge pro Nacht.
Ein Überwachungssystem kennt für jeden Job die erwartete Laufzeit. Dauert einer zu lange oder bricht er ab, wird jemand aus der Rufbereitschaft alarmiert.
„Letzten Monat wurde ich um zwei Uhr nachts geweckt“, erzählt Jan. „Ein Job war abgebrochen, weil eine Eingabedatei ein unerwartetes Format hatte. Einloggen, Protokolle prüfen, Fehler finden, Korrektur testen, einspielen, Job neu starten: 40 Minuten. Das passiert selten. Die Systeme sind zuverlässig.“
Planungsrunde zur Modernisierung. Der CTO ist dabei, Vertreter der Fachbereiche, Architekten und das COBOL-Team. Der Vorschlag: 20 Prozent des COBOL-Codes als Pilotprojekt in Java-Microservices überführen – kleine, unabhängig voneinander betriebene Dienste. Geschätzte Kosten: 1,1 Millionen Euro, Dauer: 18 Monate.
Die Diskussion wird schnell hitzig. Der Fachbereich will wissen, ob in der Zeit neue Funktionen entstehen können. Der Architekt verneint: Die Migration bindet den Großteil der Kapazität. „Also zahlen wir 1,1 Millionen dafür, etwas nachzubauen, das schon funktioniert, und bekommen 18 Monate lang nichts Neues?“ Der Architekt hält dagegen: COBOL-Fachleute seien teuer und schwer zu finden – auf Dauer sei das das größere Risiko.
Jan meldet sich: „Java-Entwickler sind auch teuer. Und Sie schlagen vor, acht Leute, die dieses System in- und auswendig kennen, durch ein größeres Team zu ersetzen, das die Fachlichkeit erst von Grund auf lernen muss.“
Das Meeting endet ohne Entscheidung. Und beide Seiten haben gute Argumente – mehr dazu weiter unten.
Ein kurzfristiges Treffen: Der Vertrieb plant eine neue Produktlinie und will wissen, ob das System sie abbilden kann.
Das auf eine Stunde angesetzte Treffen ist nach 30 Minuten vorbei. Ein externer Berater ohne Systemkenntnis hätte für dieselben Antworten vermutlich Tage gebraucht.
Freitagnachmittag ist Auslieferungstag. Jan bringt drei Änderungen in Produktion: die Prämienkorrektur, ein neues Berichtsmodul und einige Optimierungen. Der Ablauf ist geordnet: Code-Review, automatisierte Tests, Fachtests durch die Qualitätssicherung, Probelauf in einer Vorproduktionsumgebung, dann das feste Zeitfenster für die Produktion, mit genug Puffer bis zum Start der Nachtverarbeitung.
Die Auslieferung dauert 15 Minuten. Kein Drama, keine Nachtschicht. Um 17 Uhr fährt Jan seinen Rechner herunter; am Wochenende will er wandern gehen.
Jans Woche zeigt: Die Arbeit besteht nur zum Teil aus Programmieren. Typisch sind diese Aufgaben:
Wer COBOL beherrscht, braucht also mehr als die Sprache: Kenntnisse in JCL, Db2 und SQL, ein Gefühl für Datenqualität und vor allem Verständnis für die Fachlichkeit der Branche.
Jan verdient im Beispiel 95.000 Euro im Jahr. Das liegt am oberen Ende dessen, was angestellte COBOL-Entwickler in Deutschland erreichen, und ist mit acht Jahren Branchenerfahrung, Rufbereitschaft und Großkonzern-Tarif erklärbar. Eine verbindliche Gehaltsstatistik nur für COBOL gibt es nicht; Gehaltsportale kommen je nach Datenbasis zu deutlich unterschiedlichen Werten (Bruttojahresgehälter, Stand Herbst 2026):
Was das Gehalt bestimmt, ist weniger die Sprache als das Umfeld:
Für die Suche nach „COBOL Entwickler Gehalt“ gilt deshalb: Die Spanne ist breit, und COBOL allein macht niemanden reich. Gefragt und gut bezahlt sind Leute, die Sprache, Großrechner und Fachlichkeit zusammenbringen – und die bereit sind, Verantwortung für Systeme zu übernehmen, die nicht ausfallen dürfen.
Die naheliegende Frage lautet: Wenn die Fachleute knapp werden, warum ersetzt man COBOL nicht? Jan rechnet es am Beispiel seines Kernsystems vor: rund 2,3 Millionen Zeilen Code. Schreibt ein Entwickler in einer so komplexen Fachdomäne 200 Zeilen neuen, getesteten Code am Tag – eine großzügige Annahme –, ergibt das 11.500 Entwicklertage, also gut 50 Personenjahre. Und am Ende stünde ein System, das dasselbe kann wie vorher, nur mit neuen, unbekannten Fehlern.
Dass Großumstellungen schiefgehen können, ist gut dokumentiert. Die britische Bank TSB etwa zog im April 2018 ihre Kundendaten auf eine neue Plattform um; danach hatte ein erheblicher Teil ihrer 5,2 Millionen Kunden Probleme mit Konten und Online-Banking, und erst im Dezember 2018 kehrte die Bank laut der britischen Aufsicht zum Normalbetrieb zurück. Die Ursachen lagen in Planung und Steuerung des Umzugs, nicht in einer bestimmten Programmiersprache – ein Lehrstück dafür, wie riskant der Austausch eines Kernsystems ist.
Zugleich stimmt das Argument des Architekten aus dem Mittwochsmeeting: Jedes Jahr gehen erfahrene Mainframe-Leute in Rente, und ein System, das nur fünf Menschen verstehen, ist ein Risiko. In der Praxis haben sich deshalb mehrere Wege etabliert, die selten „alles oder nichts“ bedeuten:
Welcher Weg passt, ist weniger eine technische als eine geschäftliche Entscheidung: Wie gut ist das System dokumentiert und getestet? Wie oft muss es sich ändern? Wie lange kann das Unternehmen auf das vorhandene Personal bauen? Wer vor dieser Entscheidung steht, findet im Seminar COBOL-Migration die Optionen, Werkzeuge und typischen Fallstricke im Zusammenhang.
Seit 2023 setzen Hersteller große Hoffnungen auf künstliche Intelligenz. IBM bietet mit watsonx Code Assistant for Z einen KI-Assistenten an, der COBOL erklären und Teile davon in Java überführen soll; auch Cloud-Anbieter wie AWS werben mit KI-gestützter Mainframe-Modernisierung. Allgemeine Programmierassistenten wie GitHub Copilot verstehen COBOL ebenfalls in Grundzügen.
Was das im Alltag bringt, sollte man realistisch einschätzen. Stark sind solche Werkzeuge beim Lesen: Sie fassen zusammen, was ein unbekanntes Programm tut, erzeugen Dokumentation, schlagen Testfälle vor und helfen Neulingen, sich schneller einzuarbeiten. Gerade für das Wissensproblem aus Jans Team ist das eine echte Hilfe. Schwächer sind sie dort, wo es darauf ankommt: bei den unausgesprochenen Regeln, die nur aus dem Zusammenspiel vieler Programme, Daten und Abläufe hervorgehen – und beim Nachweis, dass der neue Code wirklich dasselbe rechnet wie der alte.
Meine Einschätzung: KI verschiebt die Arbeit von COBOL-Entwicklern, sie macht sie nicht überflüssig. Wer die Ergebnisse prüfen und verantworten kann, wird eher wichtiger. Wie sich solche Assistenten sinnvoll in Entwicklungsprozesse einbinden lassen, behandelt das Seminar Moderne KI-Entwicklungsprozesse mit intelligenten Assistenten.
„Würde ich empfehlen, COBOL-Programmierer zu werden?“, fragt Jan am Freitagnachmittag. „Als einzige Sprache wahrscheinlich nicht. Die Sprache wächst nicht. Aber diese Systeme werden meine Karriere überdauern.“
Diese Sicht trifft es ganz gut. Für den Arbeitsmarkt sprechen zwei Entwicklungen: Viele der Fachleute, die die Systeme aufgebaut haben, gehen in den nächsten Jahren in den Ruhestand, und Modernisierungsprojekte brauchen gerade Menschen, die das Alte verstehen. Dagegen spricht, dass kaum neue COBOL-Anwendungen entstehen und der Markt überschaubar bleibt – es gibt deutlich weniger Stellen als für Java, C# oder Python.
Daraus ergibt sich eine klare Empfehlung: COBOL lohnt sich am meisten als Zusatzqualifikation, nicht als einziges Standbein. Gefragt ist die Kombination aus COBOL und Mainframe-Werkzeugen mit einer modernen Sprache wie Java, mit Kenntnissen über Schnittstellen und Cloud sowie mit Fachwissen aus Finanzen, Versicherung oder Verwaltung. Wer das mitbringt, kann sowohl im Betrieb als auch in der Modernisierung arbeiten.
Die Fähigkeiten, die Jan im Alltag braucht – Stapelverarbeitung, Datenintegrität, Transaktionssicherheit, regulatorische Anforderungen, fachliche Modellierung –, gelten zudem für jedes große Backend-System. Wer sie einmal gelernt hat, nimmt sie auch in andere Technologien mit.
Die unbequeme Wahrheit über COBOL lautet: Es funktioniert. Es ist nicht aufregend, man kann damit auf keinem Entwicklertreffen angeben. Aber es verarbeitet Tag für Tag Geschäftsvorgänge, auf die sich Millionen Menschen verlassen.
COBOL-Programmierer sind nicht veraltet, sondern spezialisiert. Sie arbeiten an Systemen, die nicht ausfallen dürfen, mit festen Abläufen, klaren Zuständigkeiten und oft erstaunlich modernen Werkzeugen. Der Beruf bietet geregelte Arbeitszeiten, solide Gehälter und eine Sicherheit, die viele Start-ups nicht bieten.
Für Unternehmen bedeutet das: COBOL ist kein Problem, das man aussitzen oder mit einem Großprojekt erschlagen sollte. Entscheidend ist, das Wissen rechtzeitig zu sichern – durch Dokumentation, Tests, Nachwuchs und schrittweise Modernisierung. Sollten neue Projekte in COBOL entstehen? Nein. Sollten bestehende Systeme um jeden Preis migriert werden? Ebenfalls nein. Wie Jan sagt: „Wenn es funktioniert und teuer zu ersetzen ist, braucht man einen sehr guten Grund.“
Die beste Infrastruktur ist die, über die niemand nachdenken muss – bis sie ausfällt. Dann erinnern sich alle daran, dass es COBOL-Programmierer gibt.
COBOL-Entwickler warten und erweitern geschäftskritische Systeme, überwachen nächtliche Batch-Läufe, beheben Fehler, setzen neue Produkte und gesetzliche Vorgaben um und verbinden den Großrechner mit modernen Anwendungen. Ein großer Teil der Arbeit ist Analyse und Abstimmung mit den Fachbereichen.
Weil die Systeme zuverlässig laufen, große Datenmengen exakt verarbeiten und in Jahrzehnten gewachsene Geschäftsregeln enthalten. Eine Ablösung ist teuer und riskant; viele Unternehmen modernisieren deshalb schrittweise.
Je nach Erfahrung, Branche und Region – und je nach Gehaltsportal – liegen die Durchschnittswerte für angestellte COBOL-Entwickler in Deutschland bei rund 55.000 bis 70.000 Euro brutto im Jahr; Einsteiger verdienen weniger, erfahrene Spezialisten erreichen auch 80.000 Euro und mehr. Den größten Unterschied macht das Fachwissen über ein bestimmtes System.
Die Sprache selbst ist überschaubar und gut lesbar; Grundlagen lassen sich in wenigen Wochen lernen. Anspruchsvoller sind das Mainframe-Umfeld mit JCL, CICS und Db2 und vor allem die Fachlogik der Anwendungen.
Nach heutigem Stand nicht. KI-Assistenten helfen, alten Code zu verstehen, zu dokumentieren und teilweise zu übersetzen. Die Verantwortung dafür, dass Berechnungen stimmen, bleibt bei Menschen, die das System kennen.
Wir erweitern ständig unser Beratungsportfolio. Über 600 Beratungsleistungen haben wir für Sie im Programm. Selbstverständlich lassen sich die einzelnen Themen kombinieren. So erhalten Sie genau die Beratung, die Sie wünschen und brauchen.
Mehr IT-, Online-, Digital-Beratungsleistungen anzeigen >>Moderne KI-Entwicklungsprozesse für die eigene Arbeit: Sie ordnen Aufgaben zwischen sich und intelligenten Assistenten neu, erweitern Ihre Werkzeuge mit MCP und Skills, koordinieren mehrere Agenten und sichern das Ergebnis ab.
Software Tests mit ChatGPT und GitHub Copilot: Sie leiten Testfälle aus Anforderungen ab, automatisieren Unit-, API- und UI-Tests mit Playwright, erzeugen Testdaten und Berichte – und prüfen per Mutationstest, ob die Tests Fehler wirklich finden.
Sie klären Kontext und Stakeholder, finden mit Double Diamond, Ishikawa und 5-Why die eigentlichen Ursachen und entscheiden begründet, welche Lösung in die Anforderungen eingeht.
Sie formulieren Anforderungen nach Schablone, beseitigen Mehrdeutigkeiten und liefern eine Anforderungsdokumentation, mit der Fachbereich, Entwicklung, Test und Coding-Agenten ohne Rätselraten arbeiten können.
Full-Stack-Webentwicklung mit KI an einem durchgehenden Projekt: vom Wireframe über Frontend, API und Datenbank bis zu Tests, Pipeline, Deployment und Dokumentation – jeder Schritt mit passenden Werkzeugen und überprüfbarem Ergebnis.
Sie beschreiben APIs kompakt in TypeSpec, erzeugen daraus OpenAPI 3, JSON Schema und Protobuf und setzen einheitliche API-Richtlinien über wiederverwendbare Bibliotheken und Linter durch.
Sie bauen in Go, Rust und TypeScript je einen kleinen Prototyp, messen Performance, Speicher und Entwicklungstempo und verlassen den Workshop mit einer begründeten Entscheidungsvorlage samt Bewertungsmatrix für Ihre Backend-Sprache.
Sie lernen die Grundlagen, nach denen moderne Software-Anwendungen aufgebaut sind – vom Python-Skript über die Full-Stack-Anwendung bis zur Cloud – und begründen Architekturentscheidungen nachvollziehbar.
Sie verankern Sicherheit in jeder Phase der Entwicklung – mit Bedrohungsmodellen im Entwurf, sicheren Mustern im Code, SAST und DAST in der Pipeline und einer SBOM für jede Auslieferung.
Wo die Grenze zwischen zwei Services verläuft, wann ein Event besser ist als ein Aufruf und welche Kompromisse bei Daten, Latenz und Betrieb dazugehören – danach entscheiden Sie begründet, ob Microservices zu Ihrem System passen.
Sie erkennen und beheben die häufigsten Schwachstellen in Webanwendungen und APIs nach den OWASP Top 10 – von fehlerhafter Zugriffskontrolle über Injection bis zu unsicherem Design und neuen Risiken durch Lieferketten und LLM-Funktionen.
Sie wenden die fünf SOLID-Prinzipien und die GRASP-Muster an Python-Code mit Typ-Hinweisen und Protocols an, erkennen Verstöße im Code-Review und machen Klassen leichter erweiterbar und testbar.
Sie verstehen, warum große native iOS- und Android-Apps anders gebaut, getestet und betrieben werden als Webanwendungen, und kennen bewährte Lösungen für Releases, Architektur, Teams und Betrieb.
Sie entwerfen Dienstverträge mit Protocol Buffers, bauen Java-Microservices mit gRPC über HTTP/2 – unär und mit Streaming – und sichern sie mit Deadlines, TLS, Tests und Tracing ab, pur oder mit Spring Boot und Quarkus.
Sie zerlegen einen gewachsenen Monolithen Schritt für Schritt in Microservices – mit klarem Ziel, sauberem Service-Schnitt, Migration im laufenden Betrieb und einem Team, das die neue Architektur auch betreiben kann.
Sie analysieren gewachsene COBOL-Programme, sichern ihr Verhalten mit Tests ab, refaktorisieren sie schrittweise und wählen eine Migrationsstrategie, die Fachlogik und Daten nicht unterwegs verliert.
Sie automatisieren Webanwendungen mit Selenium WebDriver, wählen robuste Locators, lösen Synchronisationsprobleme mit expliziten Wartezeiten und bringen Ihre Testsuite mit Page Objects und Selenium Grid in die CI-Pipeline.
Sie führen ein kleines Produkt in drei Sprints von der Problemaussage über geprüfte Anforderungen, Proof of Concept und Modelle bis zum Release 1.0 – und halten jede Entwurfsentscheidung nachvollziehbar fest.
Aktuelle und interessante Themen und Beiträge für Sie zusammengetragen und aufbereitet.
Domain Storytelling macht Fachwissen sichtbar: Fachleute erzählen einen konkreten Ablauf, der live als Bild aus Akteuren, Arbeitsgegenständen und Aktivitäten entsteht. Sie erfahren, wie ein Workshop abläuft und welche Werkzeuge helfen.
WinForms, WPF, UWP, WinUI 3, MAUI, Avalonia, Uno und Blazor: Was die .NET-Oberflächentechniken können, wo ihre Grenzen liegen und welches Framework wofür passt – mit Entscheidungshilfe und Blick auf Web, Flutter und React Native.
Rust gilt als schnell, sicher und schwer zu lernen. Sie erfahren, was Ownership, Borrowing, Lifetimes, Traits und Cargo bedeuten, wer Rust einsetzt und wie Sie mit offiziellen Werkzeugen, Forschungstools und KI-Assistenten den Einstieg schaffen.
Systematische Problemanalyse ist der Schlüssel zu erfolgreichem Requirements Engineering. Dieser Artikel zeigt Ihnen bewährte Methoden und Techniken zur Problemidentifikation, -analyse und Lösungsentwicklung. Erfahren Sie, wie der Double-Diamond-Prozess Ihre Anforderungsanalyse verbessert und warum iteratives Vorgehen entscheidend für den Projekterfolg ist.
Anforderungsmanagement entscheidet, ob ein Projekt liefert, was gebraucht wird. Lernen Sie Prozess, bewährte Methoden zum Ermitteln, Beschreiben und Priorisieren, agiles Vorgehen und passende Werkzeuge kennen.
Was DDD in der Softwareentwicklung bedeutet, wann es sich lohnt und wie Bounded Contexts, Aggregate und Event Storming zusammenhängen – verständlich für Entwickler, Architekten und Fachleute, die zum ersten Workshop eingeladen sind.
Dieser Artikel beleuchtet die Prinzipien nachhaltiger Softwarearchitektur, darunter Modularität, Schichtung und die Anwendung von Design Patterns. Er betont die Wichtigkeit, technische Schulden zu minimieren und die Rolle von KI und Automatisierung in der zukunftssicheren Softwareentwicklung. Durch Fallstudien und FAQs werden praktische Einblicke und Strategien zur Implementierung und Erhaltung einer nachhaltigen Architektur aufgezeigt, um langfristige Wartbarkeit, Skalierbarkeit und Flexibilität von Softwareprodukten zu gewährleisten.
Künstliche Intelligenz (KI), maschinelles Lernen (ML) und Data Science (DS) sind die Schlagworte in der Informationstechnologie (IT)-Branche. Die Mehrheit der Unternehmen bewegt sich von der Proof of Concept (POC)-Phase zur Produktion und Monetarisierung von KI/ML/DS-Lösungen. Aufgrund der Art der Arbeit, die in die Projekte involviert ist, unterscheiden sich Teamzusammensetzung, Qualifikationsanforderungen und die Kernentwicklung von KI/ML/DS etwas von der traditionellen Softwareentwicklung. Die Einbeziehung von Datenexploration, Data Engineering, Experimenten und spezialisierten Tools wie Jupyter-Notebook trägt zur Komplexität bei.
Der Business Analyst fungiert als Bindeglied zwischen den verschiedenen Projektrollen während des gesamten Projektlebenszyklus - von der Ermittlung bis zur Lieferung. Das bedeutet, dass der Business Analyst das "große Ganze" und die Art und Weise, wie das Team am Projekt zusammenarbeitet, kennenlernt. Dies versetzt den Business Analyst in eine gute Position, um Verbesserungen in Bezug auf Anforderungen, Kommunikation, Teamausrichtung, Einbeziehung der Stakeholder, Projektplanung und Fortschrittsüberwachung zu identifizieren und einzuführen.
Warum brauchen Sie einen Prototypen? Haben Sie zufällig eine Menge Ideen und Anforderungen von Kunden, wenn es um das Projekt geht? Wenn ja, dann ist ggf. die Entwicklung eines Prototypen eine geeignete Methode diese Ideen und Anforderungen zu überprüfen. Ein Prototyp ist etwas, das die meisten Menschen mit materiellen Produkten assoziieren, nicht unbedingt mit mobilen oder Web-Anwendungen. In der IT-Branche - und insbesondere in modernen Softwarehäusern - wird der Prototyp jedoch sehr häufig im Softwareentwicklungsprozess eingesetzt. Zunehmend ist er auch ein Schlüsselelement im Prozess der Vertragsabschlüsse.
Heute will jedes Team auf die agile Methodik der Agilen Programmierung umsteigen, d.h. den Anwender in den Mittelpunkt der Prozessplanung bei der Produktentwicklung stellen. Sie bauen schließlich ein Produkt für die Endbenutzer, richtig? User Stories sind eines der grundlegenden Werkzeuge, die Teams helfen, sich bei der Definition eines Produkts und seiner Funktionalität an den Benutzer zu erinnern. Es wird viel darüber gesprochen, wie man sie richtig schreibt.
So werden Ihre Code-Reviews (noch) besser. Wir alle wissen, dass wir ohne Code-Review nicht weit kommen. Es verbessert die Qualität des Codes und macht seine Struktur stabiler. Außerdem helfen Reviews den Programmierern, Beziehungen aufzubauen und effektiver zu arbeiten. Es lässt sich jedoch nicht leugnen, dass ein Review von gleichem Code viel einfacher zu planen als durchzuführen ist, und solche Reviews können ein Alptraum für Teamleiter sein.
Start-ups sind aus unserer Gegenwart nicht mehr wegzudenken. Immer mehr davon sind Unternehmen, die mit IT zu tun haben. Doch wir kennen nur die, die erfolgreich waren. Von denen, die gescheitert sind, hat noch nie jemand etwas gehört. Manchmal war ihr Scheitern mit überbewerteten Plänen verbunden, ein anderes Mal scheiterten sie, weil sie sich darauf konzentrierten, sofort etwas Neues zu schaffen, ohne einen richtigen langfristigen Ansatz zu verfolgen.
