Clean Core

O clean core costuma ser reduzido a "nenhum código customizado", o que não corresponde ao que a SAP descreve. O princípio trata de como um sistema se desvia do padrão, não de se ele se desvia:

• Extensões usam APIs e pontos de extensão liberados, para que a SAP possa alterar o funcionamento interno sem quebrá-las.
• Configuração é preferida a código sempre que o padrão oferece um parâmetro.
• Integração passa por interfaces liberadas e documentadas, em vez de acesso direto a tabelas.
• Dados e operações seguem os padrões atuais, para que o sistema continue suportável.

Um sistema pode ter muitas extensões e ainda assim ser clean, desde que cada uma dependa apenas do que a SAP se comprometeu a manter estável. O clean core é, portanto, uma regra sobre dependências, e não uma proibição de diferenciação.

A orientação atual da SAP classifica os objetos customizados em quatro níveis, que o SAP Cloud ALM usa para reportar uma participação de clean core:

Materiais anteriores da SAP descrevem um modelo de extensibilidade em três camadas com intenção comparável, e os dois vocabulários ainda aparecem na documentação da SAP. Os níveis de clean core transformam o princípio em algo que uma equipe consegue medir objeto por objeto.

• Upgrades previsíveis: extensões que usam apenas APIs liberadas continuam funcionando entre releases, o que reduz testes de regressão e projetos de upgrade.
• Compatibilidade com a nuvem: as mesmas regras valem no SAP S/4HANA Cloud Public Edition, então uma equipe on-premise que as segue mantém suas opções em aberto.
• Uma escada de decisão compartilhada: primeiro o padrão, depois a extensibilidade key user, depois a extensibilidade de desenvolvedor, depois o side-by-side, o que dá a arquitetos e consultores uma linguagem comum.
• Mensurabilidade: as verificações do ABAP Test Cockpit e a classificação por níveis tornam o progresso visível em vez de anedótico.
• Menor custo no longo prazo: menos modificações significam menos ajustes em support packages e mudanças de release.

Para qualquer organização que queira se manter nos releases atuais da SAP, o clean core é a política de extensão que as próprias ferramentas e orientações da SAP foram construídas para suportar.

• Não decide o que construir. O clean core governa como uma extensão depende da SAP, não se o requisito por trás dela vale a pena ser construído.
• Desloca a complexidade em vez de removê-la. Uma extensão side-by-side é clean para o core, mas acrescenta integração, identidade, monitoramento e um segundo ciclo de vida.
• A cobertura de APIs é desigual. Onde não existe API liberada, as equipes recorrem ao nível C ou esperam, e essa lacuna é uma reclamação frequente nas comunidades de profissionais.
• Código legado leva anos. Grandes bases de código da era ECC avançam nível a nível; a medição mostra a distância, não o caminho.
• A responsabilidade está fora do escopo. Uma extensão pode ser perfeitamente clean e ainda assim não ter um responsável, documentação ou um vínculo com o processo que suporta.

O clean core mantém o ERP atualizável; responsabilidade, desenho de processo e o custo do landscape ao redor continuam sendo questões separadas.

Desça esta escada e pare na primeira opção que atende ao requisito:

1. Padrão ou configuração. Um parâmetro, um business role ou um app entregue pela SAP resolve?
2. Extensibilidade key user. É um campo customizado, uma verificação, um valor padrão ou uma adaptação de UI? A necessidade da Alder Manufacturing de um campo de avaliação do fornecedor nos pedidos de compra termina aqui.
3. Extensibilidade de desenvolvedor. Precisa de ABAP customizado próximo aos dados e às transações do SAP S/4HANA? Construa com ABAP Cloud on-stack.
4. Side-by-side no SAP BTP. Atende usuários externos, combina vários sistemas ou precisa de ciclo de vida próprio? Um portal de autoatendimento para a Cedar Office Supply pertence a este nível.
5. Extensão clássica. Somente com uma exceção documentada, um responsável e um plano para subir de nível.

A decisão de clean core é tomada por requisito, e o motivo de cada escolha deve ser registrado onde os arquitetos possam encontrá-lo depois.

1. Tratá-lo como uma limpeza pontual. Sem verificações no processo de desenvolvimento, novos objetos de nível C e D aparecem depois que o projeto termina.
2. Proibir o nível C por completo. Alguns requisitos ainda não têm API liberada; um objeto de nível C monitorado pode ser a escolha honesta.
3. Contar objetos em vez de risco. Uma modificação em uma rotina central de lançamento pesa mais do que muitos relatórios sem uso.
4. Mover tudo para o SAP BTP. O side-by-side não é automaticamente mais clean se a extensão ainda precisa de interfaces não liberadas.
5. Esquecer a camada de UI. Apps SAP Fiori copiados e modificados carregam o próprio risco de upgrade; os mecanismos de extensão de UI da SAP, como os adaptation projects, são o caminho mais seguro.

A maioria das falhas de clean core são falhas de governança que aparecem depois como esforço de upgrade.