Clean Core

Le clean core est souvent réduit à « pas de code spécifique », ce qui ne correspond pas à la description de SAP. Le principe porte sur la manière dont un système s'écarte du standard, et non sur le fait qu'il s'en écarte :

• Les extensions utilisent des API et des points d'extension libérés, afin que SAP puisse modifier ses éléments internes sans les casser.
• La configuration est préférée au code partout où le standard propose un paramètre.
• L'intégration passe par des interfaces libérées et documentées plutôt que par un accès direct aux tables.
• Les données et l'exploitation suivent les standards actuels, afin que le système reste maintenable.

Un système peut comporter de nombreuses extensions et rester conforme au clean core, tant que chacune ne dépend que de ce que SAP s'est engagé à maintenir stable. Le clean core est donc une règle sur les dépendances, et non une interdiction de se différencier.

Les recommandations actuelles de SAP classent les objets spécifiques en quatre niveaux, que SAP Cloud ALM utilise pour rendre compte d'une part clean core :

Des documents SAP plus anciens décrivent un modèle d'extensibilité à trois tiers d'intention comparable, et les deux vocabulaires figurent encore dans la documentation SAP. Les niveaux clean core transforment le principe en quelque chose qu'une équipe peut mesurer objet par objet.

• Mises à niveau prévisibles : les extensions qui n'utilisent que des API libérées continuent de fonctionner d'une release à l'autre, ce qui réduit les tests de non-régression et les projets de mise à niveau.
• Compatibilité cloud : les mêmes règles s'appliquent dans SAP S/4HANA Cloud Public Edition, de sorte qu'une équipe on-premise qui les suit garde ses options ouvertes.
• Une échelle de décision commune : d'abord le standard, puis l'extensibilité key user, puis l'extensibilité développeur, puis le side-by-side ; cette séquence donne aux architectes et aux consultants un langage commun.
• Mesurabilité : les contrôles ABAP Test Cockpit et la classification par niveaux rendent les progrès visibles plutôt qu'anecdotiques.
• Coût réduit à long terme : moins de modifications signifie moins d'ajustements lors des support packages et des changements de release.

Pour toute organisation qui souhaite rester sur les releases SAP actuelles, le clean core est la politique d'extension que les outils et les recommandations de SAP sont conçus pour soutenir.

• Il ne décide pas de ce qu'il faut construire. Le clean core régit la manière dont une extension dépend de SAP, pas l'intérêt de construire l'exigence qui la motive.
• Il déplace la complexité au lieu de la supprimer. Une extension side-by-side est propre du point de vue du core, mais elle ajoute intégration, identité, supervision et un second cycle de vie.
• La couverture des API est inégale. Faute d'API libérée, les équipes se replient sur le niveau C ou attendent, et ce manque est une plainte fréquente dans les communautés de praticiens.
• Le code hérité prend des années. Les grandes bases de code de l'ère ECC progressent niveau par niveau ; la mesure montre la distance, pas le chemin.
• La responsabilité est hors du périmètre. Une extension peut être parfaitement conforme au clean core et n'avoir pourtant ni responsable, ni documentation, ni lien avec le processus qu'elle soutient.

Le clean core préserve la capacité de mise à niveau de l'ERP ; la responsabilité, la conception des processus et le coût du paysage environnant restent des questions distinctes.

Parcourez cette échelle de haut en bas et arrêtez-vous à la première option qui répond à l'exigence :

1. Standard ou configuration. Un paramètre, un business role ou une application livrée peut-il la couvrir ?
2. Extensibilité key user. S'agit-il d'un champ personnalisé, d'un contrôle, d'une valeur par défaut ou d'une adaptation de l'interface ? Le besoin d'Alder Manufacturing d'un champ de notation fournisseur sur les commandes d'achat s'arrête ici.
3. Extensibilité développeur. Faut-il du code ABAP spécifique au plus près des données et des transactions SAP S/4HANA ? Construisez-le avec ABAP Cloud on-stack.
4. Side-by-side sur SAP BTP. L'extension sert-elle des utilisateurs externes, combine-t-elle plusieurs systèmes ou nécessite-t-elle son propre cycle de vie ? Un portail en libre-service pour Cedar Office Supply a sa place ici.
5. Extension classique. Uniquement avec une exception documentée, un responsable et un plan pour remonter les niveaux.

La décision clean core se prend exigence par exigence, et la raison de chaque choix doit être consignée là où les architectes pourront la retrouver plus tard.

1. Le traiter comme un nettoyage ponctuel. Sans contrôles dans le processus de développement, de nouveaux objets de niveau C et D apparaissent après la fin du projet.
2. Interdire purement et simplement le niveau C. Certaines exigences n'ont pas encore d'API libérée ; un objet de niveau C surveillé peut être le choix honnête.
3. Compter les objets plutôt que le risque. Une seule modification dans une routine centrale de comptabilisation pèse plus que de nombreux reports inutilisés.
4. Tout déplacer vers SAP BTP. Le side-by-side n'est pas automatiquement plus propre si l'extension a toujours besoin d'interfaces non libérées.
5. Oublier la couche d'interface. Les applications SAP Fiori copiées et modifiées comportent leur propre risque de mise à niveau ; les mécanismes d'extension d'interface de SAP, comme les adaptation projects, sont la voie la plus sûre.

La plupart des échecs du clean core sont des échecs de gouvernance qui se manifestent plus tard sous forme d'effort de mise à niveau.