Peruttavuustesti

🌐 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/7 luvussa Ajattele kuin tietoarkkitehti, Data Architect -kurssin luku 1. Jokainen moduuli on itsenäinen. Edellinen: Tietomalli on luuranko · Seuraava: Arkkitehtuuri on kompromissien taitoa

Kysymys, johon tämä moduuli vastaa: Miten erotat arkkitehtuurisen päätöksen tavallisesta?

Arkkitehdit tekevät paljon päätöksiä.

Mutta jokainen päätös ei ole arkkitehtuurinen päätös.

Tämä on tärkeä ero. Jos kohtelemme jokaista päätöstä arkkitehtuurina, käytämme kaiken aikamme väittelemällä asioista, joita on suhteellisen helppo muuttaa. Jos emme tunnista päätöksiä, jotka todella ovat arkkitehtuurisia, voimme tehdä tänään viiden minuutin päätöksen, jonka purkamiseen menee viisi vuotta.

Miten siis erotamme ne?

Kysyn mielelläni yksinkertaisen kysymyksen:

Kuinka vaikeaa tämä päätös on perua myöhemmin?

Kutsun tätä peruttavuustestiksi (the Reversibility Test).

Mitä vaikeampi jotain on perua ja mitä enemmän muuta siitä riippuu, sitä enemmän se ansaitsee arkkitehtuurista huomiota.

Joitakin päätöksiä on halpa muuttaa

Aloitetaan jostain yksinkertaisesta.

Nimeämme kentän Customer Category (asiakasluokka). Puoli vuotta myöhemmin liiketoiminta päättää, että kaikki kutsuvat sitä oikeasti nimellä Customer Segment (asiakassegmentti). Muutamme otsikon. Ehkä dokumentaatiota pitää päivittää ja käyttäjiä kouluttaa vähän, mutta tämä ei ole suuri arkkitehtuurinen tapahtuma. Alkuperäisen API-nimen kanssa meidän on kuitenkin elettävä, koska sen muuttamisella on paljon suuremmat seuraukset. Tämä voi siis tarkoittaa vain otsikon muutosta ja sitä hämmennystä, joka sen mukana voi tulla.

Teimme päätöksen. Muutimme mielemme. Jatkoimme eteenpäin.

Vertaa sitä nyt erilaiseen päätökseen.

Luomme asiakkaille tunnisteen. Päätämme, mitä se tarkoittaa, missä muodossa se on ja mikä järjestelmä sen luo. Sitten julkaisemme sen.

Salesforce käyttää sitä. Tietovarasto käyttää sitä. Integraatioalusta käyttää sitä. Asiakasportaali käyttää sitä. Viisi muuta sovellusta alkaa tallentaa sitä. Raportit ja tietoputket käyttävät sitä. Ehkä asiakkaatkin lopulta näkevät sen.

Kolme vuotta myöhemmin joku sanoo:

Tunnistetta ei luultavasti olisi pitänyt suunnitella noin.

Se on aivan eri keskustelu.

Ero ei ole siinä, että toinen päätös olisi teknisempi kuin toinen.

Ero on peruttavuudessa.

Näin se voi käydä. Sanotaan, että liiketoiminta on muodostanut avaimensa osasta asiakkaan nimeä ja numerosta. Se toimii vuosia, koska kenenkään ei ole koskaan tarvinnut muuttaa nimeä. Sitten vuoden tai pidemmän ajan kuluttua nimi muuttuukin, ja yhtäkkiä avaimet eivät vastaa kaavaa, jota muut tiedot odottavat. Tämä on yksi syy siihen, miksi avaimilla ei pitäisi olla mitään sisäistä merkitystä.

Arkkitehtuuri luo painovoimaa

Arkkitehtuurinen päätös kerää ympärilleen asioita. Ajattelen sitä painovoimana.

Valitse objektimalli, ja sen ympärille rakennetaan automaatiota.

Valitse avain, ja muut järjestelmät alkavat tallentaa sitä.

Valitse, missä perustiedot asuvat, ja integraatiot alkavat virrata sinne ja sieltä pois.

Valitse jakamismalli, ja liiketoimintaprosessit alkavat riippua siitä, kuka näkee mitä.

Valitse integraatiomalli, ja järjestelmät alkavat riippua sen ajoituksesta ja käyttäytymisestä.

Mitä kauemmin nuo päätökset ovat olemassa, sitä enemmän painovoimaa niille kertyy. Lopulta alkuperäisen päätöksen muuttaminen tarkoittaa kaiken sen ympärille kertyneen muuttamista.

Tekoälykin tuntee tämän painovoiman. Tekoälytyökalu toimii sen pohjalta, mitä järjestelmässä jo on: kun keskeinen suunnitteluratkaisu on paikallaan, jokainen sen jälkeinen tekoälyn toiminto pitää sitä tosiasiana ja rakentaa sen päälle, ja rakentaa sen päälle, ja rakentaa sen päälle. Päätös kaikuu eteenpäin monen muun päätöksen läpi, eikä kukaan ihminen koskaan palaa tarkastelemaan alkuperäistä. Jokainen generointi lisää painovoimaa.

Siksi sillä, että tietomalli on ”luuranko”, on merkitystä. Emme ole varovaisia siksi, että muutos olisi pahasta. Olemme varovaisia, koska riippuvuudet tekevät muutoksesta kallista.

Kysy kaksi kysymystä

Kun katson suunnittelupäätöstä, kysyn kaksi kysymystä:

Kuinka vaikeaa tämä on perua?

Kuinka paljon siitä tulee riippumaan?

Ne liittyvät toisiinsa, mutta eivät ole samat. Jokin voi olla teknisesti helppo muuttaa, mutta sillä voi olla satoja käyttäjiä. Ennen nimettiin vakio-objekteja uudelleen selkeyden vuoksi, esimerkiksi tili (Account) nimellä ”Asiakas”. Helppo tehdä. Sitten toinen järjestelmä halusi käyttää tilejä kumppaneille, eikä se onnistunut. Jollain toisella voi olla vain muutama käyttäjä, mutta sen muuttaminen vaatii valtavan migraation, kuten objektin API-nimi, johon viitataan sisäisesti monessa paikassa. Kukaan ulkopuolinen ei näe sitä, mutta väärä nimi hämmentää tiimiä jatkuvasti. Kumpikin ansaitsee huomiota.

Mieti muutamia tavallisia tietoihin liittyviä päätöksiä:

• Mikä Salesforce-objekti kuvaa tätä liiketoiminnan käsitettä?
• Mikä on yksilöllinen tunniste?
• Mikä järjestelmä on system of record (lähdejärjestelmä)?
• Kopioidaanko nämä tiedot Salesforceen vai käytetäänkö niitä jossain muualla?
• Onko tämä yksi objekti vai useita toisiinsa liittyviä objekteja?
• Kuka omistaa tiedot, ja kuinka kauan säilytämme niitä?
• Mitkä ovat oletusarvoiset pääsyn rajamme?
• Miten nämä tiedot liikkuvat järjestelmien välillä?

Ne ovat hyvin erilaisia kuin päätös siitä, missä kohdassa Lightning-sivua kenttä näkyy. Sivun suunnittelullakin on merkitystä. Erehtymisen hinta on erilainen.

Click to enlarge

Mieti vaikutusaluetta

Toinen tapa ajatella peruttavuutta on vaikutusalue (blast radius): jos muutan tätä päätöstä, mikä muu liikkuu?

Oletetaan, että jonkin kentäksi mallintamamme asian pitääkin muuttua lapsiobjektiksi. Se ei ole pelkkä skeemamuutos. Mitä olemassa oleville tiedoille tapahtuu? Entä raporteille, integraatioille, jotka odottavat sitä kenttää, Apexille ja Flow’ille, jotka viittaavat siihen, tietoturvalle, analytiikalle tai tekoälyagentille, jonka toiminnot riippuvat alkuperäisestä rakenteesta?

Mitä suurempi vaikutusalue, sitä huolellisemmin alkuperäinen päätös kannattaa tehdä.

Siksi arkkitehtien on myös katsottava oman järjestelmänosansa ulkopuolelle. Salesforcen sisältä muutos voi näyttää helpolta. Koko yrityksen näkökulmasta se voi vaikuttaa kahteentoista muuhun järjestelmään.

Yrityksen päätökset ja Salesforcen päätökset

Tietoarkkitehti ajattelee kahdella tasolla.

Salesforcen sisällä päätämme objekteista, suhteista, avaimista, volyymista, pääsystä, automaatiosta ja siitä, miten tiedot käyttäytyvät alustalla.

Koko yrityksen tasolla kysymme laajempia kysymyksiä. Missä asiakas (Customer) oikeasti asuu? Kuka omistaa tuotteen (Product)? Mikä järjestelmä luo tilauksen (Order)? Mikä on auktoritatiivinen tunnisteemme? Mitkä tiedot kopioidaan järjestelmien välillä, ja mitkä pysyvät paikallaan?

Kahden tason täytyy kytkeytyä toisiinsa. Olen nähnyt Salesforce-toteutuksia, joissa sisäinen malli oli itsessään täysin järkevä, mutta ei sopinut ympäröivään yritykseen. Se ei riitä. Salesforcen rakenteiden täytyy näkyä yritystasolla, ja yrityksen päätösten täytyy virrata takaisin Salesforceen.

Arkkitehtuuri on kaksisuuntaista liikennettä.

Click to enlarge

Hidasta kalliiden päätösten kohdalla

Yksi teknologian vaaroista on, että helpoimmin toteutettavat päätökset voivat näyttää helpoimmilta tehdä. Ne eivät ole sama asia.

Uuden mukautetun objektin luominen on helppoa. Uuden kentän luominen on helppoa. Uuden API:n kytkeminen helpottuu koko ajan, ja tekoäly tekee kaikesta tästä vielä helpompaa.

Mutta toteutuksen helppous ei kerro meille juuri mitään arkkitehtuurisen päätöksen hinnasta.

Ennen vaikeasti peruttavaa päätöstä hidasta niin pitkäksi aikaa, että ehdit kysyä: Mitä ongelmaa oikeasti ratkaisemme? Mitä vaihtoehtoja harkitsimme? Mitä oletamme? Mitä tapahtuu, kun volyymi kasvaa ja kun liiketoiminta muuttuu? Mikä muu tulee riippumaan tästä? Mitä tapahtuu, jos olemme väärässä?

Emme tarvitse kuuden kuukauden arviointia aina, kun luomme objektin. Tarvitsemme kuitenkin harkintaa suhteessa siihen, mitä erehtyminen maksaa. Jos kyse on objektista yhdelle osastolle tai alijärjestelmälle, voit edetä nopeammin. Jos kyse on viitetiedoista, keskeisestä asiakasobjektista tai jostain, jota käytetään järjestelmien välillä, ota aikaa ajatella se loppuun.

Kirjoita perustelut ylös

Tärkeissä päätöksissä on toinenkin ongelma: ihmiset unohtavat, miksi ne tehtiin.

Joku katsoo arkkitehtuuria kolme vuotta myöhemmin ja kysyy: ”Miksi kukaan suunnittelisi sen näin?” Joskus vastaus on, että se oli huono suunnitelma. Sitä tapahtuu. Mutta joskus siihen oli erittäin hyvä syy: alustan rajoitus, jota ei enää ole, sääntelyvaatimus, toinen järjestelmä, joka ei tukenut toivottua lähestymistapaa, tai tietoisesti hyväksytty kompromissi määräajan saavuttamiseksi.

Jos kirjaamme vain sen, mitä päätimme, emmekä sitä, miksi, seuraavalla arkkitehdilla ei ole mitään keinoa tietää.

Kirjoita merkittävät päätökset ylös. Sen ei tarvitse olla 50-sivuinen dokumentti. Hyödyllinen päätöskirjaus voi olla hyvin pieni:

Konteksti: Mitä ongelmaa ratkaisemme?

Vaihtoehdot: Mitä realistisia vaihtoehtoja harkitsimme?

Päätös: Mitä valitsimme?

Seuraukset: Mitä saamme, ja mistä luovumme?

Omistaja: Kuka vastaa tästä päätöksestä?

Tarkastelu: Minkä syyn tai päivämäärän pitäisi saada meidät palaamaan siihen?

Arvo ei ole dokumentissa. Arvo on päättelyn säilyttämisessä.

Ja kun päätös muuttuu, älä pyyhi alkuperäistä. Korvaa se uudella. Päätös, joka oli oikea vuonna 2027, ei ehkä ole oikea vuonna 2030, koska volyymit, liiketoiminta, Salesforce ja ymmärryksemme muuttuvat. Haluan säilyttää tarinan: tämä oli konteksti, tämä oli päätös ja sen syy, tämä muuttui, ja tämän päätämme nyt. Se on paljon arvokkaampaa kuin teeskennellä, että tiesimme vastauksen aina.

Click to enlarge

Kokeen jälkeen: tekoäly lyhentää aikaa päätöksestä riippuvuuteen. Tekoälytyökalu voi ehdottaa tietomallia sekunneissa ja luoda sitten sen päälle objektit, automaation, integraatiokoodin ja käyttöliittymän. Kyseenalainen päätös vaati ennen kuukausien kehitystyön ennen kuin siitä riippui paljon mitään; nyt riippuvuudet syntyvät lähes heti. Arvioi siis tuotoksen alla olevat päätökset, älä pelkkää tuotosta. Tekoäly voi auttaa: se voi listata vaihtoehtoja, haastaa oletuksia ja luonnostella päätöskirjauksen. Mutta arkkitehti päättää edelleen, ja mitä vaikeampi päätös on perua, sitä tärkeämpää ihmisen harkinta on.

Tiedä, mitkä päätökset ovat tärkeitä

Yksi taidoista, joita haluan sinun kehittävän, on tietää, mihin käytät huomiosi.

Älä tee jokaisesta konfiguraatiovalinnasta arkkitehtuurin huippukokousta.

Mutta älä myöskään tee kevyesti päätöstä, jonka kanssa organisaatio elää seuraavat kymmenen vuotta.

Kysy:

Kuinka vaikeaa tämä on perua?

Kuinka paljon siitä tulee riippumaan?

Jos vastaukset ovat hyvin vaikeaa ja paljon, olet luultavasti löytänyt arkkitehtuurisen päätöksen.

Click to enlarge

Hidasta. Ymmärrä vaatimus. Tutki vaihtoehdot. Tee kompromissit näkyviksi. Tee päätös. Ja kirjoita perustelut ylös.

Arkkitehtuurin tavoite ei ole tehdä päätöksiä, joita ei voi koskaan muuttaa.

Tavoite on tunnistaa ne päätökset, joissa mielen muuttaminen tulee kalliiksi.

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

• Mitkä päätökset ovat arkkitehtuurisia: vaikeita perua, ja niistä riippuu paljon.
• Kuinka paljon huomiota kukin päätös saa, suhteessa erehtymisen hintaan.
• Mitkä päätökset kirjataan ylös kontekstin, vaihtoehtojen, seurausten, omistajan ja tarkastelukohdan kanssa.
• Miten Salesforcen päätökset sovitetaan yrityksen päätöksiin.

Lue lisää

• Object Relationships Overview (opens in a new tab), Salesforce Help (englanniksi, tarkistettu 2026-10-09; tarkistettu uudelleen 2026-10-12): master-detail-suhteessa detail-tietueen pääsy ja omistajuus seuraavat master-tietuetta, ja master-tietueen poistaminen poistaa sen detail-tietueet.
• Considerations for Object Relationships (opens in a new tab), Salesforce Help (englanniksi, tarkistettu 2026-10-09; tarkistettu uudelleen 2026-10-12): lookup-suhde muuttuu master-detail-suhteeksi vain, kun jokaisessa tietueessa on siinä arvo; muunnos muuttaa jakamismallin (Controlled by Parent), ja suhteen tyyppi ratkaisee, mitkä vakioraporttityypit ovat käytettävissä.
• Roll-Up Summary Field (opens in a new tab), Salesforce Help (englanniksi, tarkistettu 2026-10-09; tarkistettu uudelleen 2026-10-12): koontikenttiä (roll-up summary) on vain master-detail-suhteissa, ja ne on poistettava ennen kuin master-detail-suhteesta voi tehdä lookup-suhteen.