LG 1-* or LG 2-*: Add specific learning goal with purposes of API Usage

[n-nkm]

Hi,
While I think most aspects of doing APIs are well represented in the curriculum I would like to see a little more of an extension as to why APIs are used. In particular, I would like to see more detail here and think examples could be helpful.

I would like chapter 2 to hold an addition LG which requires examples of API Usages to be used in trainings. Requiring one of each type mentioned in LG 2-2 would probably do good.

A private API example might be: Companies can create value by using APIs to accelerate their development as using an API interface allows teams to work on a similar topic in parallel. This reduces time to market and reduces risk and opportunity cost.

Interested to hear your feedback.

( The curriculum could deliver those examples as well: A few examples for APIs I personally consider interesting and believe to have vastly different implications for the real world:

• The italian governments API for electronic invoicing. Hard to change, Changes are massively impactful
• Product APIs (such as the "typical" ones from Google, Amazon, etc.)
• Centralized Internal APIs (especially centralized ones such as a companies SSO)
• Single Peer APIs (between teams or departments)
• Single Application APIs (such as interfaces between domain and technical details or developers splitting a piece of work in a single team). Easy to change, less committed)

[dret]

I agree with everything you're saying. But that's why we have added chapter 2 and specifically the LGs 2-1 - 2-3. These make it clear that all scenarios (we specifically list public/partner/private) need to be covered. Which APIs you specifically describe, or which ones you're using in exercises should be something that individual trainings/trainers can decide.

I am not 100% sure how iSAQB approaches this, but it seemed to me that the idea of a curriculum is to talk about which areas should be covered and which takeaways we're expecting, without saying specifically how to cover them and which which specific examples.

[n-nkm]

I definitely agree that the trainers have a choice which examples they use.
I reread 2-1 and 2-3 and I certainly overlooked the requirement of examples in 2-3.

So my only remaining interest is: Should we add a similar sentence to 2-2 (to make sure examples are given)?
I am just gonna open a PR and see what the votes on it say. I think that is the easiest way.

Kind of unrelated to this discussion, but possibly of interest:
Since you mentioned other curricula the "foundation" one sets an example. It says

LG 2-3: Identify and Consider Factors Influencing Software Architecture (R1-R3)
[...]
Software architects are able to describe how those factors can influence design decisions and can
elaborate on the consequences of changing influencing factors by providing examples for some of them
(R2)

or

LG 2-5: Describe, Explain and Appropriately Apply Important Solution Patterns (R1, R3)
[...]
Software architects can explain and provide examples for the following patterns (R1)

Since the participant needs to be able to provide examples it indirectly ensures the trainer will use one instead of an abstract slide.

(Should I close this now since we are moving towards a pr? Or should the pr mention the issue and close with either merge or rejection?)

[dret]

(Should I close this now since we are moving towards a pr? Or should the pr mention the issue and close with either merge or rejection?)

I'd suggest creating a branch and PR from this issue and then we can keep those things linked. Thanks!

[sippsack]

I would suggest to postpone to the second release.