Software Architecture Gathering 2024

Software Architecture Gathering 2024

Software Architecture Gathering 2024

We will be there!

Essential for Software Architects!
Get ready! We are proud to announce that we will once again be a sponsor and active participant at the Software Architecture Gathering (SAG) 2024 in Berlin – from November 11-14!

With nearly 40 captivating expert presentations and a host of exciting workshops, you will gain invaluable insights into the secrets of successful software architecture.

ITech Progress won’t just be present at an information stand (Tuesday, November 12 to Wednesday, November 13, 2024); we will also host a workshop on the first day and deliver two engaging expert presentations on the first and second conference days.

Additionally, our Chief Architect Mahbouba Gharbi has once again taken an active role in shaping the event program as a member of the program committee.

Our team will be on-site, ready to connect with like-minded professionals and share the latest trends, challenges, and innovations in the field of software architecture. Whether you’re looking to discuss groundbreaking solutions, network with industry leaders, or simply stop by to say hello – we can’t wait to meet you!

We’re offering an exclusive 20% discount on your SAG 2024 tickets.

Use the promo code ITECHPROGRESS20 when registering for the event. Don’t miss this opportunity to be part of the future of software architecture and profit from a reduced rate!

ITech Progress Jubiläum

ITech Progress Jubiläum

Jahre Jubiläum

𝗜𝗺𝗺𝗲𝗿 𝗮𝗺 𝗣𝘂𝗹𝘀 𝗱𝗲𝗿 𝗜𝗻𝗻𝗼𝘃𝗮𝘁𝗶𝗼𝗻!

Am 07. Juni 2024 haben wir unser 20-jähriges Jubiläum auf unvergessliche Weise gefeiert. Diese besondere Feier war nicht nur ein Rückblick auf unsere Errungenschaften, sondern auch ein Fest der Gemeinschaft, des Feierns und der Inspiration.
Während dieser Feier wurden wir nicht nur von spektakulären Shows beeindruckt, sondern auch von der Vielfalt und Kreativität, die unser Team auszeichnet. Ein Zauberer faszinierte uns mit seinen Künsten, die Lichtkünstler entführten uns in eine Welt magischer Farben und Formen, und die Feuerkünstler entfachten die Leidenschaft und den Ehrgeiz in unseren Herzen.
Diese Auftritte waren mehr als nur Unterhaltung – sie waren Symbole für Kreativität, Innovation und die unbegrenzten Möglichkeiten, die entstehen, wenn Talent und Leidenschaft aufeinandertreffen. Sie spiegelten die Essenz unseres Unternehmens wider – vielseitig, dynamisch und stets bereit, Grenzen zu überschreiten.
Doch das wahre Highlight unserer Feier waren nicht die spektakulären Shows, sondern die Menschen, die sie erlebt haben. Jeder hat durch seine Anwesenheit, sein Engagement und seine Einzigartigkeit dieses Jubiläum zu einem unvergesslichen Erlebnis gemacht. Gemeinsam haben wir gelacht, getanzt und uns inspirieren lassen – und genau das macht uns zu dem Team, das wir sind.

Wir danken jedem Einzelnen für die Teilnahme, die Beiträge und die unermüdliche Leidenschaft, die unser 20. Jubiläum zu einem unvergesslichen Ereignis gemacht hat. Die Begeisterung ist der Antrieb, unser Bestes zu geben, aufregende Wege zu gehen und gemeinsam Großartiges zu erreichen.
Während wir auf die Feierlichkeiten zurückblicken, erinnern wir uns nicht nur an die Showeinlagen, sondern vor allem an die Momente des Miteinanders, der Freude und der Verbundenheit. Diese Erinnerungen werden uns immer begleiten und uns dazu inspirieren, auch in Zukunft gemeinsam nach den Sternen zu greifen.
Auf die nächsten 20 Jahre – möge unser Weg weiterhin magisch, inspirierend und erfolgreich sein!

OOP 2024 – wir sind dabei!

OOP 2024 – wir sind dabei!

OOP digital 2024 – wir sind dabei!

H. Tiemeyer präsentiert die Kernkompetenzen der ITech Progress GmbH

Es ist gut, unseren Geist gegen den von anderen zu reiben und zu polieren.

Michel Eyquem de Montaigne

Wir blicken auf eine Woche voller interessanter und bereichernder Gespräche bei der OOP in München zurück!

Holger Tiemeyer steht während seinem Vortrag auf der Bühne. Hinter ihm ist die Präsentation auf einer Leinwand zu sehen.
H. Tiemeyer präsentiert die Kernkompetenzen der ITech Progress GmbH
Was ist die OOP? SOFTWARE MEETS BUSINESS – eine führende Fachkonferenz für Softwarearchitekten mit angeschlossener Messefläche die immer Januar in München stattfindet. Immer? Dies war das erste Jahr nach der Pandemie in dem die Messe wieder zu gewohnter Zeit stattfand. Sie ist der ideale Ort, um auf dem Laufenden zu bleiben, Inspiration zu sammeln und wertvolle Kontakte zu knüpfen.
Neben neuen Kontakten haben wir uns aber auch insbesondere gefreut, alte Bekannte widerzutreffen – es ist einfach ein grandioser Event des Austausches!
Ein besonderes Highlight am Stand war natürlich das Gewinnspiel für eine iSAQB-lizensierte Schulung!
Holger Tiemeyer steht während seinem Vortrag auf der Bühne. Hinter ihm ist die Präsentation auf einer Leinwand zu sehen.

Wir freuen uns jetzt schon auf nächstes Jahr!

Kontrollverlust in Softwaresystemen?

Kontrollverlust in Softwaresystemen?

Kontrollverlust in Softwaresystemen?

Strukturen zur Beherrschung der neuen Unübersichtlichkeit und die Unendlichkeit von Software
DevSecOps

Im Rahmen des Java Forums in Stuttgart am 07.07.2022 hält Holger Tiemeyer einen spannenden Vortrag, welcher sich mit dem Thema „Kontrollverlust in Softwaresystemen?“ befasst.

Im Vorfeld konnten wir mit Holger über seinen Vortrag sprechen und erfahren wichtige Fragestellungen und Ansatzpunkte zu dieser Problematik.

Als studierter Informatiker mit Nebenfach Psychologie verbindet Holger Tiemeyer in seinen Fachvorträgen und Veröffentlichungen aktuelle Themen mit weitergehenden, aus der Psychologie her- oder ableitbaren Aspekten.

Holger Tiemeyer

Wenn du von einem „Kontrollverlust in Softwaresystemen“ sprichst, was können wir hier erwarten?

Holger: Als Berater habe ich in der jüngsten Vergangenheit einige bemerkenswerte Ausprägungen mitbekommen: Der Hype nach der Umsetzung von Microservice-Architekturen setzte sich ungebremst in den Unternehmen durch – und das zu großen Teilen, ohne diesen Trend wirklich zu reflektieren.
Notwendige Fragestellungen wie: „Warum machen wir Microservice-Architekturen?“, „Was sind die Argumente für deren Einführung?“ wurden manchmal nicht gestellt oder beantwortet. Oftmals fußt die Entscheidung für Microservice-Architekturen auf bunten Marketing-Foliensätzen eines/einer bekannten Architekt:in, die den Trend auf einer Konferenz oder in einem Zeitungsartikel als die Lösung vieler offensichtlicher Probleme postuliert hat.

Mit dieser Herangehensweise an die Umsetzung von Microservice-Architekturen nehmen wir etwas in Kauf: Eine verborgene Komplexität, denn wir wissen zu Teilen gar nicht, was sich dahinter tatsächlich verbirgt. Und hierin besteht eine ungemeine Gefahr des Scheiterns eines solchen Vorhabens, denn die explizite Inkaufnahme von etwas Verborgenem äußert 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ällt u.a. eine Aussage wie: „das wird nicht funktionieren“ oder „das ist nicht umsetzbar“. In der Konsequenz nimmt die eigene Unzufriedenheit oder diejenige von Kunden oder Auftraggebern zu. Der daraus resultierende Aktionismus führt 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.

Es kann potenziell eine Unübersichtlichkeit oder auch ein Chaos, das nicht mehr beherrschbar erscheint – oder schlimmstenfalls sogar ist -, entstehen.

Nehmen wir dieses Chaos also als etwas schicksalhaftes an? Oder möchten wir lieber die Komplexitäten – die aus der Wahl eines geeigneten Architekturstils resultieren – aktiv angehen und beherrschbar halten und die Kontrolle über das Vorgehen der Umsetzung von Softwaresystemen behalten? Was bedeutet dann ein geeigneter Architekturstil?

Und genau diesen Fragestellungen sehe ich mich sowohl in meinen Projekten als auch in meinen Trainings zu flexiblen Architekturmodellen und Cloudinfra gegenübergestellt. Die Teilnehmer:innen dieser Schulungen bitten häufig um Hilfestellungen aus genau den gerade erwähnten Aspekten heraus. Die Lösungsräume erarbeiten wir dann gemeinsam.

Du sprichst Unbewusstes, Komplexität und Chaos an, die wir in der digitalen Welt beherrschen wollen, was ist hier Dein Postulat?

Holger: 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ängnis einer höheren Macht, die das Leben bestimmt und lenkt, angesehen werden. Es wird somit hingenommen und akzeptiert.

Bezogen auf unsere Softwaresysteme und -architekturen wäre die Frage: Gibt es evtl. Themen, die wir in einer Entscheidungsfindung nicht sehen, die sozusagen im Verborgenen, Unbewussten liegen?

Eine Entscheidung für oder gegen eine Realisierung/Umsetzung oder einen Architekturstil würde evtl. ganz anders gefällt werden, wenn wir uns gewisse Aspekte bewusst machen.

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.

Es geht daher nicht um das Beherrschen des Unbewussten oder der Komplexität, sondern um das Bewusstwerden darüber – über blinde Flecken und Bereiche, die uns in der Entscheidung massiv beeinflussen und die Komplexität reduzieren können – resultierend aus den Ergebnissen, die uns das CAP-Theorem liefert.

Wo hilft uns hierbei das CAP-Theorem genau?

Holger: Das CAP-Theorem liefert uns eine wesentliche Erkenntnis, die uns in der Entscheidungsfindung für gewisse Eigenschaften in verteilten Systemen, ermöglicht: Wir müssen uns für zwei der drei Eigenschaften: Konsistenz, Verfügbarkeit und Partitionstoleranz, entscheiden.

Diese Entscheidung hat einen fundamentalen Einfluss auf die Ausgestaltung und weitergehenden Möglichkeiten eines Systems. Benötigen wir beispielsweise eine ad-hoc-Konsistenz unserer zugrundeliegenden Daten, die den ACID-Prinzipien unterliegt oder nicht?

Wenn ich nun von „oder nicht“ spreche, ist dann schon jedem klar, wovon ich in der Alternative spreche? Dieses ist ein schönes Beispiel für das Bewusstmachen des Unbewussten. Was verbirgt sich denn hinter der Alternative zu ACID?

Wir sprechen von BASE (Base vs. Säure – scherzhaft). Dabei steht BASE für Basically available, soft-state und Eventual Consistency.
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ären.

Du sprichst von einer Komplexitätsreduktion durch das Bewusstmachen blinder Flecken. Könntest du dieses noch etwas genauer darlegen?

Holger: Ein zentrales Thema in der Architekturarbeit – insbesondere in Microservice-basierten Systemen – ist die Verteilung von Verantwortlichkeiten (Separation of Concerns).

Wo liegen denn meine Verantwortlichkeiten – fachliche und technische? In einem Service oder über mehrere Services verteilt? Kann ich die Verantwortlichkeiten trennen – und wenn ja, dann wie?

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ärt werden. Wir müssen diese blinden Flecken aufdecken.

Ein moderner Trend ist es mit weitergehenden Aspekten zu arbeiten: Sidecars und daraus resultierend die Service-Meshes bieten uns ein enormes Potential bestimmte Komplexitäten und Verantwortlichkeiten in die Infrastruktur auszulagern. Auch hier kommt wieder die Frage nach dem Bewusstsein über diese Möglichkeiten zum Tragen. Ich hoffe dieses in meinem Vortrag aufzuklären.

Wie kann man dies erlernen?

Holger: Die Psychologie beschäftigt sich mit der Fragestellung der Problemlösung. Ein Problem wird dadurch gekennzeichnet, dass ich von einem Ausgangszustand in einen Zielzustand übergehen möchte, wobei zwischen diesen beiden Zuständen eine Barriere existiert, die es zu überwinden gilt.

Die Problemlösung besteht nun darin sog. Operatoren zu finden, mit deren Hilfe ich diese Barriere überwinden kann.

Der Erwerb dieser Operatoren erfolgt aufgrund von drei Arten:
I.) Entdecken

II.) Instruktion und

III.) Beobachtungslernen.

Aus diesen Möglichkeiten des Erwerbs müssen die Operatoren extrahiert werden und dieses passiert anhand der Analogiebildung. Dieses Konzept geht schon auf Platon zurück und ist essenziell. Wir erlernen die Themen anhand von Analogien.

Die Frage ist nun, wie uns dieser Prozess der Analogiebildung dabei helfen kann unbewusste Teile aufzudecken, um fundierte Entscheidungen für unsere Systemarchitekturen zu treffen, die uns die Kontrolle über diverse Ausprägungen ermöglichen?

Unendlichkeit der Software, wie definierst Du das?

Holger: Gegenfrage: Wodurch ist der Rahmen eines Softwaresystems definiert? Wo liegt seine Grenze? Wir klären dieses in Rahmen des Vortrags.

Wie können wir all diese Themen bei der Software Architektur einbringen?

Holger: Die ISO-25010-Norm definiert Qualitätsmerkmale für Software. Diesen Qualitätsmerkmalen werden Qualitätsszenarien, die aus den Qualitätsanforderungen abgeleitet werden, zugeordnet und priorisiert.

Wichtig ist nun, dass jedes System in seinen Lösungsszenarien und -strategien in Bezug auf die in der Norm definierten Qualitätsmerkmalen optimiert werden kann.

Hier fängt unser Entscheidungsprozess als Softwarearchitekt an. Unter Einbezug der Erkenntnisse aus dem CAP-Theorem sowie der Aufklärung blinder Flecken in Bezug auf die Infrastruktur (oder auch Makroarchitektur) können unsere zu realisierenden Systeme exakt auf die umzusetzenden funktionalen sowie qualitativen Merkmalen optimiert und angepasst werden.
Wir werden dieses an einem durchgängigen Beispiel in meinem Vortrag entdecken.

Danke für die Einführung! Wir sind gespannt auf deinen Vortrag, und die Antworten und Empfehlungen, wie man die Kontrolle in der Software Architektur behält.

 

Wir freuen uns auf viele interessante Gespräche an unserem Ausstellungsstand im Foyer des Java Forums Stuttgart!

Die Hochschule Worms setzt bei der Suche nach neuen Impulsen auf die Expertise der ITech Progress GmbH

Die Hochschule Worms setzt bei der Suche nach neuen Impulsen auf die Expertise der ITech Progress GmbH

Geschäftsführerin Frau Mahbouba Gharbi als Wirtschaftsvertreterin in den Beirat des Fachbereichs Informatik berufen

 

Die international angesehene Hochschule Worms mit ihren über 3 700 Studierenden sowie 80 Partnerhochschulen in mehr als 50 Ländern dieser Welt hat die diplomierte Ingenieurin und Software-architektin Frau Mahbouba Gharbi in das Beratungsgremium für die Studiengänge Angewandte Informatik und Mobile Computing berufen. Mahbouba Gharbi doziert regelmäßig an internationalen Hochschulen und hält zudem Vorträge auf renommierten Fachmessen.
Das Kerngeschäft ihres im Jahr 2004 gegründeten IT-Beratungsunternehmens ITech Progress GmbH liegt in der Beratung von namhaften Unternehmen aus den Bereichen des öffentlichen Dienstes, des Bankenwesens und der IT-Dienstleistung. Mit über 40 Mitarbeitern an den Standorten in Ludwigshafen am Rhein, Eschborn und Nürnberg bildet eine hauseigene Academy für Trainings und Workshops rund um das Thema Softwarearchitektur die perfekte Grundlage zur Wissensvermittlung.
Die Geschäftsführerin der ITech Progress GmbH wurde deswegen schon in der Vergangenheit zum Wissensaustausch nach Worms eingeladen. Somit lag es nahe, dass der Beirat auf der Suche nach einer erfolgreichen Wirtschaftsvertreterin sich an die Vorstandsvorsitzende des „International Software Architecture Qualification Board“ (Zusammenschluss von Fachexperten mit dem Ziel, die fachliche und inhaltliche Qualität von Lehre, Aus- und Weiterbildung für Softwarearchitektur sicherzustellen) wendet.
Mit der Berufung in das Beratungsgremium liegen die zukünftigen Aufgaben in der Weiterentwicklung des Fachbereiches und der Lehr- und Forschungsprogramme. „Insbesondere zur inhaltlichen Gestaltung der Lehrprogramme entsprechend den Erfordernissen der Arbeitswelt sowie der Attraktivität eines modernen Studienangebotes, ist die Expertise von Frau Gharbi sehr gefragt“, so Prof. Dr. Herbert Thielen (Prodekan des Fachbereichs Informatik, Hochschule Worms).

Anpassungsfähigkeit bei Softwarearchitekten

Anpassungsfähigkeit bei Softwarearchitekten

Axel Feix spricht im Interview darüber, was Anpassungsfähigkeit für ihn als Softwarearchitekten bedeutet, warum sie für den Projekterfolg so wichtig ist und welcher Druck damit auch verbunden sein kann.

Axel Feix hat langjährige Projekterfahrung als Analyst und Softwarearchitekt. Er unterstützt Kunden als Senior Consultant und Trainer bei der Einführung und Umsetzung von Software-Engineering, Requirements-Engineering, Softwarearchitektur-Management und Architekturdokumentation. Er interessiert sich für was fliegt, alles was man visualisieren und spielen kann, und was die Welt zusammenhält.

Was bedeutet es für dich als Softwarearchitekt anpassungsfähig zu sein?

Feix: Nachdem die Definitionsphase im Projekt abgeschlossen ist und feststeht, wie die Softwarearchitektur grundsätzlich aussehen soll, sind die Leitplanken für den Softwarearchitekten vorgegeben. Wenn die Entscheidung auf eine Web-Anwendung gefallen ist, dann wird daraus keine Embedded-Anwendung mehr. Die Softwarearchitektur muss in dem festgelegten Rahmen aber trotzdem verhandelbar bleiben, ohne dabei den Blick auf das Endprodukt zu verlieren. Welches Framework wird in welcher Version verwendet? Welche API wird eingesetzt? Das sind Fragen, über die noch diskutiert werden kann und muss.

Als Softwarearchitekt finde ich es wichtig, mir darüber im Klaren zu sein, dass ich nicht die Weisheit mit Löffeln gefressen habe. Lösungen werden nicht nur fachlich, sondern auch technisch im Team entschieden und das heißt, sich auf gute Argumente einzulassen und aufgeschlossen zu sein. Wenn ein Entwickler oder eine Entwicklerin etwas Cleveres auf die Beine gestellt hat, dann sollte das innerhalb der Leitplanken auch umgesetzt werden. Nur so entsteht am Ende eine gute und vor allem langlebige Softwarearchitektur.

Warum ist die Anpassungsfähigkeit für einen Softwarearchitekten so wichtig?

Feix: Anpassungsfähigkeit für mich als Softwarearchitekt ist wichtig, weil heutzutage alles agil entwickelt wird. Dabei kommt es immer wieder vor, dass Dinge wichtig werden, an die anfangs nicht gedacht wurde oder die keinen hohen Stellenwert hatten. Da denke ich zum Beispiel an die neuen Anforderungen, die es seit der Pandemie in Bezug auf Behörden gibt. Diverse Angelegenheiten, die Bürgerinnen und Bürger immer vor Ort geregelt haben, müssen jetzt auch auf den mobilen Endgeräten funktionieren.

Der technische Wandel ist schnell. Es heißt, etwa alle zwei Jahre werden die alten Technologien durch neue Technologien ersetzt und das Know-how bedarf einer Auffrischung. Wer sich bemüht, immer vorne auf der Buchwelle mitzuschwimmen, um auf dem neuesten Stand zu bleiben, der kann auch anpassungsfähig auf den technischen Wandel reagieren. Neu ist aber nicht immer besser. Anhand von Erfahrungswerten sollte kritisch hinterfragt werden, ob und wie neue Technologien zum eigenen Vorhaben passen und wie sie gewinnbringend eingesetzt werden können. Was heute gehypt wird, kann in wenigen Jahren schon wieder von der Bildfläche verschwinden.

Deshalb müssen Softwaresysteme von Anfang an anpassungsfähig gebaut werden, aber auch als Softwarearchitekt sollte ich mich auf neue Entwicklungen einlassen. Anpassungsfähigkeit ist ein lebenslanger Lernprozess.

In welchen Phasen des Projekts oder in welchen Situationen braucht ein Softwarearchitekt besonders viel Anpassungsfähigkeit?

Feix: Als Softwarearchitekt brauche ich zu Beginn des Projekts besonders viel Anpassungsfähigkeit, bis die Softwarearchitektur durch das Board genehmigt ist. Im Board gibt es viele Stakeholder und alle Interessen sollten angemessen berücksichtigt oder wegdiskutiert werden. Wenn die Softwarearchitektur dann auf die Projektwirklichkeit trifft und das umgesetzt werden soll, was konzipiert wurde, dann müssen die nicht-funktionalen Anforderungen wie Barrierefreiheit, Skalierbarkeit und IT-Sicherheit bedacht werden. Dazu sind eine Reihe von Workshops notwendig, um die Entwicklungsteams auf ihre Aufgaben vorzubereiten und für die Herausforderungen zu sensibilisieren. Gute Ideen vonseiten des Teams sollten in die Detaillierung der Softwarearchitektur einfließen und in der Architekturdokumentation dokumentiert werden. Außerdem kann es Überraschungen organisatorischer Art geben, weil ein Framework oder eine API nicht mehr verfügbar ist, auf die man gesetzt hat. Oder Vertragspartner wurden gewechselt, sodass mit neuen Datenbanken und Produkten gearbeitet werden muss.

Wann herrscht ein ‚zu viel‘ an Anpassungsfähigkeit und wie lässt sich dieses Problem in der Praxis vermeiden?

Feix: Ein „zu viel“ an Anpassungsfähigkeit in der Softwarearchitektur herrscht dann, wenn es keine klaren Strukturen und Verantwortlichkeiten mehr gibt. Wenn es mehrere APIs gibt, die das Gleiche tun, nur an anderen Stellen in der Softwarearchitektur. Das verschlammt die ganze Struktur. Bei Problemen sollte der Softwarearchitekt meiner Meinung nach immer auf das Team zurückgreifen. Er ist bestenfalls Teil eines Querschnittteams oder einer Community of Practice (COP) mit den wichtigsten Vertretern aus Entwicklung, UX-Design, Test und so weiter. Insbesondere die Lead Entwickler spielen eine wichtige Rolle. Die Softwarearchitektur sollte vorgestellt werden, sodass das Team Feedback geben kann und Kompromisse gefunden werden, die die Entwickler und den Architekten zufriedenstellen. Dabei kann dann auch mal klassisch über Optionen abgestimmt werden. Auch hier ist wichtig: Immer im Rahmen der Leitplanken und das vereinbarte Endprodukt nicht vergessen!

Ich finde es generell wichtig, dass man sich auf eine gemeinsame Softwarearchitektur einschwört und das Architekturmanagement im Team am Leben erhält. Wenn dann mal neue Leute dazukommen, lassen sich schnell mithilfe des Teams und der Architekturdokumentation alle auf den gleichen Wissensstand bringen. So gibt es nicht nur einen gemeinsamen Code, sondern auch eine gemeinsame Softwarearchitektur. Wenn ich als Entwicklungsteam an der Entstehung und der Entwicklung von etwas beteiligt bin, kann ich mich auch besser daranhalten.

Die Welt verändert sich immer schneller. Verspüren Softwarearchitekten einen Druck anpassungsfähig zu sein und wenn ja, ist dieser über die letzten Jahre gewachsen?

Feix: Ich glaube, dass der Druck gewachsen ist, weil das IT-Management gerne sagt, dass Softwarearchitekten nur im ersten Teil eines Projekts notwendig sind. Wenn die Softwarearchitektur erst mal steht, haben sie nichts mehr zu tun, aber das stimmt natürlich nicht. Bis das Projekt live geht, gibt es ständig neue Anpassungen, die Prüfungsbedarf haben. Neben Frameworks, die evaluiert und Architekturentscheidungen, die getroffen werden müssen, achtet der Softwarearchitekt im Sprint darauf, dass nicht nur fachliche, sondern auch technische Anforderungen umgesetzt werden. Gerade das Refactoring ist wichtig, damit eine Softwarearchitektur klar bleibt und nicht versumpft. Mit jedem Sprint lagert sich ein kleines bisschen Bodensatz an, der aus neuen Anforderungen und neuen Funktionalitäten besteht. Der Softwarearchitekt schöpft diesen Bodensatz ab, damit neue Anforderungen umgesetzt werden können. Neue Anforderungen vom Fachteam müssen zusammen mit dem PO und dem Entwicklungsteam natürlich auch auf Umsetzbarkeit und notwendige Änderungen an der Architektur geprüft werden.

Bei all diesen Aufgaben ist es von großem Vorteil, als Softwarearchitekt anpassungsfähig zu sein, um verschiedene Rollen einnehmen zu können. Für das Team ist es beispielsweise wichtig, den Softwarearchitekten als starken Fürsprecher zu haben, wenn es um technische Schulden geht und der dann auch vor der Projektleitung dafür eintritt, die Softwarearchitektur sauber zu halten.

 

Vielen Dank an Axel Feix für dieses Interview.

 

Was sagen Sie zum Thema Anpassungsfähigkeit bei Softwarearchitekt:innen?

Wie würden Sie auf die Fragen antworten? Wir freuen uns auf den Austausch in den Kommentaren!