Connettori riusciti: Best practice e strategie di implementazione

La migliore pratica con i Connettori è sempre quella di forzare un approccio basato su regole e affrontare eventuali eccezioni come conseguenza o esaurimento delle regole, piuttosto che iniziare con un approccio basato sulle eccezioni.

L'approccio basato sull'eccezione è allettante e attraente perché valorizza la scelta umana e la conservazione dell'attuale struttura del processo. Ma traccia un vettore verso un luogo che non offrirà buone alternative per scalare e sostenere processi sani a lungo termine. A questo proposito, iniziare a pensare alle eccezioni invece che alle regole è un errore che evitiamo a tutti i costi.

Guadagno a breve termine per dolore a lungo termine in poche parole. La maggior parte delle Organizzazioni con cui lavoriamo condivide questo in comune: cercano di preservare i processi attuali. Quando si cerca la tecnologia, si intende abbracciare il processo attuale anziché trovare un compromesso tra le limitazioni del processo e l'efficienza.

I nostri Connettori sono un modo per collegare il flusso di Contenuto da un repository a BWX e poi indietro. Mentre comprendiamo la necessità occasionale di selezionare un file o un altro per un lavoro basato su connettori, la migliore pratica per i connettori è seguire un approccio basato su regole anziché un approccio manuale.

‍La tentazione dell'approccio manuale spiegata

‍Gli approcci manuali sono allettanti perché non richiedono alcun cambiamento di processo. Le persone possono esplorare il file esatto che desiderano tradurre e avviare un progetto di traduzione utilizzando il connettore. Il problema con l'approccio manuale è che non è scalabile, non è sostenibile e non è prevedibile (difficile da migliorare).

Questo è il motivo per cui esploriamo l'approccio manuale solo dopo aver esaurito tutte le possibilità di adattare il comportamento del connettore in un comportamento basato su regole. È necessario gestire le eccezioni, ma non è possibile progettare per eccezione.

Un prodotto di successo e la sua rispettiva implementazione si basano su regole che coprono la più ampia percentuale possibile di casi d'uso. I casi d'uso che rimangono scoperti devono essere valutati attentamente per esplorare le soluzioni alternative e le Soluzioni al fine di strumentarli all'interno dei paradigmi proposti.

Ecco un esempio: il cliente A ha un connettore che funziona in base a un programma, ma occasionalmente hanno progetti che richiedono un'esecuzione fuori programma. Ecco alcune opzioni diverse su come affrontare questo:

1. Richiedi manualmente un'esecuzione fuori programma al nostro team di assistenza
2. Utilizza la nostra CLI per richiedere un'esecuzione fuori programma
3. Crea un ramo/directory fuori ciclo che viene controllato più frequentemente rispetto al programma tipico per raccogliere lavori urgenti.

Ecco un altro esempio: il client B è abituato a selezionare i file per avviare il processo di localizzazione. Piuttosto che perpetuare l'approccio manuale, la maggior parte dei processi di cherrypicking segue un comportamento che può essere decodificato.

Vale sempre la pena spingere questa ingegneria inversa ai suoi limiti. Se inizi con un approccio manuale o ti concentri sulla copertura delle eccezioni giusto dall'inizio tramite l'interfaccia utente, questo diventerà poi una stampella debilitante piuttosto che un acceleratore del programma. Quando pensiamo a un connettore, pensiamo sempre all'Automazione.

Questa è la vera efficienza del processo guidata da un connettore. Esportare e importare progetti è un piccolo guadagno quando si tratta di connettori. Il vero guadagno ruota attorno alle regole aziendali e alla prevedibilità e governance che generano.

Il problema è che se progetti e implementi per eccezione, l'Automazione non diventa mai davvero un'opzione. L'Automazione per definizione richiede un certo grado di cambiamento del processo e se non spingiamo per questa aderenza tra processo e software finiamo per non superare le aspettative e diventare venditori della digitalizzazione del caos.

Questo non è ciò che rappresentiamo e non abbracceremo questo. I connettori su piccola scala devono seguire lo stesso design e principi dei connettori su larga scala in modo che possano scalare e crescere in modo efficiente. La maggior parte dei programmi di localizzazione richiede Soluzioni basate su casi d'uso attuali (che in realtà sono passati) anziché su casi d'uso orientati al futuro che prevedono più file, più cadenza, più località, meno tempo per il lancio sul mercato, meno costi e più persone che lavorano insieme.

Se non parti nel corretto quadro di riferimento, correggere il corso in seguito è costoso e molto impegnativo perché perderai la finestra di cambiamento introdotta da una nuova implementazione. Tutti i nostri Connettori, grandi o piccoli, si basano su regole e parametri.

Sono governati dagli stessi principi di progettazione e nessuno di essi richiede un'interfaccia utente per funzionare correttamente. L'interfaccia utente può essere un interessante add-on per un connettore maturo, ma principalmente per cambiare facilmente le configurazioni del connettore piuttosto che come un modo per avviare manualmente i progetti.

Non possiamo promuovere il successo a lungo termine se siamo complici dell'accelerazione dei processi analogici esistenti.  

Piuttosto, il nostro obiettivo è tradurre i processi analogici in un pensiero digitale in modo che diventino veramente compatibili con il software, permettendo l'automazione orientata ai dati. Siamo abituati a gestire Connettori che elaborano migliaia di file al giorno in quasi cento località diverse.

Abbiamo imparato nel corso degli anni che gli stessi ingredienti che rendono un grande Connettore di successo devono essere rispettati anche per i Connettori su piccola scala, al fine di aderire ai principi di base del design di scalabilità e sostenibilità.