Applikationsverständnis und maschinelles Lernen - oder: wo komme ich her

Seit 25 Jahren bin ich im Bereich der Automatisierung tätig. Aber das war nicht der Anfang meiner Karriere. Während meines Masterstudiums an der USC wurde ich zum ersten Mal mit künstlicher Intelligenz konfrontiert, ein Bereich, der mich sofort faszinierte. Zu dieser Zeit gab es nur wenige Stellen, die mit künstlicher Intelligenz zu tun hatten, aber meine erste Stelle war tatsächlich relevant: Ich arbeitete mit regelbasierten Entscheidungssystemen. Seitdem hat sich der Bereich der künstlichen Intelligenz stark weiterentwickelt, zumeist ohne für Schlagzeilen zu sorgen. Erst in den letzten Jahren hat er wieder große Aufmerksamkeit erregt, insbesondere der Bereich des maschinellen Lernens. Das erinnert mich an den Hype, den das Internet und "dot com" in den 1990er Jahren ausgelöst haben. Blase gefällig? Nur dieses Mal haben die Fortschritte in diesem Bereich eine solide Grundlage geschaffen, um die Expansion des maschinellen Lernens zu unterstützen. Mein zweiter Job führte mich in die Welt des Anwendungs- und Sprachverständnisses ein, und in diesem Bereich bin ich nun schon seit vielen Jahren tätig. In dieser Zeit sind viele faszinierende Dinge passiert, und wie Sie sehen werden, geht es jetzt dorthin, wo ich angefangen habe. Der Kreislauf schließt sich jetzt.

Verstehen von Anwendungen und deren Code

Am Anfang stand der Großrechner. Leistungsstarke Geräte, die eine enorme Anzahl von Transaktionen bewältigen konnten, die aber auch ihren Preis hatten. Dann kam das "Netzwerk als Computer", wie Sun Microsystems der Welt verkündete. Die Unternehmen hatten nun Alternativen zu den Mainframe-Monolithen.

Es gab jedoch ein Problem. Erfolgreiche Unternehmen hatten viel Geld in die Entwicklung von Mainframe-Prozessen investiert, die ihnen einen Vorsprung verschafften, und natürlich Unmengen an benutzerdefiniertem Code, der dazu gehörte. Was sollte man nun mit all dem benutzerdefinierten Code machen? Der Wille war stark, aber der Code war schwach, proprietär und inkompatibel. Und wir sollten nicht vergessen, dass relationale Datenbanken noch nicht als selbstverständlich galten. Hierarchische und Netzwerk-Datenbankverwaltungssysteme waren stark und, wenn Sie mich fragen, basierten sie auf eleganten Konzepten und waren sehr gut in dem, was sie taten. Aber die Geschichte wird von den Gewinnern (neu) geschrieben, und so wurden es Server und relationale Datenbanken.

Die Rolle der Automatisierung

Das Wort des Tages war Migration. Weg von den Mainframe-Monolithen, hin zu den Client-Servern. Dies erforderte jedoch eine Aufteilung der Anwendungen auf verschiedene Ebenen, die dem Client-Server-Modell entsprachen: Front-End, Business- und Datenbankebene. Das war eine große Aufgabe, denn die Herausforderung war vielschichtig:

• Frontend: Übergang von Green-Screen-Terminals zu schicken grafischen Terminals mit WYSIWYG-Funktionen (ja, WYSIWYG war damals ein Feature)
• Netzwerk: Staatlichkeit war die Norm, daher war der richtige Umgang mit dem Staat von größter Bedeutung
• Datenbank: Konsistente Transaktionsabwicklung, Kompatibilität mit Transaktionsmanagern (nicht alle wollten oder konnten gleichzeitig wechseln)
• Neue Sprachen: COBOL war die vorherrschende Sprache für die Geschäftslogik. Die neue Serverwelt unterstützte jedoch weitere Sprachen, wie C, C++ und Java.
• Betriebssysteme: Unix und seine zahlreichen Varianten, Windows und X für die Front-End-Interaktion.

Es war klar, dass ein disziplinierter Ansatz erforderlich war, um erfolgreich zu sein. Und hier kamen das Verstehen von Anwendungen und die Automatisierung ins Spiel. Anwendungsverständnis kann für jeden etwas anderes bedeuten, aber hier definieren wir es als eine Methode zur Extraktion der wichtigsten Attribute und Merkmale der Anwendung. Die Extraktion erfolgt programmatisch auf wiederholbare Weise und wird in einem Repository als Metamodell der Anwendung und ihrer Komponenten gespeichert. Die Attribute und Merkmale müssen sorgfältig ausgewählt werden, um eine intelligente Entscheidungsfindung zu ermöglichen, wenn es an der Zeit ist, die Anwendung "umzuschreiben". "Rewriting" bedeutet eigentlich sowohl Refactoring als auch Rearchitecting. Refactoring bezieht sich auf den Code, Rearchitecting auf die Anwendung. In unserem Fall bestand die Umstrukturierung in der Neuverteilung der Anwendungskomponenten, um dem Client-Server-Paradigma am besten gerecht zu werden. In den meisten Fällen bedeutete das Aufbrechen von Monolithen sowohl Re-Architektur als auch Refactoring.

Das objektorientierte Paradigma

Der meiste Code, mit dem wir es in monolithischen Systemen zu tun hatten, war in prozeduralen Sprachen oder Berichtssprachen wie COBOL geschrieben. Ebenfalls üblich war die Verwendung von Generatoren, vor allem für Code, Bildschirmdefinitionen und Datenbankartefakte. Das frühe Refactoring wurde mit C durchgeführt, der damaligen Unix-Sprache für Geschäfts- und Datenbankschichten. Für die Front-End-Codierung war C++ bis zu einem gewissen Grad die beste Option, um die Vorteile der Windows-GUI-Funktionen zu nutzen.

Zu Beginn des neuen Jahrtausends hat Java bei den Entwicklern stark Fuß gefasst. Inzwischen ist es auch zum "Favoriten" in der Unternehmensentwicklung geworden. Java wurde einem breiteren Entwicklerkreis vorgestellt und hat einige Schlüsselaspekte der Programmierung gefördert: objektorientierte Programmierung, Trennung von Belangen, virtuelle Maschinen, Softwarepaketierung und Interoperabilität.

Durch die Verwendung eines Metamodells und eines Repositorys konnten wir eine flexible und plattformneutrale Infrastruktur und Tools aufbauen. All dies ist unserem intelligenten Automatisierungsansatz zu verdanken, der eine steckbare Unterstützung von Quell- und Zielsprachen und die Fähigkeit, zahlreiche Plattformen zu assimilieren und optimal zu nutzen, ermöglicht

ERP und SAP(r)

Ein weiterer wichtiger Trend, der Mitte der 1990er Jahre an Fahrt aufnahm und seither immer stärker wird, sind ERP-Software und -Plattformen. Eine für uns als Unternehmen besonders wichtige ERP-Software war und ist SAP. Dank unseres intelligenten Automatisierungsansatzes konnten wir dessen Entwicklung in den letzten 10-15 Jahren verfolgen und werden dies auch in Zukunft tun. Die frühere Anwendung unserer automatisierten Lösung befasste sich hauptsächlich mit Code-Refactoring und hatte einen starken Fokus auf ABAP, die Programmiersprache von SAP ERP. Wir waren und sind immer noch dabei, um SAP-Kunden mit unserer intelligenten Automatisierung zu unterstützen, insbesondere als SAP seine Reise zur Digitalisierung mit der Unterstützung von In-Memory-Datenbanken, der Einführung von S/4 und dem Wechsel in die Cloud begann.

Schlusswort

Der Beginn eines neuen Jahres ist immer eine gute Gelegenheit, Bilanz zu ziehen, nachzudenken und vorauszuplanen. Wie Sie wahrscheinlich inzwischen wissen, wiederholt sich die Geschichte. Intelligente Automatisierung bedeutet, wachsam zu bleiben und nach neuen Chancen Ausschau zu halten. Wie ich bereits angedeutet habe, sehe ich, dass sich der Zyklus nach all den Jahren nun schließt, vor allem aus meiner Sicht. Ich freue mich, sagen zu können, dass wir jetzt maschinelles Lernen in unser Automatisierungs-Repository als weiteres Werkzeug einführen, um das Verständnis für Anwendungen zu fördern und unseren Tools und Kunden neue Möglichkeiten zu eröffnen. In diesem Sinne wünsche ich Ihnen allen einen erfolgreichen Start in das neue Jahr und in das neue Kapitel, das Sie nun aufschlagen werden. Unser Vorsatz für das neue Jahr ist es, mehr Blogs über uns, unseren intelligenten Automatisierungsansatz und die von uns verwendeten Technologien zu veröffentlichen.

Niko Faradouris, leitender technischer Architekt, smartShift Technologies, Mannheim