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!

DevSecOps – sichere Softwareentwicklung und Betrieb

DevSecOps – sichere Softwareentwicklung und Betrieb

DevSecOps – sichere Softwareentwicklung und Betrieb

DevSecOps

In einem agilen Umfeld nach DevOps-Ansatz wird kurz vor dem Release festgestellt: jeder und jede darf alles: Zugriffe auf alle Daten sind allen möglich ohne jegliche Einschränkungen und/oder Zugriffskontrolle. Was ist schiefgelaufen?

Die Sicherheit der Anwendung war von Anfang an außer Acht gelassen worden und es wurde keine Zugriffskontrolle bei der Implementierung umgesetzt.

Da kommt die Anwendungssicherheit (Security) ins Spiel: DevSecOps ist ein Kunstwort, welches sich aus den englischen Begriffen für Softwareentwicklung (Development), (Cyber-)Sicherheit (Security) und IT-Betrieb (Operations) zusammensetzt. Es handelt sich um einen Ansatz für Unternehmenskultur, Automatisierung und Plattformdesign, bei dem die Sicherheit eine zentrale Rolle spielt und als gemeinsame Verantwortung im gesamten IT-Lebenszyklus integriert ist. DevSecOps zielt darauf ab, IT-Sicherheitsmaßnahmen direkt in den Prozess der Anwendungsentwicklung zu integrieren.

Vergleich zwischen DevSecOps und DevOps

DevSecOps ist eine Weiterentwicklung des DevOps-Ansatzes und beschreibt einen kulturellen Wandel in der Software-Entwicklung. Ziel ist der Einsatz interdisziplinärer Teams und die konsequente Integration automatisierter Sicherheitsverfahren in alle Phasen des rasanten Entwicklungszyklus – vom Entwurf bis zur Implementierung und Betrieb [2].

Bei DevOps geht es nicht nur um die Entwicklungs- und Operations-Teams. In einem ausgesonderten Blogartikel ist das Thema ‘DevOps’ ausführlich behandelt worden. Wenn Sie die Agilität und Reaktionsfähigkeit des DevOps-Ansatzes vollständig ausschöpfen möchten, muss die IT-Sicherheit ebenfalls in den gesamten Lifecycle der App integriert werden [1].

Warum ist dies wichtig? In der Vergangenheit war die Sicherheit zumeist Aufgabe eines speziellen Teams in der Endphase der Entwicklung. Das war auch kein größeres Problem, als die Entwicklungszyklen noch mehrere Monate oder gar Jahre in Anspruch nahmen. Diese Zeiten sind aber vorbei. Aufgrund beschleunigter Entwicklungsphasen gelten diese Praktiken als veraltet: die vorhandene Zeit vor dem nächsten Release reicht meist nicht aus, um den Code effektiv auf Fehler zu überprüfen. Dies führt dazu, dass die Entwicklung unnötig ausgebremst wird oder dass essenzielle Sicherheitsmaßnahmen übergangen werden, wodurch das Gefahrenrisiko steigt [2].

Als notwendige Antwort auf diese Problematik wurde der unternehmenskulturelle DevSecOps-Ansatz entworfen. DevSecOps stellt die Evolution des DevOps-Gedankens dar und ergänzt die kollaborative Entwicklungsorganisation um das Thema Sicherheit. Dabei werden Security-Maßnahmen direkt in den Entwicklungsablauf integriert und alle Beteiligten tragen gemeinsam die Verantwortung zur Gewährleistung von Sicherheitsstandards. Durch die Berücksichtigung des Sicherheitsaspekts im Entwicklungsprozess selbst werden agile Verfahren nicht eingeschränkt und es besteht durchgängig die Möglichkeit, schnell auf Sicherheitsrisiken zu reagieren [2].

Eine effiziente DevOps-Strategie sorgt für schnelle und häufige Entwicklungszyklen (Wochen oder manchmal gar nur Tage), aber veraltete Sicherheitspraktiken können selbst die effektivsten Prozesse ausbremsen [1].

Beim kollaborativen DevOps-Ansatz von heute aber wird die Sicherheit zur gemeinsamen Verantwortung, die vom Anfang an in dem Ablauf integriert ist [1].

DevSecops

DevSecOps bedeutet, dass die Sicherheit der Anwendungen und der Infrastruktur von Anfang an beachtet werden muss. Es bedeutet ebenfalls, dass einige Sicherheits-Gates automatisiert werden müssen, damit der DevOps-Workflow nicht zu langsam wird. Wenn Sie die richtigen Tools zur kontinuierlichen Integration von Sicherheitsfunktionen verwenden und sich auf eine IDE (Integrated Development Environment) mit Sicherheits-Features einigen, können diese Ziele leichter erreicht werden. Allerdings ist für eine effiziente DevOps-Sicherheit mehr erforderlich als nur ein paar neue Tools. Sie basiert auf den veränderten kulturellen Anforderungen von DevOps, die Arbeiten der Sicherheits-Teams lieber früher als später zu integrieren [1].

Beim DevSecOps-Ansatz müssen Sicherheitsfunktionen von Anfang an integriert sein und dürfen nicht erst später um die Apps und Daten herumgebaut werden. Dies bedeutet auch, dass die Entwickler bereits bei der Programmierung an die Sicherheit denken müssen. Damit dieser Prozess erfolgreich ist, müssen die Sicherheits-Teams transparent arbeiten, einander Feedback geben und einander mitteilen, wenn Bedrohungen vorliegen [1].

DevSecOps muss als Bestandteil des Entwicklungsprozesses betrachtet werden. Ihre Praktiken erfordern Sicherheit als Teil des gesamten Software-Entwicklungszyklus und nicht erst vor der Freigabe der Software für die Produktion. Dies bedeutet, dass Entwickler die Überprüfung auf Sicherheitslücken sowohl in den Build-Prozess als auch in ihre IDE-Umgebung integrieren, um anfällige Abhängigkeiten ausfindig zu machen [5].

DevSecOps-Kultur

Im Rahmen einer DevSecOps-Kultur übernimmt jeder Einzelne die Verantwortung und das Eigentum an der Sicherheit. In Verbindung mit den Best Practices von DevOps sollte jedes Entwickler-Team einen Sicherheitsbeauftragten benennen, der die Prozesse für die Sicherheit und die Einhaltung von Lizenzbestimmungen und diesbezügliche Aktionen im Team leitet, um die Sicherheit der gelieferten Software zu maximieren.

Das Wesen von DevOps besteht darin, so viel wie möglich zu automatisieren, um menschliche Fehler zu vermeiden und automatisierte Gates zu schaffen, die verhindern, dass instabiler Code in die Produktion gelangt. Im Grunde ist Code, der Sicherheitslücken oder nicht eingehaltene Lizenzen beinhaltet, instabil [5].

DevSecOps-Prinzipien

Die Einführung und Umsetzung von DevSecOps in einer Organisation erfordert ein Umdenken in der Unternehmenskultur und im Betriebsablauf. Dies umfasst Tools, Ressourcen und Training bezüglich der Sicherheit. Im Folgenden finden Sie einige nützliche Konzepte für die Veränderung Ihrer Unternehmenskultur [5].

Wie kann die Sicherheit im DevSecOps-Ansatz umgesetzt werden?

Benötigt wird der Einsatz von modernen, innovativen Technologien (z.B. Container, Microservices…), kurze und häufige Entwicklungszyklen, Integration von Sicherheitsmaßnahmen schon bei der Programmierung sowie Begünstigung von enger Zusammenarbeit zwischen den sonst isolierten Teams.

Vor allen technischen Ansätzen kommt aber der menschliche Faktor ins Spiel: alles fängt auf der Personalebene an und mit der Art und Weise der Zusammenarbeit. Das wichtigste technische Instrument ist aber die Automatisierung.

Die Automatisierung umfasst im Großen und Ganzen folgende Aspekte: Quellkontroll-Repositories, Container-Registries, die CI/CD-Pipeline (Continuous Integration/Continuous Deployment), API-Management, die Orchestrierung und Release-Automatisierung sowie die operative Verwaltung und Überwachung [1].

DevOps-Sicherheit wurde für Container und Microservices entwickelt. DevSecOps bedeutet nichts anderes, als dass Sicherheit zum festen Bestandteil der kompletten Entwicklungs-Pipeline (von Anfang bis Ende) wird. Dieser Umstand aber erfordert sowohl eine neue Unternehmensphilosophie als auch neue Tools. Vor diesem Hintergrund sollten DevOps-Teams daher die Sicherheit automatisieren, um die gesamte Umgebung inklusive aller Daten und des CI/CD-Bereitstellungsprozesses zu schützen. Dieses Vorhaben aber betrifft höchstwahrscheinlich auch die Sicherheit von Microservices in Containern [1].

Automatisierung und moderne cloudnative Technologien wie Container und Microservices unterstützen Anwendungsentwickler und erlauben die Aufteilung der Entwicklungsschritte in viele unabhängig voneinander ablaufende Prozesse. Zusätzlich sorgen DevOps-Strategien dafür, dass Entwicklungszyklen beschleunigt werden, wodurch die Zeit zwischen Releases verkürzt wird und neue Anwendungsversionen innerhalb von Wochen oder sogar Tagen verfügbar sind [2].

Merkmale von DevSecOps

  • Anti-Silos: erst wenn alle am Entwicklungsprozess Beteiligten gemeinsam Verantwortung für die Integration von Sicherheitsmaßnahmen übernehmen, können diese durchgängig und so früh wie möglich in die CI/CD-Pipelines eingebunden werden.
  • Shift-Left: dies bedeutet, dass Sicherheitsmaßnahmen früher (also Richtung “links”) in den Entwicklungszyklus eingebunden werden. Dies steht im Kontrast zu traditionellen Praktiken, bei denen QS- und Security-Checks erst am Ende durchgeführt wurden.
  • Automatisierung: Automatisierte Sicherheitstests während des Entwicklungsprozesses dienen dazu, Sicherheitslücken schon vor Implementierung der Software aufzudecken, damit Gefahrenpotenziale leichter ausgeschaltet werden können. Mithilfe automatischer Tests können Sicherheitsmaßnahmen außerdem an den Einsatz cloudnativer Technologien angepasst werden. Konkrete Sicherheitsmaßnahmen können bspw. ein zentrales Identity- und Access-Management, integrierte Security Scans für Container oder die Isolierung von Microservices sein. [2].
  • Cloudnative Technologien: Cloudnative Technologien wie Microservices und Container ermöglichen die Entwicklung von Anwendungen in kleinen, inkrementellen Schritten. Container und Microservices sind mittlerweile fester Bestandteil vieler DevOps- bzw. DevSecOps-Prozesse und müssen bei der Umsetzung von Sicherheitsmaßnahmen beachtet werden. DevSecOps-Maßnahmen können bspw. dafür sorgen, dass Übertragungen zwischen den verschiedenen Services sicher und verschlüsselt ablaufen oder dass integrierte Sicherheitsfunktionen von Container- und Orchestrierungsplattformen in Entwicklungsprozesse eingebunden werden. Zugangskontrollen und Authentifizierungsverfahren zählen ebenfalls zu integralen Aufgabenbereichen von DevSecOps [2].
    DevSecOps Tools

    Heutzutage existieren eine Reihe von Tools, die in unterschiedlichen Phasen der Softwareentwicklung dabei helfen sollen, DevSecOps-Ansatz ganzheitlich umzusetzen [2]:

    Build Phase:

    • Quellcodeanalyse
    • Automatic Security Testing (AST)
    • Web Application Firewall (WAF)

    Test Phase:

    • Static Application Security Testing (SAST), um Sicherheitsfehler im Code zu finden [5]
    • Interactive Application Security Testing (IAST)
    • Web Application Firewall (WAF)

    Run Phase:

    • Web Application Firewall (WAF)
    • Dynamic Application Security Testing (DAST), als Teil eines automatisierten Ablaufs für die Qualitätssicherung [5]
    • Bug Bounty
    • Bedrohungsanalyse
    Vor- und Nachteile

    Vorteile:

    Erfolgt die Software-Entwicklung in kleinen, inkrementellen Schritten, lassen sich Sicherheitsmaßnahmen in jede Entwicklungsphase integrieren und sind stets überprüfbar. Somit wird der Code bis zur Auslieferung der Anwendung kontinuierlich analysiert, getestet und freigegeben. Werden dabei Probleme oder Risiken identifiziert, können diese umgehend behoben werden, wodurch doppelte Überprüfungen und unnötige Neuerstellungen vermieden werden. Moderne Werkzeuge für die Analyse und den Schutz von Anwendungen übernehmen wiederkehrende Sicherheitsaufgaben und entlasten so die Entwicklungsteams, die sich somit auf höherwertige Aufgaben konzentrieren können [2].

    Nachteile:

    Der DevSecOps-Ansatz ist besonders zu Beginn mit großen Herausforderungen verbunden. Soll die Umsetzung gelingen, sind Zeit und konsequentes Handeln erforderlich. Prozesse und Mitarbeiter müssen gleichermaßen auf die neuen Abläufe und Anforderungen vorbereitet werden. Es bedarf eine Bestandsaufnahme bisheriger Sicherheitsmaßnahmen und der Überprüfung, ob diese weiterhin einsetzbar sind. Alternativ muss nach neuen Lösungen Ausschau gehalten werden, in die sich Mitarbeiter dann einarbeiten müssen. Generell müssen sich Entwickler zusätzliche Kompetenzen im Security-Bereich aneignen, um DevSecOps-Maßnahmen umsetzen zu können [2].

    Fazit

    Der Hauptunterschied zwischen DevOps und DevSecOps ist klar: das letzte setzt die Sicherheit in einer Anwendung im Fokus. Wie anfangs im Szenario kurz beschrieben wurde, ist die Sicherheit in der Softwareentwicklung keine Nebensache und sollte im gesamten Entwicklungszyklus berücksichtigt werden. Mit Einsatz von DevSecOps können Entwicklungsteams dafür sorgen, dass Sicherheitsschwächen in der Anwendung früh genug entdeckt und behoben werden können. Außerdem wird die agile Softwareentwicklung dadurch beschleunigt, das Wissen und die Sensibilisierung über die Sicherheit bei allen Teammitgliedern wird verteilt und gestärkt.

    DevOps als Unternehmens-Kultur verändert  die agile Software-Entwicklung

    DevOps als Unternehmens-Kultur verändert die agile Software-Entwicklung

    DevOps als Unternehmenskultur verändert die agile Softwareentwicklung

    Nach einer Entwicklungsphase jeder Software geht die Anwendung im besten Fall in Produktion und wird eingesetzt und betrieben. DevOps ist eine Kombination der Wörter “Development” und “Operations” und vereint zwei organisatorisch voneinander getrennte IT-Bereiche: die Softwareentwicklung (Dev) und den IT-Betrieb (Ops).

    Dadurch kann die Entwicklung hochqualitativer Anwendungen vorangetrieben und einen stabilen, zuverlässigen Betrieb gewährleistet werden.

    Ziel von DevOps

    DevOps ist hauptsächlich eine Unternehmenskultur und zielt darauf, die Bereiche der Entwicklung und des IT-Betriebs in der modernen Softwareentwicklung zusammenzubringen. Alle Prozesse, die die Entwicklung, den Betrieb und die Auslieferung von Software betreffen, müssen gegebenenfalls angepasst werden. Dies wird durch agile Entwicklungsprozesse (Development, Tests) vereinfacht, der Prozess der Softwareauslieferung (Delivery) wird dann mit aufgenommen.

    Durch den DevOps-Ansatz werden Prozesse der Softwareentwicklung und des IT-Betriebs optimiert und automatisiert, damit Software schneller, effizienter und zuverlässiger erstellt, getestet und freigegeben werden kann.

    Warum DevOps

    Moderne Softwareentwicklung setzt immer mehr auf Agilität und ist bemüht, bestehende Systeme ständig zu optimieren.

    Der Betrieb hat hingegen das Ziel, möglichst stabile Software, Infrastrukturen und   Systemlandschafen zu betreuen.        Somit    bleiben     beide     IT- Bereiche     oft isoliert  voneinander und jeweils auf   eigene   Ziele konzentriert. DevOps-Ansatz versucht, beide Bereiche zusammenzubringen,    um sowohl eine  schnelle und effiziente Entwicklung als          auch einen stabilen Betrieb zu   gewährleisten. Somit wird der komplette Lebenszyklus einer Softwarekomponente vom selben Team betreut, frei nach dem Motto:

    You build it, you ship it, you run it”.

    Bei DevOps geht es darum, eine Brücke zwischen traditionell isolierten Entwicklungs- und operationellen Teams zu schaffen. In diesem Modell arbeiten Entwicklungs- und Betriebsteams von der Entwicklung und dem Test über die Bereitstellung bis hin zum Betrieb zusammen.

    DevOps Komponenten

    DevOps gleicht einer “Endlosschleife”, die von der Softwareplanung, über Code-, Build-, Test- und Release-Phasen über die Bereitstellung, den Betrieb, die Überwachung und das Feedback wieder zurück zur Planung zurückführt.

    Eine grundlegende DevOps-Praxis besteht darin, sehr häufige, aber kleine Updates inkrementeller Art durchzuführen.
    Durch DevOps soll sich das komplette Projektteam gegenseitig unterstützen und Wissen und Erfahrungen über alle Teammitglieder geteilt werden. So sollen Wissensmonopole verhindert werden.
    Zu den gängigen und beliebten DevOps-Methoden zählen Scrum, Kanban und Agile.

    DevOps Praktiken
    • Fortlaufende Entwicklung: Planungs- und Codierungsphasen des Lebenszyklus
    • Kontinuierliche Prüfung: durch automatisierte Tests
    • Kontinuierliche Integration: Im Kern von kontinuierlicher Integration steht ein Versionsverwaltungssystem, um den Code zu organisieren, Änderungen zu verfolgen und automatisierte Tests zu ermöglichen.
    • Kontinuierliche Lieferung: Code-Updates sollten so oft wie möglich bereitgestellt werden, um das kontinuierliche Angebot optimal nutzen zu können. Durch die Freigabe von Codes in kleineren Blöcken werden Engpässe vermieden und ein stetiger, kontinuierlicher Integrations-Fluss gewährleistet.
    • Kontinuierliche Bereitstellung: automatische Freigabe von neuem oder geändertem Code in der Produktion. Dies bedarf robuste Test-Frameworks, um sicherzustellen, dass der neue Code fehlerfrei und bereit für die Produktion ist.
    • Kontinuierliche Überwachung: fortlaufende Überwachung des sich in der Produktion befindlichen Codes und zugrundeliegender Infrastruktur. Eine Benachrichtigung über Fehler oder Probleme führt zur Entwicklung zurück.
    DevOps Vorteile
    • Schnelle Entwicklung
    • Schnelle Bereitstellung
    • Schnelle Reaktion auf Zwischenfälle
    • Lieferung qualitativ hochwertiger Software
    • Verbesserung der Zusammenarbeit und Kommunikation zwischen den Teams
    • Steigerung der Produktivität durch DevOps-Tools
    • Schnelle Problemlösung/Fehlerbehebung
    • Minimierung von Ausfallzeiten der Anwendung
    DevOps – Open source softwares

    Die gesamte Prozesskette läuft wie folgt ab:

    1. Entwickler pushen ihren Code in ein Repository
    2. Unittests werden ausgeführt
    3. Packaging + Build
    4. Automatisierte Integrationstests
    5. Releasemanagement
    6. Konfiguration
    7. Monitoring

     Mit den richtigen Tools kann der oben gezeigte Prozess automatisiert werden. In diesem Hinblick haben sich folgende Tools in vielen Unternehmen und Projekten bewährt:

    • Docker
    • Git
    • JUnit
    • Jenkins
    • Apache Maven
    • Selenium
    Fazit

    Das DevOps-Modell kommt mit einem Umdenken umher: der neue Prozess, der die Entwicklung und den Betrieb vereinen soll, muss erstmal in den Köpfen aller Teammitglieder ankommen. DevOps ermutigt Entwicklungs- und Betriebsteams, über die gesamte Anwendung hinweg, zusammenzuarbeiten. Der IT-Betrieb, der sich eher auf Stabilität der Software stützt und selten neue Deployments durchführt, muss großes Vertrauen im gesamten Prozess bringen, dass Entwicklung und Test ein stabiles Produkt liefern. Dadurch sind häufige Deployments kein Widerspruch zur Stabilität von Anwendungen. Ein weiterer Vorteil bei der Arbeit mit DevOps-Ansatz ist die Geschwindigkeit. Wenn Codeänderungen häufiger und mit geringem Risiko auf negative Auswirkungen auf andere Bereiche oder Komponenten bereitgestellt werden, lassen sich Innovationen dadurch schneller und einfacher realisieren.

    Native Cloud Application (NCA) – Entwicklung unter den Wolken

    Native Cloud Application (NCA) – Entwicklung unter den Wolken

    Waldemar Artes

    Waldemar Artes hat langjährige Erfahrung als Anwendungsentwickler. Er unterstützt Kunden als Senior-Entwickler bei der Umsetzung und Instandhaltung von Fachanwendungen. Er interessiert sich für technischen Fortschritt und alles, was uns weiterbringt.

    Nichts hat die Art und Weise, wie in der IT-Welt Software konzipiert und entwickelt wird in den letzten Jahren so sehr verändert wie Microservices. Heutige Anwendungen müssen in einem Cluster von mehreren Knoten funktionieren, dynamisch platzierbar, skalierbar und fehlertolerant sein.

    Microservices wiederum bilden die Basis von Cloud Native Applikationen. Die einzelnen Microservices sind voneinander unabhängig und können auf mehreren Servern an verschiedenen Standorten laufen. Cloud Native Anwendungen nutzen diese lose gekoppelten Cloud Services. Bei Cloud Native handelt es sich um einen Ansatz, der gewährleisten soll, dass Anwendungen für die Cloud-Computing-Architektur entworfen und entwickelt werden. Die Besonderheiten der Cloud-Computing-Architektur sollen zum Vorteil der Anwendungen genutzt und alle Möglichkeiten voll ausgeschöpft werden. Für diese Art von Anwendungen wird oft die Abkürzung NCA verwendet, welche für Native Cloud Application steht.

    Eine Native Cloud Application ist ein echtes Multitalent

    Native Cloud Applications haben zahlreiche Vorteile. Sie sind weder an eine spezielle Hardware noch an bestimmte Betriebssysteme gebunden, lassen sich leicht skalieren, sind einfach zu deployen, und sie sind georedundant. „Redundanz“ heißt, dass mindestens eine zusätzliche Ressource als Back-up für den Notfall vorhanden ist. In der Kombination mit „Geo“ bedeutet es, dass diese Ressourcen zusätzlich räumlich voneinander getrennt sind. Nur so kann wirklich sichergestellt werden, dass auch bei schwerwiegenden technischen Problemen an dem einen Ort noch immer ein intaktes Back-up an einem anderen Ort verfügbar ist. Laut Bundesamt für Sicherheit in der Informationstechnik (BSI) sollten es sogar mindestens 200 km sein, um auch vor Naturkatastrophen gut geschützt zu sein.

    Die vier zentralen Bestandteile der Entwicklung einer Native Cloud Application: DevOps, Continuous Delivery, Microservices und Container

    Vier zentrale Bestandteile für die Entwicklung einer Native Cloud Application

     

    • DevOps ist die Zusammenarbeit zwischen Entwicklung und Betrieb mit dem Ziel, den Auslieferungsprozess zu automatisieren.
    • Continuous Delivery erlaubt die schnellere und zuverlässigere Auslieferung von Software mit weniger Risiken
    • Microservices ist ein Architekturansatz, in dem eine Anwendung als Verbund von mehreren kleinen Services gebaut wird.
    • Container bieten leichtgewichtige Virtualisierung. Sie sind schneller und effizienter als normale Virtualisierung. Container können miteinander verknüpft und gemeinsam orchestriert werden.

    Diese vier Prinzipien erlauben es gemeinsam, schnell und risikoarm eine verteile Anwendung zu entwickeln, auf verteilter Infrastruktur auszuliefern und zu betreiben. Als Infrastruktur kann zum Beispiel Amazon Web Services oder Microsoft Azure genutzt werden.

    Herausforderungen bei der Entwicklung und dem Betrieb von NCAs

    Die Entwicklung einer Native Cloud Application bringt neue Herausforderungen mit sich, die ein Umdenken in der Entwicklung erfordern.

     

    • Persistente Datenablage: Container lassen sich nur kaum zur Datenhaltung nutzen, da diese sehr flüchtig sind. Wird ein Container gelöscht oder abgebaut, sind die Daten auch weg. Persistente Daten sollten deshalb außerhalb der Microservices gehalten werden. Auf diese Daten kann dann mittels einer Service-Schnittstelle zugegriffen werden.
    • Integration der Services: Verteilte Anwendungen bringen eine eigene Komplexität mit sich. So müssen die einzelnen Microservices über Server oder sogar Cloud-Provider hinweg miteinander integriert werden. Sie müssen sich gegenseitig finden und die Kommunikation soll fehlertolerant verlaufen.
    • Monitoring: NCAs können aus mehreren hundert bis tausend einzelnen Microservices bestehen. Umso wichtiger ist es, alle im Blick zu behalten. So müssen Werte wie Auslastung und Antwortzeiten beobachtet werden, um die Stabilität des gesamten Produktes zu gewährleisten.
    • Cloud Lock-in vermeiden: Durch die Einfachheit in ihrer Bedienung passiert es schnell, dass man sich von einem einzigen Cloud-Provider abhängig macht. Dessen sollte man sich bei der Planung bereits bewusst sein und so viele Industrie-Standards wie möglich anstelle von proprietären Lösungen nutzen.
    • Bauen von Pipelines zum Ausliefern der NCAs: NCAs arbeiten typischerweise in der Cloud. Möglicherweise sogar bei mehreren Cloud-Providern. Das erschwert das Ausliefern von NCAs, da diese stark verteilt sind und miteinander integriert werden müssen. Zudem können unterschiedliche Microservices unterschiedliche Abhängigkeiten fordern. Es werden Pipelines benötigt, die die einzelnen Microservices dorthin und in der benötigten Redundanz deployen, wo sie gebraucht werden.

    Vorteile einer Native Cloud Application

    Mit all den Herausforderungen, um eine Native Cloud Application zu entwickeln und zu Betreiben stellt sich immer die Frage: Ist es den Aufwand wert? Was sind die Vorteile?

     

    • Kosten: Wird die Anwendung auf einem Cloud-Anbieter betrieben, zahlt man nur das, was verbraucht. So können die Kosten für den Betrieb in nicht-aktiven Zeiten gesenkt werden.
    • Skalierbarkeit: Native Cloud Applications sind durch ihre Microservice-Architektur stark skalierbar. So können einzelne Microservices bei Bedarf dupliziert werden.
    • Kundennähe: NCAs können auf Servern weltweit betrieben werden. So müssen Anwender die Daten nicht über die ganze Welt verschicken und die Latenz sinkt.
    • Life-Cycle: NCAs können schneller und mit weniger Aufwand und Kosten aktualisiert werden. Dadurch erhöht sich die Auslieferungsgeschwindigkeit und das Time-To-Market sinkt.
    • Robustheit: NCAs können georedundant betrieben werden, wodurch Ausfälle bei lokalen technischen Problemen deutlich verringert werden.

    Tools für Entwicklung und Betrieb einer Native Cloud Application

    Die Cloud Native Computing Foundation ist eine neutrale Plattform für die meisten Open-Source-Projekte, die dabei helfen, die Herausforderungen und Probleme bei der Entwicklung und im Betrieb einer Native Cloud Application zu meistern. Darunter fällt das Orchestrierungstool Kubernetes, sowie das Monitoring-Tool Prometheus.

    Die CNCF stellt eine Übersicht über alle Projekte, Tools und Provider zur Verfügung, die bei der Entwicklung, Auslieferung und Betrieb von NCAs helfen.

    Was Softwarearchitekt:innen beachten müssen

    Das Sicherstellen der ACID-Eigenschaften (Atomic, Consistency, Isolated, Durability) bei der Datenhaltung ist in hoch verteilten Anwendungen mit mehreren Datenbanken sehr schwierig bis unmöglich. In der Regel kann für eine gewisse Zeit auf Konsistenz der Daten verzichtet werden. In diesen Fällen sind Datenbanken mit BASE-Eigenschaften (Basically Available, Soft state, Eventual consistency) interessant, denn hier wird die Datenkonsistenz im Laufe der Zeit hergestellt. Ein gutes Beispiel ist Twitter, da auf dieser Plattform die Follower-Zahlen nicht in Echtzeit aktualisiert werden.

    Softwarearchitekt:innen müssen entscheiden, für welche Daten Konsistenz benötigt wird und für welche nicht. Genauso müssen Sie darauf achten, die richtige Anzahl und Größe zu finden, da sie miteinander integriert werden. So sollte vermieden werden, aus reiner Bequemlichkeit neue Microservices zu implementieren. Microservices sollten immer nur eine Funktion erfüllen.

    Je mehr Microservices es gibt, desto schwieriger und wichtiger wird es, diese zu beobachten. Wichtige Daten wie Durchlaufzeiten und Aufrufe pro Zeiteinheit können kritische Bereiche, Fehler und Flaschenhälse aufdecken. Monitoring-Lösungen wie der ELK-Stack helfen dabei, die verteilten Metriken zu sammeln, zentralisieren und visualisieren. So können auch Grenzwerte gesetzt werden, deren Überschreitung oder Unterschreitung einen Alarm auslösen. Diese Grenzwerte sollten aber auch immer wieder evaluiert und angepasst werden.

    Best Practices bei der Entwicklung und Betrieb von Native Cloud Applications

    Die Microservices einer NCA sollten sauber in zustandlose Services und zustandsbehaftete Services getrennt werden. Zustandslose Services können problemlos dupliziert und wieder abgebaut werden, ohne den Zustand der Anwendung zu ändern.

    Microservices sollten nach Möglichkeit auch keine Anforderungen an das zu Grunde liegende System wie beispielsweise SSDs oder GPU haben. So lassen sie sich simpel in verschiedenen Umgebungen deployen.

    Bei der Entwicklung der NCAs ist es wichtig, so viel wie möglich zu automatisieren. Das hilft, die vielen Microservices und die verteilte Natur einer solchen Anwendung beherrschbar zu machen. Infrastructure-as-Code automatisiert die Bereitstellung der Infrastruktur. Dieser Code kann und sollte auch mit versioniert werden. Das garantiert, dass jeder Service immer und in jeder Umgebung für ihn passend konfigurierte Infrastruktur besitzt.

    Wenn dann ein weitverbreiteter Standard zur Kommunikation benutzt wird, wie etwa HTTP, können Microservices mit Technologien und Sprachen entwickelt werden, die am besten zur Aufgabe passen.

    Fazit

    Native Cloud Applications erlauben es den großen Internetgiganten wie Google und Twitter global ihre Services anzubieten, schnell Änderungen und neue Funktionen an die Nutzer:innen zu bringen. Herausforderungen, die sie mit sich bringen, lassen sich durch bereits etablierte Entwurfsmuster und Open Source Tools und Projekte ohne große Schwierigkeiten meistern. Die Hürden bei der Entwicklung und dem Betrieb einer Anwendung in der Cloud werden immer geringer, sodass heute jeder die Möglichkeit hat NCAs zu entwickeln und zu betreiben.

    Training zu ‘Infrastruktur, Container und Cloud Native (CLOUDINFRA)‘

    Unser 3-tägiges Training ‘Infrastruktur, Container und Cloud Native (CLOUDINFRA)‘ vermittelt das notwendige Wissen und die Fähigkeiten, um dynamische Cloud Native Architekturen konzipieren und implementieren zu können. Es werden zentrale Themen wie Container Application Design, Logging/Monitoring/Alerting, Container Native Storage, Möglichkeiten zur UI Integration sowie Container Manager vorgestellt. Wenn Sie die Zertifizierung zum Certified Professional for Software Architecture – Advanced Level (CPSA-A) nach dem iSAQB-Programm anstreben, erhalten Sie für dieses Training 20 Credit Points im Kompetenzbereich Technologie und 10 Credit Points im Kompetenzbereich Methodik.

    Termine zum Training 'Infrastruktur, Container und Cloud Native (CLOUDINFRA)'

    ITech Academy stellt 10 neue Trainings vor!

    ITech Academy stellt 10 neue Trainings vor!

    Neue Trainings in den Bereichen: Softwaremodellierung, Softwareentwicklung und Softwarearchitektur

    Wenn Sie unsere ITech Academy bereits kennen, wissen sie bestimmt, dass Softwarearchitektur ein untrennbarer Teil unserer DNA und vor allem unsere Leidenschaft ist! Das spiegelt sich auch in unserem großen Angebot an iSAQB-akkreditierten Softwarearchitektur Trainings wider. Von den Grundlagen bis hin zu fortgeschrittenen Trainings sind alle relevanten und aktuellen Themen aus der Welt der Softwarearchitektur vertreten. Als IT-Beratungsunternehmen beraten wir unsere Kunden neben innovativen Architekturparadigmen wie Microservices und Cloud Architekturen seit über 17 Jahren auch in allen Phasen ihrer IT-Projekte, von der Konzeption über den Entwurf und die Implementierung bis hin zu Testing, Fertigstellung und Qualitätssicherung.

    Wir als ITech Progress haben uns mit der ITech Academy einen Ort geschaffen, um genau diese langjährige Erfahrung in den Bereichen Softwaremodellierung, Softwareentwicklung und Softwarearchitektur in Form von theoretischem und praktischem Wissen weiterzugeben. Denn einer unserer Grundsätze lautet: Wissensmonopole sind für uns tabu!

    Aus diesem Grund haben wir 10 neue Trainings und Workshops nach eigenem Lehrplan entwickelt, die jetzt ein Teil unseres Academy-Portfolios sind! In allen Trainings und Workshops steckt das Beste aus unserer Arbeit und Erfahrung mit komplexen Systemen, bewährten Tools, Technologien, Architekturen und den Best Practices der Softwareentwicklung und -architektur. Und all das: Immer auf dem neuesten Stand!

    Das sind die neuen Trainings und Workshops:

    Softwaremodellierung

    Objektorientierter Softwareentwurf mit UML und Objektorientierung

    Dieses 3-tägige Grund- und Aufbautraining richtet sich an alle Softwareentwickler:innen und –architekt:innen im objektorientierten Umfeld, die UML als effektives Entwurfs-, Planungs- und Kontrollinstrument einsetzen möchten.

    Softwareentwicklung

    SQL & DB Design (5 Tage inkl. Workshopzeit)

    Java und OOP (5 Tage inkl. Workshopzeit)

    html und CSS (3 Tage inkl. Workshopzeit)

    JEE (3 Tage inkl. Workshopzeit)

    Programmieren für Fortgeschrittene mit JAVA

    Diese Trainings eignen sich ideal zur Mitarbeiterbefähigung, wenn in Ihrem Unternehmen beispielsweise noch Legacy-Systeme genutzt werden und der Umstieg auf zeitgemäße Technologien und Architekturen erfolgen soll.

    Softwarearchitektur

    Methodischer Fokus:

    Enterprise Application Integration Patterns

    In diesem 2-tägigen Training für Softwareentwickler:innen und -architekt:innen lernen sie Enterprise Application Integration (EAI) Patterns kennen, um Geschäftsfunktionen entlang der Wertschöpfungskette eines Unternehmens, die über diverse Applikationen auf verschiedenen Plattformen verteilt sind, zu integrieren.

    Design Patterns

    In diesem 2-tägigen Training für Softwareentwickler:innen und -architekt:innen lernen sie das Konzept und den Sinn von Entwurfsmusstern kennen.  Wir geben Ihnen aus unserer jahrelangen Projekterfahrung eine Auswahl wichtiger Entwurfsmuster an die Hand und führen sie mithilfe verschiedener Methoden in die praktische Anwendung.

    Technologischer Fokus:

    Clean Code

    In diesem Training lernen Sie die Werte, Regeln und Prinzipien kennen, auf denen die Handwerkskunst der Softwareentwicklung fußt und können damit dem Sprichwort „Wie der Meister, so das Werk“ folgend, sauberen, änderbaren, testbaren und objektorientierten Code entwickeln.

    Kommunikativer Fokus:

    Führungskräfteentwicklung

    In diesem 2-tägigen branchenübergreifenden Training geben wir Führungskräften das Know How für situationsgerechte Kommunikation, Reflexion und Verantwortungsdelegation als aktive Bestandteile einer effektiven und erfolgreichen täglichen Arbeit mit. Teilnehmer:innen erlernen, die eigenen Rollen und Ziele zu definieren und darauf aufbauend Ihr Verhalten auszurichten.

    So nehmen Sie an unseren neuen Trainings und Workshops teil

    Vorläufig ist das neue Portfolio nur in Form von Inhouse-Trainings (auch remote) buchbar, aber wir freuen uns auf Ihre direkte Rückmeldung, wenn Interesse an offenen Terminen besteht! Kommen Sie hierfür gerne über die unten angegebenen Kontaktmöglichkeiten auf uns zu oder melden Sie sich für unseren monatlichen Newsletter an, um keine Termine und Neuigkeiten zu verpassen. Aus unserer Erfahrung heraus wissen wir, dass eine Lernatmosphäre außerhalb des eigenen Standortes eine echte Bereicherung für das Team sein kann, weshalb wir Ihnen an unseren Standorten in Ludwigshafen und Nürnberg gerne auch großflächige, modern ausgestattete Schulungsräume zur Verfügung stellen.

    Sie haben Interesse an den neuen Trainings oder eine Frage?

    Dann rufen Sie uns bitte unter +49 621 595702 41 an, schreiben Sie eine E-Mail an training@itech-progress.com oder schicken Sie uns über das Kontaktformular eine schriftliche Anfrage:

    7 + 4 =

    OOP digital 2021 – wir sind dabei!

    OOP digital 2021 – wir sind dabei!

     Full Day Tutorial mit Mahbouba Gharbi und Tom Asel
     
     Digitaler Austausch mit unserem Team via 1:1 Chat über Softwarearchitektur, Trainings, Consulting, Projektunterstützung und Karrieremöglichkeiten 
     
     Verlosung eines iSAQB CPSA Trainings Ihrer Wahl über unsere Präsenz im Event Hub
     
     100€ Rabattcode für alle Trainings über unsere Präsenz im Event Hub

    Unter dem Motto “Back to the Future” findet die diesjährige OOP rein digital statt und wir sind wie immer mit dabei! Wir freuen uns bereits aus dem Home Office heraus mit Ihnen in den Austausch zu kommen. Sie finden unsere Teammitglieder über den 1:1 Chat oder Sie besuchen ITech Progress und die ITech Academy direkt im Event Hub.

    Full Day Tutorial: 
    Wardley Maps als Werkzeug in der Architekturanalyse –
    Eine Group Mapping Session für Architekten und Entscheider
     
    Datum und Uhrzeit:
    Mo, 08.02.2021 von 10:00 – 17:00 Uhr
     
    Mit:
    Mahbouba Gharbi und Tom Asel
     
    Publikum:
    Maximal 30 Teilnehmer*innen
    l
    Abstract:

    Der Workshop richtet sich sowohl an interessierte Einsteiger:innen als auch an bereits erfahrene Mapper. Im Plenum werden Wardley Maps als Werkzeug in der Toolbox der Software-Entwickler:innen diskutiert und im Rahmen einer ausgiebigen Group-Mapping-Session in der Praxis erprobt. Am praktischen Beispiel der Digitalisierung eines Möbelhauses wird gezeigt, wie Maps dabei helfen, Lagebewusstsein zu schaffen, Risiken zu erkennen und eine Strategie zu entwickeln.

    Wir untersuchen die Systemlandschaft, führen eine Architekturanalyse durch und verorten die Ergebnisse wieder auf unserer Landkarte.

    Der Workshop zeigt, warum Trägheit ein Unternehmen scheitern lassen kann, wie Softwarearchitektur und Unternehmens-Strategie zusammenhängen und wie Wardley Maps dabei helfen, beides zu kommunizieren.

    .