Consideriamo un requisito ipotetico di controllo degli ordini già approvato per una migrazione SAP. L’implementazione esistente legge i dati SAP, applica una validazione e blocca una registrazione non valida. Spostare quel codice in un’applicazione esterna potrebbe soddisfare una preferenza architetturale lasciando però senza risposta la domanda essenziale: il progetto proposto può ancora applicare il controllo al confine transazionale richiesto?
Una strategia SAP clean core per le estensioni dovrebbe preservare i comportamenti aziendali necessari attraverso meccanismi supportati, non assegnare ogni estensione a un runtime separato. Le indicazioni SAP sull’estensibilità distinguono le estensioni strettamente accoppiate dalle applicazioni debolmente accoppiate e le indirizzano verso opzioni implementative differenti. Per architetti e sponsor della migrazione, il risultato concreto è una scheda decisionale per ogni funzionalità: cosa accade all’implementazione esistente, perché la collocazione scelta è adeguata e quali dipendenze irrisolte ne impediscono l’approvazione.
Separare la funzionalità da mantenere dal codice esistente
Approvare una funzionalità aziendale non significa approvare la migrazione della sua implementazione attuale senza modifiche. La scheda per approvare le personalizzazioni ERP definisce la decisione precedente: approvare il requisito prima di scegliere l’implementazione e considerare le responsabilità continuative per gestione, interfacce, test e supporto. Qui assumiamo che il requisito abbia superato questa verifica. Il compito è stabilire come debba funzionare nell’ambiente SAP di destinazione.
Iniziate la scheda decisionale con una descrizione aziendale, non con un elenco di oggetti. Indicate il responsabile del processo, il risultato richiesto e la condizione di accettazione. Aggiungete poi le dipendenze tecniche esistenti: oggetti custom, modifiche, implementazioni di enhancement, letture e scritture dei dati, elaborazioni pianificate, interfacce e sistemi a valle che li utilizzano. Chiedete al team tecnico di dimostrare come queste dipendenze contribuiscano al risultato approvato.
Assegnate all’implementazione un esito esplicito:
- Dismettere: rimuovere un’implementazione ridondante preservando altrove la funzionalità approvata. Se è la funzionalità stessa a non essere più necessaria, rimettete la decisione al responsabile aziendale.
- Sostituire con lo standard: dimostrare che funzionalità e configurazione di destinazione soddisfano la condizione di accettazione, quindi rimuovere l’implementazione su misura.
- Adattare all’interno del core SAP: individuare un meccanismo di estensione supportato, adeguato alla prossimità richiesta rispetto a dati, transazioni o comportamento applicativo.
- Spostare side-by-side: verificare che l’accesso remoto supportato e un ciclo di vita operativo separato siano adatti al requisito.
- Bloccare: mantenere una scelta provvisoria assegnando un responsabile alla questione irrisolta, invece di presentare una preferenza architetturale come un progetto approvato.
Tenete separati i risultati delle analisi tecniche dalla decisione sull’implementazione. Per ogni rapporto di analisi utilizzato nella migrazione del codice custom SAP, registrate ambito, ipotesi sull’ambiente di destinazione e limiti documentati. Chiedete al team di spiegare la conseguenza aziendale di ciascun rilievo. Un rilievo tecnico dovrebbe orientare la decisione, non sostituire l’accettazione del responsabile del processo né dimostrare che una sostituzione preservi il comportamento richiesto.
Rendere deployment, release e supporto delle interfacce condizioni di approvazione
Il solo nome del prodotto di destinazione è troppo impreciso per una scheda relativa a un’estensione. Specificate se il deployment proposto è Public Edition, Private Edition oppure on-premises, insieme alla release e ai componenti pertinenti. Richiedete poi documentazione aggiornata, specifica per l’ambiente di destinazione, sul meccanismo proposto. Non trasferite a questa decisione l’approvazione di un meccanismo ottenuta per un altro deployment o un’altra release senza verificarne l’applicabilità.
La guida SAP all’estensibilità ABAP indirizza gli scenari strettamente accoppiati verso l’estensibilità key-user o developer on-stack. Tra gli esempi figurano la modifica congiunta dei dati del cliente e di SAP con coerenza transazionale, l’estensione dell’interfaccia utente o del modello dati di un’applicazione e l’implementazione di un punto di estensione applicativo. Questo giustifica la valutazione di una soluzione on-stack. Non dimostra però che il punto di estensione necessario esista per la specifica applicazione e per l’ambiente di destinazione.
Per una possibile soluzione on-stack, chiedete se il requisito sia compatibile con un meccanismo key-user disponibile oppure richieda un’implementazione professionale da parte di sviluppatori. Fate individuare al team il punto di estensione effettivo e ogni oggetto SAP utilizzato dal progetto. Se propone ABAP Cloud, richiedete evidenze sulle restrizioni del linguaggio applicabili, sulle dipendenze consentite e sui requisiti relativi agli oggetti rilasciati nell’ambiente di destinazione. Non approvate un progetto solo perché la proposta usa la terminologia corretta.
Applicate lo stesso rigore alle API rilasciate da SAP. Registrate l’interfaccia esatta, le operazioni richieste, il modello di utilizzo consentito, lo stato di rilascio, il contratto di compatibilità applicabile e le restrizioni documentate. Un’interfaccia di lettura non dimostra che un’operazione di scrittura sia supportata. Quando il progetto dipende da un evento, verificatene il significato e gli accessi successivi necessari, senza considerare la notifica come un’integrazione aziendale completa.
Risolvete queste dipendenze insieme alla pianificazione della migrazione. Utilizzate il registro dell’orizzonte di manutenzione SAP ECC per collegare le decisioni sull’ambiente di destinazione e sulle interfacce al piano complessivo di transizione. Mantenete visibile una dipendenza irrisolta da un’API o da un punto di estensione come un blocco alla realizzazione, assegnandole un responsabile decisionale, invece di nasconderla in una stima generale dello sviluppo.
Lasciare che il confine transazionale determini la prima ipotesi di collocazione
La collocazione diventa più chiara quando il responsabile del processo specifica quali operazioni debbano riuscire o fallire insieme. SAP indica l’estensibilità side-by-side su SAP BTP come scelta predefinita per le applicazioni debolmente accoppiate che utilizzano dati replicati o API remote e non richiedono che dati custom e dati del core vengano modificati insieme nella stessa transazione. Questa distinzione è più utile di un’istruzione generalizzata a spostare il codice custom fuori dal core.
Scenario ipotetico: validazione prima di una registrazione
Supponiamo che un controllo obbligatorio debba respingere una transazione aziendale non valida prima della registrazione, utilizzando i valori correnti della transazione stessa. Considerate un’implementazione on-stack come candidata iniziale, perché il requisito richiede uno stretto accoppiamento transazionale. L’approvazione dipende comunque dall’individuazione di un punto di estensione supportato che disponga dei dati necessari e intervenga nel momento richiesto. Né questo scenario né le indicazioni generali sulla collocazione confermano che tale punto esista.
Chiedete al team di dimostrare una registrazione accettata, una respinta e lo stato aziendale risultante. Se propone invece una validazione remota, richiedete una spiegazione precisa di cosa accada quando la risposta tarda ad arrivare o non è disponibile. Il responsabile del processo deve accettare il comportamento durante l’attesa, la gestione dei guasti e la copertura del controllo su tutti i percorsi di registrazione pertinenti. Il solo successo di una chiamata remota non costituisce un test di accettazione sufficiente.
Scenario ipotetico: workflow esterno di revisione documentale
Supponiamo ora che un team esterno esamini i documenti di supporto dopo la creazione di un record e che l’azienda accetti uno stato di attesa mentre la revisione prosegue. La collocazione side-by-side è una candidata iniziale ragionevole se la revisione non deve essere confermata atomicamente insieme alla transazione SAP originale. Prima dell’approvazione, verificate l’accesso supportato al record, l’operazione di aggiornamento richiesta e il modello di comunicazione consentito nello specifico ambiente di destinazione.
Testate cosa accade se la revisione termina dopo un annullamento, un aggiornamento viene respinto, una risposta va persa o lo stesso completamento viene inviato nuovamente. Richiedete che il progetto spieghi la gestione dei duplicati, la riconciliazione e le procedure di ripristino autorizzate. Se il requisito cambia e la revisione deve impedire la registrazione originale, riaprite la decisione sulla collocazione. È cambiato il requisito transazionale, non soltanto un dettaglio dell’integrazione.
Completare la matrice decisionale con evidenze operative
Un diagramma architetturale non basta ad assegnare le responsabilità continuative. Le indicazioni SAP per scegliere l’opzione di estensibilità distinguono la gestione del ciclo di vita integrata con il core, propria dello sviluppo custom ABAP e delle estensioni key-user, dalla gestione separata del ciclo di vita delle estensioni side-by-side. Attribuiscono la stabilità del ciclo di vita side-by-side ad API ed eventi stabili, non semplicemente alla separazione dal core.
Traducete questa distinzione in attività con responsabilità assegnate. Chiedete chi rilascia l’estensione, chi verifica la compatibilità con l’ambiente SAP di destinazione e chi accetta il workflow aziendale completo dopo una modifica su uno dei due lati. Non approvate una presunta riduzione del lavoro di aggiornamento o dei costi solo perché l’implementazione viene spostata altrove.
| Campo della scheda | Evidenza o decisione richiesta |
|---|---|
| Funzionalità e responsabile aziendale | Risultato approvato, condizione di accettazione e responsabile autorizzato ad accettare cambiamenti di comportamento. |
| Dipendenze attuali | Inventario tecnico collegato ai percorsi effettivi del processo, agli accessi ai dati e ai sistemi utilizzatori a valle. |
| Destinazione ed esito | Deployment, release, componenti pertinenti e decisione di dismettere, sostituire, adattare, spostare o bloccare. |
| Meccanismi supportati | Documentazione specifica per la destinazione su punti di estensione, API, eventi, contratti di rilascio e restrizioni. |
| Transazione e latenza | Operazioni da confermare insieme, comportamento di attesa consentito, aggiornamento dei dati e risultati misurati dei test di accettazione. |
| Guasti e autorizzazioni | Modello delle identità, permessi aziendali, operazioni respinte, gestione dei duplicati e autorità di ripristino. |
| Monitoraggio e ciclo di vita | Rilevamento delle eccezioni, responsabile della riconciliazione, responsabilità del deployment, test di aggiornamento e responsabile degli interventi correttivi. |
| Prerequisiti e blocchi | Verifiche su runtime, connettività, diritti di utilizzo e aspetti commerciali; questioni irrisolte con responsabili decisionali assegnati. |
Per le autorizzazioni, richiedete test sia delle azioni consentite sia di quelle negate, includendo l’esecuzione in background quando pertinente. Per il monitoraggio, chiedete al team di mostrare come un operatore distingua il trasferimento riuscito di un messaggio dal completamento effettivo dell’operazione aziendale. Individuate chi riconcilia un disallineamento e chi può autorizzare un’azione correttiva.
Per una proposta side-by-side, confermate runtime e servizi scelti, relativi prerequisiti, responsabilità operative e diritti di utilizzo applicabili prima di autorizzare l’implementazione. Mantenete queste verifiche associate alla scheda decisionale. Una collocazione tecnicamente plausibile dovrebbe restare provvisoria finché l’organizzazione non è in grado di supportarla e gestirla.
Approvare il lavoro di migrazione solo quando i blocchi sono espliciti
Trasformate ogni esito approvato in un pacchetto di lavoro per la migrazione: eliminare le dipendenze obsolete, configurare la soluzione sostitutiva, adattare l’estensione supportata oppure costruire e collegare l’applicazione esterna. Includete nel pacchetto il trattamento dei dati, le modifiche alle autorizzazioni, le procedure per le eccezioni e l’accettazione aziendale. Non chiudetelo solo perché il codice compila o un’interfaccia restituisce una risposta positiva.
Registrate cosa potrebbe modificare la raccomandazione. Una funzionalità standard dimostrata può eliminare lo sviluppo su misura; l’assenza di un’operazione di scrittura supportata può bloccare la collocazione side-by-side; un requisito di atomicità può favorire una soluzione on-stack; un processo di ripristino senza responsabile dovrebbe impedire l’approvazione operativa. Mantenete verificabile la motivazione della decisione, affinché il cambiamento di un’ipotesi faccia scattare una revisione.
Prima di approvare il prossimo pacchetto di lavoro relativo a un’estensione, completatene la scheda decisionale con il responsabile del processo e il referente della manutenzione tecnica, quindi risolvete il blocco che più probabilmente potrebbe modificarne la collocazione. Se vi serve supporto per valutare il lavoro di migrazione del codice custom SAP o implementare l’approccio scelto, discutete i vostri requisiti con gli specialisti funzionali e tecnici SAP di Digiventi.
