Der entscheidende Unterschied zu klassischen Sprachen wie COBOL oder PL/I liegt in der engen Verzahnung von Sprache und Datenbank. Natural wurde nicht als universeller Allrounder entworfen, sondern als produktive Umgebung, in der Datenbankzugriffe auf Adabas mit wenigen, gut lesbaren Anweisungen möglich sind. Diese Spezialisierung ist die Wurzel sowohl der Stärken als auch der Grenzen von Natural: Wo Adabas und Natural zusammenarbeiten, entsteht bemerkenswert kompakter Code – zugleich bindet dieses Modell die Anwendung eng an ein bestimmtes Produktökosystem.
Drei Eigenschaften prägen Natural:
Als Natural entstand, war es ein Fortschritt: Anwendungen ließen sich schneller entwickeln als mit den damaligen Standardsprachen, und die Nähe zur Datenbank machte datenintensive Programme kompakt. Viele Organisationen bauten auf dieser Grundlage über Jahrzehnte umfangreiche Anwendungslandschaften auf, die bis heute im produktiven Betrieb sind. In diesem Sinn ist Natural ein Musterbeispiel für erfolgreiche, langlebige Unternehmenssoftware.
Gerade diese Langlebigkeit führt jedoch dazu, dass Natural-Systeme heute oft als Legacy wahrgenommen werden – nicht, weil sie schlecht funktionieren, sondern weil das technische und personelle Umfeld sich verändert hat. Wer heute in eine bestehende Natural-Landschaft investiert, muss zwei Perspektiven zusammenbringen: den Respekt vor einem bewährten, laufenden System und die nüchterne Bewertung seiner strategischen Zukunftsfähigkeit. Genau diese doppelte Sichtweise ist das Ziel dieses Artikels.
Anders als moderne Allzwecksprachen, die für sehr unterschiedliche Aufgaben taugen, ist Natural ein Spezialist für ein bestimmtes Umfeld: datenintensive, transaktionsorientierte Anwendungen auf Basis von Adabas, historisch vor allem auf dem Mainframe. Innerhalb dieses Rahmens ist Natural sehr produktiv; außerhalb spielt es kaum eine Rolle. Diese klare Domänenbindung ist wichtig zu verstehen, weil sie erklärt, warum Natural in der breiten Softwareentwicklung heute selten vorkommt, in seinen Kerndomänen aber weiterhin präsent ist.
Wer Natural als altmodische Nischensprache abtut, unterschätzt den realen Wert der damit betriebenen Kernsysteme – und wer es umgekehrt als dauerhaft zukunftssichere Basis für Neuentwicklungen betrachtet, blendet die strategische Abhängigkeit von einem einzelnen Anbieter und das enger werdende Fachkräfteangebot aus. Beide Extreme führen in der Praxis zu Fehlentscheidungen.
Das prägendste Merkmal von Natural ist seine Einordnung als Sprache der vierten Generation. Während Sprachen der dritten Generation – etwa COBOL oder PL/I – jeden Verarbeitungsschritt vergleichsweise ausführlich beschreiben, hebt eine 4GL die Abstraktionsebene an: Wiederkehrende Muster wie das Lesen von Datensätzen, das Durchlaufen von Ergebnismengen oder die Steuerung von Bildschirmmasken sind in die Sprache eingebaut. Das Ergebnis ist Code, der dieselbe fachliche Aufgabe mit deutlich weniger Zeilen ausdrückt.
Für die Zeit, in der Natural entstand, war das ein erheblicher Produktivitätsgewinn – und in seinem angestammten Umfeld ist er es bis heute. Die Kehrseite: Diese Abstraktion ist eng auf ein bestimmtes Datenbank- und Betriebsmodell zugeschnitten. Was die Entwicklung datenintensiver Kernanwendungen beschleunigt, macht Natural gleichzeitig zu einem Spezialwerkzeug, das außerhalb seiner Domäne kaum Anwendung findet und sich nicht ohne Weiteres in beliebige moderne Architekturen einfügt.
Anders als universelle Sprachen, die über austauschbare Schnittstellen mit verschiedenen Datenbanken sprechen, ist Natural historisch auf Adabas hin optimiert. Diese Nähe erklärt, warum datenbezogene Operationen in Natural so knapp ausfallen und warum beide Produkte in der Praxis als Einheit betrachtet werden. In modernen Varianten und Werkzeugen der Software AG lässt sich Natural zwar auch mit relationalen Datenbanken über standardisierte Schnittstellen verbinden; der aktuelle Funktionsumfang und die unterstützten Kombinationen sollten jedoch stets anhand der offiziellen Produktdokumentation geprüft werden.
Für Unternehmen ist die enge Kopplung ein zweischneidiges Merkmal. Sie liefert im Bestand Effizienz und ein durchdachtes Zusammenspiel, führt aber dazu, dass Sprache und Datenbank strategisch gemeinsam betrachtet werden müssen: Entscheidungen über die eine Komponente berühren fast immer die andere. Diese Verkopplung ist ein wesentlicher Grund für die im weiteren Verlauf behandelte Anbieterbindung.
Der Aufbau von Natural-Programmen ist durch klar abgegrenzte Struktureinheiten geprägt: Datendefinitionen werden getrennt von der eigentlichen Verarbeitungslogik geführt, und Programme lassen sich in Unterprogramme, Subroutinen und wiederverwendbare Bausteine gliedern. Diese Trennung sorgt in gepflegten Beständen für nachvollziehbaren Aufbau, ist aber in gewachsenen, jahrzehntealten Anwendungen nicht immer diszipliniert eingehalten worden – ein häufiger Befund in unseren Bestandsanalysen.
Das charakteristischste Element der Natural-Syntax ist die Art, wie Datenbankzugriffe ausgedrückt werden. Wo eine universelle Sprache eine separate Abfragesprache einbetten und Ergebnisse umständlich verarbeiten muss, sind das Auffinden, Durchlaufen und Bearbeiten von Datensätzen in Natural unmittelbar in die Sprache integriert. Für Entwickler, die im Adabas-Umfeld arbeiten, wirkt das natürlich und effizient: Datenzentrierte Logik liest sich kompakt und folgt einem einheitlichen Muster.
Für Umsteiger aus einer relationalen, SQL-geprägten Welt ist genau das jedoch ungewohnt. Die Denkweise unterscheidet sich von der mengenorientierten Logik relationaler Datenbanken, und viele Konzepte lassen sich nicht eins zu eins übertragen. Wer Natural neu erlernt, muss daher nicht nur eine Syntax, sondern ein eigenes Daten- und Verarbeitungsmodell verstehen – ein Grund, warum die Einarbeitung trotz grundsätzlicher Lesbarkeit Zeit braucht.
Natural ist so gestaltet, dass gut geschriebener Code für Kundige verständlich bleibt: Die Anweisungen orientieren sich an fachlichen Vorgängen, und die Sprache verzichtet auf einen Großteil des technischen Beiwerks systemnaher Sprachen. In sauber strukturierten Anwendungen mit einheitlichen Namenskonventionen ist Natural-Code daher durchaus wartbar. Voraussetzung ist allerdings, dass diese Konventionen über die Jahre konsequent gelebt wurden.
In der Praxis treffen wir häufig auf das Gegenteil: Bestände, die über Jahrzehnte von wechselnden Teams erweitert wurden, unterschiedliche Stile vermischen und deren ursprüngliche Dokumentation lückenhaft ist. Das ist kein spezifisches Natural-Problem, sondern gilt für alle langlebigen Sprachen – wiegt bei Natural aber schwerer, weil das Wissen um die Sprache und um die konkrete Anwendung oft an wenigen erfahrenen Personen hängt. Die Lesbarkeit der Sprache nützt wenig, wenn niemand mehr das fachliche Modell dahinter kennt.
Natural ist über die Jahrzehnte kontinuierlich erweitert worden und deckt neben der klassischen Dialog- und Stapelverarbeitung auch modernere Anforderungen ab, etwa die Bereitstellung von Funktionen als Dienste oder die Anbindung an andere Systeme. Welche Sprachmittel und Schnittstellen in welcher Produktversion verfügbar sind, ändert sich mit den Releases der Software AG und sollte stets in der offiziellen Dokumentation geprüft werden – konkrete Versions- oder Funktionsangaben ändern sich laufend und sind nicht Gegenstand dieses Überblicks.
Wichtig für die Praxis ist die Erkenntnis, dass Natural heute nicht mehr nur die klassische Mainframe-Sprache meint, sondern ein Produkt mit mehreren Plattformvarianten und einem modernen Entwicklungswerkzeug. Für die strategische Bewertung eines Bestands ist daher weniger die abstrakte Sprachfrage entscheidend als der konkrete Versions- und Plattformstand des eigenen Systems.
Untrennbar mit Natural verbunden ist Adabas, die hochperformante Datenbank der Software AG, die auf schnelle Verarbeitung großer Datenmengen ausgelegt ist. Adabas folgt nicht dem relationalen Modell klassischer SQL-Datenbanken, sondern einem eigenen, auf Effizienz getrimmten Ansatz. In Kombination mit Natural entsteht ein Gespann, das für transaktionsintensive Verwaltungs- und Finanzanwendungen über Jahrzehnte sehr zuverlässig gearbeitet hat. Wenn im Umfeld von Natural die Rede ist, ist Adabas fast immer Teil der Betrachtung.
Für die strategische Bewertung bedeutet das: Sprache und Datenbank lassen sich in der Regel nicht getrennt betrachten. Eine Entscheidung über die Zukunft der Natural-Anwendungen ist gleichzeitig eine Entscheidung über Adabas – und umgekehrt. Diese Kopplung ist ein zentraler Grund, warum Migrationsprojekte in diesem Umfeld sowohl die Sprache als auch das Datenmodell umfassen müssen.
Historisch ist Natural eine Mainframe-Technologie, etwa auf Großrechner-Betriebssystemen wie z/OS oder BS2000, wo es einen erheblichen Teil der kritischen Verwaltungs- und Finanzsysteme mitträgt. In diesem Umfeld ist die Ablaufsteuerung von Stapelverarbeitungen häufig über Job-Control-Sprachen wie JCL organisiert, und Natural fügt sich in die etablierten Betriebsabläufe des Großrechners ein. Diese Verankerung erklärt die hohe Stabilität, aber auch die Nähe zu einer bestimmten, spezialisierten Betriebswelt.
Über die Jahre hat die Software AG Natural und Adabas zusätzlich auf offene Plattformen wie Unix, Linux und Windows gebracht, sodass Anwendungen nicht mehr zwingend an den Mainframe gebunden sind. Für Unternehmen eröffnet das Wege, Bestände von teuren Großrechner-Umgebungen auf kostengünstigere Plattformen zu verlagern, ohne die Anwendung vollständig neu zu schreiben. Welche Plattformen in welchem Umfang unterstützt werden, hängt von der jeweiligen Produktversion ab und sollte konkret geprüft werden.
Die Entwicklung mit Natural erfolgte lange über zeichenbasierte Werkzeuge direkt auf dem Großrechner. Mit NaturalONE stellt die Software AG eine moderne, auf einer verbreiteten Entwicklungsplattform basierende Entwicklungsumgebung bereit, die zeitgemäßes Arbeiten mit Natural-Code ermöglicht – etwa komfortables Editieren, Navigieren und die Anbindung an moderne Versionsverwaltung. Für Teams, die Natural weiterpflegen, ist das ein wichtiger Schritt weg von der reinen Terminalwelt hin zu Arbeitsweisen, die auch jüngere Entwickler kennen.
Ergänzt wird das Umfeld durch Predict, das als zentrales Data Dictionary Metadaten über Datenstrukturen und deren Verwendung verwaltet. Diese Werkzeuge fördern Konsistenz und Übersicht innerhalb des Ökosystems – binden die Organisation aber zugleich enger an die Produktwelt eines einzelnen Anbieters. Der konkrete Werkzeugumfang und dessen Bezeichnungen entwickeln sich mit den Produktlinien der Software AG weiter und sollten anhand der aktuellen Dokumentation nachvollzogen werden.
Wenn ein Muster den Einsatz von Natural im DACH-Raum erklärt, dann ist es die Kombination aus großen, langlebigen Datenbeständen und hohen Anforderungen an Zuverlässigkeit. Öffentliche Verwaltung, Banken und Versicherungen teilen diese Merkmale: Ihre Kernprozesse laufen über Jahrzehnte, betreffen sensible und regulierte Daten und dürfen im Betrieb nicht ausfallen. Genau für dieses Profil wurde Natural konzipiert, und genau hier hat es sich über lange Zeiträume bewährt.
Für ein Unternehmen oder eine Behörde mit einem solchen Bestand ist die praktische Konsequenz wichtig: Diese Systeme funktionieren in der Regel gut und tragen zentrale Geschäftsprozesse. Ein vorschneller Ersatz aus rein technischer Modernitätserwägung ist selten wirtschaftlich. Zugleich verlangt die strategische Abhängigkeit eine bewusste, langfristige Planung – ein Spannungsfeld, das wir in den folgenden Kapiteln vertiefen.
Ein oft übersehener Aspekt beim Einsatz von Natural ist, dass diese Systeme über die Jahre nicht nur Daten, sondern auch fachliches Prozesswissen gespeichert haben. Regeln, Sonderfälle und Ausnahmen, die im Laufe von Jahrzehnten in den Code eingeflossen sind, existieren häufig nirgendwo anders dokumentiert. Der Wert eines Natural-Systems liegt daher nicht nur in seiner technischen Funktion, sondern in diesem verkörperten Wissen.
Das hat unmittelbare Konsequenzen für jede Modernisierung: Wer ein Natural-System ablösen will, muss nicht nur Code umschreiben, sondern das darin enthaltene Fachwissen erst rekonstruieren und verstehen. Diese oft unterschätzte Aufgabe ist einer der Hauptgründe, warum Migrationen im Natural-Umfeld aufwendiger sind, als es die reine Codemenge vermuten lässt. Wir gehen darauf im Modernisierungskapitel gezielt ein.
COBOL ist die wohl bekannteste Mainframe-Sprache und über viele Hersteller und Plattformen hinweg verbreitet. Als Sprache der dritten Generation ist COBOL ausführlicher, aber auch offener: Es ist nicht an eine bestimmte Datenbank oder einen einzelnen Anbieter gebunden und arbeitet mit unterschiedlichen Datenhaltungen zusammen. Natural setzt dagegen auf eine höhere Abstraktionsebene und liefert im Adabas-Umfeld kompakteren Code, erkauft dies aber mit der engen Bindung an das Ökosystem der Software AG.
Für die strategische Bewertung ist dieser Unterschied zentral: COBOL-Bestände profitieren von einem größeren, wenn auch alternden Fachkräftepool und einer herstellerübergreifenden Basis, was Migrations- und Betriebsoptionen tendenziell breiter macht. Natural-Bestände sind kompakter und im Betrieb effizient, aber stärker an einen Anbieter und eine Datenbank gekettet. Beide sind bewährte Kernsystem-Technologien; die Wahl fällt jedoch selten neu, sondern ergibt sich aus der historisch gewachsenen Landschaft.
PL/I ist eine weitere klassische Mainframe-Sprache, die historisch für ein breites Spektrum von kaufmännischen bis technisch-numerischen Aufgaben gedacht war. Sie ist wie COBOL herstellerübergreifend ausgerichtet und nicht an eine bestimmte Datenbank gebunden. In der Praxis ist PL/I weniger verbreitet als COBOL, und das Fachkräfteangebot ist entsprechend kleiner. Gegenüber Natural fehlt PL/I die 4GL-typische Datenbanknähe; dafür ist es nicht an einen einzelnen Anbieter gebunden.
In gewachsenen Rechenzentren treffen diese Sprachen oft nebeneinander an – COBOL, PL/I und Natural, jeweils für unterschiedliche Anwendungen und aus unterschiedlichen Beschaffungsentscheidungen der Vergangenheit. Für den Betrieb heißt das, dass mehrere Legacy-Kompetenzen parallel vorgehalten werden müssen, was den Fachkräftebedarf zusätzlich verschärft. Die Bündelung und Priorisierung dieser Bestände ist ein wiederkehrendes Thema in unseren Beratungsprojekten.
ABAP ist die Programmiersprache der SAP-Welt und teilt mit Natural ein wesentliches Merkmal: Sie ist eng an das Ökosystem eines einzelnen Anbieters gebunden und außerhalb dieses Umfelds kaum relevant. Beide sind produktiv innerhalb ihrer jeweiligen Domäne und beide erzeugen eine strategische Abhängigkeit vom Hersteller. Der entscheidende Unterschied liegt in der Marktstellung: ABAP profitiert von der enormen Verbreitung von SAP und einem entsprechend großen Fachkräftepool, während Natural eine deutlich kleinere, spezialisiertere Nische bedient.
Diese Gegenüberstellung ist für Entscheider aufschlussreich, weil sie zeigt, dass Anbieterbindung nicht automatisch problematisch ist – sie ist es umso mehr, je kleiner und rückläufiger die zugehörige Community und je enger der Anbietermarkt wird. Genau deshalb wiegt die strategische Abhängigkeit im Natural-Umfeld schwerer als im breiteren SAP-Umfeld, obwohl das Grundprinzip vergleichbar ist. Auf diesen Punkt gehen wir im folgenden Kapitel gezielt ein.
Im Unterschied zu Sprachen, die von offenen Gremien oder Gemeinschaften getragen werden, ist Natural das Produkt eines Unternehmens. Nutzung, Wartung und Weiterentwicklung erfolgen im Rahmen kommerzieller Lizenz- und Wartungsvereinbarungen mit der Software AG. Für Bestandskunden bedeutet das einerseits einen klaren Ansprechpartner, professionellen Support und eine geordnete Produktpflege; andererseits eine strukturelle Abhängigkeit von den strategischen und kommerziellen Entscheidungen dieses Anbieters.
Diese Abhängigkeit ist zunächst wertneutral zu sehen – viele Unternehmen setzen erfolgreich auf proprietäre Kernsoftware. Sie wird jedoch zum strategischen Faktor, wenn sich Eigentümerverhältnisse, Produktstrategien oder Marktbedingungen des Anbieters ändern. Wer eine geschäftskritische Landschaft auf Natural betreibt, sollte die Entwicklung des Anbieters und dessen langfristige Produktausrichtung bewusst beobachten, statt sie als selbstverständlich vorauszusetzen.
Wie bei jeder kommerziellen Software gibt es für Natural und Adabas definierte Produkt- und Support-Lebenszyklen: Versionen werden gepflegt, erhalten Aktualisierungen und laufen zu bestimmten Zeitpunkten aus dem regulären Support. Für den Betrieb ist es essenziell zu wissen, in welchem Lebenszyklus-Status die eigene Version steht, da davon Sicherheit, Stabilität und Handlungsdruck abhängen. Konkrete Termine, Versionsstände und Support-Zusagen ändern sich fortlaufend und sind ausschließlich den offiziellen Angaben des Anbieters zu entnehmen.
Ein häufiger Befund in unseren Bestandsanalysen ist, dass Organisationen den Lebenszyklus-Status ihrer Legacy-Produkte nicht präzise kennen. Das ist riskant: Läuft eine Version aus dem Support, entstehen Sicherheits- und Betriebsrisiken, und der Handlungsdruck kann kurzfristig stark steigen. Deshalb gehört die laufende Beobachtung des Support-Status zu einer soliden IT-Governance – unabhängig davon, ob mittelfristig Weiterbetrieb oder Ablösung geplant ist.
Die Anbieterbindung im Natural-Umfeld ist ausgeprägter als bei offenen Standards, weil Sprache, Datenbank und Werkzeuge aus einer Hand stammen und eng verzahnt sind. Ein Wechsel betrifft daher nicht eine einzelne Komponente, sondern das gesamte Ökosystem – mit entsprechendem Aufwand. Diese Bindung erhöht die Abhängigkeit von Preis-, Lizenz- und Strategieentscheidungen des Anbieters und schränkt die Verhandlungsposition ein, je kritischer und alternativloser das System ist.
Für Entscheider heißt das nicht, dass Anbieterbindung per se falsch ist – sondern dass sie bewusst und kalkuliert eingegangen und regelmäßig überprüft werden sollte. Zentrale Fragen sind: Wie kritisch ist das System, welche Ausstiegsoptionen bestehen grundsätzlich, welche Kosten und Risiken hätte ein Wechsel, und wie entwickelt sich der Anbietermarkt? Diese Bewertung ist eine strategische, keine rein technische Aufgabe und sollte auf Leitungsebene verankert sein.
Der wohl drängendste Faktor im Natural-Umfeld ist die Verfügbarkeit von Fachkräften. Erfahrene Natural-Entwickler sind häufig langjährige Mitarbeiter, die dem Ruhestand entgegengehen, und der Nachwuchs lernt Natural in Ausbildung und Studium kaum noch. Anders als bei verbreiteten modernen Sprachen ist der Arbeitsmarkt für Natural-Kompetenz klein und wird tendenziell enger. Für ein mittelständisches Unternehmen oder eine Behörde entsteht daraus ein reales Betriebsrisiko: Wenn wenige Schlüsselpersonen das System tragen, hängt dessen Weiterbetrieb an einzelnen Köpfen.
Dieser Engpass ist oft der eigentliche Auslöser für Modernisierungsüberlegungen – nicht die Technik selbst. Ein System, das technisch stabil läuft, wird zum Problem, wenn niemand mehr da ist, der es pflegen und im Fehlerfall verstehen kann. Deshalb gehört zur seriösen Bewertung eines Natural-Bestands immer auch die nüchterne Frage: Wie lange ist das nötige Wissen im Haus oder am Markt noch verfügbar, und wie wird es gesichert?
Zwischen alles bleibt und alles neu liegt ein Spektrum an Optionen, die sich je nach Kritikalität, Budget und Risikobereitschaft kombinieren lassen. Grob lassen sich mehrere Ansätze unterscheiden:
Welcher Weg der richtige ist, lässt sich nicht pauschal sagen. Er hängt von der Kritikalität des Systems, der verfügbaren Zeit, dem Budget und der Risikobereitschaft ab. In der Praxis bewährt sich oft ein gestufter Ansatz: erst Bestand und Risiken verstehen, dann Betrieb absichern, dann gezielt und schrittweise modernisieren, statt einen riskanten Komplettaustausch zu wagen.
Ein wiederkehrendes Muster in Modernisierungsprojekten ist die Unterschätzung des Aufwands. Der Grund liegt selten in der reinen Codemenge, sondern in dem bereits beschriebenen Prozesswissen, das im Code eingebettet ist. Regeln, Sonderfälle und historische Ausnahmen sind oft nirgends dokumentiert und müssen bei einer Ablösung erst rekonstruiert werden. Hinzu kommt die enge Adabas-Kopplung: Eine Migration betrifft nicht nur die Sprache, sondern auch das nicht-relationale Datenmodell, das in eine neue Datenhaltung überführt werden muss.
Für den Mittelstand ist die wichtigste Lehre, Modernisierung nicht als reines Technikprojekt zu behandeln. Erfolgreiche Vorhaben verbinden technische Migration mit der systematischen Sicherung des Fachwissens, mit realistischer Zeit- und Budgetplanung und mit einer klaren Priorisierung, welche Systeme zuerst und welche vielleicht gar nicht abgelöst werden müssen. Ein ehrlicher Blick auf diese Komplexität zu Beginn erspart teure Überraschungen im Verlauf.
Im laufenden Betrieb sind Natural-Systeme in der Regel bemerkenswert stabil – das ist einer ihrer größten Vorzüge und ein Grund, warum sie über Jahrzehnte bestehen. Die eigentlichen Betriebsrisiken sind daher weniger technischer Natur als organisatorisch: die Abhängigkeit von wenigen Wissensträgern, unklarer Support-Status der eingesetzten Produktversionen und fehlende Dokumentation der fachlichen Logik. Eine solide Governance adressiert genau diese Punkte, unabhängig von der Modernisierungsstrategie.
Konkret bedeutet das: Wissen aktiv sichern, statt sich auf einzelne Personen zu verlassen; den Lebenszyklus- und Support-Status der Produkte laufend beobachten; Änderungen am Bestand versioniert und nachvollziehbar durchführen; und regelmäßig bewerten, wie kritisch das System für die Geschäftsprozesse ist. Diese Maßnahmen sind keine Bürokratie, sondern die Grundlage dafür, ein Legacy-System kontrolliert und mit vertretbarem Risiko zu betreiben.
Beim Thema Sicherheit ist zwischen der Anwendung und ihrer Umgebung zu unterscheiden. Natural-Systeme laufen häufig in etablierten, gut abgesicherten Großrechner- oder Serverumgebungen, die eigene, ausgereifte Sicherheitskonzepte mitbringen. Die relevanten Risiken entstehen in der Praxis eher aus veralteten, nicht mehr gepflegten Produktversionen, aus fehlenden Aktualisierungen und aus der Anbindung alter Systeme an moderne, offene Netze, für die sie ursprünglich nicht konzipiert wurden.
Die Gegenmaßnahmen sind klar: den Support- und Aktualisierungsstand der eingesetzten Natural- und Adabas-Versionen aktuell halten, Sicherheitsupdates des Anbieters zeitnah einspielen und die Integration in moderne Umgebungen bewusst absichern. Wenn Legacy-Systeme über neue Schnittstellen erreichbar gemacht werden, muss die Sicherheit dieser Übergänge besonders sorgfältig geprüft werden. Der jeweils aktuelle Stand zu Versionen und bekannten Schwachstellen ist beim Anbieter zu erfragen und laufend zu verfolgen.
Die Zukunft von Natural ist von zwei Kräften geprägt. Auf der einen Seite steht die reale Persistenz gewachsener Kernsysteme, die sich nicht kurzfristig ablösen lassen und daher noch auf Jahre hinaus betrieben werden – Legacy-Technologien haben eine bemerkenswerte Beharrlichkeit. Auf der anderen Seite steht der langfristige Strukturwandel: schrumpfender Fachkräftepool, anbieterseitige Strategieentwicklung und der Wunsch vieler Organisationen nach offeneren, integrierbaren Architekturen.
Für den Mittelstand und die öffentliche Verwaltung ergibt sich daraus eine pragmatische Haltung: Weder überstürzter Ausstieg noch sorgloses Weiterlaufenlassen sind sinnvoll. Die tragfähige Strategie ist ein bewusst gesteuerter, langfristiger Umgang – den Bestand kennen, Risiken aktiv managen, Wissen sichern und den Modernisierungspfad rechtzeitig und schrittweise vorbereiten, bevor externer Druck durch Support-Ende oder Personalabgang die Entscheidung erzwingt. Diese vorausschauende Governance ist die beste Versicherung gegen teure Zwangslagen.
