Salesforce on yksi järjestelmä monien joukossa

🌐 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 1/6 luvussa Yrityksen tietojen ymmärtäminen, Data Architect -kurssin luku 4. Jokainen moduuli on itsenäinen. Seuraava: Yrityksen tietojen lajit

Kysymys, johon tämä moduuli vastaa: Miksi tietoarkkitehti piirtää sen, mikä ympäröi orgia, ennen kuin suunnittelee orgin?

Kun opetan CTA-kandidaatteja, ensimmäisen päivän kotitehtävä on aina sama. Lue skenaario. Aloita järjestelmäkartta tyhjältä pohjalta. Tee vasta sitten ensimmäinen yritys tietomallista. Ei objekteja, ei integraatioita yksityiskohtaisesti: järjestelmäkartta. Haluan nähdä, mikä ympäröi Salesforcea, ennen kuin päätämme, mitä sen sisälle kuuluu.

Se on näkökulman muutos monelle Salesforce-ammattilaiselle. Jos olet tehnyt uraasi ylläpitäjänä tai kehittäjänä, Salesforce on luonnollisesti maailmasi keskipiste. Avaat Setupin, luot objekteja, rakennat flow’ita, kirjoitat Apexia ja integroit muita järjestelmiä Salesforceen sisään. Kaikki tuntuu alkavan orgista. Arkkitehdin täytyy vetää kameraa taaksepäin, koska yrityksessä Salesforce on yksi järjestelmä monien joukossa, ja melko usein se ei ole se, joka omistaa tiedot.

Piirrä järjestelmäkartta ensin

Luku 2 rakensi loogisen mallin, ja luku 3 kysyi, miten se elää Salesforcessa. Nyt teen ongelmasta isomman. Ennen kuin päätän, mitä Salesforcen pitäisi omistaa, haluan ymmärtää sitä ympäröivän yrityksen. Mitä järjestelmiä on jo olemassa? Missä asiakkaat luodaan, tuotteet määritellään, tilaukset aloitetaan ja laskut muodostetaan? Missä identiteetti asuu? Missä analytiikka tapahtuu, missä asiakirjoja säilytetään, missä historia on? Mitkä järjestelmät tarvitsevat Salesforcen tietoja, ja mistä Salesforce on riippuvainen?

Nuo kysymykset muuttavat arkkitehtuuria. Siksi aloitan tyhjältä pohjalta, laitan Salesforcen keskelle ja piirrän kaiken sen ympärille. Moduuli 4 näyttää tarkalleen, miten sen asettelen. Toistaiseksi oppi on yksinkertaisesti: älä suunnittele orgia ennen kuin ymmärrät maailman, jossa sen täytyy elää.

Salesforce ei usein ole lähdejärjestelmä

Otetaan hyvin tavallinen yritys: Salesforce sekä ERP, toiminnanohjausjärjestelmä kuten SAP tai Oracle, joka pyörittää taloutta, tuotteita, varastoa, hankintoja ja toimitusten toteutusta. Kysy nyt yksinkertainen kysymys: missä asiakas asuu?

Se voi olla Salesforce, ERP tai molemmat, ja siinä asiasta tulee kiinnostava. Myyjät voivat työstää prospekteja tileinä (Account) Salesforcessa, kun taas ERP antaa virallisen asiakasnumeron, kun heistä tulee maksavia asiakkaita. Tuotteet ja hinnat? Luultavasti ERP. Varasto? Lähes koskaan Salesforce. Tilaukset voidaan kirjata Salesforcessa ja toteuttaa ERP:ssä; laskut tulevat ERP:stä; asiakaspalvelu asuu Salesforcessa; analytiikka jakautuu Salesforcen raporttien ja tietovaraston kesken. Yhtäkkiä hieno Salesforce-tietomallimme ei olekaan yrityksen tietomalli. Se on yksi osa sitä.

Integraatio, jonka näen yhä uudelleen

Yleisin näkemäni integraatio menee näin: asiakkaat, tuotteet ja hinnat virtaavat Salesforceen ERP:stä, ja tilaukset virtaavat ulos. Vaihda tilalle SAP, Oracle tai mikä tahansa muu ERP; muoto on sama. ERP omistaa asiakkaan ja tuotteen golden recordin, joten nuo virrat tulevat oikealta Salesforceen. Myynti sulkee kaupan Salesforcessa, joten tilaus alkaa sieltä ja palaa ERP:hen toteutettavaksi, laskutettavaksi ja kirjanpitoon.

Nuo virrat eivät ole pelkkiä integraatioita. Ne kertovat minulle, missä yritys uskoo totuuden asuvan.

Yksisuuntaiset nuolet hermostuttavat minua

Aina kun näen integraation, jossa on vain yksi virta, alan huolestua. Korkealla tasolla joku piirtää yhden nuolen: tilaukset Salesforcesta ERP:hen. Hyvä. Katso nyt syvemmälle. Miten voin lähettää tilauksen ERP:hen, jos en tunne sen asiakkaita, tuotteita tai hintoja? Tilaus täytyy kohdistaa asiakkaaseen, joka ERP:llä jo on, ja jokaisen rivin täytyy olla SKU, jota ERP jo myy. En voi lähettää tilausriviä tuotteesta, jota toisella puolella ei ole. Joten ennen kuin tilausnuoli voi toimia, paluuvirtojen täytyy olla olemassa, toiseen suuntaan.

Se on kysymys, jonka esitän jokaiselle nuolelle: mistä tämä virta riippuu? Näkyvä korkean tason nuoli tarvitsee yleensä paluuvirtoja, joita et ole vielä piirtänyt.

Katso vielä syvemmälle, niin löydät paluumatkan. Salesforce lähettää tilauksen. Mitä sitten? Hyväksyttiinkö vai hylättiinkö se? Lähetettiinkö se, osittain, peruttiinko se? Laskutettiinko se? Tarvitseeko kenenkään Salesforcessa tietää? Ehkä ei. Mutta jonkun olisi pitänyt kysyä. Jos mitään ei palaa, hyvä. Kerro minulle miksi.

Yritys ei syntynyt kerralla

Järjestelmäkartat monimutkaistuvat osittain siksi, ettei kukaan rakentanut niitä kerralla. Tiedot ovat tulleet aaltoina. Ensin tiedostot: kiinteämuotoiset tietueet, sitten erotinmerkein jäsennetyt tiedostot kuten CSV. Sitten relaatiotietokannat operatiivisille tiedoille. Sitten tietovarastot, jotka kokosivat tiedot yhteen analyysia varten. Sitten NoSQL-tietokannat asiakirjoille, avain-arvo-pareille ja graafeille, jotka eivät istu siististi tauluihin. Sitten tietoaltaat valtaville määrille raakoja ja puolijäsenneltyjä tietoja, ja lakehouset, jotka yhdistävät nämä kaksi. Tapahtumavirrat, kuten Kafka tai Salesforcen tapahtumaväylä, siirtävät tietoja sitä mukaa kuin asioita tapahtuu öisten eräajojen sijaan. Ja nyt federointi, jossa tietoja ei tarvitse kopioida yhteen paikkaan ennen kuin toinen alusta voi käyttää niitä.

Teknologia ei ole vielä pääasia. Tämä on: uusi aalto harvoin hävittää vanhaa. Kävele suureen yritykseen, niin löydät ne kaikki yhtä aikaa: relaatiotietokannat, ERP:n, Salesforcen, tietovaraston, tietoaltaan, SFTP-pudotukset, API:t, tapahtumavirrat, taulukon, jonka joku yhä lähettää sähköpostilla joka perjantai, ja sen yhden järjestelmän, johon kaikki pelkäävät koskea, koska sen rakentaja jäi eläkkeelle kuusi vuotta sitten. Se on yritys, jonka arkkitehtuuria suunnittelet, ei esitteen yritys.

Eri järjestelmät ovat olemassa eri syistä

Siksi en myöskään koskaan aloita kysymyksellä ”miten saamme kaikki tiedot Salesforceen?” Miksi haluaisin niitä kaikkia sinne? Salesforce voi olla paras paikka myynnille ja asiakaspalvelulle työskennellä asiakkaiden kanssa. Se ei tee siitä talousjärjestelmää, yrityksen tietovarastoa, telemetriasäilöä, asiakirja-arkistoa eikä jokaisen klikkauksen, GPS-lukeman ja historiallisen tapahtuman kotia, jonka yritys on koskaan tuottanut.

Luku 3 kysyi yhden orgin osalta: missä näiden tietojen pitäisi asua? Yrityksen tasolla sama kysymys kasvaa: joskus Salesforce omistaa tiedot, joskus se säilyttää kopion, joskus vain viitteen, ja joskus sillä ei pitäisi olla niitä lainkaan.

Core, coren ulkopuoli ja Hyperforce

On vielä yksi raja, joka pitää ymmärtää: edes ”Salesforce” ei ole yksi ajoympäristö ja yksi tietokanta. Luvussa 3 coressa tarkoitti sitä, missä tiedot ovat: työpöydälläsi, orgin omissa objekteissa. Tässä samat sanat kuvaavat, missä tuote toimii. Kuulet arkkitehtien käyttävän molempia.

Historiallisesti Core-ajoympäristö isännöi suurinta osaa alustasta. Nykyään Salesforce kuvaa alustaa, joka koostuu sadoista itsenäisistä, metatietoihin perustuvista palveluista, ja Core on edelleen sovellusten metatietojen ainoa system of record (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab)). Siksi kuulet arkkitehtien sanovan, että jokin ominaisuus toimii coressa tai coren ulkopuolella.

Sillä oli merkitystä kauan ennen kuin alusta jakautui palveluiksi. Kun kysyn kurssilla, miksi Salesforce osti tarjouksia varten SteelBrickin eikä Apttusta, haen yksinkertaista vastausta: SteelBrick oli rakennettu 100-prosenttisesti coreen. Flow’t ja triggerit asuvat coressa, joten sinne rakennettu tuote saa alustan metatiedot, mukautukset ja automaation mukaansa. Tuo tarjoustuote on sittemmin väistynyt Revenue Cloudin tieltä, mutta oppi ei ole. Sitten on lähellä corea (near-core), ja Data 360 on esimerkki, jota käytän. Data 360 ei ole core. Sen tenantti on coren ulkopuolella: tiedot ja niitä käsittelevät mekanismit toimivat sen omassa lakehousessa, orgin relaatiotietokannan rinnalla eivätkä sen sisällä (The Salesforce Platform: Transformed for Tomorrow (opens in a new tab)). Mutta näkymät, joilla määrität ja ohjaat sitä, näytetään coressa, orgissa. Tarkimmin sanottuna siis: hallitaan coressa, isännöidään coren ulkopuolella. Mitään tiedoista tai käsittelystä ei oikeasti tapahdu Coressa; Coren käyttöliittymä ohjaa coren ulkopuolista tenanttia. Ja sitten tietysti on kaikki se, mikä on coren ulkopuolella, koska se ei ole Salesforcea lainkaan.

Minua kiinnostaa vähemmän se, mikä tuote toimii missäkin tänä vuonna, koska se muuttuu, kuin tapa: raja voi vaikuttaa tietojen liikkumiseen, viiveeseen, identiteettiin, integraatioon ja tietojen sijaintiin. Älä siis oleta, että koska tuotteen nimessä lukee Salesforce, sen tiedot ovat aivan tilitietueidesi vieressä. Katso todellista arkkitehtuuria.

Sitten on Hyperforce: Salesforcen infrastruktuuri, joka on rakennettu julkiseen pilveen ja määritelty koodina perinteisten omien konesalien sijaan, ja joka antaa asiakkaille enemmän valinnanvaraa siihen, missä heidän tietonsa sijaitsevat (Salesforce Hyperforce: General Information and FAQ (opens in a new tab)). Sillä on merkitystä, ja moduuli 5 palaa siihen. Mutta infrastruktuuriarkkitehtuuri ei ole yrityksen tietoarkkitehtuuria. Orgin siirtäminen julkiseen pilveen ei kerro, kuka omistaa asiakkaan, missä varasto asuu, missä analytiikka toimii tai mitkä tiedot saavat ylittää rajan. Hyperforce voi muovata osaa näistä päätöksistä, erityisesti tietojen sijaintia. Se ei korvaa järjestelmäkartan tuntemista.

Järjestelmäkartta tulee ennen laatikkoa

Tässä siis tapa. Joku ojentaa sinulle skenaarion. Älä ala rakentaa Salesforce-ratkaisua. Etsi ensin järjestelmät: ERP, identiteetinhallinnan palvelu, tietovarasto, integraatioalusta, kumppanien järjestelmät, asiakaskanavat, asiakirjasäilöt. Etsi sitten niiden välillä liikkuvat tiedot: asiakkaat, tuotteet, tilaukset, laskut, asiakirjat, tapahtumat, identiteetit. Kysy sitten, kuka omistaa kunkin. Päätä vasta sitten, mitä Salesforceen kuuluu. Muuten suunnittelet laatikkoa tietämättä, mihin se liittyy.

Click to enlarge

Vaihe 1/3: suunnittelemamme org yksinään. Tästä katsottuna se näyttää koko maailmalta.

Click to enlarge

Vaihe 2/3: loitonna. Salesforce on yksi järjestelmä monien joukossa (moduuli 4 opettaa tämän asettelun).

Click to enlarge

Vaihe 3/3: ensimmäiset nuolet. Asiakkaat, tuotteet ja hinnat sisään ERP:stä, tilaukset ulos: ne kertovat, missä yritys uskoo totuuden olevan.

Järjestelmäkartta muuttaa tietomallia

Tästä syystä asialla on merkitystä tietoarkkitehdille. Luku 2 sanoo, että asiakas on tärkeä entiteetti. Hyvä. Sitten järjestelmäkartta sanoo, että ERP on asiakkaan osalta auktoritatiivinen. Se muuttaa fyysistä mallia. Salesforce voi yhä säilyttää paikallisen tilin, koska ihmiset käyttävät sitä joka päivä, mutta nyt tarvitsemme ERP:n tunnisteen External ID:nä; meidän täytyy tietää, mitä kenttiä Salesforce saa muuttaa (merkitsen ERP:n kentät erp_-etuliitteellä, kuten näemme moduulissa 3), kuinka nopeasti ERP:n muutokset saapuvat, voiko Salesforce luoda asiakkaan ennen kuin ERP tietää siitä ja mitä tapahtuu, kun nämä kaksi ovat eri mieltä. Ne eivät ole myöhemmin ratkaistavia integraatiokysymyksiä. Ne ovat tietoarkkitehtuurin kysymyksiä, ja järjestelmäkartta toi ne esiin.

Näin yksi niistä puraisee. Myyjä muuntaa liidin suurelle juomayhtiölle, luo tilin, voittaa kaupan, ja asiakas siirtyy ERP:hen. Mutta yritys on tehnyt kauppaa tuon juomayhtiön kanssa vuosia, ja ERP:ssä se on jo. Nyt niitä on kaksi. Olisiko myyjän pitänyt pystyä luomaan tuo tili lainkaan? Luvut 5 ja 6 palaavat tähän; järjestelmäkartassa näet sen tulevan.

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

• Mitkä järjestelmät ympäröivät Salesforcea, ja mikä rooli kullakin on.
• Mikä järjestelmä omistaa kunkin tärkeän tietolajin, ennen kuin päätetään, kuinka paljon siitä Salesforce säilyttää.
• Mitä virtaa Salesforceen, mitä virtaa ulos ja mitä palaa takaisin.
• Mitkä tiedot Salesforcen pitäisi omistaa, kopioida, viitata, federoida, arkistoida tai jättää rauhaan.
• Mitkä alustan ja infrastruktuurin rajat ovat merkityksellisiä, sen sijaan että oletetaan kaiken Salesforce-brändätyn asuvan yhdessä paikassa.

Siirtymä kehittäjästä arkkitehdiksi ei usein ole uuden ominaisuuden opettelua. Se on sen opettelua, milloin lopettaa Salesforcen katsominen: vedä kameraa taaksepäin, seuraa tietoja, selvitä, kuka omistaa totuuden, ja palaa sitten päättämään, mikä Salesforcen tehtävän pitäisi olla.

Lue lisää

• Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (opens in a new tab) (englanniksi, tarkistettu 2026-10-14).
• Salesforce Help, Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab) (englanniksi, tarkistettu 2026-10-14).