HT: Agile Software Architekturen

In dieser Folge reden wir mit Daniel Sack, einem Experten für Software Architektur von unserer Parterfirma TechTalk, über die Rolle der Softwarearchitektur in Zeiten der agilen Softwareentwicklung. Daniel erzählt über seinen Alltag als Software Architekt, sowie Herausforderungen und Trends im Softwarearchitekur-Bereich. Im Studium widmen wir uns diesem Thema insbesondere im ersten Semester unseres Masterstudiums in der gleichnamigen Lehrveranstaltung. 

Transcript

Copy Transcript Copied

00:00:05
 Intro Speaker: Wissenswertes und Wissen, News aus den Studiengängen der Technik an der FH Campus Wien.

00:00:23
 Sigrid Schefer-Wenzl: Eine Softwarearchitektur existiert in jedem Software Projekt geplant oder ungeplant. In einem Wasserfall artigen Projekt wird die Softwarearchitektur in eigenen Dokumenten im Voraus spezifiziert. In agilen Projekten ist das so nicht möglich, da die Softwarearchitektur laufend angepasst und weiterentwickelt wird.

00:00:43
 Igor Miladinovic: In dieser Folge reden wir mit Daniel Sack, einem Experten für Softwarearchitektur von unserer Partner Firma TechTalk über die Rolle der Softwarearchitektur in Zeiten der agilen Softwareentwicklung. Daniel erzählt über seinen Alltag als Softwarearchitekt sowie Herausforderungen und Trends im Softwarearchitektur Bereich. Im Studium widmen wir uns diesem Thema insbesondere im ersten Semester unseres Masters Studiums in der gleichnamigen Lehrveranstaltung.

00:01:19
 Igor Miladinovic: Die Entwicklung der Informatik und digitalen Kommunikation war nie so schnell wie heute

00:01:25
 Sigrid Schefer-Wenzl: und sie wird nie so langsam sein wie heute.

00:01:31
 Igor Miladinovic: In diesen Podcast stellen wir wichtige Themen rund um unsere Informatik Studiengänge der FH Campus Wien vor,

00:01:39
 Sigrid Schefer-Wenzl: die Sie optimal für diese Entwicklung vorbereiten werden.

00:01:46
 Igor Miladinovic: Willkommen zu dieser Folge von unserem Podcast 10 nach 10. Mein Name ist Igor Miladinovic und ich bin der Studiengangsleiter von den Studiengängen Computer Science and Digital Communications und Software Design and Engineering.

00:01:59
 Sigrid Schefer-Wenzl: Willkommen auch von meiner Seite. Mein Name ist Sigrid Schefer-Wenzl und ich unterrichte in diesen beiden Studiengängen.

00:02:07
 Igor Miladinovic: Heute reden wir über Softwarearchitektur In Zeiten der agilen Softwareentwicklung und wir haben als Gast Daniel Sack, er ist seit mehreren Jahren Softwarearchitekt bei der Frima TechTalk. Es ist eine Firma, die sehr stark auf die agile Softwareentwicklung setzt. Wir haben deine perfekte Kombination zwischen Software, Architektur und Agilität. Und am Anfang würde ich Daniel bitten, dass er sich kurz vorstellt.

00:02:32
 Daniel Sack: Hallo, mein Name ist Daniel Sack, 36 Jahre alt. Meine aktuelle Rolle ist Softwarearchitekt in der Firma TechTalk. Ich nehme auch sehr oft eine Rolle als Developer Coach oder Mentor ein. Ich sehe Softwareentwicklung als eines meiner Hobbies. Ich habe eine Passion für Softwareentwicklung und mit dem, was darin verbunden ist und damit glaube ich, passt das auch ganz gut zu meiner Rolle als Softwarearchitekten. Ich beschreibe mich immer so von der Pike, von der Codierung bis hin zu den höherwertig Themen, das ich so die ganze Bandbreite versuche immer abzudecken und das begleitet mich einen ganzen Tag in meiner Arbeit.

00:03:12
 Sigrid Schefer-Wenzl: Zunächst werde ich dich mal bitten, könntest du uns erklären, was versteht man denn unter dem Begriff Softwarearchitektur oder was würdest du darunter verstehen?

00:03:23
 Daniel Sack: Unter Software Architektur verstehe ich heute alles, was notwendig ist, um Software Projekte erfolgreich umzusetzen. Ob das jetzt die Softwareentwicklung selbst ist. Ob das Teile der Anforderungsanalyse sind, Ausarbeiten von technischen Konzeptionen, aber auch Business Value zu verstehen bei den Kunden und auch wirklich einen gutes Gefühl für Leadership Themen und auch Organisations Themen, die voranzutreiben ist mehr als nur Technik. Und ich sehe das als eine Notwendigkeit um in der Software Architektur auch diese ganze Bandbreite abzudecken.

00:04:01
 Igor Miladinovic: Vielen Dank! Ich habe auch kurz drüber geredet, wie du zu dieser Rolle gekommen bist, aber vielleicht kannst du jetzt auch für unsere Hörerinnen und Hörer sagen Wie bist du zu diesem Beruf gekommen?

00:04:13
 Daniel Sack: Also ich habe 2007 bei der TechTalk als Praktikant während meines Studiums angefangen und hab da meine ersten Erfahrungen mit Software Architektur gehabt. Ich hatte die Möglichkeit in ein sehr großes Projekt mit einzusteigen in sehr komplexes Projekt. Es war damals schon sehr viele Teams, verteilte Teams beteiligt. Es waren die Teams in Europa verteilt. Wir hatten fünf Nationalitäten und da war es besonders wichtig in der Konzeption das auch alle diese Teams koordiniert an einer selben Versionen der selben Technik zu arbeiten. Und das sind so Themen wie Anforderungen und Skalierung sehr wichtig gewesen in der Softwareentwicklung. Es waren so Themen wie Features vs. Zeit in der Umsetzung. Es waren sehr hoe Qualitätsanforderungen notwendig. Ein wichtiger Aspekt in dem Projekt war auch die zukünftige Erweiterbarkeit, weil es quasi eine Basis Software war die zukünftig sehr stark weiterentwickelt worden ist und jetzt immer noch weiterentwickelt wird. Und vor allem auch weil es eine lange läuffähige Software ist, ist auch das Wartungs Thema sehr präsent gewesen. Mit diesen ersten Erfahrungen in meinen jungen Jahren habe ich dann beschlossen das Thema interessiert mich und habe mich persönlich weiterentwickelt und habe aufgrund meiner langen Zeit jetzt bei der TechTalk die Möglichkeit und auch die Unterstützung gehabt durch meine Kollegen und auch durch die Organisation mich in dem Bereich weiterzuentwickeln, aus Fehlern der Vergangenheit zu lernen und das auch als Opportunities verwenden zu können, neue Themen zu lernen. Und das hat mich dazu gebracht, dass ich heute versuch, diese Erfahrungen und dieses ist Mindset, halt meine Rolle als Softwarearchitekt nicht nur meinen Kollegen mitzugeben, sondern auch an unsere Kunden der Technik weiterzugeben. Und so bin ich in diese Rolle des Softwarearchitekten hineingewachsen. Einfach über diese vielen Jahre und über die vielen Projekte sind die vielen Kunden, wo ich die Möglichkeit hatte mich mich da hinein zu entwickeln auch.

00:06:12
 Sigrid Schefer-Wenzl: Kannst du uns vielleicht erzählen, wie so ein typischer Arbeitstag als Softwarearchitekt bei dir aussieht?

00:06:20
 Daniel Sack: Also jetzt in der Corona Zeit muss ich sagen, ein wesentlicher Bestandteil ist sicher die Kommunikation, also die Kommunikation mit Teams. Also ich arbeite grad mit einer 5 bis 6 köpfigen Team zusammen. Kommunikation mit den Stakeholdern, mit unseren Kunden, da vor allem auch zu übersetzen zwischen den involvierten Parteien. Auch das Verstehen der Kundenwünsche und das Übertragen dieser Kundenwünsche und Anforderungen von Stakeholdern, in auch eine Sprache, die sowohl Techniker verstehen. Es ist sicherlich jetzt ein sehr starker Bestandteil, der in der Corona Zeit massiv zugenommen hat. Durch diese asynchrone Kommunikation mit den digitalen Medien Teams zusammen, alle diese Werkzeuge, die uns das Leben jetzt erleichtern. Was ich aber trotzdem weiter in meiner täglichen Arbeit versucht beizubehalten ist, mit den Entwicklungsteam gemeinsam auch wirklich Code zu schreiben, gemeinsam gewisse technische Konzepte zu entwickeln und auch gewisse Architektur Themen in die Teams abzugeben und aus den Teams herauswachsen zu lassen, um auch die Teams eine gewisse Autorität zu ermöglichen. Auf der anderen Seite ist, was mich so in meiner täglichen Arbeit sehr beschäftigt sind, dann auch immer wieder strategische Themen, wo wir natürlich auch so Themen haben wie Research von neuen Technologien, Evaluierung von bestehenden technischen Lösungen oder Evaluierung von neuen technischen Lösungen, um zukünftige Opportunities z.B. herausarbeiten zu können. Und auch ein großer Aspekt ist das Thema Unterstützung und Weiterentwicklung der Skalierung von der Organisations Prozessen. Und das sind vor allem Leadership Themen dabei also Entwicklungsteams der gleichen Vision folgen zu lassen, gemeinsam mit Technologien Visionen voran zu treiben, Skalierungstheme und vor allem auch Requirements von diesen Zielen. Genau das is so im Groben, was mich so tagtäglich beschäftigt, also eine große Bandbreite an ganz unterschiedlichen Themen.

00:08:21
 Igor Miladinovic: Und danke für diese Antwort. Jetzt ist eine Softwarearchitektur, das ist natürlich viel mehr als Diagramme, UML Diagramme, die das Ganze beschreiben und Komponenten. Eine Softwarearchitektur kann auch als Enabler eingesetzt werden. Kannst du uns vielleicht sagen, wie kann eine Software Architektur als Enabler eingesetzt werden?

00:08:41
 Daniel Sack: Also ich arbeite heute als Software Architekt nicht nur alleine, sondern ich arbeite in einem Software Architektur und Infrastruktur Team, wo wir die verschiedenen Kompetenzen gebündelt haben und bei uns laufen in diesem Team ganz, ganz viele Informationen zusammen. Ob Sie jetzt Anfragen aus dem Business sind, Anforderungen aus der Organisation selbst, aus dem Management, Anforderungen von den Softwareentwicklern, quasi an die Technologien und Werkzeuge, die wir haben und auch Anforderungen aus der IT aus der Infrastruktur Ebene. Und damit haben wir ganz tolle Möglichkeiten um nicht nur bestehende Probleme und Blocker aus dem Weg zu räumen, sondern auch neue Business Opportunities daraus zu entwickeln, neue Ideen zu schaffen und die neue Visionen zu verpacken und dann eben an Stakeholder und Entwicklern weiterzugeben. Und das ermöglicht ganz verschiedene Aspekte, bestehende Lösungen quasi neu anders zu machen, aber auch bestehende Lösungen einfach zu optimieren und um das Arbeiten effizienter zu gestalten. Und das sind oft sehr strategische Themen, die wir da erkennen können. Und das hat dann wirklich sehr wenig mehr mit klassischen UML Diagrammen zu tun, sondern oftmals auch mit Veränderungen von Business Prozessen oder auch mit strategischen Entscheidungen. Ist das jetzt vielleicht noch eine Software, die wir weiter betreiben und warten wollen? Oder ist es etwas, was wir uns vielleicht als Cloud Service dazu kaufen wollen oder als fertige Produktlösung? Und das setzt vor allem ein sehr gutes Verständnis des Business voraus und auch eine sehr gute Vertrauensbasis in Business, an die Softwarearchitekten, an die Softwarearchitektur. Auch und da ist es besonders wichtig, dass auch das Business des Managements und Stakeholder Software Architektur nicht nur als Notwendigkeit sehen, sondern wirklich als Investment und Opportunity, um eine Organisation weiterzuentwickeln.

00:10:32
 Sigrid Schefer-Wenzl: Vielen Dank. Wir haben jetzt schon seit einigen Jahren eine recht intensive Kooperation in unseren Studiengängen mit der Firma TestTalk und wissen daher, dass eher im Bereich agile Softwareentwicklung, das heißt Softwareentwicklung, die eben möglichst nahe auch am Kunden ist, sehr aktiv seid. Was ist das Besondere, würdest du sagen an Softwarearchitektur im agilen Umfeld?

00:10:56
 Intro Speaker: Ich glaube, das Spannendste im agilen Umfeld: Agilität bedeutet ja, schneller auf Veränderungen reagieren zu können. Wenn wir uns Software Systeme von vor zehn Jahren anschauen und typische Projekte abwickeln von vor zehn oder fünfzehn Jahren. Da kommen noch so klassische Vorgehens, Modelle wie Wasserfall Modelle. Es gibt eine lange Anfangs Analyse, dann wird die Software gebaut und dann kommt die Produktion. In agilen Projekten ist es oftmals so, dass wir im stetigen Wandel unterwegs sind und das setzt doch ganz neue Herausforderungen an Software Systemen, auch an die Softwarearchitekturen, dass diese Systeme diesen Wandel auch mittragen können. Das heißt Agilität kann zu Veränderungen auch in Software Architekturen führen, kann auch bestehende Softwarearchitektur aufbrechen und kann dazu führen, dass Softwarearchitekturen geändert werden müssen und das auch rein technisch unter einen Hut zu bringen und trotzdem kontinuierlich quasi fürs Business neue Funktionalitäten bereitstellen zu können. Das ist eine sehr große Herausforderung und ich sehe da sehr oft die Herausforderung einerseits von der Technik Seite, wo wir uns in unserer Entwicklungskompetenz mit neuen Technologien, mit geänderten Software Architekturen, mit Wartungs und bestehenden Software Systemen beschäftigen müssen, wo wir es ermöglichen müssen, dieses Software Systeme dann auch kontinuierlich und fehlerfrei ausliefern zu können. Aber auch die Anforderungen ans Business, nämlich Veränderungen im Business, heißt natürlich auch, dass wir organisatorische Prozesse verändern können müssen und dass wir auch unsere Benutzer, unsere Software Systeme damit mitnehmen müssen, dass die auch mit diesen Veränderungen, die ja auch schnell abnehmen können und die auch schnell in der Praxis noch leben können, dass auch diese organisatorisch oder diese Business Component ist eine ganz, eine wichtige, dass sich vor allem die Notwendigkeit eines sehr guten Risikomanagements also wenn wir rein aus der Technik z.B. herausgehen, man kennt das, Automatisierung ist das A und O was wir brauchen, um sicher ausrollen zu können, um manuelle Fehlerquellen ausmerzen zu können, um im Fehlerfall auch wiederum schnell reagieren zu können. Man kennt es, diese mean time to repair die möglichst gering zu halten. Auch von der Organisation ist es halt wichtig, auch in eine offene Kommunikation zugehen, dass man auch Investments in die Werkzeuge, die Tooling in seinem Kontext vornehmen kann, dass man Investments auch in die Mitarbeiterin des Mitarbeiter Know how und auch in entsprechende Trainings investiert, weil nur agil arbeiten am Papier hilft nix, wenn das Know How nicht da ist, wenn wenn die Rahmenbedingungen nicht passen. Und es ist wichtig, dass alle Stakeholder quasi diese Vision auch auch mitverfolgen und dasselbe Alignment und das ist auch ein wichtiges Kommunikations Thema, was auch oftmals in diesem Software Architektur Bereich miterlebt und mitgetragen wird,vweil da oftmals Probleme zwischen Organisation und Technik einfach mit kommuniziert werden, mit übersetzt werden und alle in dem Fall alle beteiligten Parteien auch mit abgeholt werden. Und ich sehe vor allem jetzt Software Architektur im agilen Umfeld nicht mehr jetzt als eine Aufgabe eines einzelnen Softwarearchitekten, sondern für mich ist es ganz stark ein Thema, dass das eine Teamaufgabe ist in einer Organisation und da gehören noch so rollen wie Enterprise Architekten, Qualitäts Engineers, Entwickler, Product Owner, also alle Rollen sind wichtig mit beteiligt zu sein, auch um hier eine gemeinsame Architektur, ein gemeinsames Vorgehen zu haben. Das sowohl Organisation und Technik da zusammenpaßt und dieses Element in einem agilen Umfeld, das kontinuierlich zu leben und kontinuierlich up to date zu halten. Das ist, glaube ich, eine der großen Herausforderungen.

00:14:44
 Igor Miladinovic: Und hast du vielleicht ein Beispiel aus der Praxis? Ein Projekt, das schon abgeschlossen ist. Wir brauchen da keine Firmen Geheimnisse besprechen, sondern vielleicht ein Beispiel aus der Praxis von einem Projekt, das schon abgeschlossen ist und wo man diese Softwarearchitektur so schnell in einem agierenden Umfeld anpassen musste.

00:15:03
 Daniel Sack: Naja, ich ich glaube das beste Beispiel, was wir im heutigen Kontext sagen können ist jetzt in der Corona Zeit, wir sind alle remote unterwegs, klassische Prozesse funktionieren oftmals nicht. Ich bin in den letzten Jahren sehr stark im öffentlichen Sektor vertreten. Da gibt's noch sehr, sehr viel klassische Prozesse. Sehr oft Papier getriebene Prozesse. Und wenn man dann Dokumente hat, die man auf dem Papier einen Kugelschreiber unterschreiben muss, die im Homeoffice unterschreibt, an Scans dann über die Email oder sonstige Transport Medien verschicken muss, damit ein Kollege unterschreibt und dann wieder eingescannt werden muss. Und dann irgendwo abgelegt werden muss, irgendwo konvertiert werden müssen, verschickt werden muss. Das skaliert nicht mehr. Das funktioniert nicht mehr. Das sind so typisch Prozesse, die mir dann sehr stark im Kontext der Digitalisierung auch dann und sehr stark automatisieren kann.. Es reicht doch vollständig aus, in seinem Kontext in einem digitalen System quasi so etwas wie eine digitale Unterschrift zu haben. Und da gibt's ganz viele verschiedene Ausprägungen wie ich kann mit einem Tablet unterschreiben. Oder ich kann aufgrund einer Applikationsfunktion eine Freigabe machen in einem Dokument und schicke es im Hintergrund z.B. in eine automatische Konvertierungen und Drucker Strasse um so einen Postversand auszulösen, wo wir dann ganz viel einfach von manuellen Tätigkeiten digitalisiert haben und unsere Benutzer enabled haben, einfach andere Tätigkeiten viel mehr Zeit zu widmen, ist zum Beispiel ein Beispiel jetzt in der Corona zeit, wo wir jetzt relativ viel auch gemacht haben in meinem letzten projekt.

00:16:34
 Sigrid Schefer-Wenzl: Danke schön. In den letzten Jahren ist der Begriff der technischen Schuld englisch technical debt recht populär geworden oder immer wieder thematisiert worden. Kannst du uns vielleicht sagen, was heißt technical debt und welche Strategien kann man einsetzen, um sie zu vermeiden?

00:16:51
 Daniel Sack: Ich erlebe in meinem Kontext Technical Debt immer als eine Abstraktion, als eine Analogie auf viele Themen. Und ich sehe das oft, dass diese Begrifflichkeit für viele, viele Themen verwendet wird und in der Kommunikation oftmals gar nicht klar ist, wenn viele Parteien über Technik gemeinsam miteinander sprechen, was eigentlich genau damit gemeint wird. Ein Beispiel könnte sein: Wird man heute einen Prototypen, ein Experiment, um quasi eine Business Idee zu evaluieren, gehen hier technische Shortcuts ein. Der Code ist vielleicht nicht wartbar, das könnte eine Form von technical debt sein. Das ist ein strategisches Investment, wo wir von strategische Investments reden, um jetzt sehr schnell am Markt reagieren z.B. zu können. Mit der Konsequenz daraus uu einem späteren Zeitpunkt müssen wir in die Technologie vielleicht noch etwas investieren, wenn das Experiment positiv war und wenn sich das gezeigt hat, dass es im Markt gut ankommt oder wir die Entscheidung treffen müssen: das Experiment ist vielleicht fehlgeschlagen. Das ist eine Funktionalität, die wir in unser Softwaresystem eingebaut haben, was wir eigentlich nicht brauchen. Dann sollten wir wieder die Entscheidung treffen: bauen wir es wieder aus, um langfristig einfach uns den Wartungsaufwand auf einem Niveau zu halten, das uns die Wartungs Aufwände nicht über den Kopf wachsen. Was ich auch oft erlebe, das als technical debt sehr oft kommuniziert wird: Wir haben alten Source Code, der passt nicht mehr zu den aktuellen Entwicklungsstandards oder wir haben Software Systeme, die Security Updates nicht eingespielt haben, die eingespielt werden müssen. Was ich in den letzten Jahren gelernt habe ist, wenn wir das Thema technical debt angreifen, wenn das zur Diskussion wird, vielleicht doch nochmal zu hinterfragen, was war denn eigentlich wirklich damit gemeint. Und dann wird es oftmals sehr viel klarer und dann lassen sich oftmals sehr einfach Strategien ableiten, was man jetzt wirklich eigentlich erreichen möchte und was für Möglichkeiten hat, um diese Problemstellungen auch auch abdecken zu können.

00:18:56
 Igor Miladinovic: Vielen Dank! Das heißt, wenn mir jetzt eine Softwareentwicklung, also egal wie entwickelt agil oder nicht agil, in den meisten Fällen ist es heute agil. Das Problem ist aber, dass diese Software in eine Landschaft integriert werden muss, wo auch andere Software dabei ist. Das und veraltete Software, die eben irgendwann entwickelt wurde, sogenannte Legacy Software. Welche Rolle spielt diese Legacy Software in deinem Alltag aus Softwarearchitekt?

00:19:25
 Daniel Sack: In meinem Alltag ist Legacy softe, die Software, die heute in Produktion läuft, die heute Business Value liefert, die heute es uns ermöglicht, überhaupt unsere Arbeit als Softwarearchitekten zu machen und die wir meistens oder typischerweise entweder weiterentwickeln wollen oder erweitern wollen durch andere Software Systeme, um neuen Business Value zu generieren. Das ist so eine Sichtweise, die ich habe auf Legacy Software die Software sie unterstützt die tägliche Arbeit, hieß sie haltet unser Business am Leben. Und dann gibt's noch den anderen Aspekt von Legacy Software. Es ist diese alte Technologie, die man vielleicht nicht mehr warten möchte, wo man vielleicht doch nicht mehr die Mitarbeiter mit dem Know How hat, die man vielleicht ja auch irgendwann einmal ablösen muss technologisch. Und ich glaube, da ist einfach die Schwierigkeit oder die Schwierigkeit. In meinem Alltag ist, es einfach einen guten Mittelweg zu finden. Wie viel Zeit investiert man in neue Software, in Ablöse von alter Software um neuen Business Value zu schaffen? Und wie viel Zeit muss man investieren, um diese Legacy Software auch zu ebablen? Das mit diesen neuen Business Value Schaffen kann. Wenn man jetzt eine alte Legacy Software hat, die keine Schnittstellen anbietet, die vielleicht ein Monolith ist, die mit einer alten Datenbank Technologie arbeitet, da ist bei uns Software Architekten immer wieder die Herausforderung: Was können wir machen, um hier neuere Software Systeme anzuschließen oder vielleicht Teilaspekte herauszulösen? In dem Kontext fallen dann auch immer so, trendig auch in Software,architektur, Konferenzen, das Thema Microservices. Können wir aus bestehenden Landschaften Microservices raus extrahieren? Können wir es bestehenden Software lösen, gewisse Business Capabilities herauslösen, die vielleicht auch modernisieren und weiter nehmen? Und das sind alles so spannende Themen, die uns im Softwarearchitektur Bereich mit Legacy Software halt tagtäglich beschäftigen.

00:21:16
 Sigrid Schefer-Wenzl: Schauen wir jetzt noch einmal ein bisschen in die Zukunft. Was würdest du sagen? Was sind so aktuelle Trends im Architektur Bereich? Du hast schon ein bisschen Microservices genannt. Vielleicht schon wieder ein alter Hut. Was sind so Trends aus deiner Sicht?

00:21:30
 Daniel Sack: Als ich glabe so Trends, die man sieht diese ganze Digitalisierung Bereich der der aus der Prozesssicht aus der Businesssicht getrieben wird und die Automatisierung von ganz vielen Prozessen. Also heute können wir viel, viel mehr mit unseren Technologien automatisieren, weil mit so Technologien wie Cloud, Cloud Architekturen, Microservices oder gut geschnittene Monolithen ermöglichen uns einfach schneller und effizienter gewisse Problemstellungen zu lösen und neue Business Opportunities zu ermöglichen. Ich glaube, wo der Markt auch sehr stark hingeht ist: Wie können wir Softwareentwicklung im aktuellen Jahrzehnt und in den kommenden Jahrzehnten besser skalieren? Wie können wir in einen Modus kommen, dass wir mehr Komponenten zu mehr fertigen Komponenten zusammen kombinieren können? Wie kann man mehr bestehende Systeme integrieren? Wie können wir die Abstraktionsebene von von Softwareentwicklung erhöhen? Es gibt vor allem in Cloud Bereich diese Themen wie Serverless. Und wenn man sich anschaut am Markt man sieht die großen Cloud Vendoren treiben alle auch weiter Konzepte von von No Code Entwicklungen. Also auch, wie solche Werkzeuge in der Zukunft auch mit der klassischen Softwareentwicklung leicht harmonieren können und auch gewartet werden können, das sind glaube ich Trends, die wie jetzt beobachten können. Etwas, was man auch immer mehr sieht: Was auch von den großen Cloud Mentoren immer mehr kommuniziert und sichtbarer wird, ist auch der ökologische Footprint. Also Rechenzentren versuchen, quasi in immer effizienter zu werden. Versuchen Themen wie Abwärme zu nutzen, um z.B. Brauchwasser aufzubereiten, große Cloud Vendoren versuchen auch ihre Software Entwicklungs Toolkits, ihreFrameworks auch zu optimieren auf Rechenzeiten, um auch da den ökologischen Footprint zu reduzieren. Ich glaube, dieses Thema Nachhaltigkeit in der Softwareentwicklung, glaube ich, wird in den nächsten Jahrzehnten wirklich auf uns zukommen. Und da bin ich auch ganz gespannt, was uns da alles erwarten wird und was es da für neue Werkzeuge geben wird.

00:23:44
 Igor Miladinovic: Danke und alle diese Trends natürlich beeinflussen auch die Rolle von Softwarearchitektur. Da würde mich interessieren, wo siehst du die Rolle von Softwarearchitektur in den nächsten fünf bis zehn Jahren?

00:23:57
 Daniel Sack: Also ich glaube, die Rolle der Software Architektur wird eine wichtige Rolle bleiben. Ich glaube, sie wird noch mehr zu einer Team Rolle. Ich glaube, das viele Parteien in Softwarearchitektur involviert sind. Ich glaube, das wird noch stärker werden. Ich glaube, die große Herausforderung wird werden alle diese neuen technischen Möglichkeiten, die in den nächsten fünf bis zehn Jahren kommen, auch mit dem, was wir heute alles an Software bereits da haben, gut kombinieren zu können und zu einer Strategie zu kommen, neue Technologien für neue Opportunities zu verwenden und aber trotzdem an diesem Skalierung Thema zu arbeiten. Wie können wir bestehende Software, die wir haben, trotzdem noch weiter betreiben? Weiter warten? Also wir entwickeln in unserer Industrie immer mehr, immer mehr Software. Es kommen immer mehr Software Systeme raus und irgendwie schaffen wir mehr Software als Kapazität, die bestehende Software zu warten und weiterzuentwickeln. Und ich glaube, dass das wird eine der größten Herausforderungen dieses Problem in den nächsten fünf bis zehn Jahren in unserer Industrie zu meistern. Und ich glaube, da sind wir in der Rolle der Softwarearchitekten in der Industrie sehr stark gefordert, hier auch auch mit Ideen und neuen Konzepten auch hinauszugehen und da auch zu schauen, was können wir als Software Architekten in den Communities auch beizutragen und was können wir quasi auch auch in Entwicklungs Communities und Produkte zurückfließen zu lassen und dieses Problem auch zu lösen. Das wird, glaube ich, eine der größten Herausforderungen auch, die uns, den Softwarearchitekten treffen wird.

00:25:26
 Igor Miladinovic: Vielen Dank, Daniel, in diese tollen Einblicke in die Zuständigkeiten, in die Aufgaben von einem Softwarearchitekten oder von einer Softwarearchitektin. Wir haben auch sehen können, wie wichtig diese Rolle eigentlich ist und wie wichtig diese Rolle bleiben wird. In der nächsten Zeit danke auch an unsere Hörerinnen und Hörer, dass sie heute mit uns waren. Ich wünsche Ihnen noch einen schönen Tag und bis zum nächsten Mal.

00:25:56
 Sigrid Schefer-Wenzl: Bis zum nächsten Mal.