Ottaa mukaan: Isäntä Eric Kavanagh keskustelee datan mallinnuksen 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. Sen keskiviikko klo 4:00 EST. Tämä tarkoittaa sen aikaa Hot Technologiesille. Todellakin. Nimeni on Eric Kavanagh, minä olen sinun isäntäsi.
Nykypäivän aiheeseen, se on vanha, mutta hyvä. Se paranee joka päivä, koska se muotoilee tiedonhallintamaailmaamme, ”Data Modeling in Agile Environment”. The dia dio itsestäsi, lyö minut @eric_kavanagh-sivulle. Meidän pitäisi todella laittaa se tuolle dialle. Minun on päästävä siihen.
Joten vuotta kuuma. Tietojen mallinnus on ollut olemassa ikuisesti. Se on todella ollut tietohallintoyrityksen ydin ja sielu, suunnitellessaan datamalleja, yrittäessään ymmärtää liiketoimintamalleja ja sovittaa ne tietomalleihisi. Että todella yrität tehdä, eikö niin?
Tietomalli edustaa yritystä perustavanlaatuisella tavalla, joten kuinka nämä uudet tietolähteet muuttavat peliä? Aioimme saada selville siitä. Halusimme selvittää, kuinka voit pysyä asioiden päällä ketterästi. Ja tietenkin, se on vuoden sana.
Robin Bloors kanssamme, pääanalyytikomme, Dez Blanchfield soittaen Sydneystä, Australiasta ja Ron Huizenga, vanhempi tuotepäällikkö IDERAsta - pitkäaikainen ystäväni, erinomainen puhuja tällä alueella, tietää hänen asiat, joten älä ole ujo, kysy häneltä 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 katsoimme 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ä yleensä teemme, olen minä ja Dez puhumme eri asioista ja ajattelin vain, että annan yleisen yleiskuvan mallinnukselle, mutta tässä on totta, mikä on nyt ilmeistä.
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 siellä on suurempi tarve ymmärtää tietoja ja lisääntynyt muutosnopeus, koska dataa lisätään enemmän ja samalla käytetään enemmän tietorakenteita.
Se on vaikea maailma. Tässä on kuva siitä, mikä on tosiasia, jota piirsimme noin kolme vuotta sitten, mutta pohjimmiltaan, kun sisällytät suoratoiston miksaukseen ja saat tämän idean tietojen jalostamisesta, tietokeskuksesta, tietolinkistä tai muusta, huomaat, että tieto on olemassa aidosti levossa siinä mielessä, että se ei liiku paljon. Ja sitten Theres, tiedot, streamit ja kaikki kaupalliset sovellukset ovat saaneet, samoin kuin nykyään sinulla tapahtumia, tapahtumien datavirtoja, jotka tapahtuvat sovelluksissa ja joita saattaa joutua tekemään, ja nykyään niiden lambda-arkkitehtuurien kanssa, joista ikinä kertovat puitteet, todella vaikuttavat vain koko tietokenttä.
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 kovin paljon vaikeuksia. Metatietojen on oltava siellä, mutta merkityksellä on rakenne. En halua mennä merkitysfilosofiaan, mutta jopa tapaan, jolla käsittelemme tietoa, on ihmisen ajatuksissa ja ihmiskielissä paljon hienostuneisuutta, joka ei ilmaise itseään helposti 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 yhdistetään muihin tietoja, vaatii mallintamaan sen. Se ei ole tarpeeksi hyvä vain tallentaa 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 näiden kerrosten välillä on epäjohdonmukaisuuksia, 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, se on todella vaikea vaihtaa. Se on tarpeeksi helppo saada metatiedot tietueen sisälle ja pystyä saamaan ne merkityssarjasta, mutta se ei kerro sinulle tietueiden rakennetta tai mitä tietueet tarkoittavat tai tietueen con.
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 lisättäisi maailmalle ei vain enemmän asioita, jotka vastaisivat tietueita, vaan lisäisivät tosiasiallisesti enemmän merkitystä maailmalle kaappaamalla tietoja yhä useammista asioista. Siitä on tulossa yhä monimutkaisempi tunne, joka meidän on ymmärrettävä.
Teoriassa on 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; sen jatkuva toiminta - sen tulisi olla jatkuva toiminta jokaisessa ympäristössä, jossa he ovat. Onneksi on olemassa monia ympäristöjä, joissa näin ei todellakaan ole ja asiat loistuvat käsistä 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, vaikkakin se otti käyttöön uusia ulottuvuuksia: sijainnin ulottuvuuden mobiililaitteilla. Kun olet päässyt Internetiin, tarkastelimme poikkeuksellisia tietoongelmia, joita meidän ei koskaan tarvinnut tehdä ennen, ja meidän on tavalla tai toisella ymmärrettävä oikein, mitä meillä on, kuinka voimme koota sen, mitä voimme tehdä kannalta merkityksen saaminen aggregaatiosta ja tietysti mitä voimme tehdä siihen, kun käsittelemme sitä.
Minusta tuntuu, että olen sanonut tarpeeksi. Aion siirtää Dez Blanchfieldille, sanon 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 otoista, enkä halua varastaa tämän nimenomaista ukkosta, mutta yksi esittelynäyttelijältämme tekemistä takeista, jotka haluan jakaa, jos et saanut sitä kiinni, oli vain tietomatkan aiheen ympärillä. , ja se sai minut todella kirjoittamaan sen ajatellen matkaa, jonka tiedot kuluttavat eri tavalla sukupolvien elinaikana - vuosi, kuukaudet, viikko, päivä, tunti, minuutti, sekunti - ja datan ympärillä olevat con sijaitsevat siinä con . Onko kyse koodin kehittäjästä vai onko tietospesialisti ja ajattelen kunkin elementin rakennetta ja muotoa ja metatietoja tai tapaa, jolla järjestelmät ja yritys ovat vuorovaikutuksessa sen kanssa.
Se on mielenkiintoinen pieni takea vain huomautuksen suhteen, mutta annan kuitenkin sukeltaa 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 se ei ollut niin kauan sitten, että kehittäjät ja data-asiantuntijat työskentelivät yksin; ne olivat omissa siiloissaan ja suunnittelupalvelut siirtyivät siilosta toiseen. Mutta olen erittäin mieltä näistä päivistä, että paitsi, että muuttuu, 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 ympärillä olevat pisteet, mikä riippuu siitä, mikä sinulla oli, tai älä tee toista osaa, 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 organisaation siirron 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 pintapäälliköistä, jotka valvovat koko tätä asiaa ja ymmärtävät metodologian riittävän hyvin sen johtamiseksi. Olemme kaikki nähneet nämä kuvat, jotka sain 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 vie luettelon asioista, jotka organisaatio haluaa tehdä, suorittaa ne läpi joukon kutsumme ss-asioita, 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, yhtä aikaa.
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, sillä olen hyvin sitä mieltä, että tietosuoja-asiantuntijoiden on - ei pitäisi - olla nyt läheisesti mukana kaikissa hankkeen toimittamisessa, todellakin, etenkin kehitystyössä. 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 tietokannan 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ä, kuinka data tulee ja miten matkan järjestäminen 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 joihinkin yhteisiin haasteisiin, sanoen yksinkertaisesti sanottuna, kuuluu pelkkä perustietokannan luominen ja ylläpito sekä hallitseminen ydintietokannan suunnittelussa, tietojen ja tietokantainfrastruktuurin dokumentoiminen ja näiden tietoresurssien, kaavioiden uudelleenkäyttö 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ö myyntien nähdä kaikki taulukon tietueet vai pitäisikö heidän nähdä vain osoitteen, etunimen ja sukunimen, jonka postissa olet? 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 suunnata IDERAn hyvälle ystävällemme 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 asentanut lavan hyvin, ja näet hiukan päällekkäisyyttä parissa asioissa, 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 siitä, mistä puhun tänään, perustuu noihin kokemuksiin sekä näkemykseen työkaluista ja joistakin niiden työkalujen ominaisuuksista, joita me autamme meille matkan varrella. Aion käsitellä hyvin lyhyesti, en 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 datan mallinnuskonseptin organisaatioissamme, kun kyse on datan mallintajista, miten mallinntajat ja arkkitehdit osallistuvat projektiin, 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. Sitten teemme tiivistelmän vielä muutamasta seikasta ja meillä on lisäksi kysymyksiä ja vastauksia sen lisäksi.
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 yritysarkkitehti, jossa teemme prosessimallintamista ja ohjelmistoarkkitehti, 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ä arkistopohjaisia näkökohtia. 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, sellaisenaan, johon viitattiin aiemmassa esityksessä, on välttämätöntä, että meillä on tietomallinntajat ja / tai arkkitehdit täysin sitoutuneet ketteriin kehitysprosesseihin. Nyt se, mitä on historiallisesti 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 sellaisia, 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 kehityshankkeen yhteydessä, jossa kehitämme sovellusta, jonka tietysti myös siihen liittyvät tietokomponentit liittyvät. 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 saattavat jo olla 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ötyyli, jossa kehitämme asteittain sen komponentteja ja kehitämme sitä ajan mittaan, kun tuotamme käyttökelpoisia koodeja tai käyttökelpoisia esineitä, aion sanoa, jokaiselle s. Tärkeä asia on yhteistyö tiimin teknisten sidosryhmien ja yritysmaailman sidosryhmien välillä, kun teemme yhteistyötä hajottaaksemme nämä käyttäjän tarinat toteutettavissa olevaksi visioksi koodista ja sitä tukevasta tiedosta. Ja ketterä Data-mallinntaja itse huomaa usein, että meillä ei ole tarpeeksi mallintajia organisaatioissa, joten yksi tietomallintaja 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 mennä tämän läpi nopeasti, koska käsitelimme sitä jo edellisessä osassa. Ketterän todellinen lähtökohta on, että perustat asiat tyhjästä, tarinoista tai vaatimuksista. Toistojen sisällä teemme yhteistyötä ryhmänä. Tyypillisesti kahden viikon tai yhden kuukauden s, organisaatiosta riippuen, on hyvin yleistä. Ja myös päivittäiset tarkistukset 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 niissä ss haluamme varmistaa, että tuotamme käyttökelpoisia toimituksia osana jokaista s.
Vain hieman erilainen ottelu siihen, laajentamalla sitä edelleen, scrum on menetelmä, josta aion puhua tarkemmin täällä, ja olemme vain pohjimmiltaan lisänneet sitä edellistä kuvaa muutamilla muilla puolilla. Tyypillisesti siellä on tuotekanta ja sitten siellä on kanta. Joten meillä on yleinen taakka, jonka jokaisen toiston alussa sanomme: "Mitä me rakennamme tämän?" Ja se tehdään suunnittelukokouksessa. Sitten hajotamme siihen liittyvät tehtävät ja suoritamme yhden - neljän viikon ss noissa päivittäisissä arvosteluissa. 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 s: n 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, siellä on arvostelu lopussa ja retrospektiivinen, joten ennen seuraavan iteraation aloittamista tarkistat tekemäsi ja etsit tapoja, joilla voit parantaa seuraavan kerran läpi.
Suoritteiden kannalta tämä on pohjimmiltaan dia, jossa esitetään yhteenveto tyypillisistä asioista, jotka tapahtuvat ss: ssä. Ja se on erittäin 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 tutkittava, 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.
Jotkut sanovat, että meidän on tuotettava käyttökelpoinen koodi jokaisen kappaleen lopussa. Se ei välttämättä ole tilanne, se on puhtaimmassa kehitysnäkymässä, mutta melko usein - etenkin alussa - meillä voi olla jotain s nollan kaltaista, 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 meillä on s nolla tai jopa s nolla ja yksi. Voi olla hieman käynnistysvaihe, ennen kuin saavutamme täyden lennon ratkaisun toimittamisessa.
Puhutaanko tämän mallin 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, en tarkoita pelkästään relaatiotietokantoja, joita voimme käyttää, mutta 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äydellisen eritelmän, joten loogisen eritelmän siitä, mitä tämä tarkoittaa organisaation näkökulmasta, mitkä ovat fyysiset rakenteet sen suhteen, kuinka me tosiasiallisesti määrittelemme datan, sen väliset suhteet sinun tietokannat, referenssisysteemisi rajoitukset, 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 siitä tulee yhä yleisempiä, ovat esimerkiksi 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. Olen myös vanginnut asioita, kuten perustietoluokit, 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 kun oli paljon yhdessä diassa, aion käydä loput näistä läpi melko nopeasti.
Puhun nyt hyvin nopeasti siitä, mitä tietomallinnuslaite tekee näiden erilaisten vaiheiden läpi. Ensinnäkin, täysimääräinen osallistuja suunnittelutilaisuuksissa, joissa otamme käyttäjän tarinoita, sitoudumme siihen, mitä aiomme toimittaa niissä, 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 erilaiset 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 ehkä joku työskentelee sovelluksen aikataulutusosan parissa, voin jonkun muun työskennellä tilauksen tekemisessä, jossa teemme kaikki nämä asiat yhdellä kertaa, 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 oltava lähtötasolla, johon voimme palata, koska yksi niistä asioista, jotka meidän on kyettävä tekemään, on, olipa se sitten tai lopussa. useita ss, haluamme tietää mistä aloitimme ja on aina perustiedot tietää, mikä oli delta tai ero siitä, mitä tuotimme tietyssä s. 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 vaunusta tekemällä tietyn s ja otat ne myöhemmin ss.
Esimerkiksi, voit keskittyä tietorakenteisiin vain saadaksesi kehityksen sanomaan sanoa, että tilauksen kirjoituskappale, josta puhin. Myöhemmässä vaiheessa saatat palata takaisin ja täyttää tiedot kuten jotkut datasanakirjan dokumentaatioista joidenkin luomiesi esineiden ympärillä. Et aio täyttää tätä määritelmää yhdellä kertaa; 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 läpi tämän kaiken meidän laitteillemme, jotta saamme täydelliset datatoimitukset, täydelliset asiakirjat ja määritelmän kaikille tuottamistamme 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 nopeaa merkitystä asioiden saamisessa eteenpäin erilaisten kehitysryhmien kanssa, joiden kanssa työskentelemme.
Myös s-toiminnoissa 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 ylläpidettävä kurinalaisuutta, jolla varmistetaan, että meillä on kaikki oikeat rakenteet tietomallimme edetessä, mukaan lukien asiat, kuten nolla- ja ei nolla-arvot, viiterajoitukset, pohjimmiltaan tarkistusrajoitukset, kaikki nämä 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 mitä voimme tehdä tiedonmuodostajina - ja tämä on katkelma osasta tietomallia taustalla -, 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 tilannekuvia matkalla läpi, voimme aina verrata yhden päivän alkua toisen alkuun tai loppuun, jotta voimme nähdä täydellinen asteittainen muutos siihen, mitä annettiin tietyssä kehitysvaiheessa tai sarjassa ss.
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ä pidä 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 näissä 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 toimitukset, 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 liitettynä lukuisiin tietokoneisiin alueellamme, 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 käsite, 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, 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ä s loppuun, s käärimisen lopussa, minulla on paljon asioita, jotka minun on tehtävä, joita kutsun taloudenhoitoon seuraaville s. Jokainen luominen, jota kutsun nimeltään julkaisuksi - antaa minulle lähtökohdan sille, mikä minulla on nyt julkaisun lopussa. Joten se tarkoittaa, että on lähtötasoni 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 mihinkään tiettyyn loppupäähän muista, jotka 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 s: n alusta loppuun. Olen ehkä tarkistanut kokonaisen joukon inkrementaalisia komentosarjoja, mutta jos tarvitsen sitä, minulla on nyt skripti, jonka voin ottaa käyttöön muiden hiekkalaatikoiden seisomiseksi, jotta voin vain sanoa, että tämä oli sellainen, joka meillä oli yhden s alussa, paina sen läpi, rakenna tietokanta hiekkalaatikkona aloittaen seuraavista asioista ja voimme käyttää näitä asioita myös tekemään asioita, kuten standup QA -tapahtumat, ja viime kädessä tietysti haluamme siirtää muutoksemme tuotantoon, joten meillä on useita asioita meneillään samaan aikaan. Olemme jälleen täysin mukana suunnittelussa ja retrospektiivissä, retrospektiivit ovat todella opittuja oppeja ja se on erittäin tärkeää, koska voit mennä 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 seuraavan ss: n edetessä.
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äänteen, että noin puolitoista sisällä näimme valtavan lisäyksen luotavien ja rakennettavien kohteiden ja tietorakenteiden lukumäärään, koska tuotimme tiedon mallinnustyökalusta pikemminkin kuin kehittäjäkehysrakennusta. he olivat ympäristössä, ja he olivat oikein, koska heillä oli asianmukainen referenssieheys ja muut rakenteet, joita sillä pitäisi olla. 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 kurinalaisuuden kannattaja, mutta sinun on varmistettava, että sinulla on kaikkien oikeiden ryhmien taidot, jotka ovat mukana projektitiiminä, kun jatkat 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 kehitysmenetelmien kanssa ja minusta näyttää siltä, että täällä tekemäsi 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ä nollassa on mielestäni ehdottoman tärkeä, koska yrität todella saada toimitukset kiinnitettynä sinne. Ja jos et saa toimituksia kiinni, niin toimitukset muuttavat muotoa.
Se on, eräänlainen mielipiteeni. Se on myös mielipiteeni - minulla ei todellakaan ole mitään väitettä siitä ajatuksesta, että sinun on saatava tietomallinnus oikealle tietylle yksityiskohtaisuustasolle ennen kuin lähdät 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ämä taulukot. 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 neuvottelut 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 syntyy myös DDL: ssä. 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 siinä, että meillä oli 150 ihmistä rannalla joukkueessa ja toinen 150 resurssia offshore-joukkueessa, jotka tekivät yhteistyötä kahden viikon ajan 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 s 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 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, kutsutaan sitä, erittäin moderni huolenaihe, ja mielestäni on todella paljon työtä, joka, 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, lopulta et voinut.
Joka tapauksessa siirron Dezille, koska mielestäni minulla on ollut varattu aika. Dez?
Dez Blanchfield: Kyllä kiitos. Katson ja ajattelen koko tämän asian kautta, että puhumme ketterien näkemisestä, joita käytetään vihaan monin tavoin. Vaikka sillä 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 kyseisen kaavion, jossa oli vikoja ennen ja jälkeen tietojenmuodostimen osallistumisen. Melko usein, ja on ennakkokäsityksiä, etenkin jos asiat pyörivät siellä, missä se tehdään puhtaasti kehityksen näkökulmasta, sovellusten toimittamiseen osallistuvat näissä ketterissä projekteissa vain kehittäjät. 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 sitä, miltä tietorakenteet näyttävät", ja että mentaliteetti on kadonnut. 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 tässä 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 mieleen tulee, on se, että tiedätte, että monet keskusteluista, joita päivittäin käyn, koskevat tätä tavarajunaa, joka saapuu meille, eräänlaisena koneesta toiseen ja esineiden internetin. Ja jos ajattelemme, että meillä on nyt paljon tietoa nykyisestä yritysympäristöstämme, tiedät, jos jätämme yksisarviset sivuun hetkeksi, kun tiedämme, että Googlesilla ja s: llä ja Ubersilla on petatavua dataa, mutta perinteisessä yrityksessä puhumme vielä satoista teratavuista ja paljon datasta. Mutta tämä tavarajuna on tulossa mielestäni organisaatioihin, 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 tietojen 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ä me 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 näitä tietoja, vangitsemme ne, meidän on peruutettava ne, tarkastettava, mitä niissä on, olipa se sitten 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ä mitä 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 toista osaa on, älä tee sitä, koska kaiken tämän ulkoisen tiedon kuluttamisen kannalta voit 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 erottelemaan, syntetisoimaan, mallintamaan ja ymmärtämään. 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. Ainoa kysymys, jonka aion käsitellä, tuli herralta nimeltä Eric, ja olemme keskustelleet siitä yksityisesti. Olen juuri kysynyt hänen luvansa, jonka hän on antanut, kysyä sitä sinulta. Koska se johtaa mukavasti tähän, vain kietomiseen, koska olemme menossa 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: Tämä 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 erityiseen arvoon, jonka aiot rakentaa osana startup-yritystäsi, ja sinun ei todennäköisesti tarvitse olla kaiken asiantuntija, joten upea neuvo. Mutta paljon kiitoksia, loistava esitys. Todella hienoja vastauksia ja kysymyksiä. Eric, aion palata takaisin sinulle, koska tiedän, että olemme kuluneet kymmenen minuuttia ajan myötä, ja tiedän, että haluat pysyä lähellä aikamme ikkunoitamme.
Eric Kavanagh: Ei se mitään. 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 yhdessä ja sitten joutua suunnittelemaan uudelleen kolmesta tai neljään. Eikö tämä näytä haitalliselta? Kuinka voit välttää sellaista?
Ron Huizenga: Se on vain ketterän luonnetta, että et saa kaikkea aivan oikein tietyissä tilanteissa. Ja se on itse asiassa osa ketterän henkeä, on: työskentele sen kanssa - aiot tehdä prototyyppien tekemistä siinä missä työskentelet koodilla tietyissä kohdissa, 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 taitavinta.
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 etsiessään esimerkkejä ja olet osoittanut joitain kuvakaappauksia siitä, kuinka käytät tosiasiallisesti näitä asioita. Koko tämän prosessin 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 s-tyylinen lähestymistapa näkökulmastasi?
Ron Huizenga: Luulen, että näemme sen yhä enemmän. Tiedän, että sanoisin, luultavasti etenkin viimeisen 15 vuoden aikana, että olen nähnyt paljon enemmän ihmisten adoptiota tunnustamaan, että heidän on todella otettava käyttöön 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 avulla me jäämme jäähyväiset, ihmiset. Kiitos vielä aikaa ja huomiosta. Kiitos, että pysyt 75 minuutin ajan, se on melko hyvä merkki. Hyvät show-kaverit, puhumme sinulle seuraavan kerran. Hei hei.