Merge pull request #76 from isaqb-org/70-chapter-3-software-modules-a…

…nd-the-organisation-transform-and-enhance-to-new-learning-goal-structure

#70 new chapter 3 added

docs/01-motivation/02-learning-goals.adoc

@@ -23,17 +23,7 @@
 - Die Vorteile verschiedener Isolationsarten (Devtime, Runtime, Deployment, Team) bewerten
 
 [[LZ-1-3]]
-==== LZ 1-3: Wechselwirkung von Architekturtypen und Organisation analysieren und benennen
-
-- Erklären, wie Beziehungen zwischen Teams und Organisationseinheiten die Architektur von Systemen und damit Aspekte wie Abstimmungsaufwände und Time-to-Market beeinflussen
-- Erkennen, wie Conway's Law die Entwicklungsgeschwindigkeit beeinflusst
-- Den Zusammenhang zwischen Teamgrenzen und Systemgrenzen analysieren und erklären
-- Die Balance zwischen technischer und organisatorischer Struktur erklären
-- Unterschiede von Buildtime- und Runtime-Abhängigkeiten für Softwareentwicklungsprozesse erklären
-- Die Parallelisierbarkeit von Softwareentwicklungsaufgaben als Architekturziel verstehen
-
-[[LZ-1-4]]
-==== LZ 1-4: Kompromisse der vorgestellten Architekturtypen vermitteln und adaptieren
+==== LZ 1-3: Kompromisse der vorgestellten Architekturtypen vermitteln und adaptieren
 
 - Die Vor- und Nachteile verschiedener Architekturstile abwägen
 - Wissen, wie man Architekturentscheidungen dem Business-Kontext anpasst
@@ -43,8 +33,8 @@
 - Die Kosten von Verteilung und Service-Kommunikation realistisch einschätzen
 
 
-[[LZ-1-5]]
-==== LZ 1-5: Langfristige Qualitätsziele von flexiblen Architekturen benennen
+[[LZ-1-4]]
+==== LZ 1-4: Langfristige Qualitätsziele von flexiblen Architekturen benennen
 
 - Zentrale Qualitätsmerkmale flexibler Architekturen kennen
 - Verstehen, warum Flexibilität und schnelles Feedback strategische Ziele sind
@@ -54,8 +44,8 @@
 - Die Rolle von Reproduzierbarkeit und Vorhersagbarkeit verstehen
 - Automatisierbarkeit als Qualitätsziel erkennen
 
-[[LZ-1-6]]
-==== LZ 1-6: Typische Architekturentscheidungen von flexiblen Architekturen erklären und begründen
+[[LZ-1-5]]
+==== LZ 1-5: Typische Architekturentscheidungen von flexiblen Architekturen erklären und begründen
 
 - Architekturentscheidungen durch Businessziele und Qualitätsszenarien begründen
 - Die Notwendigkeit bestimmter Architekturmuster erklären
@@ -97,17 +87,7 @@
 - Evaluate benefits of different isolation types (devtime, runtime, deployment, team)
 
 [[LG-1-3]]
-==== LG 1-3: Analyze and Define the Interplay Between Architecture Types and Organization
-
-- Explain how relationships between teams and organizational units influence system architecture, affecting coordination overhead and time-to-market
-- Recognize how Conway's Law impacts development speed
-- Analyze and explain the correlation between team boundaries and system boundaries
-- Explain the balance between technical and organizational structure
-- Explain differences between buildtime and runtime dependencies in software development processes
-- Understand parallel software development capability as an architectural goal
-
-[[LG-1-4]]
-==== LG 1-4: Communicate and Adapt Trade-offs of Presented Architecture Types
+==== LG 1-3: Communicate and Adapt Trade-offs of Presented Architecture Types
 
 - Weigh advantages and disadvantages of different architectural styles
 - Know how to adapt architectural decisions to business context
@@ -116,8 +96,8 @@
 - Understand when combining different architectural styles makes sense
 - Realistically assess costs of distribution and service communication
 
-[[LG-1-5]]
-==== LG 1-5: Define Long-term Quality Goals of Flexible Architectures
+[[LG-1-4]]
+==== LG 1-4: Define Long-term Quality Goals of Flexible Architectures
 
 - Know core quality characteristics of flexible architectures
 - Understand why flexibility and rapid feedback are strategic goals
@@ -127,8 +107,8 @@
 - Understand the role of reproducibility and predictability
 - Recognize automation capability as a quality goal
 
-[[LG-1-6]]
-==== LG 1-6: Explain and justify Typical Architectural Decisions in Flexible Architectures
+[[LG-1-5]]
+==== LG 1-5: Explain and justify Typical Architectural Decisions in Flexible Architectures
 
 - Justify architectural decisions through business goals and quality scenarios
 - Explain the necessity of specific architectural patterns

docs/01-motivation/references.adoc

@@ -1,6 +1,6 @@
 === {references}
 
-<<humblecd>>, <<wolffcd>>, <<humbleacd>>
+<<wolffcd>>, <<humbleacd>>, <<fowler>>, <<takada>>
 
 
 

docs/02-modularization/02-learning-goals.adoc

@@ -17,27 +17,21 @@
 * Isolationsebenen: Unterschiede zwischen modularer Isolation im Code, in der Laufzeitumgebung und bei Netzwerkschnittstellen.
 
 [[LZ-2-3]]
-==== LZ 2-3: Kommunikationsstruktur der Organisation bei Zerlegung berücksichtigen
-
-* Conway’s Law: Bedeutung und Auswirkungen der Kommunikationsstruktur der Organisation auf die Wahl und Gestaltung von Modulgrenzen.
-* Autonomie und Zusammenarbeit: Sicherstellung der Entwicklungsautonomie durch modulare Schnitte entlang fachlicher Grenzen.
-
-[[LZ-2-4]]
-==== LZ 2-4: Modularisierungskonzepte bewerten und auswählen
+==== LZ 2-3: Modularisierungskonzepte bewerten und auswählen
 
 * Technische Modularisierung: Bewertung von Konzepten wie Dateien, Bibliotheken, Prozesse, Microservices oder Self-Contained Systems.
 * Integration und Kopplung: Analyse von Kopplungsebenen (Sourcecode, Kompilate, Netzwerkprotokoll) und deren Auswirkungen.
 * Qualitätsziele: Auswahl einer Modularisierung passend zu Anforderungen wie Parallelisierung der Entwicklung oder unabhängiges Deployment.
 
-[[LZ-2-5]]
-==== LZ 2-5: Modularisierungsstrategien bewerten
+[[LZ-2-4]]
+==== LZ 2-4: Modularisierungsstrategien bewerten
 
 * Strategien und Konsequenzen: Bewertung der Auswirkungen verschiedener Modularisierungsansätze, z. B. Monolith vs. verteilte Module.
 * Technologieabhängigkeit: Wie Modularisierungstechnologien (z. B. Container oder Laufzeitumgebungen) Strategien beeinflussen.
 * Aufwands-Nutzen-Abgleich: Abwägung organisatorischer und technischer Aufwände gegen die erwarteten Vorteile.
 
-[[LZ-2-6]]
-==== LZ 2-6: Aufwand und Nutzen von Modularisierungsstrategien gegenüberstellen
+[[LZ-2-5]]
+==== LZ 2-5: Aufwand und Nutzen von Modularisierungsstrategien gegenüberstellen
 
 * Integration vs. Dezentralisierung: Identifikation von organisatorischen und technischen Aufwänden  für die Integration modularer Systeme.
 * Erwartete Vorteile: Bewertung des Nutzens, wie etwa unabhängiges Deployment, Parallelisierung und verbesserte Verständlichkeit.
@@ -60,24 +54,19 @@
 * Levels of isolation: Differentiating modular isolation in code, runtime environments, and network interfaces.
 
 [[LG-2-3]]
-==== LG 2-3: Considering the communication structure of the organization during decomposition
-* Conway’s Law: Understanding the importance and impact of the organization’s communication structure on the choice and design of module boundaries.
-* Autonomy and collaboration: Ensuring development autonomy by aligning modular cuts with business boundaries.
-
-[[LG-2-4]]
-==== LG 2-4: Evaluating and selecting modularization concepts
+==== LG 2-3: Evaluating and selecting modularization concepts
 * Technical modularization: Assessing concepts such as files, libraries, processes, microservices, or self-contained systems.
 * Integration and coupling: Analyzing levels of coupling (source code, compile-time, network protocols) and their implications.
 * Quality goals: Choosing modularization approaches suitable for requirements like development parallelization or independent deployment.
 
-[[LG-2-5]]
-==== LG 2-5: Assessing modularization strategies
+[[LG-2-4]]
+==== LG 2-4: Assessing modularization strategies
 * Strategies and consequences: Evaluating the impact of different modularization approaches, e.g., monolith vs. distributed modules.
 * Technology dependency: How modularization technologies (e.g., containers or runtime environments) influence strategies.
 * Effort-benefit trade-offs: Weighing organizational and technical efforts against expected benefits.
 
-[[LG-2-6]]
-==== LG 2-6: Contrasting the costs and benefits of modularization strategies
+[[LG-2-5]]
+==== LG 2-5: Contrasting the costs and benefits of modularization strategies
 * Integration vs. decentralization: Identifying organizational and technical costs for integrating modular systems.
 * Expected benefits: Assessing advantages such as independent deployment, parallelization, and improved system comprehensibility.
 * Module boundaries and complexity: Analyzing how module boundary choices affect complexity and development effort.

docs/02-modularization/references.adoc

@@ -1,5 +1,5 @@
 === {references}
 
-<<evansddd>>, <<fowler>>, <<twelvefactor>>, <<wolffms>>, <<newman>>, <<parnas>>
+<<evansddd>>, <<fowler>>, <<wolffms>>, <<newman>>, <<parnas>>
 
 

docs/03-modules-organization/00-structure.adoc

@@ -0,0 +1,18 @@
+// header file for curriculum section 3: Lerneinheit 3
+// (c) iSAQB e.V. (https://isaqb.org)
+// ====================================================
+
+// tag::DE[]
+== Softwaremodule und der Bezug zu Organisationsstrukturen
+// end::DE[]
+
+// tag::EN[]
+== Software Modules and the Organization
+// end::EN[]
+
+include::01-duration-terms.adoc[{include_configuration}]
+
+include::02-learning-goals.adoc[{include_configuration}]
+
+// references (if any!)
+include::references.adoc[{include_configuration}]

docs/03-modules-organization/01-duration-terms.adoc

@@ -0,0 +1,17 @@
+// tag::DE[]
+|===
+| Dauer: 60 Min. | Übungszeit: 30 Min.
+|===
+
+=== Begriffe und Konzepte
+
+// end::DE[]
+
+// tag::EN[]
+|===
+| Duration: 60 min | Practice time: 30 min
+|===
+
+=== Terms and Principles
+
+// end::EN[]

docs/03-modules-organization/02-learning-goals.adoc

@@ -0,0 +1,84 @@
+=== {learning-goals}
+
+
+// tag::DE[]
+[[LZ-3-1]]
+==== LZ 3-1: Wechselwirkung von Architekturtypen und Organisation analysieren und benennen
+
+- Erklären, wie Beziehungen zwischen Teams bzw. Organisationseinheiten die Architektur von Systemen beeinflussen und damit Auswirkungen auf Abstimmungsaufwände und Time-to-Market haben
+- Erkennen, wie Conway's Law die Entwicklungsgeschwindigkeit und Änderungsfähigkeit von Systemen beeinflusst
+- Den Zusammenhang zwischen Teamgrenzen und Systemgrenzen analysieren und erklären
+- (OPTIONAL) Die Balance zwischen technischer und organisatorischer Struktur erklären
+- Unterschiede von Buildtime- und Runtime-Abhängigkeiten für Softwareentwicklungsprozesse erklären
+- Die Parallelisierbarkeit von Softwareentwicklungsaufgaben als Architekturziel verstehen
+- (OPTIONAL) Darstellen wie organisatorische Änderungen die Software beeinflussen und umgekehrt, um bewusste Entscheidungen für Organisations- und Softwarearchitektur treffen zu können.
+
+[[LZ-3-2]]
+==== LZ 3-2: Kommunikationsstruktur der Organisation bei Zerlegung berücksichtigen
+
+* Conway’s Law: Bedeutung verstehen und Auswirkungen der Kommunikationsstruktur der Organisation auf die Wahl und Gestaltung von Modulgrenzen.
+* Autonomie und Zusammenarbeit: Sicherstellung der Entwicklungsautonomie durch modulare Schnitte entlang fachlicher Grenzen.
+
+[[LZ-3-3]]
+==== LZ 3-3: Context Maps für Stakeholder Management nutzen
+
+* Context Maps aus Domain-Driven Design (DDD) einsetzen, um den aktuellen IST-Zustand und einen gewünschten zukünftigen SOLL-Zustand einer Systemlandschaft darzustellen. 
+* (OPTIONAL) Context Maps zielgruppenabhängig (Entwickler vs. Management) als Kommunikations- und Planungswerkzeug verstehen und anwenden.
+
+[[LZ-3-4]]
+==== LZ 3-4: (OPTIONAL) Begriffe wie Teamorganisation und sozio-technische Architekturen sicher verwenden
+
+* Begriffe wie Team-Organisation, sozio-technische Architekturen und ähnliche Konzepte einordnen.
+* Bedeutung im Kontext moderner Softwareentwicklung erklären.
+* Verständnis für die Verknüpfung technischer und sozialer Aspekte bei der Architekturgestaltung zu entwickeln.
+
+[[LZ-3-5]]
+==== LZ 3-5: Außerhalb des eigenen Einflussbereiches getroffene Makroarchitekturentscheidungen identifizieren
+
+- Unterschied zwischen Mikro- und Makroarchitektur verstehen, um potenzielle Einschränkungen und Abstimmungsaufwände zu identifizieren und proaktiv zu adressieren.
+- Die Abgrenzung zwischen Makro- und Mikroarchitektur verstehen, um potenzielle Einschränkungen und Möglichkeiten bei Deployment-Strategien zu identifizieren.
+- Makroarchitekturentscheidungen wie Kommunikationsprotokolle, Betriebsstandards und Plattformvorgaben analysieren und deren Auswirkungen auf Deployment- und Runtime-Methoden bewerten.
+- Die Bedeutung von zentralen Plattformstandards für die Effizienz von Kommunikation und Deployments/Softwarelieferungen erkennen.
+
+// end::DE[]
+
+// tag::EN[]
+[[LG-3-1]]
+==== LG 3-1: Analyze and name the interaction between architecture types and organization
+
+* Explain how relationships between teams or organizational units influence the architecture of systems, impacting coordination efforts and time-to-market
+* Recognize how Conway's Law affects the development speed and adaptability of systems
+* Analyze and explain the relationship between team boundaries and system boundaries
+* (OPTIONAL) Explain the balance between technical and organizational * structure
+* Explain the differences between build-time and runtime dependencies for software development processes
+* Understand the parallelizability of software development tasks as an architectural goal
+* (OPTIONAL) Describe how organizational changes affect software and vice versa, enabling informed decisions for organizational and software architecture
+
+[[LG-3-2]]
+==== LG 3-2: Consider the organization's communication structure when decomposing
+
+* Conway's Law: Understand the significance and impact of the organization's communication structure on the choice and design of module boundaries.
+* Autonomy and Collaboration: Ensure development autonomy through modular cuts along business boundaries.
+
+[[LG-3-3]]
+==== LG 3-3: Use context maps for stakeholder management
+
+* Use context maps from Domain-Driven Design (DDD) to represent the  current state (AS-IS) and a desired future state (TO-BE) of a system landscape.
+
+* (OPTIONAL) Understand and apply context maps as a communication and planning tool depending on the target audience (developers vs. management).
+
+[[LG-3-4]]
+==== LG 3-4: (OPTIONAL) Use terms like team organization and socio-technical architectures confidently
+
+* Classify terms such as team organization, socio-technical architectures, and similar concepts.
+* Explain their meaning in the context of modern software development.
+* Develop an understanding of the link between technical and social aspects in architecture design.
+
+[[LG-3-5]]
+==== LG 3-5: Identify macro-architecture decisions made outside your sphere of influence
+
+* Understand the difference between micro and macro architecture to identify and proactively address potential constraints and coordination efforts.
+* Understand the distinction between macro and micro architecture to identify potential limitations and opportunities in deployment strategies.
+* Analyze macro-architecture decisions such as communication protocols, operational standards, and platform requirements, and evaluate their impact on deployment and runtime methods.
+* Recognize the importance of central platform standards for the efficiency of communication and deployments/software deliveries.
+// end::EN[]

docs/03-modules-organization/references.adoc

@@ -0,0 +1,3 @@
+=== {references}
+
+<<skeltonpais>>, <<evansddd>>, <<vossencloud>>, <<conway>>, <<baxtersommerville>>

docs/04-integration/01-duration-terms.adoc

@@ -1,21 +1,17 @@
 // tag::DE[]
 |===
-| Dauer: 90 Min. | Übungszeit: 30 Min.
+| Dauer: 60 Min. | Übungszeit: 30 Min.
 |===
 
 === Begriffe und Konzepte
-Frontend Integration, Legacy Systeme, Authentifizierung, Autorisierung, (lose) Kopplung, Skalierbarkeit, Messaging Patterns, Domain Events, dezentrale Datenhaltung.
 
 // end::DE[]
 
 // tag::EN[]
 |===
-| Duration: 120 min | Practice time: 30 min
+| Duration: 60 min | Practice time: 30 min
 |===
 
 === Terms and Principles
-Frontend integration, legacy systems, authentication, authorisation,
-(loose) coupling, scalability, messaging patterns, domain events,
-decentralised data management.
 
 // end::EN[]

docs/04-integration/references.adoc

@@ -1,6 +1,6 @@
 === {references}
 
-<<evansddd>>, <<oauth>>, <<hohpe>>
+<<evansddd>>, <<oauth>>, <<hohpe>>, <<tanenbaum>>, <<lamport>>, <<brewer>>, <<takada>>, <<nygard>>, <<hanmer>>, <<hamilton>>