Skip to content

02-learning-goals.adoc

Latest commit

 

History

History
126 lines (75 loc) · 5.67 KB

02-learning-goals.adoc

File metadata and controls

126 lines (75 loc) · 5.67 KB

{learning-goals}

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: 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: 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: [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: 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.

LG 3-1: Distribution tradeoffs and challenges

Software architects understand the implementation tradeoffs between monolithic and distributed systems:

  • independent deployment of modules

  • compile-time interopability checks

  • velocity shipping new features to production

  • leverage from re-using code among subsystems

  • difficulty of moving module boundaries

Software architects understand the communication and implementation challenges in distributed systems:

  • communication delivery failure

  • overload from divergent processing rates in the overall system

  • network latency

  • security

  • observability

  • testing

  • fault localization

LG 3-2: Distribution strategy

  • Software architects can choose appropriate module boundaries to separate services.

  • Software architects understand the tradeoffs of request/response communication vs. fire-and-forget.

  • Software architects understand that distributed systems involve both implicit and explicit queues.

  • Software architects can design a communication strategy between services in a distributed system.

  • Software architects can design an architecture for achieving horizontal scalability using microservices.

  • Software architects can implement an appropriate communication strategy for a self-contained systems architecture.

LG 3-3: Distribution mechanisms

  • Software architects know mechanisms for communication in a distributed system such as REST, SOAP, GraphQL, gRPC, Thrift, event feeds, and event buses.

  • Software architects know languages for interfaces in distributed systems such as Protocol, WSDL, JSON schemas, XML schemas, GraphQL schemas, OpenAPI, and AsynAPI.

  • Software architects can choose appropriate technologies and conventions for implementing communication in a distributed system.

  • Software architects can implement flow control/backpressure in a distributed system to ameliorate overload.

  • Software architects can design appropriate fault detection and mitigation strategies.

LG 3-5: Distributed state

  • Software architects can design an appropriate strategy for maintaining distributed state.

  • Software architects understand the difficulty of achieving ACID in a distributed setting.

  • Software architects understand the tradeoffs implied in the CAP theorem.

  • Software architects can decide when BASE is an appropriate strategy for maintaining distributed state.

  • Software architects can utilize events for maintaining distributed state.

LG 3-5: Distribution and the organization

  • Software architects understand the tradeoffs between using common modules across organizational units and "shared nothing" strategies.

  • Software architects can choose and implement high-leverage abstractions (such as platform, libraries, DSLs) across organizational units.