Il management vuole un'API nel software acquistato

1

La mia azienda vuole acquistare un nuovo software per la nostra contabilità generale. Vogliamo essere in grado di interfacciarlo con vari altri sistemi, tutti acquistati. Niente è personalizzato Il software che i nostri contabili piacciono non ha alcuna API. Tuttavia, consente di importare ed esportare attraverso vari formati di file.

Le importazioni (che sono le più importanti per noi) possono essere attivate da un file di importazione inserito in una cartella. Un "comitato direttivo" coinvolto in questa decisione di acquisto è composto da persone che non sono né persone IT né programmatori. Sono avvocati, amministratori delegati, un addetto alla conformità e pochi altri in ruoli simili. Sono fissate su questo software con un'API o API, che non è più appropriato.

Mi sembra che con la funzionalità di importazione ed esportazione possiamo fare ciò che dobbiamo fare. Dal momento che non scriviamo il nostro software, non potremmo codificarlo su un'API. Ma non ho abbastanza esperienza per sapere veramente cosa potrebbe offrire un'API che il software in questione non è in grado di fornire. Sono presidente del comitato direttivo e vorrei che non venissero segnalati da qualcosa che sospetto sia irrilevante. Qualcuno può aiutarmi a capire cosa potrei mancare, o piuttosto come sarebbe un'API vantaggiosa?

    
posta Mitchell Kaplan 13.02.2013 - 03:01
fonte

2 risposte

3

API = Standardizzazione (in misura molto maggiore dei file di testo)

Avendo trascorso un paio di anni a sviluppare un'applicazione che un determinato cliente voleva interagire con MYOB, raccomanderei seriamente un GL con API.

L'importazione / esportazione di file di testo è un modo orribile per gestire un'azienda.

(SE) hai mai avuto bisogno di personalizzazione del prodotto / modulo la prima cosa che uno sviluppatore sta per fare è costruire un qualche tipo di API se non ne hai già uno. Poi, 6 mesi dopo, è purtroppo morta in un incidente d'auto ... e hai bisogno di un po 'più di personalizzazione. Quindi il prossimo sviluppatore guarda al graffio di un'API avviata dal primo e poi modifica / aggiunge a quello per lo scopo a portata di mano ... e così via ... e in poco tempo hai un frankenstein sulle tue mani .... perché come dici tu non sviluppi in casa e chi dire che qualcuno di questi sviluppatori sono esperti nel modulo GL comunque. Così iniziano a creare le proprie API in base a quello che pensano sia il modulo GL, non necessariamente quello che effettivamente è.

Mentre un prodotto con un'API preformata è direttamente dalla bocca dei cavalli. Le persone che hanno creato il modulo GL stanno dicendo che questo è come dovresti interagire con il nostro prodotto a livello di programmazione. Poi puoi uscire e ottenere uno sviluppatore che in realtà già conosce l'API .... dall'ultimo lavoro che hanno fatto. non devono prima imparare il frankenstein della tua azienda.

Anche con un'API pre-compilata, aggiungere moduli / aggiornamenti, ecc. da fornitori di terze parti diventa più fattibile. Ancora una volta perché l'API di GL è standardizzata e conosciuta al di fuori della vostra azienda e rappresenta quindi un'opportunità di mercato per gli sviluppatori affamati.

Sicurezza: con un'API puoi comunicare in modo più sicuro con il tuo GL. È molto più difficile hackerare una memoria di processo dei sistemi per fare confusione con le importazioni / esportazioni basate su API GL, piuttosto che aprire e modificare una serie di file di testo che si trovano in una cartella sul file system.

Il tuo argomento sembra essere non abbiamo bisogno di accesso programmatico al prodotto e non lo faremo mai , buona fortuna con quello. ;)

Se recentemente hai intrapreso una revisione strategica completa del modo in cui l'IT viene utilizzato nella tua azienda e puoi dire onestamente che non avrai mai bisogno di modificare il modo in cui ottieni i dati nel tuo GL e come modellerai i dati che escono dal tuo GL quindi procede e soddisfa il requisito per un nuovo modulo GL di avere un'API.

Detto questo il futuro è il grande sconosciuto. Personalmente non consiglierei MAI un modulo GL senza un'API .... semplicemente perché so che cosa c'è là fuori ... e nessun pacchetto contabile che guarderei per i nostri clienti (PMI) che stanno andando avanti è privo di API. ... soprattutto considerando la diffusione del cloud computing.

    
risposta data 13.02.2013 - 08:54
fonte
1

Ingegnere software addestrato in un dibattito / discussione / discussione con avvocati, commercialisti e amministratori delegati - perderete, senza dubbio! L'unica via d'uscita per te è disporre di livelli adeguati di documentazione CYA ....

Seriamente - non puoi usare fatti e numeri contro questo attaccamento emotivo a un'idea / ideale. Se hanno letto una rivista che dice "Deve avere un'API", allora diranno "Abbiamo bisogno di un'API" e non saremo felici senza. Non avranno assolutamente idea di cosa si tratta - questa è la tua risorsa più grande, usala.

Cosa farei (prima / a parte rinunciare e scrivere una pila di e-mail CYA), discutere del file import / export come API e usare sempre la parola "API" quando lo discuti. Questo sposterà l'attenzione sui requisiti funzionali e su come può ottenere ciò che deve essere fatto, e lontano dal ballo "Devo avere una API".

    
risposta data 13.02.2013 - 03:11
fonte

Leggi altre domande sui tag