Mainframe- und Midrangemodernisierung mit Azure Logic Apps

In diesem Leitfaden wird beschrieben, wie Sie den Geschäftswert und die Flexibilität Ihrer Organisation steigern können, indem Sie Ihre Mainframe- und Midrange-Umgebungen mit Azure Logic Apps modernisieren. Die aktuelle Geschäftswelt erlebt eine Ära der Hyperinnovation und ist ständig auf der Suche nach Unternehmenseffizienz, Kostenreduzierung, Wachstum und Geschäftsausrichtung. Organisationen suchen nach Möglichkeiten zur Modernisierung, und eine effektive Strategie besteht darin, den geschäftlichen Wert bei Verwendung vorhandener Legacy-Ressourcen zu erhöhen.

Für Organisationen, die in Mainframe- und Midrange-Systeme investiert haben, bedeutet dies, dass sie die Plattformen, die dazu beigetragen haben, Menschen auf den Mond zu schicken oder die aktuellen Finanzmärkte aufzubauen, optimal nutzen und ihren Wert mithilfe der Cloud und künstlicher Intelligenz (KI) erweitern können. In diesem Szenario kommen Azure Logic Apps und seine nativen Funktionalitäten für die Integration mit Mainframe- und Midrange-Systemen ins Spiel, indem sie die Tür zur KI-Welt für Legacy-Investitionen öffnen. Neben anderen Funktionen beinhaltet Azure Logic Apps die Kernfunktionen von Host Integration Server (HIS), der seit über 20 Jahren zentral für die Mainframe- und Midrange-Integration bei den strategischsten Kunden von Microsoft eingesetzt wird. Daher wurde Azure Logic Apps zu einer Integrationsplattform als ein Dienst (Integration Platform-as-a-Service, iPaaS) für Mainframe- und Midrange-Systeme.

Wenn Unternehmensentwickler*innen Integrationsworkflows mit Azure Logic Apps erstellen, können sie neue Anwendungen mit wenig oder gar keinem Code oder weniger benutzerdefiniertem Code schneller bereitstellen. Entwickler*innen, die Visual Studio Code und Visual Studio verwenden, können produktiver sein als diejenigen, die IBM-Mainframe-Entwicklungstools und -Technologien verwenden, da sie keine Kenntnisse über Mainframesysteme und -infrastruktur benötigen. Azure Logic Apps ermöglicht Geschäftsanalyst*innen und Entscheidungsträger*innen, wichtige Legacyinformationen schneller zu analysieren und in Berichten zusammenzustellen. Sie können direkt auf Daten in Großrechnerdatenquellen zugreifen, sodass Mainframeentwickler*innen keine Programme zur Extraktion und Konvertierung komplexer Mainframestrukturen erstellen müssen.

Cloudnative Funktionen für die Integration von Mainframe- und Midrangesystemen

Seit 1990 bietet Microsoft die Integration in Mainframe- und Midrangesysteme über Microsoft Communications Server an. Die Weiterentwicklung von Microsoft Communications Server hat im Jahr 2000 zur Erstellung von Host Integration Server (HIS) geführt. HIS war zwar anfangs ein Systemnetzwerkarchitektur (SNA)-Gateway, wurde jedoch um IBM-Datenspeicher (DB2, VSAM und Informix), IBM-Transaktionssysteme (CICS, IMS und IBM i) und IBM-Messaging (MQ Series) erweitert. Die strategischen Kunden von Microsoft nutzen diese Technologien seit mehr als 20 Jahren.

Damit Kunden, die Anwendungen und Daten in Azure ausführen, diese Technologien weiterhin verwenden können, wurden diese Funktionen schrittweise in Azure Logic Apps und Visual Studio integriert. Beispiel: Der HIS-Designer für Logic Apps, der in Visual Studio ausgeführt wird, und das 3270-Designtool helfen Ihnen beim Erstellen von Metadatenartefakten, die von den integrierten Connectors benötigt werden, die Sie für die Mainframe- und Midrange-Integration in Azure Logic Apps verwenden. Diese integrierten Connectors werden mit den gleichen Computeressourcen wie Standard-Logik-App-Workflows ausgeführt. Mit diesem Design können Sie nicht nur latenzarme Szenarien erreichen, sondern auch Ihre Reichweite erweitern, um mehr Kundenanforderungen für Notfallwiederherstellung und Hochverfügbarkeit zu adressieren.

Weitere Informationen zu den Funktionen von Microsoft für die Integration von Mainframe- und Midrangesystemen finden Sie in den folgenden Abschnitten.

Microsoft HIS-Designer für Logic Apps

Dieses Tool erstellt Mainframe- und Midrange-Systemmetadatenartefakte für Azure Logic Apps und arbeitet mit Microsoft Visual Studio zusammen, indem es einen grafischen Designer bereitstellt, mit dem Sie Metadatenobjekte erstellen, anzeigen, bearbeiten und zuordnen können. Azure Logic Apps verwendet diese Zuordnungen, um die Programme und Daten in Mainframe- und Midrangesystemen zu spiegeln. Weitere Informationen finden Sie unter HIS Designer für Logic Apps.

Microsoft 3270-Designtool

Dieses Tool zeichnet Bildschirme, Navigationspfade, Methoden und Parameter für die Aufgaben in Ihrer App auf, sodass Sie diese Aufgaben als 3270-Connectoraktionen hinzufügen und ausführen können. Während der HIS Designer für Logic Apps auf Transaktionssysteme und -daten ausgerichtet ist, zielt das 3270-Designtool auf 3270-Anwendungen ab. Weitere Informationen finden Sie unter 3270-Designtool.

Azure Logic Apps-Connectors für IBM-Mainframe- und Midrangesysteme

In den folgenden Abschnitten werden die integrierten, anbieterbasierten Connectors beschrieben, mit denen Sie beim Erstellen von Standardworkflows in Azure Logic Apps auf IBM-Mainframe- und Midrangesysteme zugreifen und mit diesen interagieren können.

IBM 3270

Mit diesem Azure Logic Apps-Connector für 3270 können Standardworkflows auf IBM Mainframe-Apps zugreifen und diese ausführen, die normalerweise mittels Navigation in 3270-Emulatorbildschirmen gesteuert werden. Der Connector verwendet den TN3270-Datenstrom. Weitere Informationen finden Sie unter Integrieren von bildschirmgesteuerten 3270-Apps auf IBM-Mainframes in Azure mithilfe von Azure Logic Apps und dem IBM 3270-Connector.

IBM Customer Information Control System (CICS)

Dieser Azure Logic Apps-Connector für CICS bietet Standardworkflows die Möglichkeit, mit CICS-Programmen mit mehreren Protokollen wie TCP/IP und HTTP zu interagieren und zu integrieren. Wenn Sie mit LU6.2 auf CICS-Umgebungen zugreifen müssen, müssen Sie Host Integration Server (HIS) verwenden. Weitere Informationen finden Sie unter Integrieren von CICS-Programmen auf IBM-Mainframes mit Standardworkflows in Azure Logic Apps mithilfe des IBM CICS-Connectors.

IBM DB2

Dieser Azure Logic Apps-Connector für DB2 ermöglicht Verbindungen zwischen Standardworkflows und DB2-Datenbanken, die lokal oder in Azure vorhanden sind. Der Connector bietet IT-Expert*innen und Entwickler*innen von Unternehmen direkten Zugriff auf wichtige Informationen, die in DB2-Datenbankverwaltungssystemen gespeichert sind. Weitere Informationen finden Sie unter Zugreifen auf und Verwalten von IBM DB2-Ressourcen mithilfe von Azure Logic Apps.

IBM-Hostdateien

Dieser Azure Logic Apps -Connector für Host Files stellt einen dünnen Wrapper um das Feature „Flat File Parser“ in Host Integration Server bereit. Dieser „Offlineconnector“ bietet Vorgänge zum Analysieren oder Generieren von Binärdaten in und aus Hostdateien. Diese Vorgänge erfordern, dass diese Daten von einem Trigger oder einer anderen Aktion stammen, die Binärdaten erzeugt. Weitere Informationen finden Sie unter Analysieren und Generieren von IBM-Hostdateien mithilfe von Azure Logic Apps.

IBM i

Mit diesem Azure Logic Apps-Connector für IBM i können Standard-Workflows mit auf IBM i-Systemen mit TCP/IP ausgeführten COBOL- und RPG-Programmen interagieren und diese integrieren. Wenn Sie mit LU6.2 auf IBM i-Umgebungen zugreifen müssen, müssen Sie Host Integration Server (HIS) verwenden. Weitere Informationen finden Sie unter Integrieren von COBOL- und RPG-Programmen auf IBM-Midranges mit Standardworkflows in Azure Logic Apps mithilfe des IBM i-Connectors.

IBM Informationssicherheitsverwaltungssystem (IMS)

Dieser Azure Logic Apps-Connector für IMS verwendet die IBM IMS Connect-Komponente, die einen leistungsstarken Zugriff von Standardworkflows auf IMS-Transaktionen über TCP/IP ermöglicht. Dieses Modell verwendet die IMS-Nachrichtenwarteschlagen zum Verarbeiten der Daten. Weitere Informationen finden Sie unter Integrieren von IMS-Programmen auf IBM-Mainframes mit Standardworkflows in Azure Logic Apps mithilfe des IBM IMS-Connectors.

IBM MQ

Dieser Azure Logic Apps-Connector für MQ ermöglicht Verbindungen zwischen Standardworkflows und lokalen oder in Azure vorhandenen IBM MQ-Servern. Microsoft bietet auch IBM MQ-Integrationsfunktionen für Host Integration Server und BizTalk Server. Weitere Informationen finden Sie unter Herstellen einer Verbindung mit einem IBM MQ-Server über einen Workflow in Azure Logic Apps.

Herausforderungen für die Modernisierung von Mainframe- und Midrange-Systemen

Mainframe- und Midrange-Systeme können mehrere Umgebungen hosten, die Programme, Daten, Dateien und Tools enthalten. Im Laufe der Jahre wurden diese Umgebungen möglicherweise nicht umgestaltet oder mussten trotz Hardwareupgrades weiter wachsen und kamen dadurch an ihre Grenzen. Diese Umgebungen wurden möglicherweise auch von mehreren Entwicklern und IT-Administratoren verwaltet, die unterschiedlichen Programmiermustern und -techniken folgen, oder haben andere Parteien beauftragt, um bei Aufgaben zu helfen, die spärliche Expertise auf dem Markt erfordern. Zusammen mit einem schrumpfenden Pool erfahrener Profis führen all diese Faktoren zu einer komplexen und herausfordernden Aufgabe bei der Modernisierung von Mainframe- und Midrange-Umgebungen.

Während die folgende Liste nicht umfassend ist, beinhaltet die Definition einer erfolgreichen Modernisierungsstrategie zumindest Möglichkeiten zur Behandlung der folgenden Aufgaben:

• Verwalten der aktuellen Indikatoren und Ziele auf Dienstebene für Ihre Umgebungen.
• Verwalten der Koexistenz zwischen Legacydaten und migrierten Daten.
• Führen Sie DevOps während der Koexistenz in allen Umgebungen durch.
• Verwalten der Abhängigkeiten zwischen den Anwendungen.
• Definieren der Zukunft des Mainframe-Zeitplaners und der Aufträge.
• Definieren einer Strategie zum Ersetzen Commercial Off-The-Shelf (COTS)-Produkte.
• Durchführen hybrider funktionaler und nichtfunktionaler Testaktivitäten.
• Verwalten externer Abhängigkeiten oder Schnittstellen.

Unter Berücksichtigung dieser Aufgaben wählen Kunden in der Regel einen der folgenden Wege zur Modernisierung von Mainframe- und Midrange-Systemen aus:

• Big Bang

  Dieser Ansatz basiert weitgehend auf dem Wasserfallmodell für die Softwareentwicklung, jedoch mit phasenweisen Iterationen. Der Big Bang-Ansatz wird von Kunden mit kleinen Mainframe- oder Midrange-Systemen und Umgebungen mit geringer Komplexität aufgrund einer geringen Anzahl von Codezeilen, geringer Anwendungsdichte und bekannten älteren Systemen oder Programmiersprachen verwendet.

• Agile Wellen

  Dieser Ansatz folgt den Agile-Prinzipien der Softwareentwicklung. Der Agile-Wellen-Ansatz wird von Kunden mit größeren Mainframe- oder Midrange-Systemen und Umgebungen mit hoher Komplexität aufgrund einer hohen Anzahl von Codezeilen, hoher Anwendungsdichte, weniger bekannten Systemen oder Programmiersprachen und einer hohen Anzahl von Abhängigkeiten und Schnittstellen verwendet.

Die Entscheidung zwischen diesen Pfaden hängt von den Anforderungen und Szenarien Ihrer Organisation ab. Jeder Weg hat zu berücksichtigende Vorteile und Nachteile. In den folgenden Abschnitten finden Sie weitere Informationen zu diesen Modernisierungsansätzen.

Big Bang oder Wasserfall

Eine Big Bang-Migration umfasst in der Regel die folgenden Phasen:

1. Vorstellung: Einführung

2. Planung: Identifizieren und Vorbereiten von Planungsergebnissen, z. B. Umfang, Zeit und Ressourcen.

3. Erstellung: Beginnt nach der Genehmigung der Planungsergebnisse

   In dieser Phase wird auch erwartet, dass alle Arbeiten für Abhängigkeiten identifiziert worden sind, und dann können die Migrationsaktivitäten beginnen. Der Abschluss der Migrationsarbeit umfasst mehrere Iterationen.

4. Stabilisierung oder Tests: Beginnt, wenn die migrierte Umgebung, Abhängigkeiten und Anwendungen für die Testregionen in der Mainframeumgebung getestet werden.

5. Bereitstellen: Nachdem alles genehmigt worden ist, wird die Migration in die Produktion überführt.

Organisationen, die sich für diesen Ansatz entscheiden, konzentrieren sich in der Regel auf die Sperrzeit, den Migrationsumfang und die Ressourcen. Dieser Pfad klingt positiv, birgt aber die folgenden Risiken:

• Migrationen können Monate oder gar Jahre dauern.

• Bereitstellungen in der Produktion sind riskanter.

• Die Analyse, die Sie zu Beginn der Migration oder während der Planung durchführen, ist nicht mehr korrekt, weil diese Informationen in der Regel veraltet sind.

• Organisationen konzentrieren sich in der Regel auf umfassende Dokumentationen, um Bereitstellungsrisiken für die Lieferung zu reduzieren.

  Die Zeit, die für die Bereitstellung von Planungsartefakten aufgewendet wird, hat jedoch genau den gegenteiligen Effekt. Wer sich stärker auf die Planung als auf die Ausführung konzentriert, neigt dazu, die Ausführung zu verzögern, was auf lange Sicht zu höheren Kosten führt.

Agile Wellen

Ein Agile-Ansatz ist ergebnisorientiert und konzentriert sich auf das Erstellen von Software und nicht auf die Planung von Ergebnissen. Die ersten Phasen einer agilen Umsetzung können aufgrund der zu überwindenden organisatorischen Hindernisse chaotisch und komplex für das Migrationsteam sein. Wenn das Migrationsteam jedoch nach mehreren Sprints in der Ausführung gereift ist, wird die Reise reibungsloser verlaufen. Das Ziel dieses Ansatzes ist es, Funktionen in regelmäßigen Abständen für die Produktion freizugeben und schneller als bei einem Big-Bang-Ansatz einen geschäftlichen Nutzen zu erzielen.

Eine Agile-Wellen-Migration umfasst in der Regel die folgenden Sprints:

• Sprint Null (0)

  • Definieren Sie das Team, einen anfänglichen Arbeitsrückstand und die Kernabhängigkeiten.
  • Identifizieren Sie die Features und ein Minimum Viable Product (MVP), das bereitgestellt werden soll.
  • Starten Sie die Mainframebereitschaft mit einer ausgewählten Gruppe von Arbeitsaufgaben oder Benutzergeschichten, um die Arbeit zu beginnen.

• Sprint 1, 2, ..., N

  Jeder Sprint hat ein Ziel, bei dem das Team eine Versandmentalität beibehält, d. h. es konzentriert sich auf die Erreichung der Migrationsziele und die Übergabe der Ergebnisse an die Produktion. Das Team kann eine Gruppe von Sprints nutzen, um ein bestimmtes Feature oder eine Welle von Features bereitzustellen. Jedes Feature enthält Segmente von Integrationsworkloads.

Es sind gemeinsame Elemente, z. B. Aufträge und Abhängigkeiten, vorhanden, die sich auf die gesamte Umgebung auswirken. Eine erfolgreiche Strategie konzentriert sich darauf, Aufträge teilweise zu aktivieren, Anwendungen für die Modernisierung umzugestalten und die Systeme mit den meisten Abhängigkeiten bis zum Ende zu belassen, um zunächst den Umfang der Migrationsarbeit zu reduzieren und dann den Umfang der Modernisierungsbemühungen zu vervollständigen.

Microsoft empfiehlt die Modernisierung von Mainframe- und Midrange-Systemworkloads, indem sie einem iterativen, auf agilen Wellen basierenden Modell folgen, bei dem sie sich auf Investitionen in die neue Plattform konzentrieren und gleichzeitig das Wachstum älterer Systeme einschränken. Dieser Ansatz reduziert die Implementierungsrisiken erheblich, da der bestehende Geschäftswert erhalten bleibt und gleichzeitig die modernisierte Umgebung eingeführt wird. Auf diese Weise kann Ihr Team auch Technologiekompetenzen nutzen, die Ihrem Unternehmen helfen, wettbewerbsfähiger zu sein. In diesem Szenario können Azure Logic Apps Ihnen bei ihrer Modernisierung helfen.

Modernisierungsmuster

Ein guter Entwurf umfasst Faktoren wie Konsistenz und Kohärenz im Komponentenentwurf und in der Bereitstellung, Wartbarkeit zur Vereinfachung der Verwaltung und Entwicklung sowie Wiederverwendbarkeit, um die Wiederverwendung von Komponenten und Subsystemen in anderen Anwendungen und Szenarien zu ermöglichen. Während der Entwurfs- und Implementierungsphase getroffene Entscheidungen haben großen Einfluss auf die Qualität und die Gesamtkosten.

Das Azure Architecture Center bietet getestete Entwurfs- und Implementierungsmuster, die das Problem, das sie lösen, sowie Überlegungen zur Anwendung des Musters und ein Beispiel auf der Grundlage von Microsoft Azure beschreiben. Es gibt zwar mehrere Entwurfs- und Implementierungsmuster, aber einige der wichtigsten Muster für die Mainframe-Modernisierung sind die Muster „Anti-corruption Layer“, „Strangler Fig“, „Saga“ und „Choreography“.

Muster „Antibeschädigungsebene“

Unabhängig davon, welchen Modernisierungsansatz Sie auswählen, müssen Sie eine „Antibeschädigungsebene" mithilfe von Azure Logic Apps implementieren. Dieser Dienst bildet die Fassade oder Adapterschicht zwischen dem Legacysystem des Großrechners und Azure. Für einen effektiven Ansatz müssen die Mainframeworkloads identifiziert werden, die integriert werden oder als Mainframe-Integrationsworkloads koexistieren sollen. Erstellen Sie eine Strategie für jede Integrationsworkload, d. h. für die Schnittstellen, die Sie für die Migration einer Mainframeanwendung aktivieren müssen.

Weitere Informationen finden Sie unter Antibeschädigungsebene.

Strangler-Muster

Nachdem Sie die Antibeschädigungsebene implementiert haben, erfolgt die Modernisierung schrittweise. Für diese Phase müssen Sie das Muster „Strangler Fig“ verwenden, bei dem Sie Mainframeworkloads oder -Features identifizieren, die Sie inkrementell modernisieren können. Wenn Sie z. B. eine CICS-Anwendung modernisieren möchten, müssen Sie nicht nur die CICS-Programme, sondern wahrscheinlich auch die 3270-Anwendungen zusammen mit den entsprechenden externen Abhängigkeiten, Daten und Aufträgen modernisieren.

Nachdem Sie schließlich alle Workloads oder Features im Mainframesystem durch Ihr neues System ersetzt haben, beenden Sie den Migrationsprozess. Das bedeutet, dass Sie Ihr Legacysystem außer Betrieb nehmen können.

Weitere Informationen finden Sie unter Strangler Fig-Muster.

Saga- und Choreography-Muster

Verteilte Transaktionen wie das Zweiphasencommit (2PC)-Protokoll erfordern, dass alle Teilnehmer in einer Transaktion einen Commit oder Rollback ausführen, bevor die Transaktion fortgesetzt werden kann. Cloudhybridarchitekturen funktionieren besser nach einem Paradigma der letztendlichen Konsistenz als nach einem verteilten Transaktionsmodell.

Das Entwurfsmuster „Saga“ ist eine Möglichkeit zum Verwalten der Konsistenz für Dienste in Szenarios mit verteilten Transaktionen. Ein Saga ist eine Sequenz von Transaktionen, die alle Dienste aktualisieren und eine Meldung oder ein Ereignis veröffentlichen, um den nächsten Transaktionsschritt auszulösen. Wenn ein Schritt fehlschlägt, werden kompensierende Transaktionen ausgeführt, die den vorhergehenden Transaktionen entgegenwirken. Weitere Informationen finden Sie unter Saga-Muster für verteilte Transaktionen.

In Azure Logic Apps können Workflows als Choreographen fungieren, um Sagas zu koordinieren. Workflowaktionen sind atomar, sodass Sie diese einzeln erneut ausführen können. Der Aktionstyp Bereich bietet die Möglichkeit, eine Gruppe von Aktionen nur auszuführen, nachdem eine andere Gruppe von Aktionen erfolgreich war oder fehlschlug. Azure Logic Apps führt Ausgleichstransaktionen auf Bereichsebene durch, während Azure Event Grid und Azure Service Bus die für bestimmte Domänen erforderliche Ereignisverwaltung bereitstellen. Alle diese Dienste, aus denen Azure-Integrationsdienste bestehen, bieten den Kunden den erforderlichen Support, wenn sie eine zuverlässige Integrationsplattform für unternehmenskritische Szenarien benötigen. Weitere Informationen finden Sie unter Choreographiemuster.

Während dieser Artikel einige Modernisierungsmuster behandelt, erfordern komplexe Lösungen viele weitere Muster, und Sie müssen die Modernisierungsziele Ihrer Organisation genau verstehen. Obwohl die Aufgabe, den Wert von Legacy-Ressourcen zu verlängern, eine Herausforderung darstellt, ist diese Option die beste Möglichkeit, Investitionen in diese Ressourcen zu erhalten und ihren Geschäftswert zu verlängern.

Nächste Schritte

• Azure Architecture Center für Mainfrrame- und Midrangesysteme