Suurimman osan kahdesta viime vuosikymmenestä data-arkkitehtuuria kohdeltiin loppupään huolena. Sovellukset ostettiin tai rakennettiin prosessien ajamiseen, ja data oli sitä, mitä nuo sovellukset sattuivat kirjaamaan. Raportointi liitettiin päälle jälkikäteen, integrointi hoidettiin pisteestä pisteeseen tarpeiden ilmetessä, ja datan semantiikka jätettiin implisiittiseksi, koodattuna niiden ihmisten päähän, jotka olivat olleet talossa pisimpään. Tämä oli siedettävää niin kauan kuin järjestelmiä oli vähän ja muutostahti oli hidas.

Tuo sietokyky on loppunut. Tyypillinen yritys ajaa nykyään laajaa kirjoa software as a service -sovelluksia, joilla kullakin on oma mallinsa asiakkaasta, tuotteesta ja tapahtumasta, sekä rinnalla vanhoja järjestelmiä, joita ei voi poistaa käytöstä, ja dataplatform, jonka odotetaan sovittavan ne kaikki yhteen. Jokainen yritysoston, jokainen uusi kanava ja jokainen sääntelyvelvoite lisää saman asian yhden määritelmän lisää. Epäselvyyden kustannus, joka ennen imeytyi hiljaisesti, nousee nyt pintaan epäonnistuneina migraatioina, kiisteltyinä raportteina ja analytiikkana, johon ei voi luottaa riittävästi toimiakseen sen pohjalta.

Analyyttisten ja generatiivisten työkuormien saapuminen on nostanut panoksia entisestään. Malli, joka on koulutettu epäjohdonmukaisella, nimeämättömällä ja huonosti ymmärretyllä datalla, ei kaadu äänekkäästi. Se tuottaa itsevarmoja vastauksia perustuksille, joita kukaan ei ole tarkastellut. Organisaatiot, jotka saavat näistä tekniikoista arvoa, ovat lähes poikkeuksetta niitä, jotka olivat jo tehneet epäglamurin työn informaationsa selkeän määrittelyn parissa. Merkitys ei ole enää dokumentointiharjoitus. Se on rajoite, joka ratkaisee, voidaanko mihinkään datan päälle rakennettuun luottaa, ja juuri siksi informaatio- ja data-arkkitehtuuri on siirtynyt jonon hännästä sen kärkeen.

Data-arkkitehtuurin perustavanlaatuinen tieteenala on mallinnus, ja mallinnus ymmärretään oikeaoppisesti kolmena erillisenä näkymänä samaan kohteeseen, joista kukin palvelee eri yleisöä ja kukin vastaa eri kysymykseen. Niiden yhteen romahduttaminen tai kahden ylemmän ohittaminen ja aloittaminen suoraan tietokannasta on alan yleisin rakenteellinen virhe.

Käsitteellinen malli kuvaa, mitä liiketoiminta tarkoittaa, liiketoiminnan kielellä. Se nimeää ydinentiteetit, asiakkaan, sopimuksen, omaisuuserän, toimituksen, ja niiden väliset suhteet viittaamatta lainkaan siihen, miten ne tallennetaan. Sen tarkoitus on yhteisymmärrys. Kun kaksi osastoa kiistelee siitä, onko liidi asiakas, käsitteellinen malli on se paikka, jossa tuo kiista ratkaistaan, kerran, kirjattuna. Se on pieni, vakaa ja ilmaistu termein, jotka ei-tekninen johtaja voi lukea ja hyväksyä.

Looginen malli ottaa nuo sovitut käsitteet ja tekee niistä täsmällisiä. Se määrittelee attribuutit, tunnisteet, kardinaliteetit ja niitä hallitsevat säännöt: sopimuksella on oltava täsmälleen yksi omistava osapuoli, laskurivi viittaa tuotteeseen, jonka on oltava olemassa. Se on riippumaton mistä tahansa yksittäisestä teknologiasta, joten sama looginen malli voidaan toteuttaa relaatiotietokannassa, dokumenttivarastossa tai tapahtumavirrassa. Tämä on se kerros, jossa täsmällisyys asuu, ja se on se kerros, joka useimmiten puuttuu kokonaan.

Fyysinen malli on toteutus: taulut, sarakkeet, indeksit, partitiot, tiedostomuodot ja suorituskyvyn sekä kustannusten vuoksi tehdyt kompromissit. Se on tarkoituksella alin kerros, koska se on se, joka on eniten altis muutokselle. Kun fyysisten päätösten annetaan ohjata loogista ja käsitteellistä ymmärrystä, eikä päinvastoin, yritys päätyy määrittelemään oman liiketoimintansa sen mukaan, minkä sen tietokantatoimittaja katsoi mukavaksi. Kurinalaisuutta on antaa merkityksen virrata alas rakenteeseen eikä koskaan antaa rakenteen hiljaa määritellä merkitystä uudelleen.

Useat kehityskulut muovaavat sitä, miten tämä työ tehdään, ja on syytä erottaa sisällölliset siirtymät niiden ympärillä pyörivästä markkinoinnista. Merkittävin on siirtymä puhtaasti keskitetystä datan omistajuudesta kohti federoituja malleja, joista data mesh on tunnetuin ilmaisu. Oivallus on pätevä: niiden ihmisten, jotka ymmärtävät toimialueen, tulisi olla vastuussa sen datan laadusta ja merkityksestä, ja datan kohteleminen tuotteena, jolla on nimetty omistaja, sopimus ja kuluttaja, parantaa molempia. Riski, joka usein toteutuu, on että federointi ilman jaettua semantiikkaa vain hajauttaa epäselvyyden sen sijaan, että ratkaisisi sen. Federoitu omistajuus toimii vain koko yrityksen laajuisten määritelmien päällä, ei niiden sijasta.

Toinen siirtymä on semanttisen kerroksen nousu ja uudistunut vakavuus metadataa kohtaan. Aktiivinen metadata, dataluettelot ja automatisoitu lineage-tieto ovat tehneet mahdolliseksi tietää laajassa mittakaavassa, mitä dataa on olemassa, mitä se tarkoittaa ja mistä se on peräisin, sen sijaan että luotettaisiin heimotietämykseen. Tämä on aitoa edistystä, kunhan luetteloa kohdellaan hallittuna artefaktina eikä kaatopaikkana, joka vanhenee merkityksettömäksi vuoden sisällä.

Kolmanneksi analyyttisten ja generatiivisten työkuormien vaatimukset ovat tehneet datan laadusta ja lineage-tiedosta kaupallisia välttämättömyyksiä hygienian sijaan. Kun organisaation on selitettävä sääntelijälle tai itselleen, miksi malli teki tietyn päätöksen, sen on jäljitettävä vastaus jokaisen muunnoksen läpi takaisin lähteeseensä. Lineage on siirtynyt mukavasta kaaviosta auditoitavaksi vaatimukseksi. Datan ympärillä olevan sääntelyn tasainen kiristyminen, tietosuojalainsäädännöstä toimialakohtaisiin velvoitteisiin, vahvistaa samaa seikkaa: yrityksen odotetaan yhä enemmän tietävän täsmälleen, mitä dataa se pitää hallussaan, mitä se tarkoittaa ja miten se liikkuu, ja todistavan sen.

Hyvä informaatioarkkitehtuuri lepää pienen periaatejoukon varassa, jotka on yksinkertaista lausua ja vaativaa pitää yllä. Ensimmäinen on yksi luotettava merkitys kullekin ydinkäsitteelle. Tämä ei tarkoita yhtä fyysistä kopiota datasta, mikä ei ole saavutettavissa eikä toivottavaa. Se tarkoittaa yhtä auktoritatiivista määritelmää, jota jokainen kopio noudattaa, ja selkeää nimeämistä sille, mikä järjestelmä on totuuden lähde kullekin entiteetille. Master data management on tämän periaatteen käytännön ilmentymä: sen tunnistaminen, että asiakas ja tuote jaetaan koko yrityksen laajuudelta, ja niiden golden recordien hallitseminen tietoisesti sen sijaan, että kukin sovellus keksisi omansa.

Toinen periaate on referenssidatan selkeä erottaminen master- ja transaktiodatasta. Referenssidata, maakoodien, valuuttojen, tilojen ja luokitusten hallitut listat, on pientä, hitaasti muuttuvaa ja kaikkialle levinnyttä, ja se aiheuttaa suhteettoman suurta vahinkoa kun se ajautuu erilleen. Sen hallitseminen keskitetysti, omistetuin koodilistoin ja hallituin muutoksin, estää suuren luokan hiljaisia integrointivirheitä.

Kolmas periaate on, että data tulisi mallintaa kerran ja toteuttaa fyysisesti monta kertaa, lineage-tiedon yhdistäessä kopiot. Sama looginen entiteetti voi elää operatiivisessa varastossa, tietovarastossa ja välimuistissa, mutta kukin on projektio yhdestä ymmärretystä määritelmästä, ja niiden väliset muunnokset ovat dokumentoituja ja jäljitettäviä. Neljäs periaate on, että omistajuus suunnitellaan sisään, ei osoiteta jälkikäteen. Jokaisella merkittävällä data-alueella on nimetty stewardi, joka vastaa sen määritelmästä ja laadusta, ja tuo vastuu on todellinen, valtuuksin ratkaista kiistoja. Lopuksi, laatua mitataan merkitystä vastaan, ei tallennusta vastaan. Data on kelvollista, kun se edustaa uskollisesti sitä, mitä käsitteellinen malli sanoo sen edustavan, ja laatusäännöt, joita ei ole ankkuroitu määriteltyyn semantiikkaan, eivät mittaa mitään erityistä.

Tämän tieteenalan epäonnistumistavat ovat riittävän johdonmukaisia nimettäviksi. Aloittaminen fyysisestä kerroksesta on yleisin. Tiimi pystyttää tietovaraston tai lakehousen, mallintaa suoraan tauluihin ja huomaa kahdeksantoista kuukautta myöhemmin, että se on uskollisesti toistanut jokaisen lähdejärjestelmiensä epäjohdonmukaisuuden, suuremmassa mittakaavassa ja korkeammin kustannuksin. Rakenne rakennettiin ennen kuin merkityksestä sovittiin, eikä mikään määrä työkaluja palauta puuttuvaa yhteisymmärrystä.

Määritelmien lisääntyminen on toinen. Liikevaihto tarkoittaa yhtä asiaa taloushallinnolle, toista myynnille ja kolmatta hallitukselle, ja koska kukaan ei pidä kynää kädessään, kaikki kolme säilyvät. Jokaisesta raportista tulee neuvottelu, ja luottamus lukuihin rapautuu, kunnes ihmiset pitävät hiljaa omia laskentataulukoitaan, mikä on varmin merkki siitä, että arkkitehtuuri on epäonnistunut.

Hallitsemattoman masterdatan epäonnistuminen seuraa läheltä. Ilman hallittua golden recordia sama asiakas on olemassa neljänä tietueena, kaksoiskappaleet paisuttavat lukuja, ja täsmäytyksestä tulee pysyvä manuaalinen vero. Läheinen kuvio on luettelo, jota kukaan ei ylläpidä: metadata-aloite käynnistyy innolla, tallentaa ympäristön kerran eikä sitä koskaan päivitetä, joten vuoden sisällä se kuvaa järjestelmää, jota ei enää ole olemassa, ja johon kukaan ei luota.

Sitten on lineage koristeena, jossa virtauskaaviot piirretään auditointia varten eivätkä koskaan heijasta todellisia muunnoksia, joten kun jotakin lukua kyseenalaistetaan, sitä ei silti voida jäljittää. Lopuksi, ja hiljaisimmin vahingollinen, on hallinta ilman auktoriteettia: hallintaelin, joka kokoontuu, tuottaa politiikkaa eikä sillä ole valtaa saada mitään tiimiä muuttamaan mitään. Jokaisella näistä epäonnistumisista on yhteinen juuri. Joku kohteli informaatiota teknisenä sivutuotteena eikä hallittuna varallisuutena, jolla on omistaja, määritelmä ja elinkaari.

Nashua lähtee liikkeelle merkityksestä, ei teknologiasta. Ennen minkään platformin suosittelemista työskentelemme liiketoiminnan kanssa käsitteellisen mallin luomiseksi: ne kourallinen ydinentiteettejä, jotka yritys aidosti jakaa, ja ne määritelmät, joista on sovittava ja jotka on omistettava. Tämä tehdään tarkoituksella liiketoiminnan sidosryhmät huoneessa, koska asiakkaan määritelmä, jota sekä kaupalliset että talouden toiminnot eivät ole molemmat hyväksyneet, ei ole määritelmä, se on ehdotus. Vasta kun merkitys on ratkaistu, laskeudumme loogiseen ja fyysiseen suunnitteluun.

Sieltä kartoitamme todellisen ympäristön: mitkä järjestelmät pitävät mitäkin entiteettejä, mikä on auktoritatiivinen lähde kullekin, ja miten data todella liikkuu niiden välillä tänään, mukaan lukien ne dokumentoimattomat virrat, jotka jokaisella organisaatiolla on. Tämä tuottaa rehellisen kuvan lineage-tiedosta ja siitä, missä merkitys katoaa tai kahdentuu siirron aikana. Tuota kuvaa vasten suunnittelemme tavoitteen: missä master- ja referenssidataa hallitaan, miten golden recordit muodostetaan ja ylläpidetään, ja miten laatua mitataan sovittua semantiikkaa vasten sen sijaan, että mitattaisiin mukavia korvikkeita vasten.

Ratkaisevaa on, että Nashua kohtelee hallintaa operatiivisena kyvykkyytenä eikä dokumenttina. Autamme luomaan datan omistajuuden, jolla on todellinen auktoriteetti, stewardship-roolit, jotka sijaitsevat niillä toimialueilla, jotka ymmärtävät datan, ja luettelon, jota ylläpidetään elävänä artefaktina, koska se on kytketty siihen, miten muutos tehdään, eikä kuratoitu sivussa. Työskentelemme inkrementaalisesti, todistaen lähestymistavan yhdellä tai kahdella korkean arvon toimialueella, joilla epäselvyys maksaa liiketoiminnalle todellista rahaa, ja laajentaen sitten mallia. Tavoite läpi työn on, että organisaatio jää kykeneväksi ajamaan tieteenalaa itse, mallit, omistajuus ja hallinta upotettuina siihen, miten se toimii, sen sijaan että se olisi riippuvainen meistä pitääkseen sen koossa.

Se, mikä erottaa Nashuan tässä työssä, on kieltäytyminen antamasta työkalupäätöksen korvata vaikeampaa merkityksen kurinalaisuutta. Monet palveluntarjoajat toteuttavat mielellään luettelon, masterdata-platformin tai lakehousen ja julistavat dataongelman ratkaistuksi. Olemme nähneet riittävästi tuollaisia toimeksiantoja tietääksemme, että ratkaisemattoman semantiikan päälle ladottu teknologia vain automatisoi sekaannuksen. Meidän panoksemme on tehdä vaativa, epäglamuri määrittelyn, omistajuuden ja lineage-tiedon työ ensin, ja saada teknologia palvelemaan sitä, niin että yksi luotettava merkitys on todellinen ja kestävä eikä pelkkä tavoiteltu.

On myös käytännöllinen seuraus, joka muuttaa sitä, mitä työn sallitaan olettaa. Kun toimeksianto vaatii kyvykkyyttä, jota ei vielä ole olemassa, sen ei tarvitse odottaa hankintasykliä tai toimittajan tiekarttaa. enterprise platform on rakennettu mukautumaan lähes mihin tahansa ominaisuuteen ripeästi, agenttipohjaisen insinöörityön kautta: se, mitä tarvitaan, kuvataan selkokielellä ja generoidaan nopeasti, mutta aina lujien arkkitehtuuriperiaatteiden puitteissa ja tiukan laadunvarmistuksen alaisena, niin ettei nopeus koskaan tule johdonmukaisuuden, tietoturvan tai hallinnan kustannuksella. Vaikutus on strateginen eikä pelkästään kätevä. Se siirtää tee tai osta -rajaa, pitää optioiden hinnan alhaisena ja antaa arkkitehtuurin seurata strategiaa sen sijaan, että strategia taipuisi sen mukaan, mitä sattui olemaan hyllyllä.

Tuo yhdistelmä, syvä arkkitehtoninen täsmällisyys datan semantiikassa ja liikkeessä, yhdistettynä platformiin, joka kuljettaa syntyneet määritelmät, omistajuuden ja lineage-tiedon päivittäiseen toimintaan, on se, mikä antaa organisaation siirtyä tietueiden kartuttamisesta itsestään todella päättelemiseen. Menestyksen mitta on hiljainen ja konkreettinen. Sama kysymys esitettynä kahdessa liiketoiminnan osassa palauttaa saman vastauksen, raportin luku voidaan jäljittää ilman palaveria, ja uusi analyyttinen tai generatiivinen työ voidaan rakentaa datan päälle, jonka merkitys ymmärretään ja johon luotetaan. Nashua on olemassa saadakseen organisaatiot tuohon tilaan ja jättääkseen ne kykeneviksi pitämään sen.