Jeff Sussna, voce di spicco nella comunità DevOps crede nell'approccio “moving fast without breaking things”, e aiuta le organizzazioni a evolversi verso la formazione di team ad alte prestazioni all'interno di un ecosistema agile di persone, prodotti, pratiche e promesse.
Di recente è stato intervistato da Matt McLarty, Global Leader for API Strategy presso MuleSoft, in merito a quali tecniche efficaci possono essere impiegate per implementare un programma API.
Vediamo insieme i punti salienti dell’intervista.
MuleSoft: Nel tuo libro del 2015, Designing Delivery, sottolinei l’importanza del design thinking per le aziende di software delivery. In che modo pensi che le aziende di software possano beneficiare maggiormente di questo approccio?
Jeff Sussna: Nell’IT moderno, qualunque cosa facciamo, a qualunque livello, lo scopo principale è soddisfare le esigenze dei clienti.
Qualsiasi attività svolgiamo, dall'esecuzione di database alla gestione di un helpdesk, lo facciamo per aiutare i nostri clienti a raggiungere determinati obiettivi. Dobbiamo quindi integrare principi e pratiche di progettazione “human-centered” all'interno del nostro lavoro.
Le domande che dobbiamo porci sono le seguenti:
- "Chi trarrà vantaggio da questa capacità e come?"
- "Qual è l’apporto che possiamo fornire per facilitare il loro progetto?"
- "Di cosa hanno bisogno per poter utilizzare facilmente e con successo qualsiasi servizio che forniamo?"
MuleSoft: Nella comunità delle API, parliamo sempre di "gestire le API come prodotti" per cercare di spostare la mentalità dei team tecnici dalla visualizzazione delle API come interfacce a veri e propri servizi software.
Di recente, hai parlato del cambiamento di approccio che passa dal pensiero di prodotto a quello di servizio. Puoi dirci qualcosa in merito?
Jeff Sussna: L'obiettivo di questo passaggio è modificare il nostro approccio per la realizzazione di veri e propri servizi. Per essere veramente utili, dobbiamo pensare oltre le funzionalità.
Per quanto riguarda le API, uno degli aspetti che mi frustra sono i team che vedono gli API test server come attività private. "È solo un server di prova; se è inattivo da settimane è perché abbiamo cose più importanti da fare ".
Altri team che utilizzano la tua API potrebbero aver bisogno di testarla. Per loro, il tuo server di prova potrebbe essere una risorsa e magari hanno bisogno che sia disponibile per svolgere il proprio lavoro di sviluppo, che fa parte del processo di erogazione del servizio.
MuleSoft: Tu hai creato il concetto di “promise-driven design”. Puoi spiegare cos’è e che valore apporta ad un’organizzazione?
Jeff Sussna: Una promessa è l'intenzione di facilitare il raggiungimento del risultato desiderato per il cliente. Il software di scansione di sicurezza, ad esempio, potrebbe promettere di aiutarti a trovare eventuali minacce in pochi minuti, anziché in ore.
Le promesse fanno luce su due importanti aspetti del servizio. Il primo è la connessione con i risultati, non solo con le funzionalità. Il fatto che la soluzione garantisca il rilevamento di minacce in pochi minuti anziché ore, è chiaro.
È facilmente comprensibile il perché dovrei acquistare quel software. Il secondo aspetto ha a che fare con il fatto che le promesse non sempre vengono mantenute. Questo è un aspetto positivo: avendo chiara la possibilità di fallimento, le promesse ci aiutano ad aumentare le nostre possibilità di successo.
Il design promise-driven si basa su una semplice serie di domande per garantire un miglioramento continuo e incentrato sul cliente:
- Quali promesse stiamo facendo? Cosa si aspettano da noi?
- Quanto manteniamo le nostre promesse? Come possiamo migliorare la nostra capacità di mantenerle?
- Sono le giuste promesse da fare? Stiamo facendo promesse che non possiamo mantenere o possiamo spingerci oltre?
Queste domande generano nuove opportunità per un design user-centered. Il processo promise-driven design spazia dal marketing del prodotto, alla progettazione delle API, all'architettura di sistema resiliente, alle recensioni sugli incidenti, alle retrospettive.
MuleSoft: Considereresti i contratti API come una promessa da parte delle aziende?
Jeff Sussna: Sì. Queste promesse vanno oltre il semplice livello di aspettative funzionali (“questa REST call ti mostra i dettagli dell'account che sei autorizzato a vedere e non quelli di cui non hai autorizzazione”) ed esprime anche i cosiddetti requisiti non funzionali ("la nostra API promette la disponibilità di 5-9", "la nostra API promette di restituire risultati in <50 millisecondi", ecc.).
MuleSoft: Come esperto delle comunità Agile e DevOps hai visto una correlazione nelle società con cui lavori tra le pratiche Agile e DevOps e la prima architettura API?
Jeff Sussna: Le pratiche Agile e DevOps riguardano fanno parte di ecosistemi complessi. Le informazioni più utili per i tuoi clienti sono quelle che possono utilizzare con flessibilità. I team ad alte prestazioni utilizzano le architetture API-first per abilitare sistemi di delivery dinamici che aiutano le organizzazioni ad adattarsi e innovare continuamente.
MuleSoft Anypoint Platform è la piattaforma che consente di integrare facilmente tutti i sistemi IT. Gli oltre 120 connettori Plug & rendono l’integrazione dei diversi sistemi e software dell’azienda (ERP e gestionali, software CRM, Suite Microsoft, Salesforce, Oracle, SAP, NetSuite, sistemi SOA, applicazioni SAAS ed API) semplice, veloce e flessibile.
Per avere maggiori informazioni sulla soluzione invia una mail a cio@florence-consulting.it o chiama lo (055) 538-3250.
In alternativa, puoi compilare il form sottostante con la tua domanda.