Tekijä Techopedia Staff, 16. marraskuuta 2016
Takeaway: Isäntä Eric Kavanagh keskustelee tietomallinnuksen tärkeydestä ketterässä kehityksessä Robin Bloorin, Dez Blanchfieldin ja IDERAn Ron Huizengan kanssa.
Et ole tällä hetkellä kirjautunut sisään. Kirjaudu sisään tai kirjaudu sisään nähdäksesi videon.
Eric Kavanagh: Okei, hyvät naiset ja herrat. Tervetuloa jälleen kerran. Se on keskiviikko klo 4:00 EST. Tämä tarkoittaa, että on aika Hot Technologiesille. Todellakin. Nimeni on Eric Kavanagh, minä olen sinun isäntäsi.
Nykypäivän aiheessa se on vanha, mutta hyvää. Se paranee joka päivä, koska se muotoilee tiedonhallintamaailmaamme, ”Tietojen mallintaminen ketterässä ympäristössä”. Siellä on dio sinun todellisesta tiedosta, lyö minut Twitteriin @eric_kavanagh. Meidän pitäisi todella laittaa se tuolle dialle. Minun on päästävä siihen.
Joten vuosi kuuma. Tietojen mallinnus on ollut olemassa ikuisesti. Se on ollut tietohallintoyrityksen sydän ja sielu, suunnitellessaan datamalleja, yrittänyt ymmärtää liiketoimintamalleja ja sovittaa ne tietomalleihisi. Se on todella mitä yrität tehdä, eikö niin?
Tietomalli edustaa yritystä perustavanlaatuisella tavalla, joten kuinka nämä uudet tietolähteet muuttavat peliä? Aiomme tietää siitä. Aiomme selvittää, kuinka voit pysyä asioiden päällä ketterästi. Ja tietenkin, se on vuoden sana.
Robin Bloor kanssamme, pääanalyytikomme, Dez Blanchfield soittaen Sydneystä, Australiasta ja Ron Huizenga, vanhempi tuotepäällikkö IDERA: sta - pitkäaikainen ystäväni, erinomainen puhuja tällä alueella, tietää hänen asiat, joten älä ole ujo, kysy hänelle kovat kysymykset, ihmiset, kovat. Aion tehdä Robinista juontajan ja viedä sen pois.
Dr. Robin Bloor: Okei. No kiitos siitä, Eric. Minun on sanottava mallinnuksesta, että mielestäni olin tosiasiallisesti tietotekniikan maailmassa ennen sen olemassaoloa siinä mielessä, että muistan vakuutusyhtiössä, jossa työskentelin, että meillä oli kaveri tulossa sisään ja antoi meille kaikenlaista työpaja tietojen mallinnuksesta. Joten katsomme noin 30 vuotta, onko se 30 vuotta? Ehkä jopa pidempään kuin ehkä 35 vuotta sitten. Pitkä, pitkä aikainen mallinnus on itse asiassa ollut osa teollisuutta, ja sillä ei tietenkään ole mitään tekemistä naisten kanssa kävelykaduilla.
Asia, jonka halusin sanoa, koska mitä me yleensä teemme, olen minä ja Dez puhumme eri asioista ja ajattelin vain, että annan yleisen yleiskuvan mallinnukselle, mutta tässä on todellisuus, joka on nyt ilmeinen.
Meillä on, tiedätkö, iso data todellisuus, meillä on enemmän dataa, enemmän tietolähteitä, meillä on tietovirtoja, jotka ovat syöttäneet yhtälön viimeisen kolmen tai neljän vuoden aikana ja alkavat saada suuremman osan siitä, ja dataa on ymmärrettävä enemmän ja muutosnopeus on lisääntynyt, koska dataa lisätään enemmän ja käytetään myös enemmän tietorakenteita.
Se on vaikea maailma. Tässä on kuva siitä, joka on tosiasiassa jotain, jonka piirsimme noin kolme vuotta sitten, mutta pohjimmiltaan, kun sisällytät streamin miksaukseen ja saat tämän idean tietojen jalostamisesta, datakeskuksesta, tietolinkistä tai muusta, huomaat, että on olemassa tietoja, jotka ovat aidosti levossa siinä mielessä, että se ei liiku paljon. Ja sitten siellä on data, streamit ja kaikki kaupalliset sovellukset, samoin kuin nykyään kaikki tapahtumat, tapahtumien datavirrat, jotka tapahtuvat sovelluksissa ja joudutaan välttämättä tekemään, ja nykyään lambda-arkkitehtuurien kanssa, joista kaikki puhuvat, ovat aidosti jolla on vaikutus vain koko tietokenttään.
Ja nykyään ajattelee tietokerroksen olemassaoloa. Tietokerros on olemassa eräänlaisella virtuaalisella tavalla siinä mielessä, että hyvä kappale siitä voisi olla pilvessä ja se voidaan levittää tietokeskuksiin, se voi olla työasemilla. Tietokerros on jossain määrin kaikkialla, ja siinä mielessä kaikkialla on prosesseja, jotka yrittävät tavalla tai toisella käsitellä tietoja ja siirtää tietoja. Mutta myös tietää, mikä se on, kun siirrät sitä, on iso juttu.
Jos tarkastelemme tietojen mallintaa yleisimmässä mielessä, sinulla on tällaisen pinon alaosassa tiedostoja ja tietokantoja. Sinulla on tietoelementtejä, joissa on avaimet, elementimääritelmät, aliakset, synonyymit, tietyt fyysiset muodot ja sitten meillä on tämä metatietotaso.
Mielenkiintoinen asia metatietojen suhteen on, että metatiedot ovat täysin sitä, kuinka data saa merkityksen. Jos sinulla ei tosiasiassa ole metatietoja, niin parhaimmillaan voit arvata datan merkityksen, mutta sinulla on todella paljon vaikeuksia. Metatietojen on oltava siellä, mutta merkityksellä on rakenne. En halua mennä merkitysfilosofiaan, mutta jopa tapaan, jolla käsittelemme tietoa, on ihmisen ajatuksessa ja kielessä paljon hienostuneisuutta, mikä ei helposti ilmaise itseään tiedoissa. Mutta jopa niiden tietojen suhteen, joita tosiasiallisesti käsittelemme maailmassa, metatiedoilla on merkitys ja metatietojen rakenne - yksi tieto suhteessa toiseen ja mitä tämä tarkoittaa, kun ne kootaan ja mitä tämä tarkoittaa, kun ne " liitetään uudelleen muihin tietoihin, vaatii mallintamaan sitä. Ei riitä, että vain tallennat metatietotunnisteita asioihin, sinun on itsekin tallennettava merkitys rakenteittain ja rakenteiden välinen suhde.
Sitten meillä on ylimmässä kerroksessa liiketoimintamääritelmät, joka on yleensä kerros, joka yrittää siirtää merkitystä metatietojen välillä, mikä on tietomäärittelyn muoto, joka sopii tapaan, jolla tiedot on järjestetty tietokoneessa, ja inhimilliseen tarkoitukseen. Joten sinulla on kyseisessä kerroksessa olemassa olevia liiketoimintatermejä, määritelmiä, suhteita ja kokonaisuustasoja. Ja jos meillä on epäjohdonmukaisuus näiden kerrosten välillä, niin meillä on oltava datan mallintaminen. Se ei ole oikeastaan valinnainen. Mitä enemmän voit tosiasiallisesti tehdä sen automatisoinnissa, sitä parempi. Mutta koska se liittyy merkitykseen, on todella vaikea vaihtaa. Se on tarpeeksi helppo saada metadata tietueen sisälle ja pystyä saamaan se merkityssarjasta, mutta se ei kerro sinulle tietueiden rakennetta tai mitä tietueet tarkoittavat tai tietueen kontekstia.
Joten tästä datan mallinnus on mielestäni kyse. Huomautettakoon: mitä monimutkaisemmaksi data-maailmankaikkeus tulee, sitä enemmän sinun täytyy mallintaa sitä. Toisin sanoen, se on vähän kuin se, että emme lisää vain maailmaan asioita, jotka vastaisivat tietueita, vaan lisäämme tosiasiallisesti enemmän merkitystä maailmalle kaappaamalla tietoja yhä useammista asioista. Se on tulossa yhä monimutkaisemmaksi tunteeksi, joka meidän on ymmärrettävä.
Teoriassa on olemassa tietouniversumi ja tarvitsemme kuvan siitä. Käytännössä varsinaiset metatiedot ovat osa tietokaikkeutta. Joten, se ei ole yksinkertainen tilanne. Alku mallinnus on ylhäältä alas ja alhaalta ylös. Sinun on rakennettava molempiin suuntiin, ja syy siihen, että tiedolla on merkitystä tietokoneelle ja prosessille, joiden on käsiteltävä sitä, mutta sillä on merkitys itsessään. Tarvitset siis alhaalta ylöspäin suuntautuvaa merkitystä, joka tyydyttää ohjelmiston, joka tarvitsee tiedonsaannin, ja tarvitset ylhäältä alas merkityksen, jotta ihmiset ymmärtävät sen. Metatietomallien rakentaminen ei ole eikä voi koskaan olla projekti; se on jatkuvaa toimintaa - sen tulisi olla jatkuva toiminta jokaisessa ympäristössä, jossa he ovat. Onneksi on olemassa monia ympäristöjä, joissa näin ei oikeastaan ole ja asiat spin hallitsematta vastaavasti.
Edelleen mallinnus kasvaa merkityksen kanssa tekniikan siirtyessä eteenpäin. Se on minun mielipiteeni. Mutta jos tarkastellaan IoT: tä, voimme ymmärtää mobiililaitteita enemmän kuin ennen, vaikka se on ottanut käyttöön uusia ulottuvuuksia: sijainnin ulottuvuuden mobiililaitteilla. Kun olet päässyt Internetiin, tarkastelemme poikkeuksellisia tietoongelmia, joita meidän ei koskaan ole ennen ollut tehtävä, ja meidän on tavalla tai toisella ymmärrettävä asianmukaisesti, mitä meillä on, kuinka voimme koota sen, mitä voimme tehdä merkityksen saamiseksi aggregoinnista, ja tietysti mitä voimme tehdä sen kanssa, kun olemme käsitellyt sen.
Minusta se on sanonut tarpeeksi. Aion siirtää Dez Blanchfieldille, joka sanoo jotain muuta kokonaan.
Dez Blanchfield: Kiitos. Aina kova teko seurata, mutta tästä aiheesta sovimme ja puhuimme siitä lyhyesti esittelynäyttelyssä, ja jos valitsit aikaisin, olet todennäköisesti saanut kokonaisen joukon upeita helmiä. Yksi takeavesista, enkä halua varastaa tämän nimenomaista ukkosta, mutta yksi esittelynäyttelijältämme liittyvä takea, jonka haluan jakaa, jos et saanut sitä kiinni, oli vain aiheen ympärillä tietojen matkaa, ja se sai minut todella kirjoittamaan sen ajatellen matkaa, jonka tiedot kuluttavat eri tilanteessa sukupolvien elinaikana - vuosi, kuukaudet, viikko, päivä, tunti, minuutti, sekunti - ja tietojen ympärillä oleva konteksti ovat sijoitettu tuossa yhteydessä. Joko olen kehittäjä, joka käyttää koodia, vai olenko tietospesialisti, ajattelen rakennetta ja muotoa ja metatietoja jokaisen elementin ympärillä tai tapaa, jolla järjestelmät ja yritys ovat vuorovaikutuksessa sen kanssa.
Se on mielenkiintoinen pieni takea vain huomauttamiseksi, mutta joka tapauksessa, sallikaa minun sukeltua sisään. Erityisesti datasuunnittelu on lause, jota puhun kaiken tiedon tiedosta ja erityisesti sovellusten tai tietokantainfrastruktuurin kehittämisestä. Uskon, että tietosuunnittelu on termi, joka vain kaappaa kaiken mieleni mielestäni. Nykyään, kun puhumme datasuunnittelusta, puhumme nykyaikaisesta ketterästä tietosuunnittelusta, ja mielestäni ei ollut niin kauan sitten, että kehittäjät ja tietotekniikan asiantuntijat työskentelivät yksin; ne olivat omissa siiloissaan ja suunnittelupalvelut siirtyivät siilosta toiseen. Mutta olen erittäin sitä mieltä, että nykyään ei ole vain se, että tilanne on muuttunut, vaan sen on muututtava; se on eräänlainen välttämättömyys, ja se on se sovellus - kehittäjät ja kaikki muutokset, jotka liittyvät tietojen käsittelyyn, suunnittelijat, jotka tekevät asiaankuuluvat suunnitteluelementit kaavioista ja kentistä ja tietueista sekä sijainti- ja tietokantajärjestelmät ja infrastruktuurit, mallinnus ja koko hallinta haaste sen ympärille. Se on nyt joukkueurheilua, ja tästä johtuen kuvani joukosta ihmisiä, jotka hyppivät lentokoneesta ja toimivat joukkueena pelatakseen tätä visuaalisesti mielenkiintoista kuvaa taivaan läpi putoavista ihmisistä.
Kolmanneksi, mitä tapahtui tämän saavuttamiseksi? No, siellä on artikkeli vuonna 1986, jonka ovat kirjoittaneet pari herrasmiestä, joiden nimien kanssa yritin epätoivoisesti tehdä oikeudenmukaisuutta. Hirotaka Takeuchi ja Ikujiro Nonaka, mielestäni se lausutaan, julkaisivat artikkelin, jonka otsikkona oli ”Siirrä Scrumin alakenttää”. He esittelivät artikkelin. tämä ajatus menetelmästä rugbypelin voittamiseksi, joka menee tästä harjatoiminnasta, jossa kaikki liikkuvat ympäriinsä yhdessä paikassa ja kaksi joukkuetta lukitsee päänsä jotain nimeltään scrum yrittääkseen hallita palloa ja pelata sitä kentällä päästäksesi koeviivalle ja kosketa maata pallon kanssa ja saat pisteen, jota kutsutaan kolmiksi, ja toistat tämän prosessin ja saat enemmän pisteitä joukkueelle.
Tämä artikkeli julkaistiin vuonna 1986 Harvard Business Review -sivustolla, ja omituisen kiinnostuksen perusteella se sai todella paljon huomiota. Se sai paljon huomiota, koska se esitteli uskomattomia uusia käsitteitä ja tässä on kuvakaappaus sen edestä. Joten he ottivat tämän käsikirjoituksen pois pelin rugbystä ja veivät sen liiketoimintaan ja etenkin suunnittelun ja projektin toimituksen, erityisesti projektin toimittamisen, peliin.
Se, mitä scrum teki, antoi meille uuden metodologian verrattuna PRINCE2: n tai PMBOK: n kaltaisiin menetelmiin, joita olemme aikaisemmin käyttäneet ns. Vesiputousmenetelmään, tiedät, tee tämä ja tämä ja tämä asia ja seuraa niitä järjestyksessä ja yhdistä kaikki pisteet ympärillä, mikä riippuu siitä, mikä sinulla oli, tai älä tee osaa toinen, ennen kuin olet tehnyt osan ensimmäisestä, koska se riippui ensimmäisestä. Se antoi meille uuden menetelmän olla hieman ketterämpi, josta termi tulee, siitä, kuinka toimitamme asioita, ja erityisesti suunnittelun ja kehityksen ruohonjuuritason projektitoimitusten ympärille.
Jotkut avainvuokralaisista - vain niin pääsen tähän - ovat saastumisen keskeisten vuokralaisten ympärillä. Se esitteli epävakauden rakentamisen ajatuksen, että jos ajattelet kaaoksen pelkoa, maailma on kaaoksen tilassa, mutta muodostui planeetta, joka on mielenkiintoinen, joten rakennuksen epävakaus, kyky palautua vähän ympäri ja tosiasiallisesti saavat asiat toimimaan, itseorganisoituvat projektiryhmät, päällekkäisyydet suosimalla erittäin vastuullisen kehityksen, erityyppisen oppimisen ja hallinnan kautta projektin toteutuksen matkalla, oppimisen organisaationsiirron kautta. Joten miten otamme tietoa yhdestä liiketoiminnan osasta ja siirrämme sen toiselle ihmisiltä, joilla on idea, mutta jotka eivät kehitä koodia tai eivät kehitä tietokantoja ja infrastruktuureja, mutta tietoja näille ihmisille? Ja erityisesti aikataulussa olevat tulokset. Toisin sanoen, tehdään tämä tietyn ajanjakson ajan, joko päivässä, kuten 24 tunnissa, tai viikon tai parin viikon ajan, katsotaan mitä voimme tehdä, sitten askel taaksepäin ja katsotaan sitä.
Joten, jos armahdat punin, tämä on todella uusi peli projektin toimittamisessa ja siihen liittyvät kolme keskeistä komponenttia, jotka ovat järkeviä, kun pääsemme hiukan eteenpäin - siellä on tuote: kaikilla näillä ihmisillä on idea ja heillä on tarve saada jotain aikaan ja tarina, joka ympäröi heitä. Kehittäjät, jotka toimivat ketterässä mallissaan saada tarinoitaan ja päivittäisillä standupeilla, käyttävät scrum-menetelmää keskustellaksesi siitä ja ymmärtääksesi mitä heidän on tehtävä, ja sitten vain mennä ja jatkaa ja tehdä se. Sitten ihmiset, olemme kuulleet scrum-päälliköistä, jotka valvovat koko tätä asiaa ja ymmärtävät metodologian riittävän hyvin ajaakseen sitä. Olemme kaikki nähneet nämä kuvat, jotka sain täällä oikealla puolella seiniä ja tauluja täynnä Post-It-muistiinpanoja ja niitä palveli Kanbanin seinäinä. Jos et tiedä kuka Kanban on, kutsun sinut Googleen, kuka herra Kanban oli ja miksi se oli muutos tapaan, jolla siirrämme asioita sivulta toiselle seinässä kirjaimellisesti, mutta projektissa.
Yhdellä silmäyksellä scrum-työnkulku tekee tämän: se ottaa luettelon asioista, jotka organisaatio haluaa tehdä, suorittaa ne läpi joukon kutsumme sprintejä, jotka on hajotettu 24 tunnin jaksoiksi, kuukauden mittaisiksi jaksoiksi, ja me hanki tämä inkrementaalinen ulostulosarja. Se on merkittävä muutos tapaan, jolla projektit toimitetaan, toimitettiin siihen vaiheeseen saakka, koska osa siitä virtaa kuten Yhdysvaltain armeija, jolla oli suuri osa kehittää jotain nimeltä PMBOK, kuten ajatus, että älä vie säiliötä kentälle kunnes laitat luoteja juttuun, koska jos kentän säiliössä ei ole luoteja, se on hyödytön. Joten siksi osa ensimmäinen laitetaan luodit säiliöön, osa toinen laitetaan säiliö kenttään. Valitettavasti kehitysmaailman kehittäjien kanssa tapahtunut tapahtuma sai jotenkin käsityksen tästä ketterästä menetelmästä ja juoksi sen kanssa, jos armahdat punin, sprintissä.
Aina, mitä tapahtui, kun ajattelemme ketterää, ajattelemme yleensä kehittäjiä emmekä tietokantoja eikä mitään tekemistä tietokantojen maailman kanssa. Se oli valitettava tulos, koska todellisuus on, että ketterä ei rajoitu vain kehittäjiin. Itse asiassa termi ketterä liittyy mielestäni usein väärin yksinomaan ohjelmistokehittäjiin eikä tietokannan suunnittelijoihin ja arkkitehteihin. Poikkeuksellisesti samat haasteet, joita kohtaat ohjelmistojen ja sovellusten kehittämisessä, kohtaavat kaiken suunnittelun ja kehittämisen, käytön ja ylläpidon, ja siten tietoinfrastruktuurin ja erityisesti tietokantojen, suhteen. Tämän nimenomaisen valettujen näyttelijöiden joukossa on esimerkiksi tietoarkkitehtejä, muokkauslaitteita, tietokantainfrastruktuurien ylläpitäjiä, ylläpitäjiä ja varsinaisia tietokantoja koko yrityksen ja järjestelmien analyytikoiden ja arkkitehtien kautta, ihmisiä, jotka istuvat ja ajattelevat kuinka järjestelmät ja yritykset toimivat ja kuinka olemme saaneet siirtää tietoja näiden kautta.
Se on aihe, jonka esittelen säännöllisesti, koska se on jatkuvaa turhautumista, koska olen hyvin sitä mieltä, että tietosuoja-asiantuntijoiden on - ei pitäisi -, heidän on nyt oltava tiiviisti mukana kaikissa hankkeen toimittamisen osissa, todellakin, erityisesti kehittämisessä. Jotta emme voi, niin emme todellakaan anna itsellemme parhaita mahdollisuuksia hyvään tulokseen. Meidän on usein kiertävä taaksepäin ja ajateltava uudelleen näitä asioita, koska on olemassa skenaario, pääsemme rakennettavaan sovellukseen ja löydämme, että kehittäjät eivät ole aina tietoasiantuntijoita. Tietokantojen kanssa työskenteleminen vaatii hyvin erikoistuneita taitoja, etenkin datan suhteen, ja rakentaa kokemusta. Sinusta ei tule vain heti tietokanta guru tai data-asiantuntija yön yli; tämä on usein jotain, joka tulee elinikäisestä kokemuksesta ja varmasti kuten Dr. Robin Bloorin tapaan Code Today -tapahtumassa, joka kirjoitti melko rikkaasti kirjan.
Monissa tapauksissa - ja se on valitettavaa, mutta se on todellisuutta - että kolikossa on kaksi osaa, ts. Ohjelmistokehittäjillä on oma pimennys tietokanta-asiantuntijoiden kanssa ja rakennettu tietokannan suunnittelun mallintamisessa tarvitsemasi taidot, mallin kehittämisen ollessa vain perustiedot gurun suunnittelulle siitä, miten data tulee ja kuinka matkan järjestäminen tapahtuu ja millaisen sen pitäisi olla tai minkä pitäisi näyttää, tai epäilemättä se, että nautitaan ja ymmärretään, että se on saatu yleensä ohjelmistokehittäjille asetetuilla alkuperäisillä taidoilla. Ja eräät yhteiset haasteet, joita pelkäämme tässä yhteydessä, sisältävät pelkän perustietokannan luomisen, ylläpidon ja hallinnan ydintietokannan suunnittelussa, tietojen ja tietokantainfrastruktuurin dokumentoinnissa ja näiden tietoresurssien, kaavioiden uudelleenkäytössä, skeemien luominen, järjestelmän hallinto ja ylläpito sekä niiden käyttö, tiedon jakaminen siitä, miksi tämä skeemi on suunniteltu tietylle tavalla, ja siihen liittyvät vahvuudet ja heikkoudet ajan myötä aiheuttavat datan muutokset ajan myötä, datan mallinnus ja tyypit malleista, joita käytämme järjestelmiin ja niiden läpi kulkevaan tietoon. Tietokantakoodien luominen ja se jatkaa integrointia ja sitten mallinntaa tietoja heidän ympärilleen ja sitten nopeammin pääsee hallitsemaan tietoturvaa datan ympärillä. Tietojen eheys siirrämme tietoja ympärillemme säilyttäen sen eheyden, onko metatietoja riittävästi sitä, pitäisikö myynnin nähdä kaikki taulukon tietueet vai pitäisikö heidän nähdä vain osoite, etunimi ja sukunimi, joka lähettää sinulle viestejä? Ja sitten tietysti kaikkien suurin haaste on tietokantaalustojen mallintaminen, mikä on itsessään täysin erilainen keskustelu.
Olen erittäin sitä mieltä, että kaiken tämän huomioon ottaen tämän nirvaanan mahdollistamiseksi on ehdottoman tärkeää, että sekä tietosuoja-asiantuntijoilla että kehittäjillä on asianmukaiset työkalut ja että nämä työkalut kykenevät ryhmäkeskeiseen projektitoimitukseen, suunnittelu, kehittäminen ja jatkuva toiminnan ylläpito. Tiedätte esimerkiksi asioiden, kuten data-asiantuntijoiden ja ohjelmistokehittäjien välisen yhteistyön, totuuden yhden pisteen tai yhden totuuden lähteen kaiken, joka liittyy tietokantojen itse dokumentointiin, tietoihin, järjestelmiin, mistä tietueet tulevat, näiden tietueiden omistajiin. . Mielestäni tänä päivänä on ehdottoman kriittistä, saamme tämän tiedon nirvaanan kuninkaaksi, että oikeiden työkalujen on oltava paikoillaan, koska haaste on nyt liian suuri, jotta voimme tehdä sen käsin, ja jos ihmiset Kun siirrymme sisään ja ulos yhdestä organisaatiosta, meille on liian helppoa olla noudattamatta samaa prosessia tai metodologiaa, jonka yksi henkilö voi perustaa, ja jotka eivät ole hyviä eikä välttämättä siirrä näitä taitoja ja kykyjä eteenpäin.
Tätä silmällä pitäen aion siirtyä IDERAn hyvän ystävämme luo ja kuulla siitä työkalusta ja kuinka se käsittelee näitä asioita.
Ron Huizenga: Kiitos paljon ja kiitos sekä Robinille että Dezille siitä, että olet todella asettanut lavan hyvin, ja näet hiukan päällekkäisyyttä muutamassa asiossa, joista olen puhunut. Mutta he ovat todella luoneet erittäin vankan perustan joillekin käsitteille, joista aion puhua datan mallintamisen näkökulmasta. Ja monet asioista, jotka he ovat sanoneet, vastaavat omaa kokemustani, kun työskentelin konsultin kanssa, joka työskenteli tietojen mallintamisessa ja tietoarkkitehtuurissa yhdessä ryhmien kanssa - sekä vesiputous alkuaikoina että kehittyvä nykyaikaisemmiksi tuotteiksi projektiin, joissa käytimme ketterää menetelmät ratkaisujen toimittamiseksi.
Joten se, mistä puhun tänään, perustuu niihin kokemuksiin sekä näkemykseen työkaluista ja joistakin niiden työkalujen ominaisuuksista, joita me autamme meille matkan varrella. Aion käsitellä hyvin lyhyesti sitä, etten aio mennä yksityiskohtiin; meillä oli vain todella hyvä yleiskuva siitä, mikä tämä on. Aion puhua siitä suhteessa siihen, mikä on tietomalli ja mitä se meille todella tarkoittaa? Ja kuinka me annamme ketterän datamallinntajan konseptin organisaatioissamme, suhteessa seuraaviin kysymyksiin: miten saadaan mukaan mallinntajat, miten mallinntajat ja arkkitehdit osallistuvat sprinttiin, millaisia toimia heidän tulisi harjoittaa, ja tämän taustalla, mitä on muutamia tärkeistä mallinnustyökalujen ominaisuuksista, joita käytämme todella helpottamaan työn tekemistä? Sitten aion mennä vähän kietoutumiseen ja puhua vain vähän joistakin liiketoiminnan arvoista ja eduista, jotka aiheutuvat datan mallinntajan osallistumisesta tai tapa, jolla tosiasiallisesti kerron tarinan, ongelmat siitä, että tietomallinntajaa ei ole täysin mukana hankkeissa. Näytän sen kokemuksen ja vikakaavion edestä ja jälkeen -kuvasta todellisesta projektista, jonka kanssa olen ollut mukana monta vuotta sitten. Ja sitten me teemme tiivistelmän vielä muutamasta seikasta ja meillä on sen lisäksi kysymyksiä ja vastauksia.
Lyhyesti sanottuna, ER Studio on erittäin voimakas sarja, jossa on paljon erilaisia komponentteja. Data-arkkitehti, jossa data-mallinntajat ja arkkitehdit viettävät suurimman osan ajastaan tekemällä tietojen mallinnusta. On myös muita komponentteja, joista emme aio puhua tänään, kuten Business Architect, jossa teemme prosessimallintamista ja Software Architect, joillekin UML-mallinnuksista. Sitten on arkisto, jossa me kirjaudumme sisään ja jaamme malleja ja annamme tiimien tehdä yhteistyötä niiden kanssa ja julkaista ne tiimipalvelimelle, jotta useat projektiin osallistuvat sidosryhmät voivat todella nähdä esineitä, joita me uudelleen luominen datanäkökulmasta sekä muut asiat, joita teemme itse projektitoimituksessa.
Aion keskittyä tänään olemaan muutamia asioita, jotka aiomme nähdä tietoarkkitehdilta ja koska on todella tärkeää, että meillä on yhteistyössä Repository-pohjaisten näkökohtien kanssa. Varsinkin kun alamme puhua käsitteistä, kuten muutoksen hallinta, jotka ovat välttämättömiä ketterien kehitysprojektien lisäksi myös kaikenlaiselle kehitykselle.
Joten puhutaanpa hetkeksi ketterästä Data Modellerista. Kuten olemme jo aikaisemmassa esityksessä maininneet, on välttämätöntä, että meillä on tietomallinntajat ja / tai arkkitehdit täysin sitoutuneet ketteriin kehitysprosesseihin. Nyt se, mitä historiallisesti on tapahtunut, on, kyllä, olemme todella ajatelleet ketterää kehityksen näkökulmasta, ja on olemassa muutamia asioita, jotka ovat menneet eteenpäin, jotka todella ovat aiheuttaneet tämän. Osa siitä johtui vain tavasta, jolla kehitys itse kehittyi. Kun ketterä kehitys alkoi ja aloitimme tällä itseorganisoivien joukkueiden käsitteellä, jos joit Kool-Aidia vähän liian puhtaana ja olit asioiden äärimmäisellä ohjelmointipuolella, asioista, kuten itseorganisoivia tiimejä, joita monet ihmiset tulkitsi tarkoittavan, tarvitsemme vain ryhmän kehittäjiä, jotka voivat rakentaa kokonaisen ratkaisun. Tarkoittaako se koodin, tietokantojen tai sen takana olevien tietopisteiden kehittämistä, ja kaikki annettiin kehittäjille. Mutta mitä tapahtuu, menetät ihmiset erityiset kyvyt. Olen huomannut, että vahvimmat joukkueet ovat niitä, jotka koostuvat eri taustoista tulevista ihmisistä. Kuten yhdistelmä vahvoja ohjelmistokehittäjiä, tietoarkkitehteja, tietomuotoilijoita, yritysanalyytikoita ja yritystoimintaa tekeviä sidosryhmiä, jotka kaikki tekevät yhteistyötä lopputuloksen löytämiseksi.
Puhun tänään myös siitä, että aion tehdä tämän kehitysprojektin yhteydessä, jossa kehitämme sovellusta, joka tietysti myös siihen liittyvän tietokomponentin liittyy. Meidän on kuitenkin otettava askel taaksepäin ennen kuin teemme sen, koska meidän on ymmärrettävä, että siellä on hyvin vähän Greenfield-kehityshankkeita, joissa keskitymme kokonaan sellaisen tiedon luomiseen ja kuluttamiseen, joka on rajoitettu vain itse itse kehityshankkeeseen. . Meidän on otettava askel taaksepäin ja tarkasteltava organisaation yleistä näkökulmaa data- ja prosessinäkökulmasta. Koska saamme tietää, että käyttämämme tiedot voivat olla jo jossain organisaatioissa. Suunnittelijoina ja arkkitehteina tuomme sen esille, jotta tiedämme mistä hankkia nämä tiedot itse projekteihin. Tiedämme myös asiaan liittyvät tietorakenteet, koska meillä on suunnittelumallit, kuten kehittäjillä on koodinsa suunnittelumallit. Ja meidän on myös otettava tämä yleinen organisatorinen näkökulma. Emme voi vain tarkastella tietoja rakentamassamme sovelluksessa. Meidän on mallinnettava tiedot ja varmistettava, että dokumentoimme ne, koska ne elää kauan kuin itse sovellukset. Nämä sovellukset tulevat ja menevät, mutta meidän on pystyttävä tarkastelemaan tietoja ja varmistamaan, että ne ovat tukevia ja hyvin jäsenneltyjä paitsi sovellusten lisäksi myös päätöksiä varten, jotka raportoivat toimintaa, BI-raportointia ja integrointia muihin sovelluksiin, sisäisiin ja myös organisaatioiden ulkopuolella. Joten meidän on tarkasteltava kyseistä kokonaisvaltaista kuvaa tiedoista ja niiden tietojen elinkaaresta ja ymmärrettävä tietotietojen matka koko organisaatiossa kehtosta hautaan.
Nyt takaisin varsinaisiin ryhmiin ja siihen, kuinka meidän on todella työskenneltävä, vesiputousmenetelmän katsottiin olevan liian hidas tulosten tuottamiseksi. Koska, kuten säiliöesimerkissä todettiin, se oli askel toisensa jälkeen ja toimivan lopputuloksen antaminen kesti usein liian kauan. Nyt teemme sen, että meillä on oltava iteratiivinen työskentelytyyli, jossa kehitämme asteittain sen komponentteja ja kehitämme sitä ajan myötä, kun tuotamme käytettäviä koodeja tai käyttökelpoisia esineitä, sanon sanon, jokaiselle sprintille. Tärkeä asia on yhteistyö tiimin teknisten sidosryhmien ja liike-elämän sidosryhmien välillä, kun teemme yhteistyötä saadaksemme nuo käyttäjän tarinat toteutettavissa olevaksi visioksi koodista ja sitä tukevasta tiedosta. Ja Agile Data Modeler itse havaitsee usein, että meillä ei ole tarpeeksi mallintajia organisaatioissa, joten yksi datamuotoilija tai arkkitehti voi tukea samanaikaisesti useita joukkueita.
Ja sen toinen näkökohta on, että vaikka meillä olisi useita mallintajia, meidän on varmistettava, että meillä on työkalusarja, jota käytämme ja joka mahdollistaa useiden samanaikaisesti lennossa olevien projektien yhteistyön ja niiden jakamisen. data-esineitä sekä sisään- ja uloskirjautumisominaisuuksia. Aion käsitellä tämän nopeasti, koska olemme jo käsitellyt sen edellisessä osassa. Ketterän todellinen lähtökohta on, että olet perustanut asiat tyhjästä, tarinoista tai vaatimuksista. Toistojen puitteissa teemme yhteistyötä ryhmänä. Tyypillisesti kahden viikon tai yhden kuukauden sprintti on organisaatiosta riippuen erittäin yleinen. Ja myös päivittäiset katsaukset ja standup-kokoukset, jotta eliminoimme estoja ja varmistamme, että siirrymme kaikkiin näkökohtiin eteenpäin pysähtymättä eri alueilla läpi käydessämme. Ja noissa sprintissä haluamme varmistaa, että tuotamme käyttökelpoisia toimituksia osana jokaista sprinttiä.
Vain hieman erilainen ota huomioon, laajentamalla sitä edelleen, scrum on menetelmä, josta aion puhua tarkemmin täällä, ja olemme juuri pohjimmiltaan lisänneet sitä edellistä kuvaa muutamilla muilla puolilla. Tyypillisesti siellä on tuotekanta ja sitten sprintin kanta. Joten meillä on yleinen taakka, jonka jokaisen sprintikertauksen alussa me sanomme: "Mitä aiomme rakentaa tähän sprinttiin?", Ja se tehdään sprintisuunnittelukokouksessa. Sitten hajotamme siihen liittyvät tehtävät ja suoritamme niissä yhden tai neljän viikon sprinteissä päivittäisillä arvosteluilla. Kun teemme niin, seuraamme edistymistämme palamiskaavioiden ja palamiskaavioiden avulla seurataksesi pohjimmiltaan mitä on jäljellä rakentaa verrattuna siihen, mitä rakennamme rakentaaksemme sellaisia asioita kuin mikä on kehityksen nopeus, aiommeko tehdä aikataulu, kaikki nämä tyypit. Kaikkia niitä kehitetään jatkuvasti sprintin aikana sen sijaan, että menisit muutama kuukausi tielle ja huomaat, että aiot tulla lyhyeksi ja sinun on pidennettävä projektiaikataulua. Ja erittäin tärkeä osana sitä, koko joukkueelle, on sprintikatsaus lopussa ja sprintin retrospektiivi, joten ennen seuraavan iteraation aloittamista tarkistat tekemäsi ja etsit tapoja, joilla voit parantaa seuraavalla kerralla.
Suoritteiden kannalta tämä on pohjimmiltaan dia, jossa esitetään yhteenveto tyypillisistä asioista, jotka jatkuvat sprintissä. Ja se on hyvin kehityskeskeinen, joten monet täällä näkemistä asioista, kuten toiminnalliset mallit ja käyttötapaukset, suunnittelukooditestien tekeminen, kun katsomme näitä laatikoita täällä, enkä aio käydä läpi niitä kaikilla yksityiskohtaisuustasoilla, ne ovat hyvin kehitykseen suuntautuneita. Ja tässä on haudattu se tosiseikka, että meillä on myös oltava nämä toimitettavat tiedot, jotka kulkevat käsi kädessä tämän pyrkimyksen tukemiseksi. Joten joka kerta, kun näemme asioita, kuten jälkikäteen liittyviä vaatimuksia ja käyttäjän tarinoita, käydessämme läpi, meidän on tarkasteltava, mitkä kehityspanokset meidän on tehtävä, mitkä analyysipalat meidän on tehtävä, entä tietosuunnittelu tai tietomalli, entä esimerkiksi kaupalliset sanastot, jotta voimme yhdistää liiketoiminnan merkityksen kaikkiin tuotteisiin, joita tuotamme? Koska meidän on tuotettava noita käyttökelpoisia tuloksia jokaisessa sprintissä.
Jotkut sanovat, että meidän on tuotettava käyttökelpoinen koodi jokaisen sprintin lopussa. Se ei välttämättä ole tilanne, eli se on puhtain kehitysnäkymä, mutta melko usein - etenkin alussa - meillä voi olla jotain sprint nollasta, jossa keskitymme puhtaasti seisomaan asioihin, tekemään esimerkiksi testistrategioidemme saaminen paikka. Korkean tason suunnittelu sen aloittamiseksi ennen kuin aloitamme täyttämään yksityiskohdat ja varmistamalla, että meillä on puhdas aloitustarinoita tai vaatimuksia, ennen kuin aloitamme muiden yleisöjen sitoutumisen ja sitten rakennamme eteenpäin joukkueena. Aina on vähän prep-aikaa, joten melko usein sprint nolla tai jopa sprint nolla ja yksi. Voi olla hieman käynnistysvaihe, ennen kuin saavutamme täyden lennon ratkaisun toimittamisessa.
Puhutaanko tässä yhteydessä datamalleista hyvin lyhyesti. Kun ihmiset ajattelevat datamalleja, he ajattelevat usein datamalleja olevan kuvan siitä, kuinka erilaiset informaatiot sitovat toisiaan - se on vain jäävuoren huippu. Jotta voit täysin ilmentää sen hengen, kuinka todella haluat lähestyä datan mallintamista - onko kyseessä ketterä kehitys ja muut asiat -, sinun on ymmärrettävä, että tietomallista, jos se tehdään oikein, tulee täydellinen määrittelysi siitä, mitä tämä tieto tarkoittaa organisaatiossa ja miten sitä käytetään taustatietokannoissa. Kun sanon tietokannat, tarkoitan paitsi relaatiotietokantoja, joita olemme mahdollisesti käyttäviä, myös nykypäivän arkkitehtuureissa, joissa meillä on iso data tai NoSQL-alustoja, kuten haluan kutsua niitä. Myös ne suuret tietosäilöt, koska saatamme yhdistää paljon erilaisia tietovarastoja tiedon kuluttamisen ja tuomiseksi ratkaisuihimme sekä sen suhteen, kuinka säilymme tai tallennamme tiedot myös ratkaisuistamme.
Voimme työskennellä useiden tietokantojen tai tietolähteiden kanssa samanaikaisesti tietyn sovelluksen yhteydessä. Tärkeää on, että haluamme saada täyden eritelmän, joten loogisen eritelmän siitä, mitä tämä tarkoittaa sprinttilaiselle organisaation näkökulmalle, mitkä ovat fyysiset rakenteet sen suhteen, kuinka me tosiasiallisesti määrittelemme datan, sen väliset suhteet tietokannat, referenssien eheysrajoitukset, tarkistusrajoitukset, kaikki ne validointipalat, joista yleensä ajattelet. Kuvaileva metatieto on erittäin tärkeä. Kuinka osaat käyttää tietoja sovelluksissasi? Ellet pysty määrittelemään sitä ja tiedä, mitä se tarkoittaa, tai tiedä mistä se tuli, varmistaaksesi, että kulutat oikeita tietoja kyseisissä sovelluksissa - varmista, että meillä on oikeat nimeämiskäytännöt, täydet määritelmät, mikä tarkoittaa täydellistä datasanakirjaa paitsi taulukot, mutta sarakkeet, jotka koostuvat kyseisistä taulukoista, - ja yksityiskohtaiset käyttöönottohuomautukset siitä, kuinka me käytämme sitä, koska meidän on rakennettava tämä tietopohja, koska jopa silloin, kun tämä sovellus tehdään, näitä tietoja käytetään muihin aloitteisiin, joten meidän on varmistettava että meillä on kaikki dokumentoitu tulevia toteutuksia varten.
Jälleen kerran siirrytään asioihin, kuten tietotyypit, avaimet, hakemistot, itse tietomalli ilmentää suurta osaa esiintyvistä liiketoimintasäännöistä. Suhteet eivät ole vain rajoituksia eri taulukoiden välillä; ne auttavat meitä usein kuvailemaan, mitkä todelliset liiketoimintasäännöt ympäröivät sitä, kuinka kyseinen data käyttäytyy ja miten se toimii yhdessä yhtenäisenä kokonaisuutena. Ja tietysti arvorajoitukset ovat erittäin tärkeitä. Nyt tietysti yksi asioista, joita jatkuvasti käsittelemme ja josta on tulossa yhä yleisempiä, ovat asiat, kuten tiedonhallinta. Joten tiedonhallinnan näkökulmasta meidän on myös tarkasteltava, mitä määrittelemme täällä? Haluamme määritellä esimerkiksi turvallisuusluokitukset. Millaisia tietoja käsittelemme? Mitä pidetään perustietojen hallintana? Mitä kauppakauppoja luomme? Mitä vertailutietoja me hyödynnämme näissä sovelluksissa? Meidän on varmistettava, että se on otettu asianmukaisesti huomioon malleissamme. Ja myös tietojen laatua koskevia näkökohtia, on olemassa tiettyjä tietoja, jotka ovat tärkeämpiä organisaatiolle kuin toiset.
Olen ollut mukana projekteissa, joissa korvasimme yli tusina vanhaa järjestelmää uusilla liiketoimintaprosesseilla ja suunnittelemme uusia sovelluksia ja tietovarastoja niiden korvaamiseksi. Meidän piti tietää mistä tiedot tulivat. Mikä tärkeimpien tietojen osalta, liiketoiminnan näkökulmasta, jos tarkastelet tätä tietyn mallin diaa, jonka minulla on täällä, huomaat, että näiden tiettyjen yksiköiden alalaatikot, joka on vain pieni osajoukko, minä Olemme todella pystyneet kaappaamaan liiketoiminnan arvon. Olipa korkea, keskitaso tai matala tällaisille asioille organisaation erilaisille rakenteille. Ja olen myös tallentanut asioita, kuten perustietoluokkia, ovatko ne isäntätaulukoita, ovatko ne referenssejä, ovatko ne tapahtumia. Joten voimme laajentaa metatietojemme malleissamme saadaksemme meille paljon muita ominaisuuksia itse tiedon ulkopuolella, mikä todella auttoi meitä muissa aloitteissa alkuperäisten hankkeiden ulkopuolella ja siirtää niitä eteenpäin. Nyt mitä oli paljon yhdessä diossa, aion käydä läpi nämä muut melko nopeasti.
Puhun nyt hyvin nopeasti siitä, mitä tietomallinntaja tekee näiden erilaisten sprinttien läpi. Ensinnäkin täysimääräinen osallistuja sprintisuunnitteluistunnoissa, joissa otamme käyttäjän tarinoita, sitoutumme siihen, mitä aiomme toimittaa kyseisessä sprintissä, ja selvitämme, kuinka aiomme sen rakentaa ja toimittaa. Tiedon mallinntajana teen myös sen, että työskentelen erillisillä alueilla eri kehittäjien tai ihmisten kanssa. Joten yksi tärkeistä ominaispiirteistä, joita meillä voi olla, on tietomallia tehdessämme, että voimme jakaa kyseisen tietomallin eri näkymiin, kutsutko heitä sitten aihealueiksi vai alamalleiksi, meidän terminologiaa. Joten kun rakennamme mallia, näytämme sitä myös näissä eri osamalleissa, joten eri yleisöt näkevät vain heidän kannalta merkityksellisen, jotta he voivat keskittyä siihen, mitä he kehittävät ja esittävät. Joten minulla saattaa olla joku työskentelemässä sovelluksen aikataulutusosan suhteen, voisin jonkun muun työskennellä tilauksen tekemisessä, jossa teemme kaikki nämä asiat yhdessä sprintissä, mutta voin antaa heille näkökulmat niiden alamallien kautta, jotka vain sovelletaan alueelle, jolla he työskentelevät. Ja sitten ne siirtyvät kokonaismalliin ja koko alamallien rakenteeseen antaakseen erilaisille yleisönäkymille sen, mitä he tarvitsevat nähdä.
Periaatteet tietomallinnusnäkökulmasta, jota haluamme saada, on aina oma lähtötaso, johon voimme palata, koska yksi niistä asioista, jotka meidän on kyettävä tekemään, on, onko se sprintin lopussa vai lopussa useasta sprintistä haluamme tietää, mistä aloitimme, ja aina olla perustiedot tietää, mikä oli delta tai ero siitä, mitä tuotimme tietyssä sprintissä. Meidän on myös varmistettava, että meillä on nopea käännös. Jos tulet siihen mallinntajana, mutta perinteisessä portinvartijaroolissa sanomalla “Ei, ei, et voi tehdä niin, meidän on tehtävä kaikki nämä asiat ensin”, sinut poistetaan joukkueesta, kun todella tarvitset olla aktiivinen osallistuja kaikissa noissa ketterissä kehitysryhmissä. Tämä tarkoittaa, että jotkut asiat putoavat vaunulta tietyn sprintin suorittamisen yhteydessä ja otat ne myöhemmissä sprinteissä.
Esimerkiksi, voit keskittyä tietorakenteisiin vain saadaksesi kehityksen sanomaan sanoa, että tilauksen kirjoituskappale, josta puhin. Myöhemmässä sprintissä saatat palata takaisin ja täyttää tiedot kuten jotkut datasanakirjan dokumentaatioista joidenkin luomiesi esineiden ympärillä. Et aio täyttää tätä määritelmää kaikki yhdessä sprintissä; aiot jatkaa toimituksesi kanssa asteittain, koska voi joskus täyttää nämä tiedot työskennellessään liiketoiminta-analyytikkojen kanssa, kun kehittäjät ovat kiireisiä sovellusten rakentamisessa ja pysyvyyttä näiden tietovarastojen ympärillä. Haluat helpottaa eikä olla pullonkaula. Kehittäjien kanssa työskentelemme eri tavoin. Joissakin asioissa meillä on suunnittelumallit, joten olemme täysivaltaisia osallistujia, joten meillä voi olla suunnittelumallit, joissa sanotaan, että laitamme sen malliin, työnnämme sen kehittäjien hiekkalaatikkotietokantoihin ja sitten he voivat alkaa työskennellä sen kanssa ja pyytää siihen muutoksia.
Voi olla muitakin alueita, joilla kehittäjät ovat työskennelleet, he ovat saaneet jotain, jota he työskentelevät, ja he prototyypistävät joitain asioita, joten kokeilevat joitain asioita omassa kehitysympäristössään. Otamme sen tietokannan, jonka kanssa he ovat työskennelleet, tuomme sen mallinnustyökaluomme, vertaamme meihin malleihimme ja sitten ratkaisemme ja ajamme muutokset takaisin niihin, jotta he voivat reagoida koodiinsa, jotta he noudattavat asianmukaista tietorakennetta jota tarvitsemme. Koska he ovat saattaneet luoda joitain asioita, jotka meillä jo oli muualla, joten varmistamme, että he työskentelevät oikeiden tietolähteiden kanssa. Jatkamme vain iteraatiota koko tämän ajan sprinttiin asti, jotta saamme täydelliset datatoimitukset, täydelliset asiakirjat ja määritelmän kaikille tuottamillesi tietorakenteille.
Menestynein ketterä projekti, johon olen osallistunut erittäin hyvien toimitusten suhteen, on meille ollut filosofia, mallintaa kaikki muutokset täydelliseen fyysiseen tietokannan eritelmään. Pohjimmiltaan tietomallista tulee käyttöönotetut tietokannat, joiden kanssa työskentelet kaikkeen luomaan uuteen, ja sillä on täydet viitteet muihin tietovarastoihin, jos kulutamme muista ulkopuolisista tietokannoista. Osana sitä tuotamme inkrementaalisia skriptejä verrattuna tekemään täysi sukupolvi joka kerta. Ja käytämme suunnittelumallimme antaaksemme meille nopeaa nousua asioiden liikkumisen suhteen erilaisissa kehitysryhmissä, joiden kanssa työskentelemme.
Myös sprintitoiminnassa on jälleen vertailun / yhdistämisen lähtökohta, joten ajatellaan jokaisen muutoksen mallintamista. Joka kerta kun teemme muutoksen, haluamme tehdä muutoksen mallinnuksen ja mikä on erittäin tärkeää, mitä on ollut puutteellista tietojen mallinnuksesta viime aikoihin saakka, tosiasiallisesti siihen saakka, kunnes olemme ottaneet sen käyttöön, on kyky yhdistää mallintaminen tehtävät ja suoritettavat tiedot käyttäjän tarinoiden ja tehtävien kanssa, jotka tosiasiallisesti aiheuttavat muutokset. Haluamme pystyä tarkistamaan mallimuutoksemme samalla tavalla kuin kehittäjät tarkistavat koodinsa viittaamalla käyttäjien tarinoihin, jotka meillä ovat, jotta tiedämme, miksi teimme muutoksia ensinnäkin, se on jotain, mitä teemme. Kun teemme sen, me generoimme inkrementaaliset DDL-skriptit ja postitamme ne, jotta ne voidaan noutaa muiden kehitystoimitusten kanssa ja tarkistaa rakennusratkaisuusi. Meillä voi jälleen olla yksi malli tai työskennellä useiden joukkueiden kanssa. Ja kuten olen puhunut, jotkut asiat ovat datan mallinntajan lähtökohtana, toiset ovat kehittäjien lähtökohtia ja tapaamme keskellä keksimään parhaan kokonaissuunnittelun ja ajamaan sitä eteenpäin ja varmistamaan, että se on suunniteltu oikein yleiset tietorakenteet. Meidän on pidettävä yllä kurinalaisuutta sen varmistamiseksi, että meillä on kaikki asianmukaiset rakenteet tietomallissamme eteenpäin mennessä, mukaan lukien asiat kuten nolla- ja ei nolla-arvot, viiterajoitukset, pohjimmiltaan tarkistusrajoitukset - kaikki ne asiat, joista yleensä ajattelemme .
Puhutaanko nyt vain muutamasta kuvakaappauksesta työkaluista, jotka auttavat meitä tekemään tämän. Mielestäni on tärkeää, että meillä on yhteistoiminnallinen arkisto, joten se, mitä voimme tehdä tietomallittajina - ja tämä on katkelma osasta tietomallia taustalla - on, kun työskentelemme asioiden kanssa, jotka haluamme varmistaa, että pystymme työskentele vain niiden esineiden kanssa, joita meidän on kyettävä muuttamaan, tee muutokset, luo DDL-skriptit muutoksille, jotka olemme tehneet, kun tarkistamme asiat takaisin. Joten mitä voimme tehdä, ER Studiossa on esimerkki, voimme tarkistaa objektit tai objektiryhmät työskennelläksesi, meidän ei tarvitse tarkistaa koko mallia tai alamallia, voimme tarkistaa vain ne asiat, jotka kiinnostavat meitä. Se mitä haluamme sen jälkeen on joko lähtöselvityksessä tai lähtöselvityksessä - teemme sen molemmin puolin, koska erilaiset kehitysryhmät toimivat eri tavoin. Haluamme varmistaa, että yhdistämme tämän käyttäjän tarinaan tai tehtävään, joka ajaa vaatimuksia tälle, ja se on sama käyttäjäjuttu tai tehtävä, jota kehittäjät kehittävät ja tarkistavat koodinsa.
Joten tässä on erittäin nopea katkelma parista näytöistä yhdestä muutoksenhallintakeskuksesta. Mitä tämä tekee, en aio käydä läpi tässä yksityiskohtaisesti, mutta näet käyttäjän tarinan tai tehtävän, joka on sisennetty jokaisen todellisen muutostietueen näkemän alla - olemme luoneet automatisoidun muutostietueen, kun teemme sisään- ja uloskirjautumisen, ja voimme laittaa lisää kuvauksen myös muutostietueeseen. Se liittyy tehtävään, meillä voi olla useita muutoksia tehtävää kohti, kuten voisit odottaa. Ja kun siirrymme siihen muutostietueeseen, voimme katsoa sitä ja mikä tärkeintä, nähdä, mitä todella muutimme? Tätä nimenomaista, korostettua tarinaa varten minulla oli yhden tyyppinen muutos, joka tehtiin, ja kun tarkastelin varsinaista muutostietuetta, se on tunnistanut mallin yksittäiset kappaleet, jotka ovat muuttuneet. Muutin täällä pari määritteitä, sekvensoin ne uudelleen ja se toi mukanaan näkemyksiä, jotka oli tarpeen muuttaa ja jotka olivat riippuvaisia myös niistä, jotta ne syntyisivät inkrementaalisessa DLL: ssä. Kyse ei ole pelkästään mallintaminen perusobjekteissa, mutta myös tällainen suuritehoinen mallityökalu havaitsee muutokset, jotka on rypistettävä tietokannassa tai tietomallissa olevien riippuvaisten kohteiden läpi.
Jos teemme yhteistyötä kehittäjien kanssa ja teemme tämän muutamassa erilaisessa asiassa, teemme jotain heidän hiekkalaatikossaan ja haluamme vertailla ja nähdä, missä erot ovat, käytämme vertailu- / yhdistämisominaisuuksia oikealla ja vasemmalla puolella. puolella. Voimme sanoa: "Tässä on malli vasemmalla puolella, tässä on heidän tietokannansa oikealla puolella, näytä minulle erot." Sitten voimme valita, miten ratkaisemme nämä erot, työnnämmekö asiat tietokantaan tai jos Heillä on tietokannassa joitain asioita, jotka palautamme malliin. Voimme mennä kaksisuuntaiseksi, jotta voimme mennä molempiin suuntiin päivittämällä samanaikaisesti sekä lähdettä että tavoitetta ja tuottaa sitten inkrementaaliset DDL-skriptit asentaaksemme muutokset itse tietokantaympäristöön, mikä on erittäin tärkeää. Voimme myös käyttää sitä, että voimme käyttää tätä vertailu- ja yhdistämisominaisuutta milloin tahansa. Jos otamme otoksia läpi, voimme aina verrata yhden sprintin alkua toisen sprintin alkuun tai loppua, jotta voimme nähdä täydellinen asteittainen muutos siihen, mitä annettiin tietyssä kehitys sprintissä tai sarjassa.
Tämä on erittäin nopea esimerkki muutetusta komentosarjasta, jokainen teistä, jotka olette työskennellyt tietokantojen kanssa, on nähnyt tämän tyyppiset asiat, tämän voimme purkaa koodista muuttuneena komentosarjana, jotta varmistamme, että pitää asiat täällä. Se, mitä vedin täältä, vain sotkuisuuden vähentämiseksi, on se, mitä teemme myös näiden muutettujen komentosarjojen kanssa, jos oletetaan, että myös kyseisissä taulukoissa on tietoja, joten luomme myös DML, joka kerää väliaikaisten taulukoiden tiedot ja työnnä se takaisin uusiin tietorakenteisiin, joten tarkastelemme paitsi rakenteita myös tietoja, jotka olemme jo mahdollisesti sisältäneet kyseisiin rakenteisiin.
Keskustelemme nopeasti automatisoiduista rakennusjärjestelmistä, koska tekeessämme ketterää projektia melko usein työskentelemme automatisoitujen rakennusjärjestelmien kanssa, joissa meidän on tarkistettava eri toimitukset yhdessä varmistaaksemme, että emme riko rakennuksiamme. Mitä tämä tarkoittaa, että synkronoimme suoritteet, ne muutoskomentosarjat, joista puhuin DDL-skriptin kanssa, on kirjauduttava sisään, vastaava sovelluskoodi on kirjauduttava sisään samanaikaisesti ja paljon kehittäjiä ei tietenkään nyt kehitä. tehdään suoralla SQL: llä tietokantoja ja tällaista asiaa vastaan. Melko usein käytämme pysyvyyskehyksiä tai rakennamme datapalveluita. Meidän on varmistettava, että näiden kehysten tai palveluiden muutokset kirjataan sisään täsmälleen samaan aikaan. Ne menevät automatisoituun rakennusjärjestelmään joissakin organisaatioissa ja jos rakennus katkeaa, ketterässä metodologiassa, kannen kiinnitys on käsitelty ennen siirtymistä eteenpäin, jotta tiedämme, että meillä on toimiva ratkaisu ennen kuin siirrymme eteenpäin. Ja yhdessä niistä hankkeista, joissa olin mukana, otimme tämän äärimmäisyyteen - jos rakennusrikko meillä oli tosiasiallisesti liitetty useisiin alueemme tietokoneisiin, joissa olimme yhdessä yrityksen käyttäjien kanssa, meillä oli punaiset vilkkuvat valot vain kuten poliisiautojen huipulla. Ja jos rakennus hajosi, nuo punaiset vilkkuvat valot alkoivat sammua ja tiesimme, että kannen kaikki kädet olivat: korjaa rakennus ja jatka sitten mitä teimme.
Haluan puhua muista asioista, ja tämä on ER Studion ainutlaatuinen kyky. Se todella auttaa, kun yritämme rakentaa näitä esineitä kehittäjinä näille pysyvyysrajoille, meillä on konsepti, jota kutsutaan liiketoimintadataobjekteiksi ja mikä antaa meille mahdollisuuden Toisin sanoen, jos tarkastellaan tätä hyvin yksinkertaistettua tietomallia, se antaa meille mahdollisuuden kapseloida entiteettejä tai entiteettiryhmiä sille, missä pysyvyysrajat ovat. Missä tietomallinntajana voimme ajatella jotain ostotilauksen otsikkoa ja tilausten kohdistamista sekä muita yksityiskohtaisia taulukoita, jotka sitovat siihen rakentamistapojemme mukaisesti, ja datapalvelumme kehittäjien on tiedettävä, kuinka asiat jatkuvat näiden eri tietojen kanssa rakenteisiin. Kehittäjämme ajattelevat esimerkiksi ostotilausta kokonaisuutena esineenä ja mikä on heidän sopimuksensa siitä, kuinka he luovat kyseiset esineet. Voimme paljastaa tuon teknisen yksityiskohdan, jotta datapalvelimia rakentavat ihmiset näkevät sen alla olevan tilan ja voimme suojata muut yleisöt monimutkaisuuksilta, jotta he vain näkevät eri korkeamman tason esineet, mikä toimii myös erittäin hyvin kommunikoidessaan liiketoiminnan kanssa analyytikot ja yritysryhmät, kun puhumme myös erilaisten liiketoimintakonseptien vuorovaikutuksesta.
Mukava asia on myös se, että laajennamme ja tiivistämme niitä rakentavasti, jotta pystymme ylläpitämään korkeamman asteen objektien välisiä suhteita, vaikka ne ovatkin lähtöisin rakenteista, jotka sisältyvät itse yritystietokohteisiin. Nyt mallineena päästä sprintin loppuun, sprintin käärityksen lopussa minulla on paljon asioita, jotka minun on tehtävä, joita kutsun taloudenhoitoon seuraavaa sprinttiä varten. Jokainen sprintti, jonka luon nimeltään julkaisuksi, antaa minulle lähtökohdan sille, mikä minulla on nyt julkaisun lopussa. Joten se tarkoittaa sitä, että lähtötasoni on menossa eteenpäin, kaikkia näitä perustietoja tai nimeltään julkaisuja, joita luon ja tallennan arkistossani, voin käyttää vertailuun / yhdistämiseen, jotta voin aina verrata mihin tahansa muuhun sprinttiin tiettyyn sprintin päähän, joka on erittäin tärkeää tietää, mitkä muutokset olivat tietomalliasi matkalla matkalle.
Luon myös delta DDL-skriptin käyttämällä vertailua / yhdistämistä uudelleen sprintin alusta loppuun. Olen ehkä tarkistanut kokonaisen joukon inkrementaalisia komentosarjoja, mutta jos tarvitsen sitä, minulla on nyt komentosarja, jonka voin ottaa käyttöön muiden hiekkalaatikoiden seisomiseksi, jotta voin vain sanoa, että tämä meillä oli yhden sprintin alussa, push sen läpi, rakenna tietokanta hiekkalaatikkona seuraavan sprintin aloittamiseen ja voimme myös käyttää näitä asioita esimerkiksi standup QA -tapahtumien tekemiseen ja viime kädessä tietysti haluamme siirtää muutoksemme tuotantoon, joten meillä on useita asioita meneillään samaan aikaan. Olemme jälleen täysin mukana sprintisuunnittelussa ja jälkikäteen, jälkikäteen liittyvät näkökohdat ovat todellakin opittua ja se on erittäin tärkeää, koska liikkua voi nopeasti nopeasti ketterän aikana, sinun on lopetettava ja juhlittava menestyksiä, kuten nyt. Selvitä mikä on vialla, tee siitä parempaa seuraavan kerran, mutta juhlia myös asioita, jotka menivät oikein, ja rakenna niihin jatkaessasi eteenpäin seuraavissa sprinteissä eteenpäin.
Aion nyt puhua erittäin nopeasti liiketoiminnan arvosta. Oli projekti, johon olen osallistunut monta vuotta sitten ja joka alkoi ketteränä projektina, ja se oli äärimmäinen projekti, joten se oli puhdasta itsensä järjestävää joukkuetta, jossa vain kehittäjät tekivät kaiken. Lyhyesti sanottuna, tämä projekti pysähtyi ja he huomasivat käyttävänsä yhä enemmän havaittujen virheiden korjaamiseen ja korjaamiseen kuin toimintojen lisäämiseen ja itse asiassa, kun he katsoivat sitä palamiskaavioissa heidän piti pidentää hanketta kuusi kuukautta suurilla kustannuksilla. Ja kun tarkastelimme sitä, tapa korjata ongelma oli käyttää asianmukaista tietomallinnustyökalua, kun asiantunteva tietomallintaja on mukana itse projektissa.
Jos tarkastelet tätä pystysuuntaista palkkia tällä tietyllä kaaviolla, se näyttää kumulatiiviset viat verrattuna kumulatiivisiin objekteihin, ja puhun tietoobjekteista tai rakenteista, jotka on luotu, kuten taulukoita rajoituksilla ja tällaisista asioista, jos katsot Ennen tietomallinntajan käyttöönottoa virheiden määrä oli tosiasiallisesti ylittämässä ja alkoi muodostua pieni aukko siihen pisteeseen asti tuotettujen kohteiden todelliseen lukumäärään verrattuna. Viikon 21 jälkeen, ts. Kun tietomallintaja tuli sisään, uudisti tietomallin useiden asioiden korjaamiseksi perustuvan tiedon perusteella ja aloitti sitten mallinnuksen osana projektiryhmää eteenpäin, muutokset projektin työntyessä eteenpäin . Ja näitte erittäin nopean käännöksen, että noin puolentoista sprintin sisällä meillä oli valtava nousu luotavien ja rakennettavien kohteiden ja tietorakenteiden lukumäärään, koska tuotimme tiedon mallinnustyökalusta pikemminkin kuin kehittäjäkeppua. rakentamalla niitä ympäristöön, ja ne olivat oikein, koska heillä oli asianmukainen referenssieheys ja muut rakenteet, joita sillä olisi oltava. Vikojen taso verrattuna melkein tasaisiin. Suorittamalla kyseiset asianmukaiset toimenpiteet ja varmistamalla, että tietojen mallintaminen oli täysimääräistä, hanke toteutettiin ajoissa paljon korkeammalla laadulla, eikä sitä itse asiassa olisi toteutettu, ellei näitä vaiheita olisi toteutettu. Siellä on paljon ketteriä epäonnistumisia, on myös paljon ketterät onnistumisia, jos saisit oikeat ihmiset oikeisiin rooleihin. Olen valtava ketterän operatiivisen oppiaineen kannattaja, mutta sinun on varmistettava, että sinulla on kaikkien oikeiden ryhmien taidot, jotka ovat mukana projektitiiminä, kun siirryt eteenpäin ketterässä pyrkimyksessä.
Yhteenvetona voidaan todeta, että tietoarkkitehdit ja mallinntajat on osallistuttava kaikkiin kehityshankkeisiin. ne todella ovat liima, joka pitää kaiken yhdessä, koska tietomallinnustajina ja arkkitehteina ymmärrämme, paitsi tietyn kehitysprojektin tietorakenteet, myös silloin, kun tiedot ovat organisaatiossa ja mistä voimme lähteä, ja miten aiotaan käyttää ja hyödyntää tietyn sovelluksen ulkopuolella, jonka parissa työskentelemme. Ymmärrämme monimutkaiset tietosuhteet ja on ensiarvoisen tärkeää, että pystymme etenemään eteenpäin ja myös hallinnon näkökulmasta dokumentoimaan karttaa ja ymmärtämään, miltä koko tietomaisema näyttää.
Se on kuin valmistus; Tulin valmistustaustasta. Et voi tarkastaa laatua jotain lopussa - sinun on rakennettava laatu suunnitteluun etukäteen ja läpi, ja tietomallinnus on tapa rakentaa tämä laatu suunnitteluun tehokkaasti ja kustannustehokkaasti koko ajan. . Ja taas, jotain muistettavaa - ja tämä ei ole olla harhaa, mutta se on totuus - sovellukset tulevat ja menevät, data on elintärkeä yrityksen omaisuus ja se ylittää kaikki nämä sovellusrajat. Aina kun lisäät sovelluksen, sinua todennäköisesti pyydetään säilyttämään tiedot muista aiemmin tulleista sovelluksista, joten meidän on vain muistettava, että se on tärkeä yritysomaisuus, jota ylläpidämme ajan myötä.
Ja siinä kaikki! Täältä otamme lisää kysymyksiä.
Eric Kavanagh: Hyvä on, anna minun heittää sen ensin Robinille. Ja sitten, Dez, olen varma, että sinulla on pari kysymystä. Ota se pois, Robin.
Dr. Robin Bloor: Okei. Rehellisesti sanottuna minulla ei ole koskaan ollut ongelmia ketterien kehittämismenetelmien kanssa ja minusta näyttää siltä, että mitä teet täällä, on erittäin järkevää. Muistan, että tarkastelin jotain 1980-luvulla, joka todella osoitti, että ongelma, johon tosiasiallisesti joudut hallitsemattoman projektin suhteen, on yleensä se, että annat virheen jatkaa tietyn vaiheen ulkopuolella. Se on vain yhä vaikeampaa korjata, jos et saa kyseistä vaihetta oikein, joten yksi niistä asioista, joita täällä teet - ja mielestäni tämä on liukumäki - mutta yksi niistä asioista, joita teet täällä nolla sprintissä on mielestäni ehdottoman tärkeä, koska yrität todella saada toimitukset kiinnittymään sinne. Ja jos et saa toimituksia kiinni, niin toimitukset muuttavat muotoa.
Se on eräänlainen mielipiteeni. Se on myös mielipiteeni - minulla ei oikeastaan ole mitään väitettä siitä ajatuksesta, että sinun on saatava tietomallinnus oikealle tietylle yksityiskohtaisuustasolle ennen läpi. Se mitä haluaisin sinun yrittävän, koska en saanut siitä ymmärrystä kokonaan, on vain kuvaus yhdestä näistä hankkeista sen koon suhteen, sen suhteen, miten se sujui, kuka, tiedätkö, missä ongelmat hajaantuivat, ratkaistiinko ne? Koska mielestäni tämä dia on melko paljon sen sydän ja jos voisit tarkentaa asiaa tarkemmin, olisin erittäin kiitollinen.
Ron Huizenga: Toki, ja käytän pari esimerkkihanketta. Se, joka eräänlaisena meni pois kiskoilta, joka vedettiin takaisin ottamalla oikeat ihmiset mukaan ja tekemällä tietojen mallintaminen, ja kaikki oli todella tapa varmistaa, että suunnittelu ymmärrettiin paremmin ja meillä oli selvästi parempi toteutussuunnittelu matkalla läpi mallintamalla sitä. Koska mallinnettaessa tiedät, että voit generoida DDL: n ja kaiken takaapäin ja työkalusta sen sijaan, että tarvitset kiinni rakentaa tätä kuten ihmiset yleensä tekevät menemällä suoraan tietokantaympäristöön. Ja tyypillisiä asioita, jotka tapahtuvat kehittäjien kanssa, ovat, että he menevät sinne ja sanovat: okei, tarvitsen näitä taulukoita. Oletetaan, että teemme tilauksia. Joten he saattavat luoda tilauksen otsikon ja tilauksen yksityiskohtaiset taulukot sekä tällaiset asiat. Mutta he usein unohtaa tai laiminlyövät varmistaakseen, että rajoitukset edustavat ulkomaisia avainasuhteita. Heillä ei ehkä ole avaimia oikein. Myös nimeämiskäytännöt voivat olla epäilyttäviä. En tiedä kuinka monta kertaa olen käynyt ympäristössä, jossa näet joukon erilaisia taulukoita, joilla on eri nimet, mutta silloin sarakkeiden nimet samoissa taulukoissa ovat kuten tunnus, nimi tai mikä tahansa, joten ne Olemme todella menettäneet kontekstin ilman taulukkoa tarkalleen mitä se on.
Joten tyypillisesti tietojen mallinnuksen yhteydessä varmistamme, että käytämme asianmukaisia nimeämiskäytäntöjä kaikkiin esineisiin, joita myös DDL: ssä syntyy. Mutta tarkemmin itse hankkeiden luonteesta tarkoitan yleensä melko suuria aloitteita. Yksi niistä oli 150 miljoonan dollarin liiketoiminnan muutosprojekti, jossa korvasimme yli tusinan vanhan järjestelmän. Meillä oli viisi erilaista ketterää joukkuetta, jotka olivat käynnissä samanaikaisesti. Minulla oli täysi tietoarkkitehtuuritiimi, joten tiimissäni olivat mallinntajat jokaiseen muuhun sovellusaluetiimiin upotettuna, ja työskentelimme yhdessä yrityksen sisäisten yritysasiantuntijoiden kanssa, jotka tunsivat aiheen ja tekivät käyttäjän tarinoita itse vaatimuksia varten. Meillä oli liike-elämän analyytikoita jokaisessa ryhmässä, joka mallitsi tosiasiallisesti liiketoimintaprosessia aktiivisuuskaavioilla tai liiketoimintaprosessikaavioilla auttamalla muokkaamaan käyttäjän tarinoita enemmän käyttäjien kanssa, ennen kuin heidät nauttivat myös muut tiimit.
Ja sitten tietysti kehittäjät, jotka rakensivat sovelluskoodin päälle. Ja työskentelimme myös, luulen, että myös neljä erilaista järjestelmäintegraation myyjää rakensivat sovelluksen erilaisia osia, joissa yksi joukkue rakensi datapalveluita, toinen rakensi sovelluslogiikkaa yhdelle alueelle, toinen asiantuntijoita toisella liiketoiminta-alueella rakensi sovelluslogiikkaa kyseiselle alueelle. Joten meillä oli koko yhteistyö ihmisiä, jotka työskentelivät tämän projektin parissa. Erityisesti sillä joukkueella oli maalla 150 ihmistä rannalla ja toisessa 150 resurssia offshore-joukkueessa, jotka tekivät yhteistyötä kahden viikon sprinteissä tämän asian ajamiseksi. Ja sinun täytyy varmistaa, että ampat kaikkia sylintereitä ja että kaikki ovat synkronoituja niiden toimituksien suhteen hyvin, ja sinulla oli usein nollauksia varmistaaksesi, että olemme saaneet valmiiksi kaikki tarvittavat esineet. jokaisen sprintin lopussa.
Dr. Robin Bloor: No, se on vaikuttavaa. Ja vain vähän tarkemmin tästä - päädyitkö lopuksi täydelliseen MD-karttaan koko tietoalueelta, jota kutsun nimeltään, projektin lopussa?
Ron Huizenga: Meillä oli täydellinen tietomalli, joka hajotettiin hajoamisen myötä kaikkien eri liiketoiminta-alueiden kesken. Itse datasanakirja kokonaisten määritelmien suhteen jäi hieman lyhyeksi. Meillä oli suurin osa taulukoista määritelty; meillä oli suurin osa sarakkeista määritelty tarkalleen, mitä ne tarkoittivat. Oli joitain, joita ei ollut siellä, ja, mielenkiintoista kyllä, monet niistä olivat tietoja, jotka tulivat vanhoista järjestelmistä, joissa itse hankkeen päättymisen jälkeen asiakirja oli edelleen siirretty kokonaisuus esineitä, sellaisena kuin ne olivat, itse projektin ulkopuolella, koska organisaatio jatkoi sitä jotain, jota piti ylläpitää. Joten samalla organisaatio suhtautui tiedonhallinnan tärkeyteen huomattavasti, koska näimme paljon puutteita vanhoissa järjestelmissä ja vanhoissa tietolähteissä, joita yritimme kuluttaa, koska niitä ei dokumentoitu. Monissa tapauksissa meillä oli vain tietokantoja, jotka meidän piti kääntää suunnittelijaksi ja yrittää selvittää, mitä siellä oli ja mitä tietoja varten oli.
Dr. Robin Bloor: Se ei ole yllättävää minulle, että se erityinen osa sitä. Tietohallinto on, kutsutaanpa sitä, erittäin moderni huolenaihe, ja mielestäni on todella paljon työtä, jonka, sanotaanpa, olisi pitänyt tehdä historiallisesti tiedonhallinnan suhteen. Se ei koskaan ollut, koska pystyisit tavallaan pääsemään eroon tekemättä sitä. Mutta kun tietolähde vain kasvoi ja kasvoi, et lopulta pystynyt.
Joka tapauksessa siirron Dezille, koska mielestäni minulla on ollut varattu aika. Dez?
Dez Blanchfield: Kyllä, kiitos. Tarkkailen ja ajattelen itselleni koko tämän asian kautta, että puhumme ketterän näkemisestä, jota käytetään vihaan monin tavoin. Vaikka siinä on negatiivisia konnotaatioita; Tarkoitin sitä positiivisella tavalla. Voisitteko antaa meille vain skenaarion, tarkoitan, että kahdessa paikassa voin nähdä tämän olevan täydellinen sarja: yksi on uusia projekteja, jotka on vain tehtävä ensimmäisestä päivästä lähtien, mutta mielestäni aina, kokemukseni mukaan, se on usein Asia, että kun projektit kasvavat riittävän suuriksi, että tämä on monin tavoin välttämätöntä, kahden maailman liittämisen välillä on mielenkiintoinen haaste, eikö niin? Voitko antaa meille minkäänlaista näkemystä joihinkin menestystarinoihin, jotka olet nähnyt missä olet mennyt organisaatioon, on käynyt selväksi, että heillä on pieni ristiriita kahdessa maailmassa ja olet voinut menestyä Tämä saattaa paikoilleen ja tuo suuret projektit yhteen, missä ne ovat muuten voineet mennä kiskoille? Tiedän, että se on erittäin laaja kysymys, mutta mietin vain, onko olemassa jokin erityinen tapaustutkimus, jolla voit osoittaa mihin sanoit, tiedät, laitamme tämän kaiken paikoilleen ja se on tuonut koko kehitysryhmän yhdessä tietoryhmä ja olemme jonkin verran käsitelleet jotain, joka olisi muuten saattanut upottaa veneen?
Ron Huizenga: Toki, ja itse asiassa yksi projekti, joka sattui olemaan putkilinjaprojekti, viittasin projektiin, jossa osoitin kaavion, jossa oli vikoja ennen ja jälkeen data-mallinntajan. Melko usein, ja on ennakkokäsityksiä, etenkin jos asiat pyörivät siellä, missä se tehdään puhtaasti kehityksen näkökulmasta, vain kehittäjät osallistuvat näihin ketteriin hankkeisiin toimittamaan sovelluksia. Joten mitä siellä tapahtui, tietenkin on, että he ovat päässeet kiskoilta ja etenkin heidän dataesineensä tai tuottamansa tietojen luovutettavat aineistot jäävät laadun kannalta merkityksettömiin ja käsittelevät tosiasiallisesti kaiken kaikkiaan. Ja on melko usein tätä väärää käsitystä, että tietomallinntajat hidastavat projekteja, ja jos tietomallinntajalla ei ole oikeaa asennetta. Kuten sanon, joudut menettämään - joskus on tietomallintajia, joilla on tuo perinteinen portinvartija-asenne, jossa "Me olemme täällä hallitsemassa tietorakenteiden ulkonäköä" ja että mentaliteetin on katoava. Kaikkien ketterään kehitykseen osallistuvien ja etenkin tietomallien on toimittava avustajana, jotta ryhmät todella auttavat etenemään eteenpäin. Ja paras tapa havainnollistaa sitä on näyttää nopeasti joukkueille, kuinka tuottavia he voivat olla mallinnuttamalla muutokset ensin. Ja jälleen kerran, siksi puhuin yhteistyöstä.
Jotkut asiat voimme mallintaa ensin ja luoda DDL työntääkseen kehittäjille. Haluamme myös varmistaa, etteivät he tunne, että heitä rajoitetaan. Joten jos on asioita, joissa he työskentelevät, anna heidän jatkaa työskentelyä kehityshiekkalaatikoissaan, koska siellä kehittäjät työskentelevät omien pöytiensä tai muiden tietokantojen parissa tehdä joitain muutoksia, kun he testaavat asioita. Ja teemme yhteistyötä heidän kanssaan ja sanomme: "Okei, työskentele sen kanssa." Tuomme sen työkaluun, ratkaisemme sen ja siirrämme sitten eteenpäin ja annamme sinulle skriptit, joita voit käyttää sen päivittämiseen tietokannat päivittääkseen ne siihen, minkä todellisen seuraamuksena on todellinen tuotantokuva siitä, kun jatkamme eteenpäin. Ja voit kääntää tämän ympäri erittäin nopeasti. Huomasin, että päiväni olivat täynnä, kun menin vain edestakaisin iteroimalla eri kehitysryhmien kanssa, katsellen muutoksia, vertaamalla, luomalla skriptejä, saamaan ne eteenpäin ja pystyin pitämään itseni suhteessa neljään kehitysryhmään melko helposti, kun olemme saavuttanut vauhdin.
Dez Blanchfield: Yksi niistä asioista, jotka mieleeni tuodaan, on se, että tiedätte, että monet keskusteluista, joita päivittäin käyn, koskevat tätä tavarajunaa, joka saapuu meille, eräänlaisena koneelta -kone ja Internet. Ja jos ajattelemme, että meillä on nyt paljon tietoa nykyisestä yritysympäristöstämme, tiedätkö, jos otamme yksisarviset sivuun hetkeksi, kun tiedämme, että Googlesilla ja Facebookeilla ja Ubersilla on datan petatavuja, mutta perinteisessä yrityksessä puhumme vielä satoista teratavuista ja paljon datasta. Mutta tämä tavarajuna tulee mielestäni organisaatioissa, ja tohtori Robin Bloor viittasi siihen aiemmin, Internetistä. Tiedätkö, meillä on paljon verkkoliikennettä, meillä on sosiaalista liikennettä, meillä on nyt liikkuvuus ja mobiililaitteet, pilvi on, tavallaan, räjähtänyt, mutta nyt meillä on älykäs infrastruktuuri, älykkäät kaupungit ja tässä koko tietomaailmassa on juuri räjähtää.
Jokapäiväisessä organisaatiossa keskisuuri tai suuri organisaatio, joka istuu siellä ja näkee tämän tuskallisen maailman tulevan heidän luokseen ja jolla ei ole välitöntä suunnitelmaa mielessä, mitkä ovat vain muutaman lauseen sisältämät otot, jotka olet pannut heille milloin ja missä heidän täytyy alkaa keskustella keskustelemalla joidenkin näiden metodologioiden käyttöönotosta. Kuinka aikaisin heidän täytyy alkaa suunnitella melkein istumaan ja kiinnittämään huomiota ja sanoa, että tämä on oikea aika hankkia joitain työkaluja paikalleen ja saada joukkue koulutukseen ja käydä keskustelua sanasta, joka kiertää tämän haasteen? Kuinka myöhässä tarinassa on liian myöhäistä tai milloin on liian aikaista? Miltä se näyttää joillekin näkemistäsi organisaatioista?
Ron Huizenga: Sanoisin useimmille organisaatioille, että jos ne eivät ole vielä tehneet sitä ja mukauttaneet datan mallintamista ja tietoarkkitehtuuria tehokkailla työkaluilla, tämä on heidän tekemänsä aika eilen. Koska on mielenkiintoista, että jopa tänään, kun tarkastellaan organisaatioiden tietoja, meillä on niin paljon tietoa organisaatioissamme ja yleisesti ottaen joihinkin havaitsemiemme kyselyjen perusteella käytämme vähemmän kuin viisi prosenttia tiedosta tehokkaasti kun tarkastelemme organisaatioita. Ja IoT: n tai jopa NoSQL: n avulla iso data - vaikka se ei olisi vain IoT, vaan vain iso data yleensä - missä nyt alamme kuluttaa entistä enemmän tietoa, joka on peräisin organisaatioiden ulkopuolelta, tuo haaste muuttuu yhä suuremmaksi koko ajan. Ainoa tapa, jolla meillä on mahdollisuus puuttua asiaan, on auttaa meitä ymmärtämään, mistä kyseisistä tiedoista on kyse.
Joten käyttötapa on hiukan erilainen. Se mitä katsomme tekevämme, on kun tarkastelemme kyseisiä tietoja, vangitsemme ne, meidän on peruutettava ne, tarkastettava, mitä niissä on, onko se tietojärvissä tai edes sisäisissä tietokannoissamme, syntetisoida mitä data on, käytä siihen merkityksiä ja määritelmiä, jotta ymmärrämme, mitä tiedot ovat. Koska emme ymmärrä, mikä se on, emme voi varmistaa, että käytämme sitä oikein tai riittävästi. Joten meidän on todellakin saatava käsitellä mitä nämä tiedot ovat. Ja toinen osa sitä on, älä tee sitä, koska voit kaiken tämän ulkoisen tiedon kuluttamisen suhteen varmistaa, että sinulla on käyttötapaus, joka tukee tämän ulkoisen tiedon kuluttamista. Keskity tarvittaviin asioihin sen sijaan, että yrittäisit vain vetää ja hyödyntää asioita, joita saatat tarvita myöhemmin. Keskity ensin tärkeisiin asioihin ja kun työskentelet läpi läpi, niin sinun tulee kuluttaa ja yrittää ymmärtää muita tietoja ulkopuolelta.
Täydellinen esimerkki siitä on, että tiedän, että puhumme Internetistä ja sensoreista, mutta saman tyyppiset ongelmat ovat olleet monissa organisaatioissa jo vuosia, jopa ennen Internetistä. Jokaisella, jolla on tuotannonvalvontajärjestelmä, on se sitten putkistoyritys, valmistava, prosessipohjaista yritystä, jolla on asioita, joissa he tekevät paljon automatisointia ohjauksineen ja käyttävät tietovirtoja ja vastaavia, nämä tiedot, joita he yrittävät juoda selvittääkseen, mitkä ovat ne tapahtumat, jotka ovat tapahtuneet tuotantolaitteissani ilmoittamaan - mitä tapahtui ja milloin? Ja tämän valtavan tietovirran joukossa on vain tiettyjä tietoja tai tunnisteita, joista he ovat kiinnostuneita, jotta he tarvitsevat seuloa, syntetisoida, mallintaa ja ymmärtää. Ja he voivat jättää huomiotta loput, kunnes on aika ymmärtää se todella, ja sitten he voivat laajentaa soveltamisalaansa vetääkseen enemmän ja enemmän siitä laajuuteen, jos se on järkevää.
Dez Blanchfield: Se todellakin. On yksi kysymys, jonka aion käsitellä, ja se tuli herralta nimeltä Eric, ja olemme keskustelleet siitä yksityisesti. Olen juuri kysynyt hänen luvansa, jonka hän on antanut, kysyä sinulta sitä. Koska se johtaa mukavasti tähän, vain kietoutumiseen, koska me menemme hiukan ajan myötä, ja annan takaisin Ericille. Mutta toisen Ericin kysymys oli, onko kohtuullista olettaa, että käynnistyksen omistajat tuntevat ja ymmärtävät mallinnusterminologian ympärillä olevat ainutlaatuiset haasteet ja niin, vai onko se annettava jollekin muulle tulkitsemista varten? Joten toisin sanoen pitäisikö käynnistyksen kyetä olemaan valmis ja halukas ja kykenevä keskittymään tähän ja toimittamaan sen? Vai onko se jotain, jonka heidän pitäisi todennäköisesti ostaa ja tuoda asiantuntijoita mukaan?
Ron Huizenga: Luulen, että lyhyt vastaus on, että se todella riippuu. Jos kyseessä on käynnistys, jolla ei ole ketään sisäistä, joka on tietoarkkitehti tai mallinntaja, joka todella ymmärtää tietokannan, niin nopein tapa aloittaa on tuoda joku konsultointitaustaan, joka on erittäin perehtynyt tähän tilaan ja voi saada he menevät. Koska mitä löydät - ja itse asiassa tein tämän monissa tehtävissä, jotka tein ennen kuin pääsin pimeälle puolelle tuotehallinnassa - haluaisinko mennä organisaatioihin konsulttina, johtaa niiden tietoarkkitehtuuritiimejä, jotta he voisivat jonkin verran keskittyä itseensä ja kouluttaa kansalaisiaan kuinka tehdä tällaisia asioita niin, että he ylläpitävät sitä ja jatkavat tehtävää eteenpäin. Ja sitten siirryn seuraavaan työhöni, jos sillä on järkeä. Siellä on paljon ihmisiä, jotka tekevät niin, joilla on erittäin hyvä datakokemus, joka voi saada heidät liikkumaan.
Dez Blanchfield: Se on hieno takeaway, ja olen täysin samaa mieltä siitä, ja olen varma, että tohtori Robin Bloor myös. Erityisesti aloittaessasi olet keskittynyt pk-yritykseksi tarjouksen erityisarvoon, jonka haluat rakentaa osana startup-yritystäsi, ja sinun ei todennäköisesti tarvitse olla asiantuntija kaikessa, joten upea neuvo. Mutta paljon kiitoksia, loistava esitys. Todella hienoja vastauksia ja kysymyksiä. Eric, aion palata takaisin sinulle, koska tiedän, että olemme menneet luultavasti kymmenen minuutin ajan myötä, ja tiedän, että haluat pysyä lähellä aikamme ikkunoitamme.
Eric Kavanagh: Se on kunnossa. Meillä on ainakin pari hyvää kysymystä. Anna minun heittää yksi sinulle. Luulen, että olet vastannut joihinkin muihin. Mutta erittäin mielenkiintoinen havainto ja kysymys yhdeltä kirjoittelijalta, joskus ketterissä projekteissa data-mallinnuksella ei ole koko pitkäaikaista kuvaa ja niin he päättävät suunnitella jotain sprintissä ja sitten joutua suunnittelemaan uudelleen kolmessa tai neljässä sprintissä. Eikö tämä vaikuta haitalliselta? Kuinka voit välttää sellaista?
Ron Huizenga: Se on vain ketterän luonnetta, että et saa kaikkea aivan oikein tietyssä sprintissä. Ja se on itse asiassa osa ketterän henkeä, on: työskentele sen kanssa - aiot tehdä prototyyppejä, joissa työskentelet koodilla tietyssä sprintissä, ja aiot tehdä tarkennuksia siihen. Ja osa tätä prosessia on, kun toimitat asioita, jotka loppukäyttäjä näkee sen ja sanoo: "Joo, se on lähellä, mutta minun on todellakin pakko saada se myös tekemään tämä vähän ylimääräistä." Joten se ei vaikuta vain toiminnalliseen suunnitteluun itse koodista, mutta melko usein meidän on muokattava tai lisättävä lisää tietorakennetta näiden tiettyjen asioiden alle antaaksemme käyttäjän haluamansa. Ja siinä kaikki on reilua peliä, ja siksi haluat todella käyttää suuritehoisia työkaluja, koska voit nopeasti mallintaa ja tehdä muutoksen mallintamistyökalussa ja luoda sitten DDL-tietokannan, jonka kehittäjät voivat sitten työskennellä toimittaakseen tämän muuttaa vielä nopeammin. Säästät heitä joutumatta tekemään tietorakenteiden käsikoodaus, sellaisena kuin se oli, ja annat heidän keskittyä ohjelmointi- tai sovelluslogiikkaan, jossa he ovat taitavimpia.
Eric Kavanagh: Se on täysin järkevää. Meillä oli muutama ihminen, joka kysyi vain konkreettisia kysymyksiä siitä, kuinka tämä kaikki sitoo työkalun. Tiedän, että vietit jonkin aikaa tutkiessasi esimerkkejä ja olet osoittanut kuvakaappauksia siitä, kuinka käytät tosiasiallisesti näitä asioita. Koko tämän sprintiprosessin suhteen kuinka usein näet organisaatioiden pelaamisessa verrattuna kuinka usein näet perinteisempiä prosesseja, joissa asiat vain, tavallaan, viihtyvät ja vievät enemmän aikaa? Kuinka yleinen on sprintityylinen lähestymistapa näkökulmastasi?
Ron Huizenga: Luulen, että näemme sen yhä enemmän. Tiedän, että sanoisin, todennäköisesti etenkin viimeisen 15 vuoden aikana, että olen nähnyt paljon enemmän ihmisten omaksumista, jotka tunnustavat, että heidän on todella omaksuttava nopeampi toimitus. Joten olen nähnyt yhä useampia organisaatioita hyppäävän ketterälle kelkkaan. Ei välttämättä kokonaan; He voivat aloittaa parilla pilottiprojektilla osoittaakseen, että se toimii, mutta jotkut ovat edelleen hyvin perinteisiä ja pitävät kiinni vesiputousmenetelmästä. Nyt hyvä uutinen on tietenkin, että työkalut toimivat erittäin hyvin myös organisaatioissa, ja myös kyseisen tyyppisille metodologeille, mutta meillä on työkalun mukautettavuus niin, että aluksella hyppääjillä on työkalut työkalupakissa osoitteessa heidän sormenpäänsä. Esimerkiksi vertailu ja yhdistäminen, esimerkiksi käänteisen suunnittelun ominaisuudet, jotta he voivat nähdä, mitä nykyiset tietolähteet ovat, joten he voivat tosiasiallisesti vertailla ja tuottaa DDL-lisäkomentoja nopeasti. Ja kun he alkavat omaksua tämän ja huomaavat, että heillä voi olla tuottavuus, heidän taipumuksensa omaksua ketterää kasvaa entisestään.
Eric Kavanagh: No, tämä on hienoa kamaa, ihmiset. Lähetin juuri linkin dioihin siellä chat-ikkunaan, joten tarkista se; se on vähän vähän täällä sinulle. Meillä on kaikki nämä verkkolähetykset myöhempää tarkastelua varten. Voit jakaa ne ystävien ja työtovereiden kanssa. Ja Ron, kiitos paljon tänään käymästäsi ajasta, olet aina miellyttävä olla näyttelyssä - todellinen alan asiantuntija ja on selvää, että tiedät tavarasi. Joten, kiitos teille ja kiitokset IDERalle ja tietysti Dezille ja omalle Robin Bloorillemme.
Ja sen kanssa me jätämme jäähyväiset, ihmiset. Kiitos vielä aikaa ja huomiosta. Arvostamme, että pysyt 75 minuutin ajan, se on melko hyvä merkki. Hyvät show-kaverit, puhumme kanssasi seuraavan kerran. Hei hei.
