IT Management Januar/Februar 2022

Weitere Magazine

Empfehlungen

Info

48 | IT INFRASTRUKTUR Einerseits sind die Komponenten und ihre Vernetzung über Aufrufbeziehungen zu betrachten. Andererseits sind die Komponenten entsprechend ihres Entwicklungsmodells klassifiziert. Dabei stehen die Komponenten A1 und A2 für Applikationen, die nach einem agilen Vorgehensmodell (A) weiterentwickelt werden. C1, C2 und C2 sind Komponenten mit einem klassischen Vorgehensmodell (C). Erfolgsfaktor: Dienste für eine Two-Speed-IT Dienste spielen in einer modernen Systemlandschaft eine zentrale Rolle. Schon Bild 2: Visualisierung des Problems. Die C-Applikationen der Kernapplikation benötigen neue Dienste. Fehlende Dienste bremsen die A-Projekte Die Entwicklung ist nicht mit der Einführung abgeschlossen. Das ist nur der Startpunkt für die Weiterentwicklung und Pflege eines Systems. Wenn zu Beginn das A-Projekt die benötigten Dienste bekommen oder sich Abhilfe geschaffen hat, so verstummt damit nicht der Ruf nach neuen oder überarbeiteten Diensten. A1 A2 Diensten gebildet werden. In solch einem Fall sollte man sich überlegen, ob es noch andere potentielle Verbraucher solch eines Dienstes gibt. In diesem Fall ist eine allgemeine Bereitstellung und langfristig eine enge Integration in das passende System empfehlenswert. Die Agilität birgt in sich die Gefahr, dass vermeintlich kurzlebige Lösungen „unsauber“ umgesetzt werden, die danach mehr und mehr zu einem Problem werden können. Es ist also wichtig, sich auch über die längerfristigen Aspekte frühzeitig Gedanken zu machen. Falls die Anforderungen an die Datenaktualität und -verwendung dies zulassen, kann ein fehlender Dienst über eine asynchrone Datenbereitstellung kompensiert werden. Dies kann beispielsweise für Stammdaten genutzt werden, die sich selten ändern. Hier wäre eine Datenversorgung für eine lesende Komponente ein gangbarer Weg. C1 C2 lange zieht die „service-oriented architecture“ (SOA) ihre Kreise durch die IT. Neuerdings werden einige Grundgedanken daraus weiter vorangetrieben und finden sich zunehmend als Micro-Services in neu konzipierten Systemen wieder. Für eine Two-Speed-IT müssen auch die beteiligten Dienste ins Auge gefasst werden. Damit die schnelllebigen A-Komponenten entwickelt werden können, müssen die benötigten Back-end-Dienste genutzt werden können. Im Idealfall stehen die Dienste der C-Komponenten bereits in einer technisch verwertbaren Form zur Verfügung. Alternativ können Wege gesucht werden, um fehlende Dienste zu kompensieren. C3 Quelle: www.explore.iteratec.com/blog/ Das Business – beispielsweise in Banken und Versicherungen – will und muss neue Produkte einführen. Dabei kommt man über kurz oder lang nicht an den C-Applikationen der Kernsysteme vorbei. Dort werden neue Dienste benötigt. Durch die Trägheit der C-Projekte kann dies nicht in der Geschwindigkeit geschehen, die von den A-Projekten gewünscht wäre (siehe Bild 2). Erfolgsfaktor: Kompensation von fehlenden Diensten Eine naheliegende Art, mit fehlenden Diensten umzugehen, ist es, diese einfach im Rahmen des Projekts zu bauen. Dazu gibt es einige Muster, die hierbei Anwendung finden können: Die Dienste können idealerweise aus der Komposition von anderen, bestehenden Die schlechteste aller Möglichkeiten soll auch nicht ungenannt bleiben. Dies wäre die schlichte Reimplementierung der fehlenden Funktionalität. Damit bekommt man eine Duplizierung in die Systeme die absolut unerwünscht ist. Im besten Fall hat dies doppelten Aufwand bei einer Anpassung zur Folge. Im schlechtesten Fall laufen die beiden Implementierungen auseinander und produzieren verschiedene Ergebnisse – fachlich gesehen ein GAU. Leider ist das trotzdem immer wieder einmal zu beobachten. Erfolgsfaktor: Technische Anbindung von Diensten Dass ein Dienst in einer C-Komponente vorhanden ist heißt noch nicht, dass er auch von einer A-Komponente angesprochen werden kann. Hierzu müssen unter Umständen auch noch technische Hürden überwunden werden. Auch wenn es prinzipiell technische Möglichkeiten gibt, dass beispielsweise Cobol-Programme auf dem Host mit Programmen in C# oder Java auf virtuellen www.it-daily.net
IT INFRASTRUKTUR | 49 Servern kommunizieren, so muss diese theoretische Möglichkeit in einer konkreten Situation doch auch eingesetzt werden. In der Regel wird hier eine Middleware zum Einsatz kommen, welche diese Hürde überwindet. Aber schon alleine die Einführung solch einer Middleware kann die Ausmaße eines C-Projekts annehmen. Auch C-Komponenten können mehr A werden Wenn man in mehreren Geschwindigkeiten unterwegs ist und Kopplungen zwischen den verschiedenen Teilen existieren, dann ergibt es sich mehr oder weniger zwangsläufig, dass sich die verschiedenen Geschwindigkeiten beeinflussen: • Die A-Komponenten werden etwas gebremst. • Die C-Komponenten werden beschleunigt. Insbesondere der zweite Punkt kann ein durchaus gewünschter Nebeneffekt sein. Durch die Anregungen aus den A-Komponenten werden die eingfahrenen Vorgehensweisen der C-Komponenten hinterfragt und auf den Prüfstand gestellt: • Wer braucht die einzelnen Artefakte, die erstellt werden müssen? • Wann und in welcher Qualität müssen die einzelnen Artefakte vorliegen? • Warum müssen die Ergebnisse fest getaktet zu lange vorher definierten Release-Terminen eingeführt werden? IT-Governance und regulatorische Anforderungen IT-Governance und regulatorische Anforderungen werden von der Software-Entwicklung oft als starre, von außen kommende Regelwerke empfunden. Die eigentlich inhärenten und sinnvollen Ziele sind dahinter verborgen: • Risikominimierung • Sicherheit • Nachvollziehbarkeit Diese haben sich im Laufe der Zeit zu Regularien verfestigt, die unter dem damaligen Stand der Kunst angemessen waren. Jetzt müssen sie mit der neuen Situation auf den Prüfstand gestellt und neu bewertet werden. Ausgehend von den gleichen Zielen kommen wir mit den verschiedenen Vorgehensmodellen zu unterschiedlichen Vorgaben für die Projekte. Keines dieser Ziele wird aufgegeben. Nur die Umsetzung wird unterschiedlich ausfallen. Beispielsweise kann das Ziel der Nachvollziehbarkeit heute auf andere technische Rahmenbedingungen aufsetzen als die klassischen Projekte vor 30 Jahren: Die Anforderungen sind versioniert und konsequent in einem Requirements-Engineering-Tool abgelegt. Die Design-Entscheidungen werden in einem Wiki abgelegt– natürlich versioniert. Dabei wird jeweils der Bezug zu den Anforderungen mit dokumentiert. Der Source-Code ist unter Versionskontrolle. Bei Änderungen wird über Kommentare der Bezug zu den Anforderungen und Design-Entscheidungen hergestellt. Eine konsequente und automatische Nummerierung der Build-Artefakte im Build- und Deployment-System sorgt dafür, dass immer genau festgestellt werden kann, welcher Stand der Software in jeder Umgebung vorhanden ist. Unter solchen Betrachtungen verlieren die Papier-Dokumente, die als Artefakte in klassischen Vorgehensmodellen im Zentrum stehen, ihre Bedeutung ohne, dass die damit verbundenen Ziele aufgegeben oder verändert würden. Welche weiteren Erfolgsfaktoren relevant sind und welche Schlussfolgerungen sich letztlich daraus ergeben, lesen Sie in der kommenden Ausgabe. Quellen: https://explore.iteratec.com/blog/erfolgsfaktoren-fuer-eine-two-speed-it https://www.bcg.com/de-de/publications/2016/software-agile-digital-transformation-end-of-two-speed-it https://www.capgemini.com/de-de/wp-content/uploads/sites/5/2018/07/Capgemini_WP1-bimodaleIT.pdf www.it-daily.net
Seite 1 und 2: JANUAR/FEBRUAR 2022 RPA-SOFTWARE- L
Seite 3 und 4: it-daily.net mehr als nur tägliche
Seite 5 und 6: IT MANAGEMENT | 5 30 20 10 COVERSTO
Seite 7 und 8: TRENDS | 7 DIE WICHTIGSTEN IT-GESET
Seite 9 und 10: TRENDS | 9 EDGE COMPUTING FÜNF ENT
Seite 11 und 12: COVERSTORY - IT MANAGEMENT | 11 Dur
Seite 13 und 14: ADVERTORIAL - IT MANAGEMENT | 13 NA
Seite 15 und 16: IT MANAGEMENT | 15 GREEN IT NEU GED
Seite 17 und 18: IT MANAGEMENT | 17 umzusetzen ist,
Seite 19 und 20: IT MANAGEMENT | 19 weniger Personen
Seite 21 und 22: IT MANAGEMENT | 21 schäftstelefons
Seite 23 und 24: IT MANAGEMENT | 23 ANGEKOMMEN 20 %
Seite 25 und 26: IT MANAGEMENT | 25 INDUSTRIE 4.0 DI
Seite 27 und 28: IT MANAGEMENT | 27 Nummern, die Zei
Seite 29 und 30: IT MANAGEMENT | 29 wie vor manuell
Seite 31 und 32: IT MANAGEMENT | 31 39 % BEDROHUNGSL
Seite 33 und 34: IT MANAGEMENT | 33 SECURITY-TRENDS
Seite 35 und 36: IT MANAGEMENT | 35 breiten Palette
Seite 37 und 38: IT MANAGEMENT | 37 Wahlen 2020. Wä
Seite 39 und 40: IT MANAGEMENT | 39 Faktoren wie die
Seite 41 und 42: IT INFRASTRUKTUR | 41 knüpften End
Seite 43 und 44: IT INFRASTRUKTUR | 43 Sämtliche, f
Seite 45 und 46: IT INFRASTRUKTUR | 45 für Laien is
Seite 47: IT INFRASTRUKTUR | 47 • Das Produ
Seite 51 und 52: SAVE THE DATE! VORSCHAU | 51 Digita

IT Management Januar/Februar 2022

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?