Yksi totuuden lähde kutakin attribuuttia kohden
Saatavilla myös 28 kielellä
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Español (México) · Français (Canada) · Deutsch (Schweiz)
Moduuli 1/6 luvussa Perustiedot ja identiteetti, Data Architect -kurssin luku 6. Jokainen moduuli on itsenäinen. Seuraava: Neljä tapaa hallita perustietoja
Kysymys, johon tämä moduuli vastaa: Mitä ”yksi totuuden lähde” oikeasti tarkoittaa?
Kuulen jatkuvasti saman lauseen: ”Tarvitsemme yhden totuuden lähteen.” Selvä. Minkä suhteen? Asiakkaan? Se ei ole tarpeeksi tarkka. Otetaan tili. Kuka omistaa asiakkaan nimen, laskutusosoitteen, luottorajan, myyntivastaavan, tukitason, markkinointiasetukset? Vastaukset eivät osoita samaan järjestelmään. ERP voi hallita virallista nimeä, laskutusosoitetta ja luottotilannetta; Salesforce asiakkuuden omistajaa ja myynnin attribuutteja; jokin toinen alusta suostumusta. Joten kun joku sanoo minulle: ”Salesforce on asiakkaan yksi totuuden lähde”, seuraava kysymykseni on: mikä totuus?
Totuus kuuluu attribuutille
Osio nimeltä “Totuus kuuluu attribuutille ”Perustietojen ensimmäinen periaate on tämä: auktoriteetti määrätään attribuuttia kohden, ei tietuetta kohden. Tili voi elää Salesforcessa ilman, että Salesforce on auktoritatiivinen sen jokaisen kentän osalta. Seitsemän kenttää yhdessä tietueessa, kaksi auktoriteettia:
| Attribuutti | Auktoritatiivinen järjestelmä |
|---|---|
| Virallinen nimi, laskutusosoite, ERP:n asiakas-ID, luottoraja | ERP |
| Myyntivastaava, strategisen asiakkaan lippu, asiakasmenestyksen taso | Salesforce |
Yksi tietue; totuus on hajautettu. Se on normaalia. ”System of record = Salesforce” ei kuvaa sitä. Auktoriteettimalli kuvaa.
Luotu, muokattu, viitattu ja kuinka nopeasti?
Osio nimeltä “Luotu, muokattu, viitattu ja kuinka nopeasti? ”Kun opetan perustietoja, palaan jokaisen tärkeän tiedon kohdalla samoihin kysymyksiin: missä se luodaan, missä sitä muokataan, missä siihen viitataan ja mikä on sen muutoksen viive? Ne paljastavat arkkitehtuurin nopeasti. (Kolme ensimmäistä tapasit luvussa 4, kun lajittelimme tietojen lajeja; tässä ne tekevät varsinaisen työnsä.)
Otetaan omaisuuserä (asset). Asiakas tilaa kolme polkupyörää. Salesforcessa on myyntimahdollisuus ja sen rivit, ja tilaus menee ERP:hen. ERP toimittaa sen, ja siellä omaisuuserät luodaan: kolme polkupyörää, kolme sarjanumeroa, jotka lähetetään takaisin Salesforceen. Kuukausia myöhemmin asiakas soittaa yhdestä niistä, ja tuki viittaa omaisuuserään tapauksessa. Nyt jonkun pitää korjata jokin attribuutti. Mitä niistä Salesforce saa muokata, ja mitkä kuuluvat ERP:lle, joka ne loi? Ja kun ERP muuttaa jotain, kuinka nopeasti Salesforcen on saatava tietää? Yksi omaisuuserä, neljä kysymystä, eivätkä vastaukset ole samat joka kentälle.
Sanotaan, että virallinen nimi luodaan ERP:ssä ja siihen viitataan Salesforcessa, ja myyjä huomaa sen olevan väärin. Pitäisikö hänen korjata se Salesforcessa? Jos ERP omistaa kentän, kopion muuttaminen ei korjaa mitään. Parhaassa tapauksessa seuraava synkronointi kirjoittaa sen yli; pahimmassa tapauksessa järjestelmät ovat nyt eri mieltä, eikä kukaan tiedä, kumpaan luottaa. Jos liiketoiminta haluaa myyjän aloittavan korjauksen, tilanne on toinen: Salesforce tarjoaa käyttökokemuksen, lähettää pyynnön ERP:hen, ERP tekee tai hyväksyy muutoksen, ja auktoritatiivinen arvo palaa takaisin. Se on hyvin erilainen arkkitehtuuri kuin se, että Salesforce saa muokata kenttää omin päin.
Viivekin on osa totuutta. ERP muuttaa asiakkaan luottotilannetta klo 10.00; Salesforce synkronoi sen yöllä; klo 15.00 myyjä katsoo Salesforcea. Onko arvo väärä? Se on vanhentunut. Jos arvo muuttuu kerran vuodessa eikä päivän viive maksa mitään, yöajo riittää. Jos se ratkaisee, hyväksytkö tänään miljoonan dollarin tilauksen, ei riitä. Auktoriteetti kertoo, mistä totuus tulee; viive kertoo, kuinka nopeasti muiden on saatava tietää sen muuttuneen. Kaksi erillistä päätöstä.
System of record, vuorovaikutusjärjestelmä, viitejärjestelmä
Osio nimeltä “System of record, vuorovaikutusjärjestelmä, viitejärjestelmä ”Luvun 4 sanasto auttaa tässä. System of record (lähdejärjestelmä) ylläpitää auktoritatiivista versiota. Vuorovaikutusjärjestelmä (system of engagement) on se, jossa ihmiset työskentelevät tietojen kanssa. Viitejärjestelmä (system of reference) toimittaa tietoja, joita toinen järjestelmä käyttää mutta ei omista. Salesforce voi olla asiakassuhteen vuorovaikutusjärjestelmä, kun taas ERP pysyy virallisten ja taloudellisten attribuuttien system of recordina. Se ei ole arkkitehtuurin heikkous; se on arkkitehtuuri. Virhe on teeskennellä, että yhden järjestelmän on omistettava kaikki, jotta kaavio näyttäisi yksinkertaisemmalta.
Hybridi golden record
Osio nimeltä “Hybridi golden record ”Se muuttaa sitä, mitä ”golden record” tarkoittaa. Luku 5 esitteli ajatuksen huonojen tietojen ulkona pitämisen yhteydessä; tässä se on suunnittelun ydin. Ihmiset kuvittelevat yhden maagisen tietueen, jonka jokaista kenttää hallitaan yhdessä paikassa. Joskus suunnitelma on juuri se. Salesforcessa näen useammin hybridin: osaa tilistä hallitaan muualla ja se kopioidaan sisään (virallinen nimi, ERP:n asiakasnumero, laskutusosoite, luottotilanne), ja osa on olemassa vain siksi, että Salesforce tarvitsee sitä (myyntivastaava, myyntimahdollisuuksien strategia, asiakasmenestyksen taso, asiakassuhteen muistiinpanot). ERP:n kentät tulevat sisään, jotta ihmiset voivat käyttää niitä. Salesforcen kentät eivät koskaan palaa takaisin, koska ERP ei välitä niistä. Täysin järkevää, kunhan kaikki tietävät, mikä on mitäkin.
Tee auktoriteetti näkyväksi
Osio nimeltä “Tee auktoriteetti näkyväksi ”Siksi teen ulkoisen auktoriteetin skeemassa ilmeiseksi. Jos SAP hallitsee kenttää, se saa etuliitteen: sap_Customer_Number, sap_Credit_Status, sap_Legal_Name. Ajatus on sama kuin luvun 4 erp_-etuliitteessä. Käytä järjestelmän nimeä, kun auktoriteetti on tietty ja vakaa, ja yleistä etuliitettä, kun merkitys on tärkeämpi kuin tämän päivän toimittaja. Pointti on, että puolen vuoden päästä mallia lukeva näkee: tämä ei ole vain yksi Salesforce-kenttä lisää; tämän arvon omistaa toinen järjestelmä. Älä pakota ihmisiä löytämään auktoriteettia uudelleen purkamalla integraatioita auki.
Rakenna auktoriteettikartta
Osio nimeltä “Rakenna auktoriteettikartta ”Tärkeille perustiedoille haluan auktoriteettikartan: kunkin avainattribuutin osalta kuka sen luo, kuka omistaa liiketoimintapäätöksen, mikä järjestelmä on auktoritatiivinen ja kuka tai mikä saa muuttaa sitä. Neljä eri kysymystä:
| Attribuutti | Luoja | Liiketoiminnan omistaja | Auktoritatiivinen järjestelmä | Saa muuttaa |
|---|---|---|---|---|
| Virallinen nimi | Taloushallinto | Taloushallinto | ERP | Taloushallinnon prosessi |
| Luottoraja | Taloushallinto | Taloushallinto | ERP | Luottotiimi |
| Myyntivastaava | Myynnin operaatiot | Myynti | Salesforce | Myynnin johto |
| Tukitaso | Palvelun operaatiot | Palvelu | Salesforce | Palvelun johto |
| Suostumus | Asiakas | Tietosuoja | Suostumusalusta | Asiakas, hyväksytty prosessi |
Huomaa, että liiketoiminnan omistaja ja auktoritatiivinen järjestelmä eivät ole sama asia. Järjestelmä ei omista käytäntöä; ihmiset omistavat. Järjestelmä tallentaa ja panee täytäntöön lopputuloksen. Taas luku 5: omistajat päättävät käytännöt, arkkitehdit panevat ne täytäntöön.
Yksi asiakas. Monta attribuuttia. Kullekin yksi auktoriteetti.
Auktoriteetti muuttuu elinkaaren aikana
Osio nimeltä “Auktoriteetti muuttuu elinkaaren aikana ”Myyjä tapaa prospektin, josta ERP ei ole koskaan kuullut, ja luo tilin Salesforceen. Siinä vaiheessa Salesforce on auktoritatiivinen nimen, osoitteen, yhteyshenkilöiden ja kvalifioinnin osalta. Prospektista tulee asiakas; ERP luo virallisen asiakkaan ja antaa asiakasnumeron, virallisen nimen, laskutusosoitteen ja luoton. Auktoriteetti siirtyi. Salesforce ei ollut aiemmin väärässä; elinkaari muuttui. Se on luvun 5 kaava väliaikaisesta hallittuun: ennen konversiota Salesforce omistaa prospektin; sen jälkeen ERP omistaa hallitut attribuutit, ja Salesforce omistaa edelleen omansa. Siksi ”mikä järjestelmä omistaa tilin?” on heikko kysymys. Kysy: mikä järjestelmä omistaa tämän attribuutin tässä elinkaaren vaiheessa?
Kopio ei ole auktoriteetti
Osio nimeltä “Kopio ei ole auktoriteetti ”Kopioimme ERP:n tietoja Salesforceen, koska ihmiset tarvitsevat niitä jatkuvasti. Se tekee Salesforcesta kätevän paikallisen kopion, ei masteria, ja arkkitehtuurin pitää käyttäytyä sen mukaan: käyttäjille vain luku, integraatio päivittää, lähde merkitty, muutokset vain pyynnön kautta, täsmäytys tarkistaa, kun kopio ajautuu erilleen. Kopio on hyödyllinen. Auktoriteetti ei ole siirtynyt.
Luottamus tarvitsee muutakin kuin arvon
Osio nimeltä “Luottamus tarvitsee muutakin kuin arvon ””Laskutusosoite: Pääkatu 123.” Pitäisikö siihen luottaa? Haluan luottamussignaaleja: mistä se tuli, milloin se viimeksi vahvistettiin, mikä järjestelmä sen toimitti ja kuka tai mikä sen viimeksi muutti: ihminen, integraatio, agentti? Nyt ERP sanoo Pääkatu 123, Salesforce sanoo 125, ja kumppanin tiedosto sanoo ”Pääk. 123, krs 2”. Mikä on oikein? Älä vastaa ”käytä uusinta”. Ehkä. Mutta ”uusin” on itsessään sääntö, joka olettaa, että viimeisin muuttaja ansaitsee voittaa. Se voi olla totta, tai kamalaa. Moduuli 3 tarttuu tähän. Luottamus tulee auktoriteetista ja alkuperästä, ei siitä, että löydät kentän, joka on täytetty.
Steve Trucking: kenen totuus se on?
Osio nimeltä “Steve Trucking: kenen totuus se on? ”Vähittäiskauppakumppani (Retail Partner) lähettää toimituksen, ja siihen yhteen transaktioon kätkeytyy useita totuuksia. Kumppanin tilausviite on kumppanin; Steve Trucking säilyttää sen päivitysten täsmäyttämiseksi, mutta ei ryhdy sen masteriksi. Toimituksen tila (saapunut, toimitettu, asennettu, poikkeus) on Steve Truckingin; kumppani vastaanottaa sen, mutta tilan vastaanottaminen ei tee kumppanista auktoritatiivista sen suhteen, mitä kuorma-autolla tapahtui. Ja vastaanottaja (Recipient) on kumppanin asiakas. Kumppani toimittaa nimen, osoitteen, puhelinnumeron ja toimitusohjeet, koska Steve Trucking tarvitsee niitä toimittaakseen. Se ei tee Steve Truckingista sen henkilön identiteetin masteria, ja juuri se ero ratkaisee vastaanottajan suunnittelun tarkistuspisteessä.
Yksi toimitus, kaksi auktoriteettia.
Se, missä tiedot asuvat, ja se, kuka omistaa niiden totuuden, ovat eri kysymyksiä. Salesforce voi säilyttää ERP:n asiakasnumeroa omistamatta sitä; Snowflake voi säilyttää toimituksen tilaa olematta sen operatiivinen master; asiakastietoalusta voi yhtenäistää identiteetit omistamatta jokaista attribuuttia. Agentti voi lukea kaikkia kolmea, eikä se todellakaan anna agentille oikeutta päättää, mikä on totta.
Kokeen jälkeen: mitä tekoäly muuttaa. Agentit muuttavat attribuuttien auktoriteetin suoritussäännöksi. Ihminen näkee väärän laskutusosoitteen ja tietää: ”tuo tulee SAP:sta; minun ei pitäisi muuttaa sitä täällä.” Agentti, jota pyydetään ”päivittämään asiakkaan laskutusosoite”, ei tiedä sitä, ellemme suunnittele sitä varten. Se tarvitsee saman auktoriteettikartan kuin arkkitehti: pääsy kenttään ei tee siitä kentästä oikeaa paikkaa kirjoittaa.
Mitä arkkitehti tässä päättää
Osio nimeltä “Mitä arkkitehti tässä päättää ”- Mikä järjestelmä on auktoritatiivinen kunkin tärkeän attribuutin osalta, eikä yksi järjestelmä koko tietueelle.
- Missä kukin attribuutti luodaan, missä sitä muokataan ja missä siihen viitataan, ja kuinka nopeasti sen muutosten on kuljettava.
- Kuka päättää kunkin attribuutin käytännön ja ketkä ihmiset, integraatiot tai agentit saavat muuttaa sitä.
- Miten ulkoinen auktoriteetti näkyy mallissa: nimeämisen etuliitteet, käyttöoikeudet, integraatioiden käyttäytyminen.
- Miten auktoriteetti siirtyy elinkaaren aikana, esimerkiksi kun prospektista tulee ERP:n hallitsema asiakas.
Yksi totuuden lähde ei tarkoita yhtä orgia, yhtä ERP:tä, yhtä MDM-alustaa tai yhtä jättimäistä tietuetta. Se tarkoittaa, että kunkin hallitun tiedon osalta arkkitehtuuri osaa sanoa, missä auktoritatiivinen arvo on, ja jokainen muu järjestelmä tietää sen ansiosta, miten käyttäytyä. Se ei ole yksi totuuden lähde. Se on totuuden arkkitehtuuri.
Lue lisää
Osio nimeltä “Lue lisää ”- Salesforce Architects, Data 360 Architecture (opens in a new tab) (englanniksi, tarkistettu 2026-10-14).