Standard per lo sviluppo aziendale

Gli standard suonano bene e dandy, ma cosa succede quando un cliente ha esigenze di prestazioni o un modello di business diverso che è impossibile ottenere senza un'architettura unica? Ogni cliente deve fare una scelta informata sui vantaggi e gli svantaggi delle diverse soluzioni. Il blocco degli sviluppatori è solo una preoccupazione.

I programmatori dovranno essere certificati per standard specifici? Stiamo andando a creare organi di governo che invieranno gli ispettori del software per verificare la conformità? Le specifiche dei collegamenti elettrici domestici in Australia non hanno bisogno di conformarsi all'Asia. Il software può attraversare il mondo. Quale sarà il livello di conformità? Assolutamente 100%? Sembra che l'onere delle attività di polizia ricada sui clienti che dovranno segnalare violazioni. Hanno tempo, esperienza e risorse?

Anche le aziende che creano le proprie app interne devono confrontarsi con una nuova generazione di sviluppatori che devono aggiornarsi e che non sempre ricevono la documentazione o la supervisione migliore.

Le situazioni in cui uno standard è applicabile probabilmente non hanno abbastanza nuovo sviluppo in queste aree per garantire uno standard.

Il problema principale con i modelli di architettura standard sono quelli che funzionano solo su sistemi standard. Il problema con gli ambienti aziendali del mondo reale è che sono SEMPRE diversi.

A sua volta, gli standard finirebbero per essere così vaghi che potresti star meglio senza.

La risposta molto breve è: devi essere molto molto molto intelligente per definire un'architettura che funzioni per ogni caso. Quasi nessuno è così intelligente.

Nella mia esperienza il software inizia in due modi: o con l'idea "siamo veloci per spedire un prodotto e refactoring una volta che abbiamo clienti" che ha meno architettura all'inizio e quindi non c'è tempo per fare una grande riscrittura o "creiamo una buona architettura" che all'inizio sembra carina, ma nel tempo ci sono sempre più posti che aggirano l'architettura a causa dell'ottimizzazione delle prestazioni o delle funzionalità che non si adattano all'architettura. così entrambe le volte puoi fare un casino.

ricorda anche che molti progetti "Enterprise" sono lunghi e vecchi. Lo sviluppo del software è una cosa relativamente nuova, quindi cambia rapidamente ciò che è considerato buono. Quindi, quando arrivano le nuove tendenze, c'è interesse a usarle nel prodotto ...

We could have a selection of standard architectures such as Domain Model, Transaction Script etc, but once we choose one of these, we have to follow a strict architectural template.

Perché fermarsi qui? Perché non scrivere solo alcune applicazioni standard e farle utilizzare da tutti?

Naturalmente, dovresti competere con aziende come SAP, Oracle, IBM, CA Technologies e Google, quindi faresti meglio a sapere cosa stai facendo.

Ci sono molti prodotti nello spazio delle applicazioni aziendali, quindi devi chiedertelo:

Perché ogni azienda si preoccupa di scrivere le proprie applicazioni?

Se riesci a pensare a una buona risposta, probabilmente puoi iniziare a capire perché un piccolo numero di architetture standard potrebbe non funzionare così bene. Questo non vuol dire che tutte le applicazioni aziendali siano progettate bene, o che non ci sia comunanza tra molte applicazioni aziendali. Tuttavia, le aziende tendono a competere l'una contro l'altra e ho il sospetto che la costruzione dei loro sistemi nello stesso modo in cui i loro concorrenti costruiscono sistemi potrebbe non essere attraente per una società come si penserebbe.

Quale sarebbe il punto, non si sarà in grado di costringere le aziende a utilizzare determinati standard ... il punto di sviluppo del software sta facendo qualcosa di personalizzato, non standardizzato. Ci sono sempre compromessi per varie decisioni di progettazione, una società può avere un prodotto in cui si preoccupano principalmente di ridimensionamento, mentre un altro ha un prodotto software simile in cui la sicurezza è il loro obiettivo primario. Come funzionerebbero in modo standard per entrambi? Naturalmente passeranno più tempo su diverse aree del software e prenderanno decisioni architettoniche differenti in base alle loro esigenze percepite.