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]

May 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.