Siirry sisältöön

Omistajat päättävät käytännöt, arkkitehdit panevat ne täytäntöön

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 5 kurssilla Data Architect, Osa 1: Tietoarkkitehdiksi. Edellinen: Yrityksen tietojen ymmärtäminen.

Kun sanot ”tietojen hallinta” (data governance), ihmiset näkevät mielessään kokouksia: komiteoita, käytäntöjä, asiakirjan, jota kukaan ei lue. Minä kysyn joka kerta eri kysymyksen: missä käytäntö pannaan täytäntöön?

Jos käytännön mukaan vain taloushallinto saa muuttaa asiakkaan virallista nimeä, mikä estää muita? Jos sen mukaan tiimit näkevät vastaanottajan osoitteen vain omilla pysähdyksillään ja vain sinä päivänä, mikä tekee siitä totta? Jos sen mukaan tämä säilytetään seitsemän vuotta, mikä poistaa sen seitsemän vuoden jälkeen? Käytäntö ilman täytäntöönpanokohtaa on enimmäkseen toive. Kantani on yksinkertainen: omistajat päättävät käytännöt, arkkitehdit panevat ne täytäntöön. Tietojen omistaja päättää. Arkkitehdin suunnittelema järjestelmä tekee siitä mekaanisesti totta.

Äläkä odota, että työ joskus valmistuu. Tietojen hallinta ei ole koskaan valmis. Se kulkee aaltoina ja pitää pahimmat huonot tiedot ulkona. Se on yksinkertaista, kun Salesforce on yksin, ja vaikeampaa, ja tarpeellisempaa, kun Salesforce on yksi solmu luvussa 4 piirtämässämme järjestelmäkartassa. Siksi se luku tuli ensin: järjestelmäkartta kertoo, kuinka pitkälle hallinnan on ulotuttava.

Talousjohtaja selittää tietojen käytäntöjä, ja arkkitehti kiinnittää taululle sen, mikä panee kunkin täytäntöön: vahvistus, jakaminen ja säilytys

Kuva on luotu tekoälyllä.

  • Pyöritä ohjelmaa niin kuin yritys toimii: keskitetysti, hajautetusti (federoidusti) tai hybridinä; arkkitehdin on tiedettävä, kuka hyväksyy käytännön.
  • Tietueen omistaja ei ole tietojen omistaja. Owner-kenttä ohjaa kohdistamista ja pääsyä; vastuu tiedoista on liiketoiminnalla.
  • Avoin tai lukittu luonti riippuu tietoja ympäröivästä hallinnasta. Avoin sopii useimmille pienille ja keskisuurille orgeille; lukitse se, kun tilit hallitaan ERP:ssä tai synkronoidaan sen kanssa; keskitie on väliaikainen tietuetyyppi, josta muunnetaan hallitusti hallittuun tietuetyyppiin.
  • Jos ERP hallitsee kenttää, et muuta sitä, vaan pyydät muutosta. Golden record on hybridi: ERP:n hallitsemat kentät tulevat sisään, Salesforcen omat kentät eivät koskaan palaa takaisin, ja kaksisuuntaiset virrat tarvitsevat törmäyssäännön.
  • Luokittele arkaluonteiset kentät, älä jokaista kenttää. Dokumentoi laajasti, luokittele harkiten; pidä sekä liiketoiminnan että tekniset metatiedot.
  • Opeta säädökset. Moni arkkitehti ei ole koskaan kuullutkaan oman alueensa ulkopuolisista laeista, ja nämä lait muovaavat järjestelmien suunnittelua.
  • Käytä valmista suostumusmallia aina kun voit, älä rakenna sitä uudelleen.
  • Oikeudessa tulla unohdetuksi hallitse ensin, minne henkilötiedot menevät. Poistaminen on harvinaista ja vaikeaa; suunnittele niin, että henkilötiedot päätyvät harvoihin paikkoihin, ja jäljitä sitten jokainen kopio: kenttähistoria, arkistot, analytiikan kopiot, hakuindeksit ja agenttien keskustelut, ennen kuin aika loppuu.
  • Shield on vastaus keskeisiin sääntelyvaatimuksiin, kuten levossa olevien tietojen salaukseen, ja sen kompromissit otetaan huomioon suunnittelussa.
  • Field Audit Trail, kun ala on säännelty. Tavallinen kenttähistoria on oletus.
  • Ota Event Monitoring käyttöön ennen kuin tarvitset sitä, ja suoratoista tapahtumat säilöön, kuten Splunkiin. Et halua törmätä ongelmaan ja huomata vasta silloin, ettet ole tallentanut niitä.
Hallittu tietojen elinkaari Hallittu tietojen elinkaari seitsemässä vaiheessa, kussakin kysymys ja esimerkkejä Salesforcen mekanismeista. Kerää: onko se tarpeeksi hyvää päästettäväksi sisään? Vahvistussäännöt, kaksoiskappalesäännöt, pakolliset kentät, laatuportti; moduuli 2. Luokittele: kuinka arkaluonteista se on? Tietojen luokittelun kentät luottamuksellisuudelle, vaatimustenmukaisuudelle ja omistajalle; moduuli 3. Suojaa: kuka saa nähdä ja muuttaa sitä? Jakaminen, oikeudet, kenttien käyttöoikeudet, Shield-salaus ja sandboxien peittäminen; moduuli 6. Käytä: onko tämä käyttö sallittua? Suostumusmalli, tietojen käyttötarkoitus sekä integraatioiden ja agenttien pääsy; moduuli 5. Säilytä: kuinka kauan säilytämme sitä? Säilytyskäytännöt, arkistot, big objectit; moduuli 6. Poista: mitä lopussa tapahtuu? Privacy Center, poistotyöt, tunnistettavuuden poisto; moduuli 5. Tarkasta: voimmeko todistaa sen? Kenttähistoria, Field Audit Trail ja Event Monitoring SIEMiin lähetettynä; moduuli 6. Alla: työkalut tukevat käytäntöä; ne eivät määritä sitä. VAIHE KYSYMYS SALESFORCEN MEKANISMIT, ESIMERKIKSI OPETETAAN 1 · Kerää Onko se tarpeeksi hyvää päästettäväksi sisään? Vahvistussäännöt, kaksoiskappalesäännöt, pakolliset kentät, laatuportti Moduuli 2 2 · Luokittele Kuinka arkaluonteista se on? Tietojen luokittelun kentät: luottamuksellisuus, vaatimustenmukaisuus, omistaja Moduuli 3 3 · Suojaa Kuka saa nähdä ja muuttaa sitä? Jakaminen, oikeudet, kenttien käyttöoikeudet, Shield-salaus, sandboxien peittäminen Moduuli 6 4 · Käytä Onko tämä käyttö sallittua? Suostumusmalli, tietojen käyttötarkoitus, integraatioiden ja agenttien pääsy Moduuli 5 5 · Säilytä Kuinka kauan säilytämme sitä? Säilytyskäytännöt, arkistot, big objectit Moduuli 6 6 · Poista Mitä lopussa tapahtuu? Privacy Center, poistotyöt, tunnistettavuuden poisto Moduuli 5 7 · Tarkasta Voimmeko todistaa sen? Kenttähistoria, Field Audit Trail, Event Monitoring SIEMiin Moduuli 6 Työkalut tukevat käytäntöä; ne eivät määritä sitä. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Seitsemän kysymystä tietojen elinkaaren aikana. Työkalut tukevat käytäntöä; ne eivät määrittele sitä.

Kuusi moduulia, jokainen itsenäinen.

  1. Hallinta suunnitellaan orgiin. Omistajat, vastuuhenkilöt ja ylläpitäjät; keskitetty, hajautettu tai hybridi; tietueen omistaja vs. tietojen omistaja; jokaisen käytännön muuttaminen täytäntöönpanokohdaksi.
  2. Huonojen tietojen pitäminen ulkona. ”Riittävän hyvä” liiketoiminnan määritelmänä; avoin vs. lukittu luonti, väliaikainen tietue ja tietuetyyppi kullekin virralle; hybridi golden record ja kaksisuuntaiset virrat; laatupäätös jokaisella tietojen rajalla.
  3. Tunne tietosi: sanasto, alkuperä ja luokittelu. Liiketoiminnan ja tekniset metatiedot; mitä tieto tarkoittaa, mistä se tuli, miten sitä on käsiteltävä ja miksi luokittelu ilman täytäntöönpanoa on pelkkää koristetta.
  4. Tietosuojalait muovaavat suunnittelua. Lait, jotka on syytä tunnistaa, mitä niillä on yhteistä (oikeudet, siirrot, tietoturvaloukkauksista ilmoittaminen, osoitusvelvollisuus) ja kysymykset, jotka elävät niitä pidempään; anonymisoitu vs. pseudonymisoitu; vaatimustenmukaisuus ei ole tuote.
  5. Suostumus ja oikeus tulla unohdetuksi. Suostumus tietona, vakiomuotoinen suostumusmalli, jokaiseen pyyntöön liittyvä määräaika ja poistamisen suunnittelu ennen kuin ensimmäinen pyyntö saapuu.
  6. Suojaa, säilytä ja todista. Salauksen kompromissit, sandboxit, säilytys, kenttähistoria ja Field Audit Trail sekä Event Monitoring, joka otetaan käyttöön ennen tarvetta.

Kun olet valmis, testaa itsesi luvun opiskeluoppaalla: tarkistuslista koetta varten, tavat kokeen jälkeen, tärkeät termit ja muutama kysymys.

  • Kuka omistaa kunkin tärkeän tietoalueen, ja mikä panee kunkin omistajan käytännön täytäntöön.
  • Mitkä huonot tiedot pidetään ulkona, ja mitkä napataan kiinni, eristetään ja korjataan myöhemmin.
  • Mitkä kentät ovat arkaluonteisia, ja mitä se luokittelu muuttaa.
  • Minne henkilötiedot menevät, mihin niitä saa käyttää ja miten ne poistetaan jokaisesta kopiosta.
  • Kuinka kauan tietoja ja niiden historiaa säilytetään, ja millä näytöllä voidaan todistaa, mitä tapahtui.

Tämä luku on arkkitehtuuriohjeistusta, ei oikeudellista neuvontaa. Lakiasioiden ja compliancen tiimit päättävät, mitkä lait ovat sovellettavia ja mitä ne vaativat; arkkitehti muuntaa nämä vaatimukset suunnitteluksi.

Kokeen jälkeen: tietojen hallinnalla on uusi kuluttaja, agentti. Luokittelu ratkaisee, mitä se saa hakea, suostumus ratkaisee, mihin se saa tietoja käyttää, ja alkuperän ja auditoinnin on ulotuttava aina siihen asti, mitä se sanoi ja teki. Jokainen moduuli päättyy siihen, mitä tekoäly muuttaa sen osassa elinkaarta.

Seuraava: Perustiedot ja identiteetti