Yritystoiminnallisen tietoarkkitehtuurin rakentaminen

Tekijä Techopedia Staff, 28. syyskuuta 2016

Takeaway: Isäntä Rebecca Jozwiak keskustelee tietoarkkitehtuuriratkaisuista OSTHUS: n Eric Little, ensimmäisen San Francisco -kumppanin Malcolm Chisholmin ja IDERA: n Ron Huizengan kanssa.

Et ole tällä hetkellä kirjautunut sisään. Kirjaudu sisään tai kirjaudu sisään nähdäksesi videon.

Rebecca Jozwiak: Hyvät naiset ja herrat, hei ja tervetuloa vuoden 2016 kuumaan teknologiaan. Keskustelemme tänään. ”Yritystoiminnallisen tietoarkkitehtuurin rakentaminen” on ehdottomasti kuuma aihe. Nimeni on Rebecca Jozwiak, olen tämän päivän webcast-palvelun isäntä. Teemme twiittiä, jolla on # HotTech16-hashtagi, joten jos olet jo Twitterissä, ota rohkeasti mukaan myös tähän. Jos sinulla on kysyttävää milloin tahansa, lähetä ne näytön oikeassa alakulmassa olevaan Q & A-paneeliin, niin varmistamme, että heille vastataan. Jos ei, varmistamme, että vieraamme saavat ne sinulle.

Joten tänään meillä on todella kiehtova kokoonpano. Paljon raskaita iskuja kanssamme tänään. Meillä on Eric Little, OSTHUS: n tietotekniikan johtaja. Meillä on Malcolm Chisholm, innovaatiojohtaja, joka on todella hieno nimike First San Francisco Partnersille. Ja meillä on IDERA: n vanhempi tuotepäällikkö Ron Huizenga. Ja IDERA on todella täydellinen tiedonhallinta- ja mallinnusratkaisu. Ja tänään hän antaa meille demon, kuinka hänen ratkaisunsa toimii. Mutta ennen kuin pääsemme siihen, Eric Little, välitän pallon sinulle.

Eric Little: Okei, kiitos paljon. Joten aion käydä läpi pari aihetta, jotka luulen liittyvän hiukan Ronin puheeseen ja toivottavasti asettavan vaiheen myös joillekin näistä aiheista, joillekin kysymyksille ja vastauksille.

Joten asia, joka kiinnosti minua IDERAn tekemästä on se, että mielestäni he huomauttavat oikein, että monimutkaiset ympäristöt ajavat nykyään todella paljon liikearvoja. Ja monimutkaisissa ympäristöissä tarkoitamme monimutkaisia ​​tietoympäristöjä. Ja tekniikka todella liikkuu nopeasti ja on vaikea pysyä ajan tasalla nykyisessä liiketoimintaympäristössä. Joten ne, jotka työskentelevät teknologiatiloissa, näkevät usein, että sinulla on asiakkaita, jotka selvittävät ongelmia: ”Kuinka voin käyttää suuria tietoja? Kuinka sisällyttää semantiikan? Kuinka yhdistää jotkut näistä uusista tavaroista vanhempiin tietoihini? "Ja niin edelleen, ja sellainen johtaa meidät nykyään näihin neljään isoihin tietoihin, jotka monet ihmiset ovat melko tuttuja, ja ymmärrän, että niitä voi olla enemmän kuin neljä Joskus - olen nähnyt jopa kahdeksan tai yhdeksän - mutta yleensä, kun ihmiset puhuvat isoista tiedoista tai jos puhut isoista tiedoista, katsot yleensä jotain, joka on sellaista yritysskaalaa. Ja niin ihmiset sanovat: okei, hyvin, ajattele tietosi määrää, johon yleensä keskitytään - juuri niin paljon sinulla on. Tietojen nopeus liittyy joko siihen, kuinka nopeasti voin liikuttaa sitä tai kuinka nopeasti voin kysellä sitä tai saada vastauksia jne. Ja henkilökohtaisesti uskon, että vasemmalla puolella on jotain, joka on ratkaistu ja hoidettu suhteellisen nopeasti monien erilaisten lähestymistapojen avulla. Mutta oikealla puolella näen paljon parannuskykyä ja paljon uutta tekniikkaa, joka on todella tulossa etualaan. Ja sillä on todella tekemistä kolmannen sarakkeen, tietolajin kanssa.

Joten toisin sanoen suurin osa yrityksistä tarkastelee nykyään jäsenneltyä, osittain jäsentämätöntä ja jäsentämätöntä tietoa. Kuvatiedoista on tulossa kuuma aihe, joten kun pystyt käyttämään tietokonenäkymää, katselemaan pikseliä, kykenemään raaputtamaan tekstiä, NLP: tä, entiteetin poimimista, sinulla on kuvaajatietoja, jotka ovat tulossa joko tilastollisista malleista tai semanttisista. malleja, sinulla on relaatiotietoja, jotka ovat olemassa taulukoissa, ja niin edelleen. Ja niin, että kaikkien näiden tietojen yhteenvetäminen ja kaikki nämä erityypit edustavat todella suurta haastetta, niin näet sen Gartnerissa ja muissa ihmisissä, jotka seuraavat tavallaan alan suuntauksia.

Ja sitten viimeinen asia, josta ihmiset puhuvat isoissa tiedoissa, on usein tämä käsitys vääryydestä, joka on oikeastaan ​​tietosi epävarmuus, sen epäselvyys. Kuinka hyvin tiedät, mistä tiedoista on, kuinka hyvin ymmärrät mitä siellä on ja tiedätkö? Kyky käyttää tilastoja ja kyky käyttää tietyn tyyppistä tietoa ympärilläsi, mitä ehkä tiedät, tai käyttää jotain kontekstia, voi olla arvokas siellä. Ja siten kyky tarkastella tietoja tällä tavalla suhteessa siihen, kuinka paljon sinulla on, kuinka nopeasti sinun on siirrettävä sitä ympäri tai saatava sitä, kaikenlaisia ​​tietoja, joita sinulla voi olla yrityksessäsi, ja kuinka varmaa olet missä se on, mikä se on, mitä laatua se on ja niin edelleen. Tämä vaatii todella suuria, koordinoituja ponnisteluja useiden ihmisten välillä, jotta he hallitsevat tietojaan tehokkaasti. Siksi datan mallinnus on yhä tärkeämpää nykymaailmassa. Joten hyvät tietomallit johtavat todella menestykseen yrityssovelluksissa.

Sinulla on tietolähteitä monista lähteistä, kuten sanoimme, mikä todella vaatii paljon erilaisia ​​integraatioita. Joten kaiken vetäminen yhteen on todella hyödyllistä, jotta pystymme suorittamaan kyselyitä esimerkiksi useille tietolähteille ja vetämään tietoja takaisin. Mutta jotta voit tehdä niin, tarvitset hyviä kartoitusstrategioita, joten tällaisten tietojen kartoittaminen ja niiden seuraaminen voi olla todellinen haaste. Ja sitten sinulla on tämä kysymys, kuinka voin linkittää vanhat tietoni kaikkiin uusiin tietolähteisiin? Oletetaanko, että minulla on kuvaaja, otanko kaikki relaatiotietoni ja laitan sen kuvaajaan? Yleensä se ei ole hyvä idea. Joten miten se on, että ihmiset kykenevät hallitsemaan kaikkia tällaisia ​​meneillään olevia tietomalleja? Analyysi on todella suoritettava monille tällaisille tietolähteille ja yhdistelmille. Joten tästä tulevat vastaukset, vastaukset, jotka ihmisten täytyy todella tehdä hyviä liiketoimintapäätöksiä, ovat kriittisiä.

Joten kyse ei ole pelkästään rakennustekniikasta tekniikan vuoksi, se on oikeastaan ​​se, mitä aion tehdä, mitä voin tehdä sillä, millaista analyysiä voin suorittaa, ja siten kykyyn, kuten olen jo Olen puhunut siitä, että näiden juttujen yhdistäminen ja integroiminen on todella tärkeää. Ja yksi näistä analyysityypeistä suoritetaan sitten esimerkiksi hajautetulle haulle ja kyselyille. Siitä on todella tulossa pakollinen. Kysymyksesi on normaalisti liitettävä monenlaisiin lähteisiin ja saatava tiedot takaisin luotettaviksi.

Yksi tärkeä tekijä, joka usein, etenkin ihmiset, aikoo tarkastella tärkeimpiä asioita, kuten semanttista tekniikkaa, - ja tästä toivon Ronin puhuttavan vähän IDERA-lähestymistavassa - on miten erotat tai hallitset mallikerros tietosi itse tietokerroksesta, siitä raa'asta tiedosta? Joten alakerrassa tietokannasta, sinulla voi olla tietokantoja, sinulla voi olla asiakirjadataa, sinulla voi olla laskentataulukkotietoja, sinulla voi olla kuvatietoja. Jos olet sellaisilla aloilla kuin lääketeollisuus, sinulla on valtavia määriä tieteellistä tietoa. Ja tämän lisäksi ihmiset yleensä etsivät tapaa rakentaa malli, jonka avulla he voivat nopeasti integroida kyseiset tiedot. Kun etsit tietoja nyt, et halua vetää kaikkia tietoja mallikerrokseen, mitä tarvitset mallikerroksessa tehtäväksi, on antaa sinulle hieno looginen esitys siitä, mitä asiat ovat, yleisiä sanastoja, yleisiä tyyppejä kokonaisuuksia ja suhteita sekä kykyä päästä tietoihin tosissaan, missä se on. Joten sen on sanottava, mikä se on, ja sen on sanottava, missä se on, ja sen on sanottava, kuinka mennä hakemaan ja palauttamaan se.

Joten tämä on ollut lähestymistapa, joka on onnistunut melko hyvin ajamaan semanttisen tekniikan eteenpäin, mikä on ala, jolla työskentelen paljon. Joten kysymys, jonka halusin esittää Ronille ja joka mielestäni on hyödyllistä Q & A-osiossa, on nähdä, kuinka IDERA-alusta toteuttaa tämän? Joten onko mallikerros todella erillinen tietokerroksesta? Ovatko he integroituneempia? Kuinka se toimii ja mitkä ovat tuloksia ja etuja, joita he näkevät lähestymistapaansa? Siksi vertailutiedoista on todella tulossa myös kriittisiä. Joten jos sinulla on tällaisia ​​tietomalleja, jos pystyt yhdistämään ja etsimään asioita, sinulla on todella oltava hyvät viitetiedot. Mutta ongelma on vertailutiedoissa, joita voi olla todella vaikea ylläpitää. Joten standardien nimeäminen itsessään on usein vaikea haaste. Yksi ryhmä kutsuu jotain X ja yksi ryhmä kutsuu jotain Y ja nyt sinulla on ongelma, kuinka joku löytää X ja Y etsiessään tämän tyyppisiä tietoja? Koska et halua antaa heille vain osaa tiedoista, haluat antaa heille kaiken siihen liittyvän. Samanaikaisesti ehdot muuttuvat, ohjelmistot vanhenevat ja niin edelleen, kuinka voit pitää yllä ja ylläpitää tätä vertailutietoa ajan myötä?

Ja jälleen, semanttinen tekniikka, joka käyttää erityisesti taksonomioita ja sanastoja, datasanakirjoja, on tarjonnut standardin avaruustavan tehdä tämä, joka on todella vahva, siinä käytetään tietyntyyppisiä standardeja, mutta tietokantayhteisö on tehnyt tämän myös pitkään, vain eri tavoin. Mielestäni yksi avaimista tässä on miettiä, kuinka käyttää kenties kokonaisuussuhdemalleja, kuinka käyttää esimerkiksi kuvaajamalleja tai jonkin tyyppistä lähestymistapaa, joka todella antaa sinulle toivottavasti vakiovälisen tavan käsitellä viitetietojasi. Ja sitten tietysti kun sinulla on viitetiedot, kartoitusstrategioissa on hallittava monenlaisia ​​nimiä ja entiteettejä. Joten aiheen asiantuntijat haluavat usein käyttää omia termejään.

Joten haaste tässä on aina, miten annat jollekin tietoa, mutta tee siitä merkityksellinen tapa, jolla he puhuvat siitä? Joten yhdellä ryhmällä voi olla yksi tapa katsoa jotain, esimerkiksi saatat olla kemisti, joka työskentelee huumeen suhteen, ja voit olla rakennebiologi, joka työskentelee saman lääkkeen kanssa, ja sinulla voi olla eri nimet samantyyppisille kokonaisuuksille. jotka liittyvät alaasi. Sinun on selvitettävä tapoja tuoda henkilökohtaiset terminologiat yhteen, koska toinen lähestymistapa on, sinun on pakotettava ihmiset luopumaan termiistään ja käyttämään jonkun muun termiä, josta he eivät usein pidä. Toinen asia tässä on, että suuren määrän synonyymien käsitteleminen on vaikeaa, joten monien ihmisten tiedoissa on paljon erilaisia ​​sanoja, jotka voivat viitata samaan asiaan. Sinulla on ongelma viitata siellä käyttämällä monenvälisiä suhteita. Erikoistermit vaihtelevat toimialoittain, joten jos keksit tällaisen tiedonhallinnan kokonaisratkaisun, kuinka helposti siirrettävissä se on yhdestä projektista tai sovelluksesta toiseen? Se voi olla uusi haaste.

Automaatio on tärkeää ja se on myös haaste. Viitetietojen manuaalinen käsittely on kallista. On kallista pitää pitää manuaalista kartoitusta, ja on kallista, jos aiheen asiantuntijat lopettavat päivittäisten töidensä tekemisen ja joutuvat menemään sisään ja korjaamaan jatkuvasti datasanakirjoja ja päivittämään määritelmiä uudelleen ja niin edelleen. Toistettavat sanastot osoittavat todella paljon arvoa. Joten ne ovat usein sanastoja, jotka löydät organisaation ulkopuolelta. Jos teet esimerkiksi raakaöljyä, siellä on tietyntyyppisiä sanastoja, joita voit lainata avoimen lähdekoodin tiloista, samoja lääkkeistä, samoja pankkisektorilla ja rahoituksesta, samoja monilla tällaisilla alueilla. Ihmiset asettavat sinne uudelleenkäytettäviä, yleisiä, toistettavia sanastoja ihmisten käytettäväksi.

Ja jälleen kerran, katsellen IDERA-työkalua, olen utelias näkemään, kuinka he käsittelevät tätä erilaisten standardien käytön kannalta. Semantiikkamaailmassa näet usein sellaisia ​​asioita kuin SKOS-mallit, jotka tarjoavat standardit ainakin laajemmalle / kapeammalle kuin suhteet ja näitä asioita voi olla vaikea tehdä ER-malleissa, mutta tiedätkö, ei mahdotonta, se riippuu vain siitä, kuinka suuri osa tästä koneet ja linkitys, jota pystyt käsittelemään tällaisissa järjestelmissä.

Joten viimein halusin vain tehdä vertailun joihinkin teollisuuden näkemiin semanttimoottoreihin, ja pyytää Ronia sitten hiukan puhumaan siitä, kuinka IDERA-järjestelmää on käytetty minkä tahansa semanttisen tekniikan yhteydessä. Pystyykö se integroimaan kolminkertaisiin kauppoihin, kuvaajatietokantoihin? Kuinka helppoa on käyttää ulkoisia lähteitä, koska sellaisia ​​asioita semanttisessa maailmassa voidaan usein lainata SPARQL-päätepisteiden avulla? Voit tuoda RDF- tai OWL-malleja suoraan malliisi - viitata niihin takaisin - niin esimerkiksi geeni-ontologia tai proteiini-ontologia, jotka voivat elää jossain omassa tilassa omalla hallintorakenteellaan ja voin yksinkertaisesti tuoda kaikki tai osa siitä, kun tarvitsen sitä omiin malleihini. Ja minua kiinnostaa tietää kuinka IDERA lähestyy tätä asiaa. Pitäisikö sinun ylläpitää kaikkea sisäisesti tai onko olemassa tapoja siirtyä käyttämään muun tyyppisiä standardimoituja malleja ja vetää ne sisään, ja miten tämä toimii? Ja viimeksi mainitsin tässä, kuinka paljon käsityötä todella tarvitaan sanastojen ja metatietovarastojen luomiseen?

Joten tiedän, että Ron aikoo näyttää meille joitain demoja tällaisista asioista, jotka ovat todella mielenkiintoisia. Mutta ongelmana, jota näen usein konsultoidessaan asiakkaiden kanssa, on se, että paljon virheitä tapahtuu, jos ihmiset kirjoittavat omia määritelmiään tai omia metatietoja. Joten saat kirjoitusvirheitä, saat rasvan sormen virheitä, se on yksi asia. Saat myös ihmisiä, jotka voivat ottaa jotain, tiedät vain, Wikipediasta tai lähteestä, joka ei välttämättä ole määritelmässäsi mahdollisesti haluamaasi laatua, tai määritelmäsi on vain yhden henkilön näkökulmasta, joten se ei ole täydellinen, ja se ei ole sitten selvää miten hallintoprosessi toimii. Hallinnointi on tietysti erittäin, erittäin suuri ongelma aina, kun puhutaan vertailutiedoista ja milloin tahansa puhutaan siitä, kuinka nämä sopivat jonkun perustietoihin, kuinka he aikovat käyttää metatietojaan, ja pian.

Joten halusin vain laittaa joitain näistä aiheista esiin. Nämä ovat kohteita, jotka näen liiketoiminta-alueella monien erilaisten konsultointiyritysten ja monien eri tilojen välillä, ja olen todella kiinnostunut siitä, mitä Ron aikoo näyttää meille IDERA: n kanssa osoittaakseen joitain näistä aiheista . Joten kiitos paljon.

Rebecca Jozwiak: Kiitos paljon, Eric, ja pidän kommenttistasi, että monia virheitä voi tapahtua, jos ihmiset kirjoittavat omat määritelmänsä tai metatietonsa. Tiedän, että journalismin maailmassa on mantra, että ”monet silmät tekevät vähän virheitä”, mutta kun kyse on käytännöllisistä sovelluksista, liian monet kädet keksepurkissa yleensä jättävät sinulle paljon rikkoutuneita evästeitä, eikö niin?

Eric Little: Kyllä, ja bakteereja.

Rebecca Jozwiak: Kyllä. Aion mennä eteenpäin ja välittää sen Malcolm Chisholmille. Malcolm, lattia on sinun.

Malcolm Chisholm: Paljon kiitoksia, Rebecca. Haluaisin tutkia jonkin verran sitä, mistä Eric on puhunut, ja lisätä eräänlaisiin huomioihin, joihin Ron, tiedätte, voi myös vastata, puhuessaan ”Kohti liiketoimintaohjattua tietoarkkitehtuuria” ”- mitä tarkoittaa olla yrityslähtöistä ja miksi se on tärkeää? Vai onko se vain jonkinlainen hype? En usko, että se on.

Jos tarkastelemme tapahtumia siitä lähtien, tiedätte, että keskusyksiköiden tietokoneet ovat todella olleet saatavissa yrityksille - sanoen noin vuonna 1964 - tänä päivänä, voimme nähdä, että muutoksia on tapahtunut paljon. Ja nämä muutokset, joita tiivistäisin, ovat siirtymät prosessikeskeisyydestä datakeskeisyyteen. Ja se tekee yrityslähtöisistä tietoarkkitehtuureista niin tärkeitä ja merkityksellisiä tänään. Ja luulen, että tiedät, että se ei ole vain sanasana, se on jotain aivan todellista.

Mutta voimme arvostaa sitä hiukan enemmän, jos sukellamme historiaan, joten ajatellen ajassa taaksepäin 1960-luvulle ja jonkin aikaa sen jälkeen mainframes hallitsivat. Sitten nämä antoivat tien tietokoneisiin, joissa olit tosiasiallisesti kapinoineet käyttäjiä tietokoneiden saapuessa sisään. Kapina keskitettyä IT: tä vastaan, joka heidän mielestään ei täytä heidän tarpeitaan, ei ollut riittävän ketterä. Se synnytti nopeasti hajautetun laskennan, kun tietokoneet yhdistettiin toisiinsa. Ja sitten Internet alkoi tapahtua, mikä hämärtti yrityksen rajoja - se voi nyt olla vuorovaikutuksessa itsensä ulkopuolella olevien osapuolten kanssa tiedonvaihdon suhteen, mitä ei ollut aiemmin tapahtunut. Ja nyt olemme siirtyneet pilvien ja suurten tietojen aikakauteen, jossa pilvi on alustoja, jotka todella hyödyntävät infrastruktuuria, ja joten me jäimme IT: n tarpeeseen ylläpitää suuria datakeskuksia, koska tiedätte, Olemme saaneet pilvikapasiteetin käytettäväksi ja samanaikaisesti sen suuren datan kanssa, josta Eric on, tiedätkö, niin kaunopuheisesti keskustellut. Ja kaiken kaikkiaan, kuten näemme, kun tekniikan muutos tapahtui, siitä on tullut datakeskeisempää, välitämme enemmän tiedosta. Kuten Internetissäkin, miten tietoja vaihdetaan. Suurella datalla neljä tai enemmän v-tiedostoja itsestään.

Samalla - ja mikä tärkeämpää - liiketoiminnan käyttötapaukset muuttuivat. Kun tietokoneet otettiin ensimmäisen kerran käyttöön, niitä käytettiin automatisoimaan esimerkiksi kirjoja ja levyjä. Ja kaikki mikä oli manuaalista prosessia, johon liittyivät pääkirjat tai vastaavat, ohjelmoitiin pääosin taloon. Se muutti 80-luvulla operatiivisten pakettien saatavuuteen. Sinun ei enää tarvinnut kirjoittaa omaa palkkasummaa, voit ostaa jotain, joka teki sen. Tämä johti moniin IT-osastoihin tuolloin huomattavaan supistamiseen tai rakenneuudistukseen. Mutta sitten liiketiedot, esimerkiksi tietovarastot, ilmestyivät, enimmäkseen 90-luvulla. Seurasi dotcom-liiketoimintamalleja, jotka olivat tietysti iso vimma. Sitten MDM. MDM: n avulla huomaat, että emme ajattele automaatiota; keskitymme tosiasiallisesti datan kuoraamiseen datana. Ja sitten analytiikka, joka edustaa arvoa, jonka voit saada pois tiedoista. Ja analytiikassa näet erittäin menestyviä yrityksiä, joiden ydinliiketoimintamalli pyörii datan ympärillä. Google, Twitter, Facebook olisivat osa tätä, mutta voisit väittää myös, että Walmart on.

Ja niin liiketoiminta on nyt todella ajatellut tietoja. Kuinka voimme saada arvoa tiedoista? Kuinka data voi ajaa yritystä, strategiaa, ja olemme datan kultakaudella. Joten ottaen huomioon, mitä tapahtuu tietoarkkitehtuurimme kannalta, jos tietoja ei enää pidetä pelkkänä pakokaasuna, joka tulee sovellusten loppupäästä, vaan joka on todella keskeinen liiketoimintamalleissamme? No, osa ongelmasta, joka meillä on tietotekniikan saavuttamisessa, on todella juuttunut järjestelmien kehityksen elinkaareen, joka johtui siitä, että jouduttiin nopeasti käsittelemään prosessiautomaatiovaihetta jo varhaisessa IT-iässä ja työskentelemään projektit on samanlainen asia. IT: lle - ja tämä on vähän karikatyyri -, mutta yritän sanoa, että jotkut esteet yrityslähtöisen tietoarkkitehtuurin saavuttamiselle johtuvat siitä, että olemme jonkin verran kriittisesti hyväksyneet tietotekniikan kulttuurin joka johtuu menneestä iästä.

Joten kaikki on projekti. Kerro vaatimuksesi yksityiskohtaisesti. Jos asiat eivät toimi, se johtuu siitä, ettet kertonut minulle vaatimuksiasi. No, se ei toimi tänään datan kanssa, koska emme aloita automaattisilla manuaalisilla prosesseilla tai, tiedätkö, liiketoimintaprosessien teknisellä muuntamisella, aloitamme hyvin usein jo olemassa olevilla tuotetiedoilla, joita yritämme saada arvo pois. Mutta kukaan, joka sponsoroi datakeskeistä projektia, ei todellakaan ymmärrä näitä tietoja perusteellisesti. Meidän on tehtävä tietojen löytäminen, lähdetietojen analyysi. Ja se ei oikeastaan ​​vastaa järjestelmän kehitystä, tiedätte - vesiputous, SDLC-elinkaari - joista Agile, väittäisin, on eräänlainen parempi versio siitä.

Ja mihin keskitytään, on tekniikka ja toiminnallisuus, ei data. Esimerkiksi, kun teemme testausta testausvaiheessa, niin yleensä tulee, toimiiko toiminnallisuuteni, sanotaan esimerkiksi ETL, mutta emme testaa tietoja. Emme testaa oletuksiamme lähdetietojen saapumisesta. Jos tekisimme, olisimme ehkä paremmassa kunnossa ja olisin kiitollinen siitä, että joku, joka on tehnyt tietovarastoprojekteja ja kärsinyt alkuvaiheen muutoksista ja lyönyt ETL-luetteloni. Ja itse asiassa se, mitä haluamme nähdä, on testaus alkuvaiheena jatkuvalle tuotantotietojen laadunvalvonnalle. Joten meillä on täällä paljon asenteita, joissa on vaikeaa saavuttaa yrityslähtöistä tietoarkkitehtuuria, koska meitä ehtii prosessikeskeisyyden aikakausi. Meidän on siirryttävä tietokeskeisyyteen. Eikä tämä ole kokonainen siirtymä, tiedätkö, siellä on vielä paljon prosessityötä, mutta emme oikein ajattele tietokeskeisissä olosuhteissa, kun meidän on tarpeen, ja olosuhteisiin, jotka tapahtuvat, kun olemme todella pakko tehdä niin.

Nyt yritys ymmärtää tietojen arvon, he haluavat avata tiedot, joten miten aiomme tehdä sen? Joten miten teemme siirtymisen? Asetamme datan kehitysprosessien ytimeen. Ja annamme liiketoiminnan johtaa tietovaatimuksilla. Ja ymmärrämme, että kukaan ei ymmärrä olemassa olevaa lähdetietoa projektin alkaessa. Voisit väittää, että tietorakenne ja itse tieto pääsivät sinne tietotekniikan ja vastaavasti toimintojen kautta, joten meidän pitäisi tietää se, mutta oikeasti, emme. Tämä on datakeskeistä kehitystä. Joten meidän on ajatellessamme missä ja miten me mallinnemme datakeskeisessä maailmassa, meillä on oltava palautussilmukoita käyttäjille heidän tietotarpeidensa parantamiseksi, kun teemme tiedonhakua ja tietojen profilointia, ennakoida lähdetietojen analysointia, ja kun saamme vähitellen entistä enemmän varmuutta tiedoistamme. Ja nyt puhun perinteisemmästä projektista, kuten MDM-keskitin tai tietovarasto, ei välttämättä isoista dataprojekteista, vaikkakin tämä on edelleen mielestäni melko lähellä sitä. Ja niin, että palautteen silmukoihin sisältyy tietomallinntajat, tiedätte, asteittain etenevän tietomallinsa kanssa ja toimimalla vuorovaikutuksessa käyttäjien kanssa varmistaakseen, että tietovaatimuksia tarkennetaan perustuen siihen, mikä on mahdollista, mitä käytettävissä, lähdetiedoista, kun he paremmin ymmärtävät sitä, joten kyse ei enää ole siitä, että tietomalli olisi, sellaisena kuin sitä ei ole olemassa tai täysin valmis, se on asteittainen keskittyminen siihen.

Samoin myöhemmässä vaiheessa meillä on laadunvarmistus, jossa kehitämme sääntöjä tietojen laadun testaamiseen varmistaaksemme, että tiedot ovat parametrien sisällä, joista oletamme. Mennessä sisään Eric viittasi vertailutietojen muutoksiin, joita voi tapahtua. Et halua olla sellaisenaan hallitsemattoman muutoksen jatkokäyttäjä tällä alueella, joten laadunvarmistussäännöt voivat mennä tuotannon jälkeiseen jatkuvaan tietojen laadun seurantaan. Joten voit alkaa nähdä, olemmeko tietokeskeisiä, miten datakeskeinen kehitys tapahtuu aivan eri tavalla kuin toimintopohjainen SDLC ja ketterä. Ja sitten meidän on kiinnitettävä huomiota myös yritysnäkymiin. Meillä on - ja tämä toistaa jälleen sitä, mitä Eric sanoi - meillä on tietomalli, joka määrittelee tietokannan tietojutun suunnitelman, mutta samalla tarvitsemme niitä käsitteellisiä malleja, niitä liiketoiminnallisia näkemyksiä tiedoista, joita perinteisesti ei ole tehty menneisyys. Luulemme joskus ajatellut, että tietomalli voi tehdä kaiken, mutta meillä on oltava käsitteellinen näkymä, semantiikka ja tutkittava tiedot, esitettävä ne abstraktiokerroksen kautta, joka muuntaa tallennusmallin liiketoiminnaksi view. Ja jälleen kerran, kaikista asioista, joista Eric puhui semantiikan suhteen, tulee tärkeitä sen tekemiseksi, joten meillä on tosiasiallisesti ylimääräisiä mallinnustehtäviä. Se on mielestäni mielenkiintoista, jos olet tullut joukkoon tietomallinntajaksi kuten minäkin, ja taas jotain uutta.

Ja lopuksi haluaisin sanoa, että myös suuremman arkkitehtuurin on vastattava tätä uutta todellisuutta. Esimerkiksi perinteinen asiakas MDM on eräänlainen, okei, siirrämme asiakastietomme keskittimeen, jossa voimme, tiedämme, tehdä sen järkeväksi tosiasiallisesti tietojen laadun suhteen takakonttorisovelluksiin. Mikä liiketoimintastrategian kannalta on jonkinlainen haukotus. Tänään kuitenkin tarkastelemme asiakas MDM-keskittimiä, joissa on ylimääräisiä asiakasprofiilitietoja, ei vain staattista tietoa, jolla todella on kaksisuuntainen rajapinta asiakkaan transaktiosovelluksiin. Kyllä, he tukevat edelleen takakonttoria, mutta nyt tiedämme myös näistä asiakkaidemme käyttäytymisistä. Tämä on kalliimpaa rakentaa. Tätä on monimutkaisempi rakentaa. Mutta se perustuu liiketoimintaan tavalla, jolla perinteinen asiakas MDM ei ole. Olet suunnittelemassa liiketoimintaan suuntautumista yksinkertaisemmilla malleilla, jotka on helpompi toteuttaa, mutta yritykselle tämä on mitä he haluavat nähdä. Olemme todella uudella aikakaudella ja mielestäni on olemassa useita tasoja, joille meidän on vastattava liiketoiminnan ajamiseen tarkoitetulla tietoarkkitehtuurilla, ja mielestäni on erittäin jännittävä aika tehdä asioita.

Joten kiitos, takaisin sinulle Rebecca.

Rebecca Jozwiak: Kiitos Malcolm, ja minä todella nauttinut siitä, mitä sanoitte datamalleista, on annettava yritysnäkymä, koska tavallaan toisin kuin sanoitte, missä IT piti ohjat niin kauan ja se ei ole enää sellainen tapaus. että kulttuurin täytyy muuttua. Ja olen melko varma, että taustalla oli koira, joka oli kanssasi täysin samaa mieltä. Ja sen avulla aion siirtää pallon Ronille. Olen todella innoissani nähdäksesi demasi. Ron, lattia on sinun.

Ron Huizenga: Kiitos paljon ja ennen kuin siirrymme siihen, käydään läpi muutamia dioja ja sitten vähän demoa, koska kuten Eric ja Malcolm ovat huomauttaneet, tämä on erittäin laaja ja syvä aihe, ja sillä, mitä tänään puhumme, vain raaputaan sen pintaa, koska siinä on niin monia näkökohtia ja niin monia asioita, että meidän on todella otettava huomioon ja tarkasteltava yrityslähtöisen arkkitehtuurin perusteella. Ja lähestymistapanamme on tehdä todella siitä mallipohjaisesta ja saada todellista arvoa malleista, koska voit käyttää niitä viestintävälineenä sekä kerroksena muiden järjestelmien mahdollistamiseksi. Suoritatko palvelusuuntautunutta arkkitehtuuria tai muita asioita, mallista tulee todella tapahtuman elinehto, kaikki ympäröivät metatiedot ja yrityksessäsi olevat tiedot.

Se, josta haluan puhua, on kuitenkin melkein ottamassa tämän askeleen taaksepäin, koska Malcolm oli käsitellyt joitain ratkaisujen kehitystyön historiaa ja tällaista asiaa. Yksi tapa osoittaa, kuinka tärkeää on vakaan tietoarkkitehtuurin olemassaolo, on käyttötapaus, johon jouduin usein tapaamaan neuvotteluni ennen kuin aloin tuotejohtamisen roolissa, ja siis menin organisaatioihin tekevätkö ne liiketoiminnan muutosta tai vain vaihtavat joitain olemassa olevia järjestelmiä ja tällaista asiaa, ja kävi nopeasti ilmi, kuinka heikosti organisaatiot ymmärtävät omia tietojaan. Jos otat tietyn käyttötarkoituksen, kuten tämä, olitpa konsultti menossa tai ehkä kyse on henkilöstä, joka on juuri aloittanut organisaation perustamisen, tai organisaatiosi on rakennettu vuosien varrella hankkimalla erilaisia ​​yrityksiä, mitä lopetat up with on erittäin monimutkainen ympäristö nopeasti, sisältäen useita uusia tekniikoita, samoin kuin vanhaa tekniikkaa, ERP-ratkaisuja ja kaikkea muuta.

Joten yksi niistä asioista, jotka voimme todella tehdä mallinnuksellisella lähestymistavallamme, on vastata kysymykseen, kuinka voin ymmärtää tämän kaiken? Voimme todella alkaa kerätä tietoja yhdessä, joten yritys voi hyödyntää meillä oikein olevaa tietoa. Ja käy ilmi, mitä meillä on siellä noissa ympäristöissä? Kuinka voin käyttää malleja tarvittavien tietojen poistamiseen ja ymmärtää niitä paremmin? Ja sitten meillä on perinteiset metadatan tyypit kaikille erilaisille asioille, kuten relaatiotietomallit, ja olemme tottuneet näkemään esimerkiksi määritelmiä ja datasanakirjoja, tiedätte, tietotyyppejä ja tällaista asiaa. Entä entinen metatieto, jonka haluat kaapata, jotta sille todella annettaisiin vielä enemmän merkitystä? Kuten, mitkä entiteetit todella ovat ehdokkaita, joiden tulisi olla vertailutietoobjekteja, joiden tulisi olla päädatanhallintaobjekteja ja tämäntyyppisiä asioita ja sitoa ne yhteen. Ja miten tieto kulkee organisaation kautta? Tiedot kulkevat siitä, kuinka niitä kulutetaan sekä prosessin kannalta että myös tietolähteenä tiedon kulkemisen kautta yrityksemme ja kuinka se kulkee eri järjestelmien kautta tai tietovarastojen kautta, joten tiedämme Kun rakennamme I-ratkaisuja tai sellaisia ​​asioita, kulutamme tosiasiallisesti oikeat tiedot käsillä olevaan tehtävään.

Ja sitten on erittäin tärkeätä, miten saamme kaikki nämä sidosryhmät ja etenkin yritysryhmät toimimaan yhteistyössä, koska he antavat meille tiedon todellisen merkityksen. Yritykset omistavat tiedot päivän lopussa. He toimittavat määritelmät sanastoille ja asioille, joista Eric puhui, joten tarvitsemme paikan sitoa kaiken tämän yhteen. Ja tapa, jolla se tehdään, on tietomallinnus- ja tietovarastoarkkitehtuuriemme kautta.

Aion koskea muutamia asioita. Puhun ER / Studio Enterprise Team Editionista. Ensinnäkin puhun tietoarkkitehtuurituotteesta, jossa suoritamme tietojen mallintamista ja tällaista asiaa, mutta sarjassa on paljon muita komponentteja, joita kosketan vain hyvin lyhyesti. Näet yhden katkelman yritysarkkitehdista, jossa voimme tehdä käsitteellisiä malleja, mutta voimme myös tehdä liiketoimintaprosessimalleja ja sitoa nämä prosessimallit linkittääksemme todelliset tiedot, joita meillä on datamalleissamme. Se todella auttaa meitä yhdistämään tämän solmion. Ohjelmistoarkkitehdin avulla voimme tehdä lisäkonstrukteja, kuten joitain UML-mallinnuksia ja sellaisia ​​asioita, jotta voimme antaa tukilogiikan joillekin muille järjestelmille ja prosesseille, joista puhumme. Mutta erittäin tärkeätä liikkuessamme alas on meille arkisto ja tiimipalvelin, ja puhun siitä eräänlaisena kahden puolikkaana samaa asiaa. Varastointiin tallennetaan kaikki mallinnetut metatiedot ja kaikki liiketoiminnan metatiedot liiketoimintasanakirjojen ja -termien muodossa. Ja koska meillä on tämä arkistopohjainen ympäristö, voimme sitten ommella kaikki nämä eri asiat yhteen samassa ympäristössä ja sitten voimme tosiasiallisesti tarjota ne kuluttamiseen, ei vain teknisille ihmisille, vaan myös liikemiehille. Ja näin me todella aloitamme ajaa yhteistyötä.

Ja sitten viimeinen kappale, josta puhun lyhyesti, on, että kun kävelet näissä ympäristöissä, kyse ei ole vain tietokannoista, joita sinulla on. Sinulla on useita tietokantoja, tietovarastoja, sinulla on myös paljon, mitä kutsun, vanhoja esineitä. Ehkä ihmiset ovat käyttäneet Visioa tai muita kaavioita joidenkin asioiden kartoittamiseen. Ehkä heillä on ollut muita mallinnustyökaluja ja tällaista asiaa. Joten mitä me MetaWizardilla voimme tehdä, se on tosiasiallisesti purkaa osa kyseisestä tiedosta ja tuoda se malleihimme, saattaa se ajan tasalle ja pystyä käyttämään sitä, kuluttamaan sitä uudelleen nykyisellä tavalla sen sijaan, että se vain istuisi siellä. Siitä tulee nyt aktiivinen osa työskentelymallejamme, mikä on erittäin tärkeää.

Kun kävelet organisaatiossa, kuten sanoin, siellä on paljon erilaisia ​​järjestelmiä, paljon ERP-ratkaisuja, sopimattomia osastoratkaisuja. Monet organisaatiot käyttävät myös SaaS-ratkaisuja, joita myös hallitaan ja hallitaan ulkoisesti, joten emme hallitse tietokantoja ja kyseisiä asioita niiden isäntälaitteissa, mutta meidän on silti tiedettävä miltä nämä tiedot näyttävät ja tietysti sen ympärillä olevat metatiedot. Löydämme myös paljon vanhentuneita vanhoja järjestelmiä, joita ei ole puhdistettu sen projektiperusteisen lähestymistavan takia, josta Malcolm oli puhunut. On hämmästyttävää, kuinka organisaatiot viime vuosina kehittivät hankkeita, korvaavat järjestelmän tai ratkaisun, mutta vanhentuneiden ratkaisujen käytöstäpoistamiseen ei usein jää tarpeeksi projektin budjettia, joten nyt ne ovat vain matkalla. Ja meidän on selvitettävä, mistä voimme todella päästä eroon ympäristössämme, ja mitä hyödyllistä jatkaa. Ja se liittyy huonoon käytöstäpoistostrategiaan. Se on olennainen osa samaa asiaa.

Mitä me myös löydämme, koska kaikista näistä erilaisista ratkaisuista on rakennettu paljon organisaatioita, näemmekö paljon pisteestä pisteeseen -rajapintoja, joissa on paljon tietoa liikkuvan monissa paikoissa. Meidän on kyettävä rationalisoimaan se ja selvittämään se tietolähde, jonka aiemmin mainitsin lyhyesti, jotta meillä voisi olla johdonmukaisempi strategia, kuten palvelukeskeisen arkkitehtuurin, yrityspalvelulinja-autojen ja tällaisten asioiden hyödyntäminen oikean tiedon toimittamiseksi. julkista ja tilaa -tyyppiseen malliin, jota käytämme oikein koko liiketoiminnassamme. Ja sitten meidän on tietenkin vielä tehtävä jonkinlainen analyysi, käytämmekö tietovarastoja, tietokarttoja perinteisen ETL: n kanssa vai joitain uusia tietojärviä. Kaikki laskeutuu samaan asiaan. Se on kaikki tietoja, onko kyse iso tiedoista, onko kyse perinteisestä tiedosta relaatiotietokannoissa, meidän on koottava kaikki nämä tiedot yhteen, jotta voimme hallita sitä ja tietää, mitä käsittelemme kaikissa malleissamme.

Jälleen monimutkaisuus, jota aiomme tehdä, on se, että meillä on useita vaiheita, jotka haluamme pystyä suorittamaan. Ensinnäkin, kävelet sisään ja sinulla ei ehkä ole piirroksia siitä, miltä tämä tietomaisema näyttää. Tietojen mallinnustyökalussa, kuten ER / Studio Data Architect, aiot tehdä ensin paljon käänteistä suunnittelua osoittamalla ulos lähteistä tietolähteistä, tuomalla ne sisään ja sitomalla sitten ne yhteen edustavammaksi mallit, jotka edustavat koko yritystä. Tärkeää on, haluammeko pystyä hajottamaan nämä mallit myös liiketoimintalinjojen mukaan, jotta voimme suhtautua niihin pienemmissä paloissa, joihin liikemiehet voivat myös liittyä, ja liiketoiminta-analyytikoimme ja muihin sidosryhmiin, jotka työskentelevät sen päällä.

Nimeämisstandardit ovat erittäin tärkeitä, ja puhun siitä täällä parilla eri tavalla. Nimeämme normeja sen suhteen, miten nimitämme asioita malleissamme. Se on melko helppo tehdä loogisissa malleissa, joissa meillä on hyvä nimeämiskäytäntö ja hyvä datasanakirja malleillemme, mutta silloin näemme myös erilaisia ​​nimeämiskäytäntöjä monille näille fyysisille malleille, joita tuomme esiin. käännösinsinööri, melko usein näemme lyhennettyjä nimiä ja sellaista asiaa, josta puhun. Ja meidän on käännettävä nämä takaisin merkityksellisiksi englanniksi, jotka ovat merkityksellisiä yritykselle, jotta ymmärrämme, mitkä kaikki nämä tietopalat ovat, mitä meillä on ympäristössä. Ja sitten universaali kartoitus on se, kuinka me ompelemme ne yhteen.

Tämän lisäksi dokumentoimme ja määrittelemme tarkemmin, ja siinä voimme luokitella tietomme edelleen nimellä Liitteet, jonka avulla näytän sinulle pari dioa. Ja sitten sulkemalla silmukan, haluamme soveltaa tätä liiketoiminnan merkitystä, jossa sitoudumme liiketoimintaan liittyviin sanastoihin ja linkittää ne erilaisiin malliesineisiin, joten tiedämme, kun puhumme tietystä liiketoiminnasta, missä se on toteutettu tietoihimme koko organisaatiossa. Ja sitten viimeiseksi, olen jo puhunut siitä, että tarvitsemme kaiken tämän olevan arkistopohjaisia, ja siinä on paljon yhteistyö- ja julkaisukykyä, jotta sidosryhmämme voivat hyödyntää sitä. Aion puhua käänteissuunnittelusta melko nopeasti. Olen jo tavallaan antanut sinulle erittäin nopean korostuksen siitä. Näytän sen sinulle todellisessa esittelyssä vain näyttääkseni joitain asioita, joita voimme tuoda sinne.

Ja haluan puhua joistakin niistä erityyppisistä malleista ja kaavioista, jotka voisimme tuottaa tämän tyyppisissä tilanteissa. Ilmeisesti teemme käsitteellisiä malleja monissa tapauksissa; En aio viettää paljon aikaa siihen. Haluan todella puhua loogisista malleista, fyysisistä malleista ja erikoistyypeistä, joita voimme luoda. Ja on tärkeää, että pystymme luomaan nämä kaikki samaan mallipohjaan, jotta voimme ommella ne yhteen. Se sisältää ulottuvuusmalleja ja myös malleja, jotka hyödyntävät joitain uusia tietolähteitä, kuten NoSQL, jonka näytän sinulle. Ja mitä sitten tietolähdemalli näyttää? Ja kuinka me ompelemme nämä tiedot liiketoimintaprosessimalliin, siitä puhumme seuraavaksi.

Aion siirtyä mallinnusympäristöön täällä vain antaakseni erittäin korkean ja nopean yleiskuvan. Ja uskon, että sinun pitäisi voida nähdä näytöni nyt. Ensinnäkin haluan puhua vain perinteisestä tietomallista. Ja tapa, jolla haluamme järjestää mallit, kun tuomme niitä, on se, että haluamme pystyä hajottamaan ne. Joten mitä näet täällä vasemmalla puolella, meillä on loogiset ja fyysiset mallit tässä nimenomaisessa mallitiedostossa. Seuraava asia on, voimmeko hajottaa sen liiketoiminnan hajoamisia pitkin, joten siksi näet kansiot. Vaaleansiniset ovat loogisia malleja ja vihreät ovat fyysisiä malleja. Ja voimme myös porata, joten jos ER / Studiossa on liiketoiminnan hajoamista, voit mennä niin monta tasoa syvälle tai alimalleja kuin haluat, ja alemmilla tasoilla tekemäsi muutokset heijastuvat automaattisesti korkeammilla tasoilla. Joten siitä tulee erittäin voimakas mallinnusympäristö nopeasti.

Haluan huomauttaa, että on erittäin tärkeää aloittaa näiden tietojen kerääminen, jos meillä voi olla useita fyysisiä malleja, jotka vastaavat myös yhtä loogista mallia. Melko usein sinulla voi olla looginen malli, mutta fyysisiä malleja voi olla erilaisilla alustoilla ja tämäntyyppisillä asioilla. Ehkä yksi on SQL Server -ilmentymä siitä, ehkä toinen on Oracle-ilmentymä. Meillä on kyky sitoa kaikki tämä yhteen samassa mallinnusympäristössä. Ja jälleen kerran, mitä täällä on, on todellinen tietovarastomalli, joka voi taas olla samassa mallintamisympäristössä tai voimme olla sen arkistossa ja yhdistää myös erilaisiin asioihin.

Halusin näyttää teille tässä joitain muita asioita ja muita variantteja malleista, joihin pääsemme. Joten kun pääsemme tällaiseen perinteiseen datamalliin, olemme tottuneet näkemään tyypilliset entiteetit sarakkeiden ja metatietojen kanssa ja kyseisen tyyppiset asiat, mutta tämä näkökulma vaihtelee hyvin nopeasti, kun alamme käsitellä joitain näistä uudemmista NoSQL-tekniikoista, tai kuten jotkut ihmiset edelleen haluavat kutsua heitä, suuriin tietotekniikoihin.

Joten nyt sanotaan, että meillä on myös pesä ympäristössämme. Jos käännämme insinööriä pesän ympäristöstä - ja pystymme eteenpäin ja taaksepäin insinööriä Hivestä tällä täsmälleen samalla mallinnustyökalulla -, näemme jotain, joka on hiukan erilainen. Näemme siellä edelleen kaikki tiedot konstruktioina, mutta meidän TDL-luettelomme ovat erilaiset. Ne, jotka olet tottuneet näkemään SQL: n, mitä nyt näkisit, on Hive QL, joka on hyvin SQL-tyyppinen, mutta saman työkalun avulla voit nyt aloittaa työskentelyn eri komentosarjojen kielillä. Joten voit mallintaa tässä ympäristössä, tuottaa sen ulos pesäympäristöön, mutta yhtä tärkeätä on, että kuvaamassani skenaariossa voit kääntää sen kaiken perään ja ymmärtää sen ja aloittaa ompeleminen yhdessä .

Otetaan toinen, joka on vähän erilainen. MongoDB on toinen alusta, jota tuemme natiivisti. Ja kun aloitat tutustumisen JSON-tyyppisiin ympäristöihin, joissa sinulla on asiakirjavarastoja, JSON on erilainen eläin ja siinä on rakenteita, jotka eivät vastaa relaatiomalleja. Alat pian käsitellä käsitteitä, kuten sulautetut objektit ja upotetut objektiryhmät, kun aloitat kyselyn JSON: sta, eikä näitä käsitteitä ole olemassa perinteisessä relaatiomerkinnässä. Mitä olemme tehneet täällä, olemme todella laajentaneet merkintää ja luettelomme voidaksemme käsitellä sitä samassa ympäristössä.

Jos katsot täältä vasemmalta, kutsumme heitä objekteiksi sen sijaan, että näkisimme esimerkiksi kokonaisuuksia ja taulukoita. Ja näet erilaisia ​​merkintöjä. Näet täällä vielä tyypillisiä viittauslajeja, mutta nämä siniset entiteetit, jotka näen tässä tietyssä kaaviossa, ovat todella upotettuja objekteja. Ja me osoitamme erilaisia ​​kardinaliteetteja. Diamond-kardinaliteetti tarkoittaa, että se on esine toisella puolella, mutta yhden cardinality tarkoittaa, että meillä on julkaisijassa, jos seuraamme tätä suhdetta, meillä on upotettu osoiteobjekti. Kuuleessamme JSON: ta olemme havainneet, että se on täsmälleen sama esineiden rakenne, joka on upotettu suojelijaan, mutta se on todella upotettu objektien joukkoksi. Me näemme sen, ei vain itse liittimien kautta, mutta jos tarkastelemme todellisia kokonaisuuksia, huomaat, että näet osoitteet suojelijan alla, joka on luokiteltu myös kohteiden joukkoksi. Saat hyvin kuvailevan näkökulman siitä, kuinka voit tuoda sen esiin.

Ja taas, nyt se, mitä olemme toistaiseksi nähneet vain muutamassa sekunnissa, ovat perinteiset relaatiomallit, jotka ovat monitasoisia, voimme tehdä saman asian Hiven kanssa, voimme tehdä saman asian MongoDB: n ja muiden suurten tietolähteiden kanssa hyvin. Mitä voimme myös tehdä, ja aion vain näyttää tämän sinulle nopeasti, puhuin tosiasian tuomasta asioita muilta alueilta. Oletan, että tuon mallin tietokannasta tai suunnittelen sen, mutta tuon sen ulkoisista metatiedoista. Vain antaaksesi sinulle erittäin nopean näkökulman kaikista erityyppisistä asioista, joita voimme alkaa tuoda esiin.

Kuten näette, meillä on lukemattomia asioita, joilla pystymme tosiasiallisesti tuomaan metatiedot mallintamisympäristöömme. Alkaen esimerkiksi Amazon Redshiftistä, Cassandrasta, monista muista isoista tietoalustoista, joten näet paljon niistä luettelossa. Tämä on aakkosjärjestyksessä. Näemme paljon suuria tietolähteitä ja tällaista asiaa. Näemme myös paljon perinteisiä tai vanhempia mallinnusympäristöjä, joiden avulla metatiedot voidaan tosiasiallisesti tuoda läpi. Jos käyn läpi täällä - enkä aio viettää aikaa jokaiselle niistä -, näemme paljon erilaisia ​​asioita, joista voimme saada sen aikaan, mallinnusalustojen ja tietoalustojen suhteen. Ja jotain, joka on tässä yhteydessä erittäin tärkeätä ymmärtää, on toinen osa, jonka voimme tehdä, kun alamme puhua tietolähteestä. Enterprise Team Edition -sarjassa voimme myös kuulustella ETL-lähteitä, ovatko asiat kuten Talend tai SQL Server Information Services -kartat, voimme tosiasiallisesti tuo se myös aloittaaksesi myös datalinjakaaviomme ja piirtääksesi kuvan näissä muutoksissa tapahtuvasta. Kaiken kaikkiaan meillä on yli 130 näitä erilaisia ​​siltoja, jotka ovat tosiasiallisesti osa Enterprise Team Edition -tuotetta, joten se todella auttaa meitä kootamaan kaikki esineet nopeasti mallinnusympäristöön.

Viimeisenä, mutta ei vähäisimpänä, haluan puhua myös siitä, ettemme voi unohtaa sitä tosiasiaa, että tarvitsemme muun tyyppisiä rakenteita, jos teemme tietovarastoja tai kaikenlaista analytiikkaa. Haluamme silti kyvyn tehdä asioita, kuten ulottuvuusmalleja, joissa meillä on tosiasiat, ja meillä on ulottuvuudet ja tämäntyyppiset asiat. Yksi asia, jonka haluan näyttää myös sinulle, on, että metatiedoissamme voi olla myös laajennuksia, jotka auttavat meitä luokittelemaan mitkä ovat tyypit ja kaikki muu. Joten jos tarkastellaan esimerkiksi ulottuvuustietovälilehteä, esimerkiksi yhtä näistä, se havaitsee automaattisesti näkemänsä mallikuvan perusteella ja antaa sinulle lähtökohdan, onko sen mielestä ulottuvuus vai tosiasiapöytä. Mutta sen lisäksi, mitä voimme tehdä, on ulottuvuuksien sisällä ja meillä on jopa erityyppisiä ulottuvuuksia, joita voimme käyttää luokittelemaan tietoja myös tietovarastointityyppiseen ympäristöön. Niin erittäin tehokkaita ominaisuuksia, joiden kanssa me ompelemme tämän kokonaan.

Aion hypätä tähän, koska olen tällä hetkellä demoympäristössä ja näytän sinulle pari muuta asiaa, ennen kuin hyppään takaisin dioille. Yksi asioista, jotka olemme äskettäin lisänneet ER / Studio Data Architect -yritykseen, on se, että olemme joutuneet tilanteisiin - ja tämä on hyvin yleinen käyttötapa, kun työskentelet projekteissa - kehittäjät ajattelevat kohteiden suhteen, kun taas tietomme Mallinntajat ajattelevat yleensä taulukoita ja entiteettejä ja tällaista asiaa. Tämä on erittäin yksinkertainen tietomalli, mutta se edustaa muutamia peruskonsepteja, joissa kehittäjät tai jopa liike-elämän analyytikot tai yrityskäyttäjät voivat ajatella niitä erilaisina kohteina tai liiketoimintakonsepteina. Näiden luokittelu on tähän asti ollut erittäin vaikeaa, mutta mitä olemme tosiasiallisesti tehneet ER / Studio Enterprise Team Edition -versiossa, 2016 julkaisussa, onko meillä nyt käsite nimeltä Business Data Objects. Ja mitä me voimme tehdä, se antaa meidän kapseloida kokonaisuusryhmiä tai taulukoita todellisiksi liiketoimintaobjekteiksi.

Esimerkiksi, mitä meillä on tässä uudessa näkymässä, on ostotilauksen otsikko ja tilausrivi on nyt koottu yhteen, ne on kapseloitu esineeksi, ajattelemme niitä työn yksiköksi, kun jatkamme tietoja, ja yhdistämme ne, joten on nyt erittäin helppo yhdistää se erilaisiin yleisöihin. Ne ovat uudelleenkäytettäviä koko mallinnusympäristössä. Ne ovat todellinen esine, ei vain piirustusrakenne, mutta meillä on myös lisäetu, että kun todella kommunikoimme mallintamisen näkökulmasta, voimme valikoivasti romahtaa tai laajentaa niitä, jotta voimme tuottaa tiivistelmänä vuoropuheluista tiettyjen sidosryhmien yleisöjen kanssa, ja voimme tietysti myös pitää yksityiskohtaisemman kuvan kuin me täällä näemme enemmän tekniselle yleisölle. Se antaa meille todella hyvän viestintävälineen. Nyt näemme yhdistävän useita erilaisia ​​mallityyppejä, laajentamalla niitä liiketoimintadataobjektien käsitteeseen, ja nyt puhun siitä, kuinka me tosiasiallisesti lisäämme merkitystä tämäntyyppisille asioille ja kuinka ompelemme ne yhteen yleiset ympäristöt.

Yritän vain löytää WebExin täältä takaisin, jotta pystyn siihen. Ja siellä menemme takaisin Hot Tech-dioihin. Aion vain siirtää eteenpäin muutamia dioja täällä, koska olet jo nähnyt nämä itse malliesittelyssä. Haluan puhua standardien nimeämisestä nopeasti. Haluamme soveltaa ja valvoa erilaisia ​​nimeämisstandardeja. Mitä haluamme tehdä, on, että meillä on kyky tallentaa nimitystandardimallit arkistoihimme pohjimmiltaan rakentaaksesi tämä merkitys sanojen tai lauseiden tai jopa lyhenteiden avulla ja sitoa ne takaisin merkitykselliseen englanninkieliseen sanatyyppiin. Käytämme liiketoimintatermejä, lyhenteitä jokaiselle ja voimme määritellä tilauksen, tapaukset ja lisätä etuliitteet ja jälkiliitteet. Tyypillinen käyttötapa tähän on tyypillisesti silloin, kun ihmiset ovat luoneet loogisen mallin ja sitten todella siirtyneet luomaan fyysisen mallin, jossa he ovat saattaneet käyttää lyhenteitä ja kaikkea muuta.

Kaunis asia on se, että se on yhtä voimakas, jopa voimakkaampi käänteisesti, jos voimme vain kertoa, mitkä noista nimeämisstandardeista olivat joissain niistä fyysisistä tietokannoista, joita olemme kääntäneet, voimme ottaa nämä lyhenteet, muuttaa ne pidemmiksi sanoja ja tuo ne taaksepäin englanninkielisiin lauseisiin. Nyt voimme todella saada oikeita nimiä siitä, miltä tietomme näyttää. Kuten sanon, tyypillinen käyttötapaus on, että siirrymme eteenpäin, loogisesti fyysiseksi ja kartoitamme tietovarastot ja tämäntyyppiset asiat. Jos tarkastelet oikeanpuoleista kuvakaappausta, huomaat, että lähteiden nimistä löytyy lyhennettyjä nimiä, ja kun olemme käyttäneet nimeämisstandardimallia, meillä on tosiasiallisesti enemmän täydellisiä nimiä. Ja voisimme laittaa välilyöntejä ja kaikkea sellaista, jos haluamme, riippuen käytetyistä nimestandardimalleista. Voimme näyttää siltä, ​​että haluamme sen saavan esiin malleissamme. Vasta kun tiedämme, mitä jotain kutsutaan, voimme tosiasiallisesti aloittaa määritelmien liittämisen siihen, koska kuinka voimme soveltaa siihen merkitystä, ellei tiedä mikä se on?

Hieno asia on, voimmeko todella vedota tähän, kun teemme kaikenlaisia ​​asioita. Puhuin käänteissuunnittelusta, voimme tosiasiassa vedota nimeämisstandardimalleihin samanaikaisesti, kun teemme käänteistä suunnittelua. Joten yhdessä vaiheessa ohjatun toiminnon avulla voimme tehdä, jos tiedämme, mitkä sopimukset ovat, voimme kääntää fyysisen tietokannan suunnittelijaksi, se aikoo palauttaa sen fyysisinä malleina mallinnusympäristössä ja se on aion myös soveltaa näitä nimeämiskäytäntöjä. Joten näemme, mitkä englanninkieliset nimien esitykset ovat vastaavassa loogisessa mallissa ympäristössä. Voimme myös tehdä sen ja yhdistää sen XML Schema -generaation kanssa, jotta voimme ottaa mallin ja jopa työntää sen pois lyhenteillämme, olimme sitten tekemässä SOA-kehyksiä vai tällaista asiaa, joten voimme sitten työntää pois myös erilaisia ​​nimeämiskäytäntöjä jonka olemme itse tallentaneet malliin itse. Se antaa meille paljon erittäin tehokkaita ominaisuuksia.

Tässä on jälleen esimerkki siitä, miltä se näyttää, jos minulla olisi malli. Tämä osoittaa tosiasiallisesti, että minulla oli EMP ”työntekijälle”, SAL ”palkalle”, PLN ”suunnitelmalle” nimeämisstandardien yhteydessä. Voin myös soveltaa niitä toimimaan vuorovaikutteisesti, kun rakennan malleja ja asennan asioita. Jos käyttäisin tätä lyhennettä ja kirjoitin kokonaisuuden nimeen ”Työntekijän palkkaohjelma”, se toimisi nimeämisstandardimallin avulla. Olen määritellyt täällä, se olisi antanut minulle EMP_SAL_PLN, kun olen luonut entiteettejä ja antanut minulle vastaavat fyysiset nimet heti.

Jälleen erittäin hyvä, kun suunnittelemme ja eteenpäin myös suunnittelua. Meillä on hyvin ainutlaatuinen konsepti, ja täällä todella aloitamme näiden ympäristöjen yhdistämisen. Ja sen nimi on Universal Mappings. Kun olemme tuoneet kaikki nämä mallit ympäristöömme, mitä pystymme tekemään, olettaen, että olemme nyt soveltaneet näitä nimeämiskäytäntöjä ja että niitä on helppo löytää, voimme nyt käyttää konstruktiota nimeltä Universal Mappings ER /Studio. Voimme linkittää kokonaisuuksia malleihin. Missä näemme “asiakkaan” - meillä todennäköisesti on “asiakas” monissa erilaisissa järjestelmissä ja paljon eri tietokannoissa - voimme alkaa linkittää kaikki nämä yhteen siten, että kun työskentelen sen kanssa yhdessä mallissa näkee, missä muissa malleissa asiakkaat ovat. Ja koska meillä on mallikerros, joka edustaa sitä, voimme jopa sitoa sen tietolähteisiin ja viedä sen mihin käytetyissä tiedusteluissa, mihin tietokantoihin nämä myös sijaitsevat. Se todella antaa meille kyvyn sitoa tämä kaikki hyvin johdonmukaisesti.

Olen osoittanut sinulle yritystietokohteet. Haluan puhua myös nopeasti metadata-laajennuksista, joita kutsumme liitteiksi. Mitä se tekee, se antaa meille mahdollisuuden luoda ylimääräisiä metatietoja malliobjekteillemme. Aivan usein perustaisin tämän tyyppisiä ominaisuuksia ajamaan paljon erilaisia ​​asioita tiedonhallinnan ja tietojen laadun näkökulmasta ja auttamaan meitä myös perustietojen hallinnassa ja tietojen säilyttämiskäytännöissä. Perusajatuksena on, että luot nämä luokitukset ja voit liittää ne minne haluat, taulukotason, sarakkeen tasolla, nämä tyypit. Yleisin käyttötapaus on tietysti se, että entiteetit ovat taulukoita, ja sitten voin määritellä: mitkä ovat perustietoobjektini, mitkä ovat viitetaulukot, mitkä ovat transaktiotaulukot? Tietojen laadun näkökulmasta voin tehdä luokituksia liiketoiminnan kannalta tärkeinä, jotta voimme priorisoida tietojen puhdistamistoimet ja kyseisen tyyppiset asiat.

Jotakin huomiotta jätettyyn kysymykseen kuuluu, mikä on organisaatiomme erityyppisten tietojen säilyttämispolitiikka? Voimme perustaa nämä ja voimme tosiasiallisesti liittää ne erityyppisiin informaatioaiheisiin mallintamisympäristössämme ja tietysti myös arkistoomme. Hyvin kauneus on, ovatko nämä liitteet eläviä tietohakemistossamme, joten kun käytämme yritystietojen sanakirjoja ympäristössä, voimme liittää ne useisiin malleihin. Meidän on määriteltävä ne vain kerran ja voimme hyödyntää niitä yhä uudelleen ympäristön eri malleissa. Tämä on vain nopea kuvakaappaus osoittaa, että voit itse määrittää, kun teet liitetiedoston, mihin kaikkiin kappaleisiin haluat kiinnittää sen. Ja tämä esimerkki tässä on oikeastaan ​​luettelo arvoista, joten kun ne menevät sisään, voit valita arvoluettelosta, sinulla on paljon hallintaa valitun mallintamisympäristössä ja voit jopa asettaa, mikä oletusarvo on arvo on, jos arvoa ei valita. Joten paljon voimaa siellä. He elävät datasanakirjassa.

Jotain, jonka haluan näyttää sinulle hieman kauemmas tällä näytöllä, lisäksi yläosassa näkyy liitteitä, joiden alapuolella näet tietoturvatiedot. Voimme tosiasiallisesti soveltaa tietoturvakäytäntöjä myös ympäristön erilaisiin tietoihin. Eri vaatimustenmukaisuuden kartoituksia, tietoturvallisuusluokituksia varten lähetämme joukon niistä laatikosta, jonka voit vain luoda ja alkaa käyttää, mutta voit määritellä myös omat vaatimustenmukaisuuskartat ja standardit. Oletko tekemässä HIPAA tai mitä tahansa muuta siellä olevaa aloitetta. Ja voit todella alkaa rakentaa tätä erittäin rikas metatietojoukkoasi ympäristössäsi.

Ja sitten sanasto ja termit - tässä on sidottu yritystoiminnan merkitys. Meillä on melko usein datasanakirjoja, joita organisaatio usein käyttää lähtökohtana sanastojen ajamiselle, mutta terminologia ja sanamuoto ovat usein erittäin tekninen. Joten mitä voimme tehdä, voimme halutessaan käyttää niitä lähtökohtana sanastojen laatimiseen, mutta todella haluamme, että yritys omistaa ne. Se mitä olemme tehneet tiimipalvelinympäristössä, olemme antaneet ihmisille mahdollisuuden luoda yritysmäärittelyjä ja sitten voimme linkittää ne erilaisiin malliesineisiin, joita ne vastaavat myös mallintamisympäristössä. Tunnustamme myös se seikan, josta aiemmin keskusteltiin: mitä enemmän ihmisiä kirjoitat, sitä enemmän potentiaalia on ihmisvirheille. Se, mitä teemme myös sanastorakenteessamme, on, että tuemme sanastojen hierarkiaa, joten organisaatiossa voi olla erilaisia ​​sanastotyyppejä tai erityyppisiä asioita, mutta yhtä tärkeätä on, jos sinulla on jo jokin näistä lähteistä siellä määriteltyjen ehtojen ja kaiken kanssa, voimme tosiasiallisesti tehdä CSV-tuonnin vetääksemme ne mallinnusympäristöömme ja myös tiimipalvelimeemme tai sanastoon ja aloittamaan linkityksen sieltä. Ja joka kerta kun jotain vaihdetaan, siellä on täysi tarkastuskäytäntö siitä, mitkä aiemmat ja seuraavat kuvat olivat määritelmien ja kaiken muun suhteen, ja se, mitä näet tulevan lähitulevaisuudessa, on myös enemmän valtuutusprosessia joten voimme todella valvoa sitä, kuka vastaa siitä, komiteoiden tai henkilöiden hyväksymiä ja tämän tyyppisiä asioita, jotta hallintomenettelystä voidaan tehdä entistä vahvempi eteneessä.

Mitä tämä meille tekee, on myös se, että kun meillä on nämä sanastotermit tiimipalvelimen sanastoissa, tämä on esimerkki muokkaamisesta itse mallin kokonaisuudessa, jonka olen tuonut esille. Se saattaa olla linkittänyt termit, mutta mitä teemme myös, jos sanastossa on sanoja, jotka ilmestyvät muistiinpanoihin tai kuvauksiin siitä, mitä meillä on täällä olevissa yksiköissä, ne näytetään automaattisesti vaaleammalla hyperlinkillä, ja jos me Jos hiiri on niiden yläpuolella, näemme määritelmän tosiasiassa myös yrityssanakirjasta. Se antaa meille jopa rikkaamman tiedon, kun kulutamme itse tietoja kaikilla siellä olevilla sanastoilla. Se todella auttaa rikastuttamaan kokemusta ja soveltamaan merkitystä kaikkeen, jonka kanssa työskentelemme.

Joten jälleen kerran, se oli erittäin nopea flyby. Tietenkin voisimme viettää päiviä tähän, kun kalastamme eri osiin, mutta tämä on erittäin nopea flyby pinnan yli. Pyrimme todella ymmärtämään, miltä nämä monimutkaiset tietoympäristöt näyttävät. Haluamme parantaa kaikkien näiden esineiden näkyvyyttä ja tehdä yhteistyötä niiden ohjaamiseksi ulos ER / Studion kanssa. Haluamme mahdollistaa tehokkaamman ja automatisoidun tiedon mallinnuksen. Ja se on kaiken tyyppistä dataa, josta puhumme, olipa kyse sitten isodatasta, perinteisestä relaatiotiedosta, asiakirjavarastoista tai muusta. Ja jälleen kerran, olemme saavuttaneet tämän, koska meillä on tehokkaat eteen- ja taaksepäin suunnittelevat ominaisuudet eri alustoille ja muille työkaluille, joita sinulla voi olla siellä. Ja kyse on jakamisesta ja kommunikoinnista organisaation välillä kaikkien sidosryhmien kanssa. Siellä käytämme merkitystä nimeämisstandardien avulla. Käytämme sitten määritelmiä liiketoimintasanakirjamme kautta. Ja sitten voimme tehdä lisäluokituksia kaikille muille hallintoominaisuuksille metadatalaajennuksilla, kuten tiedonlaatulaajennuksilla, luokituksilla perustietojen hallintaa varten tai muilla luokituksilla, joita haluat soveltaa kyseisiin tietoihin. Ja sitten voimme tehdä yhteenvedon edelleen ja parantaa viestintää vielä enemmän yritystietokohteiden kanssa, eri sidosryhmien kanssa, etenkin mallintajien ja kehittäjien välillä.

Ja tässä on jälleen erittäin tärkeää, että kaiken takana on integroitu arkisto, jolla on erittäin vankat muutostenhallintaominaisuudet. Minulla ei ollut aikaa näyttää sitä tänään, koska se on melko monimutkainen, mutta arkistolla on erittäin vankat muutostenhallintaominaisuudet ja tarkastusketjut. Voit tehdä nimettyjä julkaisuja, voit tehdä nimettyjä versioita, ja meillä on myös kyky niille, jotka hoitavat muutoksenhallintaa. Voimme sitoa sen oikein tehtäviinne. Meillä on tänään kyky laittaa tehtäviä ja yhdistää mallimuutoksesi tehtäviin, aivan kuten kehittäjät yhdistäisivät koodimuutoksensa tehtäviin tai käyttäjän tarinoihin, joiden kanssa he myös työskentelevät.

Tämä oli jälleen erittäin nopea yleiskatsaus. Toivon, että ruokavalion lisääminen on ollut tarpeeksi, jotta voimme käydä paljon syvempiä keskusteluja jakaaksesi joitain näistä aiheista tulevaisuuden edetessä. Kiitos ajastasi ja takaisin sinulle, Rebecca.

Rebecca Jozwiak: Kiitos, Ron, se oli upeaa ja minulla on melko vähän kysymyksiä yleisöltä, mutta haluan antaa analyytikoillemme mahdollisuuden upottaa hampaat siihen, mitä teidän on sanottu. Eric, aion mennä eteenpäin ja ehkä jos haluat käsitellä tätä tai toista diaa, miksi et mene eteenpäin? Tai mikä tahansa muu kysymys.

Eric Little: Toki. Anteeksi, mikä oli kysymys, Rebecca? Haluat minun kysyvän jotain erityistä tai…?

Rebecca Jozwiak: Tiedän, että sinulla oli alun perin joitain kysymyksiä Ronille. Jos haluat pyytää häntä nyt ottamaan yhteyttä joku niistä, tai jotkut heistä teidän diojen ulkopuolella, tai jotain muuta, joka herätti kiinnostustanne, josta haluat kysyä? IDERAn mallinnustoiminnoista.

Eric Little: Joo, niin yksi asioista, Ron, joten miten näyttää, näyttää siltä, ​​että esittämäsi kaaviot ovat yleisiä olosuhteiden kaavioita, joita normaalisti käyttäisit tietokannan rakentamisessa, oikein?

Ron Huizenga: Niin, yleisesti ottaen, mutta tietysti meillä on laajennetut tyypit asiakirjavarastoille ja myös tämäntyyppiset asiat. Olemme tosiasiallisesti vaihdelleet pelkästään suhteellisista merkinnöistä, olemme lisänneet ylimääräisiä merkintöjä myös näihin muihin kauppoihin.

Eric Little: Onko teillä tapa, jolla te voitte käyttää kuvaajapohjaisia ​​mallinnustyyppejä, niin onko olemassa tapa integroida, esimerkiksi oletetaan, että minulla on jotain ylin kvadrantti, TopBraid-säveltäjätyökalu tai olen tehnyt jotain Protégéssä tai, kuten tiedät, kuten FIBO: n finanssikaverit, he tekevät paljon työtä semantiikassa, RDF-tavaroita - onko olemassa tapa tuoda tämäntyyppinen olosuhteiden kuvaajatyyppinen mallinnus tähän työkaluun ja hyödyntää sitä se?

Ron Huizenga: Etsimme tosiasiassa kuinka voimme käsitellä kuvaajia. Emme nykyään käsittele nimenomaisesti kuvaajatietokantoja ja tällaista asiaa, mutta etsimme tapoja, joilla voimme tehdä niin metadatan laajentamiseksi. Tarkoitan, että voimme tuoda asiat XML: n ja tämän tyyppisten asioiden kautta nyt, jos pystymme ainakin tekemään jonkinlaisen XML: n luovutuksen sen tuomiseksi lähtökohdaksi. Mutta etsimme tyylikkäitä tapoja tuoda se esiin.

Ja osoitin sinulle myös luettelon käänteissuunnittelu siltoista, joita meillä on myös, joten etsimme jatkuvasti laajennuksia noihin siltoihin myös tietyille alustoille. Se on jatkuvaa ja jatkuvaa pyrkimystä, jos se on järkevää, alkaa omaksua paljon näitä uusia rakenteita ja erilaisia ​​alustoja. Mutta voin sanoa, että olemme ehdottomasti kärjessä tekemässä sitä. Asiat, jotka näyttelin esimerkiksi MongoDB: lle, ja tämäntyyppiset asiat, olemme ensimmäisiä tietojen mallinnusmyyjiä, jotka tosiasiallisesti tekevät sen omalla tuotteellamme.

Eric Little: Okei, kyllä. Joten toinen kysymys, joka minulla oli sinulle sitten, koski hallintoa ja ylläpitämistä - kuten silloin, kun käytit esimerkkiä, kun näytit henkilön, joka on “työntekijä”, uskon, että se oli “ palkka ”ja sitten sinulla on” suunnitelma ”, onko olemassa tapa, jolla hallitaan esimerkiksi erilaisia ​​ihmisiä, joilla voi olla - oletetaan, että sinulla on suuri arkkitehtuuri, eikö, oletetaan, että sinulla on suuri yritys ja ihmiset alkavat vetää asioita yhteen tällä työkalulla ja sinulla on täällä yksi ryhmä, jossa on sana “työntekijä” ja yksi ryhmä täällä, jossa on sana “työntekijä”. Ja yksi täällä oleva henkilö sanoo “palkka” ja toinen henkilö sanoo ”palkkakustannuksilla.”

Kuinka kaverit sovittavat yhteen ja hallitsevat ja hallitsevat sellaisia ​​eroja? Koska tiedän, kuinka tekisimme sen graafimaailmassa, tiedät, käyttäisit synonyymiluetteloita tai sanoisit, että on yksi käsite ja sillä on useita määritteitä, tai voisitko sanoa SKOS-mallissa, että minulla on ensisijainen etiketti ja minulla on lukuisia vaihtoehtoisia etikettejä, joita voin käyttää. Kuinka te teette sen?

Ron Huizenga: Teemme sen parilla eri tavalla, ja puhutaan ensinnäkin ensin terminologiasta. Yksi asioista, joita teemme, tietenkin, on se, että haluamme, että meillä on määritellyt tai seuraamukselliset termit, ja yrityssanakirjassa on selvästi se, missä haluamme. Sallimme myös linkit synonyymeihin myös yrityssanakirjassa, joten voit sanoa, tässä on minun termi, mutta voit myös määritellä, mitkä kaikki niiden synonyymit ovat.

Nyt mielenkiintoinen asia on tietenkin, kun aloitat tutkimaan tätä laajaa tietokenttää kaikkien näiden erilaisten järjestelmien kanssa, jotka sinulla on siellä, et voi vain mennä sinne ja muuttaa vastaavia taulukoita ja kyseisiä asioita vastaavat tätä nimeämisstandardia, koska se voi olla ostamasi paketti, joten et voi hallita tietokannan tai muun muuttamista.

Voimme siellä sen lisäksi, että pystymme yhdistämään sanastomääritelmät, niiden universaalien kartoitusten kautta, joista puhuin, mitä tekisimme, ja eräänlainen suositeltava lähestymistapa, että meillä on kattava looginen malli, joka asettaa mitä nämä erilaiset liikeideat ovat siitä, mistä puhut. Yhdistä yrityssanakirjatermit niihin, ja hieno asia on nyt, että sinulla on tämä rakenne, joka edustaa loogista kokonaisuutta sellaisenaan, voit sitten aloittaa linkin kyseisestä loogisesta kokonaisuudesta kaikkiin loogisen entiteetin toteutuksiin eri järjestelmät.

Sitten missä sinun täytyy päästä siihen, voit nähdä, oi, "henkilö" täällä on nimeltään "työntekijä" tässä järjestelmässä. "Palkka" kutsutaan tässä "palkkaksi" tässä toisessa järjestelmässä. Koska näet sen, näet kaikki ne erilaiset ilmenemismuodot, koska olet linkittänyt ne toisiinsa.

Eric Little: Okei hieno, kyllä, sait sen. Tässä mielessä on turvallista sanoa, että se on kuin jotkut oliopohjaisista lähestymistavoista?

Ron Huizenga: Hieman. Se on hiukan intensiivisempi kuin luulet voisit sanoa. Tarkoitan, että voit käyttää lähestymistapaa linkittää manuaalisesti ja käydä läpi, tarkastaa ja tehdä ne kaikki. Yksi asia, josta minulla ei oikeastaan ​​ollut mahdollisuutta puhua - koska taas meillä on paljon ominaisuuksia - meillä on myös täysi automaatiorajapinta itse Data Architect -työkalussa. Ja makroominaisuus, joka on todella työkalun ohjelmointikieli. Joten voimme todella tehdä asioita, kuten kirjoittaa makroja, antaa sen mennä ulos, kuulustella asioita ja luoda linkkejä sinulle. Käytämme sitä tietojen tuontiin ja vientiin, voimme käyttää sitä asioiden muuttamiseen tai määritteiden lisäämiseen, tapahtumaan, joka perustuu itse malliin, tai voimme käyttää sitä juoksemaan erissä tosiasiallisesti lähteäkseen tutkimaan asioita ja asuttamaan tosiasiallisesti erilaisia ​​rakenteita malli. Joten siellä on täysi automaatiorajapinta, jota ihmiset voivat myös hyödyntää. Ja yleismaailmakarttojen käyttäminen niiden kanssa olisi erittäin tehokas tapa tehdä se.

Rebecca Jozwiak: Okei, kiitos Ronille ja Ericille. Ne olivat suuria kysymyksiä. Tiedän, että juoksemme vähän tunnin huipun ohi, mutta haluaisin antaa Malcolmille mahdollisuuden heittää joitain kysymyksiä Ronin tapaan. Malcolm?

Malcolm Chisholm: Kiitos, Rebecca. Joten, Ron, se on erittäin mielenkiintoista, näen, että täällä on paljon ominaisuuksia. Yksi alueista, joista olen erittäin kiinnostunut, on esimerkiksi sanoa, jos meillä on kehitysprojekti, miten näet datan mallinntajan käyttävän näitä ominaisuuksia ja työskentelevän ehkä enemmän yhteistyössä liike-elämän analyytikoiden, dataprofiilin ja tietojen laadun analyytikon kanssa, ja niiden yrityssponsorien kanssa, jotka ovat viime kädessä vastuussa hankkeen todellisista tietovaatimuksista. Kuinka tietomallinnuslaite, tiedätkö, todella tekee projektista tehokkaamman ja tehokkaamman etsimillämme ominaisuuksilla?

Ron Huizenga: Mielestäni yksi ensimmäisistä asioista, jotka sinun on tehtävä siellä, on datamuotoilija - en tarkoita valita joitain mallintajista, mutta aion kuitenkin -, onko joillakin ihmisillä edelleen käsitys, että datan mallinntaja on oikeastaan ​​portinvartijan tyyppinen rooli, määrittelemme miten se toimii, olemme vartijoita, jotka varmistavat, että kaikki on oikein.

Nyt siellä on yksi näkökohta, että sinun on varmistettava, että määrität vakaan dataarkkitehtuurin ja kaiken muun. Tärkeämpää on kuitenkin datamuotoilijana - ja olen havainnut tämän melko selvästi neuvotteleessani - onko sinun tehtävästäsi avustaja, joten sinun on saatava nämä ihmiset yhteen.

Se ei tule olemaan suunnittelun alusta, luomaan ja rakentamaan tietokantoja enää - mitä sinun on pystyttävä tekemään, sinun on kyettävä työskentelemään kaikkien näiden eri sidosryhmien kanssa tekemällä muun muassa käänteistä suunnittelua, tuomaan tietoja, muut ihmiset tekevät yhteistyötä riippumatta siitä, onko kyse sanastoista tai dokumentaatiosta, kaikesta sellaisesta - ja auttakaa vetämään tämä arkistoon, yhdistämään käsitteet arkistossa ja työskentelemään näiden ihmisten kanssa.

Se on todellakin paljon yhteistyötyyppistä ympäristöä, jossa jopa määrittelemällä tehtäviä tai jopa keskusteluprosesseja tai sellaisia ​​asioita, joita meillä on tiimipalvelimella, että ihmiset voivat tosiasiassa tehdä yhteistyötä, kysyä kysymyksiä ja päästä lopulliseen lopputuotteeseen, jonka he ovat tietoarkkitehtuurin ja organisaation tarve. Onko tällainen vastaus?

Malcolm Chisholm: Joo, olen samaa mieltä. Tiedätte, luulen, että helpotustaito on jotain, mikä on todella toivottavaa datamuotoilijoissa. Olen samaa mieltä siitä, että emme aina näe sitä, mutta mielestäni se on välttämätöntä, ja ehdottaisin, että joskus on taipumusta pysyä nurkassa tekemässä tietosi mallintaa, mutta sinun on todella oltava siellä työskentelemässä muiden sidosryhmien kanssa. tai et vain ymmärrä käsittelemääsi tietoympäristöä, ja mielestäni malli kärsii siitä. Mutta se on vain minun mielipiteeni.

Ron Huizenga: Ja se on mielenkiintoista, koska mainitsit aiemmin diassasi jotain historiasta siitä, kuinka yritykset ovat tavallaan kääntyneet tietotekniikan ulkopuolelle, koska ne eivät toimittaneet ratkaisuja ajoissa ja tällaisia ​​asioita.

On erittäin mielenkiintoista, että myöhemmissä konsultointitoiminnoissani, ennen kuin tulin tuotepäälliköksi, suurin osa projekteista, jotka tein viimeisen kahden vuoden aikana sitä ennen, olivat liiketoiminnan sponsoroimia, missä sitä ohjaavat yritykset ja tietoarkkitehdit ja mallinntajat eivät olleet osa IT: tä. Olimme osa yritystoiminnan tukemaa ryhmää ja olimme siellä avustajina työskentelemässä muun projektitiimin kanssa.

Malcolm Chisholm: Joten mielestäni se on erittäin mielenkiintoinen asia. Luulen, että olemme alkaneet nähdä muutoksen yritysmaailmassa, jossa yritys kysyy tai ajattelee ehkä, ei niin paljon kuin mitä teen, prosessin tapaisena, mutta he alkavat myös miettiä, mikä on tieto joiden kanssa työskentelen, mitkä minun tietotarpeeni ovat, mitä tietoja käsittelen datana ja missä määrin voimme saada IDERA-tuotteita ja -ominaisuuksia tuon näkökulman tukemiseksi, ja uskon, että yrityksen tarpeet, jopa vaikka se on tavallaan vielä vähän syntymässä.

Ron Huizenga: Olen kanssani samaa mieltä ja luulen, että näemme sen jatkuvan entistä enemmän. Olemme nähneet herätyksen, ja te kosketitte sitä aikaisemmin tietojen tärkeyden suhteen. Näimme datan merkityksen jo varhaisessa vaiheessa IT: ssä tai tietokantojen kehityksessä. Sitten kuten sanoit, pääsimme eräänlaiseen koko prosessinhallintasykliin - ja prosessi on erittäin tärkeä, älä ymmärrä minua väärin - mutta nyt mitä tapahtui on silloin, kun se tapahtui, tietotyyppi kadonnut keskittyminen.

Ja nyt organisaatiot ymmärtävät, että tieto on todellakin keskipiste. Tiedot edustavat kaikkea mitä olemme tekemässä liiketoiminnassamme, joten meidän on varmistettava, että meillä on tarkkoja tietoja, että löydämme oikeat tiedot, joita tarvitsemme päätöksentekoksi. Koska kaikki ei johdu määritellystä prosessista. Osa tiedoista on sivutuotetta muista asioista, ja meidän on silti kyettävä löytämään ne, tietämään, mitä ne tarkoittavat, ja kyettävä kääntämään näkemämme tiedot lopulta tietoon, jota voimme käyttää ohjaamaan yritystämme paremmin.

Malcolm Chisholm: Oikein, ja nyt toinen alue, johon olen kamppaillut, on se, jota kutsun datan elinkaareen, mikä on, tiedättekö, jos tarkastelemme sellaista tietojen toimitusketjua, joka menee yrityksen läpi, aloittaisimme tietojen hankkiminen tai tietojen sieppaaminen, mikä saattaa olla tietojen syöttäminen, mutta se voi yhtä hyvin olla, saan tietoja yrityksen ulkopuolelta joltakin tietomyyjältä.

Ja sitten tiedonkeruusta siirrymme datan ylläpitoon, jossa mietin näiden tietojen standardisointia ja lähettämistä ympäri paikkoja, joissa sitä tarvitaan. Ja sitten datan käyttö, tosiasialliset kohdat, joissa data on, saat arvon irti tiedoista.

Ja vanhoina tämä kaikki tapahtuu yhdessä yksilöllisessä tyylissä, mutta nykyään se voi olla, esimerkiksi, analytiikkaympäristö ja sen jälkeen arkisto, myymälä, johon laitamme tiedot, kun emme enää tarvitsemme sitä ja lopulta puhdistavanlaista prosessia. Kuinka näet datan mallinnuksen sopivan koko tämän tiedon elinkaaren hallintaan?

Ron Huizenga: Se on erittäin hyvä kysymys, ja yksi asia, jolla minulla ei todellakaan ollut aikaa tutkia mitään yksityiskohtia täällä tänään ollenkaan, on se, mistä me oikeasti puhumme, on tietolähde. Joten mitä todella pystymme tekemään, on, että työkaluissamme on datalinjaominaisuudet, ja kuten sanoin, voimme tosiasiassa purkaa osan siitä ETL-työkaluista, mutta voit myös kartoittaa sen vain piirtämällä suuntaviivan. Mikä tahansa näistä datamalleista tai tietokannoista, jotka olemme tarttaneet ja tuoneet malleihin, voisimme viitata rakenteisiin siitä, jotka ovat tietolähdekaaviossamme.

Mitä pystymme tekemään, on vetää tiedonkulku, kuten sanot, lähteestä kohteeseen ja koko elinkaaren ajan siitä, kuinka nämä tiedot kulkevat eri järjestelmien läpi ja mitä etsit, on otettava työntekijät 'data - se on yksi suosikeistani, joka perustuu projektiin, jonka tein vuosia sitten. Työskentelin organisaation kanssa, jolla oli työntekijätietoja 30 eri järjestelmässä. Se mitä päädyimme tekemään siellä - ja Rebeccan nousi ylös tietolähteiden diaan - on täällä melko yksinkertaistettu tietolähteiden dia, mutta mitä pystyimme tekemään, oli tuoda kaikki tietorakenteet, viitata ne kaavioon ja sitten me voi todella alkaa tutkia, mitkä ovat virrat välillä, ja kuinka nämä eri tietokokonaisuudet kytketään yhteen virtauksessa? Ja voimme myös mennä pidemmälle. Tämä on osa täällä näkemäämme datavirta- tai linjakaaviota. Jos haluat mennä pidemmälle, meillä on myös liiketoimintaarkkitehti osa tätä sviittiä ja sama asia koskee myös siellä.

Mihin tahansa tietorakenteista, jotka olemme tarttuneet datan mallintamisympäristöön, niihin voidaan viitata liiketoimintamallinnustyökalussa siten, että jopa liiketoimintamallikaavioissasi tai liiketoimintaprosessikaavioissasi voit viitata yksittäisiin tietovarastoihin, jos haluat poistua datan mallintamisympäristössä, ja kun käytät niitä liiketoimintaprosessimallisi kansioihin, voit myös määrittää CRUD: n myös niissä, kuinka kyseiset tiedot joko kulutetaan tai tuotetaan, ja sitten voimme alkaa tuottaa kuten vaikutus- ja analyysiraportit ja kaaviot siitä.

Mihin tavoitteemme päästä ja meillä on jo paljon valmiuksia, mutta yksi niistä asioista, joita meillä on tavallaan tavoitepostina, jota tarkastelemme, kun jatkamme työkalujen kehitystä eteenpäin, pystyy kartoittamaan kyseisen päästä päähän -kohdan, organisaation tietolähteen ja datan koko elinkaaren.

Malcolm Chisholm: Okei. Rebecca, saanko vielä yhden?

Rebecca Jozwiak: Annan sinulle vielä yhden, Malcolm, mennä eteenpäin.

Malcolm Chisholm: Kiitos paljon. Kun ajattelemme tiedonhallintaa ja ajattelemme datan mallintamista, miten saamme nämä kaksi ryhmää toimimaan tehokkaasti yhdessä ja ymmärtämään toisiaan?

Eric Little: No, se on mielenkiintoista, mielestäni se todella riippuu organisaatiosta, ja se juontaa aikaisempaan konseptini, että niissä organisaatioissa, joissa aloitteet perustuivat liiketoimintaan, olimme sidoksissa oikein. Esimerkiksi johdin tietoarkkitehtuuria joukkue, mutta olimme sidoksissa oikein liiketaloudellisiin käyttäjiin ja auttimme tosiasiallisesti heitä puolustamaan tiedonhallintaohjelmaansa. Jälleen kerran neuvoa-antava lähestymistapa, mutta se on todellakin enemmän liiketoiminnallista toimintaa.

Mitä todella tarvitset pystyäksesi siihen, tarvitset tietomallit ja arkkitehdit, jotka todella ymmärtävät liiketoimintaa, voivat suhtautua liiketoiminnan käyttäjiin ja ovat sitten auttaneet heitä seisomaan hallintomenettelyjensä ympärillä. Liiketoiminta haluaa tehdä sen, mutta yleisesti ottaen meillä on teknologiatuntemus auttaaksemme heitä erotumaan tällaisista ohjelmista. Sen on todellakin oltava yhteistyötä, mutta sen on oltava yrityksen omistama.

Malcolm Chisholm: Okei, se on hienoa. Kiitos.

Dr. Eric Little: Okei.

Rebecca Jozwiak: Okei, kiitos paljon. Yleisön jäsenet, pelkään, ettemme päässeet kysymyksiisi, mutta varmistan, että heidät välitetään edelleen asianmukaiselle vieraalle, joka meillä oli tänään linjalla. Haluan kiittää teitä niin paljon Ericille, Malcolmille ja Ronille siitä, että olette tänään vieraitamme. Tämä oli hienoa kamaa, ihmiset. Ja jos nautit tämän päivän IDERA-verkkolähetyksestä, IDERA on myös keskiviikkona Hot Technologies ensi keskiviikkona, jos haluat liittyä keskustelemaan indeksoinnin ja oraakkelien haasteista, joten toinen kiehtova aihe.

Kiitos paljon, ihmiset, ole varovainen, ja tapaamme seuraavan kerran. Hei hei.