Standard universali per l'interscambio di dati - Esistono e li segui? [chiuso]

Do data interchange standards for common entities such as people, purchase orders, sales orders/invoices, shipping documents, projects, tasks, appointments, etc. already exist?

Sì. Ecco di cosa si occupa EDI.

Inizia qui: link

Assuming some do exist, are they commonly accepted, ratified standards?

Assolutamente.

Would you program a business system to use or follow these standards if the initial requirements of the project did not call for it?

No.

In other words, how common or accepted are these standards, enough to be followed every time?

Il problema non è "comune" o "accettato", è "costo" e "valore". A volte l'EDI non crea abbastanza valore. A volte è assolutamente essenziale per lavorare in un dato settore.

Ne abbiamo alcuni: http, xml, json, tcp / ip.

Ho vissuto le guerre dello schema XML della prima parte di questo secolo. Sai, quel periodo di pochi anni in cui pensavamo di poter usare questo magico materiale XML per creare una definizione di dati per tutto e quindi usarlo ovunque .

La lezione sull'oggetto era il problema con gli "standard" universali, è che tendono ad essere progettati da un comitato e provano e coprono ogni permutazione. Conducendo a tipici progettati da problemi di commissione quali over-engineering, eccessiva enfasi sugli obiettivi di marketing di [INSERT BIG IMPORTANT ENTITY] per quel trimestre. Funzionano raramente.

Gli standard che funzionano sono nati sul campo e fabbricati sotto stress. Tendono a fare ciò che è necessario e non di più e sono molto flessibili e succinti. Cose che non avrai mai con un comitato di architettura.

Realisticamente, no, probabilmente non ci sono standard di interscambio e probabilmente non ci saranno mai ... le entità di cui parli sono probabilmente troppo complicate per creare uno standard che tutti possano abbracciare che non sono anche così orribilmente complicati che tutti odiano usandolo.

In vari settori, ci sono stati tentativi di definire gli standard di interscambio. Nell'assistenza sanitaria, ad esempio, HL7 definisce gli standard per la definizione di varie entità comuni come i pazienti. Questi sono ampiamente usati nei software, ma tutti quelli che li trattano tendono a odiare perché lo standard è sempre molto più complicato di quanto il singolo sistema abbia bisogno (o voglia veramente) di gestire. Il problema sorge sempre dal fatto che, sebbene ogni sistema abbia bisogno solo di una manciata relativa di informazioni relative al paziente, per diventare uno standard, è necessario abbracciare i requisiti di chiunque utilizzi i dati. Ciò significa che il record PERSON standard, ad esempio, probabilmente dovrebbe avere circa una dozzina di indirizzi diversi e avrebbe bisogno di codificare regole per determinare cose come il tuo "attuale indirizzo postale per un particolare tipo di documento" perché alcuni sistemi ti permettono di definire più indirizzi postali con varie regole per interpretarli (ad esempio, la persona A vive a Rhode Island da marzo a settembre e va in Florida da ottobre a febbraio, ma i rendiconti finanziari dovrebbero essere indirizzati al suo contabile in Massachusetts). E per il 99% dei sistemi che in realtà non hanno bisogno di avere quel livello di informazione, scrivere il processo di importazione è un dolore reale perché devi capire quali scenari lo standard effettivamente consente e capire come mappare tutti quegli scenari in il tuo sistema automaticamente. Questo è uno dei motivi per cui nessuno parla mai affettuosamente di trattare con i dati HL7.

Spostandoci in software di uso generale con aziende molto più piccole, il costo e la complessità della scrittura di quel tipo di codice di importazione non vale la pena. Se sei una grande azienda di software medicale e sai che il tuo sistema ha bisogno di interoperare con molti altri sistemi, è economicamente conveniente utilizzare qualcosa come lo standard HL7 anche se passi un numero ridicolo di ore a parlare di casi d'angolo perché alcuni sistemi a cui sei interessato potrebbe produrre un record con quel formato perché non dovrai scrivere routine di importazione ed esportazione personalizzate per ogni altro sistema medico nel mondo. Se stai vendendo ad una piccola impresa, tuttavia, è quasi certamente molto meno costoso scrivere 3 o 4 import & routine di esportazione per i 3 o 4 tipi più comuni di prodotti che una piccola impresa avrebbe (vale a dire importare ed esportare materiale di contabilità da QuickBooks, scambiare contatti con Outlook) piuttosto che cercare di colpire alcune specifiche massicciamente complicate anche se si potesse ottenere lo slancio per produrne uno.

Aggiornamento: che dire di EDI?

EDI è un termine molto generico. Esistono più standard in competizione per quali elementi compromettono una persona o un ordine di acquisto. E, come HL7, ognuno degli standard EDI ha probabilmente molti più requisiti di quanti un determinato software di piccole aziende voglia davvero affrontare. Ad esempio, esistono standard ANSI EDI separati per un ordine di acquisto e un ordine di acquisto di prodotti alimentari. Se QuickBooks desiderava generare un ordine di acquisto EDI "standard", avrebbe bisogno di sapere se i prodotti alimentari erano coinvolti, potenzialmente in base alla singola linea in modo da poter creare ordini di acquisto separati di generi alimentari e non alimentari. Quindi ci sarebbe un numero di elementi di dati che QuickBooks avrebbe bisogno di raccogliere che infastidirebbe il 99% dei loro utenti al fine di essere in grado di soddisfare lo standard ANSI per la generazione di un messaggio di ordine di acquisto. Naturalmente, ci sono anche SAP, Oracle e dozzine di altri standard di formato dei messaggi EDI per gli ordini di acquisto.

E anche se puoi assemblare il messaggio, devi occuparti di scambiarlo con qualcun altro. Il tuo fornitore dovrebbe sapere come consegnarti il messaggio EDI. Ciò richiederebbe in genere che la tua piccola azienda gestisca un server su Internet in grado di accettare i messaggi EDI e inoltrarli a QuickBooks in grado di generare e inviare i riconoscimenti. Ciò introduce una serie di elementi mobili che QuickBooks deve codificare e implementare, che la tua azienda deve mantenere e che i tuoi fornitori devono gestire. Cosa succede se il fornitore elabora fatture mentre il server EDI non funziona? Come gestisci assicurandoti che la modifica dell'ordine d'acquisto inviata la scorsa notte a QuickBooks venga trasformata in una notifica che il cliente ha cambiato l'ordine da 100 widget rossi a 200 blu?

C'è ad esempio un Open Catalogue Interface progettato da SAP. Viene utilizzato principalmente nel dominio SRM (Supplier Relationship Management) per integrare cataloghi di fornitori esterni con sistemi esistenti.

1) Do data interchange standards for common entities such as people, purchase orders, sales orders/invoices, shipping documents, projects, tasks, appointments, etc. already exist?

Sì e no. La risposta disinvolta è "la cosa bella degli standard è che ci sono così tanti tra cui scegliere".

Ci sono alcuni standard come vCard che sono pensati per la gestione dei contatti che funzioneranno con le applicazioni di posta elettronica, ma in genere non molto più di questo. Gli ordini di acquisto e gli ordini di vendita / fatture saranno di proprietà del sistema - un formato diverso per Quickbooks Pro rispetto a quello che usereste per SAP. Puoi utilizzare iCal per gli appuntamenti, che sembra funzionare per gli strumenti di calendario ma è un problema da consumare nel tuo strumento. Potresti essere in grado di estendere iCal per gestire le attività (ha un tipo di dati per gli elementi to-do). Per quanto riguarda i progetti, di nuovo quelli sono proprietari.

Parte del problema è che non esiste una ragione convincente da standardizzare per le persone che realizzano questi prodotti. Quando lo scambio di dati è standardizzato, significa che è più facile scambiare qualsiasi parte del sistema. Questa è una proposta spaventosa per prodotti ingombranti e di grandi dimensioni che vogliono essere agganciati perché sarebbe troppo costoso e richiedere molto tempo per cambiare.

2) Assuming some do exist, are they commonly accepted, ratified standards?

Gli standard vCard e iCal sono comunemente accettati in alcune impostazioni . Alcuni strumenti di gestione del progetto esportano i dati utilizzando questi standard in modo che un utente possa avere le informazioni sul proprio calendario. Tuttavia sono usati raramente per scambiare appuntamenti e contatti con il sistema. Non sono sicuro se ci sono ragioni tecniche per questo, o se è solo qualcosa a cui la gente non pensa.

3) Would you program a business system to use or follow these standards if the initial requirements of the project did not call for it? In other words, how common or accepted are these standards, enough to be followed every time?

Dipende davvero dal pubblico. Ogni progetto deve valutare se utilizzare gli standard è appropriato , avere un buon senso aziendale e soddisfare un bisogno reale . In alcuni casi sarebbe una schifezza dire "userete vCard e iCal per lo scambio di informazioni, così dice l'onnipotente appaltatore!" In altri casi lo strumento è troppo piccolo per garantire il sovraccarico, altrimenti il client non utilizzerà mai la funzionalità.

Altri standard come RSS possono essere consumati in modi creativi, quindi hanno anche molto senso a condizione che i dati lo supportino. Dipende dai dati e dalla necessità.

1 Do data interchange standards for common entities such as people,
  purchase orders, sales orders/invoices, shipping documents, projects, 
  tasks, appointments, etc. already exist?

Sì, ci sono alcuni di questi. A volte ci sono standard in competizione. Di solito ci sono buone ragioni per questi diversi standard. Se stai progettando un sistema, gli standard esistenti sono un buon posto dove cercare informazioni sugli attributi che potresti voler acquisire e archiviare.

• Gli standard per le persone includono schemi LDAP, X.500 e vcard. C'è uno standard postale internazionale per il layout degli indirizzi.
• Per le transazioni commerciali ci sono gli standard EDI. Sfortunatamente, le industrie hanno requisiti specifici e diversi.
• Per gli appuntamenti l'unico standard che ho usato è ical.

Esistono altri standard di dati di cui non sono a conoscenza o che non ho elencato. Ho affrontato gli standard di cui sopra ad un certo livello.

Oltre a questi, ci sono una serie di standard sottostanti che usiamo come ASCII, UTF-8, FTP, SCP, SMTP e altri. Questi sono elementi costitutivi che rendono possibile lo scambio di dati.

2 Assuming some do exist, are they commonly accepted, ratified standards?

Gli standard di livello inferiore sono tutti ratificati e comunemente accettati. Quando si entra in formati di dati reali, molti sono ratificati o comunemente accettati.

3 Would you program a business system to use or follow these standards
 if the initial requirements of the project did not call for it? 
 In other words, how common or accepted are these standards, enough 
 to be followed every time?

La risposta semplice è che si applicano allo scambio di dati e non ai requisiti aziendali per i sistemi. In quanto tali, non sono rilevanti per la maggior parte dei sistemi. Gli standard sono più utili quando un sistema ha bisogno di scambiare dati con un numero elevato di sistemi in altre organizzazioni. In quel caso seguirò gli standard appropriati.

Quando si programma un sistema aziendale, fare riferimento agli standard appropriati per convalidare il modello di dati. Non aggiungerei alcun attributo perché erano richiesti da uno standard di interscambio. La maggior parte dei sistemi ha poche necessità di scambiare dati con sistemi esterni e gli standard di interscambio non sono il metodo migliore per eseguire il trasferimento interno dei dati.

Se e quando è stato richiesto un sistema per comunicare con un altro sistema, prenderei in considerazione il modo migliore per costruire il modulo di interfaccia. Una considerazione importante in quel momento è come selezionare e proteggere i dati che vengono trasferiti. Sarebbe fondamentale garantire che venga trasferito solo il sottoinsieme di dati corretto.

La mia preoccupazione principale per la creazione di un sistema aziendale è che i dati sono richiesti dall'azienda. I dati registrati nel sistema devono riflettere le esigenze dell'azienda. Ciò può includere la registrazione di dati non riflessi in nessuno standard o l'omissione di dati richiesti da uno standard.

La maggior parte dei sistemi di interscambio dati con cui ho lavorato ha comportato il trasferimento di dati da un sistema a un altro. Sebbene gli standard siano utili in questi casi, potrebbero richiedere uno sforzo molto maggiore del necessario.

Sarebbe meraviglioso se potessi aggiornare i miei dati di contatto nell'unico vero luogo e chiedere a tutti coloro che ne avevano bisogno di ottenere le parti appropriate. Tuttavia, l'unico vero luogo dovrebbe anche garantire la mia privacy e impedire l'accesso non autorizzato ai dati. Invece abbiamo un processo frammentario in cui diversi sistemi hanno dati diversi. Molti negozi hanno dati obsoleti su di me, ma io sto bene con quello. Aggiornerò i dati quando lo ritengo importante. Tuttavia, potrei non fornire tutti i dati che potrebbero piacere.

Quello che ho usato è qui: link . Hanno definizioni per molte cose, dalle ricette ai vari tipi di attività.

È usato anche in molti posti. Ad esempio, gli ordini Amazon ecc. Contengono Schema da qui nelle loro e-mail e quando apri le loro e-mail in Gmail o Inbox, viene visualizzato un riepilogo di ciò che hai ordinato, il prezzo e altri.

Sarebbe bello se ci fossero degli standard. Ma non ci sono. Dipende davvero dai requisiti quando il software è stato scritto. Tuttavia, se stai sempre convertendo i dati dalla stessa fonte, c'è un software che può aiutarti con quel processo. Personalmente, ho usato Data Junction in passato. Risparmia tempo dalla programmazione del tuo.

Tom

1. Sì. parecchi. alcuni cercano di fare tutto e falliscono. alcuni fanno troppo poco. la varietà è il sale della vita e la rovina delle norme. il mondo reale dice: usa lo standard che funziona, ignora gli standard che non lo fanno. se non esiste uno standard e ne hai davvero bisogno , creane uno.

2. alcuni lo sono, altri no. alcuni sono antichi, complessi e maldestri (EDI, per esempio). alcuni sono specifici del fornitore e spesso richiesti dal cliente.

3. no, non se lo scopo del lavoro non include lo scambio di dati utilizzando uno standard specifico.

In molti sistemi, non vi è alcun vantaggio o valore nell'aggiungere standard e servizi di interscambio di dati, specialmente quando non c'è una necessità ovvia / pressante per loro.