isaqb-org · anjakammer · Apr 4, 2024 · Mar 6, 2024 · Mar 6, 2024 · Mar 6, 2024
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -8,11 +8,13 @@
 - DevOps, DevSecOps, and SRE
 - Abstraction Layers of Container Managers
 
-## Added/Changed wording
+## Naming concepts more explicitly
 
 - Chaos engineering
 - Eventual consistency
 - Platform quality requirements
+- Serverless
+- Functions as a Service (FaaS)
 
 ## Removed
 - Mentioning of tool names for automation and operation (Ansible, Chef, Terraform, Rancher, Tectonic, Kops, Kubeadm, OpenShift)

diff --git a/docs/01-Fundamentals-of-Modern-Infrastructures/01-duration-terms.adoc b/docs/01-Fundamentals-of-Modern-Infrastructures/01-duration-terms.adoc
@@ -4,7 +4,7 @@
 |===
 
 === Begriffe und Konzepte
-Cloud, Cloud-Arten, Cloud-Anbieter, On Premise, Bare Metal, Cloud Service Modelle (*aaS), Vendor Lock-in, Managed Services, Cloud Native Services, Cloud-Muster, Cloud-Migrationsmuster, Multi/Hybrid Cloud, Organisatorische Aspekte der Cloud Migration, Rechtliche Rahmenbedingungen, Time-to-Market, Verfügbarkeit, Skalierung, Geo Redundanz und Skalierung, Performance, IOPS, Decoupling Operations, Networking.
+Cloud, Cloud-Arten, Cloud-Anbieter, On Premise, Bare Metal, Cloud Service Modelle (*aaS), Vendor Lock-in, Managed Services, Serverless Computing, Cloud Native Services, Cloud-Muster, Cloud-Migrationsmuster, Multi/Hybrid Cloud, Organisatorische Aspekte der Cloud Migration, Rechtliche Rahmenbedingungen, Time-to-Market, Verfügbarkeit, Skalierung, Geo Redundanz und Skalierung, Performance, IOPS, Decoupling Operations, Networking.
 
 // end::DE[]
 
@@ -14,7 +14,7 @@ Cloud, Cloud-Arten, Cloud-Anbieter, On Premise, Bare Metal, Cloud Service Modell
 |===
 
 === Terms and Principles
-Cloud, cloud types, cloud provider, on premise, bare metal, cloud service models (*aaS), vendor lock-in, managed services, cloud native services, cloud patterns, cloud migration patterns, multi/hybrid cloud, organizational aspects of cloud migration, legal conditions, time-to-market, availability, geo redundancy and scalability, performance, IOPS, decoupling operations, networking.
+Cloud, cloud types, cloud provider, on premise, bare metal, cloud service models (*aaS), vendor lock-in, managed services, serverless computing, cloud native services, cloud patterns, cloud migration patterns, multi/hybrid cloud, organizational aspects of cloud migration, legal conditions, time-to-market, availability, geo redundancy and scalability, performance, IOPS, decoupling operations, networking.
 // end::EN[]
 
 

diff --git a/docs/01-Fundamentals-of-Modern-Infrastructures/02-learning-goals.adoc b/docs/01-Fundamentals-of-Modern-Infrastructures/02-learning-goals.adoc
@@ -15,7 +15,9 @@ Sie verstehen den Unterschied zwischen Cloud- und On-Premise-Betrieb sowie die A
 
 Softwarearchitekt:innen kennen unterschiedliche Cloud Service Modelle (*aaS) und können Services anhand dieser Modelle klassifizieren.
 
-Sie verstehen das Shared-Responsibility-Modell und dessen Relevanz für Kosten- und Risikobewertungen bei der Nutzung von managed Cloud Services.
+Sie verstehen darüber hinaus das Serverless Computing Konzept und können es den Cloud Service Modellen zuordnen.
+
+Softwarearchitekt:innen verstehen das Shared-Responsibility-Modell und dessen Relevanz für Kosten- und Risikobewertungen bei der Nutzung von managed Cloud Services.
 
 Sie kennen das Konzept des Vendor Lock-in und seine Relevanz für die Entscheidungsfindung zwischen managed und self-managed Services.
 
@@ -56,7 +58,9 @@ They understand the difference between cloud and on-premise operations, as well
 
 Software architects know different cloud service models (*aaS) and can classify services based on these models.
 
-They understand the shared responsibility model and its relevance for cost and risk assessments when using managed cloud services. 
+They also understand the serverless computing concept and can assign it to the cloud service models.
+
+Software architects understand the shared responsibility model and its relevance for cost and risk assessments when using managed cloud services.
 
 They know the concept of vendor lock-in and its relevance for decision-making between managed and self-managed services.
 

diff --git a/docs/04-Patterns/01-duration-terms.adoc b/docs/04-Patterns/01-duration-terms.adoc
@@ -4,7 +4,7 @@
 |===
 
 === Begriffe und Konzepte
-Resilienz Muster, Container Application Design, Cloud Native Architekturen, Container Pattern, Service Mesh
+Resilienz Muster, Container Application Design, Cloud Native Architekturen, Container Pattern, Functions as a Service (FaaS), Service Mesh
 
 // end::DE[]
 
@@ -14,7 +14,7 @@ Resilienz Muster, Container Application Design, Cloud Native Architekturen, Cont
 |===
 
 === Terms and Principles
-Resilience Patterns, Container Application Design, Cloud Native Architectures, Container Patterns, Service Mesh
+Resilience Patterns, Container Application Design, Cloud Native Architectures, Container Patterns, Functions as a Service (FaaS), Service Mesh
 
 // end::EN[]
 

diff --git a/docs/04-Patterns/02-learning-goals.adoc b/docs/04-Patterns/02-learning-goals.adoc
@@ -19,7 +19,20 @@ Softwarearchitekt:innen kennen Methoden, um technische von fachlichen Aufgaben d
 * Container Management durch Operator bzw. Controller
 
 [[LZ-4-2]]
-==== LZ 4-2: Passende Resilienzmuster zur Erhöhung von Fehlertoleranz auswählen
+==== LZ 4-2: Passende Technologien für den Betrieb von Modulen auswählen
+
+Softwarearchitekt:innen können geeignete Technologien zum Betrieb von Modulen eines verteilten Systems auswählen, z.B. mit Functions as a Service (FaaS) und Container Orchestrierung.
+
+Darüber hinaus können Sie die Anwendung dieser Technologien Anforderungsgetrieben anwenden. Dabei gibt es verschiedene Aspekte zu beachten wie:
+
+* Skalierungsanforderungen
+* Start- und Ausführungszeit
+* Komplexität des Betriebs und fachlichen Schnitts
+* Zugriff auf Persistenz
+* Limitierungen für Observability und Debugging
+
+[[LZ-4-3]]
+==== LZ 4-3: Passende Resilienzmuster zur Erhöhung von Fehlertoleranz auswählen
 
 Softwarearchitekt:innen verstehen, wie bei einer verteilten Anwendung die Kommunikation zwischen den Services fehlertolerant realisiert werden kann.
 
@@ -54,7 +67,20 @@ Software architects are familiar with methods for separating technical and busin
 * Container management through operators or controllers
 
 [[LG-4-2]]
-==== LG 4-2: Ability to Select Appropriate Resilience Patterns to Increase Fault Tolerance
+==== LG 4-2: Ability to Select Suitable Technologies for Operating Modules
+
+Software architects can select suitable technologies for operating modules of a distributed system, e.g. with Functions as a Service (FaaS) and container orchestration.
+
+They select these technologies in a requirements-driven manner. Various aspects must be taken into account, such as
+
+* Scaling requirements
+* Start and runtime duration
+* Complexity of operation and domain boundaries
+* Access to persistence
+* Limitations on observability and debugging
+
+[[LG-4-3]]
+==== LG 4-3: Ability to Select Appropriate Resilience Patterns to Increase Fault Tolerance
 
 Software architects understand how communication between services in a distributed application can be made fault-tolerant.