replace exception rule by Incubator status

[depressiveRobot]

Resolves #1024

There are still some open questions:

• How to allow implementation partners that don't want to offer an own public environment (criteria c) to get a certification?
  • current idea is v3 of the procedural (or a new procedural) which introduces another stage of certification, like "Certified SCS Engineer/Consultant/Trainer"
• How do we want to handle joint references? (e.g. two or more partners have jointly set up SCS environments or manage them together)
• How to prove that the environment is not "scripted only"?
  • maybe some kind of plausibility checks and statistics (customers, applications, workloads, stress tests etc.)
  • mainly affects KaaS environments

Show differences between v1 and v2:

Procedural:

git diff --no-index Standards/scs-0007-v1-certification-integrators.md Standards/scs-0007-v2-certification-integrators.md

Supplement:

git diff --no-index Standards/scs-0007-w1-certification-integrators-implementation-notes.md Standards/scs-0007-w2-certification-integrators-implementation-notes.md

[mbuechse]

In my mind, the Incubator status needs to be implemented differently, namely, as a dedicated kind of certificate (maybe two, one for each layer), to be listed in the Section "Certificates".

Also and probably independent of my previous point, I think the Section "Criteria" should be rephrased. Something along the lines of:

The partner should achieve at least two points (for Integrator) or one point (for Apprentice) according to the following system:

• one point for each SCS-compliant environment of a third party successfully brought into production in the last 12 months, where the environment must fulfill at least ...
• one point for each SCS-compliant environment of a third party actively being managed by the applicant,
• etc. pp

This way, we can allow a mixture of what is currently a, b, and c.

[fkr]

Very good point. I always had in mind that is a separate Certificate, in order not to add to any confusion. I like the idea with the points.

[fkr]

In addition to @mbuechse 's comment: With the points we get rid of the voting, since I see the voting as one of the primary culprits of the original proposal as well. The decision should lie in the attestation body and with the proposed variant upon points, this would work nicely.

[mbuechse]

I tried to incorporate what we had discussed in the SIG. I think the name "Incubator" should be reconsidered.

[fkr]

I tried to incorporate what we had discussed in the SIG. I think the name "Incubator" should be reconsidered.

i concur. Reading it like "SCS-Certified IaaS Incubator" does not really make sense. Apprentice ;)

• SCS-certified IaaS Associate?
• SCS-certified IaaS Mentee?
• SCS-certified IaaS Protégé?

[depressiveRobot]

Many thanks to both of you, especially @mbuechse for incorporating what was discussed in the SIG. Based on this, I tried to make further adjustments:

• definition of terms: "implementation partner" and "applicant"
• wording "scoring system" to get rid of "criteria"

My two cents for a better name than "Incubator":

• "Associate" does not clearly express to me that the organization is not yet an integrator
• "Mentee", "Protege" and "Apprentice", "Trainee", "Candidate", "Recriut", "Novice": we can name it like we want, however, with all of them it is not clear to me that the certificate is about becoming a fully-fledged integrator.
• That's why I have the idea of "SCS-certified IaaS Bronze Integrator". This way we could also reflect the score in the certificate name:
  • two points: "SCS-certified IaaS Bronze Integrator"
  • four points: "SCS-certified IaaS Silver Integrator"
  • six or more points: "SCS-certified IaaS Gold Integrator"

The actual certification process could be described as implementation hints in the Supplement w2. Also with the additions proposed in the SIG, with the three stages of "self-assessment", "codified checks" and "audit". However, this would still require specific plausibility checks and statistics.

[fkr]

Couple of thoughts:

By having several levels of SCS-Certified IaaS it becomes more complex to comprehend for outsiders, thats why I kinda liked the different naming. “SCS-certified IaaS Integrator” is simple and easily understood. But maybe this discussion / the course of discussion since September shows that we need this added "complexity" in order to address the needs adequately.

The second thought: we just certified four companies with ‘SCS-certified IaaS Integrator’ and renaming this would mean that this has to be adjusted as well.

[mbuechse]

We can say that "Silver" (and above) MAY be omitted, so as to remain backwards-compatible.

[depressiveRobot]

I tried to incorporate our latest proposal regarding certificate levels and the points mentioned in the last SIG Std/Cert on 2025-12-02.

[depressiveRobot]

Regarding the open question "How to allow implementation partners who are very knowledgeable, but will never meet the requirements of Integrator to become certified?"

Version 2 of this standard intentionally does not consider this question. It should rather be a separate new standard like "Certified SCS Consultant".

The other two open issues are addressed in the current draft, see supplement.

[depressiveRobot]

During the presentation at the Forum SCS-Standards regular call on 2025-12-12 the issue was raised that the current naming system using certificate levels (aka "Certified SCS IaaS Bronze Integrator") is too long:

These were the suggestion so far:

• Certified SCS IaaS Bronze Integrator
• Certified SCS IaaS Integrator with a label/stamp "Incubator"/"Incubator status"
• Certified SCS IaaS Incubator (relation to Integrator missing)
• SCS-certified IaaS ...
  • Associate, Mentee, Protege, Trainee, Candidate, Recriut, Novice
  • with all of them it is not clear that the certificate is about becoming a fully-fledged SCS Integrator

What we are looking for: A shorter name/term that clearly expresses that it is an entry-level/lower level certification to the "normal" SCS Integrator.