topics to be deleted in the curriculum

[mrtnlhmnn]

The current topics of the curriculum should be skipped:

f) 12-factor app
g) Chapter 3 - "Datenfluss- und Batch-orientierte Systeme" (last bullet point on page 11)
h) Chapter 5 - "Die Teilnehmer sollen auf Basis des DevOps-Organisationsmodells einen Team-Aufbau skizzieren können". This is too ambitious, taking this learning goal literally. "Team-Aufbau" would need to take organizational requirements and team topologies into account. This goes too far for such a training.

[aburmeis]

Not sure about f) 12-factor app, but you have my go for g) and h). Btw. what about OSGi Bundles?

[mrtnlhmnn]

what about OSGi Bundles?
Are you suggesting to skip these as well?

Actually I would like to keep them. Yes, they are not very widespread and in business applications they typically don't play a role. But in embedded systems or "systems closer to hardware" , they are still well known.
Especially when one needs
a) strict encapsulation (ok, now also available with Java Jigsaw / JPMS, with lots of limitations)
and/or b) lifecycle , i.e. the possibility to start/stop/pause/resume the bundles at runtime.

[aheusingfeld]

Interesting discussion here, I'm of exactly the opposite opinion: it turned out to actually be a very good practice every time I conduct the h) excercise because it makes participants think about the impact that code structure has on collaboration between teams and thus coordination effort which is the most common reason for coupling-issues in distributed systems.

On f) see #18

[sippsack]

Maybe we change h) from „can“ to „understand“ or „know“. So every trainer can decide how important this topic is.

[aheusingfeld]

to „understand“ or „know“

hm, that's different things IMPOV, Falk.

1. "understand" or "know" does not tell whether the attendee SHOULD understand, MUST understand or CAN understand this. I.e. it doesn't suggest a severity
2. the choice of wording "understand" at least with me creates a mental link to the former Learning Goal formulation. AFAIK this choice of wording is explicitly depreciated by the WG AL.
3. CAN or COULD is AFAIK the terminology used in the foundation curriculum to suggest to trainers that they CAN include this into an individual training but they don't have to.

My goal is to adopt what is already established in the Foundation curriculum in order to build on what attendees already got familiar with

[sippsack]

Ok, I thought these verbs are similiar to the relevance level in the foundation curriculum. But there R1 means, it will be part of the exam and R3 is not relevant for the exam at all.

So, then I meant, we can make this topic optional.

[programming-wolf]

R1-R3 are nonexistent in advanced level curricula ☺️

[mrtnlhmnn]

I support Falks suggestion on h) . As I had written in my original comment, the requirement "... sollen ... skizzieren können" is too ambitious when taken literally.

Participants need to understand ("verstehen" in the old Learning Goal wording) the implications from and to organizational aspects but not be able ("können"), i.e. to actively design that thing.

What is written here, and when taken literally, h) alone could fill a 2 days course as it says and mentions:

1. DevOps
2. Organisationsmodell
3. Team-Aufbau (side note: reads like we only look at the "team build-up" but actually we should talk about the "team structure during the whole life cycle from ramp-up to ramp-down all the way)

All of this is absolutely relevant, no question, but to design this, you need to understand very many different aspects of Dev&Ops, of organizational and process aspects (roles, collaboration models, SW process and its constraints, agility, team sizing), team building and sociological aspects etc.

IMHO this is not possible in such a training. One can show consequences and a bit of background theory (DevOps, Conway, Reverse Convay, Team Topology with Platform Teams etc. etc.) but even if we would spend 2h on that topic, I would not say that participants can actively be able to design that.