From 023e9fae39a3931709dc13a5a3f3ce8d409a3a1c Mon Sep 17 00:00:00 2001 From: Falk Sippach Date: Fri, 29 Nov 2024 17:32:52 +0100 Subject: [PATCH 1/3] #70 new chapter 3 added --- docs/03-integration/01-duration-terms.adoc | 8 ++--- .../03-modules-organization/00-structure.adoc | 18 ++++++++++ .../01-duration-terms.adoc | 17 ++++++++++ .../02-learning-goals.adoc | 34 +++++++++++++++++++ docs/03-modules-organization/references.adoc | 1 + docs/curriculum-flex.adoc | 2 +- 6 files changed, 73 insertions(+), 7 deletions(-) create mode 100644 docs/03-modules-organization/00-structure.adoc create mode 100644 docs/03-modules-organization/01-duration-terms.adoc create mode 100644 docs/03-modules-organization/02-learning-goals.adoc create mode 100644 docs/03-modules-organization/references.adoc diff --git a/docs/03-integration/01-duration-terms.adoc b/docs/03-integration/01-duration-terms.adoc index 1e240ab..035bffc 100644 --- a/docs/03-integration/01-duration-terms.adoc +++ b/docs/03-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[] diff --git a/docs/03-modules-organization/00-structure.adoc b/docs/03-modules-organization/00-structure.adoc new file mode 100644 index 0000000..b729220 --- /dev/null +++ b/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}] diff --git a/docs/03-modules-organization/01-duration-terms.adoc b/docs/03-modules-organization/01-duration-terms.adoc new file mode 100644 index 0000000..035bffc --- /dev/null +++ b/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[] diff --git a/docs/03-modules-organization/02-learning-goals.adoc b/docs/03-modules-organization/02-learning-goals.adoc new file mode 100644 index 0000000..5ecc1c6 --- /dev/null +++ b/docs/03-modules-organization/02-learning-goals.adoc @@ -0,0 +1,34 @@ +=== {learning-goals} + + +// tag::DE[] +[[LZ-3-1]] +==== LZ 3-1: Conway's Law anhand von Beispielen erklären + +Die Teilnehmenden sollen das Prinzip von Conway's Law verstehen und anhand praktischer Beispiele verdeutlichen können, wie die Kommunikationsstrukturen einer Organisation die Softwarearchitektur prägen. Ziel ist es, die Auswirkungen dieser Wechselwirkungen bewusst zu machen und für Architekturentscheidungen zu nutzen. + +[[LZ-3-2]] +==== LZ 3-2: Context Maps für Stakeholder Management nutzen + +Die Teilnehmenden lernen, Domain-Driven Design (DDD) Context Maps einzusetzen, um den aktuellen Zustand (AS-IS) und einen gewünschten zukünftigen Zustand (TO-BE) einer Systemlandschaft darzustellen. Dabei wird auch das Einbinden von Stakeholdern in den Veränderungsprozess thematisiert. Ziel ist es, Context Maps als Kommunikations- und Planungswerkzeug zu verstehen und anzuwenden. + + +[[LZ-3-3]] +==== LZ 3-3: Wechselwirkungen zwischen Organisation und Software Systemen erklären und analysieren + +Die Teilnehmenden sollen die bidirektionalen Einflüsse zwischen Organisationsstrukturen und Softwarearchitekturen verstehen und analysieren können. Dabei wird der Fokus darauf gelegt, wie organisatorische Änderungen Software beeinflussen und umgekehrt, um eine bessere Abstimmung zwischen beiden Welten zu erreichen. + +[[LZ-3-4]] +==== LZ 3-4: Begriffe wie Teamorganisation und sozio-technische Architekturen einordnen + +Die Teilnehmenden sollen Begriffe wie Team-Organisation, sozio-technische Architekturen und ähnliche Konzepte einordnen und deren Bedeutung im Kontext moderner Softwareentwicklung erklären können. Ziel ist es, ein Verständnis für die Verknüpfung technischer und sozialer Aspekte bei der Architekturgestaltung zu entwickeln. + +// end::DE[] + +// tag::EN[] +[[LG-3-1]] +==== LG 3-1: Explain Conway's Law using examples + +// end::EN[] + + diff --git a/docs/03-modules-organization/references.adoc b/docs/03-modules-organization/references.adoc new file mode 100644 index 0000000..da9242d --- /dev/null +++ b/docs/03-modules-organization/references.adoc @@ -0,0 +1 @@ +=== {references} diff --git a/docs/curriculum-flex.adoc b/docs/curriculum-flex.adoc index 5b7052d..235b5d1 100644 --- a/docs/curriculum-flex.adoc +++ b/docs/curriculum-flex.adoc @@ -47,7 +47,7 @@ include::01-motivation/00-structure.adoc[{include_configuration}] include::02-modularization/00-structure.adoc[{include_configuration}] <<< -include::03-integration/00-structure.adoc[{include_configuration}] +include::03-modules-organization/00-structure.adoc[{include_configuration}] <<< include::04-rollout/00-structure.adoc[{include_configuration}] From 6fe731b9d98175b19979b5325593142522b5c3be Mon Sep 17 00:00:00 2001 From: Alexander Heusingfeld Date: Sun, 1 Dec 2024 01:04:29 +0100 Subject: [PATCH 2/3] Moved organisation LG to chapter3 and added references --- docs/01-motivation/02-learning-goals.adoc | 40 +++-------- docs/02-modularization/02-learning-goals.adoc | 31 +++----- docs/02-modularization/references.adoc | 2 +- .../02-learning-goals.adoc | 72 ++++++++++++++++--- docs/03-modules-organization/references.adoc | 2 + docs/05-rollout/02-learning-goals.adoc | 65 +++++++---------- docs/99-references/00-references.adoc | 14 ++-- 7 files changed, 119 insertions(+), 107 deletions(-) diff --git a/docs/01-motivation/02-learning-goals.adoc b/docs/01-motivation/02-learning-goals.adoc index e7f1566..2a259a8 100644 --- a/docs/01-motivation/02-learning-goals.adoc +++ b/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 diff --git a/docs/02-modularization/02-learning-goals.adoc b/docs/02-modularization/02-learning-goals.adoc index 01c3573..e2d5bc7 100644 --- a/docs/02-modularization/02-learning-goals.adoc +++ b/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. diff --git a/docs/02-modularization/references.adoc b/docs/02-modularization/references.adoc index 170973e..c49d6b7 100644 --- a/docs/02-modularization/references.adoc +++ b/docs/02-modularization/references.adoc @@ -1,5 +1,5 @@ === {references} -<>, <>, <>, <>, <>, <> +<>, <>, <>, <>, <> diff --git a/docs/03-modules-organization/02-learning-goals.adoc b/docs/03-modules-organization/02-learning-goals.adoc index 5ecc1c6..3d18e06 100644 --- a/docs/03-modules-organization/02-learning-goals.adoc +++ b/docs/03-modules-organization/02-learning-goals.adoc @@ -3,32 +3,82 @@ // tag::DE[] [[LZ-3-1]] -==== LZ 3-1: Conway's Law anhand von Beispielen erklären +==== LZ 3-1: Wechselwirkung von Architekturtypen und Organisation analysieren und benennen -Die Teilnehmenden sollen das Prinzip von Conway's Law verstehen und anhand praktischer Beispiele verdeutlichen können, wie die Kommunikationsstrukturen einer Organisation die Softwarearchitektur prägen. Ziel ist es, die Auswirkungen dieser Wechselwirkungen bewusst zu machen und für Architekturentscheidungen zu nutzen. +- 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: Context Maps für Stakeholder Management nutzen - -Die Teilnehmenden lernen, Domain-Driven Design (DDD) Context Maps einzusetzen, um den aktuellen Zustand (AS-IS) und einen gewünschten zukünftigen Zustand (TO-BE) einer Systemlandschaft darzustellen. Dabei wird auch das Einbinden von Stakeholdern in den Veränderungsprozess thematisiert. Ziel ist es, Context Maps als Kommunikations- und Planungswerkzeug zu verstehen und anzuwenden. +==== 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: Wechselwirkungen zwischen Organisation und Software Systemen erklären und analysieren +==== LZ 3-3: Context Maps für Stakeholder Management nutzen -Die Teilnehmenden sollen die bidirektionalen Einflüsse zwischen Organisationsstrukturen und Softwarearchitekturen verstehen und analysieren können. Dabei wird der Fokus darauf gelegt, wie organisatorische Änderungen Software beeinflussen und umgekehrt, um eine bessere Abstimmung zwischen beiden Welten zu erreichen. +* 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: Begriffe wie Teamorganisation und sozio-technische Architekturen einordnen +==== 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 -Die Teilnehmenden sollen Begriffe wie Team-Organisation, sozio-technische Architekturen und ähnliche Konzepte einordnen und deren Bedeutung im Kontext moderner Softwareentwicklung erklären können. Ziel ist es, ein Verständnis für die Verknüpfung technischer und sozialer Aspekte bei der Architekturgestaltung zu entwickeln. +- 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: Explain Conway's Law using examples +==== LG 3-1: Analyze and name the interaction between architecture types and organization -// end::EN[] +* 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[] diff --git a/docs/03-modules-organization/references.adoc b/docs/03-modules-organization/references.adoc index da9242d..128f8ee 100644 --- a/docs/03-modules-organization/references.adoc +++ b/docs/03-modules-organization/references.adoc @@ -1 +1,3 @@ === {references} + +<>, <>, <>, <>, <> \ No newline at end of file diff --git a/docs/05-rollout/02-learning-goals.adoc b/docs/05-rollout/02-learning-goals.adoc index d985281..b03e0db 100644 --- a/docs/05-rollout/02-learning-goals.adoc +++ b/docs/05-rollout/02-learning-goals.adoc @@ -2,55 +2,48 @@ // tag::DE[] [[LZ-5-1]] -==== LZ 5-1: Außerhalb des eigenen Einflussbereiches getroffene Makroarchitekturentscheidungen identifizieren - -- Makroarchitekturentscheidungen wie Kommunikationsprotokolle, Betriebsstandards und Plattformvorgaben analysieren und deren Auswirkungen auf Deployment- und Runtime-Methoden bewerten. -- Die Abgrenzung zwischen Makro- und Mikroarchitektur verstehen, um potenzielle Einschränkungen und Möglichkeiten bei Deployment-Strategien zu identifizieren. -- Die Bedeutung von zentralen Plattformstandards für die Vereinheitlichung und Effizienz von Deployments erkennen. - -[[LZ-5-2]] -==== LZ 5-2: Voraussetzungen und Auswirkungen für Continuous Deployment benennen +==== LZ 5-1: Voraussetzungen und Auswirkungen für Continuous Deployment benennen - Anforderungen an eine CI/CD-Pipeline erklären, einschließlich Automatisierungsgrad, Tests und Infrastrukturintegration. - Die Rolle von DevOps in Continuous Deployment verstehen und organisatorische Implikationen erkennen. - Unterschiede zwischen traditionellen und modernen Deployment-Ansätzen, wie Immutable Infrastructure oder Infrastructure as Code, evaluieren. - Risiken und Vorteile von Continuous Deployment, einschließlich Zero Downtime, im Kontext verschiedener Projekte abwägen. -[[LZ-5-3]] -==== LZ 5-3: (OPTIONAL) Unterschiede von IaaS, PaaS, CaaS, FaaS erklären und auswählen +[[LZ-5-2]] +==== LZ 5-2: (OPTIONAL) Unterschiede von IaaS, PaaS, CaaS, FaaS erklären und auswählen - Die technischen Eigenschaften und Anwendungsbereiche der verschiedenen Plattformansätze (IaaS, PaaS, CaaS, FaaS) erläutern. - Kriterien für die Auswahl des passenden Plattformansatzes in Abhängigkeit von Projektanforderungen wie Skalierbarkeit, Flexibilität und Kosten aufstellen. - Auswirkungen der Plattformwahl auf die Deployment-Strategie analysieren und Entscheidungen zu Containerisierung (z. B. Docker, Kubernetes) oder serverlosen Ansätzen treffen. -[[LZ-5-4]] -==== LZ 5-4: Zero Downtime Methodiken und ihre Auswirkungen benennen und auswählen +[[LZ-5-3]] +==== LZ 5-3: Zero Downtime Methodiken und ihre Auswirkungen benennen und auswählen - Verschiedene Zero-Downtime-Strategien (Blue-Green-Deployment, Canary Releases, Rolling Updates) erläutern und deren Vor- und Nachteile analysieren. - Die Rolle von Immutable Infrastructure und Automatisierung für Zero Downtime erklären. - Herausforderungen und Architekturanforderungen für Zero-Downtime-Deployments evaluieren. -[[LZ-5-5]] -==== LZ 5-5: Unterschiede zwischen Continuous Integration, Continuous Deployment und Continuous Delivery erklären +[[LZ-5-4]] +==== LZ 5-4: Unterschiede zwischen Continuous Integration, Continuous Deployment und Continuous Delivery erklären - Die Bedeutung von Continuous Integration (CI) als Grundlage für Continuous Deployment und Delivery erläutern. - Unterschiede in Zielsetzung und Automatisierungsgrad zwischen den drei Konzepten analysieren. - Abhängigkeiten von Architekturentscheidungen auf den Einsatz von CI/CD-Pipelines beschreiben. -[[LZ-5-6]] -==== LZ 5-6: (OPTIONAL) Deployment-spezifische Sicherheitsanforderungen benennen +[[LZ-5-5]] +==== LZ 5-5: (OPTIONAL) Deployment-spezifische Sicherheitsanforderungen benennen - Anforderungen an den Schutz von Secrets (z. B. API-Keys, Zertifikate) und Sicherheitsrichtlinien im Deployment-Prozess erklären. - Konzepte wie Zugriffskontrollen, Verschlüsselung und Compliance-Anforderungen in Deployment-Strategien integrieren. - Werkzeuge zur Verwaltung sicherheitsrelevanter Informationen (Secret Store) einsetzen und bewerten. -[[LZ-5-7]] -==== LZ 5-7: (OPTIONAL) Die Rolle von Observability im Deployment-Prozess erklären +[[LZ-5-6]] +==== LZ 5-6: (OPTIONAL) Die Rolle von Observability im Deployment-Prozess erklären - Anforderungen an ein Monitoring-System und dessen Bedeutung für den Deployment-Erfolg erläutern. - Die Rolle von zentralisierten Logging- und Metriksystemen (z. B. Elastic Stack, Prometheus, Grafana) erklären. - Strategien entwickeln, um potenzielle Probleme im Deployment-Prozess frühzeitig zu erkennen und zu adressieren. -[[LZ-5-8]] -==== LZ 5-8: (OPTIONAL) Kosten- und Ressourceneffizienz im Deployment optimieren +[[LZ-5-7]] +==== LZ 5-7: (OPTIONAL) Kosten- und Ressourceneffizienz im Deployment optimieren - Methoden zur Kostenoptimierung im Deployment evaluieren (z. B. Reserved Instances, Spot Instances, Serverless). - Auswirkungen der Wahl von Cloud- und Virtualisierungsstrategien auf die Betriebskosten und Ressourcennutzung analysieren. - Deployment-Methoden entwickeln, die Skalierbarkeit und Effizienz maximieren. @@ -60,50 +53,44 @@ // tag::EN[] [[LG-5-1]] -==== LG 5-1: Identify Macro-architectural Decisions Beyond Your Sphere of Influence -- Analyze macro-architectural decisions such as communication protocols, operational standards, and platform requirements, evaluating their impact on deployment and runtime methods -- Understand the distinction between macro and micro architecture to identify potential constraints and opportunities in deployment strategies -- Recognize the importance of central platform standards for deployment uniformity and efficiency - -[[LG-5-2]] -==== LG 5-2: Specify prerequisites and implications for Continuous Deployment +==== LG 5-1: Specify prerequisites and implications for Continuous Deployment - Utilize quality goals to explain CI/CD pipeline requirements, including automation levels, testing, and infrastructure integration - Understand DevOps' role in Continuous Deployment and recognize organizational implications - Evaluate differences between traditional and modern deployment approaches, such as Immutable Infrastructure or Infrastructure as Code - Assess risks and benefits of Continuous Deployment, including zero downtime, in various project contexts -[[LG-5-3]] -==== LG 5-3: (OPTIONAL) Explain and select differences between IaaS, PaaS, CaaS, and FaaS +[[LG-5-2]] +==== LG 5-2: (OPTIONAL) Explain and select differences between IaaS, PaaS, CaaS, and FaaS - Describe technical characteristics and application areas of different platform approaches (IaaS, PaaS, CaaS, FaaS) - Establish criteria for selecting appropriate platform approaches based on project requirements like scalability, flexibility, and costs - Analyze platform choice impacts on deployment strategy and make decisions regarding containerization (e.g., Docker, Kubernetes) or serverless approaches -[[LG-5-4]] -==== LG 5-4: Identify and select Zero Downtime methodologies and their implications +[[LG-5-3]] +==== LG 5-3: Identify and select Zero Downtime methodologies and their implications - Explain various zero-downtime strategies (Blue-Green Deployment, Canary Releases, Rolling Updates) and analyze their pros and cons - Explain the role of Immutable Infrastructure and automation for zero downtime - Evaluate challenges and architectural requirements for zero-downtime deployments -[[LG-5-5]] -==== LG 5-5: Explain differences between Continuous Integration, Continuous Deployment, and Continuous Delivery +[[LG-5-4]] +==== LG 5-4: Explain differences between Continuous Integration, Continuous Deployment, and Continuous Delivery - Explain the significance of Continuous Integration (CI) as a foundation for Continuous Deployment and Delivery - Analyze differences in objectives and automation levels between the three concepts - Describe how architectural decisions influence CI/CD pipeline implementation -[[LG-5-6]] -==== LG 5-6: (OPTIONAL) Specify deployment-specific security requirements +[[LG-5-5]] +==== LG 5-5: (OPTIONAL) Specify deployment-specific security requirements - Explain requirements for protecting secrets (e.g., API keys, certificates) and security policies in the deployment process - Integrate concepts like access controls, encryption, and compliance requirements into deployment strategies - Implement and evaluate tools for managing security-relevant information -[[LG-5-7]] -==== LG 5-7: (OPTIONAL) Explain the role of observability in the Deployment Process +[[LG-5-6]] +==== LG 5-6: (OPTIONAL) Explain the role of observability in the Deployment Process - Explain monitoring system requirements and their importance for deployment success - Explain the role of centralized logging and metrics systems (e.g., Elastic Stack, Prometheus, Grafana) - Develop strategies to identify and address potential problems in the deployment process early -[[LG-5-8]] -==== LG 5-8: (OPTIONAL) Shop options to optimize cost and resource efficiency in the deployment process +[[LG-5-7]] +==== LG 5-7: (OPTIONAL) Shop options to optimize cost and resource efficiency in the deployment process - Evaluate methods for cost optimization in deployment and runtime (e.g., Reserved Instances, Spot Instances, Serverless) - Analyze how cloud and virtualization strategy choices impact operational costs and resource utilization - Develop deployment methods that maximize scalability and efficiency diff --git a/docs/99-references/00-references.adoc b/docs/99-references/00-references.adoc index 68c52b3..97cea8f 100644 --- a/docs/99-references/00-references.adoc +++ b/docs/99-references/00-references.adoc @@ -14,6 +14,10 @@ This section contains references that are cited in the curriculum. - [[[brewer,Brewer 2000]]] Eric Brewer, Towards Robust Distributed Systems, PODC Keynote, July-19-2000 +**C** + +- [[conway, Conway 1968]] Melvin E. Conway, How Do Committees Invent?, Datamation, 1968, https://en.wikipedia.org/wiki/Conway's_law + **E** - [[[evansddd,Eric Evans 2003]]] Eric Evans: Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison- Wesley Professional, 2003 @@ -46,21 +50,21 @@ This section contains references that are cited in the curriculum. in Decomposing Systems into Modules. Communications of the ACM 15(12):1053--1058, 1972. +**S** + +- [[[sommerville, Baxter, Sommerville 2011]]], Gordon Baxter, Ian Sommerville: Sociotechnical Systems Design: Evolving Theory and Practice, 2011, https://academic.oup.com/iwc/article/23/1/4/693091 **T** - [[[takada,Takada 2013]]] Mikito Takada, Distributed Systems for Fun and Profit, http://book.mixu.net/distsys/ (Guter Einstieg und Überblick) - [[[tanenbaum,Tanenbaum, van Steen 2006]]] Andrew Tanenbaum, Marten van Steen, Distributed Systems – Principles and Paradigms, Prentice Hall, 2nd Edition, 2006 +- [[[skeltonpais,Skelton, Pais 2019]]] Mathew Skelton, Manuel Pais - TEAM TOPOLOGIES: ORGANIZING BUSINESS AND TECHNOLOGY TEAMS FOR FAST FLOW, IT Revolution, 2019, ISBN 978-1-942788-81-2 **V** -- [[[vossencloud,Vossen, Haselmann, Hoeren 2012]]] Gottfried Vossen, Till Haselmann, Thomas Hoeren: Cloud-Computing für Unternehmen: Technische, wirtschaftliche, rechtliche und organisatorische Aspekte, dpunkt, 2012, ISBN 978-3- 89864-808-0 +- [[[vossencloud,Vossen, Haselmann, Hoeren 2012]]] Gottfried Vossen, Till Haselmann, Thomas Hoeren: Cloud-Computing für Unternehmen: Technische, wirtschaftliche, rechtliche und organisatorische Aspekte, dpunkt, 2012, ISBN 978-3-89864-808-0 **W** - [[[wolffcd,Wolff 2016]]] Eberhard Wolff: Continuous Delivery: Der pragmatische Einstieg, 2. Auflage, dpunkt, 2016, ISBN 978-3-86490-371-7 - [[[wolffms,Wolff 2018]]] Eberhard Wolff: Microservices - Grundlagen flexibler Software Architekturen, 2. Auflage, dpunkt, 2018, ISBN 978-3-86490-555-1 - [[[wolfpaas, Wolff, Müller, Löwenstein 2013]]] Eberhard Wolff, Stephan Müller, Bernhard Löwenstein: PaaS - Die wichtigsten Java Clouds auf einen Blick, entwickler.press, 2013 - -**1** - -- [[[twelvefactor,12 Factor App 2012]]] 12 Factor App, Guidelines for building apps on Heroku http://12factor.net/ From 0b0b7d3eefc9d89efceb4e15b42f4d5f71620cf3 Mon Sep 17 00:00:00 2001 From: Alexander Heusingfeld Date: Sun, 1 Dec 2024 01:21:53 +0100 Subject: [PATCH 3/3] fixed references --- docs/01-motivation/references.adoc | 2 +- docs/03-modules-organization/references.adoc | 2 +- docs/04-integration/references.adoc | 2 +- docs/99-references/00-references.adoc | 6 ++---- 4 files changed, 5 insertions(+), 7 deletions(-) diff --git a/docs/01-motivation/references.adoc b/docs/01-motivation/references.adoc index cfd0993..193c7cc 100644 --- a/docs/01-motivation/references.adoc +++ b/docs/01-motivation/references.adoc @@ -1,6 +1,6 @@ === {references} -<>, <>, <> +<>, <>, <>, <> diff --git a/docs/03-modules-organization/references.adoc b/docs/03-modules-organization/references.adoc index 128f8ee..6b77de4 100644 --- a/docs/03-modules-organization/references.adoc +++ b/docs/03-modules-organization/references.adoc @@ -1,3 +1,3 @@ === {references} -<>, <>, <>, <>, <> \ No newline at end of file +<>, <>, <>, <>, <> \ No newline at end of file diff --git a/docs/04-integration/references.adoc b/docs/04-integration/references.adoc index 925216b..9e00087 100644 --- a/docs/04-integration/references.adoc +++ b/docs/04-integration/references.adoc @@ -1,6 +1,6 @@ === {references} -<>, <>, <> +<>, <>, <>, <>, <>, <>, <>, <>, <>, <> diff --git a/docs/99-references/00-references.adoc b/docs/99-references/00-references.adoc index 97cea8f..8da1758 100644 --- a/docs/99-references/00-references.adoc +++ b/docs/99-references/00-references.adoc @@ -12,11 +12,12 @@ This section contains references that are cited in the curriculum. **B** +- [[[baxtersommerville,Baxter, Sommerville 2011]]] Gordon Baxter, Ian Sommerville: Sociotechnical Systems Design: Evolving Theory and Practice, 2011, https://academic.oup.com/iwc/article/23/1/4/693091 - [[[brewer,Brewer 2000]]] Eric Brewer, Towards Robust Distributed Systems, PODC Keynote, July-19-2000 **C** -- [[conway, Conway 1968]] Melvin E. Conway, How Do Committees Invent?, Datamation, 1968, https://en.wikipedia.org/wiki/Conway's_law +- [[[conway,Conway 1968]]] Melvin E. Conway, How Do Committees Invent?, Datamation, 1968, https://en.wikipedia.org/wiki/Conway%27s_law **E** @@ -50,9 +51,6 @@ This section contains references that are cited in the curriculum. in Decomposing Systems into Modules. Communications of the ACM 15(12):1053--1058, 1972. -**S** - -- [[[sommerville, Baxter, Sommerville 2011]]], Gordon Baxter, Ian Sommerville: Sociotechnical Systems Design: Evolving Theory and Practice, 2011, https://academic.oup.com/iwc/article/23/1/4/693091 **T** - [[[takada,Takada 2013]]] Mikito Takada, Distributed Systems for Fun and Profit, http://book.mixu.net/distsys/ (Guter Einstieg und Überblick)