Make or Buy?

by Giovanni Foschini on 25 maggio 2010

Person hold spanner

Le mie responsabilità commerciali mi portano ad incontrare software house che stanno decidendo come sviluppare la prossima generazione dei propri prodotti e il problema che si presenta è spesso ben sintetizzato dalla frase: Make or Buy?

Il taglio di questa domanda è diverso rispetto ai clienti finali: per una software house Make significa fare tutto da soli partendo da zero, mentre Buy vuol dire sviluppare a partire da un framework esistente. Nel passato la scelta primaria era il Make, oggi invece, a causa della complicazione e della rapida obsolescenza delle infrastrutture web, rispondere a questa domanda è diventato più difficile.

Decidere per il Make sembra garantire l’autonomia e la libertà nelle decisioni da prendere, ma presto si evidenziano altri vincoli, imposti dai costi e dai tempi necessari per sviluppare via web quanto si è deciso: la libertà e l’autonomia si devono piegare alle leggi economiche e si finisce per arrivare a compromessi poco onorevoli. Dall’altro lato, scegliere il Buy non è meno delicato: si rischia di investire tempo e denaro in qualcosa che sembra promettente, ma nel tempo può trasformarsi in un catenaccio poco piacevole.

Come è possibile superare questa dicotomia? Credo che sia interessante parlarne e, per iniziare, metto in campo il percorso che stiamo facendo: le applicazioni create con Instant Developer si basano su un framework flessibile, pensato per essere modificato e personalizzato nei suoi comportamenti interni e di interfaccia utente senza perdere le caratteristiche di sviluppo rapido (RAD) che lo caratterizzano.

Attualmente sono stati previsti tre livelli di flessibilità a livello di framework:

  1. Nel framework “document orientation” è possibile creare servizi trasversali tramite tecniche di aspect oriented programming (AOP) che modificano i comportamenti del framework nei confronti della gestione degli oggetti del business model.
  2. A livello di gestione dell’interfaccia utente è possibile creare servizi UI che modificano il funzionamento del framework nella gestione delle videate e degli oggetti in esse contenuti.
  3. A livello di definizione globale del tema grafico e dei comportamenti lato browser è possibile personalizzare il framework RD3 per adattarlo ed estenderlo con i propri componenti.

Come sentite questo problema? Ci sono valide soluzioni alternative? Avete iniziato a provare i livelli di personalizzazione descritti? Queste sono le domande con cui vorrei iniziare una discussione con voi.

Leave a Comment

Previous post:

Next post: