Emportar: Eric Kavanagh, l'amfitrió parla de la importància del modelat de dades en el desenvolupament àgil amb Robin Bloor, Dez Blanchfield i Ron Huizenga de IDERA.
Actualment no teniu la sessió iniciada. Inicieu la sessió o registreu-vos per veure el vídeo.
Eric Kavanagh: D’acord, senyores i senyors. Benvinguts de nou un cop més El dimecres a les 4:00 EST. Això significa que és el seu moment per a les tecnologies calentes. Sí, efectivament. Em dic Eric Kavanagh, seré el vostre amfitrió.
Per al tema d’avui, és un oldie, però un goodie. Cada dia millora perquè el seu model de gestió de dades, "Modelatge de dades en un entorn àgil", és una diapositiva sobre el vostre, realment, em va impactar a @eric_kavanagh. Realment l’hauríem de posar en aquesta diapositiva. He d’afrontar-ho.
Així els anys calents. El modelatge de dades ha estat per sempre. Realment ha estat al cor i l’ànima del negoci de gestió de la informació, dissenyant models de dades, intentant comprendre els models de negoci i alineant-los als seus models de dades. Això és el que estàs tractant de fer, oi?
El model de dades representa el negoci de forma fonamental, de manera que canvien totes aquestes noves fonts de dades? Aniríem a saber sobre això. Voleu saber com podeu mantenir-vos al capdamunt de les coses d’una manera àgil. I, per descomptat, aquesta és la paraula de l'any.
Robin Bloors amb nosaltres, el nostre analista en cap, Dez Blanchfield, que va trucar a Sydney, Austràlia i Ron Huizenga, Senior Product Manager d’IDERA, amic meu de molt de temps, excel·lent orador en aquest espai, sap les seves coses, així que no siguis tímid, li pregunteu les preguntes dures, les persones, les dures. Amb això, faré de Robin el presentador i m'ho emportaré.
Robin Bloor: Bé. Doncs gràcies per això, Eric. He de dir sobre el modelatge que crec, en realitat estava al món de les TI abans que existís, en el sentit que recordo a la companyia d’assegurances per a la qual vaig treballar, que teníem un noi que ens venia i ens donés a tots una mena. de taller sobre com modelar dades. Vam mirar, aproximadament, uns 30 anys? Potser fins i tot més temps que això, potser fa 35 anys. Un model de molt de temps ha estat part de la indústria i, per descomptat, no té res a veure amb les dones de les passarel·les.
El que volia dir, perquè el que normalment fem, sóc jo i Dez parlem de coses diferents i només pensava que Id donaria la visió general del modelatge, però hi ha una realitat que ara es fa evident.
Ja sabem, la realitat de grans dades, tenim més dades, més fonts de dades, hem obtingut fluxos de dades que han entrat en l’equació en els darrers tres o quatre anys i comença a treure-hi una part més gran i n’hi ha. una major necessitat d’entendre les dades i un augment de la taxa de canvi que s’afegeixen més dades i també s’utilitzen més estructures de dades.
És un món difícil. Heus aquí una imatge, que és realment una cosa que vam dibuixar fa uns tres anys, però bàsicament, un cop incloses la reproducció a la combinació i teniu aquesta idea de refineria de dades, centre de dades, enllaç de dades o qualsevol altra cosa, veieu que hi ha dades. genuïnament en repòs, en el sentit que no es mou gaire. A continuació, hi ha les dades, els fluxos i tots els que tens l'aplicació transaccional, a més, actualment, tens esdeveniments, fluxos de dades d'esdeveniments que es produeixen a les aplicacions i que potser necessiten, i avui dia amb les arquitectures lambda de tots els que parlem, tenen un impacte real. tot el camp de dades.
I, actualment, penseu en què existeix una capa de dades. La capa de dades existeix en una mena de forma virtual, en el sentit que una bona part es pot trobar al núvol i es pot estendre a centres de dades, pot existir en estacions de treball. La capa de dades és, fins a cert punt, a tot arreu i en aquest sentit, hi ha processos a tot arreu que intenten, d’una manera o altra, processar les dades i moure-les. Però també saber de què es tracta quan ho traslladeu, és un gran negoci.
Si ens fixem en el modelatge de dades en el sentit més general, a la part inferior d’aquest tipus de pila teniu fitxers i bases de dades. Teniu elements de dades, que tenen claus, definicions d’elements, àlies, sinònims, formats físics específics i, a continuació, tenim aquesta capa de metadades.
El més interessant de les metadades és que les metadades són enterament com les dades tenen significat. Si realment no teniu metadades, en el millor dels casos podreu endevinar el significat de les dades, però tindreu moltes dificultats. Les metadades han d’estar-hi, però el significat té estructura. No vull aprofundir en la filosofia del significat, però fins i tot en la manera en què tractem les dades, hi ha molta sofisticació en el pensament humà i el llenguatge humà, que no s’expressa fàcilment en dades. Però fins i tot pel que fa a les dades que processem realment al món, els metadades tenen significat i estructura de les metadades: una dada en relació amb una altra i què significa quan es reuneixen i què significa quan estan units amb altres dades, exigeixen que el modelem. No és prou bo per registrar etiquetes de metadades a coses, de fet, heu de registrar el significat per estructures i la relació entre aquestes estructures.
A continuació, tenim a la capa superior, les definicions de negoci, que normalment és una capa que intenta transferir el significat entre metadades, que és una forma de definició de dades que s’adapta a la forma d’organitzar les dades a l’ordinador i el significat humà. De manera que teniu termes comercials, definicions, relacions, conceptes a nivell d'entitat que existeixen en aquesta capa. I si haguéssim present una incoherència entre aquestes capes, haurem de tenir un model de dades. No és realment opcional. Com més ho puguis fer en termes d’automatitzar-lo, millor. Però a causa del seu sentit, és realment difícil alternar. És prou fàcil per agafar les metadades dins d’un registre i poder obtenir-lo a partir d’una sèrie de significats, però no us indica l’estructura dels registres ni el que signifiquen els registres o la connexió del registre.
Aleshores, això és el que es tracta del modelatge de dades. Cal destacar: com més complex sigui l'univers de dades, més cal modelar-lo. Dit d'una altra manera, és una mica com ara afegir no només més casos al món, cosa que correspondria als registres de dades, sinó que, de fet, afegien més sentit al món mitjançant la captació de dades de cada cop més. Es converteix en una sensació cada cop més complexa que hem d’entendre.
En teoria, hi ha un univers de dades i necessitem una visió sobre ell. A la pràctica, les metadades reals formen part de l’univers de dades. Per tant, no és una situació senzilla. El model inicial és de dalt a baix i de baix a dalt. Heu de construir les dues direccions i la raó és a dir, les dades tenen significat per a l’ordinador i el procés, que han de processar-lo, però tenen significat per si mateix. Per tant, necessiteu un significat de baix a dalt, que satisfaci el programari que necessita accedir a les dades i necessiteu el significat de dalt a baix per tal que els éssers humans puguin comprendre-ho. La creació de models de metadades no és mai i mai no pot ser un projecte; és una activitat continuada: hauria de ser una activitat continuada en tots els entorns que existeixen. Afortunadament, hi ha molts ambients en què això no és així i les coses no tenen control.
A l’avanç, el model augmenta amb importància a mesura que avança la tecnologia. Aquesta és la meva opinió. Però si ens fixem en el IoT, podrem entendre el mòbil més del que abans, tot i que va introduir noves dimensions: la dimensió de la ubicació amb el mòbil. Una vegada que arribeu al IoT, teníeu en compte problemes extraordinaris de dades que mai havíem de fer abans i hem de comprendre, d’una manera o altra, adequadament el que tenim, exactament com podem agregar-ho, què podem fer en termes d’aconseguir un significat de l’agregació i, per descomptat, què podem fer amb ella, quan l’hem processat.
Crec que he dit prou. Passaré a Dez Blanchfield, digues una altra cosa completament.
Dez Blanchfield: Gràcies. Sempre és un acte difícil de seguir, però aquest és un tema que vam estar d’acord i en vam parlar breument a l’hora inicial, i si us vau marcar d’hora, probablement haureu captat un munt de grans joies. Una de les coses per emportar-se i no vull robar el tro d’aquest concret, però una de les coses per emportar-se del nostre abast previ que vull compartir, en cas que no l’atrapessis, estava al voltant del tema del viatge de les dades. , i em va cridar l’atenció en realitat pensant en el recorregut que fan les dades de manera diferent al llarg de la vida generacional (any, mesos, setmana, dia, hora, minut, segon) i el contingut al voltant de les dades es posicionen dins d’aquest concepte. . Tant si sóc un codi que desenvolupa un desenvolupador, com si sóc un especialista en dades i estic pensant en l'estructura i el format i les metadades al voltant de cadascun dels elements, o la manera en què els sistemes i el negoci interactuen amb ell.
És prou interessant per emportar-me, però de totes maneres, permeteu-me submergir-me. El disseny de dades, en particular, és una frase que faig servir per parlar de totes les dades i concretament del desenvolupament d’aplicacions o d’infraestructura de bases de dades. Crec que el disseny de dades és un terme que només ho capta tot molt bé. Aquests dies en què parlem de disseny de dades, parlem de disseny de dades àgils i moderns, i la meva opinió és que feia temps que els desenvolupadors i experts en dades treballaven sols; estaven en les seves pròpies sitges i les peces de disseny anaven d’una sitja a una altra. Però estic molt d’opinió en aquests dies, que no només és el cas que ha canviat, sinó que ha de canviar; és una necessitat i això és aquesta aplicació: els desenvolupadors i tot allò que es pot fer al voltant del desenvolupament que tracta dades, els dissenyadors que facin els elements de disseny rellevants d’esquemes i camps i registres i sistemes i infraestructures de ubicació i base de dades, modelatge i tota la gestió. repte al voltant d’això. Ara és un esport d’equip i, per tant, la meva imatge d’un grup de persones que salten d’un avió que actuen en equip per representar aquesta imatge visualment interessant de gent que cau pel cel.
En tercer lloc, què ha passat per provocar-ho? Bé, hi ha un article del 1986 escrit per un parell de senyors els noms dels quals intentava desesperadament fer justícia, Hirotaka Takeuchi i Ikujiro Nonaka, crec que es pronuncia, van produir un article que van titular "Moving the Scrum Downfield". aquesta idea de una metodologia de guanyar un joc de rugbi que parteix d’aquesta activitat escrúpica, on tothom es desplaça en un lloc i dos equips fonamentalment bloquegen els caps en una cosa que s’anomena escrúixol per intentar controlar la pilota i jugar-la pel terreny. arribar a la línia de prova i tocar el terra amb la pilota i obtenir un punt, anomenat trine, i repeteixes aquest procés i obtindràs més punts per a l’equip.
Aquest article es va publicar el 1986 a la Harvard Business Review i, curiosament, va cridar molt l’atenció. Va cridar molt l'atenció perquè va introduir conceptes sorprenents i aquí teniu una captura de pantalla de la part frontal. Així que van treure aquest concepte de scrum del rugbi del joc i el van portar als negocis i, sobretot, al joc de disseny i lliurament de projectes, concretament a la publicació de projectes.
El que va fer es va donar-nos una nova metodologia en comparació amb els tipus de PRINCE2 o PMBOK que abans havíem utilitzat en el que vam anomenar metodologia de la cascada, ja sabeu, feu aquesta cosa i aquesta cosa i aquesta cosa i seguiu-los en seqüència i connecteu-los. tots els punts del voltant, que depèn del que tingueu, o no feu la segona part fins que no hagueu realitzat la primera part, ja que depenia de la primera. El que ens va donar és una nova metodologia per ser una mica més àgil, que és d’on prové el terme, sobre com entreguem les coses, i específicament sobre el disseny i el desenvolupament de projectes de base.
Alguns dels principals llogaters –tant i tot això, aprofito amb això– són els inquilins clau de la consellera.Va introduir la idea de construir la inestabilitat, que efectivament si es pensa en la por del caos, el món existeix en un estat de caos, però el planeta va formar, que és interessant, de manera que es construeix la inestabilitat, la capacitat de rebotar una mica i En realitat fan que les coses funcionin, autoorganitzen equips de projectes, solapant-se favors mitjançant un desenvolupament molt responsable, diferents tipus d’aprenentatge i control a través del viatge de l’entrega del projecte, la transferència organitzativa dels aprenentatges. Llavors, com podem treure informació d’una part del negoci i transferir-la a una altra de persones que tenen una idea però no desenvolupen codi o no desenvolupen bases de dades i infraestructures, sinó dades a aquestes persones? I específicament els resultats de caixa temporal. És a dir, fem-ho durant un període de temps, tant al dia com en 24 hores, o a la setmana o a un parell de setmanes, i veiem què podem fer i, a continuació, retrocedim.
Així, si perdoneu el puny, aquest és realment un joc nou en la publicació de projectes i els tres components bàsics que tindran sentit, a mesura que avancem una mica més aquí. Hi ha el producte: totes aquestes persones tenen la idea i tenen una necessitat de fer alguna cosa i la història que els envolta. Els desenvolupadors que operen en el model àgil d’aconseguir les seves històries i mitjançant plantejaments diaris mitjançant la metodologia scrum per discutir-la i entendre el que han de fer, i només cal que continuïn i ho facin. Aleshores, les persones, hem sentit a parlar de mestres d’escrocs que vetllen per tota aquesta cosa i entenen la metodologia prou bé com per impulsar-la. Tots hem vist aquestes imatges que vaig trobar a la part dreta de parets i pissarres plenes de notes Post-It i van ser parets de Kanban. Si no sabeu qui és Kanban, us convido a Google qui era el senyor Kanban i per què va ser un canvi en la manera de moure les coses d’un costat a l’altre en un mur literalment però en un projecte.
D'un cop d'ull, el flux de treball de scrum fa això: es fa una llista de coses que una organització vol fer, les fa passar per una sèrie de coses que anomenem ss que es desglossen en períodes de 24 hores, períodes d'un mes i que obté aquesta sèrie incremental de resultats. És un canvi significatiu en la forma en què es lliuren els projectes i es van lliurar fins a aquesta fase, ja que una part d’aquest flueix com l’exèrcit nord-americà que va desenvolupar una gran part de desenvolupar una cosa anomenada PMBOK, com la idea de no portar el tanc al camp. fins que no introduïu les bales, perquè si un tanc al camp no té bales, no serveix per a res. Així doncs, la primera part es posa bales al dipòsit, la segona part es posa el dipòsit al camp. Desgraciadament, però, el que va passar amb els desenvolupadors del món del desenvolupament d’alguna manera va agafar aquesta àgil metodologia i es va acabar amb ella, si perdona el puny, al s.
Invariablement el que va passar és, quan pensem en àgil, normalment pensem en desenvolupadors i no en bases de dades i res a veure amb el món de les bases de dades. Va ser un resultat lamentable perquè la realitat és que l’àgil no es limita als desenvolupadors. De fet, el terme àgil segons el meu parer és sovint associat exclusivament a desenvolupadors de programari i no a dissenyadors i arquitectes de bases de dades. Invariablement, els mateixos reptes que afronta en el desenvolupament de programari i d'aplicacions tenen a veure amb tot el que es refereix al disseny, desenvolupament, operació i manteniment, per tant, de la infraestructura de dades i, en particular, de les bases de dades. Entre els actors d’aquest repartiment de dades s’inclouen com els arquitectes de dades, els modeladors, els administradors, els gestors de les infraestructures de bases de dades i les pròpies bases de dades reals fins a analistes de negocis i sistemes i arquitectes, persones que s’asseuen i pensen en com són els sistemes. i les empreses funcionen i com hem arribat a fluir dades a través d’aquests.
És un tema que presento regularment, ja que és una frustració constant en la meva part perquè crec que els especialistes en dades, no haurien de ser, han d’estar íntimament implicats en tots els components de la publicació del projecte, realment, en particular el desenvolupament. Perquè no ho siguem, realment no ens estem donant la millor oportunitat d’un bon resultat. Sovint hem de fer voltes i pensar en aquestes coses perquè hi ha un escenari, arribem a una aplicació que s'està construint i descobrim que els desenvolupadors no sempre són experts en dades. Treballar amb bases de dades requereix competències molt especialitzades, sobretot al voltant de les dades, i genera una experiència. Al llarg de la nit, no us convertireu de forma instantània en un guru de base de dades o expert en coneixement de dades; sovint és una cosa que prové d’una experiència de tota la vida i, certament, és del gust del doctor Robin Bloor a Code Today, que va escriure el llibre bastant ricament.
En molts casos, i és lamentable, però és una realitat, que hi ha dues parts d’aquesta moneda, és a dir, que els desenvolupadors de programari tenen un apagat propi en referència a l’especialista de bases de dades i han creat les habilitats que necessita en el disseny de bases de dades, el desenvolupament de models és només el fonamental per a l’enginyeria de gurus de com s’obtenen les dades i de com s’organitza el viatge i com s’hi hauria de fer o no s’ha de semblar, o, sens dubte, que s’ha ingerit i entendre que s’aconsegueix generalment en habilitats natives per als desenvolupadors de programari. I alguns dels reptes habituals que tenim, només per dir-ho, inclouen com ara la creació bàsica i el manteniment i la gestió del propi disseny bàsic de bases de dades, documentar les dades i la infraestructura de bases de dades i reutilitzar aquestes actius de dades, dissenys d'esquemes, generacions d’esquemes, l’administració i el manteniment de l’esquema i l’ús d’aquests, compartir el coneixement al voltant de per què aquest esquema està dissenyat d’una manera determinada i els punts forts i feblesos que comporten amb el pas del temps provoquen canvis de dades amb el pas del temps, el modelatge de dades i els tipus. de models que apliquem als sistemes i les dades que els fem arribar. Generació de codi de base de dades i continua integrant-se i modelant dades al seu voltant i, després, accedim més ràpidament per controlar la seguretat al voltant de les dades, la integritat de les dades estem movent les dades al voltant, ja que mantenim la seva integritat, hi ha prou metadades al voltant si, en cas que les vendes vegin tots els registres de la taula o només hagin de veure l'adreça, el nom i el cognom que aparegueu a la publicació? I, per descomptat, el major repte de tot és que modelar plataformes de bases de dades que sigui totalment una conversa diferent en si mateixa.
Estic molt a l’opinió que tenint en compte tot això per fer possible qualsevol cosa d’aquest nirvana, és absolutament crític que tant els especialistes en dades com els desenvolupadors tinguin les eines adequades i que aquestes eines siguin capaces d’entregar projectes centrats en equip, disseny, desenvolupament i manteniment operatiu continuat. Ja sabeu, coses com col·laborar en projectes entre experts de dades i desenvolupadors de programari, punt de veritat o font única de veritat per a tot el que hi ha al voltant de la documentació de les bases de dades mateixes, les dades, els esquemes, d’on provenen els registres, propietaris d’aquests registres. . Crec que en aquests moments i en l’edat és absolutament crític, aconseguirem que aquest nirvana de dades sigui rei, que les eines adequades han d’estar en marxa perquè el repte és massa gran ara per a que ho puguem fer manualment i si la gent desplaçar-se i sortir d’una organització, és massa fàcil per a nosaltres no seguir el mateix procés o metodologia que pot establir una persona que sigui bona i no necessàriament transferir aquestes habilitats i habilitats endavant.
Tenint en compte això, em dirigiré al nostre bon amic d'IDERA i escoltaré aquesta eina i com aborda aquestes coses.
Ron Huizenga: Moltes gràcies i gràcies tant a Robin com a Dez per posar-vos bé en escena i veureu una mica de solapament en un parell de coses de les que us he parlat. Però realment han establert uns fonaments molt sòlids per a alguns dels conceptes dels que parlaré des de la perspectiva del modelatge de dades. I moltes de les coses que han dit fan ressò de la meva pròpia experiència quan era consultor que treballava en modelat de dades i arquitectura de dades, juntament amb equips, tant a la cascada dels primers dies com a evolucionar cap a productes més moderns amb projectes en els quals estàvem utilitzant àgils. metodologies per donar solucions.
Així doncs, del que parlaré avui es basa en aquestes experiències, així com en una visió de les eines i algunes de les capacitats de les eines que utilitzem per ajudar-nos en aquest viatge. El que tractaré molt breument és, no entraré en fragments amb gaires detalls; només teníem una panoràmica real de què és això. Parlaré sobre això, què és un model de dades i què significa realment per a nosaltres? I com permetem el concepte de modelador de dades àgils a les nostres organitzacions, en termes de, com involucrem els modeladors de dades, quina participació de modeladors i arquitectes durant els s, en quins tipus d’activitats s’han de realitzar? i, com a teló de fons, quines són algunes de les importants capacitats d’eines de modelatge que utilitzem per ajudar realment a fer aquesta feina més fàcil? A continuació, vaig a aprofundir i parlaré una mica sobre alguns dels valors empresarials i els avantatges de tenir un modelador de dades implicat, o de la manera en què explicaré la història, els problemes de no tenir un modelador de dades completament implicat en els projectes i t’ho mostraré que es basa en l’experiència i en un gràfic de defectes d’una imatge abans i després d’un projecte real en què vaig estar involucrat fa molts anys. A continuació, resumirem alguns punts més i, a continuació, tindrem preguntes i respostes.
ER Breu és una suite molt potent que compta amb molts components diferents. L’arquitecte de dades, que és on els modeladors i arquitectes de dades passen la major part del temps fent la seva modelització de dades. També hi ha altres components dels quals no parlarem del moment, com ara Business Architect, on fem modelatge de processos i Software Architect, per a alguns models de UML. Després hi ha el Repositori, on fem el registre i compartim els models i permetem als equips col·laborar en aquests i publicar-los al servidor d'equip de manera que diversos públics interessats que participen en un projecte puguin veure els artefactes que nosaltres. tornem a crear tant des de la perspectiva de les dades com les altres coses que estem fent en el lliurament del projecte.
En el que em centraré avui, seran algunes de les coses que veurem a partir de Data Architect i perquè és realment important que comptem amb la col·laboració d’aspectes basats en dipòsits. Especialment quan comencem a parlar de conceptes com la gestió del canvi que són imprescindibles, no només els projectes de desenvolupament àgils, sinó també qualsevol tipus de desenvolupament.
Parlem, doncs, d’un moment sobre el Modelador de dades àgil. Com ja, al·ludit anteriorment a la presentació, és imprescindible que tinguem modeladors de dades i / o arquitectes dedicats plenament als processos de desenvolupament àgils. Ara, el que ha passat històricament és, sí, realment hem pensat en una forma àgil des del punt de vista del desenvolupament, i hi ha un parell de coses que han passat que realment han provocat que es produís. Part d'ella es va deure només a la naturalesa de la manera com es va desenvolupar el desenvolupament. A mesura que el desenvolupament àgil va començar i vam començar amb aquest concepte d’equips d’autoorganització, si beus el Kool-Aid una mica massa pur i estàs al costat de la programació extrema de les coses, hi havia una interpretació literal de coses com la equips autoorganitzadors, que molta gent va interpretar, el que necessitem és un grup de desenvolupadors capaços de crear tota una solució. Tant si es tracta de desenvolupar el codi, les bases de dades o les bases de dades que hi ha al darrere i tot va quedar relegat als desenvolupadors. Però el que passa amb això és perdre's en les habilitats especials que tenen les persones. He descobert que els equips més forts són els que estan compostos per persones de diferents orígens. Com ara una combinació de desenvolupadors de programari forts, arquitectes de dades, modeladors de dades, analistes de negocis i grups d’interès empresarials, tots col·laborant junts per impulsar una solució final.
Del que també parlo avui, ho faré en el marc d’un projecte de desenvolupament on desenvolupem una aplicació que, òbviament, també hi tindrem associat el component de dades. Tanmateix, hem de fer un pas enrere abans de fer-ho, perquè ens adonem que hi ha molt pocs projectes de desenvolupament de Greenfield allà on ens centrem completament en la creació i el consum de dades limitats només dins del mateix projecte de desenvolupament. . Hem de fer un pas enrere i mirar el punt de vista organitzatiu global des de la perspectiva de les dades i la perspectiva del procés. Perquè la informació que estem utilitzant pot ser que ja existeixi en algun lloc de les organitzacions. Com a modelistes i arquitectes, la traiem a la llum, així sabrem d’on provenir aquesta informació dels propis projectes. També coneixem les estructures de dades implicades perquè tenim patrons de disseny igual que els desenvolupadors tenen patrons de disseny del seu codi. I també cal tenir aquesta perspectiva organitzativa general. No podem simplement mirar dades a la contra de l’aplicació que creem. Hem de modelar les dades i assegurar-nos que les documentem perquè viuen molt més enllà de les pròpies aplicacions. Aquestes aplicacions vénen i van, però hem de ser capaços de mirar les dades i assegurar-nos que siguin robustes i estructurades, no només per a l'aplicació, sinó també per a decisions que informin d'activitats, informes de BI i integració a altres aplicacions, internes i externs a les nostres organitzacions també. Per tant, hem de fixar-nos en tota la imatge general de les dades i en què consisteix el cicle de vida d’aquestes dades i comprendre el viatge de peces d’informació a tota l’organització, des del bressol fins a la tomba.
Tornant als equips reals i com hem de treballar realment, la metodologia de la cascada es va percebre com a massa lenta per obtenir resultats. Perquè, tal com es va assenyalar amb l’exemple del tanc, va ser un pas rere l’altre i sovint es va trigar massa temps a obtenir un resultat final viable. El que fem ara és que necessitem tenir un estil de treball iteratiu on desenvolupem de forma creixent components del mateix i elaborant-lo al llarg del temps on produïm codi o artefactes utilitzables, per a tots els diré. L’important és la col·laboració entre els grups d’interès tècnics de l’equip i els grups d’interessos empresarials, ja que col·laborem per portar aquestes històries d’usuaris a una visió implementable del codi i les dades que també admetin aquest codi. I el mateix Modelador de dades àgil sovint trobarà que no tenim prou modeladors a les organitzacions perquè un model de dades o arquitecte pugui donar suport simultàniament a diversos equips.
I l’altre aspecte d’això és que, fins i tot si tenim diversos modelistes, hem d’assegurar-nos que disposem d’un conjunt d’eines que estem utilitzant que permet la col·laboració de diversos projectes que estan en vol alhora i compartir-los. artefactes de dades i les funcions de check-in i check-out. Passaré tot això ràpidament, ja que ja ho vam tractar a la secció anterior. La veritable premissa de l’àgil és que baseu les coses fora de la llista d’històries, d’històries o requisits. Dins de les iteracions, col·laborem com a grup. Normalment és molt freqüent que hi hagi dues setmanes o un mes, segons l’organització. A més, fem reunions de revisió i puntualització diàries de manera que eliminem els bloquejants i ens assegurem que avancem tots els aspectes sense haver-nos detingut en diferents àrees a mesura que passem. I, en aquests ss, volem assegurar-nos que estem produint lliuraments usables com a part de cada article.
Una solució lleugerament diferent, ampliant-la encara més, scrum és la metodologia de què parlaré més específicament aquí i només hem augmentat bàsicament aquesta imatge anterior amb algunes altres facetes. Normalment hi ha una llista de producte i, després, hi ha un enllaç. Així doncs, tenim un retard general que, al principi de cada reiteració, ens pareixem per dir: "Què anem a crear això?" I que es farà en una reunió de planificació. A continuació, desglossem les tasques associades a això i realitzem aquestes publicacions diàries d'una a quatre setmanes. A mesura que anem fent el seguiment dels nostres avenços mitjançant gràfics de combustió i gràfics desplegables per fer un seguiment bàsic del que queda per construir vers el que estem construint per establir coses com la nostra velocitat de desenvolupament, farem la nostra horari, tot aquest tipus de coses. Tots aquests s’elaboren contínuament durant els s, en comptes d’anar uns mesos pel camí i esbrinar que arribaràs breument i caldrà ampliar la programació del projecte. I molt important, com a part de tots els equips, hi ha una revisió al final i tan retrospectiva, així que abans de començar la propera iteració estàs revisant el que vas fer i estàs buscant maneres de millorar. la propera vegada a través.
Pel que fa a productes lliurables, es tracta bàsicament d’una diapositiva que resumeix els tipus típics de coses que es produeixen a la ss. I és molt centrada en el desenvolupament, de manera que hi ha moltes coses que veiem aquí, com ara dissenys funcionals i casos d’ús, fer proves de codi de disseny, quan mirem aquestes caselles aquí i no passaré per elles. en qualsevol nivell de detall, estan molt orientats al desenvolupament. I, enterrat a sota, hi ha el fet que també necessitem disposar de dades lliurables que vagin de la mà per recolzar aquest esforç. Així, cada cop que veiem coses com els endarreriments enrere, els requisits i les històries d’usuaris, a mesura que anem passant, hem de mirar quins són els treballs de desenvolupament que hem de fer, quines són les peces d’anàlisi que hem de fer, i què? Disseny de dades o model de dades, què passa amb coses com els glossaris de negocis per associar el significat comercial a tots els artefactes que estem produint? Perquè hem de produir aquests lliuraments útils en tots els s.
Hi ha qui dirà que hem de produir un codi usable al final de cada s. No és necessàriament el cas, és a dir en una perspectiva de desenvolupament més pura, però molt sovint, sobretot al principi, pot ser que tinguem una cosa com el zero, on estem concentrats exclusivament a posar-nos en peu, fer coses com aconseguir les nostres estratègies de prova. lloc.Un disseny d’alt nivell per iniciar-lo abans de començar a omplir els detalls i assegurar-nos que tenim un conjunt net d’històries o requisits inicials abans de començar a comprometre altres públics i, a continuació, construir-nos com a equip a mesura que avancem. Sempre hi ha una mica de temps de preparació, de manera que sovint tindrem un zero o fins i tot un zero. Podria ser una mica una fase d’inici abans de fer un vol complet a l’hora d’entregar la solució.
Parlem molt breument dels models de dades. Quan les persones pensen en models de dades, sovint pensen en un model de dades com una imatge de com s’uneixen les diferents dades d’informació: aquesta és només la punta de l’iceberg. Per encarnar plenament l’esperit de com realment voleu apropar-vos al modelat de dades, ja sigui en desenvolupament àgil i altres coses, és necessari adonar-vos que el model de dades, si es fa correctament, esdevé la vostra especificació completa per a què signifiquen aquestes dades a l’organització i com es desplega a les bases de dades de fons. Quan dic bases de dades, no em refereixo només a les bases de dades relacionals que podríem utilitzar, sinó a les arquitectures actuals on tenim dades grans o plataformes NoSQL, ja que prefereixo anomenar-les. També els grans magatzems de dades, perquè potser estem combinant molts magatzems de dades diferents pel que fa a consumir informació i incloure-ho a les nostres solucions, així com com persistim o guardem aquesta informació de les nostres solucions.
És possible que estiguem treballant amb diverses bases de dades o fonts de dades simultàniament a l’aplicació d’una determinada aplicació. El que és molt important és voler ser capaç de tenir una especificació completa, per tant, una especificació lògica del que això vol dir com a perspectiva organitzativa, quines són les construccions físiques en termes de com realment definim les dades, les relacions que hi ha en el seu. bases de dades, les restriccions d’integritat referencials, comproven les restriccions, totes aquelles peces de validació que normalment penseu. Les metadades descriptives són extremadament importants. Com saps com utilitzar les dades de les teves aplicacions? Si no es pot definir i saber què significa o saber d’on prové, per assegurar-se que està consumint les dades correctes en aquestes aplicacions, assegurant-nos que tenim convencions de denominació correctes, definicions completes, cosa que significa un diccionari complet de dades per a no només les taules, però les columnes que inclouen aquestes taules, i les notes de desplegament de detalls sobre com utilitzem això perquè necessitem crear aquesta base de coneixement perquè, fins i tot quan es faci aquesta aplicació, aquesta informació s'utilitzarà per a altres iniciatives, així que hem d'assegurar-nos que tenim tot això documentat per a futures implementacions.
Un cop més, ens referim a coses com ara tipus de claus, claus, índexs, el mateix model de dades inclou moltes de les regles de negoci que es fan en joc. Les relacions no són només restriccions entre diferents taules; sovint ens ajuden a descriure quines són les veritables regles comercials al voltant de com es comporten aquestes dades i com funcionen junts com a unitat cohesionada. I, per descomptat, les restriccions de valor són molt importants. Ara, per descomptat, una de les coses que tractem constantment, i que cada vegada és més freqüent, són coses com el govern de les dades. Així, doncs, des de la perspectiva de governança de dades, també hem de mirar, què estem definint aquí? Volem definir coses com ara classificacions de seguretat. Quins tipus de dades tractem? Què es considerarà la gestió de dades mestres? Quins són els comerços transaccionals que estem creant? Quines dades de referència utilitzem en aquestes aplicacions? Hem d’assegurar-nos que es captura correctament en els nostres models. I també les consideracions sobre la qualitat de les dades, hi ha certes dades que són més importants per a una organització que d’altres.
He participat en projectes on substituíem més d’una dotzena de sistemes antics per nous processos empresarials i dissenyem noves aplicacions i magatzems de dades per substituir-los. Calia saber d’on venia la informació. Quin tipus d’informació més important, des d’una perspectiva empresarial, si ens fixem en aquesta diapositiva de model de dades en concret que tinc aquí, veureu que els quadres inferiors d’aquestes entitats particulars, que només són un petit subconjunt, jo. En realitat he sabut capturar el valor del negoci. Ja siguin alts, mitjans o baixos per a aquest tipus de coses per a aquests diferents constructes dins de l'organització. També he capturat coses com ara les classes de dades mestres, ja siguin taules mestres, tant si són de referència com si eren transaccionals. Així, podem ampliar els nostres metadades en els nostres models per donar-nos moltes altres característiques fora de les pròpies dades, cosa que ens va ajudar realment amb altres iniciatives fora dels projectes originals i tirar-ho endavant. Ara, en una diapositiva, vaig a passar bastant ràpidament.
Ara parlaré molt ràpidament sobre què fa un modelador de dades a mesura que anem passant per aquests diferents ss. En primer lloc, un participant complet a les sessions de planificació de les sessions, on estem donant històries dels usuaris, comprometent-nos amb el que oferirem, i esbrinant com ho estructurarem i el farem arribar. El que també faig com a modelador de dades és que sé que treballaré en àrees separades amb diferents desenvolupadors o amb persones diferents. Una de les característiques importants que podem tenir és quan estem fent un model de dades, que podem dividir aquest model de dades en visions diferents, tant si les anomeneu àmbits matèries com a sub-models, és la nostra terminologia. De manera que a mesura que anem construint el model, també el mostrem en aquestes diferents perspectives sub-model, de manera que els diferents públics només veuen el que és rellevant per a ells per poder concentrar-se en el que estan desenvolupant i presentant. De manera que potser algú treballa en una part de programació d’una aplicació, potser algú més treballa en una entrada de comanda on fem totes aquestes coses en una sola, però puc donar-los els punts de vista a través d’aquests sub-models que només aplicar-se a la zona on es treballa. A continuació, els que s’orienten al model global i a tota l’estructura de sub-models per oferir a les audiències diferents el que han de veure.
Els fonaments des d’una perspectiva de modelatge de dades que volem tenir és tenir sempre una línia de referència a la qual podem remuntar-nos perquè una de les coses que hem de poder fer és, ja sigui al final o al final de diverses ss, volem saber per on vam començar i sempre tenim una línia de referència per saber què era el delta o la diferència del que vam produir en un determinat s. També hem d’assegurar-nos que podem obtenir un canvi ràpid. Si hi entra com a modelador de dades, però en el paper tradicional de gatekeeper dient "No, no, no ho pots fer, primer hauríem de fer totes aquestes coses", seran exclosos de l'equip quan realment ho necessitin ser un participant actiu en tots aquells equips de desenvolupament àgils. Això vol dir que algunes coses cauen del vagó fent una determinada s i les recolliu a les versions posteriors.
A tall d’exemple, podeu centrar-vos en les estructures de dades només per aconseguir que el desenvolupament tingui en compte la peça d’entrada de comanda de què us parlava. En algunes versions posteriors, podeu tornar i emplenar les dades com alguns de la documentació del diccionari de dades d'alguns d'aquests artefactes que heu creat. No completareu aquesta definició només en una; continuareu seguint els vostres lliuraments de manera incremental perquè hi haurà vegades que podreu omplir aquesta informació treballant amb analistes empresarials quan els desenvolupadors estiguin ocupats en crear les aplicacions i la persistència al voltant d'aquests magatzems de dades. Vostè vol facilitar i no ser el coll d’ampolla. Hi ha diferents maneres de treballar amb desenvolupadors. Per a algunes coses, tenim uns patrons de disseny, de manera que som un participant complet al capdavant, de manera que pot ser que tinguem un patró de disseny on direm que el posarem al model, el transmetrem cap a les bases de dades de la caixa de sorra dels desenvolupadors i, després, poden començar a treballar amb ell i sol·licitar canvis.
Hi pot haver altres àrees en què els desenvolupadors han estat treballant, tenen alguna cosa en què estan treballant i prototipen algunes coses per intentar algunes coses en el seu propi entorn de desenvolupament. Prenem la base de dades amb la qual han estat treballant, la incorporem a la nostra eina de modelatge, comparem amb els models que tenim i, després, resolem i emportem els canvis de nou perquè puguin refactoritzar els seus codis perquè siguin les estructures de dades adequades. que necessitem Com que potser han creat algunes coses que ja teníem en altres llocs, així que ens assegurem que treballin amb les fonts de dades adequades. Ens limitem a iterar-ho fins a les nostres solucions de manera que aconseguim els lliuraments de dades complets, la documentació completa i la definició de totes aquelles estructures de dades que estem produint.
Els projectes àgils amb més èxit amb els quals he estat involucrat en termes d’entregues molt bones és, teníem una filosofia, modelar tots els canvis a l’especificació completa de bases de dades físiques. En essència, el model de dades es converteix en les bases de dades desplegades amb les quals treballa per a qualsevol cosa nova que creem i que té referències completes dels altres magatzems de dades si la consumim d’altres bases de dades externes. Com a part d'això, produïm scripts incrementals versus fer una generació completa cada vegada. I estem utilitzant els nostres patrons de disseny per donar-nos aquest augment ràpid en termes d’introduir les coses en ss amb els diferents equips de desenvolupament amb què estem treballant.
A les activitats també hi ha una altra vegada aquesta línia de referència per comparar / fusionar, així que prenem la idea de modelar cada canvi. Cada cop que fem un canvi, el que volem fer és voler modelar el canvi i el que és molt important, el que ha faltat a la modelització de dades fins fa poc, de fet, fins que l’hem reintroduït, és la capacitat d’associar el modelatge. les tasques i els vostres lliuraments amb les històries i tasques dels usuaris que realment provoquen aquests canvis. Volem poder comprovar els canvis de model, de la mateixa manera que els desenvolupadors comproven els seus codis, fent referència a aquelles històries d’usuaris que tenim, de manera que sabem per què hem fet canvis en primer lloc, això és el que fem. Quan ho fem, generem els nostres scripts de DDL incrementals i els publiquem de manera que es puguin recollir amb els altres lliuraments de desenvolupament i consultar la nostra solució de creació. Un cop més, potser tindrem un model o treballem amb diversos equips. I, com he parlat, algunes coses són originades pel modelador de dades, altres són originades pels desenvolupadors i ens trobem al mig per presentar el millor disseny general i impulsar-lo endavant i assegurar-nos que estigui correctament dissenyat en el nostre estructures de dades generals. Hem de mantenir la disciplina de vetllar per tenir totes les construccions adequades en el nostre model de dades a mesura que avancem, incloses coses com valors nuls i no nuls, restriccions referencials, comprovar bàsicament restriccions, totes aquestes coses en les que normalment pensarem .
Parlem ara d’unes quantes captures de pantalla d’algunes de les eines que ens ajuden a fer-ho. El que crec que és important és tenir aquest dipòsit col·laboratiu, de manera que el que podem fer com a modeladors de dades, i es tracta d’un fragment de part d’un model de dades en segon pla, és quan treballem en coses que volem assegurar-nos que podem treballar només els objectes que necessitem per poder canviar, fer les modificacions, generar els nostres scripts DDL per als canvis que hem realitzat a mesura que revisem les coses. Així doncs, en ER Studio és un exemple, podem consultar objectes o grups d'objectes per treballar, no hem de revisar tot un model o sub-model, podem consultar només aquelles coses que ens interessen. El que volem després d’això és a l’hora de check-out o check-in - ho fem de totes dues maneres perquè diferents equips de desenvolupament funcionen de maneres diferents. Volem assegurar-nos que ho associem a la història o tasca d’usuari que condueixi als requisits i que serà la mateixa història o tasca d’usuari que els desenvolupadors desenvoluparan i comprovarà el seu codi.
Aquí teniu un fragment molt ràpid d'un parell de pantalles d'un dels nostres centres de gestió de canvis. Què fa això, no passaré a grans detalls aquí, però el que estàs veient és la història o la tasca de l’usuari i indentats a sota de cadascun dels quals veieu els registres de canvis reals: hem creat un registre de canvi automatitzat quan fem el check-in i el check-out i també podem incloure més descripció d’aquest registre de canvis. S'associa a la tasca, podem tenir diversos canvis per tasca, com espereu. I quan entrem en aquest registre de canvis podem mirar-lo i més important veure, què hem canviat realment? Per a aquesta particular, la història destacada hi vaig tenir un tipus de canvi que es va fer i quan vaig mirar el registre de canvis real, ha identificat les peces individuals del model que ha canviat. He canviat un parell d'atributs aquí, els he tornat a seleccionar i he aportat les visites que havien de canviar que també eren depenents d'aquests, de manera que es generaran a la DLL incremental. No només es modela en els objectes base, sinó que una eina de modelat de gran potència com aquesta també detecta els canvis que s’han d’arreplegar a través dels objectes dependents de la base de dades o del model de dades.
Si estem treballant amb desenvolupadors, i ho fem en un parell de coses diferents, això és fer alguna cosa a la seva caixa de sorra i volem comparar i veure on es troben les diferències, utilitzem funcions de comparació / fusió on es troba a la part dreta i esquerra. costat. Podem dir, "Aquí és el nostre model a la part esquerra, aquí es troba la seva base de dades a la part dreta, mostra'm les diferències". A continuació, podem triar i triar com resolem aquestes diferències, tant si introduïm les coses a la base de dades com si Hi ha algunes coses que tenen a la base de dades que introduïm al model. Podem anar de forma bidireccional, de manera que podrem anar ambdues direccions actualitzant simultàniament tant la font com la destinació i, a continuació, produïm els scripts DDL incrementals per desplegar aquests canvis al propi entorn de la base de dades, que és extremadament important. El que també podem fer és que també puguem fer servir aquesta capacitat de comparació i combinació en un moment donat, si estem realitzant instantànies a través del camí, sempre podem comparar l’inici d’una amb l’inici o el final d’una altra per tal que puguem veure el canvi incremental complet del que es va fer en un desenvolupament o d'una sèrie de ss.
Aquest és un exemple molt ràpid d’alter script, qualsevol de vosaltres que hagi estat treballant amb bases de dades haurà vist aquest tipus de coses, això és el que podem treure del codi com un script de manera que ens assegurem que conserva les coses aquí El que vaig treure d’aquí, només per reduir l’enfocament, és el que també fem amb aquests alter scripts és que suposem que també hi ha dades d’aquestes taules, de manera que també generarem el DML que obtindrà la informació de les taules temporals i impulsar-la de nou a les noves estructures de dades, de manera que no només estem analitzant les estructures, sinó les dades que ja podríem contenir en aquestes estructures.
Anem a parlar molt ràpidament sobre sistemes de construcció automatitzats, ja que quan realitzem un projecte àgil amb molta freqüència treballem amb sistemes automatitzats de construcció on hem de revisar els diferents lliuraments junts per assegurar-nos que no es trenqui la nostra composició. El que vol dir és sincronitzar els lliuraments, cal que es registrin els scripts de canvis de què he parlat amb l'script DDL, el codi d'aplicació corresponent s'ha de registrar al mateix temps i, per descomptat, no hi hagi molts desenvolupadors. es fa amb SQL directe contra les bases de dades i aquest tipus de coses. Molt sovint fem servir marcs de persistència o construint serveis de dades. Hem d’assegurar-nos que els canvis d’aquests marcs o serveis es registren exactament al mateix temps. Entren en un sistema de generació automatitzat en algunes organitzacions i si la construcció es trenca, amb una metodologia àgil, tot funciona en la reparació del pont que es construeixen abans que avancem, de manera que sabem que tenim una solució de treball abans d’anar més enllà. I en un dels projectes amb els quals estava involucrat, ho vam arribar a l’extrem: si es va produir un trencament de la creació, en realitat teníem adherit a diversos ordinadors de la nostra zona on estàvem colocats amb els usuaris del negoci, teníem llums intermitents vermelles. com la part superior dels cotxes de la policia. I si la acumulació es trencava, aquestes llums vermelles intermitents començaven a apagar-se i sabíem que era tot plegat a la coberta: arreglar la construcció i continuar amb el que estàvem fent.
Vull parlar d’altres coses, i aquesta és una capacitat única d’ER Studio, realment ajuda quan intentem crear aquests artefactes com a desenvolupadors d’aquests límits de persistència, tenim un concepte anomenat objectes de dades empresarials i el que ens permet fer és que si observeu un model de dades tan simplista com a exemple, ens permet encapsular entitats o grups d’entitats per on es troben els límits de la persistència. Quan nosaltres, com a modelador de dades, puguem pensar en alguna cosa com una capçalera de la comanda de compra i l’alineació de la comanda i altres taules detallades que s’ajusten a la forma en què la construïm i els desenvolupadors de serveis de dades necessiten saber com continuen les coses per a aquestes dades diferents. estructures. Els nostres desenvolupadors estan pensant en coses com l'ordre de compra com a objecte en general i quin és el seu contracte amb la creació d'aquests objectes. Podem exposar aquest detall tècnic perquè la gent que construeixi els servidors de dades pugui veure què hi ha a sota i puguem protegir els altres públics de les complexitats, de manera que només veuen els diferents objectes de nivell superior, que també funciona molt bé per comunicar-se amb el negoci. analistes i grups d’interès empresarials quan parlem també d’interacció de diferents conceptes empresarials.
El més bo d’això també és ampliar i esfondrar constructivament, de manera que puguem mantenir les relacions entre els objectes d’ordre superior, encara que s’originin en construccions que s’inclouen dins dels mateixos objectes de dades comercials. Ara, com a modelista, arribo al final de la s, al final de la reunió, tinc moltes coses que necessito fer, que anomeno la meva neteja per als propers. Cada cop creo el que anomeno alliberament anomenat, que és el que em proporciona la meva línia de referència per al que ara tinc al final de la versió. De manera que això vol dir que la meva línia de base avança, totes aquestes línies bàsiques o les publicacions anomenades que creo i deso al meu dipòsit, puc fer una comparació / unió, de manera que sempre puc comparar amb els extrems de qualsevol de qualsevol altre s, que és molt important conèixer quins van ser els vostres canvis al model de dades durant el viatge.
També creo un script DDL delta fent servir la comparació / fusió de nou des del principi fins al final de s. Potser he comprovat un conjunt de seqüències incrementals, però si ho necessito, ara tinc un script que puc desplegar per presentar altres caixes de sorra de manera que només puc dir que això és el que teníem al principi de la primera. a través de, creem una base de dades com a caixa de sorra per començar amb les properes s i també podem utilitzar aquestes coses per fer coses com les instàncies de QA standup i, per descomptat, volem anar impulsant els canvis cap a la producció, per la qual cosa tindrem múltiples coses en marxa. al mateix temps. De nou, participem plenament en la planificació i les retrospectives, les retrospectives són realment les lliçons apreses i això és extremadament important, ja que es pot anar molt ràpidament durant l’àgil, cal aturar-se i celebrar els èxits, com ara. Esbrineu el que no és correcte, milloreu-ho millor la propera vegada, però també celebreu les coses que van anar bé i aprofiteu-les mentre continueu avançant en les pròximes publicacions.
Ara parlaré molt ràpidament del valor empresarial. Hi va haver un projecte en el qual em vaig involucrar fa molts anys que va començar com un projecte àgil i va ser un projecte extrem, de manera que es tractava d’un pur equip d’autoorganització on es feien només desenvolupadors que ho feien tot. Per fer una història llarga, aquest projecte s’aturava i trobaven que es dedicaven cada cop més a l’hora de remetre i arreglar els defectes que s’identificaven que no pas a impulsar més funcionalitat i, de fet, quan s’ho miraven basats. A les llistes de detalls, haurien d’ampliar el projecte sis mesos a un cost enorme. I quan el vam examinar, la manera de solucionar el problema va ser utilitzar una eina de modelat de dades adequada amb un modelador de dades qualificat implicat en el propi projecte.
Si mireu aquesta barra vertical d’aquest gràfic en concret, es mostren defectes acumulatius enfront d’objectes acumulatius i estic parlant d’objectes de dades o construccions que s’han creat, com les taules amb les restriccions i aquest tipus de coses, si us fixeu en Abans que es va introduir el modelador de dades, el nombre de defectes superava realment i començava a generar una mica de buit respecte el nombre real d'objectes produïts fins a aquest moment. Després de la setmana 21, és a dir quan va entrar el modelador de dades, va tornar a configurar el model de dades basat en el que hi havia per arreglar diverses coses i després va començar a modelar com a part de l’equip del projecte endavant, els canvis a mesura que aquell projecte s’anava avançant. . I vàreu veure un canvi ràpid que al cap de mig any aproximadament, vàrem veure una enorme pujada en el nombre d'objectes i construccions de dades que es generen i es construïen perquè generem una eina de modelatge de dades en lloc d'un edifici de pal de desenvolupador. en un entorn i eren correctes perquè tenien la integritat referencial adequada i les altres construccions que hauria de tenir. El nivell de defectes respecte a la línia gairebé plana. Mitjançant les accions apropiades i assegurant-se que el modelat de dades estigués totalment implicat, el projecte es va lliurar a temps amb un nivell de qualitat molt més elevat i, de fet, no s’hauria realitzat en absolut si aquests passos no s’haguessin realitzat. Hi ha molts fracassos àgils, també hi ha molts èxits àgils si obtindríeu les persones adequades en els papers adequats. Sóc un gran defensor de l’àgil com a disciplina operativa, però heu d’assegurar-vos que disposeu de les habilitats de tots els grups adequats implicats com a equips de projecte a mesura que s’avança en un tipus de treball àgil.
En resum, els arquitectes i modeladors de dades han d’estar implicats en tots els projectes de desenvolupament; realment són la cola que ho manté tot plegat perquè, com a modeladors i arquitectes de dades, entenem, no només les construccions de dades del projecte de desenvolupament donat, sinó també allà on les dades existeixen a l’organització i on podem originar aquestes dades i també com s'utilitzarà i es farà servir fora de la pròpia aplicació en què estem treballant. Entenem les complexes relacions de dades i és primordial poder avançar i també des d’una perspectiva de govern per a fer un mapa de documents i entendre com és el vostre paisatge de dades complet.
És com fabricar; Venia d’un bagatge de fabricació. No podeu inspeccionar la qualitat en alguna cosa al final: heu de contribuir a la qualitat en el vostre disseny previ i pel vostre pas, i el modelat de dades és una manera d’incorporar aquesta qualitat al disseny d’una manera eficient i rendible fins al moment. . I una vegada més, alguna cosa que cal recordar, i això no és de veritat, sinó que és la veritat, les aplicacions vénen i van, les dades són l’actiu corporatiu vital i transcendeixen tots els límits de l’aplicació. Cada vegada que introduïu una sol·licitud, probablement se us demani que conserveu les dades d’altres aplicacions anteriors, per la qual cosa només cal recordar que és un actiu corporatiu vital que mantenim al llarg del temps.
I ja està! A partir d’aquí ens farem més preguntes.
Eric Kavanagh: D'acord, bé, deixa'm tirar-ho primer a Robin. Aleshores, Dez, estic segur que teniu un parell de preguntes. Treu-ho, Robin.
Robin Bloor: Bé. Per ser sincer, mai he tingut cap problema amb els mètodes de desenvolupament àgils i em sembla que el que esteu fent aquí té un sentit eminent. Recordo haver estudiat alguna cosa a la dècada de 1980 que indicava, realment, que el problema amb el qual realment teniu en compte un projecte que no té control, normalment és si deixeu que un error continuï més enllà d’una etapa determinada. Simplement és més i més difícil de solucionar si no aconseguiu aquesta fase correcta, així que una de les coses que esteu fent aquí i crec que es tracta de la diapositiva, però és una de les coses que feu aquí. en zero, en la meva opinió, és absolutament important perquè realment intenteu que s'incloguin els lliuraments. I si no teniu els lliuraments fixats, els lliuraments canviaran de forma.
Aquesta és la meva opinió. També és la meva opinió: realment no tinc cap argument amb la idea que haureu d’aconseguir que el modelat de dades sigui correcte fins a un cert nivell de detall abans de passar. El que m'agradaria que proveu de fer perquè no tenia un sentit complet, és simplement descriure un d'aquests projectes quant a la seva mida, quant a com va fluir, quant a qui, ja ho sabeu, on es van solucionar els problemes, es van resoldre? Perquè crec que aquesta diapositiva és el cor més important i, si podríeu aprofundir una mica més, estaria molt agraïda.
Ron Huizenga: Segur, i faré servir un parell de projectes. El que, de forma, es va despenjar dels carrils que es tornaven a fer, implicant realment les persones adequades i fent el modelatge de dades i tot era realment una manera d’assegurar-se que el disseny s’entenia millor i, òbviament, teníem un millor disseny d’implementació. en el camí tot modelant-lo. Ja que quan el modeleu, ja ho sabeu, podeu generar el vostre DDL i tot allò que es faci enrere i fora de l’eina en lloc d’haver d’enganxar la creació d’aquest tipus com la gent normalment podria fer accedint directament a un entorn de bases de dades. I les coses típiques que passaran amb els desenvolupadors és que hi entraran i diran, d’acord, que necessito aquestes taules. Diguem que fem entrades de comandes. De manera que podrien crear l’encapçalament de la comanda i les taules de detall de l’ordre i aquest tipus de coses. Però solen oblidar o descuidar-se per assegurar-se que les restriccions hi són per representar les relacions clau exteriors. És possible que no tinguin les claus correctes. També es pot sospitar que les convencions de nomenament. No sé quantes vegades he entrat en un entorn, per exemple, on veieu un conjunt de taules diferents amb noms diferents, però els noms de columna d’aquestes taules són com ID, Nom o qualsevol cosa, de manera que Realment he perdut el joc sense la taula de què es tracta exactament.
Així, normalment, quan realitzem un model de dades, ens assegurem que també apliquem convencions de denominació adequades a tots els artefactes que també es generen al DDL. Però, per ser més específic sobre la naturalesa dels projectes, parlo, en general, d’iniciatives bastant grans. Un d’ells va ser un projecte de transformació empresarial de 150 milions de dòlars on vam substituir més d’una dotzena de sistemes heretats. Teníem cinc equips àgils diferents en marxa simultàniament. Tenia un equip complet d’arquitectura de dades, de manera que tenia modeladors de dades del meu equip incrustats a tots els altres equips de l’àrea d’aplicació i estàvem treballant amb una combinació d’experts empresarials interns que coneixien el tema, que feien el tema. històries d’usuari per als propis requisits. Teníem analistes empresarials en cadascun d’aquests equips que realment estaven modelant el procés empresarial, amb els esquemes d’activitats o els esquemes de processos de negoci, ajudant a detallar les històries d’usuaris més amb els usuaris abans de consumir-los també la resta de l’equip.
I, per descomptat, els desenvolupadors que estaven construint el codi de l'aplicació a sobre. I també estàvem treballant, crec que van ser quatre proveïdors d’integració de sistemes diferents que estaven construint diferents parts de l’aplicació on un equip estava construint els serveis de dades, l’altre construïa una lògica d’aplicació en una àrea, una altra que tenia experiència. en una altra àrea comercial es construïa la lògica d'aplicació en aquesta àrea. Així doncs, vam comptar amb tota una col·laboració de persones que estaven treballant en aquest projecte. En concret, vam tenir 150 persones a la costa de l'equip i altres 150 recursos a la costa de l'equip que van col·laborar durant dues setmanes per evitar aquest tema. I per fer-ho, assegureu-vos que esteu disparant a tots els cilindres, i tothom està ben sincronitzat pel que fa als seus lliuraments i teníeu aquests restabliments freqüents per assegurar-nos que estiguéssim completant els lliuraments de tots els artefactes necessaris. al final de cada s.
Robin Bloor: Doncs és impressionant. I només per obtenir una mica més de detall: heu acabat amb un mapa complet de MDM de tota l'àrea de dades al final d'aquest projecte?
Ron Huizenga: Teníem un model complet de dades desglossat amb la descomposició entre totes les diferents àrees de negoci. El diccionari de dades en termes de definicions completes va quedar una mica curt. Teníem la majoria de les taules definides; teníem la majoria de les columnes definides sobre què volien dir exactament. Hi havia algunes que no hi eren i, interessantment, moltes eren dades que provenien dels sistemes antics en què, després del final del propi abast del projecte, encara es documentava com un conjunt de publicacions artefactes, per tant, fora del propi projecte, perquè era una cosa que necessitava mantenir el suport de l'organització. Així, al mateix temps, l'organització va tenir un punt de vista molt més gran de la importància de la governança de dades perquè vam veure moltes mancances en els sistemes heretats i en les fonts de dades heretades que estàvem intentant consumir perquè no estaven documentades. En molts casos només teníem bases de dades que vam haver de revertir l’enginyer i intentar esbrinar què hi havia i per a què servia la informació.
Robin Bloor: No m'estranya aquest aspecte concret. La governança de dades és, doncs, una preocupació molt moderna i crec que, realment, hi ha molta feina que, diguem-ne, s’hauria d’haver realitzat històricament en el govern de les dades. Mai va ser perquè podríeu, una mica, sortir amb no fer-ho. Però, a mesura que el recurs de dades acaba creixent i creixent, al final no podries.
De totes maneres, passaré a Dez perquè crec que he tingut el meu temps assignat. Dez?
Dez Blanchfield: Sí gràcies. Durant tot aquest aspecte, estic veient i pensant a mi mateix que estem parlant de veure àgilment usat en ira de moltes maneres. Tot i que això té connotacions negatives; Vaig voler dir-ho de manera positiva. Potser potser ens donen un escenari, vull dir, hi ha dos llocs on puc veure que aquest és un conjunt perfecte: es tracta de projectes nous que només s’han de fer des del primer dia, però crec que sempre, segons la meva experiència, sol ser el cas que quan els projectes siguin prou grans perquè això sigui necessari de moltes maneres, hi ha un repte interessant entre enganxar els dos mons, oi? Pot donar-nos una mica de coneixement sobre algunes històries d’èxit que heu vist on heu entrat en una organització, està clar que tenen un petit xoc entre els dos mons i que heu pogut posar amb èxit això és el seu lloc i ajuntar grans projectes on podrien haver estat al capdavant? Sé que és una pregunta molt àmplia, però només em pregunto si hi ha algun cas concret que puguis, per exemple, apuntar a on ho has dit, ja ho saps, ho posem tot i ha reunit tot l’equip de desenvolupament. l’equip de dades i, en algun cas, hem tractat alguna cosa que d’una altra manera podria haver enfonsat el vaixell?
Ron Huizenga: És clar, i de fet, el que va passar a ser un projecte de canalització va ser el que vaig fer al·lusió on vaig mostrar aquest gràfic amb els defectes abans i després de la modelització de dades. Molt sovint, i hi ha nocions preconcebudes, sobretot si les coses es donen a conèixer allà on es fa des d’una perspectiva purament de desenvolupament, només són els desenvolupadors que participen en aquests àgils projectes per lliurar les aplicacions. El que hi va passar, per descomptat, és que es van baixar dels carrils i els seus artefactes de dades en particular, o els lliuraments de dades que estaven produint, van quedar fora de la marca en termes de qualitat i van abordar realment les coses en general. I hi ha sovint aquesta idea errònia que els modelistes de dades retarden els projectes i ho faran si el modelador de dades no té l'actitud adequada. Tal com dic, heu de perdre, de vegades, hi ha modelistes de dades que tenen aquesta tradicional actitud de "gatekeeper" on "Estem aquí per controlar el que semblen les estructures de dades" i aquesta mentalitat ha de desaparèixer. Qualsevol que estigui involucrat en un desenvolupament àgil, i en especial els modeladors de dades, ha d’assumir un rol de facilitador per ajudar els equips a avançar realment. I la millor manera d’il·lustrar és mostrar molt ràpidament als equips com de productius poden ser, modelant primer els canvis. I de nou, per això he parlat de la col·laboració.
Hi ha algunes coses que podem modelar en primer lloc i generar el DDL per impulsar als desenvolupadors. També volem assegurar-nos que no se sentin restringits. Per tant, si hi ha coses en què treballen, deixeu-les treballar als seus safareigs de desenvolupament, perquè és allà on els desenvolupadors treballen en els seus propis ordinadors de sobretaula o en altres bases de dades per fer alguns canvis en què estan provant coses. Col·laboreu amb ells i digueu: “D’acord, treballa amb això”. La introduirem a l’eina, la resoldrem i la tirarem endavant i us donarem els scripts que podeu implementar per actualitzar la vostra les bases de dades per actualitzar-les a allò que serà la visió real de la producció real sancionada a mesura que continuem avançant. I es pot convertir de forma ràpida. Vaig trobar que els meus dies es van omplir on només anava i tornava a iterar-me amb diferents equips de desenvolupament, mirant canvis, comparant, generant scripts, fent-los sortir i vaig poder mantenir-me amb quatre equips de desenvolupament bastant fàcilment una vegada que va aconseguir un impuls.
Dez Blanchfield: Una de les coses que em vénen al cap és que, ja sabeu, moltes de les converses que tinc diàriament versen sobre aquest tren de mercaderies que ens arriba, un tipus de màquina a màquina i IoT. I si pensem que tenim moltes dades sobre els nostres entorns actuals a l'empresa, ja ho sabeu, si deixem els unicorns a part per un moment en què sabem que els googles i els s i els ubers tenen petabytes de dades, però en una empresa tradicional, parlem encara de centenars de terabytes i moltes dades. Però, al meu parer, aquest tren de mercaderies arriba a les organitzacions, i el doctor Robin Bloor hi feia al·lusió anteriorment al IoT. Ja sabeu, tenim molt trànsit web, tenim trànsit social, ara tenim mobilitat i dispositius mòbils, el núvol ha explotat, ha sortit, però ara tenim infraestructures intel·ligents, ciutats intel·ligents i tot aquest món de dades acaba d'explotar.
Per a una organització quotidiana, una organització de mitjana a gran, que s’asseu allà i veu que aquest món del dolor els arriba i no tenen en compte un pla immediat, quines són algunes de les adquisicions, en només un parell de frases. Per a ells, quan i on han de començar a pensar de manera conversa sobre com posar en pràctica algunes d’aquestes metodologies. Quin temps necessiten per començar a planificar gairebé asseure’s i prestar atenció i dir que és el moment adequat per posar algunes eines al seu lloc i formar l’equip i formar una conversa de vocabulari al voltant d’aquest repte? Quant tard a la història és massa tard o quan és massa aviat? Com es veu això per a algunes de les organitzacions que veieu?
Ron Huizenga: Diria per a la majoria d’organitzacions que si no ho han fet ja i han adaptat el modelatge de dades i l’arquitectura de dades amb eines potents com aquesta, el temps que necessiten per fer-ho és ahir. Perquè és interessant que, encara avui, quan es fixen les dades de les organitzacions, tinguem tantes dades a les nostres organitzacions i, en general, en base a algunes enquestes que hem vist, estem utilitzant menys del cinc per cent d’aquestes dades de manera efectiva quan ens fixem en organitzacions. I amb IoT o fins i tot NoSQL, les dades grans, encara que no sigui només IoT, sinó només grans dades en general, on ara comencem a consumir encara més informació que prové de fora de les nostres organitzacions, el repte és cada cop més gran. tot el temps. I l’única manera que tenim la possibilitat d’afrontar-ho és ajudar-nos a comprendre de què es tracta.
Per tant, el cas d’ús és una mica diferent. El que ens trobem fent és quan mirem aquestes dades, la captem, hem de revertir les solucions, veure què hi ha, ja sigui als nostres llacs de dades o fins i tot a les nostres bases de dades internes, sintetitzar què Dades, aplicar-li significats i definicions, de manera que puguem comprendre quines són les dades. Perquè fins que no entenguem què és, no podem assegurar-nos que l’utilitzem correctament o adequadament. Per tant, és necessari que ens ocupem de com es tracten aquestes dades.I l’altra part d’això, no ho feu perquè podeu, en termes de consumir totes aquestes dades externes, assegurar-vos que teniu un cas d’ús que admeti consumir aquestes dades externes. Centreu-vos en les coses que necessiteu més que intentar treure i utilitzar les coses que podríeu necessitar més endavant. Centreu-vos en les coses importants primer i, a mesura que us aprofiteu, podreu consumir i intentar comprendre la resta d'informació de fora.
Un exemple perfecte és que sé que parlem de IoT i de sensors, però el mateix tipus de problemes hi ha hagut en moltes organitzacions durant molts anys, fins i tot abans de IoT. Qualsevol que tingui un sistema de control de producció, ja siguin una empresa de canonades, la fabricació, qualsevol empresa basada en processos que tinguin coses en les quals fa molta automatització amb controls i utilitzin fluxos de dades i coses així. aquestes dades de foc que estan tractant de beure, per descobrir, quins són els esdeveniments que han tingut lloc en el meu equip de producció: per què passa i quan? I entre aquest gran flux de dades només hi ha informació específica o etiquetes que els interessa que necessiten definir, sintetitzar, modelar i comprendre. I poden ignorar la resta fins que arribi el moment de comprendre-ho realment, i aleshores poden ampliar el seu àmbit d’objectiu per aconseguir-ho cada cop més a l’abast, si té sentit.
Dez Blanchfield: Ho fa, efectivament. Hi ha una pregunta que em plantejaré que prové d’un senyor que es deia Eric i ho hem conversat en privat. Acabo de demanar el seu permís, que li ha donat, per demanar-lo. Com que s’aconsegueix molt bé, només s’acaba de fer, perquè anem una mica amb el pas del temps i li retornaré a Eric. Però la pregunta d’un altre Eric era: és raonable suposar que els propietaris d’una startup estiguin familiaritzats i comprenguin els reptes únics que comporta la modelització de la terminologia, o bé, o s’hauria de lliurar a algú més per a la seva interpretació? Per tant, en altres paraules, una startup ha de ser capaç i preparada i disposada, capaç de centrar-se en això i aportar-ho? O és que haurien de comprar i portar probablement experts?
Ron Huizenga: Suposo que la resposta curta és que realment depèn. Si es tracta d’una startup que no té algú a la casa que sigui un arquitecte o modelador de dades que entengui realment la base de dades, la manera més ràpida d’iniciar-lo és portar a algú amb un fons de consultoria molt ben versat en aquest espai i que pugui obtenir ells anant. Perquè el que trobareu, i de fet, ho vaig fer amb molts compromisos que vaig fer abans de passar a la part fosca en la gestió de productes, és que jo passaria a les organitzacions com a consultor, dirigiria els seus equips d’arquitectura de dades, de manera que poguessin, enfocant-se, enfocar-se i formar la seva gent sobre com fer aquest tipus de coses per tal de sostenir-la i portar a terme la missió. I després passaria al meu proper compromís, si això té sentit. Hi ha molta gent que hi fa això, que té una experiència de dades molt bona que els pot portar a terme.
Dez Blanchfield: És un excel·lent punt per emportar-ho i estic totalment d’acord amb això i estic segur que també ho seria el doctor Robin Bloor. En particular en una startup, us heu concentrat a ser una PIME sobre el valor particular de la proposta que busqueu formar com a part del vostre propi negoci d’inici i, probablement, no haureu de ser un expert en tot, per tant, un gran consell. Però moltes gràcies, una fantàstica presentació. Respostes i preguntes realment excel·lents. Eric, us tornaré a fer perquè tinc clar que hem passat deu minuts amb el pas del temps i sé que us agrada apropar-vos a les nostres finestres horàries.
Eric Kavanagh: Està bé. Tenim almenys un parell de bones preguntes. Deixa'm llançar-ne una. Crec que heu respost a algunes d’altres. Però, una observació i una pregunta molt interessants d’un assistent que escriu, de vegades els projectes àgils tenen que el modelador de dades no tingui tota la imatge a llarg termini i, per tant, acabin dissenyant alguna cosa en un mateix i després hagin de redissenyar en tres o quatre. No sembla que això sigui contraproduent? Com podeu evitar aquest tipus de coses?
Ron Huizenga: Es tracta només de la naturalesa àgil que no anirà a assolir tot absolutament bé en un determinat dia. I això, en realitat, és un esperit àgil: treballa amb ell - faràs prototips on treballes el codi en un determinat article i hi faràs perfeccionaments. I una part d’aquest procés és que estàs lliurant coses que l’usuari final ho veu i diu: “Sí, està a prop, però realment necessito que també faci una mica més.” De manera que no només afecta el disseny funcional. del propi codi, però amb molta freqüència hem de modificar o afegir més estructura de dades a sota d'aquestes coses per oferir el que l'usuari vol. I tot és un joc just, i és per això que realment voleu utilitzar les eines d’alta potència, ja que podeu modelar molt ràpidament i fer aquest canvi en una eina de modelatge i, a continuació, generar el DDL per a la base de dades amb la qual podran treballar els desenvolupadors. canviar encara més ràpidament. Els estalviareu d’haver de fer aquesta codificació manual de les estructures de dades i us permetreu concentrar-vos en la lògica de programació o d’aplicació a la qual més coneixeu.
Eric Kavanagh: Això té sentit. Vam tenir un parell de persones només fent preguntes específiques sobre com es pot vincular tot això amb l'eina. Sé que heu dedicat un temps a examinar exemples i heu mostrat algunes captures de pantalla sobre com realment esteu publicant algunes d'aquestes coses. Pel que fa a tot aquest procés, amb quina freqüència veus que el joc a les organitzacions enfront de quantes vegades veus processos més tradicionals en què les coses només s’aconsegueixen, s’amplien i es triguen més temps? Quina importància té l’enfocament de l’estil s des de la vostra perspectiva?
Ron Huizenga: Crec que ho veiem cada cop més. Ja ho sé, diria, probablement en els darrers 15 anys, en particular, he vist una adopció de persones que reconeixen que realment han de tenir un lliurament més ràpid. Així, he vist que cada vegada són més les organitzacions que salten a la via àgil. No necessàriament del tot; poden començar amb un parell de projectes pilot per demostrar que funciona, però n’hi ha alguns que són molt tradicionals i s’ajusten al mètode de la cascada. Ara bé, la bona notícia és, per descomptat, que les eines funcionen molt bé en aquestes organitzacions també per a aquest tipus de metodologies, però tenim l’adaptabilitat a l’eina perquè els que fan el salt a bord tinguin les eines a la caixa d’eines a els seus dits. Coses com la comparació i la combinació, com ara les capacitats d’enginyeria inversa, de manera que puguin veure quines són les fonts de dades existents, de manera que poden comparar i generar els scripts DDL incrementals molt ràpidament. I quan comencen a abraçar-ho i veuen que poden tenir la productivitat, la seva inclinació a abraçar-se àgilment augmenta encara més.
Eric Kavanagh: Bé, això és gran cosa, persones. Acabo de publicar un enllaç a les diapositives que hi ha a la finestra de xat, així que comproveu-ho; és una mica per a tu. Disposem de totes aquestes transmissions web per a la seva posterior visualització. No dubteu a compartir-los amb els vostres amics i companys. I Ron, moltes gràcies pel vostre temps avui, sempre us ve de gust participar al programa: un autèntic expert en la matèria i és evident que coneixeu les vostres coses. Així doncs, gràcies a vosaltres i gràcies a IDERA i, per descomptat, a Dez i al nostre propi Robin Bloor.
I amb això us farem acomiadar, amics. Gràcies de nou pel vostre temps i atenció. Agraïm que us encaixeu durant 75 minuts, això és un bon signe. Bons nois, en parlarem la propera vegada. Adeu.