Linkittäminen ei ole hallitsemista
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)
Luku 6 kurssilla Data Architect, Osa 1: Tietoarkkitehdiksi. Edellinen: Tietojen laatu ja hallinta.
”Tarvitsemme yhden totuuden lähteen.” Se on yksi arkkitehtuurin toistetuimmista lauseista ja yksi vähiten tutkituista. Minkä suhteen? Otetaan yksi tili. ERP voi omistaa sen virallisen nimen, laskutusosoitteen ja luottorajan; Salesforce sen myyntivastaavan ja tukitason; suostumusalusta sen markkinointiasetukset. Kolme auktoriteettia yhdessä tietueessa, ja se on normaalia. Joten kun joku sanoo: ”Salesforce on asiakkaan yksi totuuden lähde”, seuraava kysymykseni on aina: mikä totuus?
Tämä luku käsittelee sitä, miten tuohon kysymykseen vastataan tarkoituksella. Auktoriteetti määrätään attribuutti kerrallaan. Tietueiden linkittäminen ei ole niiden hallitsemista. Ja Salesforce antaa eri työkalut eri tehtäviin: kaksoiskappaleiden hallinta ja yhdistäminen yhden orgin sisällä; Data 360:n identiteetin selvitys (identity resolution) yhtä näkymää varten lähteiden yli; erillinen MDM-alusta, kun arvot on päätettävä kerran ja työnnettävä takaisin kaikkialle. Luku päättyy tarkistuspisteeseen 1, jossa osa 1 kootaan yhteen Steve Truckingin kohdalla.
Kuva on luotu tekoälyllä.
Tämän luvun kannat
Osio nimeltä “Tämän luvun kannat ”- Totuus attribuuttia kohden. Kysy, missä kukin tieto luodaan, missä sitä muokataan ja mihin siihen viitataan, ja kuinka nopeasti se muuttuu. Näytä ulkoinen auktoriteetti skeemassa järjestelmäetuliitteellä, kuten
sap_taierp_. - Prospektit ovat eri asia. Ne elävät Salesforcessa ennen kuin ERP tietää niistä; ERP:n auktoriteetti pätee konversion jälkeen.
- Rekisteri (registry) on normi Salesforce-projekteissa, sitten konsolidointi ja rinnakkaiselo (coexistence); puhdas keskitetty MDM on harvinainen.
- Yhdistä vain, kun voittaja on selvä. Säilytä ulkoisista latauksista tulleet kaksoiskappaleet, kun saatat joutua jäljittämään taaksepäin; yhdistäminen tuhoaa sen historian. Ja päätä, mitä lapsitietueille tapahtuu: siirrä ne, jätä ne lataamatta tai pidä ne passiivisessa tietueessa.
- Yhtenäinen profiili on kartta; golden record on päätös. Tämä voi hämmentää: identiteetin selvitys luo yhtenäisen yksilön, mutta ei golden recordia.
- Täsmäytyksen tiukkuus on riskipäätös. Kun sekoittuminen tulee kalliiksi, täsmäytä tarkoituksella liian vähän.
- Kolme työkalua kolmeen tehtävään: yhdistäminen, identiteetin selvitys, MDM.
- Hierarkioilla on jaettu hallinta. Päätä auktoriteetti haara kerrallaan.
- ”Vaikeimpia ovat kaksisuuntaiset.” Kaksisuuntainen integraatio ei tee kahta masteria. Päätä ennen ensimmäistä törmäystä, mitkä kentät kulkevat yhdessä yhtenä transaktiona.
- Tee perustiedot näkyviksi. Kenttä, joka kertoo, että kyse on perustiedoista (ERP:n avain tai lippu), ohjaa muokattavuutta, ei tietuetyyppi.
- Emme hallitse ERP-järjestelmiä. Hallitsemme sitä, miten esitämme ne Salesforcessa: yksi asiakas kahdessa ERP:ssä on hierarkia, vertaiset tai yksi tili, jolla on lapsi kutakin ERP:tä kohden, ja ratkaisu riippuu siitä, kuinka hyvin asiakas pitää ERP-järjestelmänsä synkronissa.
Kolme työkalua kolmeen tehtävään
Osio nimeltä “Kolme työkalua kolmeen tehtävään ”| Tehtävä | Työkalu | Mitä se tekee lähteille |
|---|---|---|
| Kaksoiskappaleet yhden orgin sisällä, selvä voittaja | Kaksoiskappaleiden hallinta ja yhdistäminen | Yhdistää enintään kolme tietuetta; muut menevät roskakoriin |
| Yksi identiteetti ja yksi näkymä lähteiden yli | Data 360:n identiteetin selvitys | Linkittää ne; ei muuta yhtäkään niistä (rekisteri) |
| Yksi hallittu arvo, joka työnnetään takaisin jokaiseen järjestelmään | Erillinen MDM-alusta | Päättää arvon ja jakelee sen (rinnakkaiselo tai keskitetty) |
Polku tämän luvun läpi
Osio nimeltä “Polku tämän luvun läpi ”Kuusi moduulia ja tehtävä, jokainen itsenäinen.
- Yksi totuuden lähde kutakin attribuuttia kohden. Auktoriteettikartta, hybridi golden record ja luottamussignaalit.
- Neljä tapaa hallita perustietoja. Rekisteri, konsolidointi, rinnakkaiselo ja keskitetty, ja miksi yhteinen malli ei ole yhteinen totuus.
- Täsmäytys, yhdistäminen ja säilymissäännöt. Väärän täsmäytyksen hinta, mitä Salesforcen yhdistäminen todella tekee (ja mitä lapsitietueille tapahtuu), ja säilymissäännöt lausumana luottamuksesta.
- Kartta ei ole päätös. Täsmäytyssäännöt ja täsmäytysmenetelmät, sovitussäännöt ja miksi yhtenäinen profiili ei ole golden record.
- Kun auktoriteetti on jaettu. Pyynnöt vs. päivitykset, silmukat ja törmäykset, hierarkiat jaetulla hallinnalla ja yksi asiakas kahdessa ERP:ssä.
- Tarkistuspisteen 1 tehtävä, sitten Tarkistuspiste 1 – Steve Trucking: näin minä sen suunnittelisin. Kokeile tehtävää ensin: piirrä ja perustele osan 1 suunnitelma, vertaa sitä sitten omaani ja katso, mikä muuttuu luvun 4 järjestelmäkartasta.
Kun olet valmis, testaa itsesi luvun opiskeluoppaalla: tarkistuslista koetta varten, tavat kokeen jälkeen, tärkeät termit ja muutama kysymys. Se päättää osan 1; osan 1 opiskeluopas kokoaa kaikki kuusi lukua yhteen.
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, ja miten se näkyy mallissa.
- Mikä hallintatyyli sopii kullekin tietoalueelle, ja kuinka paljon auktoriteettia hallintakerros saa.
- Milloin yhdistetään, milloin linkitetään, ja kuka omistaa kunkin säilymissäännön.
- Kuinka tiukkaa täsmäytyksen pitäisi olla, sen perusteella, mitä väärä täsmäytys maksaa.
- Missä kaksisuuntaiset tiedot ja jaetut hierarkiat tarvitsevat selvät rajat.
Kokeen jälkeen: agentit tarvitsevat yhden identiteetin, jonka perusteella toimia, ja se nostaa panoksia molempiin suuntiin. Liiallisesta täsmäytyksestä tulee tietosuojapoikkeama, ja agentin, joka ”päivittää asiakkaan”, on kirjoitettava kunkin attribuutin system of recordiin (lähdejärjestelmään), ei yhtenäiseen profiiliin. Jokainen moduuli päättyy siihen, mitä tekoäly muuttaa.
Lue lisää
Osio nimeltä “Lue lisää ”- Salesforce Architects, Data 360 Architecture (opens in a new tab) (englanniksi, tarkistettu 2026-10-14).
- Salesforce Help, Considerations for Merging Duplicate Accounts (opens in a new tab), Identity Resolution Match Methods (opens in a new tab) ja Identity Resolution Reconciliation Rules (opens in a new tab) (englanniksi, tarkistettu 2026-10-14).
Seuraava: osa 2 alkaa luvulla Suunnittelu mittakaavaa varten (coming soon).