Prüfungsstress im Projekt: Welche NOTE bekommt meine Architektur?

Prüfungsstress im Projekt: Welche NOTE bekommt meine Architektur?

Der Abnahmetermin für die Software steht bevor und das Review der Softwarearchitekturen sorgt für schlaflose Nächte. Eine Architekturbewertung soll durchgeführt werden um die Stärken und Schwächen der Softwarearchitektur zu ermitteln. Wurden die relevanten Qualitätsmerkmale erfüllt und alle Ziele erreicht?

Grundlegend geht es bei der Architekturbewertung darum, herauszufinden, ob eine Softwarearchitektur die in sie gesetzten Erwartungen erfüllt oder nicht. Was sind die Stärken und Schwächen einer Architektur und welche Risiken und Probleme ergeben sich daraus?

Als Vergleich zur Softwarearchitekturbewertung nehmen wir einmal die Bewertung von sportlichen Leistungen. Genau wie bei der Softwarearchitektur lassen sich auch sportlichen Leistungen je nach Disziplin mehr oder weniger gut beurteilen. Wer läuft schneller? Wer springt höher? Wer wirft weiter? Wer schießt mehr Tore?  Diese Fragen sind noch einfach zu beantworten. In der Softwarearchitektur sind die Fragen natürlich ein wenig anders: Wie viele gefundene Fehler gibt es pro Paket? Wie hoch ist der Resscourcenverbrauch? Wie viel Zeit wird für die Verarbeitung bestimmter Funktionen oder Anwendungsfälle benötigt?

Doch nicht alle Fragen sind immer so leicht zu beantworten. Die Bewertung von Turniertänzern oder Eiskunstläufern ist schon etwas komplizierter und lässt sich nicht nach einfachen Zahlen bemessen, sondern funktioniert nach einem komplizierten Schema. Die Qualität entscheidet!

Wie ist das nun in der Softwarearchitektur? Gibt es hier sowas wie Messlatten und Schiedsrichter? Wie sieht hier das Ergebnis aus? Im Sport ist das klar: Der Gewinner bekommt die Goldmedaille.

  • Wie zuverlässig läuft das System?
  • Wie sicher ist das System?
  • Kann die Software ihr Leistungsniveau unter festgesetzten Bedingungen über einen bestimmten Zeitraum aufrechterhalten?
  • Wie sparsam ist die Software zur Lösung eines festgelegten Problems bezüglich der Ressourcen, Zeitverhalten bei Anfragen und Bearbeitungen sowie Speicherplatz?
  • Wie hoch ist der Aufwand zur Fehlerbeseitigung, zur Umsetzung von Verbesserungen oder zur Anpassung an Umgebungsveränderungen?
  • Ist die Software auch auf anderen Systemen (Hard- und Software) einsetzbar?

In der Softwarearchitektur gibt es verschiedene Methoden und Werkzeuge, die zu unterschiedlichen Zeitpunkten eingesetzt werden können. Bei der Bewertung einer Architektur gibt es jedoch zwei Ansätze: der qualitative Ansatz und der quantitative Ansatz.

Qualitativer Ansatz zur Architekturbewertung

Der qualitative Ansatz ermöglicht eine Bewertung nach Beschaffenheit oder Güte der Softwarearchitektur und hilft frühzeitig Risiken zu identifizieren, die die Erreichung der Qualitätsziele gefährden können. Ein Qualitätsmodell (wie z.B. ISO 25010) kann verwendet werden. Das ISO Modell definiert acht Qualitätsmerkmale: Benutzbarkeit, Effizienz, Funktionale Eignung, Kompatibilität, Sicherheit, Übertragbarkeit, , Wartbarkeit und Zuverlässigkeit.

Die qualitative Bewertung sollte jedoch regelmäßig und so früh wie möglich stattfinden. Eine der führenden Methoden im Bereich der Softwarearchitekturbewertung ist ATAM. ATAM seht für Architecture Tradeoff Analysis Method und bezeichnet eine Szenario-basierte Methode zur Bestimmung der Stärken, Schwächen und den getroffenen Kompromissen einer Softwarearchitektur. Ein ATAM-Workshop dauert in der Regel 3 – 4 Tage und wird gemeinsam mit den Stakeholdern durchgeführt.

Quantitativer Ansatz zur Architekturbewertung

Der quantitative Ansatz ist eine Bewertung der Artefakte in Zahlen und kann helfen, kritische Teile innerhalb von Systemen zu identifizieren. Im Gegensatz zur qualitativen Bewertung liefert sie keine Aussage über die Funktionsfähigkeit der Software. Zur Bewertung wird eine Reihe von Messungen und Metriken verwendet, wie beispielsweise die Anzahl der geänderten Anforderungen pro Zeiteinheit, die Anzahl der Testfälle, die Anzahl der gefundenen Fehler pro Paket, die Anzahl der neuen Codezeilen oder die Zyklomatische Komplexität. Der Vorteil ist, dass die Messungen automatisierbar sind und leicht wiederholt werden können. Es besteht jedoch auch die Gefahr von Missdeutungen, da ein fachlicher und technischer Kontext benötigt wird, um vergleichbar zu sein. Gesammelte Daten aus Vergleichsprojekten können hierbei hilfreich sein.

Insgesamt gesehen ist die Architekturbewertung ein wichtiges Hilfsmittel zur Bestimmung der Qualität einer Software bei der es aber weniger darum geht die Architektur zu benoten, sondern eher mehr Durchblick zu bekommen.

Architekturbewertung nach ISAQB AWERT

Die iSAQB-zertifizierte Weiterbildung Architekturbewertung vermittelt den Schulungsteilnehmern das notwendige Wissen und die Fähigkeiten, um Softwarearchitekturen bewerten zu können. Ziel ist die Beantwortung der Frage: Wie findet man heraus, ob eine Architektur die Erwartungen erfüllt?

Weiterführende Links:

Training “iSAQB Architekturbewertung (AWERT)”

Unter den Wolken – Infrastrukturen für die Cloud

Unter den Wolken – Infrastrukturen für die Cloud

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. Auch hier in unserem Blog hatten wir das Thema Microservices bereits mehrfach aufgegriffen (z.B. hier: https://www.itech-progress.com/microservices-und-bounded-contexts-perfekte-ehe-oder-ungleiches-paar/ oder hier: https://www.itech-progress.com/ueberlegen-zerlegen-softwarearchitektur-mit-der-flex/). 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, das für Native Cloud Application steht.

NCAs 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“ bedeutet, dass man mindestens eine zusätzliche Ressource als Backup für den Notfall hat. 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 Backup 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.

 

Seit Juli 2018 gibt es beim iSAQB ein neues Modul mit dem Namen CLOUDINFRA.

Das Modul beschäftigt sich mit den Themen Infrastruktur, Container und Cloud Native und mit der Frage: “Wie konzipiert und implementiert man anpassungsfähige Infrastrukturen für die Cloud?”.

Im Modul CLOUDINFRA geht es jedoch nicht nur um die Gründe für den Betrieb und die Vor- und Nachteile einer Cloud. Die Teilnehmer lernen die Grundlagen moderner Infrastrukturen, wie z.B. die unterschiedlichen *aaS Begriffe, Microservice-Architekturen, Container und verteilte Anwendungen.

Über die gängigsten Architekturkonzepte, hier im speziellen Microservices und Self-contained Systems geht es zu einer Reise in die Tiefen des Cloud-Native-Konzepts. Den Abschluss bilden hilfreiche Patterns und alles Wichtige über Development, CI/CD (Continuous Integration und Continuous Delivery) und Betrieb.

Folgen Sie uns auf Twitter und diskutieren Sie diesen Beitrag mit uns. Hier geht’s zu unserem Profil.

Weiterführende Links:

Training “iSAQB Infrastruktur, Container und Cloud Native (CLOUDINFRA)”

TRANSFORMER: Vom Häuslebauer zum Stadtplaner

TRANSFORMER: Vom Häuslebauer zum Stadtplaner

Stellen Sie sich vor, Sie sind verantwortlicher Architekt für ein Haus. Dort haben Sie dafür zu sorgen, dass das Haus nach den Wünschen und Zeitplänen des Auftraggebers und gemäß der Baugenehmigung gebaut wird und an die entsprechende Energie- und Verkehrsinfrastruktur angeschlossen werden kann. Und jetzt stellen Sie sich vor Sie sind Architekt für einen ganzen Stadtteil oder gar eine ganze Stadt mit all ihren Anforderungen an Infrastruktur, Städteplanung und Gesetzesvorgaben. Diese Stadtplanungsaufgabe ist natürlich viel größer und weitreichender als der Bau eines einzelnen Gebäudes. Dieser kleine Vergleich soll Ihnen anschaulich den Unterschied zwischen einem Software-Architekt, der seine Applikation erstellt, und dem Enterprise-Architekten zeigen, der eher stadtplanerisch unterwegs ist. Das Enterprise Architecture Management (EAM) gibt dem Enterprise-Architekten Hilfsmittel zur Hand um dieser gewaltigen Aufgabe gewachsen zu sein.

Was ist das eigentlich eine Unternehmensarchitektur?

Der Enterprise-Architekt ist für die Entwicklung und Pflege der Enterprise-Architektur eines Unternehmens verantwortlich. Unter Unternehmensarchitektur versteht man die gemeinsame Betrachtung der IT-Architektur und der Business-Architektur. Der Unternehmensarchitekt pflegt einen Unternehmens-Stack, der aus mehreren Schichten besteht. In der untersten Schicht befindet sich die IT mit all ihrer Hardware-Infrastruktur, den Servern und Netzen in denen die Legacy-Hardware betrieben wird. Also kurz: alles was man anfassen kann. In der zweiten Ebene befindet sich die Software mit all ihren Applikationen und der im Unternehmen betriebenen Middleware. In der dritten Schicht folgt die Welt der Daten und Geschäftsfunktionen und in der vierten Schicht liegen die die Geschäftsprozesse, die das eigentliche Business eines Unternehmens ausmachen. Auf den Geschäftsprozessen werden schließlich dann die Produkte des Unternehmens realisiert.

Der Umbau ist eine Herausforderung

Wie bei einer echten Stadt, muss sich auch der Unternehmens-Stack weiterentwickeln. Ein solcher Umbau ist dann eine echte Herausforderung. Oftmals wird zunächst versucht eine der Schichten zu transformieren. So versucht man z.B. durch Konsolidierung der Hardware-Landschaft die gewachsene IT-Architektur zu modernisieren. Doch diese ist meist sehr eng mit der Applikationsschicht verkoppelt, so dass ein einfacher Austausch schwierig ist. Ganz mutige Unternehmen erstellen ganz neue Geschäftsprozesse und nehmen es in Kauf, dass dabei ältere Produkte nicht mehr bedient werden können.

Der Unternehmensarchitekt als Transformator

Jetzt kommt der Enterprise-Architekt ins Spiel. Dieser versteht jede Ebene des Unternehmens-Stacks und schafft es mit Hilfsmitteln aus dem Enterprise Architecture Management eine ganzheitliche Unternehmenstransformation durchzuführen. Am Ende stehen aufgeräumte Geschäftsprozesse mit passenden Daten, weniger Applikationen und eine moderne zukunftsfähige IT-Infrastruktur. Das Wissen für eine komplexe Aufgabe wie das Enterprise Architecture Management (EAM) zu erlangen ist zeitaufwändig. Im Rahmen der ISAQB-Zertifizierung bietet die ITECH-PROGRESS GmbH daher eine dreitätige Schulung an.

ISAQB Enterprise Architecture Management (EAM)

Die iSAQB-zertifizierte Schulung Enterprise Architecture Management vermittelt den Schulungsteilnehmern das notwendige Wissen und die Fähigkeiten, um EAM für mittlere und große Systeme ein- und durchzuführen. Am Ende dieser Schulung haben Sie das Rüstzeug, um eine IT-Strategie für ein Unternehmensarchitektur zu formulieren, Prozesse und Strukturen der IT-Governance einzurichten und zu überwachen und Migrationspläne für die IT-Landschaft abzuleiten. Im Lauf der Weiterbildung lernen die Teilnehmer verschiedene Frameworks wie TOGAF und COBIT kennen.

Folgen Sie uns auf Twitter und diskutieren Sie diesen Beitrag mit uns. Hier geht’s zu unserem Profil.

Weiterführende Links:

Training “iSAQB Enterprise Architecture Management (EAM)”

Microservices und Bounded Contexts: Perfekte Ehe oder ungleiches Paar?

Microservices und Bounded Contexts: Perfekte Ehe oder ungleiches Paar?

Microservices und Domain Driven Design (DDD) zählen nach wie vor zu den Hype-Themen der IT-Szene. Ein paar Sekunden Google-Suche reichen aus, um gleich dutzende Artikel ausfindig zu machen, die wahre Loblieder auf die „Liebesbeziehung“ von Microservices und Bounded Contexts singen. Aber ist das wirklich so? Bilden Microservices und Bounded Contexts die perfekte Ehe oder wird das Thema vielleicht doch zu sehr durch die rosa Brille findiger Consultants betrachtet?

Domain Driven Design ist als ein Konzept entstanden, um die Distanz zwischen den Domänen-Experten und dem Software-Entwicklungsteam und die daraus resultierenden Projektrisiken nachhaltig zu verringern. Eric Evans hat das in seinem Standardwerk „Domain-Driven Design: Tackling Complexity in the Heart of Software“ präzise beschrieben. Ein zentrales Element ist dabei eine gemeinsame Fachsprache, die „Ubiquitous Language“, die aus der Domänen-Story entwickelt und auf allen Ebenen, vom Grobkonzept bis in den Quellcode hinein, angewendet wird. In den meisten Fällen zeigen sich bei der Herleitung der Domain-Story einige Begriffe, die in unterschiedlichen Zusammenhängen (z.B. Abteilungen) andere Bedeutungen haben. Im Domain Driven Design wird in diesem Fall keine sprachliche Lösung geschaffen, sondern eine Grenze um den maximalen Raum innerhalb der Domäne gezogen, in dem jeder Fachbegriff eine einzige, eindeutige Bedeutung hat. Dieser abgegrenzte „Sprachraum“ ist der Bounded Context.

Aus dieser Perspektive wird klar, dass ein Bounded Context – je nach Komplexität der Domäne – ganz unterschiedliche Dimensionen annehmen kann. Die Spanne erstreckt sich von einem sehr kleinen Kontext, der sich durchaus zur Abgrenzung eines Microservice eignen kann, bis hin zu einem gewaltigen, als Microservice untauglichen Kontext-Monolithen. In den meisten Fällen sind Microservice und Bounded Context folglich ein ausgesprochen ungleiches Paar. Der Bounded Context beschreibt die maximale Ausdehnung, die ein Microservice logisch annehmen kann und steht damit geradezu im Widerspruch zu dessen Anforderungen an reduzierte Komplexität und Größe.

Woher rührt dann also der Hype? Nun, zum einen sind Bounded Contexts eine Möglichkeit, erste Schnitte im Projekt anzusetzen und bieten damit zumindest eine Annäherung. Zum anderen ist jeder Bounded Context ein Cluster, in dem mehrere zu definierende (Micro-)Services durch die Ubiquitous Language logisch verbunden sind. Auch das kann bis hin zur Evolution der Microservice-Landschaft eine Menge Vorteile bringen.

Für die Microservices selbst und deren Abgrenzung stellt Domain Driven Design das Konzept der internen Bausteine (Internal Building Blocks) mit vielen nützlichen Patterns zur Verfügung. Das vielleicht wichtigste dabei sind die Aggregates, die als kleinste sinnvolle Einheit für einen Microservice sozusagen den Gegenpol zu den Bounded Contexts bilden.

Anhand dieser Betrachtungen lassen sich die Ausgangsfragen klar beantworten: „Die perfekte Ehe“ lässt sich auf der Ebene von Microservices und Domain Driven Design schließen. Bounded Contexts sind für diesen Bund ein wertvoller Beitrag – unter vielen anderen.

Einen tieferen Einblick in Microservice-Architekturen und Domain Driven Design vermittelt das Trainings-Doppelpack „Flexible Architekturmodelle (FLEX)“ und „Domain Driven Design (DDD)“ der ITech Academy.

Weiterführende Links:
Training „iSAQB Domain Driven Design (DDD)“
Training „iSAQB Flexible Architekturmodelle (FLEX)“

 


Bildrechte (Montage):
Halfaral [CC BY-SA 3.0], von Wikimedia Commons

Der stille Erfolgsfaktor agiler Teams.

Der stille Erfolgsfaktor agiler Teams.

Softwareentwicklung in agilen Teams stellt hohe Anforderungen an jedes einzelne Teammitglied. Während den fachlichen Qualitäten für gewöhnlich die höchste Aufmerksamkeit gewidmet wird, fallen die „weichen“ Faktoren naturgemäß mit schöner Regelmäßigkeit unter den Tisch. Das ist gleich aus mehreren Gründen paradox: Scrum dient nicht in erster Linie der Verwaltung von Tasks und deren termingerechter Umsetzung, sondern der Organisation des Teams, das mit der Umsetzung betraut ist. Das bringt zwangsläufig den Faktor „Mensch“ ins Spiel. Im „Daily Scrum“ bleiben oft nicht mehr als zehn Minuten, um die Befindlichkeit der Kollegen, schwelende Konflikte und Unstimmigkeiten im Team zu erfassen. Wer hier nicht eine gehörige Portion Empathie mitbringt, kann schnell mit Problemen konfrontiert werden.
Nicht minder schwierig kann die Situation werden, wenn im Zuge von Continuous Delivery die Grenzen zwischen Entwicklung und Betrieb verwischen oder im Sinne von DevOps komplett aufgehoben werden. Kollegen, die bisher in strikt getrennten „Silos“ ihren Dienst am Projekt leisteten, müssen nun plötzlich und unerwartet Seite an Seite agieren. Eine vergleichbare Szenerie kann entstehen, wenn Entwickler aus ihrem Einzelkämpferdasein in die Paar-Programmierung gelotst werden. In beiden Fällen ist Konfliktpotenzial vorprogrammiert und will erkannt und moderiert werden.
Persönliche Probleme einzelner, offene oder schwelende Konflikte im Team, Missverständnisse durch mangelnde Kommunikation: Das Erkennen und Beseitigen dieser und vergleichbarer Zustände ist für den Projekterfolg ebenso entscheidend wie die fachliche Qualität. Was ein bloß funktionierendes von einem erfolgreichen agilen Team unterscheidet, sind deshalb oft genug die stillen Erfolgsfaktoren, die Soft Skills. Das beginnt bei der sorgfältigen Zusammenstellung des Teams. Aber es lässt sich auch in laufenden Projekten weiter steuern und verbessern.
Mitarbeiter – ob Entwickler oder CEO – kann man in ihren grundlegenden menschlichen Eigenschaften nicht verändern, aber darum geht es auch nicht. Trainierte Soft Skills schärfen das Bewusstsein für kommunikative Situationen, verbessern das Gesprächsverhalten und erhöhen die Sensibilität für Zwischenmenschliches. Allein das kann das Teamplay schon entscheidend verbessern.
Das beiden Trainings Soft Skills für Softwarearchitekten und Agile Softwarearchitektur nach iSAQB-Standard genießen an der ITech Academy einen hohen Stellenwert. Zahlreiche Unternehmen aus unterschiedlichsten Branchen lassen jeden neuen IT-Mitarbeiter in einem offenen Training an der Academy schulen oder holen sich einen Trainer für eine Inhouse-Schulung ins Haus.

Für weitere Informationen:

iSAQB Soft Skills für Softwarearchitekten
iSAQB Agile Softwarearchitektur
Inhouse-Trainings

Continuous Delivery – Der Architekt als Speedmaster

Continuous Delivery – Der Architekt als Speedmaster

Sind es nicht faszinierende Zeiten, in denen ein einzelnes Feature Milliarden an Börsenwert produzieren oder über Nacht vernichten kann? Den Trend, in dem wir uns aktuell bewegen, wurde in einem Vortrag im Rahmen des “Architecture Gathering 2018” unlängst beschrieben: Wir befinden uns in der post-industriellen Ära der hochdynamischen, globalen Märkte und disruptiven Veränderungen. Im Fokus stehen dabei weniger die Entwicklungskosten. Time-to-Market ist der entscheidende Erfolgsfaktor. Wer zuerst kommt und den nächsten Hype inszeniert, hat die besten Chancen auf das große Geschäft.

In der Softwareentwicklung ist Geschwindigkeit längst keine Hexerei mehr. Immer höhere Automatisierungsgrade und ein verändertes Prozessdesign ermöglichen Performancesprünge, die noch vor wenigen Jahren undenkbar schienen. Der Softwarearchitekt ist dabei der zentrale „Driver“, sozusagen der Speedmaster im Projekt. Mit seinem Architekturkonzept steuert er nahezu alle relevanten Parameter, um ein Projekt auf seine Anforderungen auszurichten. Wenn Time-to-Market die Priorität hat, sind flexible Architekturmodelle und Continuous Delivery zumeist die erste Wahl. Erstere schaffen mit weitgehend autarken Komponenten bis hin zu Microservices die Voraussetzungen, um effizient zu entwickeln und über die Continuous Delivery Pipeline fortlaufend zu liefern. Aber schauen wir uns das einmal genauer an.

Ein erster Blick auf Continuous Delivery

Continuous Delivery – kurz „CD“ genannt – beschreibt eine Sammlung von Techniken, Prozessen und Werkzeugen, mit deren Hilfe kurze Entwicklungszyklen und die schnelle Auslieferung von Software-Updates oder produktiven Endsystemen ermöglicht werden. CD zielt darauf ab, jede Entwicklung oder Änderung im Code sofort in eine mehrstufige, weitgehend automatisierte Test-Pipeline zu übergeben und nach erfolgreichem Durchlauf mit dem nächsten Deployment produktiv zu stellen. Typischerweise werden bei den Tests drei Phasen unterschieden: Eine Commit Stage, auf der die Software gebaut und die Unit-Tests durchgeführt werden, eine Accaptance Test Stage für die Integrations-, Akzeptanz- und Systemtests sowie eine dritte Phase, in der gegebenenfalls manuelle Tests und ein Freigabeprozess stattfinden können. Für jede Phase gilt das Prinzip „Stop-the-line“: Bei Ermittlung eines Fehlers wird die Test-Pipeline angehalten, bis das Problem behoben ist. Der Entwickler erhält umgehend Feedback. So können Fehler frühzeitig entdeckt und beseitigt werden.

Continuous Delivery und DevOps

In der Konsequenz durchläuft jeder Softwarestand zigmal die Test-Pipeline und muss entsprechend zigmal auf einer Testumgebung installiert werden. Traditionell liegt die Installation für den Test im Aufgabenbereich des Betriebs. Wie soll sich das in der Praxis darstellen lassen? Betrieb und Entwicklung müssen die Konfiguration der Anwendung und die Deployments in so enger Abstimmung planen, dass eine Trennung der Abteilungen nicht länger gegeben ist. DevOps, die Zusammenlegung von Development und Operations, ist tatsächlich eine notwendige Konsequenz, wenn die Umsetzung von Continuous Delivery zum Erfolg führen soll.

Der Softwarearchitekt im Lead

Wenn wir die angesprochenen Themen zusammennehmen, ist der Softwarearchitekt der einzige im Bunde, der gleichzeitig über die Kompetenz verfügt und frei ist von Interessenskonflikten. Allein deshalb bringt es viele Vorteile, Design und Überwachung von Continuous Delivery Projekten im Aufgabenbereich erfahrener Architekten anzusiedeln. Wir haben gesehen, dass die Konzeption von Continuous Delivery unmittelbar abhängig vom Architekturmodell ist. Der Architekt kann Continuous Delivery also im Flow des Gesamtkonzepts entwickeln – auch das ist ein Argument. Weiterhin ist die Perspektive des Architekten auf die Test-Szenarien naturgemäß weniger Tool-getrieben und er kann aufkommende Konflikte von Entwicklung und Betrieb aus dem Konzept heraus moderieren.

Ein Aufwand, der sich lohnen sollte

Mit Continuous Delivery erweitern Softwarearchitekten ihren Kompetenzbereich um ein Thema, mit dem sie punkten können: Speed! Der Entwickler profitiert von unmittelbarem Feedback aus der Test-Pipeline, von der Verringerung des Risikos in der Entwicklung und einer drastischen Verkürzung der Zeit bis zur Produktivstellung. Neue Features können innerhalb weniger Tage zum Anwender gebracht und bei Bedarf mit Varianten ausgetestet werden. So lassen sich auch höchste Anforderungen an die Time-to-Market erfüllen.

Die wichtigsten Grundlagen und Tools rund um Continuous Delivery sind Teil unseres Trainings „Evolution und Verbesserung von Softwarearchitekturen (IMPROVE)“ auf iSAQB Advanced-Level. Folgen Sie uns auf Twitter und diskutieren Sie diesen Beitrag mit uns. Hier geht’s zu unserem Profil.

Nächstes Training: 05.-07. März 2019 in Ludwigshafen
Weitere Infos: www.itech-progress.com/isaqb-improve/

 


1 Quelle: Uwe Friedrichsen, „Life after Microservices“, zum Artikel auf Slideshare hier klicken