Salesforcea ympäröivät järjestelmät

🌐 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)

Kuva on luotu tekoälyllä

Tekoälyn kääntämä. Yhteisö ei ole vielä tarkistanut käännöstä. Lue englanniksi

Moduuli 3/6 luvussa Yrityksen tietojen ymmärtäminen, Data Architect -kurssin luku 4. Jokainen moduuli on itsenäinen. Edellinen: Yrityksen tietojen lajit · Seuraava: Piirrä järjestelmäkartta

Kysymys, johon tämä moduuli vastaa: Mikä ympäröi Salesforcea, ja mikä rooli kullakin järjestelmällä on?

Edellinen moduuli lajitteli tiedot. Nyt haluan sijoittaa ne jonnekin, ja juuri tässä Salesforce-arkkitehdit joutuvat vaikeuksiin. Tunnemme Salesforcen, joten asiakastiedot tarkoittavat tiliä, tilaustiedot Orderia, asiakirjat Filesia ja analytiikka raportteja. Mutta yritys ei ostanut Salesforcea korvatakseen kaiken muun, mitä se omistaa. Siellä voi olla ERP, joka pyörittää taloutta ja toimitusten toteutusta, tietovarasto, jossa on vuosien historia, integraatioalusta, identiteetinhallinnan palvelu, kumppanien järjestelmiä, tapahtuma-alusta, MDM-alusta ja Data 360 yhdistämässä useita niistä. Tehtävä ei ole teknologioiden ulkoa opettelu. Se on sen ymmärtämistä, mikä tehtävä kullakin järjestelmällä on.

Älä aloita tuotteen nimestä

”Meillä on SAP” ei kerro minulle tarpeeksi. Ei myöskään Snowflake, MuleSoft, Tableau tai Data 360. Haluan tietää, mitä järjestelmä tekee tässä arkkitehtuurissa: mitä tietoja se omistaa, mitä se lukee, mitä se muuttaa, kuka sitä käyttää, mikä riippuu siitä ja mitä tapahtuu, kun se on alhaalla. Kahdella yrityksellä voi olla täsmälleen samat tuotteet ja täysin erilaiset arkkitehtuurit.

Siksi nimeän järjestelmät roolin mukaan. Neljä roolia kattaa suurimman osan:

• System of record (lähdejärjestelmä): paikka, jossa jonkin asian auktoritatiivista versiota ylläpidetään.
• Vuorovaikutusjärjestelmä (system of engagement): paikka, jossa ihmiset tekevät työn.
• Viitejärjestelmä (system of reference): paikka, josta järjestelmä hakee tietoja, joita se tarvitsee mutta ei omista.
• Näkemysjärjestelmä (system of insight): paikka, jossa tiedot kootaan yhteen mittaamista, analysointia ja ennustamista varten.

Yksi alusta voi toimia useissa rooleissa, ja roolit vaihtelevat tietojen mukaan. Salesforce voi olla tapausten lähdejärjestelmä, asiakaspalvelijoiden vuorovaikutusjärjestelmä ja ERP:n omistamien tuotetietojen kuluttaja. Joten kun joku sanoo ”Salesforce on meidän system of record”, vie lause loppuun: system of record minkä osalta?

ERP: taustatoiminnoilla on painovoimaa

ERP on järjestelmä, jonka löydät useimmin Salesforcen vierestä, ja se pyörittää taloutta, varastoa, hankintoja, toimitusten toteutusta ja laskutusta. Moduulin 1 malli (asiakkaat ja tuotteet sisään, tilaukset ulos) tarkoittaa, että ERP omistaa tuotteet, mutta myyjät tarvitsevat niitä silti Salesforcessa. Hyvä: tuodaan ne sisään. Mutta tietojen kopioiminen ei siirrä omistajuutta. Kopio ei ole auktoriteetti.

Kantani: ERP:n omistamia tietoja luetaan paikallisesti ja kirjoitetaan hallitusti. Salesforcen käyttäjät saavat tiedot siellä, missä he työskentelevät, mutta Salesforce ei saa muuttaa sitä, minkä ERP omistaa. Ja teen sen näkyväksi skeemassa: ERP:n kentillä on erp_-etuliite, kuten erp_Product_Number__c, jotta jokainen objektia lukeva tietää, kuka omistaa kunkin kentän, ja on varovainen sitä muuttaessaan. Etuliite ei pakota mitään; sen tekevät käyttöoikeudet, vahvistus ja integraatiomalli. Se viestii tarkoituksen, ja se on auktoriteettikartta näkyväksi tehtynä.

Tietovarasto, tietoallas ja lakehouse

Operatiiviset järjestelmät pyörittävät liiketoimintaa; analyyttiset järjestelmät auttavat ymmärtämään sitä. ”Näytä avoimet myyntimahdollisuuteni” on Salesforce-raportti. ”Näytä viiden vuoden myynti, toimitukset, palautukset, tapaukset, varasto ja talous kaikissa kanavissa” on eri ongelma.

Kohtaat kolmenlaisia analyyttisiä säilöjä. Tietovarasto (data warehouse) sisältää analyysia varten valmisteltuja jäsenneltyjä tietoja. Tietoallas (data lake) sisältää paljon enemmän tietoja useammassa muodossa, usein raakana. Lakehouse yhdistää nämä kaksi: tietoaltaan tyyppinen tallennus ja tietovaraston tyyppinen analyysi. Tunne ne, koska ne näkyvät järjestelmäkartoissa. Mutta kokemukseni mukaan lakehouset ja data mesh ovat Salesforce-projekteissa yhä harvinaisia. Tyypillinen järjestelmäkartta on CRM, ERP, tietovarasto ja integraatiokerros, ja muita alustoja siellä, missä liiketoiminta niitä todella tarvitsee. Opettele arkkitehtuuri; älä jahtaa sanastoa.

Analytiikka asuu siellä, missä tiedot asuvat

Tämä on yksi vahvimmista kannoistani: analytiikan paikka seuraa tietojen paikkaa. Jos raportti tarvitsee vain tilit, myyntimahdollisuudet ja myyjät, kaikki on coressa: vakioraportit ja koontinäytöt. Sitten liiketoiminta pyytää lisäämään ERP:n laskut. Sitten tuotekustannukset. Sitten viiden vuoden tilaukset tietovarastosta. Sitten verkkosivuston toiminnan. Jossain vaiheessa kaiken sen raahaaminen operatiiviseen CRM:ään vain raportointia varten lakkaa olemasta järkevää. Kun mukana on muita tietovarastoja, analytiikka-alustasta tulee välttämätön: Tableau (myös Data 360:n päälle rakennettu Tableau Next) tai CRM Analytics siellä, missä se on jo käytössä. Se on välttämätön, kun Salesforcen tiedot yhdistetään tietovarastoon. Vaatimus ei vain monimutkaistunut; järjestelmäkartta muutti sen, missä kysymykseen pitäisi vastata. Siksi en koskaan aloita kysymyksellä ”mikä analytiikkatyökalu?” Aloitan kysymyksellä missä tiedot ovat?

Kysyn CTA-kandidaateilta samaa: ”Mikä kaavioistani ratkaisee tämän kauniisti? Järjestelmäkartta.” Jos kaikki on coressa, käytä raportteja. Jos sinulla on tietoja muissa säilöissä, haluan nähdä analytiikka-alustan. Järjestelmäkartta vastaa raportointikysymykseen ennen kuin kukaan avaa raporttityökalua. (Tuotenimet muuttuvat; Data 360 -luku käsittelee, missä Salesforcen analytiikka on nykyään.)

MDM: kuka tämä asiakas oikeasti on?

Oletetaan nyt, että asiakastiedot asuvat Salesforcessa, ERP:ssä, verkkokaupassa, kanta-asiakasalustalla ja kumppanin järjestelmässä, ja jokainen niistä luulee tietävänsä, kuka asiakas on. Siinä kohtaa tulee mukaan perustietojen hallinta (master data management, MDM): avaintietojen auktoritatiivisen identiteetin määrittäminen ja hallinta järjestelmien välillä. Mutta MDM ei ole ”asiakkaiden päätietokanta”. Vaikeat kysymykset ovat: mikä järjestelmä saa luoda asiakkaan, mitkä attribuutit kukin järjestelmä omistaa, miten kaksoiskappaleet löydetään, mikä tunniste säilyy ja mitä tapahtuu, kun järjestelmät ovat eri mieltä. Luku 6 käsittelee juuri sitä. Tunnista tässä rooli: jos MDM-alusta on olemassa, se voi olla kriittinen auktoriteetti Salesforcen ja muun yrityksen välillä.

Integraatiokerros ja tapahtumat

Yhdistä jokainen järjestelmä suoraan jokaiseen muuhun, niin järjestelmäkartasta tulee nopeasti spagettia. Siksi yrityksillä on integraatiokerros: ESB (enterprise service bus) tai iPaaS (integration platform as a service). MuleSoft on se, jonka kohtaat Salesforce-järjestelmäkartoissa useimmin. Se välittää, joten jokaisen sovelluksen ei tarvitse ymmärtää jokaista muuta.

Mutta MuleSoft-laatikko keskellä ei tee integraatiosta hyvää. Haluan silti tietää, mitä sen läpi kulkee ja mitä ei, kuka muuntaa tiedot, kuka omistaa sopimuksen, mitä tapahtuu, kun kohde on alhaalla, onko se synkroninen vai asynkroninen ja mistä tiedämme, että viesti onnistui. Integration Architect -kurssi menee syvälle; tunnista se tässä omaksi roolikseen.

Eikä jokainen integraatio ole järjestelmä A kutsumassa järjestelmää B. Joskus jotain tapahtuu (tilaus luodaan, toimituksen tila muuttuu, kuorma-auto ylittää alueen rajan), tapahtuma julkaistaan, ja jokainen, jota se kiinnostaa, reagoi. Liikkeessä olevilla tapahtumillakin on infrastruktuurinsa: Salesforcen omat tapahtumaominaisuudet, yrityksen tapahtumaväylä, muu viestinvälitys. Piirrä mekanismit, jotka kuljettavat tietoja, älä vain tietokantoja.

Järjestelmä, jonka kehittäjät unohtavat: identiteetti

On yksi laatikko, jonka haluan aina järjestelmäkarttaan ja jota kehittäjät harvoin ajattelevat: identiteetinhallinnan palvelu. Kehittäjät kirjautuvat sandboxeihinsa suoraan käyttäjätunnuksella ja salasanalla, joten identiteetti on rakentamisen aikana näkymätön. Sitten tulee hyväksymistestaus (UAT) tai tuotanto, ja yhtäkkiä on yrityksen kertakirjautuminen työntekijöille, ehkä toinen palvelu kumppaneille ja sosiaalinen kirjautuminen asiakkaille. Identiteetti oli aina osa arkkitehtuuria. Kehittäjä ei vain vielä nähnyt sitä.

Identiteetinhallinnan palvelu (IdP) on järjestelmä, joka todentaa käyttäjän ja vahvistaa identiteetin, johon Salesforce luottaa. Se kuuluu järjestelmäkarttaan ensimmäisestä päivästä alkaen, vaikka se määritettäisiin myöhemmin julkaisuputkessa, koska se, kuka pääsee sisään, ratkaisee, kuka pääsee tietoihin.

Siinä on myös käytännön mutka: identiteetin määritykset ovat siirrettävissä käyttöönotoissa, mutta eivät kokonaan. SAML-kertakirjautumisen määritykset ja todennuspalvelut ovat Metadata API -tyyppejä, joten ne kulkevat putken läpi (SamlSsoConfig (opens in a new tab)). Mutta todennuspalvelujen kuluttajasalaisuuksia ei enää palauteta Metadata API:n vastauksissa (Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab)), ja varmenteet vaihtelevat yleensä ympäristöittäin. Suunnittele sekä osat, jotka siirtyvät, että osat, jotka eivät siirry.

Click to enlarge

Lue järjestelmäkartta rooleina, ei logoina: mitä kukin järjestelmä omistaa, lukee tai päättää.

Missä Data 360 sijaitsee?

Data 360 herättää mukavan piirtämiskysymyksen. Sijoitan sen oikealle, ESB:n tai MuleSoftin alle. Syy on sen yhteydet: käyttäjät eivät koskaan yhdisty siihen suoraan, kun taas se yhdistyy suoraan moniin taustajärjestelmiin. Joten se kuuluu tietoputkiston joukkoon, missä nuo viivat pysyvät lyhyinä, eikä käyttäjien luo. Piirrä se kuin mikä tahansa näkymä, johon ihmiset kirjautuvat, niin kerrot väärää tarinaa.

Ylläpitäjät ja datatiimit kyllä avaavat Data 360:n näkymiä, mutta ne näkymät ovat orgissa, coressa. Työn tekevä tenantti, sen tiedot ja sen käsittely toimivat coren ulkopuolella. Siksi kutsun sitä nimellä lähellä corea (near-core): hallitaan coressa, isännöidään coren ulkopuolella (moduuli 1 selittää termit). Piirros seuraa tenanttia: se on putkiston joukossa, ja siitä kulkee yksi viiva takaisin orgiin, joka sitä hallitsee.

Sen tehtäviin kuuluu Salesforcen sanoin zero copy: tietojen federointiteknologia, jonka avulla yritys voi käyttää tietoja ja kysellä niitä kopioimatta (Zero Copy (opens in a new tab)). Ominaisuudet ja konnektorit muuttuvat nopeasti, joten Data 360 -luku käsittelee ne kunnolla sen sijaan, että tästä moduulista tehtäisiin tuote-esittely.

Lue järjestelmäkarttaa vastuina

Kun katsot järjestelmäkarttaa, älä lue logoja; lue vastuita. ERP: mitä se omistaa? Tietovarasto: mihin kysymyksiin se vastaa? Integraatioalusta: mitä se siirtää? IdP: kenet se todentaa? MDM: mitä identiteettiä se hallitsee? Data 360: mitä se yhdistää ja mihin tarkoitukseen? Salesforce: mistä se oikeasti vastaa? Kun osaat vastata noihin, laatikot tarkoittavat jotain, ja niiden väliset nuolet muuttuvat paljon kiinnostavammiksi. Seuraavaksi piirrämme ne harkiten.

Mitä arkkitehti tässä päättää

• Mikä rooli kullakin järjestelmällä on, tuotenimen lisäksi.
• Mikä järjestelmä on auktoritatiivinen kunkin tärkeän tietojoukon osalta, ja missä Salesforce säilyttää vain paikallisen kopion.
• Ovatko ERP:n omistamat tiedot saatavilla Salesforcessa hallituin kirjoituksin, ja miten tuo omistajuus näkyy skeemassa.
• Mihin analytiikka kuuluu sen perusteella, missä tiedot asuvat.
• Missä identiteetti, integraatio, tapahtumat ja perustietojen auktoriteetti sijaitsevat järjestelmäkartassa.

Järjestelmäkartta, jossa on kymmenen suorakulmiota, ei ole arkkitehtuuria; se on inventaario. Arkkitehtuuri alkaa, kun voit osoittaa jokaista suorakulmiota ja sanoa, miksi se on siellä, mitä se omistaa, kuka sitä käyttää, mitä Salesforce tarvitsee siltä ja mikä hajoaa, jos ymmärrät sen roolin väärin.

Lue lisää

• Salesforce Developers, Metadata API Developer Guide, SamlSsoConfig (opens in a new tab) (englanniksi, tarkistettu 2026-10-14).
• Salesforce Help, Winter ‘23 Release Notes, Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab) (englanniksi, tarkistettu 2026-10-14).
• Salesforce, Zero Copy (opens in a new tab) (tuotesivu, englanniksi, tarkistettu 2026-10-14).
• Zhamak Dehghani, How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh (opens in a new tab), martinfowler.com, 2019 (englanniksi).