Tunne työkalusi: yhdeksän kysymystä

🌐 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 6/7 luvussa Ajattele kuin tietoarkkitehti, Data Architect -kurssin luku 1. Jokainen moduuli on itsenäinen. Edellinen: Rakenna tätä päivää varten. Suunnittele huomista varten. Suunnittele virheitä varten. · Seuraava: Tietoarkkitehti tekoälyn aikakaudella

Kysymys, johon tämä moduuli vastaa: Miten arvioit minkä tahansa työkalun, myös sellaisen, jota et ole koskaan ennen nähnyt?

Arkkitehdit tarvitsevat harkintaa. Mutta harkinnasta ilman tietoa ei ole paljon hyötyä. Sinun täytyy silti tuntea työkalusi.

Olen opettanut arkkitehteja vuosia, ja yksi käyttämistäni kehikoista on joukko kysymyksiä, joihin sinun pitäisi osata vastata jokaisesta arkkitehtuurisi tärkeästä työkalusta tai ominaisuudesta. Alun perin opetin kahdeksan kysymystä. Olen lisännyt yhdeksännen. Teknologiat muuttuvat, Salesforce muuttuu, uusia tuotteita ilmestyy ja vanhat ominaisuudet kehittyvät, ja tekoäly kiihdyttää kaikkea tätä. Nämä kysymykset toimivat edelleen.

Yhdeksän kysymystä

Aina kun opettelet tai arvioit teknologiaa, kysy:

1. Mikä se on?
2. Missä sitä käytetään?
3. Miten käytän sitä?
4. Mitkä ovat vaihtoehtoni?
5. Mitkä ovat sen vahvuudet?
6. Mitkä ovat sen heikkoudet?
7. Miten selitän sen kehittäjille, liiketoiminnalle ja johtajille?
8. Miten sitä ylläpidetään pitkällä aikavälillä?
9. Mitä se maksaa, mitä lisensointia se vaatii ja mitkä ovat sen rajat?

Jos pystyt vastaamaan kaikkiin yhdeksään, alat ymmärtää työkalua kuin arkkitehti. Huomaa, mitä listalla ei ole: ”Osaanko konfiguroida sen?” Sillä on merkitystä, mutta se on vain osa työkalun tuntemista.

Click to enlarge

1. Mikä se on?

Aloita ilmeisestä kysymyksestä, koska ihmiset ohittavat sen yllättävän usein. Kuulemme tuotteen tai ominaisuuden nimen ja alamme heti keskustella, pitäisikö sitä käyttää. Hidasta. Mitä se oikeasti tekee? Mitä ongelmaa ratkaisemaan se on suunniteltu? Missä kohdassa arkkitehtuuria se on, ja mitä se ei ole? Arkkitehdin pitäisi pystyä kuvaamaan teknologia toistamatta markkinointikuvausta. Jos en pysty selittämään jotain muutamalla lauseella, en luultavasti vielä ymmärrä sitä tarpeeksi hyvin.

2. Missä sitä käytetään?

Sen tietäminen, mitä jokin tekee, ei ole sama asia kuin tietää, milloin se kuuluu arkkitehtuuriin. Millaisissa ongelmissa se on hyvä? Mitkä olosuhteet tekevät siitä sopivan, ja minkä olosuhteiden pitäisi saada minut epäluuloiseksi? Tämä on askel lauseesta ”tunnen tämän ominaisuuden” lauseeseen ”tunnistan ongelman, jonka tämä ominaisuus ratkaisee”, ja se on iso askel. Et halua kulkea etsimässä paikkoja, joissa käyttää lempiteknologiaasi. Haluat tunnistaa ongelmat ja tietää, mitkä työkalut niihin sopivat.

3. Miten käytän sitä?

Kyllä, arkkitehtien pitäisi ymmärtää toteutusta. Sinun ei tarvitse rakentaa jokaista komponenttia, mutta sinun pitäisi ymmärtää tarpeeksi tietääksesi, mitä pyydät muita rakentamaan. Tiedä, miten se konfiguroidaan, miten kehittäjä työskentelee sen kanssa, miten tiedot pääsevät sisään ja ulos, miten se otetaan käyttöön ja suojataan ja miltä se näyttää käytössä. En halua arkkitehdin suunnittelevan sellaisen teknologian ympärille, jonka hän on nähnyt vain tuotediassa. Likaa kätesi: rakenna jotain, riko jotain, katso, miten se oikeasti käyttäytyy. Arkkitehtuuri paranee, kun se perustuu todellisuuteen.

4. Mitkä ovat vaihtoehtoni?

Tämä saattaa olla listan tärkein kysymys. Jos tiedät vain yhden tavan ratkaista ongelma, sinulla ei ole arkkitehtuuripäätöstä; sinulla on oletus. Aina kun joku ehdottaa teknologiaa, haluan tietää, mitä muuta voisimme tehdä. Jokin toinen Salesforcen ominaisuus? Jotain deklaratiivista vai koodia? Voisiko ominaisuus asua Salesforcen ulkopuolella? Voisimmeko jättää tiedot paikalleen kopioimisen sijaan, käyttää tapahtumaa API-kutsun sijaan tai jättää rakentamatta mitään? Vaihtoehdot luovat kompromisseja, ja kompromissit ovat arkkitehtuurin ydin.

5. Mitkä ovat sen vahvuudet?

Jokainen työkalu on olemassa syystä. Ymmärrä, missä se on todella hyvä: mitä se tekee helpoksi, missä se skaalautuu hyvin, mitä monimutkaisuutta se poistaa, mitä ongelmia se ratkaisee tyylikkäästi. Käytä teknologioita siellä, missä niiden vahvuudet osuvat yksiin ongelman kanssa. Se kuulostaa itsestään selvältä, mutta on hyvin helppo valita työkalu, koska omistamme sen jo, tiimi osaa sen, se on uusi tai joku näki demon. Ne voivat olla tekijöitä. Ne eivät ole sama asia kuin arkkitehtuurinen sopivuus.

6. Mitkä ovat sen heikkoudet?

Tämä on aivan yhtä tärkeää. Jokaisella teknologialla on heikkoutensa, jokaisella. Jos joku osaa kertoa sinulle vain teknologian vahvuudet, ette vielä käy arkkitehtuurikeskustelua. Mitä se ei tee hyvin? Missä monimutkaisuus tulee esiin, ja mitä tapahtuu suuressa mittakaavassa? Millaisen ylläpitotaakan ja riippuvuudet se tuo? Mitkä vaatimukset työntävät sen pois sen parhaalta alueelta? Heikkous ei aina tarkoita, ettei teknologiaa pitäisi käyttää. Se tarkoittaa, että meidän täytyy tietää, mitä hyväksymme. Kompromissi, jonka ymmärrät, voi olla arkkitehtuurinen päätös. Kompromissi, jota et ymmärrä, voi muuttua yllätykseksi.

7. Miten selitän sen eri yleisöille?

Tämä on yksi niistä kysymyksistä, jotka erottavat teknisen tiedon arkkitehtuurisesta taidosta. Pystytkö selittämään saman teknologian kehittäjälle, liiketoiminnalle ja johtajalle? Niiden ei pitäisi olla sama selitys. Kehittäjä tarvitsee API:t, transaktioiden käyttäytymisen, tietoturvan, virheenkäsittelyn ja toteutusmallit. Liiketoimintaa kiinnostaa, mitä se mahdollistaa ja miten heidän prosessinsa muuttuu. Johtajaa kiinnostavat kustannukset, riski, aika, vaikutus organisaatioon ja se, mitkä vaihtoehdot päätös pitää auki tai sulkee. Et muuta totuutta; muutat abstraktiotasoa. Jos pystyt selittämään teknologian vain sen dokumentaation sanastolla, jatka ymmärryksesi työstämistä.

8. Miten sitä ylläpidetään pitkällä aikavälillä?

Projektit päättyvät. Järjestelmät eivät, tai ainakin toivomme niin. Jonkun täytyy omistaa se, mitä rakennamme, kun projektitiimi lähtee. Se tarkoittaa, että tiedät, miten sitä valvotaan, päivitetään ja vianetsitään, kuka tarvitsee taidot sen tukemiseen, miten muutokset otetaan käyttöön ja testataan ja mitä tapahtuu, kun teknologia kehittyy tai Salesforce muuttaa jotain allamme. Kuvittele se kolmen vuoden päähän. Olen nähnyt arkkitehtuureja, jotka olivat julkaisupäivänä hyvin nokkelia ja sen jälkeen kurjia pyörittää. Se ei ole menestys. Ylläpidettävyys on osa arkkitehtuuria.

9. Mitä se maksaa, mitä lisensointia se vaatii ja mitkä ovat sen rajat?

Tämän kysymyksen lisäsin alkuperäisiin kahdeksaan, ja nykyään sitä on mielestäni mahdoton jättää pois. Teknologia voi olla täydellinen tekninen ratkaisu ja silti väärä arkkitehtuurinen ratkaisu, jos talous ei toimi. Sisältyykö se lisensseihin, jotka meillä on, vai onko se lisäosa? Lisensoidaanko se käyttäjän, käytön, kulutuksen, tallennustilan vai transaktioiden mukaan? Mitä kustannuksille tapahtuu, kun skaalaudumme?

Sitten ovat rajat, ja jokaisella alustalla on niitä: API-, tallennus-, kysely-, transaktio-, rinnakkaisuus-, läpäisy- ja lisensointirajat. Jotkin ovat ehdottomia, jotkin joustavia; joitakin voi nostaa ja joitakin ei; joillakin ei ole merkitystä meidän mittakaavassamme ennen kuin lisäämme nollan. Sinun ei tarvitse opetella ulkoa jokaista Salesforcen rajaa, ja se olisi ajankäyttönä kamala. Sinun täytyy tietää, että rajat ovat olemassa, mitkä niistä ovat tärkeitä arkkitehtuurillesi ja milloin tarkistaa ajantasainen luku. Luvut muuttuvat. Arkkitehtuurinen kysymys pysyy.

Esimerkki käytännössä: Apex-jakaminen

Tässä yksi yleisimmistä esimerkeistäni siitä, miten kysymykset toimivat. Saamme vaatimuksen monimutkaisesta jakamisesta, jakamisesta, jota ei voi toteuttaa millään omistajaan tai ehtoihin perustuvalla jakamissäännöllä. Se johtaa meidät Apex-jakamiseen: koodiin, joka kirjoittaa jakamistietueet itse. Nyt meidän täytyy siis tietää, mitä Apex-jakaminen on, missä sitä käytetään, miten sitä käytetään ja niin edelleen. Se on eskalaatio: Apex-jakaminen on vaihtoehto (kysymys 4) silloin, kun tarvitsemamme säännöt menevät pidemmälle kuin omistajaan ja ehtoihin perustuva jakaminen pystyy ilmaisemaan.

Nyt sen heikkoudet (kysymys 6). Sanotaan, että meillä on asiakasyhteisö, jossa on 10 tai 20 miljoonaa jäsentä, ja käytämme Customer Community -lisenssiä, emme Customer Community Plus -lisenssiä. He ovat suuren volyymin käyttäjiä. Heillä ei ole rooleja, eivätkä he käytä jakamismallia lainkaan: heidän pääsynsä tulee jakamisjoukoista (sharing sets) ja jakamisryhmistä (share groups), jotka täsmätään heidän tilinsä ja yhteyshenkilönsä kautta. Apexilla ei ole heille kirjoitettavaa jakamistietuetta, joten Apex-jakaminen ei toimi heille. Ja juuri kustannus- ja lisensointikysymys (kysymys 9) toi meidät tähän: lisenssivalinta ratkaisi, mitkä jakamistyökalut ovat ylipäätään olemassa.

Joten aivan kuten Apex-jakaminen oli vaihtoehto omistajaan ja ehtoihin perustuville säännöille, saatat törmätä tilanteeseen, jossa tarvitset vaihtoehdon Apex-jakamiselle. Eikä siinä vaiheessa oikeastaan ole konfiguraatioon perustuvia vaihtoehtoja monimutkaisille jakamissäännöille. Päädyt tekemään objektista vain luku -tilaisen ja hallitsemaan pääsyä Apexin kautta. Siksi kysyt kaikki yhdeksän kysymystä ennen kuin valitset, et sen jälkeen.

Älä opettele alustaa ulkoa

Tämä on tärkeintä silloin, kun opettelet Salesforce-arkkitehtuuria. Älä yritä opetella Salesforcea ulkoa. Et pysty siihen: alusta on liian suuri ja muuttuu liian nopeasti. Olen työskennellyt Salesforcen parissa pitkään, ja opin yhä. Se on normaalia.

Haluan sinun kehittävän kehikon oppimiselle. Kun Salesforce julkaisee huomenna uuden ominaisuuden, minun ei tarvitse olla nähnyt sitä ennen. Tiedän, mitä kysyä: mikä se on, mihin se sopii, miten käytän sitä, mitä muuta voisin käyttää, missä se on hyvä, missä sillä on vaikeuksia, miten selitän sen, miten pyöritän sitä, mitä se maksaa ja missä rajat ovat? Nyt voin alkaa arvioida sitä. Se on paljon arvokkaampaa kuin jälleen yhden ominaisuusmatriisin opetteleminen ulkoa.

Kokeen jälkeen: tekoäly nopeuttaa vastaamista yhdeksään kysymykseen ja helpottaa erehtymistä. Kun kohtaat teknologian, jota et tunne, voit pyytää tekoälyä selittämään sen, vertaamaan kolmea lähestymistapaa, listaamaan sen rajat ja tavalliset virhetilanteet tai argumentoimaan sen käyttöä vastaan. Se on merkittävä tutkimusavustaja. Mutta se voi olla väärässä, vanhentunut tai sekoittaa varmana kaksi samannimistä tuotetta tai versiota. Tarkista kaikki, mikä vaikuttaa päätökseen: seuraa lähdettä ja tarkista ajantasainen dokumentaatio, rajat ja lisensointi. Luota, mutta tarkista (moduuli 7).

Opettele kysymykset, ei vain vastauksia

Kohtaamme tällä kurssilla paljon teknologioita. En halua sinun keräävän vastauksia; haluan sinun harjoittelevan kysymyksiä. Kun puhumme big objecteista, ulkoisista tiedoista, Data 360:sta, integraatiomalleista tai tekoälyominaisuudesta, jonka Salesforce julkaisee puoli vuotta tämän luvun kirjoittamisen jälkeen, kysy samat yhdeksän kysymystä.

Vastaukset muuttuvat. Kysymykset kestävät. Siksi tämä on arkkitehtuurin kehikko eikä opiskeluopas.

Tunne työkalusi: missä ne ovat hyviä, missä huonoja, mitä muuta voisit käyttää, mitä ne maksavat ja missä ne hajoavat. Ja tiedä tarpeeksi, jotta voit selittää päätöksen niille, joiden täytyy elää sen kanssa. Niin arkkitehti oppii teknologiaa.

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

• Sopiiko työkalu ongelmaan, arvioituna kaikilla yhdeksällä kysymyksellä eikä vain sillä, voiko sen konfiguroida.
• Mitkä vaihtoehdot ovat ja mitä työkalun kustannukset, lisensointi ja rajat tarkoittavat sinun mittakaavassasi.
• Kuka ylläpitää sitä kolmen vuoden päästä, ja miten.
• Mitkä työkalua koskevat tosiasiat tarkistetaan ennen kuin niihin luotetaan.

Lue lisää

• About High-Volume Community or Site Users (opens in a new tab), Salesforce Help (englanniksi, tarkistettu 2026-10-09; tarkistettu uudelleen 2026-10-12): suuren volyymin käyttäjillä (External Apps-, Customer Community-, High Volume Customer Portal- ja Authenticated Website -lisenssit) ei ole rooleja; heidän pääsynsä tulee jakamisjoukoista ja jakamisryhmistä; heitä ei voi sisällyttää omistajaan perustuviin jakamissääntöihin, eikä heidän omistamiaan tietueita voi jakaa manuaalisesti.
• Platform Sharing Architecture (opens in a new tab), Salesforce Architects (englanniksi, tarkistettu 2026-10-09; tarkistettu uudelleen 2026-10-12): suuren volyymin käyttäjät (Customer Community, High Volume Customer Portal, Authenticated Website) eivät käytä jakamismallia, koska heidän lisenssinsä eivät tue rooleja; pääsy toimii täsmäämällä käyttäjä tilin (Account) ja yhteyshenkilön (Contact) lookup-kenttiin jakamisjoukkojen tai jakamisryhmien kautta. Sama sivu kertoo, milloin Apex managed sharing on oikea työkalu.
• Account Sharing Sets for High Volume Customer Portal Users (opens in a new tab), Trailblazer Community -kysymys, marraskuu 2024 (englanniksi, tarkistettu 2026-10-09; tarkistettu uudelleen 2026-10-12): käytännön tekijä kertoo, että jakamistietueiden lisääminen suuren volyymin käyttäjille epäonnistui virheeseen. Kenttäraportti, ei virallista dokumentaatiota. (Verkossa toimiva Trailblazer Community muuttuu vain luku -tilaan 30. lokakuuta 2026; linkki voi muuttua.)
• Create a Sharing Set for Experience Cloud Site Users (opens in a new tab), Salesforce Help (englanniksi, tarkistettu 2026-10-09): jakamisjoukko antaa pääsyn tietueisiin, jotka liittyvät käyttäjän tiliin tai yhteyshenkilöön.