[et_pb_section fb_built=”1″ fullwidth=”on” _builder_version=”4.16″ _module_preset=”default” global_colors_info=”{}”][et_pb_fullwidth_header title=”Kontrollverlust in Softwaresystemen?” subhead=”Strukturen zur Beherrschung der neuen Un\u00fcbersichtlichkeit und die Unendlichkeit von Software” content_max_width_tablet=”” content_max_width_phone=”100%” content_max_width_last_edited=”on|desktop” _builder_version=”4.17.4″ _module_preset=”default” title_font=”|600|||||||” title_font_size=”54px” subhead_font=”|600|||||||” background_enable_color=”off” use_background_color_gradient=”on” background_color_gradient_stops=”rgba(0,63,134,0.81) 0%|rgba(0,63,134,0.47) 100%” background_color_gradient_overlays_image=”on” background_image=”https:\/\/www.itech-progress.com\/wp-content\/uploads\/2021\/06\/abstract-1278058_1920-rotated.jpg” width=”100%” height=”443px” custom_margin=”1px||||false|false” custom_margin_tablet=”1px||||false|false” custom_margin_phone=”0px||||false|false” custom_margin_last_edited=”on|phone” custom_padding=”129px||||false|false” custom_padding_tablet=”129px||||false|false” custom_padding_phone=”120px||||false|false” custom_padding_last_edited=”on|desktop” title_font_size_tablet=”30px” title_font_size_phone=”27px” title_font_size_last_edited=”on|desktop” global_colors_info=”{}”][\/et_pb_fullwidth_header][\/et_pb_section][et_pb_section fb_built=”1″ _builder_version=”4.17.3″ _module_preset=”default” global_colors_info=”{}”][et_pb_row column_structure=”1_2,1_2″ _builder_version=”4.17.4″ _module_preset=”default” use_background_color_gradient=”on” background_color_gradient_direction=”198deg” background_color_gradient_stops=”rgba(243,243,243,0) 0%|#f3f3f3 100%” global_colors_info=”{}”][et_pb_column type=”1_2″ _builder_version=”4.17.3″ _module_preset=”default” global_colors_info=”{}”][et_pb_image src=”https:\/\/www.itech-progress.com\/wp-content\/uploads\/2022\/06\/Java.png” alt=”DevSecOps” title_text=”Java” align=”center” _builder_version=”4.17.4″ _module_preset=”default” width=”45%” width_tablet=”45%” width_phone=”46%” width_last_edited=”on|desktop” border_radii=”on|10px|10px|10px|10px” border_color_bottom=”#003F86″ border_color_left=”#003F86″ global_colors_info=”{}”][\/et_pb_image][\/et_pb_column][et_pb_column type=”1_2″ _builder_version=”4.17.3″ _module_preset=”default” global_colors_info=”{}”][et_pb_text _builder_version=”4.17.4″ _module_preset=”default” locked=”off” global_colors_info=”{}”]<\/p>\n
Im Rahmen des Java Forums in Stuttgart am 07.07.2022 h\u00e4lt Holger Tiemeyer einen spannenden Vortrag, welcher sich mit dem Thema \u201eKontrollverlust in Softwaresystemen?\u201c befasst.<\/p>\n
Im Vorfeld konnten wir mit Holger \u00fcber seinen Vortrag sprechen und erfahren wichtige Fragestellungen und Ansatzpunkte zu dieser Problematik.<\/p>\n
[\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.17.4″ _module_preset=”default” global_colors_info=”{}”][et_pb_column type=”4_4″ _builder_version=”4.17.4″ _module_preset=”default” global_colors_info=”{}”][et_pb_testimonial author=”Holger Tiemeyer” portrait_url=”https:\/\/www.itech-progress.com\/wp-content\/uploads\/2020\/09\/Tiemeyer.png” portrait_width=”144px” portrait_height=”141px” _builder_version=”4.17.4″ _module_preset=”default” global_colors_info=”{}”]<\/p>\n
Als studierter Informatiker mit Nebenfach Psychologie verbindet Holger Tiemeyer in seinen Fachvortr\u00e4gen und Ver\u00f6ffentlichungen aktuelle Themen mit weitergehenden, aus der Psychologie her- oder ableitbaren Aspekten.<\/p>\n
[\/et_pb_testimonial][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.17.4″ _module_preset=”default” global_colors_info=”{}”][et_pb_column type=”4_4″ _builder_version=”4.17.4″ _module_preset=”default” global_colors_info=”{}”][et_pb_toggle title=”Wenn du von einem \u201eKontrollverlust in Softwaresystemen\u201c sprichst, was k\u00f6nnen wir hier erwarten?” _builder_version=”4.17.4″ _module_preset=”default” title_text_color=”#003F86″ title_font=”|600|||||||” title_font_size=”20px” border_radii=”on|20px|20px|20px|20px” global_colors_info=”{}”]<\/p>\n
Holger:<\/strong> Als Berater habe ich in der j\u00fcngsten Vergangenheit einige bemerkenswerte Auspr\u00e4gungen mitbekommen: Der Hype nach der Umsetzung von Microservice-Architekturen setzte sich ungebremst in den Unternehmen durch \u2013 und das zu gro\u00dfen Teilen, ohne diesen Trend wirklich zu reflektieren. Mit dieser Herangehensweise an die Umsetzung von Microservice-Architekturen nehmen wir etwas in Kauf: Eine verborgene Komplexit\u00e4t, denn wir wissen zu Teilen gar nicht, was sich dahinter tats\u00e4chlich verbirgt. Und hierin besteht eine ungemeine Gefahr des Scheiterns eines solchen Vorhabens, denn die explizite Inkaufnahme von etwas Verborgenem \u00e4u\u00dfert sich in Softwareprojekten und ihren Umfeldern in genau dem Moment, wenn Eskalationen zunehmen, Themen zu langsam umgesetzt werden oder Digitalisierung, Modernisierung und neue Anforderungen nur schwer einzubringen sind. In einer extremen oder auch verzweifelten Form f\u00e4llt u.a. eine Aussage wie: \u201edas wird nicht funktionieren\u201c oder \u201edas ist nicht umsetzbar\u201c. In der Konsequenz nimmt die eigene Unzufriedenheit oder diejenige von Kunden oder Auftraggebern zu. Der daraus resultierende Aktionismus f\u00fchrt im weiteren Verlauf dazu, dass in einem Projektrahmen nicht mehr pro-aktiv agiert, sondern schlimmstenfalls nur noch reagiert oder das Projekt als gescheitert verurteilt wird.<\/p>\n Es kann potenziell eine Un\u00fcbersichtlichkeit oder auch ein Chaos, das nicht mehr beherrschbar erscheint – oder schlimmstenfalls sogar ist -, entstehen.<\/p>\n Nehmen wir dieses Chaos also als etwas schicksalhaftes an? Oder m\u00f6chten wir lieber die Komplexit\u00e4ten \u2013 die aus der Wahl eines geeigneten Architekturstils resultieren \u2013 aktiv angehen und beherrschbar halten und die Kontrolle \u00fcber das Vorgehen der Umsetzung von Softwaresystemen behalten? Was bedeutet dann ein geeigneter Architekturstil?<\/p>\n Und genau diesen Fragestellungen sehe ich mich sowohl in meinen Projekten als auch in meinen Trainings zu flexiblen Architekturmodellen und Cloudinfra gegen\u00fcbergestellt. Die Teilnehmer:innen dieser Schulungen bitten h\u00e4ufig um Hilfestellungen aus genau den gerade erw\u00e4hnten Aspekten heraus. Die L\u00f6sungsr\u00e4ume erarbeiten wir dann gemeinsam.<\/p>\n [\/et_pb_toggle][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.17.4″ _module_preset=”default” global_colors_info=”{}”][et_pb_column type=”4_4″ _builder_version=”4.17.4″ _module_preset=”default” global_colors_info=”{}”][et_pb_toggle title=”Du sprichst Unbewusstes, Komplexit\u00e4t und Chaos an, die wir in der digitalen Welt beherrschen wollen, was ist hier Dein Postulat?” _builder_version=”4.17.4″ _module_preset=”default” title_text_color=”#003F86″ title_font=”|600|||||||” title_font_size=”20px” border_radii=”on|20px|20px|20px|20px” global_colors_info=”{}”]<\/p>\n Holger:<\/strong> Laut C.G. Jung fassen wir das Unbewusste bis zum Zeitpunkt des Bewusstmachens als Schicksal auf. D.h. das, was uns nicht bewusst ist, kann als etwas, das evtl. nicht im Detail verstanden oder bewusst wahrgenommen wird aufgefasst- und weiter: als ein Verh\u00e4ngnis einer h\u00f6heren Macht, die das Leben bestimmt und lenkt, angesehen werden. Es wird somit hingenommen und akzeptiert.<\/p>\n Bezogen auf unsere Softwaresysteme und -architekturen w\u00e4re die Frage: Gibt es evtl. Themen, die wir in einer Entscheidungsfindung nicht sehen, die sozusagen im Verborgenen, Unbewussten liegen?<\/p>\n Eine Entscheidung f\u00fcr oder gegen eine Realisierung\/Umsetzung oder einen Architekturstil w\u00fcrde evtl. ganz anders gef\u00e4llt werden, wenn wir uns gewisse Aspekte bewusst machen.<\/p>\n Fundamentaler Ausgangspunkt ist das CAP-Theorem, welches zwar oftmals bekannt ist, doch dessen Auswirkungen auf unsere Entscheidungsfindung gerade im Kontext von Softwarearchitekturen kaum oder gar nicht beachtet wird.<\/p>\n Es geht daher nicht um das Beherrschen des Unbewussten oder der Komplexit\u00e4t, sondern um das Bewusstwerden dar\u00fcber \u2013 \u00fcber blinde Flecken und Bereiche, die uns in der Entscheidung massiv beeinflussen und die Komplexit\u00e4t reduzieren k\u00f6nnen \u2013 resultierend aus den Ergebnissen, die uns das CAP-Theorem liefert.<\/p>\n [\/et_pb_toggle][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.17.4″ _module_preset=”default” global_colors_info=”{}”][et_pb_column type=”4_4″ _builder_version=”4.17.4″ _module_preset=”default” global_colors_info=”{}”][et_pb_toggle title=”Wo hilft uns hierbei das CAP-Theorem genau?” _builder_version=”4.17.4″ _module_preset=”default” title_text_color=”#003F86″ title_font=”|600|||||||” title_font_size=”20px” border_radii=”on|20px|20px|20px|20px” global_colors_info=”{}”]<\/p>\n Holger:<\/strong> Das CAP-Theorem liefert uns eine wesentliche Erkenntnis, die uns in der Entscheidungsfindung f\u00fcr gewisse Eigenschaften in verteilten Systemen, erm\u00f6glicht: Wir m\u00fcssen uns f\u00fcr zwei der drei Eigenschaften: Konsistenz, Verf\u00fcgbarkeit und Partitionstoleranz, entscheiden.<\/p>\n Diese Entscheidung hat einen fundamentalen Einfluss auf die Ausgestaltung und weitergehenden M\u00f6glichkeiten eines Systems. Ben\u00f6tigen wir beispielsweise eine ad-hoc-Konsistenz unserer zugrundeliegenden Daten, die den ACID-Prinzipien unterliegt oder nicht?<\/p>\n Wenn ich nun von \u201eoder nicht\u201c spreche, ist dann schon jedem klar, wovon ich in der Alternative spreche? Dieses ist ein sch\u00f6nes Beispiel f\u00fcr das Bewusstmachen des Unbewussten. Was verbirgt sich denn hinter der Alternative zu ACID?<\/p>\n Wir sprechen von BASE (Base vs. S\u00e4ure \u2013 scherzhaft). Dabei steht BASE f\u00fcr Basically available, soft-state und Eventual Consistency. [\/et_pb_toggle][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.17.4″ _module_preset=”default” global_colors_info=”{}”][et_pb_column type=”4_4″ _builder_version=”4.17.4″ _module_preset=”default” global_colors_info=”{}”][et_pb_toggle title=”Du sprichst von einer Komplexit\u00e4tsreduktion durch das Bewusstmachen blinder Flecken. K\u00f6nntest du dieses noch etwas genauer darlegen?” _builder_version=”4.17.4″ _module_preset=”default” title_text_color=”#003F86″ title_font=”|600|||||||” title_font_size=”20px” border_radii=”on|20px|20px|20px|20px” global_colors_info=”{}”]<\/p>\n Holger:<\/strong> Ein zentrales Thema in der Architekturarbeit \u2013 insbesondere in Microservice-basierten Systemen – ist die Verteilung von Verantwortlichkeiten (Separation of Concerns).<\/p>\n Wo liegen denn meine Verantwortlichkeiten \u2013 fachliche und technische? In einem Service oder \u00fcber mehrere Services verteilt? Kann ich die Verantwortlichkeiten trennen \u2013 und wenn ja, dann wie?<\/p>\n Die Trennung von Verantwortlichkeiten umfasst in der Umsetzung unterschiedliche Aspekte und Bereiche. Die Frage nach der Definition eines Verantwortungsbereichs muss gemeinsam mit allen beteiligten Stakeholdern gekl\u00e4rt werden. Wir m\u00fcssen diese blinden Flecken aufdecken.<\/p>\n Ein moderner Trend ist es mit weitergehenden Aspekten zu arbeiten: Sidecars und daraus resultierend die Service-Meshes bieten uns ein enormes Potential bestimmte Komplexit\u00e4ten und Verantwortlichkeiten in die Infrastruktur auszulagern. Auch hier kommt wieder die Frage nach dem Bewusstsein \u00fcber diese M\u00f6glichkeiten zum Tragen. Ich hoffe dieses in meinem Vortrag aufzukl\u00e4ren.<\/p>\n [\/et_pb_toggle][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.17.4″ _module_preset=”default” global_colors_info=”{}”][et_pb_column type=”4_4″ _builder_version=”4.17.4″ _module_preset=”default” global_colors_info=”{}”][et_pb_toggle title=”Wie kann man dies erlernen? ” _builder_version=”4.17.4″ _module_preset=”default” title_text_color=”#003F86″ title_font=”|600|||||||” title_font_size=”20px” border_radii=”on|20px|20px|20px|20px” global_colors_info=”{}”]<\/p>\n Holger:<\/strong> Die Psychologie besch\u00e4ftigt sich mit der Fragestellung der Probleml\u00f6sung. Ein Problem wird dadurch gekennzeichnet, dass ich von einem Ausgangszustand in einen Zielzustand \u00fcbergehen m\u00f6chte, wobei zwischen diesen beiden Zust\u00e4nden eine Barriere existiert, die es zu \u00fcberwinden gilt.<\/p>\n Die Probleml\u00f6sung besteht nun darin sog. Operatoren zu finden, mit deren Hilfe ich diese Barriere \u00fcberwinden kann.<\/p>\n Der Erwerb dieser Operatoren erfolgt aufgrund von drei Arten: II.) Instruktion und<\/p>\n III.) Beobachtungslernen.<\/p>\n Aus diesen M\u00f6glichkeiten des Erwerbs m\u00fcssen die Operatoren extrahiert werden und dieses passiert anhand der Analogiebildung. Dieses Konzept geht schon auf Platon zur\u00fcck und ist essenziell. Wir erlernen die Themen anhand von Analogien.<\/p>\n Die Frage ist nun, wie uns dieser Prozess der Analogiebildung dabei helfen kann unbewusste Teile aufzudecken, um fundierte Entscheidungen f\u00fcr unsere Systemarchitekturen zu treffen, die uns die Kontrolle \u00fcber diverse Auspr\u00e4gungen erm\u00f6glichen?<\/p>\n [\/et_pb_toggle][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.17.4″ _module_preset=”default” global_colors_info=”{}”][et_pb_column type=”4_4″ _builder_version=”4.17.4″ _module_preset=”default” global_colors_info=”{}”][et_pb_toggle title=”Unendlichkeit der Software, wie definierst Du das?” _builder_version=”4.17.4″ _module_preset=”default” title_text_color=”#003F86″ title_font=”|600|||||||” title_font_size=”20px” border_radii=”on|20px|20px|20px|20px” global_colors_info=”{}”]<\/p>\n Holger:<\/strong> Gegenfrage: Wodurch ist der Rahmen eines Softwaresystems definiert? Wo liegt seine Grenze? Wir kl\u00e4ren dieses in Rahmen des Vortrags.<\/p>\n [\/et_pb_toggle][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.17.4″ _module_preset=”default” global_colors_info=”{}”][et_pb_column type=”4_4″ _builder_version=”4.17.4″ _module_preset=”default” global_colors_info=”{}”][et_pb_toggle title=”Wie k\u00f6nnen wir all diese Themen bei der Software Architektur einbringen?” _builder_version=”4.17.4″ _module_preset=”default” title_text_color=”#003F86″ title_font=”|600|||||||” title_font_size=”20px” hover_enabled=”0″ border_radii=”on|20px|20px|20px|20px” global_colors_info=”{}” sticky_enabled=”0″]<\/p>\n Holger:<\/strong> Die ISO-25010-Norm definiert Qualit\u00e4tsmerkmale f\u00fcr Software. Diesen Qualit\u00e4tsmerkmalen werden Qualit\u00e4tsszenarien, die aus den Qualit\u00e4tsanforderungen abgeleitet werden, zugeordnet und priorisiert.<\/p>\n Wichtig ist nun, dass jedes System in seinen L\u00f6sungsszenarien und -strategien in Bezug auf die in der Norm definierten Qualit\u00e4tsmerkmalen optimiert werden kann.<\/p>\n Hier f\u00e4ngt unser Entscheidungsprozess als Softwarearchitekt an. Unter Einbezug der Erkenntnisse aus dem CAP-Theorem sowie der Aufkl\u00e4rung blinder Flecken in Bezug auf die Infrastruktur (oder auch Makroarchitektur) k\u00f6nnen unsere zu realisierenden Systeme exakt auf die umzusetzenden funktionalen sowie qualitativen Merkmalen optimiert und angepasst werden. [\/et_pb_toggle][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.17.4″ _module_preset=”default”][et_pb_column _builder_version=”4.17.4″ _module_preset=”default” type=”4_4″][et_pb_text _builder_version=”4.17.4″ _module_preset=”default” hover_enabled=”0″ sticky_enabled=”0″]<\/p>\n Danke f\u00fcr die Einf\u00fchrung! Wir sind gespannt auf deinen Vortrag, und die Antworten und Empfehlungen, wie man die Kontrolle in der Software Architektur beh\u00e4lt.<\/p>\n <\/p>\n Wir freuen uns auf viele interessante Gespr\u00e4che an unserem Ausstellungsstand im Foyer des Java Forums Stuttgart<\/strong>!<\/p>\n<\/blockquote>\n [\/et_pb_text][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.17.4″ _module_preset=”default” global_colors_info=”{}”][et_pb_column type=”4_4″ _builder_version=”4.17.4″ _module_preset=”default” global_colors_info=”{}”][et_pb_image src=”https:\/\/www.itech-progress.com\/wp-content\/uploads\/2022\/06\/JavaForumStuttgart2022_Vortrag_Tiemeyer.png” title_text=”JavaForumStuttgart2022_Vortrag_Tiemeyer” show_in_lightbox=”on” align=”center” _builder_version=”4.17.4″ _module_preset=”default” width=”75%” width_tablet=”75%” width_phone=”75%” width_last_edited=”on|phone” global_colors_info=”{}”][\/et_pb_image][\/et_pb_column][\/et_pb_row][et_pb_row _builder_version=”4.17.4″ _module_preset=”default” global_colors_info=”{}”][et_pb_column type=”4_4″ _builder_version=”4.17.4″ _module_preset=”default” global_colors_info=”{}”][et_pb_text _builder_version=”4.17.4″ _module_preset=”default” global_colors_info=”{}”]<\/p>\n
Notwendige Fragestellungen wie: \u201eWarum machen wir Microservice-Architekturen?\u201c, \u201eWas sind die Argumente f\u00fcr deren Einf\u00fchrung?\u201c wurden manchmal nicht gestellt oder beantwortet. Oftmals fu\u00dft die Entscheidung f\u00fcr Microservice-Architekturen auf bunten Marketing-Foliens\u00e4tzen eines\/einer bekannten Architekt:in, die den Trend auf einer Konferenz oder in einem Zeitungsartikel als die L\u00f6sung vieler offensichtlicher Probleme postuliert hat.<\/p>\n
Dieses bedeutet, dass wenn ich die ACID-ad-hoc-Konsistenz verlasse und mich dagegen entscheide, kann ich mit den Mittlen der Eventual Consistency arbeiten. Ist diese Tatsache bewusst? Wir werden es in meinem Vortrag kl\u00e4ren.<\/p>\n
I.) Entdecken<\/p>\n
Wir werden dieses an einem durchg\u00e4ngigen Beispiel in meinem Vortrag entdecken.<\/p>\n\n
\n