Requirements for Software Architects

Jun 15, 2023 | Methodisch, Softwareentwicklung, Technisch, Trainings & Workshops

Requirements for Software Architects

Agile Requirements Engineering und seine Rollen

Willkommen zurück zum zweiten Artikel in unserer Blog-Serie „Requirements for Software Architects“. Wir widmen uns in diesem Beitrag dem agilen Requirements Engineering und seinen Rollen.

Grundbegriffe von Softwarearchitektur

Definition

Es befinden sich zahlreichen Definitionen von Softwarearchitektur. Wir beschränken uns deshalb nur auf zwei davon:

Die grundlegenden Konzepte oder Eigenschaften eines Systems in seiner Umgebung, verkörpert in seinen Elementen, Beziehungen und in den Prinzipien seines Designs und seiner Entwicklung. (ISO/IEC/IEEE 42010)
Die Softwarearchitektur einer Software oder Computersystems ist die eine oder mehrere Strukturen des Systems, welche die Softwareelemente, die extern sichtbaren Eigenschaften dieser Elemente und die Beziehungen zwischen ihnen, umfassen. (Bass, Clements, Kazman Software Architecture in Practice, Addison Wesley, 2003.)

Aufgaben von Softwarearchitekten

Softwarearchitekten haben die Aufgabe die Softwarearchitektur aktiv zu gestalten und ihre Umsetzung und Wirksamkeit sicherzustellen. Dabei sollen sie im Wesentlichen die folgenden Ziele in einem Projekt erreichen:

Unterstützung von Entwurf, Implementierung, Pflege und Betrieb des Systems
Erfüllbarkeit der funktionalen Anforderungen sicherstellen
Qualitätsanforderungen in gewünschtem Maße erreichen
Komplexität systematisch reduzieren
Architekturrelevante Richtlinien für Implementierung und Betrieb spezifizieren

Die Arbeit eines Architekten kann dabei in sechs Tätigkeiten gegliedert werden:

Anforderungen klären
Strukturen entwerfen
Querschnittskonzepte erstellen
Architekturen bewerten
die Umsetzung begleiten
Architekturen kommunizieren

Der erste Schritt „Anforderungen klären“ stellt dabei die Schnittstelle unter anderem zum Requirements Engineering dar. Hierbei probiert der Architekt herauszufinden, welche Anforderungen architektonisch relevant sind.

ASR: Architektonisch bedeutende Anforderungen

Architecturally Significant Requirements (ASRs) umfassen die wichtigsten architektonischen Anforderungen. Dabei ist es egal, ob es sich um Funktionale oder nicht Funktionale Anforderungen handelt. Somit sind ASRs Anforderungen, die sich direkt auf das Architekturdesign auswirken.

Ein Architekt sollte alle NFRs mit den Stakeholdern abgestimmt und dokumentiert haben. Es ist üblich, dass eine funktionale oder nichtfunktionale Anforderung in unterschiedlichen Phasen des Software-Lebenszyklus den Status einer ASR erlangen oder verlieren kann.

Sein Entwurf und insbesondere seine Entwurfsentscheidungen sollten daher transparent machen auf Basis welcher ASRs eine Entscheidung oder ein Entwurf beruht, um Nachvollziehbarkeit zu erlangen und eine wirksame Architektur sicherzustellen.

Abbildung 9: Architecture in Technical Perspective View

Um diese zu erreichen, sollen Softwarearchitekten diese Anforderungen stets überprüfen und die Unterschiede und Besonderheiten erklären. Insbesondere der PO, RE und BA, aber auch andere Akteure, sollten für ein besseres Verständnis und eine bessere Kommunikation sensibilisiert werden .

Einige gängige Quellen für ASRs sind,

Anforderungsdokumentation (z.B. Product Backlog)
Vereinbarung zum Servicelevel (SLA)
Fachwissen
Anwendbare Standards, Richtlinien oder Richtlinien

Solange ASRs in der Dokumentation vorhanden sind, können sie von Softwarearchitekten analysiert und verbessert werden. Sind sie jedoch nicht oder unvollständig dokumentiert, so besteht das Risiko einer unwirksamen Architektur. Eine unwirksame Architektur ist nicht in der Lage die funktionalen und nichtfunktionalen Anforderungen zu erfüllen und stellt nicht nur ein signifikantes Projektrisiko dar, sondern ist mit fortschreitender Projektlaufzeit zudem teuer zu ändern.

Architecturally Significant Requirements (ASRs) müssen deshalb Vorrang bei der Identifizierung und Dokumentation haben, um das Architekturdesign in die richtige Richtung zu leiten.

Agile Requirements Engineering

Wie bereits zuvor etabliert sollen Anforderungen nicht nur korrekt erhoben werden, sondern auch verständlich kommuniziert und ihre Erreichung geprüft werden. Dabei sind Anforderungen stetig um Wandel und bedürfen Pflege.

Agile Requirements Engineering ist ein kooperativer, iterativer und inkrementeller Ansatz, der dies erreichen soll. Er gliedert sich groß in zwei Phasen: Die Definitionsphase (Anforderungserstellung) und die eigentliche Umsetzungsphase (Entwicklung). Im Gegensatz zu den herkömmlichen Vorgehensweisen laufen die beiden Phasen, Definition und Implementierung, parallel ab.

Daraus ergeben sich viele Vorteile. Zu diesen Vorteilen gehört die schnelle und flexible Reaktion auf veränderte oder neue Gegebenheiten.

Dies wird dadurch gewährleistet, dass die Anforderungsbeschreibung nie abgeschlossen und während der gesamten Entwicklungsdauer ständig neu erfasst und angepasst wird. Das heißt, wenn einzelne Aspekte eines Prozesses von den akzeptablen Grenzen abweichen oder das resultierende Produkt nicht akzeptabel ist, muss der Prozess oder die erzielten Ergebnisse angepasst werden. Eine Anpassung sollte so schnell wie möglich erfolgen, um weitere Abweichungen zu reduzieren. Dieser Ansatz folgt vier Zielen:

Kenntnis der relevanten Anforderungen auf einem angemessenen Detaillierungsgrad (zu jedem Zeitpunkt während des Systementwicklungsprozesses).
Ausreichende Übereinstimmung über Anforderungen unter den Stakeholdern erreichen.
Erfassen und Dokumentieren der Anforderungen gemäß der Einschränkungen und Vorgaben der Organisation.
Durchführung aller anforderungsbezogenen Aktivitäten gemäß den Prinzipien des agilen Manifests.

Requirements Engineering Aktivitäten sind sehr weit gefächert und von der Art des zu entwickelnden Systems und der Organisationsspezifikation abhängig. Nichtsdestotrotz gehören auch im agile Requirements Engineering folgende vier zentrale Tätigkeiten, die von IREB etabliert wurden, dazu:

Anforderungserhebung: Die Anforderungen werden anhand unterschiedlicher Methoden möglichst effizient, vollständig und fehlerfrei ermittelt. Auch Detaillierung und Verfeinerung gehören dazu.
Anforderungsdokumentation: Die Anforderungen müssen adäquat und qualitativ hochwertig beschrieben werden, um die Anforderungsspezifikation mit allen relevanten Anforderungen entstehen zu lassen.
Anforderungsprüfung und -abstimmung: Die Anforderungsspezifikation wird auf ihre Gesamtqualität geprüft. Dazu gehört auch die inhaltliche Abstimmung mit den Stakeholdern.
Anforderungsverwaltung: Auch Anforderungsmanagement genannt, geht es bei der Verwaltung der Anforderungen darum, sie zur Nutzung bereitzustellen, die Versionsstände zu pflegen, eine Priorisierung zu erstellen, etc.

Der Unterschied zwischen Requirements Engineering und Requirements Management

Die Begriffe Requirements Engineering und Requirements Management werden oft fälschlicherweise als Synonym verwendet. Wenn man von einem ganzheitlichen Requirements-Engineering-Ansatz spricht, muss man das streng genommen immer im Sinne des Anforderungsmanagements tun. Rückblickend auf die bereits genannten vier zentralen Aktivitäten bezieht sich Requirements Engineering hauptsächlich auf die ersten drei Punkte. Requirement Engineering, was ins Deutsche übersetzt wird, bedeutet Anforderungsmanagement und umfasst damit die vierte zentrale Aktivität.

Die beiden Fachtermini sind jedoch untrennbar miteinander verbunden und gehen Hand in Hand mit Requirements Management: Ohne Ermittlung gibt es keine Verwaltung und ohne effiziente Verwaltung und Aufbereitung hat die Ermittlung von Anforderungen keinen Nutzen.

Die Product Owner (PO), Business Analyst (BA) und Requirements Engineer (RE) Rollen

Agiles Requirements Engineering geschieht nicht ad-hoc, sondern über unterschiedlichen Rollen. In der Praxis kommt es oft vor, dass es nur eine Rolle gibt (wie PO, BA, RE oder alle zusammen). Unabhängig davon wie viele Rollen in der Praxis vorhanden sind, kann die Unterteilung genutzt werden, um die unterschiedlichen Tätigkeiten und Verantwortlichkeiten des Requirements Engineering und Management gewinnbringend zu gliedern und die eigene Arbeit zu strukturieren.

Der Product Owner ist für die Wertsteigerung, genauer gesagt die Rentabilität (= ROI, Return of Investment) verantwortlich, nicht nur was das Produkt angeht, sondern auch in Bezug auf das Projektteam. Es handelt sich also um eine anspruchsvolle Aufgabe. Hierbei sind ihm drei zentrale Aufgaben zugeordnet:

Vertretung der Kundeninteressen
Zusammenarbeit mit dem Entwicklungsteam und Scrum Master
Verwaltung des Product Backlogs

Dabei sollte er die richtige Funktionalität in der richtigen Priorität ins Projekt bringen. Daraus abgeleitet sollte er die folgenden Skills und Aufgaben meistern können:

Stakeholder Analyse
Erhebungstechniken
Konfliktmanagement
Priorisierung (z.B. Priority Poker)

Ähnlich zur PO-Rolle sollte der Business Analyst (BA) über Kreativitäts- und Erhebungstechniken verfügen. Zudem unterstützt er den Product Owner bei der Erhebung fachlicher Anforderungen, deren Akzeptanzkriterien und der Prüfung, ob und wie die Anforderungen zu den Geschäftsprozessen passen.

Zu guter Letzt kümmert sich der Requirements Engineer (RE) für die nachhaltige Spezifizierung von Anforderungen und ihre Übersetzung in das technische Umfeld.

Alle drei Rollen sollten über die folgenden Skills verfügen:

Stakeholder Analyse
Kreativitätstechniken
Erhebungstechniken (typischerweise mittels Befragung, Design Thinking, Persona usw.),
Dokumentationstechniken
Modellierung (typischerweise mittels UML)
Priorisierung von Anforderungen

Alle diese Skills können je nach Bedarf und Aufgabengebiet verwendet werden.

Welche verschiedenen modernen Techniken in Requirement Engineerings eingesetzt werden können, sehen wir uns im nächsten und letzten Teil der Blog-Serie an. Wir freuen uns schon Sie wiederzusehen.

Quellen

Sommerville, Ian (2009). Softwareengineering (9th ed.). Addison-Wesley. ISBN 978-0-13-703515-1.
Andreas Wintersteiger, Scrum Schnelleinstieg
McGreal, Don; Jocham, Ralph (June 4, 2018). The Professional Product Owner: Leveraging Scrum as a Competitive Advantage. Addison-Wesley Professional. ISBN 9780134686653.
https://t2informatik.de/
North, Introducing Behaviour Driven Development
Dan North et al.: Question about Chapter 11: Writing software that matters. (Nicht mehr online verfügbar.) Archiviert vom Original am 7. November 2009; abgerufen am 9. November 2011 (englisch): „The phrase ‘BDD is TDD done well’, while a nice compliment, is a bit out of date. […] BDD has evolved considerably over the years into the methodology we describe in the book. Back when it was focused purely on the TDD space– around 2003-2004 – this was a valid description. Now it only covers a small part of the BDD proposition“
Schwaber, Ken; Sutherland, Jeff (November 2017), The Scrum Guide: The Definitive Guide to Scrum: The Rules of the Game, retrieved May 13, 2020
“Lessons learned: Using Scrum in non-technical teams”. Agile Alliance. May 18, 2018. Retrieved April 8, 2019.
Ken Schwaber; Jeff Sutherland. “The Scrum Guide”. Scrum.org. Retrieved October 27, 2017.
https://www.scrum.org/
http://agilemanifesto.org/
https://www.isaqb.org/
https://swissq.it/agile/die-rollen-des-po-re-und-ba-im-vergleich/

Abbildungen

Abbildung 9: https://media.geeksforgeeks.org/wp-content/uploads/20200704172739/Untitled-Diagram160.png

Requirements for Software Architects

Mai 16, 2023 | Methodisch, Softwareentwicklung, Technisch, Trainings & Workshops

Requirements for Software Architects

Mit Requirements Engineering zu den besten Anforderungen

Herzlich Willkommen zu unserer neuen Blog-Serie, Requirements for Software Architects!
Erfahren Sie in dieser dreiteiligen Reihe etwas über die Signifikanz von Anforderungen Ihrer Kunden, die verschiedenen Rollen des Agile Requirement Engineerings und moderne Techniken.

Abbildungs 1: Wie Projekte wirklich funktionieren

Einführung und Überblick

Requirements Engineering und Softwarearchitektur sind in der Welt der Softwareentwicklung Tätigkeitsbereiche, die große Teilverantwortungen tragen, um Softwareentwicklungsprojekte erfolgreich abzuschließen. Letztlich geht es darum, die Kundenbedürfnisse zu erfüllen und den Kunden zufrieden zu stellen. Um dies zu erreichen, muss man den Kunden richtig verstehen und wissen, was er tatsächlich braucht.
In diesem Stadium sind Anforderungen und deren Management Hauptakteure im Softwareentwicklungsprozess .
Anforderungen sind in Softwareprojekten das Abbild der Kundenwünsche. Sie dienen als zentrale Briefings für fast alle weiteren Tätigkeiten. Die korrekte Erhebung, Erfassung, Überprüfung, Pflege und Verfeinerung von Anforderungen beeinflusst folglich den gesamten Software-Lebenszyklus und ist somit entscheidend für den Erfolg von Softwareentwicklungsprojekten.
Im Software-Lebenszyklus sind die Phasen der Anforderung und der Softwarearchitektur direkt aufeinander folgend und daher besonders stark miteinander verzahnt, fehlerhaftes Anforderungsmanagement hat dementsprechend direkte, schwerwiegende Folgen auf architektonische Entscheidungen.

Abbildung 2: Software-Lebenszyklus

An dieser Stelle geht es nicht nur darum, dass der Requirements Engineer oder der Product Owner die richtigen Anforderungen (von den Kunden) aufgenommen hat, vielmehr geht es darum, dass der Softwarearchitekt den Product Owner richtig versteht und die von ihm bereitgestellten Anforderungen überprüft und analysiert, um darauf aufbauend seine architektonische Entscheidung treffen zu können.
In den folgenden Abschnitten geben wir einen Überblick über Anforderungsmanagement und Softwarearchitektur, bzw. wie sie sich einander ergänzen und gegenseitig beeinflussen. Dazu betrachten wir die beiden Rollen des Softwarearchitekten und eines Product Owners, sowie ihre Verantwortlichkeiten und Aufgaben in Softwareentwicklungsprojekten. Zuvor klären wir einige Grundbegriffe.

Anforderungen Definition und Grundbegriffe

„Requirement“ (englisch) bedeutet so viel, wie „Vorausgesetztes“ oder „verpflichtendes Erfordernis“, aber auch Erwartung. Wie bei vielen Begriffen aus der IT-Welt gibt es für den Begriff „Anforderung“ zahlreiche Definitionen.

Requirements Engineering Board (IREB) definiert Anforderung hingegen als:
• ein Bedürfnis, das von einem Stakeholder wahrgenommen wird.
• eine Fähigkeit oder Eigenschaft, die ein System haben soll.
• eine dokumentierte Darstellung eines Bedarfs, einer Fähigkeit oder eines Eigentums.

Für das International Institute of Business Analysis (IIBA) ist eine Anforderung eine brauchbare Darstellung eines Bedürfnisses, die in der Regel durch Dokumente beschrieben wird.
Daraus abgeleitet können Anforderungen als eine Aussage über den zu erreichenden Merkmalen oder die zu erbringenden Leistungen für eine Software oder System definiert werden.

Arten von Anforderungen

In der Literatur gibt es viele Unterteilungen oder Klassifizierungen von Anforderungen. Zum Zwecke dieses Inhalts betrachten wir nur zwei (bekannte) Hauptkategorien, funktionale (FR) und nicht-funktionale Anforderungen (NFR).
Nichtfunktionalen Anforderungen fallen wiederum in zwei Kategorien: Die Qualitätsanforderung oder Qualitätskriterien und die Einschränkungen (eng. constraints)

Abbildung 3: Gute vs. schlechte Anforderungen

Funktionale Anforderungen

Das „WAS“ legt die Funktionale Anforderungen fest, was das Produkt tun soll. Ein Beispiel:
„Das System soll die geleisteten Arbeitsstunden eines Mitarbeiters für einen bestimmten Zeitraum berechnen.“
Das bedeutet, dass sich die funktionalen Anforderungen lediglich auf die Verhaltensergebnisse beziehen, die die Funktionalität des Systems oder der Software liefern soll.

Nichtfunktionale Anforderungen (NFRs)

Die nicht-funktionalen Anforderungen (NFR) beschreiben, wie gut das System die Leistung erbringen soll und unter welchen Rahmenbedingungen und sind eine Herausforderung für jeden PO. Sie werden typischerweise in zwei Bereiche untergliedert:
• Qualitätskriterien
• Einschränkungen

Qualitätskriterien

… sind Anforderungen, die sich auf ein Qualitätsproblem beziehen, das nicht durch funktionale Anforderungen abgedeckt ist.
Diese werden (z.B. nach Volere) in Ausführungsqualität und Weiterentwicklungsqualität gegliedert.

Ausführungsqualität (während des Betriebs / zur Laufzeit)

Zuverlässigkeit (Systemreife, Wiederherstellbarkeit, Fehlertoleranz)
Aussehen und Handhabung (Look-and-feel)
Benutzbarkeit (Verständlichkeit, Erlernbarkeit, Bedienbarkeit)
Leistung und Effizienz (Antwortzeiten, Ressourcenbedarf, Wirtschaftlichkeit)

Sicherheitsanforderungen (Vertraulichkeit, Informationssicherheit, Datenintegrität, Verfügbarkeit)
Korrektheit (Ergebnisse fehlerfrei)

Weiterentwicklungs- und Evolutionsqualität

Betriebs- und Umgebungsbedingungen
Wartbarkeit, Änderbarkeit (Analysierbarkeit, Stabilität, Prüfbarkeit, Erweiterbarkeit)
Portierbarkeit und Übertragbarkeit (Anpassbarkeit, Installierbarkeit, Konformität, Austauschbarkeit)
Flexibilität (Unterstützung von Standards)
Skalierbarkeit (Änderungen des Problemumfangs bewältigen)

Eine andere Aufteilung von Nichtfunktionalen Anforderungen findet man in der ISO 25010. Hier werden die Qualitätsanforderungen anhand 8 Kriterien beschrieben.

Abbildung 7: Standard ISO/IEC 25010. Software product quality model

1. Funktionale Eignung

Funktionelle Vollständigkeit
Korrekte Funktionalität
Angemessene Funktionalität

2. Verlässlichkeit

Reife
Verfügbarkeit
Fehlertoleranz
Wiederherstellbarkeit

3. Leistungseffizienz

Zeitverhalten
Ressourcennutzung
Kapazitätsaufwand

4. Nutzbarkeit

Angemessene Erkennbarkeit
Erlernbarkeit
Bedienbarkeit
Schutz vor Fehlbedienung durch den Nutzer
User-Interface Ästhetik
Zugänglichkeit

5. Wartbarkeit

Modularität
Wiederverwendbarkeit
Analysierbarkeit
Modifizierbarkeit
Testfähigkeit

6. Sicherheit

Datenschutz
Integrität
Unmanipulierbarkeit
Administrationsfähigkeit
Authentifizierbarkeit

7. Kompatibilität

Co-Existenz (zu weiterer Software)
Interoperabilität

8. Portierbarkeit

Anpassungsfähigkeit
Installierbarkeit
Austauschbarkeit

Einschränkungen

… sind Anforderungen, die den Lösungsraum über das hinaus beschränken, was zur Erfüllung spezifizierter funktionaler Anforderungen und Qualitätsanforderungen erforderlich ist.

Es gibt verschiedene Arten von Einschränkungen, z.B. zeitliche Terminplanbeschränkung, regulatorische oder gesetzliche Beschränkungen usw.

In Softwareprojekten spricht man von Einschränkungen, wenn Faktoren wie Zeit, Geld, Umfang (das sogenannte „Magische Dreieck“) oder Ressourcen, wie Ausrüstung oder Personalmangel das Projekt beeinflussen.

Abbildung 8: Das magische Dreieck

Die Einschränkungen hängen auch von dem Tätigkeitsbereich des Unternehmens sowie den Dienstleistungen ab, welches es anbietet.

Im Gesundheitswesen beispielsweise können bestimmte Vorschriften oder Gesetze die Qualität von Software oder sogar die Implementierung der gesamten Softwarearchitektur beeinträchtigen.

Aus allen diesen Gründen ist es wichtig, dass sich der Softwarearchitekt bereits zu Beginn des Projekts mit den verschiedenen Einschränkungen auseinandersetzt und mit den Key Rollen abklärt.

Wir freuen uns schon, Sie beim nächsten Artikel unserer Blog-Serie wieder begrüßen zu dürfen – dem Agile Requirements Engineering und seine Rollen.

Quellen

Sommerville, Ian (2009). Softwareengineering (9th ed.). Addison-Wesley. ISBN 978-0-13-703515-1.
Andreas Wintersteiger, Scrum Schnelleinstieg
McGreal, Don; Jocham, Ralph (June 4, 2018). The Professional Product Owner: Leveraging Scrum as a Competitive Advantage. Addison-Wesley Professional. ISBN 9780134686653.
https://t2informatik.de/
North, Introducing Behaviour Driven Development
Dan North et al.: Question about Chapter 11: Writing software that matters. (Nicht mehr online verfügbar.) Archiviert vom Original am 7. November 2009; abgerufen am 9. November 2011 (englisch): „The phrase ‘BDD is TDD done well’, while a nice compliment, is a bit out of date. […] BDD has evolved considerably over the years into the methodology we describe in the book. Back when it was focused purely on the TDD space– around 2003-2004 – this was a valid description. Now it only covers a small part of the BDD proposition“
Schwaber, Ken; Sutherland, Jeff (November 2017), The Scrum Guide: The Definitive Guide to Scrum: The Rules of the Game, retrieved May 13, 2020
“Lessons learned: Using Scrum in non-technical teams”. Agile Alliance. May 18, 2018. Retrieved April 8, 2019.
Ken Schwaber; Jeff Sutherland. “The Scrum Guide”. Scrum.org. Retrieved October 27, 2017.
https://www.scrum.org/
http://agilemanifesto.org/
https://www.isaqb.org/
https://swissq.it/agile/die-rollen-des-po-re-und-ba-im-vergleich/

Abbildungen

Abbildung 1: https://cdn-images-1.medium.com/max/1200/1*ApoaIZicyU0b7Jgg9MMJhw.jpeg

Abbildung 2: ITech Progress CPSA-Foundation Kurs (Präsentation) – Kapitel 1: Grundbegriffe – Einordnung der Softwarearchitektur in Software-Lebenszyklus

Abbildung 3: https://www.softwareone.com/-/media/global/social-media-and-blog/content/requirements-engineering-4-graph1.png?mw=1024&rev=bc1dea2cb4d145c79f1f5b544e3a10cd&sc_lang=de-at&hash=43114D2C3FE79F36503891506BDBA9FA

Abbildung 4: https://www.nasa.gov/images/content/549928main_jfk_speech_226.jpg

Abbildung 5: https://www.nasa.gov/sites/default/files/styles/side_image/public/62297main_neil_on_moon_full.jpg?itok=1c8GTfbJ

Abbildung 6: https://miro.medium.com/max/1762/0*ohypH8bVpf2O0uIc.png

Abbildung 7: https://www.researchgate.net/profile/Lina-Garces/publication/326584873/figure/fig2/AS:652083346808834@1532480193500/Standard-ISO-IEC-25010-Software-product-quality-model-and-system-quality-in-use-model.png

Abbildung 8: https://i.pinimg.com/originals/a1/3c/ed/a13cedd07eb87e2fab0baa483d9877fd.png

Kontrollverlust in Softwaresystemen?

Jun 9, 2022 | Interviews & Vorträge, Messen & Konferenzen, Softwareentwicklung, Technisch

Kontrollverlust in Softwaresystemen?

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

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!

Weitere Infos zum JFS:

Startseite – Java Forum Stuttgart (java-forum-stuttgart.de)

DevSecOps – sichere Softwareentwicklung und Betrieb

Mai 25, 2022 | Softwareentwicklung, Technisch

DevSecOps – sichere Softwareentwicklung und Betrieb

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 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.

Referenzen

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

Apr 28, 2022 | Softwareentwicklung, Technisch

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:

Entwickler pushen ihren Code in ein Repository
Unittests werden ausgeführt
Packaging + Build
Automatisierte Integrationstests
Releasemanagement
Konfiguration
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.

Referenzen

Lesempfehlung: Infrastructure as Code

Feb 8, 2022 | Leseempfehlungen, Softwareentwicklung

Wir haben für Sie gelesen!

Lesetipps für Alle, die an Softwarearchitektur, Softwareentwicklung und IT-Projektmanagement interessiert sind.

Infrastructure as Code

Prinzipien, Praktiken und Patterns für eine cloudbasierte IT-Infrastruktur

2. Auflage

Kief Morris

Beim Verlag kaufen



Server in der Cloud verwalten

Noch vor ein paar Jahren hielten viele Unternehmen und Banken die Nutzung von Private und Public Cloud Technologien und Infrastructure Automation Tools für ausgeschlossen – die eigenen Anforderungen seien zu komplex und das Unternehmen zu groß. Für Start-ups könnte es funktionieren – eventuell. Jetzt, 6 Jahre nach der 1. Auflage von Infrastructure as Code, sind wir inmitten des Zeitalters der Cloud angekommen. Große sowie eher konservative Unternehmen setzen immer mehr auf die „Cloud-first“ Strategie. Alternativ weichen Unternehmen auf dynamisch bereitgestellte Infrastrukturplattformen in ihren Rechenzentren aus. Wer die Möglichkeiten dieser Plattformen ignoriert, der verliert! Oder riskiert zumindest, dass der Zahn der Zeit immer weiter an der physischen Infrastruktur nagt und Fehler nur langsam und kostspielig behoben werden können.

Das Infrastructure-as-Code-Konzept ermöglicht dagegen die Automatisierung der Infrastruktur mithilfe von Ansätzen aus der Softwareentwicklung. Der Fokus liegt darauf, konsistente und wiederholbare Routinen für die Bereitstellung und Änderung von Systemen und deren Konfiguration zu erzeugen. Änderungen, die am Code vorgenommen werden, werden von der Automatisierung genutzt, um sie zu testen und auf Systeme anzuwenden. Somit ermöglicht das Infrastructure-as-Code-Konzept eine schnelle Bereitstellung von Infrastruktur bei Veränderung des Bedarfs von Rechenleistung.



Über den Autor

Der Autor, Kief Morris, ist Principal Cloud Technologist bei dem Technologie-Beratungsunternehmen thoughtworks. Er betreut und berät Unternehmen und Teams in diesem Cloud-Zeitalter hinsichtlich der passenden Technologien und Methoden. Themen wie Cloud, digitale Plattformen, Infrastructure Automation, DevOps und Continuous Delivery gehören also zu seinem täglichen Geschäft.



Über Infrastructure as Code

Mit dieser 2. Auflage von Infrastructure as Code verspricht Kief Morris ein praktisches Handbuch zu liefern, das Ihnen erklärt, wie Sie eine IT-Infrastruktur im Zeitalter der Cloud aufsetzen und managen. Genauer gesagt zeigt er, wie Sie mit Prinzipien, Praktiken und Patterns aus der Softwareentwicklung eine IT-Infrastruktur mithilfe von Technologien wie Cloud, Virtualisierung und Konfigurationsmanagement verwalten können. Die Magie besteht darin, mittels der Technologien die Infrastruktur von der Hardware zu entkoppeln, um sie dann in Code und Daten umzuwandeln.

Das erwartet Sie

Die Grundlagen: wie Infrastructure as Code mittels Tools und Technologien eingesetzt werden kann, um Cloud-basierte Plattformen aufzubauen
Die Arbeit mit Infrastructure Stacks: wie Sie kontinuierlich Änderungen an Infrastrukturressourcen definieren, bereitstellen und testen
Die Arbeit mit Servern und anderen Plattformen: Verwendung von Mustern für die Bereitstellung und Konfiguration von Servern und Clustern
Die Arbeit mit großen Systemen und Teams: aneignen von Workflows, Governance und Architekturmustern zur Erstellung und Verwaltung von Infrastrukturelementen



Dieses Buch darf in Ihren Bücherregalen nicht fehlen…

…wenn Sie in einem Bereich arbeiten, der daran beteiligt ist IT-Infrastrukturen aufzusetzen und zu betreiben:

^

Systemadministration

^

Softwareentwicklung

^

Softwarearchitektur

^

IT-Infrastrukturadministration

^

Technische Projektleitung

Infrastruktur, Container und Cloud Native (CLOUDINFRA)

Erleben Sie in Ihrem Umfeld derzeit den Übergang von einer zentralisierten hin zu einer verteilen IT? Dann wissen Sie sicherlich genauso wie wir, dass dabei eine Vielzahl von Prozessen entsteht und mit ihnen die Herausforderung, diese Fülle von kleinen Systemkomponenten für den Betrieb bereitzustellen. Um diese Herausforderung zu meistern, empfehlen wir Ihnen das 3-tägige Training „Infrastruktur, Container und Cloud Native (CLOUDINFRA)“. Die Teilnehmer erhalten umfassendes Wissen zu den Themen Cloud Native Architekturen, Container Application Design, Logging/Monitoring/Alerting, Container Native Storage und Möglichkeiten zur UI Integration.

Ebenso werden typische Konzepte aktueller Container Manager aufgezeigt und vermittelt, wie sich damit für größere Webanwendungen gängige Qualitätsanforderungen realisieren lassen. Auch Infrastructure as Code wird bei diesem Training im Rahmen der Grundlagen modernder Infrastrukturen und der Automatisierung als Konzept vorgestellt.

Dieses Training ist Teil des weltweit anerkannten Weiterbildungsprogramm „Certified Professional for Software Architecture (CPSA)“ des iSAQB. Für die Zertifizierung zum „Certified Professional for Software Architecture – Advanced Level (CPSA-A)“ sammeln Sie mit diesem Training die entsprechenden Credit Points: 20 CP Kompetenz in Technologie und 10 CP Kompetenz in Methodik. Das 3-tägige Training wird in der ITech Academy auf Deutsch (Online und Präsenz) und Englisch (Online) angeboten.

Besuchen Sie das 3-tägige „Infrastruktur, Container und Cloud Native (CLOUDINFRA)“ Training und sammeln Sie Credit Points für Ihre Zertifizierung zum „Certified Professional for Software Architecture – Advanced Level (CPSA-A)“!

Zum Training

Fazit zu Infrastructure as Code

Kief Morris lässt in sein Buch Erfahrungen aus seiner Arbeit mit Teams, die mit großen und komplexen Infrastrukturen zu kämpfen hatten und denen die Organisation und Arbeit mit Infrastrukturcode zu Beginn schwerfiel, einfließen. Infrastructure as Code ist kein Einsteigerwerk, aber ein gut geschriebenes Buch für Leute, die 1. Nicht vor Theorie zurückschrecken, denen 2. die behandelten Technologien nicht ganz neu sind und die 3. vertraut sind mit Softwareentwicklung und Konzepten wie Agile und Lean. Fans von Patterns und konzeptionellen Ansätzen für die Softwareentwicklung werden mit Infrastructure as Code auf ihre Kosten kommen.



Informiert bleiben über neue Lesetipps und Buchverlosungen

Newsletter abonnieren