02-learning-goals.adoc

{learning-goals}

LZ 1-1: Qualitätsziele von flexiblen Architekturen

Architekturen können auf unterschiedliche Qualitätsziele hin optimiert werden.

In diesem Modul lernen die Teilnehmer, wie sie Architekturen erstellen, die schnelles Deployment und damit schnelles Feedback aus der Anwendung des Systems erlauben. Solche Architekturen unterstützen die Entwickler:innen dabei, effizient funktionale Angemessenheit zu erreichen und die Usability zu verbessern. Außerdem fördern sie die Modularität und können dazu dienen, hohe Zuverlässigkeit zu erreichen und einzelne Komponenten isoliert zu ersetzen, was der Flexibilität dient.

LZ 1-2: Wechselwirkung von Architektur-Typen und Organisation

Sie haben die Treiber für die Architektur-Typen verstanden, die in diesem Lehrplanmodul vermittelt werden - also das Bedürfnis, Features schnell in Produktion zu bringen und Time-to-Market zu verkürzen. Sie haben außerdem verstanden, welche Konsequenzen die Treiber für die Architekturen haben und wie die Wechselwirkung der Architekturen mit Organisation, Prozessen und Technologien ist.

LZ 1-3: Kompromisse der vorgestellten Architektur-Typen vermitteln und adaptieren

Sie haben die Kompromisse der vorgestellten Architektur-Typen (mindestens Microservices, Self Contained Systems und Deployment Monolithen) verstanden und können diese sowohl vermitteln als auch im Rahmen konkreter Projekte/Systementwicklungen anwenden, um angemessene Architekturentscheidungen zu treffen.

LZ 1-4: Verständnis für Rahmenbedingungen von verteilten Systemen

Teilnehmer sollen Rahmenbedingungen von verteilten Systemen verstehen, wie z. B. folgende:

• Auf die Fähigkeit, neue Features schnell in Produktion bringen zu können, hat die Architektur entscheidenden Einfluss.

• Abhängigkeiten zwischen Komponenten, die von unterschiedlichen Entwicklungsteams verantwortet werden, beeinflussen die Dauer, bis Software in Produktion gebracht werden kann, weil sie die Kommunikationsaufwände erhöhen und sich Verzögerungen fortpflanzen.

• Die Automatisierung von Aktivitäten (wie z. B. Test- und Deployment-Prozesse) erhöht die Reproduzierbarkeit, Vorhersagbarkeit und Ergebnisqualität dieser Prozesse. Das kann zu einer Verbesserung des gesamten Entwicklungsprozesses führen.

• Die Vereinheitlichung der verschiedenen Umgebungen (z. B. Entwicklung, Test, QA, Produktion) reduziert das Risiko von spät entdeckten und (in anderen Umgebungen) nicht reproduzierbaren Fehlern aufgrund unterschiedlicher Konfigurationen.

• Die Vereinheitlichung und Automatisierung sind wesentliche Aspekte von Continuous Delivery.

• Continuous Integration ist eine Voraussetzung für Continuous Delivery.

• Eine geeignete Architektur ist die Voraussetzung für eine Parallelisierbarkeit der Entwicklung sowie die unabhängige Inbetriebnahme von eigenständigen Bausteinen. Das können, müssen aber nicht „Services“ sein.

• Einige Änderungsszenarien lassen sich leichter in monolithischen Architekturen umsetzen. Andere Änderungsszenarien lassen sich leichter in verteilten Service-Architekturen umsetzen. Beide Ansätze können kombiniert werden.

• Es gibt unterschiedliche Arten der Isolation mit jeweils unterschiedlichen Vorteilen. Beispielsweise kann der Ausfall auf eine Komponente begrenzt werden oder Änderungen können auf eine Komponente begrenzt werden.

• Bestimmte Arten der Isolation sind zwischen Prozessen mit Remotekommunikation deutlich einfacher umzusetzen.

• Eine geeignete Architektur kann Komponenten dahingehend voneinander isolieren, dass ein Ausfall auf eine Komponente begrenzt wird.

• Eine solche Architektur ist durch Prozesse mit Remotekommunikation deutlich einfacher umzusetzen.

• Remotekommunikation hat aber Nachteile – z. B. viele neue Fehlerquellen.

LZ 1-5: Themen und Buzzwords einordnen

• Gesetz von Conway

• Partitionierbarkeit als Qualitätsmerkmal

• Durchlaufzeiten durch die IT-Wertschöpfungskette als Wettbewerbsfaktor

• Aufbau einer Continuous-Delivery-Pipeline

• Die verschiedenen Test-Phasen in einer Continuous-Delivery-Pipeline

LG 1-1: Quality goals of flexible architectures

Architectures can be optimised to meet different quality goals.

In this module participants learn how to develop architectures that allow fast deployment and fast feedback from using the system. Such architectures support developers in achieving functional suitability efficiently and improve usability. They also foster modularity and can serve to achieve high reliability und replace individual components in isolation, which serves flexibility.

LG 1-2: Interaction of architecture types and organisation

They have understood the drivers for the architecture types taught in this curriculum module - the desire to bring feature to production fast and reduce the Time-to-Market. They understood the implications of these drivers for the architectures, and the interaction of the architectures with the organisation, processes, and technologies.

LG 1-3: Communicating and adapting compromises of the presented architecture types

They have understood the trade-offs of the architecture types presented (at least Microservices, Self-Contained Systems and Deployment Monoliths) and are able to communicate them as well as apply them in the context of concrete projects / system developments in order to make appropriate architectural decisions.

LG 1-4: Understanding the constraints of distributed systems

Participants understand the constraints of distributed systems, such as the following:

• The architecture has crucial influence on the ability to quickly bring new features into production.

• Dependencies between components of different development teams influence the duration until software can be put into production because they increase the communication costs and delays are propagated.

• Automation of activities (such as test and deployment processes) increases the reproducibility, predictability, and quality of results of these processes. This can lead to an improvement of the overall development process.

• Unification of the different environments (e.g., development, test, QA, production) reduces the risk of lately detected and (in other environments) non-reproducible errors due to different configurations.

• Unification and automation are essential aspects of continuous delivery.

• Continuous integration is a prerequisite for continuous delivery.

• A suitable architecture is the prerequisite for the parallelization of the development as well as the independent commissioning of independent modules. This can, but do not have to be "services".

• Some change scenarios are easier to implement in monolithic architectures. Other change scenarios are easier to implement in distributed service architectures. Both approaches can be combined.

• There are different types of isolation with different advantages. A failure, for example, can be limited to a single component or changes can be limited to a single component.

• Certain types of isolation are much easier to implement between processes with remote communication.

• A suitable architecture can isolate components from each other such that a failure is restricted to a single component.

• Such an architecture is easier to implement via processes with remote communication.

• Remote communication, however, has disadvantages - for example many new sources of errors.

LG 1-5: Contextualizing topics and buzzwords

• Conway’s law

• Partitionability as a quality feature

• Round trip times with the IT supply chain as a competitive factor

• Building a continuous delivery pipeline

• The different test phases of a continuous delivery pipeline