Modellazione dei dati in un ambiente agile

A cura di Techopedia Staff, 16 novembre 2016

Takeaway: l' host Eric Kavanagh discute l'importanza della modellazione dei dati nello sviluppo agile con Robin Bloor, Dez Blanchfield e Ron Huizenga di IDERA.

Al momento non sei collegato. Accedi o registrati per vedere il video.

Eric Kavanagh: Okay, signore e signori. Bentornato ancora una volta. È mercoledì alle 4:00 EST. Ciò significa che è tempo di Hot Technologies. Si Certamente. Mi chiamo Eric Kavanagh, sarò il tuo ospite.

Per l'argomento di oggi, è un vecchio ma un tesoro. Ogni giorno sta migliorando perché sta plasmando il nostro mondo di gestione dei dati, "Modellazione dei dati in un ambiente agile". C'è davvero una diapositiva sulla tua, colpiscimi su Twitter @eric_kavanagh. Dovremmo davvero metterlo su quella diapositiva. Dovrò andare su quello.

Quindi l'anno è caldo. La modellazione dei dati esiste da sempre. È stato davvero al centro del business della gestione delle informazioni, progettando modelli di dati, cercando di capire i modelli di business e allinearli ai tuoi modelli di dati. È davvero quello che stai cercando di fare, giusto?

Il modello di dati rappresenta l'attività in modo fondamentale, quindi come stanno cambiando il gioco tutte queste nuove fonti di dati? Lo scopriremo. Scopriremo come rimanere al passo con le cose in modo agile. E, naturalmente, questa è la parola dell'anno.

Robin Bloor è con noi, il nostro principale analista, Dez Blanchfield che chiama da Sydney, in Australia e Ron Huizenga, Senior Product Manager di IDERA - mio amico di vecchia data, eccellente oratore in questo spazio, conosce le sue cose, quindi non essere timido, chiedi lui le domande difficili, gente, quelle difficili. Detto questo, farò Robin il presentatore e lo porterò via.

Dr. Robin Bloor: Ok. Bene, grazie per quello, Eric. Devo dire della modellazione che penso, in realtà ero nel mondo dell'IT prima che esistesse, nel senso che ricordo nella compagnia assicurativa per cui lavoravo, che avevamo un ragazzo che entrava e ci dava un tipo del seminario su come modellare i dati. Quindi stiamo guardando circa 30 anni, sono 30 anni? Forse anche di più, forse 35 anni fa. Una modellistica da molto, molto tempo fa effettivamente parte del settore e ovviamente non ha nulla a che fare con le donne in passerella.

La cosa che volevo dire, perché quello che facciamo normalmente, sono io e Dez a parlare di cose diverse e ho solo pensato di dare una panoramica generale alla modellazione, ma c'è una realtà in questo, che ora sta diventando evidente.

Abbiamo, sai, la realtà dei big data, abbiamo più dati, più fonti di dati, abbiamo flussi di dati che sono entrati nell'equazione negli ultimi tre o quattro anni e stanno iniziando a prenderne una parte più grande, e vi è una maggiore necessità di comprendere i dati e un aumento della velocità di cambiamento, in quanto vengono aggiunti più dati e vengono utilizzate anche più strutture di dati.

È un mondo difficile. Ecco una sua immagine, che in realtà è qualcosa che abbiamo disegnato circa tre anni fa, ma fondamentalmente, una volta incluso lo streaming nel mix e hai avuto l'idea di raffineria di dati, hub di dati, collegamento dati o qualsiasi altra cosa, vedi che ci sono dati che sono sinceramente a riposo, nel senso che non si muove molto. E poi ci sono i dati, i flussi e hai tutte le applicazioni transazionali, inoltre al giorno d'oggi hai eventi, flussi di dati di eventi che si verificano nelle applicazioni e potrebbero essere necessari, e oggigiorno con le architetture lambda di cui tutti parlano, sono sinceramente avere un impatto solo sull'intero campo dei dati.

E al giorno d'oggi pensare in termini di un livello di dati. Il livello dati esiste in una sorta di modo virtuale, nel senso che un buon pezzo potrebbe essere nel cloud e può essere distribuito su data center, può esistere su stazioni di lavoro. Il livello dei dati è, in una certa misura, ovunque e in quel senso, ci sono processi ovunque che tentano in un modo o nell'altro di elaborare i dati e di spostarli. Ma anche sapere di cosa si tratta quando lo muovi, è un grosso problema.

Se guardiamo alla modellazione dei dati nel senso più generale, in fondo a questo tipo di stack ci sono file e database. Hai elementi di dati, che hanno chiavi, definizioni di elementi, alias, sinonimi, formati fisici specifici e quindi abbiamo questo livello di metadati.

La cosa interessante dei metadati è che i metadati sono interamente come i dati ottengono il loro significato. Se in realtà non hai metadati, nella migliore delle ipotesi puoi indovinare il significato dei dati, ma avrai molte difficoltà. I metadati devono essere presenti, ma il significato ha una struttura. Non voglio entrare nella filosofia del significato, ma anche nel modo in cui trattiamo i dati, c'è molta raffinatezza nel pensiero umano e nel linguaggio umano, che non si esprime facilmente nei dati. Ma anche in termini di dati che effettivamente elaboriamo nel mondo, i metadati hanno un significato e la struttura dei metadati: un dato in relazione a un altro e cosa significa quando vengono messi insieme e cosa significa quando " riuniti con altri dati, richiede che li modelliamo. Non è abbastanza buono per registrare solo tag dei metadati sulle cose, in realtà devi registrare il significato per strutture e la relazione tra le strutture.

Quindi abbiamo il livello superiore, le definizioni aziendali, che è normalmente un livello che tenta di trasferire il significato tra i metadati, che è una forma di definizione dei dati che accoglie il modo in cui i dati sono organizzati sul computer e il significato umano. Quindi hai termini commerciali, definizioni, relazioni, concetti a livello di entità che esistono in quel livello. E se avremo un'incoerenza tra questi livelli, allora dovremo avere la modellazione dei dati. Non è davvero facoltativo. Più puoi effettivamente farlo in termini di automazione, meglio è. Ma poiché ha a che fare con il significato, è davvero difficile alternare. È abbastanza facile catturare i metadati all'interno di un record ed essere in grado di ottenerli da una serie di significati, ma non ti dice la struttura dei record o cosa significano i record o il contesto del record.

Quindi, questo è ciò che riguarda la modellazione dei dati, secondo me. Punti da notare: più l'universo dei dati diventa complesso, più è necessario modellarlo. In altre parole, è un po 'come se non aggiungessimo solo più istanze di cose al mondo, il che corrisponderebbe ai record di dati, ma in realtà stiamo aggiungendo più significato al mondo acquisendo dati su sempre più cose. Sta diventando una sensazione sempre più complessa che dobbiamo capire.

In teoria c'è un universo di dati e abbiamo bisogno di vederlo. In pratica, i metadati effettivi fanno parte dell'universo dei dati. Quindi, non è una situazione semplice. L'inizio della modellazione è dall'alto verso il basso e dal basso verso l'alto. È necessario costruire in entrambe le direzioni e la ragione è che i dati hanno un significato per il computer e il processo, che devono elaborarli, ma hanno un significato a sé stante. Quindi, hai bisogno di un significato bottom-up, che soddisfi il software che deve accedere ai dati e hai bisogno del significato top-down in modo che gli esseri umani possano capirlo. La costruzione di modelli di metadati non è e non può mai essere un progetto; è un'attività in corso - dovrebbe essere un'attività in corso in ogni ambiente in cui esistono. Fortunatamente, ci sono molti ambienti in cui questo non è il caso e le cose girano fuori controllo di conseguenza.

Andando avanti, la modellazione aumenta con l'importanza man mano che la tecnologia avanza. È la mia opinione. Ma se guardiamo l'IoT possiamo capire il mobile più di quanto non facessimo prima, sebbene abbia introdotto nuove dimensioni: la dimensione della posizione con il cellulare. Una volta arrivato all'IoT, stiamo esaminando problemi di dati straordinari che in realtà non abbiamo mai dovuto fare prima e dobbiamo, in un modo o nell'altro, capire correttamente esattamente cosa abbiamo, esattamente come possiamo aggregarlo, cosa possiamo fare in termini di ottenere significato dall'aggregazione e, naturalmente, cosa possiamo fare con esso, quando l'abbiamo elaborato.

Penso che sia quello che ho detto abbastanza. Passerò a Dez Blanchfield, che dirà qualcos'altro interamente.

Dez Blanchfield: grazie. Sempre un duro atto da seguire, ma questo è un argomento che abbiamo concordato e di cui abbiamo parlato brevemente nella battuta del preshow, e se hai chiamato in anticipo, probabilmente avresti catturato un sacco di grandi gemme. Uno dei takeaway, e non voglio rubare il tuono di questo particolare, ma uno dei takeaway della nostra battuta di preshow che voglio condividere, nel caso in cui non lo avessi preso, era proprio sull'argomento di il viaggio dei dati, e mi ha colpito davvero scriverlo pensando al viaggio che i dati intraprendono in un contesto diverso attorno alla vita generazionale - anno, mesi, settimana, giorno, ora, minuto, secondo - e il contesto attorno ai dati è posizionato in quel contesto. Che io sia uno sviluppatore che esegue codice o che io sia uno specialista di dati e sto pensando alla struttura, al formato e ai metadati attorno a ciascuno degli elementi o al modo in cui i sistemi e l'azienda interagiscono con esso.

È un po 'interessante solo da notare, ma comunque, mi permetta di immergermi. Il design dei dati, in particolare, è una frase che uso per parlare di tutti i dati e in particolare dello sviluppo di applicazioni o infrastruttura di database. Penso che la progettazione dei dati sia un termine che semplicemente cattura tutto molto bene nella mia mente. In questi giorni, quando parliamo di design dei dati, parliamo di design dei dati agile moderno e la mia opinione è che non è stato tanto tempo fa che sviluppatori ed esperti di dati hanno lavorato da soli; erano nei loro silos e pezzi di design passavano da un silo all'altro. Ma al giorno d'oggi sono molto convinto che non solo è cambiato il caso, ma deve cambiare; è una specie di necessità e questa è l'applicazione: sviluppatori e tutto ciò che riguarda lo sviluppo che si occupa di dati, i progettisti che eseguono i relativi elementi di progettazione di schemi e campi e registri e sistemi e infrastrutture di ubicazione e database, modellistica e l'intera gestione sfida intorno a questo. Questo è uno sport di squadra ora e quindi la mia foto di un gruppo di persone che saltano fuori da un aeroplano che agisce come una squadra per interpretare quell'immagine visivamente interessante di persone che cadono nel cielo.

Terzo, che cosa è successo per causare questo? Bene, c'è un articolo nel 1986 scritto da un paio di signori i cui nomi ho cercato disperatamente di rendere giustizia, Hirotaka Takeuchi e Ikujiro Nonaka, penso che sia pronunciato, prodotto un articolo che hanno intitolato "Spostare lo Scrum Downfield". Hanno introdotto questa idea di una metodologia per vincere una partita di rugby partendo da questa mischia, in cui tutti si muovono in un posto e due squadre essenzialmente bloccano la testa in qualcosa chiamato mischia per cercare di ottenere il controllo della palla e giocarla in campo per arriva alla linea di prova e tocca il terreno con la palla e ottieni un punto, chiamato trigono, e ripeti questo processo e ottieni più punti per la squadra.

Questo articolo è stato pubblicato nel 1986 nella Harvard Business Review e curiosamente ha suscitato molta attenzione. Ha ricevuto molta attenzione perché ha introdotto nuovi concetti sorprendenti ed ecco uno screenshot della parte anteriore di esso. Quindi hanno preso questo concetto di mischia dal rugby del gioco e lo hanno messo in affari e in particolare nel gioco di progettazione e consegna del progetto, in particolare la consegna del progetto.

Ciò che scrum ci ha fatto è stato quello di darci una nuova metodologia rispetto a artisti del calibro di PRINCE2 o PMBOK che avevamo precedentemente utilizzato in quella che abbiamo chiamato la metodologia a cascata, sai, fai questa cosa e questa cosa e questa cosa e seguile in sequenza e connettiti tutti i punti intorno, che dipendono da ciò che avevi, o non fare la seconda parte fino a quando non hai fatto la prima parte perché dipendeva dalla prima parte. Ciò che ci ha dato è una nuova metodologia per essere un po 'più agile, da cui deriva il termine, su come consegniamo le cose, e in particolare sulla progettazione e lo sviluppo di progetti di base.

Alcuni degli inquilini chiave - solo così vado avanti con questo - è intorno agli inquilini chiave della mischia. Ha introdotto l'idea di costruire l'instabilità, che efficacemente se si pensa alla paura del caos, il mondo esiste in uno stato di caos, ma il pianeta si è formato, il che è interessante, quindi costruendo l'instabilità, la capacità di rimbalzare un po 'e ancora effettivamente far funzionare le cose, team di progetto auto-organizzanti, favori sovrapposti attraverso uno sviluppo molto responsabile, diversi tipi di apprendimento e controllo attraverso il percorso di consegna del progetto, il trasferimento organizzativo dell'apprendimento. Quindi, come possiamo prendere informazioni da una parte dell'azienda e trasferirle ad un'altra da persone che hanno un'idea ma non sviluppano codice o non sviluppano database e infrastrutture, ma dati a quelle persone? E in particolare risultati temporizzati. In altre parole, facciamolo per un periodo di tempo, o un giorno come in 24 ore, o una settimana o un paio di settimane e vediamo cosa possiamo fare e poi facciamo un passo indietro e guardiamo.

E quindi, se perdoni il gioco di parole, questo è davvero un nuovo gioco nella consegna del progetto e le tre componenti fondamentali che avranno senso man mano che andiamo un po 'più avanti qui - c'è il prodotto: tutte queste persone hanno l'idea e hanno la necessità di fare qualcosa e la storia che li circonda. Gli sviluppatori che operano nel modello agile di ottenere le loro storie e attraverso standup giornalieri usando la metodologia di scrum per discuterne e capire cosa devono fare, e poi andare avanti e andare avanti e farlo. Poi, abbiamo sentito parlare di maestri della mischia che sovrintendono a tutto questo e capiscono la metodologia abbastanza bene da guidarla. Abbiamo visto tutte queste immagini che ho trovato sul lato destro qui di pareti e lavagne piene di note Post-It e sono state servite come pareti Kanban. Se non sai chi sia Kanban, ti invito a Google chi era il signor Kanban e perché è stato un cambiamento nel modo in cui letteralmente spostiamo le cose da una parte all'altra in un muro ma in un progetto.

A colpo d'occhio, il flusso di lavoro della mischia fa questo: prende un elenco di cose che un'organizzazione vuole fare, eseguendole attraverso una serie di cose che chiamiamo sprint che sono suddivise in periodi di 24 ore, periodi di un mese e noi ottenere questa serie incrementale di output. È un cambiamento significativo nel modo in cui i progetti vengono consegnati, consegnati fino a quel punto perché parte di ciò scorre come l'esercito americano che ha avuto una grande parte nello sviluppo di qualcosa chiamato PMBOK, come l'idea che non porta il carro armato in campo fino a quando non metti proiettili nella cosa perché se un carro armato nel campo non ha proiettili, è inutile. Quindi quindi la prima parte è messa proiettili nel serbatoio, la seconda parte è messo il serbatoio sul campo. Sfortunatamente, però, quello che è successo con gli sviluppatori nel mondo dello sviluppo ha in qualche modo preso possesso di questa agile metodologia e se ne è liberato, se perdonate il gioco di parole, a uno sprint.

Invariabilmente ciò che è accaduto è che quando pensiamo all'agile di solito pensiamo agli sviluppatori e non ai database e a qualsiasi cosa abbia a che fare con il mondo dei database. È stato un risultato sfortunato perché la realtà è che l'agile non si limita agli sviluppatori. In effetti, il termine agile secondo me è spesso erroneamente associato esclusivamente a sviluppatori di software e non a progettisti e architetti di database. Invariabilmente le stesse sfide che si affrontano nello sviluppo di software e applicazioni devono essere affrontate in tutte le cose che riguardano la progettazione, lo sviluppo, il funzionamento e la manutenzione e quindi l'infrastruttura di dati e in particolare i database. Gli attori di questo particolare cast di dati includono artisti del calibro di data architetti, modellatori, amministratori, gestori delle infrastrutture di database e gli stessi database fino agli analisti e architetti di business e di sistema, persone che siedono e pensano a come i sistemi e le aziende operano e come siamo riusciti a far fluire i dati attraverso queste.

È un argomento che sollevo regolarmente perché è una mia costante frustrazione in quanto sono molto convinto che gli specialisti dei dati debbano - non dovrebbero - debbano ora essere intimamente coinvolti in ogni componente della consegna del progetto, in particolare, in particolare, nello sviluppo. Per noi no, allora non ci stiamo davvero dando le migliori possibilità per un buon risultato. Spesso dobbiamo tornare indietro e ripensarci su queste cose perché esiste uno scenario, arriviamo alla creazione di un'applicazione e scopriamo che gli sviluppatori non sono sempre esperti di dati. Lavorare con i database richiede competenze molto specializzate, in particolare per quanto riguarda i dati, e crea un'esperienza. Non si diventa istantaneamente un guru del database o un esperto di conoscenza dei dati durante la notte; questo è spesso qualcosa che proviene da un'esperienza di vita e certamente con artisti del calibro del Dr. Robin Bloor su Code Today, che ha scritto abbastanza riccamente il libro.

In molti casi - ed è sfortunato ma è una realtà - che ci sono due parti di questa moneta, ovvero gli sviluppatori di software hanno un blackout proprio per quanto riguarda lo specialista del database e hanno costruito le competenze necessarie nella modellazione della progettazione di database, lo sviluppo del modello è solo il fondamentale per l'ingegneria dei guru del modo in cui arrivano i dati e di come l'organizzazione del viaggio prende e di come dovrebbe o non dovrebbe apparire, o senza dubbio quello ingerito e la comprensione del fatto che di solito sono acquisiti in competenze native sviluppate per gli sviluppatori di software. E alcune delle sfide più comuni che affrontiamo, solo per metterlo nel contesto, includono aspetti come la creazione e la manutenzione e la gestione di base del database stesso, la documentazione dei dati e l'infrastruttura del database e il riutilizzo di tali risorse di dati, progetti di schemi, generazioni di schemi, amministrazione e manutenzione dello schema e loro utilizzo, condivisione delle conoscenze sui motivi per cui questo schema è stato progettato in un modo particolare e i punti di forza e di debolezza che ne conseguono nel tempo causano cambiamenti dei dati nel tempo, modellazione dei dati e tipi dei modelli che applichiamo ai sistemi e ai dati che fluiscono attraverso di essi. Generazione del codice del database e continua l'integrazione e poi modellato i dati attorno a loro e quindi accedendo più rapidamente al controllo della sicurezza attorno ai dati, l'integrità dei dati stiamo spostando i dati mentre ne manteniamo l'integrità, ci sono abbastanza metadati in giro esso, le vendite dovrebbero vedere tutti i record nella tabella o dovrebbero vedere solo l'indirizzo, il nome, il cognome che ti invia roba per posta? E poi ovviamente la più grande sfida di tutte è quella di modellare piattaforme di database che è una conversazione completamente diversa in sé.

Sono fermamente convinto che, tenendo conto di tutto ciò per rendere possibile tutto questo nirvana, è assolutamente fondamentale che sia gli specialisti dei dati che gli sviluppatori dispongano degli strumenti adeguati e che tali strumenti siano in grado di erogare progetti incentrati sul team, progettazione, sviluppo e manutenzione operativa in corso. Sai, cose come la collaborazione tra progetti tra esperti di dati e sviluppatori di software, singolo punto di verità o singola fonte di verità per tutto ciò che riguarda la documentazione dei database stessi, i dati, gli schemi, da dove provengono i record, i proprietari di quei record . Penso che al giorno d'oggi sia assolutamente fondamentale, stiamo per ottenere questo nirvana di dati come re, che gli strumenti giusti devono essere a posto perché la sfida è troppo grande ora per noi per farlo manualmente e se le persone spostarsi dentro e fuori da un'organizzazione, è troppo facile per noi non seguire lo stesso processo o la stessa metodologia che una persona potrebbe impostare che sono buoni e non necessariamente trasferire quelle abilità e capacità in futuro.

Con questo in mente, andrò dal nostro buon amico di IDERA e sentirò parlare di quello strumento e di come affronta queste cose.

Ron Huizenga: Grazie mille e grazie sia a Robin che a Dez per aver preparato davvero bene il palco, e vedrai un po 'di sovrapposizione in un paio di cose di cui ho parlato. Ma hanno davvero creato una base molto solida per alcuni dei concetti di cui parlerò dal punto di vista della modellazione dei dati. E molte delle cose che hanno detto fanno eco alla mia esperienza quando ero un consulente che lavorava nella modellizzazione dei dati e nell'architettura dei dati, insieme ai team - entrambi a cascata all'inizio e si evolvono in prodotti più moderni con progetti in cui stavamo usando agili metodologie per fornire soluzioni.

Quindi quello di cui parlerò oggi è basato su quelle esperienze, nonché su una vista degli strumenti e alcune delle capacità degli strumenti che utilizziamo per aiutarci durante quel viaggio. Quello che tratterò brevemente è che non entrerò nella mischia in molti dettagli; abbiamo appena avuto un'ottima panoramica di ciò che è. Ne parlerò in termini di, che cos'è un modello di dati e cosa significa veramente per noi? E come possiamo abilitare il concetto di modellatore di dati agile nelle nostre organizzazioni, in termini di, come coinvolgere i modellatori di dati, qual è la partecipazione di modellisti e architetti durante lo sprint, quali sono i tipi di attività in cui dovrebbero essere impegnati e, in base a ciò, quali sono alcune delle importanti funzionalità dello strumento di modellazione che utilizziamo per rendere davvero più semplice quel lavoro? Poi entrerò in un po 'di conclusione e parlerò solo di alcuni dei valori e dei vantaggi aziendali di avere un modellatore di dati coinvolti, o del modo in cui sto per raccontare la storia, i problemi di non avere un modellatore di dati pienamente coinvolto nei progetti e te lo mostrerò sulla base dell'esperienza e di un diagramma dei difetti di un'immagine prima e dopo di un progetto reale con cui sono stato coinvolto molti anni fa. E poi riassumeremo alcuni altri punti e quindi avremo domande e risposte oltre a quello.

In breve, ER Studio è una suite molto potente con molti componenti diversi. Data Architect, che è il luogo in cui i modellatori di dati e gli architetti trascorrono la maggior parte del loro tempo a modellare i dati. Ci sono anche altri componenti di cui non parleremo affatto oggi come Business Architect, dove facciamo modellazione di processi e Software Architect, per alcuni dei modelli UML. Poi c'è il repository, in cui effettuiamo il check-in e condividiamo i modelli e consentiamo ai team di collaborare su questi e pubblicarli sul server del team in modo che più destinatari coinvolti in un progetto possano effettivamente vedere gli artefatti che creando dal punto di vista dei dati così come le altre cose che stiamo facendo nella consegna del progetto stesso.

Quello su cui mi concentrerò oggi saranno alcune cose che vedremo da Data Architect e perché è davvero importante avere la collaborazione di aspetti basati sul Repository. Soprattutto quando iniziamo a parlare di concetti come la gestione del cambiamento che sono indispensabili, non solo progetti di sviluppo agili, ma qualsiasi tipo di sviluppo in futuro.

Quindi parliamo di Agile Data Modeler per un momento. Come abbiamo già accennato in precedenza nella presentazione, è che è indispensabile disporre di modellatori di dati e / o architetti pienamente coinvolti nei processi di sviluppo agili. Ora, quello che è successo storicamente è, sì, abbiamo davvero pensato all'agile dal punto di vista dello sviluppo, e ci sono un paio di cose che sono successe e che hanno fatto sì che ciò accadesse. Parte di ciò era dovuta alla natura del modo in cui lo sviluppo stesso si svolgeva. Quando lo sviluppo agile è iniziato e abbiamo iniziato con questo concetto di team auto-organizzanti, se hai bevuto il Kool-Aid un po 'troppo puro ed eri sul lato estremo della programmazione delle cose, c'era un'interpretazione molto letterale di cose come il team auto-organizzanti, interpretati da molte persone, tutto ciò di cui abbiamo bisogno è un gruppo di sviluppatori in grado di costruire un'intera soluzione. Che si tratti di sviluppare il codice, i database o i datastore dietro di esso e tutto è stato relegato agli sviluppatori. Ma quello che succede è che perdi le abilità speciali che le persone hanno. Ho scoperto che le squadre più forti sono quelle composte da persone di diversa estrazione. Come una combinazione di forti sviluppatori di software, architetti di dati, modellatori di dati, analisti aziendali e stakeholder aziendali, tutti che collaborano per trovare una soluzione finale.

Ciò di cui sto parlando anche oggi è che lo farò nel contesto di un progetto di sviluppo in cui stiamo sviluppando un'applicazione che ovviamente avrà anche il componente dati associato ad esso. Dobbiamo fare un passo indietro prima di farlo, però, perché dobbiamo renderci conto che ci sono pochissimi progetti di sviluppo Greenfield là fuori in cui siamo totalmente concentrati sulla creazione e il consumo di dati che è limitato solo all'interno di quel progetto di sviluppo stesso . Dobbiamo fare un passo indietro e guardare al punto di vista organizzativo generale dal punto di vista dei dati e del processo. Perché ciò che scopriamo è che le informazioni che stiamo utilizzando potrebbero già esistere da qualche parte nelle organizzazioni. Come modellisti e architetti, li portiamo alla luce, così sappiamo da dove reperire tali informazioni nei progetti stessi. Conosciamo anche le strutture di dati che sono coinvolte perché abbiamo schemi di progettazione proprio come gli sviluppatori hanno schemi di progettazione per il loro codice. E dobbiamo anche prendere quella prospettiva organizzativa complessiva. Non possiamo semplicemente guardare i dati nel contesto dell'applicazione che stiamo costruendo. Dobbiamo modellare i dati e assicurarci di documentarli perché sopravvivono ben oltre le applicazioni stesse. Queste applicazioni vanno e vengono, ma dobbiamo essere in grado di guardare i dati e assicurarci che siano robusti e ben strutturati, non solo per l'applicazione, ma anche per le decisioni che riportano attività, reportistica BI e integrazione ad altre applicazioni, interne e esterno anche alle nostre organizzazioni. Pertanto, dobbiamo esaminare l'intero quadro generale dei dati e qual è il ciclo di vita di tali dati e comprendere il viaggio di informazioni all'interno dell'organizzazione dalla culla alla tomba.

Ora torniamo ai team effettivi stessi e al modo in cui dobbiamo effettivamente lavorare, la metodologia a cascata è stata percepita come troppo lenta per fornire risultati. Perché, come sottolineato nell'esempio del serbatoio, è stato un passo dopo l'altro e spesso ci è voluto troppo tempo per ottenere un risultato finale praticabile. Ciò che facciamo ora è che dobbiamo avere uno stile di lavoro iterativo in cui sviluppiamo in modo incrementale componenti di esso e lo elaboriamo nel tempo in cui produciamo codice utilizzabile o artefatti utilizzabili, sto per dire, per ogni sprint. L'importante è la collaborazione tra gli stakeholder tecnici del team e gli stakeholder aziendali mentre collaboriamo per scacciare le storie degli utenti in una visione implementabile del codice e dei dati che supportano anche quel codice. E lo stesso Agile Data Modeler scoprirà spesso che non abbiamo abbastanza modellatori nelle organizzazioni, quindi un modellatore di dati o un architetto possono supportare contemporaneamente più team.

E l'altro aspetto è che, anche se disponiamo di più modellatori, dobbiamo assicurarci di disporre di un set di strumenti che stiamo utilizzando che consenta la collaborazione di più progetti che sono in corso contemporaneamente e la condivisione di quelli artefatti di dati e capacità di check-in e check-out. Lo esaminerò molto rapidamente perché lo abbiamo già trattato nella sezione precedente. La vera premessa di Agile è che stai basando le cose su arretrati, storie o requisiti. All'interno delle iterazioni stiamo collaborando come gruppo. In genere uno sprint di due settimane o di un mese, a seconda dell'organizzazione, è molto comune. E anche riunioni quotidiane di revisione e stand-up in modo da eliminare i bloccanti e assicurarci di spostare tutti gli aspetti in avanti senza essere fermati in diverse aree mentre attraversiamo. E in quegli sprint vogliamo assicurarci di produrre risultati utilizzabili come parte di ogni sprint.

Solo un approccio leggermente diverso su questo, espandendolo ulteriormente, la mischia è la metodologia di cui parlerò più specificamente qui e abbiamo sostanzialmente aumentato quella foto precedente con alcune altre sfaccettature. Di solito c'è un backlog di prodotto e poi c'è un backlog di sprint. Quindi abbiamo un arretrato complessivo che, all'inizio di ogni reiterazione dello sprint, ci limitiamo a dire: "Che cosa costruiremo questo sprint?" E questo viene fatto in una riunione di pianificazione dello sprint. Quindi interrompiamo le attività associate a questo e eseguiamo in quegli sprint da una a quattro settimane con quelle revisioni giornaliere. Mentre stiamo facendo che stiamo monitorando i nostri progressi attraverso grafici di burn-up e grafici di burn-down per tracciare fondamentalmente ciò che resta da costruire rispetto a ciò che stiamo costruendo per stabilire cose come la nostra velocità di sviluppo, faremo il nostro programma, tutti quei tipi di cose. Tutti questi sono elaborati continuamente durante lo sprint piuttosto che andare avanti di alcuni mesi e scoprire che stai per arrivare corto e che devi estendere il programma del progetto. E molto importante, in quanto parte di tutto il team, c'è una revisione dello sprint alla fine e una retrospettiva dello sprint, quindi prima di dare il via alla prossima iterazione stai rivedendo quello che hai fatto e stai cercando i modi in cui puoi migliorare la prossima volta.

In termini di risultati finali, questa è fondamentalmente una diapositiva che sintetizza i tipi tipici di cose che accadono negli sprint. Ed è molto incentrato sullo sviluppo, quindi molte delle cose che vediamo qui, come design funzionali e casi d'uso, test del codice di progettazione, quando guardiamo queste caselle qui, e non le esaminerò in ogni livello di dettaglio, sono molto orientati allo sviluppo. Ed è sepolto qui sotto il fatto che dobbiamo anche avere quei dati consegnabili che vanno di pari passo con questo per supportare questo sforzo. Quindi ogni volta che vediamo cose come gli arretrati, i requisiti e le storie degli utenti, mentre stiamo attraversando dobbiamo guardare quali sono i pezzi di sviluppo che dobbiamo fare, quali sono i pezzi di analisi che dobbiamo fare, che ne dite progettazione dei dati o modello di dati, che dire delle cose come i glossari aziendali in modo da poter associare il significato degli affari a tutti gli artefatti che stiamo producendo? Perché dobbiamo produrre quei risultati utilizzabili in ogni sprint.

Alcune persone diranno che dobbiamo produrre codice utilizzabile alla fine di ogni sprint. Questo non è necessariamente il caso, è in una prospettiva di sviluppo più pura, ma abbastanza spesso - specialmente all'inizio - potremmo avere qualcosa come lo sprint zero in cui siamo concentrati esclusivamente su alzare le cose, fare cose come mettere le nostre strategie di test in posto. Un progetto di alto livello per iniziare prima di iniziare a compilare i dettagli e assicurandoci di avere un insieme pulito di storie o requisiti iniziali prima di iniziare a coinvolgere altri pubblici e quindi costruire come squadra mentre procediamo. C'è sempre un po 'di tempo di preparazione, quindi abbastanza spesso avremo uno sprint zero o anche uno sprint zero e uno. Potrebbe essere un po 'una fase di avvio prima di iniziare il volo pieno nel fornire la soluzione.

Parliamo di modelli di dati in questo contesto molto brevemente. Quando le persone pensano ai modelli di dati, spesso pensano a un modello di dati come a un quadro di come le diverse informazioni si collegano - questa è solo la punta dell'iceberg. Per incarnare appieno lo spirito di come si desidera veramente approcciare la modellazione dei dati, sia che si tratti di uno sviluppo agile e di altre cose, è necessario rendersi conto che il modello di dati, se fatto correttamente, diventa la specifica completa per ciò che i dati significano nell'organizzazione e come viene distribuito nei database back-end. Quando dico database, intendo non solo i database relazionali che potremmo usare, ma nelle architetture di oggi in cui disponiamo di big data o piattaforme NoSQL, come preferisco chiamarli. Anche questi archivi di grandi quantità di dati perché potremmo combinare molti archivi di dati diversi in termini di consumo di informazioni e di introduzione nelle nostre soluzioni, nonché del modo in cui persistiamo o salviamo tali informazioni anche dalle nostre soluzioni.

Potremmo lavorare con più database o origini dati contemporaneamente nel contesto di una determinata applicazione. Ciò che è molto importante è che vogliamo essere in grado di avere una specifica completa, quindi una specifica logica di ciò che ciò significa per una prospettiva organizzativa sprint, quali sono i costrutti fisici in termini di come definiamo effettivamente i dati, le relazioni tra di essi i tuoi database, i tuoi vincoli di integrità referenziale, i vincoli di controllo, tutti quei pezzi di validazione che in genere pensi. I metadati descrittivi sono estremamente importanti. Come fai a sapere come utilizzare i dati nelle tue applicazioni? A meno che tu non possa definirlo e sapere cosa significhi o sapere da dove proviene per assicurarti di consumare i dati corretti in quelle applicazioni - assicurandoti di avere convenzioni di denominazione corrette, definizioni complete, il che significa un dizionario di dati completo non solo le tabelle ma le colonne che compongono tali tabelle e le note dettagliate sulla distribuzione di come lo utilizziamo perché abbiamo bisogno di costruire questa base di conoscenza perché anche quando questa applicazione viene eseguita, queste informazioni verranno utilizzate per altre iniziative, quindi dobbiamo assicurarci che abbiamo documentato tutto ciò per future implementazioni.

Ancora una volta, passiamo a cose come tipi di dati, chiavi, indici, il modello di dati stesso incarna molte delle regole aziendali che entrano in gioco. Le relazioni non sono solo vincoli tra tabelle diverse; spesso ci aiutano a descrivere quali sono le vere regole aziendali su come si comportano quei dati e come funzionano insieme come unità coesa. E, naturalmente, le restrizioni di valore sono molto importanti. Ora, naturalmente, una delle cose con cui ci confrontiamo costantemente, e sta diventando sempre più diffusa, sono cose come la governance dei dati. Quindi, dal punto di vista della governance dei dati, dobbiamo anche guardare a cosa stiamo definendo qui? Vogliamo definire cose come le classificazioni di sicurezza. Con quali tipi di dati stiamo trattando? Cosa verrà considerato la gestione dei dati anagrafici? Quali sono i negozi transazionali che stiamo creando? Quali dati di riferimento stiamo utilizzando in queste applicazioni? Dobbiamo assicurarci che sia correttamente catturato nei nostri modelli. E anche considerazioni sulla qualità dei dati, ci sono alcune informazioni che sono più importanti per un'organizzazione di altre.

Sono stato coinvolto in progetti in cui stavamo sostituendo oltre una dozzina di sistemi legacy con nuovi processi aziendali e progettando nuove applicazioni e archivi di dati per sostituirli. Avevamo bisogno di sapere da dove provenivano le informazioni. Quale per le informazioni più importanti, dal punto di vista aziendale, se guardi questa particolare diapositiva del modello di dati che ho qui, vedrai che le caselle in basso in queste entità particolari, che è solo un piccolo sottoinsieme, io sono stato in grado di catturare il valore aziendale. Sia alto, medio o basso per questo tipo di cose per questi diversi costrutti all'interno dell'organizzazione. E ho anche catturato cose come le classi di dati master, siano esse tabelle master, siano riferimenti, se fossero transazionali. Quindi possiamo estendere i nostri metadati nei nostri modelli per darci molte altre caratteristiche al di fuori dei dati stessi, il che ci ha davvero aiutato con altre iniziative al di fuori dei progetti originali e portarlo avanti. Ora questo è stato molto in una diapositiva, ho intenzione di passare attraverso il resto di questi abbastanza rapidamente.

Ora parlerò molto rapidamente di ciò che fa un modellatore di dati mentre stiamo attraversando questi diversi sprint. Prima di tutto, un partecipante a pieno titolo alle sessioni di pianificazione dello sprint, in cui stiamo prendendo le storie degli utenti, impegnandoci per quello che stiamo per offrire in quello sprint e capendo come lo struttureremo e lo consegneremo. Quello che sto facendo anche come modellatore di dati è che lavorerò in aree separate con sviluppatori diversi o con persone diverse. Quindi una delle caratteristiche importanti che possiamo avere è quando stiamo facendo un modello di dati, possiamo dividere quel modello di dati in diverse viste, sia che tu li chiami aree tematiche o sottomodelli, è la nostra terminologia. Quindi, mentre stiamo costruendo il modello, lo stiamo anche mostrando in queste diverse prospettive del sotto-modello, in modo che i diversi pubblici vedano solo ciò che è rilevante per loro in modo che possano concentrarsi su ciò che stanno sviluppando e proponendo. Quindi potrei avere qualcuno che lavora su una parte di pianificazione di un'applicazione, potrei avere qualcun altro che lavora su una voce di ordine in cui stiamo facendo tutte queste cose in un singolo sprint, ma posso dare loro i punti di vista attraverso quei sotto-modelli che solo si applicano all'area su cui stanno lavorando. E poi quelli si arrotolano al modello generale e all'intera struttura dei sottomodelli per offrire a diversi spettatori ciò che devono vedere.

I fondamenti da una prospettiva di modellizzazione dei dati che vogliamo avere è, avere sempre una linea di base a cui possiamo tornare indietro perché una delle cose che dobbiamo essere in grado di fare è, sia alla fine di uno sprint o alla fine tra diversi sprint, vogliamo sapere da dove siamo partiti e avere sempre una linea di base per sapere qual è stato il delta o la differenza di ciò che abbiamo prodotto in un determinato sprint. Dobbiamo anche assicurarci di avere una rapida inversione di tendenza. Se vieni coinvolto come modellatore di dati ma nel tradizionale ruolo di gatekeeper dicendo "No, no, non puoi farlo, dobbiamo prima fare tutto questo", sarai escluso dal team quando ne hai davvero bisogno partecipare attivamente a tutti quei team di sviluppo agili. Ciò significa che alcune cose cadono dal carro facendo un determinato sprint e le raccogli in sprint successivi.

Ad esempio, potresti concentrarti sulle strutture di dati solo per far avanzare lo sviluppo, per esempio, quella voce di ordine di cui stavo parlando. In uno sprint successivo, potresti tornare indietro e compilare i dati come parte della documentazione per il dizionario dei dati attorno ad alcuni di quegli artefatti che hai creato. Non completerai quella definizione tutto in uno sprint; continuerai ad andare avanti ai tuoi risultati in modo incrementale perché ci saranno momenti in cui puoi inserire tali informazioni lavorando con gli analisti aziendali quando gli sviluppatori sono impegnati a costruire le applicazioni e la persistenza attorno a questi archivi di dati. Vuoi facilitare e non essere il collo di bottiglia. Esistono diversi modi in cui lavoriamo con gli sviluppatori. Per alcune cose abbiamo modelli di progettazione in modo da essere un partecipante completo in anticipo, quindi potremmo avere un modello di progettazione in cui diremo che lo inseriremo nel modello, lo sposteremo nei database sandbox degli sviluppatori e poi potranno iniziare a lavorare con esso e richiedere modifiche.

Potrebbero esserci altre aree su cui gli sviluppatori hanno lavorato, hanno qualcosa su cui stanno lavorando e stanno prototipando alcune cose in modo da provare alcune cose nel loro ambiente di sviluppo. Prendiamo quel database con cui hanno lavorato, lo inseriamo nel nostro strumento di modellazione, confrontiamo con i modelli che abbiamo e quindi risolviamo e rispediamo loro le modifiche in modo che possano riformattare i loro codici in modo che seguano le strutture di dati appropriate di cui abbiamo bisogno. Perché potrebbero aver creato alcune cose che avevamo già altrove, quindi ci assicuriamo che stiano lavorando con le giuste fonti di dati. Continuiamo a iterare fino in fondo fino al nostro sprint in modo da ottenere tutti i risultati dei dati, la documentazione completa e la definizione di tutte quelle strutture di dati che stiamo producendo.

I progetti agili di maggior successo con cui sono stato coinvolto in termini di ottime consegne sono: abbiamo avuto una filosofia, modellato tutte le modifiche alla specifica del database fisico completo. In sostanza, il modello di dati diventa i database distribuiti con cui stai lavorando per qualsiasi cosa che stiamo creando e ha riferimenti completi agli altri archivi di dati se utilizziamo da altri database esterni. Come parte di ciò stiamo producendo script incrementali rispetto a fare una generazione completa ogni volta. E stiamo utilizzando i nostri modelli di progettazione per darci una rapida spinta in termini di accelerare le cose con i diversi team di sviluppo con cui stiamo lavorando.

Anche nelle attività sprint, è di nuovo quella base per confrontare / unire, quindi prendiamo l'idea di modellare ogni cambiamento. Ogni volta che facciamo un cambiamento, ciò che vogliamo fare è voler modellare il cambiamento e ciò che è molto importante, ciò che è mancato alla modellazione dei dati fino a poco tempo fa, infatti, fino a quando non l'abbiamo reintrodotta, è la capacità di associare la modellazione attività e risultati finali con le storie utente e le attività che causano effettivamente tali cambiamenti. Vogliamo essere in grado di controllare le modifiche del nostro modello, allo stesso modo in cui gli sviluppatori controllano i loro codici, facendo riferimento alle storie degli utenti che abbiamo, quindi sappiamo perché abbiamo apportato modifiche in primo luogo, è qualcosa che facciamo. Quando lo facciamo, generiamo i nostri script DDL incrementali e li pubblichiamo in modo che possano essere raccolti con gli altri risultati dello sviluppo e registrati nella nostra soluzione di compilazione. Ancora una volta, potremmo avere un modello o lavorare con più team. E come ho già detto, alcune cose sono originate dal modellatore di dati, altre sono state originate dagli sviluppatori e ci incontriamo nel mezzo per trovare il miglior design complessivo e spingerlo in avanti e assicurarci che sia correttamente progettato nel nostro strutture di dati generali. Dobbiamo mantenere la disciplina di assicurare che nel nostro modello di dati abbiamo tutti i costrutti adeguati nel corso del futuro, inclusi elementi come valori null e non null, vincoli referenziali, fondamentalmente controlli vincoli, tutte quelle cose a cui normalmente penseremmo .

Parliamo ora solo di alcuni screenshot di alcuni degli strumenti che ci aiutano a farlo. Quello che penso sia importante avere quel repository collaborativo, quindi quello che possiamo fare come modellatori di dati - e questo è uno snippet di parte di un modello di dati in background - è quando stiamo lavorando su cose che vogliamo assicurarci di poter lavorare solo sugli oggetti che dobbiamo essere in grado di cambiare, apportare le modifiche, generare i nostri script DDL per le modifiche che abbiamo apportato mentre controlliamo le cose. Quindi, ciò che possiamo fare è, in ER Studio, un esempio, possiamo controllare oggetti o gruppi di oggetti su cui lavorare, non dobbiamo controllare un intero modello o sotto-modello, possiamo controllare solo quelle cose che ci interessano. Quello che vogliamo dopo è al momento del check-out o del check-in: lo facciamo in entrambi i modi perché diversi team di sviluppo lavorano in modi diversi. Vogliamo assicurarci di associarlo alla user story o all'attività che sta guidando i requisiti per questo e che sarà la stessa user story o attività per cui gli sviluppatori svilupperanno e controlleranno il loro codice.

Quindi ecco un frammento molto veloce di un paio di schermate di uno dei nostri centri di gestione del cambiamento. Quello che fa, non ho intenzione di approfondirlo qui, ma quello che stai vedendo è la storia o l'attività dell'utente e rientrata sotto ognuno di quelli che stai vedendo i record delle modifiche effettive: abbiamo creato un record di modifica automatizzato quando eseguiamo il check-in e il check-out e possiamo anche fornire una descrizione più dettagliata di quel record di modifica. È associato all'attività, possiamo avere più modifiche per attività, come ci si aspetterebbe. E quando andiamo a quel record di modifiche, possiamo guardarlo e, cosa più importante, vedere cosa abbiamo effettivamente cambiato? Per questo particolare, la storia evidenziata lì ho avuto un tipo di cambiamento che è stato fatto e quando ho guardato l'effettivo record di cambiamento stesso, ha identificato i singoli pezzi nel modello che è cambiato. Ho cambiato un paio di attributi qui, li ho reinviati e ha portato per il giro le viste che dovevano essere modificate che dipendevano anche da quelle così che sarebbero state generate nella DLL incrementale. Non è solo la modellazione sugli oggetti di base, ma uno strumento di modellazione ad alta potenza come questo rileva anche le modifiche che devono essere increspate attraverso gli oggetti dipendenti nel database o nel modello di dati.

Se stiamo lavorando con gli sviluppatori, e lo facciamo in un paio di cose diverse, che sta facendo qualcosa nella loro sandbox e vogliamo confrontare e vedere dove sono le differenze, usiamo le funzionalità di confronto / unione dove sul lato destro e sinistro lato. Possiamo dire: "Ecco il nostro modello sul lato sinistro, ecco il loro database sul lato destro, mostrami le differenze". Possiamo quindi scegliere e scegliere come risolvere tali differenze, sia che inseriamo elementi nel database o se ci sono alcune cose che hanno nel database che riportiamo nel modello. Possiamo andare in modo bidirezionale in modo da poter andare in entrambe le direzioni aggiornando contemporaneamente sia l'origine che la destinazione e quindi produrre gli script DDL incrementali per distribuire tali modifiche nell'ambiente del database stesso, il che è estremamente importante. Ciò che possiamo anche fare è che possiamo anche usare questa funzionalità di confronto e unione in qualsiasi momento, se stiamo scattando delle istantanee lungo la strada, possiamo sempre confrontare l'inizio di uno sprint per iniziare o terminare un altro sprint in modo da poter vedere il completo cambiamento incrementale di ciò che è stato fatto in un determinato sprint di sviluppo o in una serie di sprint.

Questo è un esempio molto veloce di uno script alter, chiunque di voi abbia lavorato con i database avrà visto questo tipo di cose, questo è ciò che possiamo spingere fuori dal codice come uno script alter in modo da assicurarci che conserva le cose qui. Quello che ho tirato fuori da qui, solo per ridurre il disordine, è anche ciò che facciamo con questi script di modifica è supponiamo che ci siano anche dati in quelle tabelle, quindi genereremo anche il DML che estrarrà le informazioni delle tabelle temporanee e reinserirli anche nelle nuove strutture di dati, in modo che stiamo esaminando non solo le strutture ma anche i dati che potremmo avere già contenuti in tali strutture.

Parleremo molto rapidamente dei sistemi di compilazione automatizzati perché quando eseguiamo un progetto agile abbastanza spesso stiamo lavorando con sistemi di compilazione automatizzati in cui è necessario verificare insieme i diversi risultati finali per assicurarsi che non interrompiamo le nostre build. Ciò significa che sincronizziamo i risultati finali, è necessario effettuare il check-in di quegli script di modifica di cui ho parlato con lo script DDL, il codice dell'applicazione corrispondente deve essere verificato allo stesso tempo e lo sviluppo di molti sviluppatori ora ovviamente non lo è essendo fatto con SQL diretto contro i database e quel tipo di cose. Molto spesso stiamo usando framework di persistenza o costruendo servizi di dati. Dobbiamo assicurarci che le modifiche per tali framework o servizi siano registrate esattamente nello stesso momento. Entrano in un sistema di compilazione automatizzato in alcune organizzazioni e se la build si interrompe, in una metodologia agile, è tutto a portata di mano che fissa la build prima di andare avanti in modo da sapere che abbiamo una soluzione funzionante prima di andare oltre. E uno dei progetti a cui sono stato coinvolto, lo abbiamo portato all'estremo: se la build si è rotta abbiamo effettivamente attaccato un numero di computer nella nostra zona in cui eravamo associati con gli utenti aziendali, avevamo solo luci rosse lampeggianti come la cima di macchine della polizia. E se la build si è rotta, quelle luci rosse lampeggianti hanno iniziato a spegnersi e sapevamo che erano tutte le mani sul ponte: sistemare la build e procedere con quello che stavamo facendo.

Voglio parlare di altre cose, e questa è una capacità unica di ER Studio, aiuta davvero quando stiamo cercando di costruire questi artefatti come sviluppatori per questi confini di persistenza, abbiamo un concetto chiamato oggetti dati aziendali e ciò che ci consente di fare è se si considera questo modello di dati molto semplicistico come esempio, ci consente di incapsulare entità o gruppi di entità per cui si trovano i confini di persistenza. Laddove come modellatore di dati possiamo pensare a qualcosa di simile a un'intestazione dell'ordine di acquisto e all'allineamento dell'ordine e ad altre tabelle dettagliate che lo collegherebbero nel modo in cui lo costruiamo e i nostri sviluppatori di servizi dati devono sapere come le cose persistono in quei diversi dati strutture. I nostri sviluppatori stanno pensando a cose come l'ordine d'acquisto come un oggetto globale e qual è il loro contratto con il modo in cui creano quegli oggetti particolari. Possiamo esporre quei dettagli tecnici in modo che le persone che costruiscono i server di dati possano vedere cosa c'è sotto e possiamo proteggere gli altri pubblici dalle complessità in modo che vedano solo i diversi oggetti di livello superiore, che funziona anche molto bene per comunicare con le imprese analisti e stakeholder aziendali quando parliamo anche dell'interazione di diversi concetti aziendali.

La cosa bella anche di questo è espandere e comprimere in modo costruttivo questi in modo da poter mantenere le relazioni tra gli oggetti di ordine superiore anche se originano da costrutti contenuti all'interno di tali oggetti di dati aziendali. Ora come modellista, arriva alla fine dello sprint, alla fine dello sprint, ho molte cose che devo fare, che chiamo pulizie per il prossimo sprint. Ogni sprint che creo è quello che io chiamo la Named Release - che mi dà la mia base per quello che ora ho alla fine del rilascio. Quindi ciò significa che la mia linea di base sta andando avanti, tutte queste linee di base o Named Release che creo e salvo nel mio repository che posso usare per fare un confronto / unione in modo da poter sempre confrontare qualsiasi data fine dello sprint da qualsiasi altro sprint, che è molto importante sapere quali sono state le modifiche apportate al modello di dati lungo il percorso.

Creo anche uno script DDL delta usando nuovamente il confronto / unione dall'inizio alla fine dello sprint. Potrei aver controllato un sacco di script incrementali, ma se ne ho bisogno ora ho uno script che posso distribuire per alzare in piedi altri sandbox, quindi posso solo dire che questo è quello che avevamo all'inizio di uno sprint, spingere attraverso, costruiamo un database come sandbox per iniziare con il prossimo sprint e possiamo anche usare quelle cose per fare cose come istanze di QA stand-up e alla fine ovviamente vogliamo portare le nostre modifiche alla produzione in modo da avere più cose in corso allo stesso tempo. Ancora una volta, partecipiamo pienamente alla pianificazione dello sprint e alle retrospettive, le retrospettive sono davvero le lezioni apprese e questo è estremamente importante, perché puoi iniziare molto rapidamente durante l'agile, devi fermarti e celebrare i successi, come ora. Scopri cosa c'è che non va, miglioralo la prossima volta, ma celebra anche le cose che sono andate bene e costruisci su di esse mentre continui ad andare avanti negli sprint successivi andando avanti.

Ora parlerò molto rapidamente del valore commerciale. C'era un progetto con cui sono stato coinvolto molti anni fa che è iniziato come un progetto agile, ed è stato un progetto estremo, quindi era un team auto-organizzato in cui erano solo gli sviluppatori che stavano facendo tutto. Per farla breve, questo progetto era in stallo e stavano scoprendo che stavano spendendo sempre più volte a rimediare e correggere i difetti che erano stati identificati di quanto non fossero a spingere più funzionalità e, in effetti, quando lo guardavano in base sulle classifiche burn-down avrebbero dovuto prolungare il progetto di sei mesi a un costo enorme. E quando lo abbiamo esaminato, il modo per risolvere il problema era utilizzare un adeguato strumento di modellazione dei dati con un esperto modellatore di dati coinvolto nel progetto stesso.

Se guardi questa barra verticale su questo particolare grafico, questo mostra difetti cumulativi rispetto a oggetti cumulativi e sto parlando di oggetti dati o costrutti che sono stati creati come le tabelle con i vincoli e quei tipi di cose, se hai guardato prima dell'introduzione del modellatore di dati, il numero di difetti stava effettivamente superando e iniziando a creare un po 'di spazio sul numero effettivo di oggetti prodotti fino a quel momento. Dopo la settimana 21, ovvero quando è entrato il modellatore di dati, ha riformattato il modello di dati in base a ciò che c'era da risolvere un certo numero di cose e poi ha iniziato a modellare come parte del team di progetto in futuro, i cambiamenti mentre quel progetto veniva portato avanti . E hai visto una svolta molto rapida che in circa uno sprint e mezzo, abbiamo visto un enorme aumento del numero di oggetti e costrutti di dati che venivano generati e costruiti perché stavamo generando da uno strumento di modellazione dei dati piuttosto che da uno stick di sviluppo costruendoli in un ambiente, ed erano corretti perché avevano l'integrità referenziale adeguata e gli altri costrutti che avrebbe dovuto avere. Il livello di difetti contro quelli quasi lineari. Adottando le misure appropriate e assicurandosi che la modellizzazione dei dati fosse pienamente impegnata, il progetto è stato consegnato in tempo con un livello di qualità molto più elevato e, di fatto, non sarebbe stato realizzato se tali passaggi non fossero stati effettuati. Ci sono molti fallimenti agili là fuori, ci sono anche molti successi agili se si coinvolgono le persone giuste nei ruoli giusti. Sono un grande sostenitore dell'agile come disciplina operativa, ma devi assicurarti di avere le competenze di tutti i gruppi giusti coinvolti come team di progetto mentre procedi in un tipo agile di impresa.

Per riassumere, architetti e modellatori di dati devono essere coinvolti in tutti i progetti di sviluppo; sono davvero la colla che tiene tutto insieme perché come modellatori di dati e architetti capiamo, non solo i costrutti di dati del progetto di sviluppo dato, ma anche dove i dati esistono nell'organizzazione e da dove possiamo ricavarli e anche come verrà utilizzato e utilizzato al di fuori della specifica applicazione su cui stiamo lavorando. Comprendiamo le complesse relazioni con i dati ed è fondamentale essere in grado di andare avanti e anche dal punto di vista della governance per mappare il documento e capire come appare il tuo panorama di dati completo.

È come fabbricare; Vengo da un background di produzione. Alla fine non è possibile ispezionare la qualità in qualcosa: è necessario creare qualità nella progettazione in anticipo e sulla strada giusta e la modellazione dei dati è un modo per incorporare tale qualità nella progettazione in modo efficiente ed economico fino in fondo . E ancora, qualcosa da ricordare - e questo non deve essere banale, ma è la verità - le applicazioni vanno e vengono, i dati sono la risorsa aziendale vitale e trascendono tutti quei confini delle applicazioni. Ogni volta che stai inserendo un'applicazione ti viene probabilmente chiesto di preservare i dati da altre applicazioni precedenti, quindi dobbiamo solo ricordare che è una risorsa aziendale vitale che manteniamo nel tempo.

E questo è tutto! Da qui prenderemo più domande.

Eric Kavanagh: Va bene, bene, prima lasciami passare a Robin. E poi, Dez, sono sicuro che hai un paio di domande. Portalo via, Robin.

Dr. Robin Bloor: Ok. Ad essere sincero, non ho mai avuto problemi con i metodi di sviluppo agili e mi sembra che ciò che stai facendo qui abbia un senso eminente. Ricordo di aver osservato qualcosa negli anni '80 che indicava, in realtà, che il problema in cui ti imbatti in termini di un progetto che sfugge al controllo, è normalmente se permetti che un errore persista oltre un determinato stadio. Diventa sempre più difficile da risolvere se non riesci a ottenere quel palco giusto, quindi una delle cose che stai facendo qui - e penso che questa sia la diapositiva - ma una delle cose che stai facendo qui a sprint zero, a mio avviso, è assolutamente importante perché stai davvero cercando di ottenere i risultati finali bloccati lì. E se non vengono bloccati i risultati finali, i risultati cambiano forma.

Questo è, in un certo senso, la mia opinione. È anche la mia opinione: non ho davvero alcun argomento con l'idea che devi ottenere la modellazione dei dati a un certo livello di dettaglio prima di passare. Quello che mi piacerebbe che tu provassi e facessi perché non ne avevo un'idea completa, è solo descrivere uno di questi progetti in termini di dimensioni, in termini di come scorreva, in termini di chi, sai, dove sono sorti i problemi, sono stati risolti? Perché penso che questa diapositiva sia praticamente il cuore di essa e se potessi approfondire un po 'di più su questo, te ne sarei molto grato.

Ron Huizenga: Certo, e userò un paio di progetti di esempio. Quello che, in un certo senso, è uscito dai binari che sono stati ricondotti coinvolgendo effettivamente le persone giuste coinvolte e facendo la modellazione dei dati e tutto era davvero un modo per assicurarsi che il design fosse compreso meglio e ovviamente avevamo un miglior design di implementazione sulla strada modellandolo. Perché quando lo modelli, sai, puoi generare il tuo DDL e tutto da dietro e fuori dallo strumento piuttosto che dover continuare a costruire questo come le persone in genere potrebbero fare andando direttamente in un ambiente di database. E le cose tipiche che accadranno con gli sviluppatori sono che entreranno lì e diranno, okay, ho bisogno di questi tavoli. Diciamo che stiamo inserendo ordini. Quindi potrebbero creare l'intestazione dell'ordine e le tabelle dei dettagli dell'ordine e questi tipi di cose. Ma spesso dimenticheranno o trascureranno per assicurarsi che i vincoli siano lì per rappresentare le relazioni di chiave esterna. Potrebbero non avere le chiavi corrette. Anche le convenzioni di denominazione possono essere sospette. Non so quante volte sono andato in un ambiente, ad esempio, dove vedi un gruppo di tabelle diverse con nomi diversi, ma i nomi delle colonne in quelle tabelle sono come ID, Nome o altro, quindi ho davvero perso il contesto senza la tabella di quello che è esattamente.

Quindi, in genere quando modelleremo i dati ci assicureremo di applicare le convenzioni di denominazione appropriate a tutti gli artefatti che vengono generati anche nel DDL. Ma per essere più specifici sulla natura dei progetti stessi, in generale, sto parlando di iniziative abbastanza grandi. Uno di questi era un progetto di trasformazione aziendale da 150 milioni di dollari in cui abbiamo sostituito oltre una dozzina di sistemi legacy. Avevamo cinque diverse squadre agili in corso contemporaneamente. Avevo un team di architettura dei dati completo, quindi i miei modellatori di dati del mio team erano integrati in ciascuno degli altri team dell'area di applicazione e stavamo lavorando con una combinazione di esperti aziendali interni che conoscevano l'argomento, che stavano facendo il storie utente per i requisiti stessi. Avevamo analisti aziendali in ciascuno di quei team che stavano effettivamente modellando il processo aziendale, con i diagrammi di attività o i diagrammi dei processi di business, aiutando a rendere più efficaci le storie degli utenti con gli utenti prima che venissero consumati anche dal resto del team.

E poi, ovviamente, gli sviluppatori che stavano costruendo il codice dell'applicazione per di più. E stavamo anche lavorando, penso che fossero quattro diversi fornitori di integrazione di sistemi che stavano costruendo diverse parti dell'applicazione e dove un team stava costruendo i servizi dati, l'altro stava costruendo la logica dell'applicazione in un'area, un'altra che aveva esperienza in un'altra area di business stava costruendo la logica dell'applicazione in quella zona. Quindi abbiamo avuto un'intera collaborazione di persone che stavano lavorando a questo progetto. In quella in particolare c'erano 150 persone a terra nella squadra e altre 150 risorse in mare aperto nella squadra che stavano collaborando sprint di due settimane per scacciare questa cosa. E per farlo devi assicurarti di sparare su tutti i cilindri, e tutti sono ben sincronizzati in termini di ciò che sono i loro risultati finali e hai avuto quei frequenti reset per assicurarti che stavamo completando le nostre consegne di tutti i manufatti necessari alla fine di ogni sprint.

Dr. Robin Bloor: Beh, è ​​impressionante. E solo per un po 'più di dettagli su questo - sei finito con una mappa MDM completa, che chiamerei, dell'intera area dati alla fine di quel progetto?

Ron Huizenga: Avevamo un modello di dati completo che è stato scomposto con la decomposizione tra tutte le diverse aree di business. Il dizionario dei dati stesso in termini di definizioni complete è stato un po 'corto. Abbiamo definito la maggior parte delle tabelle; avevamo definito la maggior parte delle colonne esattamente sul significato. Ce n'erano alcuni che non c'erano e, cosa abbastanza interessante, molti erano informazioni provenienti dai sistemi legacy in cui, dopo la fine dello scopo del progetto stesso, era ancora documentato come un insieme di artefatti, per così dire, al di fuori del progetto stesso, perché era qualcosa che doveva essere sostenuto dall'organizzazione per il futuro. Allo stesso tempo, quindi, l'organizzazione ha preso una visione molto più ampia dell'importanza della governance dei dati perché abbiamo riscontrato molte carenze in quei sistemi legacy e quelle fonti di dati legacy che stavamo cercando di consumare perché non erano documentate. In molti casi avevamo solo database che dovevamo decodificare e provare a capire cosa c'era e a cosa servivano le informazioni.

Dr. Robin Bloor: Non mi sorprende, quell'aspetto particolare. La governance dei dati è, chiamiamolo, una preoccupazione molto moderna e penso che davvero ci sia molto lavoro che, diciamo, avrebbe dovuto essere svolto storicamente sulla governance dei dati. Non è mai stato perché potresti, in un certo senso, cavartela senza farlo. Ma man mano che la risorsa di dati cresceva e cresceva, alla fine non potevi.

Comunque, passerò a Dez perché penso di aver avuto il mio tempo assegnato. Dez?

Dez Blanchfield: Sì, grazie. Attraverso tutto ciò che sto guardando e pensando a me stesso che stiamo parlando di vedere l'agile usato nella rabbia in molti modi. Sebbene abbia connotazioni negative; Lo intendevo in modo positivo. Potresti forse darci solo uno scenario di, voglio dire, ci sono due posti in cui posso vedere che questo è un set perfetto: uno sono nuovi progetti che devono essere fatti dal primo giorno, ma penso invariabilmente, nella mia esperienza, è spesso il caso in cui quando i progetti diventano abbastanza grandi da renderlo necessario in molti modi, c'è una sfida interessante tra l'incollaggio dei due mondi, giusto? Puoi darci qualche tipo di approfondimento su alcune storie di successo che hai visto in cui sei entrato in un'organizzazione, è diventato chiaro che hanno avuto un leggero scontro tra i due mondi e sei stato in grado di mettere con successo questo in atto e riunire grandi progetti dove altrimenti sarebbero potuti andare sui binari? So che è una domanda molto ampia, ma mi chiedo solo se c'è un caso particolare che puoi, in un certo senso, indicare dove hai detto, sai, abbiamo messo tutto a posto e ha riunito tutto il team di sviluppo con il team di dati e abbiamo, in qualche modo, affrontato qualcosa che altrimenti avrebbe affondato la barca?

Ron Huizenga: Certo, e in effetti l'unico progetto che è risultato essere un progetto di pipeline è stato quello a cui ho accennato in cui ho mostrato quel grafico con i difetti prima e dopo che il modellatore di dati era coinvolto. Abbastanza spesso, e ci sono nozioni preconcette, in particolare se le cose vengono fatte girare da una prospettiva puramente di sviluppo, sono solo gli sviluppatori che sono coinvolti in questi progetti agili per fornire le applicazioni. Quindi quello che è successo lì, ovviamente, è che sono usciti dai binari e, in particolare, dai loro artefatti sui dati, o dai risultati dei dati che stavano producendo, non sono stati all'altezza della qualità e hanno affrontato davvero le cose nel loro complesso. E c'è abbastanza spesso questo malinteso che i modellatori di dati rallenteranno i progetti, e lo faranno se il modellatore di dati non ha l'atteggiamento giusto. Come ho detto, devi perdere - a volte ci sono modellatori di dati che hanno quel tradizionale atteggiamento gatekeeper in cui, "Siamo qui per controllare l'aspetto delle strutture di dati", e quella mentalità deve scomparire. Chiunque sia coinvolto nello sviluppo agile, e in particolare i modellatori di dati, deve assumere un ruolo di facilitatore per aiutare davvero i team ad andare avanti. E il modo migliore per illustrare ciò è mostrare molto rapidamente ai team quanto possono essere produttivi modellando prima le modifiche. E ancora, è per questo che ho parlato della collaborazione.

Ci sono alcune cose che possiamo prima modellare e generare il DDL da inviare agli sviluppatori. Vogliamo anche assicurarci che non si sentano come soggetti a restrizioni. Quindi, se ci sono cose su cui stanno lavorando, lascia che continuino a lavorare nei loro sandbox di sviluppo, perché è lì che gli sviluppatori stanno lavorando sui propri desktop o altri database per apportare alcune modifiche in cui stanno testando le cose. E collaborare con loro e dire: "Va bene, lavoraci." Lo porteremo nello strumento, lo risolveremo e poi lo spingeremo in avanti e ti forniremo gli script che puoi distribuire per aggiornare il tuo database per aggiornarli a ciò che la vera visione sanzionata effettiva della produzione sarà mentre continuiamo ad andare avanti. E puoi capovolgerlo in modo molto rapido. Ho scoperto che i miei giorni erano pieni dove andavo avanti e indietro ripetendo iterando con diversi team di sviluppo, osservando i cambiamenti, confrontando, generando script, facendoli andare avanti, e sono stato in grado di tenere il passo con quattro team di sviluppo piuttosto facilmente una volta che raggiunto un momento.

Dez Blanchfield: Una delle cose che mi viene in mente è che, sai, molte delle conversazioni che faccio quotidianamente riguardano questo treno merci che ci viene incontro, in un certo senso, dalla macchina alla -machine e IoT. E se pensiamo di avere molti dati ora sui nostri attuali ambienti aziendali, sai, se prendiamo da parte gli unicorni per un momento in cui sappiamo che Google e Facebook e gli Uber hanno petabyte di dati, ma in un'impresa tradizionale stiamo parlando di ancora centinaia di terabyte e molti dati. Ma c'è questo treno merci in arrivo presso le organizzazioni, secondo me, e il Dr. Robin Bloor ha accennato prima all'IoT. Sai, abbiamo un sacco di traffico web, abbiamo traffico sociale, ora abbiamo mobilità e dispositivi mobili, il cloud è, in un certo senso, esploso, ma ora abbiamo infrastrutture intelligenti, città intelligenti e c'è tutto questo mondo di dati che è appena esploso.

Per un'organizzazione di tutti i giorni, un'organizzazione medio-grande che è seduta lì e vede questo mondo di dolore venire su di loro e non avere in mente un piano immediato, quali sono alcuni degli asporto, in solo un paio di frasi, che hai messo a loro quando e dove hanno bisogno di iniziare a pensare in modo colloquiale a mettere in atto alcune di queste metodologie. Con quale anticipo devono iniziare a pianificare quasi di sedersi e prestare attenzione e dire che questo è il momento giusto per mettere in atto alcuni strumenti e formare il team e avviare una conversazione di vocab per affrontare questa sfida? Quanto tardi nella storia è troppo tardi o quando è troppo presto? Che aspetto ha per alcune delle organizzazioni che vedi?

Ron Huizenga: Direi per la maggior parte delle organizzazioni che se non l'hanno già fatto e hanno adattato la modellazione e l'architettura dei dati con strumenti potenti come questo, il tempo necessario per farlo è ieri. Perché è interessante il fatto che, anche oggi, quando guardiamo i dati nelle organizzazioni, abbiamo così tanti dati nelle nostre organizzazioni e in generale, sulla base di alcuni sondaggi che abbiamo visto, stiamo usando meno del cinque percento di quei dati in modo efficace quando guardiamo attraverso le organizzazioni. E con l'IoT o anche NoSQL, i big data - anche se non sono solo IoT, ma solo big data in generale - dove ora stiamo iniziando a consumare ancora più informazioni che provengono da fuori delle nostre organizzazioni, quella sfida sta diventando sempre più grande tutto il tempo. E l'unico modo in cui abbiamo la possibilità di essere in grado di affrontarlo è di aiutarci a capire di cosa si tratta.

Quindi, il caso d'uso è leggermente diverso. Quello che ci troviamo a fare è quando guardiamo quei dati, li stiamo catturando, abbiamo bisogno di decodificarli, vedere cosa c'è in quelli, sia nei nostri data lake che nei nostri database interni, sintetizzare ciò che il i dati sono, applicare significati ad esso e definizioni ad esso in modo da poter capire quali siano i dati. Perché fino a quando non capiamo di cosa si tratta, non possiamo garantire che lo stiamo usando correttamente o adeguatamente. Quindi abbiamo davvero bisogno di capire quali sono questi dati. E l'altra parte è che non farlo perché puoi, in termini di consumo di tutti questi dati esterni, assicurarti di avere un caso d'uso che supporti il ​​consumo di questi dati esterni. Concentrati sulle cose di cui hai bisogno piuttosto che cercare di estrarre e utilizzare le cose di cui potresti aver bisogno in seguito. Concentrati prima sulle cose importanti e man mano che ti fai strada, poi inizierai a consumare e cercare di capire le altre informazioni dall'esterno.

Un esempio perfetto di ciò è che so che stiamo parlando di IoT e sensori, ma lo stesso tipo di problema è stato in realtà in molte organizzazioni per molti anni, anche prima dell'IoT. Chiunque abbia un sistema di controllo della produzione, sia che si tratti di una pipeline, della produzione, di qualsiasi società basata sui processi che ha cose in cui sta facendo molta automazione con i controlli e sta usando flussi di dati e cose del genere, hanno queste manichette di dati che stanno cercando di estrarre per capire, quali sono gli eventi che sono accaduti nelle mie apparecchiature di produzione per segnalare: cosa è successo e quando? E tra questo enorme flusso di dati ci sono solo informazioni o tag specifici a cui sono interessati che devono setacciare, sintetizzare, modellare e comprendere. E possono ignorare il resto fino a quando non arriva il momento di capirlo davvero, e quindi possono espandere il loro ambito di applicazione per estenderne sempre di più, se ciò ha senso.

Dez Blanchfield: Sì, davvero. C'è una domanda a cui porterò quella che viene da un signore chiamato Eric, e ne abbiamo parlato in privato. Ho appena chiesto il suo permesso, che gli è stato dato, di chiedertelo. Perché conduce bene a questo, solo per concludere, perché stiamo andando un po 'nel tempo ora, e restituirò Eric. Ma la domanda di un altro Eric era: è ragionevole supporre che i proprietari di una startup conoscano e comprendano le sfide uniche legate alla modellazione della terminologia e così, o dovrebbero essere consegnati a qualcun altro per l'interpretazione? Quindi, in altre parole, una startup dovrebbe essere capace, pronta e disposta e in grado di focalizzarsi su questo obiettivo? O è qualcosa che dovrebbero probabilmente fare acquisti e coinvolgere gli esperti?

Ron Huizenga: Immagino che la risposta breve sia che dipende davvero. Se è una startup che non ha qualcuno in casa che è un architetto o modellatore di dati che capisce davvero il database, allora il modo più rapido per iniziare è portare qualcuno con un background di consulenza che è molto esperto in questo spazio e può ottenere loro stanno andando. Perché quello che troverai - e in effetti l'ho fatto in molti impegni che ho fatto prima di arrivare al lato oscuro nella gestione dei prodotti - è che vorrei entrare nelle organizzazioni come consulente, guidare i loro team di architettura dei dati, in modo che potessero, in qualche modo, concentrarsi nuovamente e formare la loro gente su come fare questo tipo di cose in modo che possano sostenerlo e portare avanti la missione. E poi passerei al mio prossimo fidanzamento, se questo ha senso. Ci sono molte persone là fuori che lo fanno, che hanno un'ottima esperienza di dati che può farli andare avanti.

Dez Blanchfield: Questo è un ottimo punto da asporto e sono totalmente d'accordo con esso e sono sicuro che anche il Dr. Robin Bloor lo farebbe. Soprattutto in una startup, ti concentri sull'essere una PMI sul particolare valore della proposizione che stai cercando di costruire come parte della tua stessa startup e probabilmente non dovresti avere bisogno di essere un esperto di tutto, quindi un ottimo consiglio. Ma grazie mille, una presentazione fantastica. Risposte e domande davvero fantastiche. Eric, ti restituirò perché so che probabilmente siamo passati dieci minuti nel tempo e so che ti piace restare vicino alle nostre finestre temporali.

Eric Kavanagh: Va bene. Abbiamo almeno un paio di buone domande. Lascia che te ne dia uno. Penso che tu abbia risposto ad alcuni degli altri. Ma un'osservazione e una domanda molto interessanti da parte di un partecipante che scrive, a volte i progetti agili hanno il modellatore di dati che non ha l'intera immagine a lungo termine e quindi finiscono per progettare qualcosa nello sprint uno e quindi devono riprogettare nello sprint tre o quattro. Non sembra controproducente? Come puoi evitare questo genere di cose?

Ron Huizenga: È proprio la natura dell'agile che non riuscirai a ottenere tutto perfettamente giusto in un determinato sprint. E questo è in realtà parte dello spirito di agilità, è: lavorare con esso - farai prototipazione in cui stai lavorando al codice in un dato sprint, e lo perfezionerai. E una parte di quel processo è quando stai consegnando cose che l'utente finale vede e dice: "Sì, è vicino, ma ho davvero bisogno che lo faccia anche un po 'di più". Questo non influisce solo sul design funzionale del codice stesso, ma abbastanza spesso dobbiamo modificare o aggiungere più struttura di dati al di sotto di queste determinate cose per fornire ciò che l'utente desidera. E questo è tutto un gioco equo ed è per questo che vuoi davvero usare gli strumenti ad alta potenza perché puoi modellare molto rapidamente e fare quel cambiamento in uno strumento di modellazione e quindi generare il DDL per il database su cui gli sviluppatori possono quindi lavorare per consegnarlo cambiare ancora più rapidamente. Li stai salvando dal dover fare quella codifica manuale, per così dire, delle strutture di dati e farli concentrare sulla logica di programmazione o di applicazione a cui sono più abili.

Eric Kavanagh: Questo ha perfettamente senso. Avevamo un paio di altre persone che facevano solo domande specifiche su come tutto ciò si ricollegasse allo strumento. So che hai passato un po 'di tempo a fare degli esempi e hai mostrato alcuni screenshot su come distribuire alcune di queste cose. In termini di questo intero processo di sprint, quanto spesso lo vedi in gioco nelle organizzazioni rispetto a quanto spesso vedi processi più tradizionali in cui le cose si muovono e richiedono più tempo? Quanto è prevalente l'approccio in stile sprint dal tuo punto di vista?

Ron Huizenga: Penso che lo stiamo vedendo sempre di più. So che, direi, probabilmente negli ultimi 15 anni in particolare, ho visto molto di più l'adozione di persone che riconoscono che hanno davvero bisogno di abbracciare una consegna più rapida. Così ho visto sempre più organizzazioni saltare sul carro agile. Non necessariamente del tutto; possono iniziare con un paio di progetti pilota per dimostrare che funziona, ma alcuni sono ancora molto tradizionali e si attengono al metodo a cascata. Ora, la buona notizia è, ovviamente, che gli strumenti funzionano molto bene anche in quelle organizzazioni per quel tipo di metodologie, ma abbiamo l'adattabilità nello strumento in modo che coloro che saltano a bordo abbiano gli strumenti nella cassetta degli attrezzi a la punta delle dita. Cose come il confronto e l'unione, come le capacità di reverse engineering, in modo che possano vedere quali sono le origini dati esistenti, in modo che possano effettivamente confrontare e generare gli script DDL incrementali molto rapidamente. E mentre iniziano ad abbracciarlo e vedono che possono avere la produttività, la loro inclinazione ad abbracciare agili aumenta ancora di più.

Eric Kavanagh: Beh, questa è roba fantastica, gente. Ho appena pubblicato un link alle diapositive lì nella finestra della chat, quindi dai un'occhiata; è un po 'un po' lì dentro per te. Abbiamo tutti questi webcast per la visualizzazione successiva. Sentiti libero di condividerli con i tuoi amici e colleghi. E Ron, grazie mille per il tuo tempo oggi, sei sempre piacevole avere nello show - un vero esperto del settore ed è ovvio che conosci le tue cose. Quindi, grazie a te e grazie a IDERA e, naturalmente, a Dez e al nostro Robin Bloor.

E con ciò ti saluteremo, gente. Grazie ancora per il tuo tempo e la tua attenzione. Ti ringraziamo che rimani in giro per 75 minuti, è un buon segno. Buon spettacolo ragazzi, ci sentiamo la prossima volta. Ciao ciao.