In che modo le aziende produttrici di software decidono tra la costruzione interna di componenti software anziché l’acquisto da terze parti?

Ehi, ho scritto una guida per la costruzione e l’acquisto specificamente orientata verso gli sviluppatori. È fondamentalmente un modello decisionale.

La guida per gli sviluppatori alla costruzione e all’acquisto di servizi

Definizione di un processo per la selezione obiettiva di soluzioni nostrane o acquistate

Per quasi tutti i componenti applicativi funzionali o architettonici, esistono numerose offerte “come servizio”. Vediamo infrastruttura come servizio (IaaS), backend come servizio (BaaS), SaaS, PaaS .. e un nuovo “aaS” sembra essere aggiunto quotidianamente.

Cosa hanno in comune tutti questi servizi? Bene, promettono di offrire a te, ingegnere, (1) maggiore libertà di concentrarsi sul tuo prodotto principale, (2) tempi di immissione sul mercato più rapidi e (3) soluzioni pronte per la produzione per operazioni di ingegneria complesse e ripetibili.

A volte questo è il caso. A volte no. Lo scopo di questa guida è fornire una serie razionale di criteri oggettivi per valutare se è necessario costruire o acquistare un determinato servizio.

Cos’è build? Cosa è comprare?

Costruire non significa necessariamente che stai facendo qualcosa da zero. Significa che stai combinando codice personalizzato, librerie open source ed esperienza individuale / della comunità per costruire una soluzione per il tuo caso d’uso. Questa soluzione è qualcosa che progetterai, costruirai, eseguirai, manterrai e ridimensionerai internamente.

D’altra parte, comprare non significa necessariamente che stai acquistando una soluzione end-to-end, pronta all’uso per il tuo caso d’uso. Rappresenta in modo più accurato l’acquisto di un servizio definito che aggiunge un valore quasi immediato al tuo caso d’uso. In genere, la redditività del servizio stesso sarà garantita dal venditore e non sarà necessario progettare e costruire il servizio stesso. Tuttavia, a seconda del tipo di servizio acquistato, è possibile scegliere di eseguirlo e ridimensionarlo internamente. Generalmente, scaricherai la gestione, la manutenzione e la scalabilità per il venditore.

La mente dello sviluppatore

Prima di continuare, ripristiniamo il nostro stato d’animo.

Molti sviluppatori hanno un forte ego e questo è generalmente un attributo che abilita. I forti ego danno agli sviluppatori la fiducia necessaria per alimentare ostacoli complessi, concentrarsi per giorni e settimane alla volta e coltivare industrie completamente nuove. Tuttavia, esiste una linea sottile tra fiducia ragionevole e irragionevole.

“Posso costruire ____ in ____ giorni!”
“Ah! Posso costruire un ____ migliore in un fine settimana! ”
“Questo è così costoso. Ho intenzione di costruirlo. ”

Spesso vediamo e ascoltiamo questi commenti sui forum degli sviluppatori, aggregatori come Reddit e HackerNews e nelle nostre interazioni quotidiane. Se non lo diciamo, allora alcuni di noi probabilmente lo pensano di tanto in tanto. Ehi, a volte probabilmente abbiamo ragione, ma a volte la nostra reazione iniziale guidata dall’ego ci allontana dai criteri oggettivi che applichiamo alla nostra pratica generale di programmazione.

Nel valutare cosa costruire e acquistare o quale rapporto scegliamo, è fondamentale ripristinare il nostro stato d’animo e affrontare la nostra soluzione nel modo più aperto e oggettivo possibile. Escludendo i puristi, a nessuno importa se siamo stati in grado di costruire il nostro prodotto da zero o se abbiamo abilmente integrato una serie di soluzioni acquistate insieme. Ciò che interessa alle persone è se il nostro prodotto funziona e offre un valore eccezionale ai clienti.

Con il processo decisionale build vs buy, risponderemo alla domanda: “Come possiamo offrire un valore eccezionale ai nostri clienti in modo rapido, efficiente e prudente?”

Build vs Buy Modello decisionale

Passaggio 1: identificare e classificare l’ambito funzionale del prodotto

Il tuo team ha avuto il compito di creare una piattaforma di e-commerce che consenta agli utenti di votare e votare i prodotti. Quindi, quali sono le caratteristiche funzionali e architettoniche del tuo prodotto?

Funzionale

  • Servizio di marketplace
  • Servizio di voto
  • Servizio di visualizzazione del prodotto
  • Servizio di gestione dell’inventario
  • Servizio di transazione
  • Servizio di gestione account acquirente, venditore e amministratore
  • Cerca, filtra, perfeziona il servizio

Architettonico e di processo

  • Banche dati
  • server
  • Bilanciatori di carico
  • Ambiente di sviluppo / Controllo versione
  • Pipeline di integrazione / consegna continua
  • API REST / Realtime
  • Frontend Framework
  • Controlli di distribuzione / Test AB

Sebbene questi non siano set di funzionalità completi, il punto importante è che esiste una chiara distinzione tra le funzionalità principali del prodotto (mercato, votazione) e l’architettura di sistema e di processo necessaria (ambiente server, pipeline CI / CD). Esistono funzionalità proprietarie e uniche del tuo prodotto e alcune caratteristiche architettoniche che si trovano in quasi tutti i moderni sistemi applicativi.

Il tuo compito è identificare quali di queste funzionalità sono proprietarie della tua piattaforma e quali sono soluzioni comprovate replicabili. Per fare questo, poni le seguenti domande:

  • Quali sono le caratteristiche proprietarie e fondamentali che rendono unica la mia applicazione?
  • Di quali servizi architettonici ho bisogno per il mio ponteggio a piattaforma?
  • Come sarà la mia pipeline di sviluppo ideale?

Tieni presente che non stiamo ancora risolvendo o decidendo cosa costruire e acquistare. Stiamo identificando e classificando la funzionalità del nostro prodotto.

Passaggio 2: definire l’ambito del lavoro e riconciliarsi con i vincoli

Sulla base della categorizzazione delle funzionalità nel passaggio 1, è tempo di definire l’ambito di lavoro per creare ciascuna funzionalità.

Innanzitutto, ordina e assegna le priorità alle funzionalità dettagliate per ogni funzione:

  • Qual è l’ambito funzionale minimo affinché la funzionalità sia praticabile?
  • Qual è l’ambito funzionale ideale per la funzione?
  • È una funzionalità di cui ho bisogno ora? O può aspettare?

In secondo luogo, per ogni funzione, rispondi alle seguenti domande di build per l’ambito funzionale minimo e ideale:

  • Quante risorse per sviluppatori sono disponibili per creare questa funzione? Mantenere questa funzione?
  • Posso utilizzare esperti di dominio per aiutare a progettare questa funzione?
  • Qualcuno del mio team l’ha mai realizzato prima?
  • Quanto tempo per progettare (A), costruire (B), testare ©, distribuire (D), mantenere (E) questa funzione?
  • Costruire questo deviare le risorse da qualcos’altro?
  • Devo assumere risorse aggiuntive? In tal caso, qual è la ripartizione dei costi?
  • Qual è il costo dell’infrastruttura per eseguirlo internamente?

In terzo luogo, per ciascuna funzionalità principale, rispondi alle seguenti domande di acquisto per l’ambito funzionale minimo e ideale:

  • Qual è il mio budget mensile per questo servizio?
  • Come posso prevedere che il mio budget cambi nel tempo?
  • Posso utilizzare esperti di dominio per aiutarmi a valutare la soluzione migliore?
  • Quali risorse per sviluppatori sono disponibili per integrare e configurare la soluzione?
  • Se applicabile, avrò le risorse per ospitare autonomamente, eseguire, gestire e ridimensionare il servizio?

Passaggio 3: divergenza della soluzione

Ora possiamo arrivare alle cose buone! In questo passaggio, non stiamo decidendo cosa costruire o acquistare; piuttosto, stiamo aggregando un inventario di scelte.

Innanzitutto, setacciare gli interwebs, ottenere referral e valutare l’ecosistema della soluzione. Altri team lo hanno costruito con successo? L’hanno comprato con successo? Quali sono le storie horror e di successo?

In secondo luogo, crea una matrice di confronto build vs buy. Assicurati di annotare i costi mensili, di infrastruttura e di manutenzione a lungo termine. Nota il tempo totale in anticipo e in corso necessario per ogni soluzione di costruzione o acquisto (anche avere ibridi di costruzione / acquisto sono fantastici!).

Passaggio 4: convergenza della soluzione

Inizia a restringere le opzioni.

Ricorda che l’acquisto non significa magia istantanea pronta all’uso. Ci sono sempre costi di costruzione associati all’acquisto:

  • Sandboxing e controllo tecnico iniziale
  • Integrazione e configurazione
  • Configurazione e messa a punto
  • Formazione operativa e onboarding del personale

Allo stesso modo, costruire non significa necessariamente che tutto sia fatto da zero, ma significa che si assumeranno i costi di manutenzione, ridimensionamento e debug in corso. Sarà inoltre necessario formare il personale e sviluppare nuovi processi operativi.

Passaggio 5: compilare o acquistare o entrambi

Scegli un’opzione di soluzione primaria e secondaria per ciascuna funzionalità. In questo modo, si avrà un piano di backup se la soluzione principale non esegue il pan out. È assolutamente fondamentale coinvolgere il proprio team durante il processo di selezione e rendere trasparenti i criteri di selezione.

Passaggio 6: sviluppare linee guida per la rivalutazione

La soluzione che hai selezionato per il primo giorno del tuo prodotto probabilmente non si adatta al tuo prodotto al giorno 600. Va bene, ma dobbiamo essere in grado di anticipare e anticipare eventuali problemi di ridimensionamento futuri. Per fare questo, impostare benchmark sia quantitativi che qualitativi per innescare una rivalutazione del build rispetto all’acquisto. Ad esempio, siamo certi che la nostra attuale soluzione architettonica ci consente di gestire con facilità fino a 500k connessioni simultanee, ma il nostro attuale modello di crescita prevede connessioni da 2m in 8 mesi. Quando iniziamo ad avvicinarci al segno di 300k, ciò attiverà un’altra valutazione build / buy in modo da poter anticipare qualsiasi problema su vasta scala. Questa nuova valutazione dovrebbe includere:

  • Cosa abbiamo imparato sulle esigenze del nostro prodotto negli ultimi X mesi?
  • Cosa è stato più difficile del previsto? Cosa è stato più facile?
  • Come si è spostato il nostro pool di risorse e conoscenze?
  • Le competenze chiave del nostro prodotto sono cambiate?
  • C’è qualcosa di nuovo e di meglio là fuori?

Considerazioni finali: provalo a modo tuo

Bene, sembra molto lavoro. Potrebbe anche essere necessario un giorno o più giorni per valutare una funzione. Ma realisticamente, quando prendiamo in considerazione l’intero ciclo di vita del tuo prodotto, alcuni giorni iniziali possono farti risparmiare mesi e molti soldi lungo la strada. Quei pochi giorni possono anche rendere o rompere il tuo prodotto.

Personalizza il tuo processo di valutazione build / buy per soddisfare le esigenze della tua organizzazione. Sebbene una grande impresa sia molto diversa da una startup, le metriche di valutazione rimangono molto simili. Aggiungi o rimuovi metriche, codifica un processo più raffinato o creane di nuove da zero.

In entrambi i casi, è importante ricordare che costruire un prodotto di successo è molto difficile, quindi non renderlo più difficile del necessario. Lascia che la tua decisione sia guidata scegliendo la soluzione giusta per il tuo prodotto, piuttosto che la soluzione giusta per te.

Fonte originale

Che grande domanda e una che la mia attuale azienda, CloudLink Solutions ha affrontato di recente.

Manterrei lo sviluppo principale in casa e esternalizziamo strumenti, relazioni e integrazioni.

Lo abbiamo fatto con la nostra ultima offerta, il prodotto CloudLink, una soluzione di inventario basata su cloud con POS mobile. Abbiamo svolto il lavoro principale all’interno dell’azienda, ma esternalizzando l’interfaccia a QuickBooks Online e uno dei processori di carte di credito.

Mantiene i gioielli di famiglia vicini a casa e consente agli sviluppatori con esperienza specifica in queste integrazioni di fare “la loro” cosa. Ha inoltre accelerato il nostro “time to market”.

Oltre una certa dimensione aziendale, la risposta si riduce davvero agli incentivi manageriali. Altrimenti non esiste una semplice risposta unilaterale.

Vere intenzioni manageriali

In questo caso particolare ti propongo di andare a pranzo con un CEO di una società di software perché la risposta varia in base alle tue esigenze e dipende dal tuo prodotto.

Costruisci la tua differenziazione, acquista tutto il resto.