Ajattele kuin arkkitehti
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)
Moduuli 1/7 luvussa Ajattele kuin tietoarkkitehti, Data Architect -kurssin luku 1. Jokainen moduuli on itsenäinen. Edellinen: luvun yleiskatsaus · Seuraava: Tietomalli on luuranko
Kysymys, johon tämä moduuli vastaa: Mitä eroa on rakentamisella ja arkkitehtuurilla, ja mitä arkkitehti oikeasti tekee?
Suurimman osan urastani olen ollut rakentaja.
Aloitin kehittäjänä. Tein töitä Javalla ja .NETillä ennen kuin siirryin Salesforcen pariin, ja olen vuosien ajan suunnitellut järjestelmiä, kirjoittanut koodia, integroinut alustoja, opettanut arkkitehteja ja arvioinut arkkitehtuureja.
Yksi tärkeimmistä asioista, jotka matkan varrella opin, on kuitenkin se, että loistava rakentaja ja loistava arkkitehti eivät aina ole sama asia.
Rakentaja kysyy:
Miten rakennan tämän?
Arkkitehdin on kysyttävä toisenlaisia kysymyksiä:
Pitäisikö meidän rakentaa tämä?
Miksi rakennamme sen juuri näin?
Mitkä ovat vaihtoehdot?
Mitä tapahtuu, kun tämä kasvaa?
Mitä tapahtuu, kun se pettää?
Ja minkä päätöksen teemme tänään, jota olisimme toivoneet miettineemme tarkemmin kolmen vuoden päästä?
Muistan projektin vähittäiskaupan yritykselle, jossa oli ajanvarauksia. Kysyin: montako ajanvarausta päivässä myymälää kohden? Sitten: montako myymälää teillä on? Ja montako päivää viikossa olette auki? Huomasin nopeasti, että pelkästään ensimmäisenä vuonna ajanvarauksia kertyisi miljoonia. Tällaisia kysymyksiä arkkitehti kysyy projektin alussa.
Tästä ajattelun muutoksesta tässä kurssissa oikeastaan on kyse.
Henkilö, jolla on piirustukset kädessä
Osio nimeltä “Henkilö, jolla on piirustukset kädessä ”Olen käyttänyt tätä vertausta monta kertaa opettaessani arkkitehteja.
Kuvittele rakennustyömaa. Siellä on ihmisiä valamassa betonia, vetämässä sähköjä, asentamassa putkia, rakentamassa seinärunkoja ja tekemässä kymmeniä muita erikoistuneita töitä. Heidän täytyy olla todella hyviä siinä, mitä tekevät.
Jonkun täytyy kuitenkin myös pitää piirustuksia kädessään.
Tämän henkilön täytyy ymmärtää, miten kaikki palaset sopivat yhteen. Hänen täytyy huomata, kun jokin projektin yhdessä osassa aiheuttaa ongelman jossain muualla.
Se on arkkitehtuuria.
Teknologiassa teemme joskus sen virheen, että ajattelemme arkkitehdin olevan yksinkertaisesti se, joka tietää eniten. Ei se oikeastaan niin mene. Alustan tunteminen on tärkeää. Tarvitset teknistä syvyyttä. Mutta arkkitehtuuri ei ole tietovisa.
Arkkitehdin tehtävä on tehdä hyviä päätöksiä, joskus puutteellisin tiedoin ja ristiriitaisten vaatimusten keskellä, ja ymmärtää niiden päätösten seuraukset.
Se on aivan eri taito.
Älä vain ota vaatimusta vastaan
Osio nimeltä “Älä vain ota vaatimusta vastaan ”Yksi ensimmäisistä tavoista, jonka haluan arkkitehtien omaksuvan, on yksinkertainen:
Kysy miksi.
Joku sanoo sinulle:
Tarvitsemme uuden objektin.
Miksi?
Tarvitsemme tämän kentän kopioituna tilille (Account).
Miksi?
Tarvitsemme kaikki nämä tiedot tallennettuna Salesforceen.
Miksi?
Se ei tarkoita hankalana olemista. Se tarkoittaa todellisen liiketoimintavaatimuksen ymmärtämistä sen sijaan, että toteuttaisit ehdotetun ratkaisun saman tien.
Vaatimus saapuu usein suunnitelmaksi naamioituneena.
”Tarvitsemme uuden mukautetun objektin” ei välttämättä ole vaatimus. Vaatimus voi oikeasti olla ”meidän täytyy seurata näitä tietoja erikseen”. Ne eivät ole sama asia.
Kun ymmärrät todellisen vaatimuksen, voit alkaa tutkia vaihtoehtoja. Ehkä uusi objekti on juuri oikea vastaus. Ehkä tiedot kuuluvat johonkin jo olemassa olevaan paikkaan. Ehkä Salesforcen ei pitäisi omistaa niitä tietoja lainkaan.
Arkkitehdin täytyy erottaa se, mitä liiketoiminta tarvitsee, yhdestä ehdotetusta tavasta toteuttaa se.
Teimme myyntisovellusta, ja asiakkaalla oli useita hyväksyntöjä, joista jokaisella oli hyväksyjä ja päivämäärä. Heidän ensimmäinen pyyntönsä oli lisätä myyntimahdollisuudelle (Opportunity) kentät Hyväksyjä 2 ja Hyväksyjä 3, kummallekin oma päivämäärä. Kun kaivoimme syvemmälle, huomasimme, että hyväksyjiä voisi olla enemmän kuin kaksi tai kolme. Siirsimme siis hyväksynnät lapsiobjektiin. Pyyntö koski lisää kenttiä; vaatimus oli seurata jokaista hyväksyntää, oli niitä lopulta kuinka monta tahansa.
Ajattele vaatimusta pidemmälle
Osio nimeltä “Ajattele vaatimusta pidemmälle ”Miksi-kysymyksestä seuraa kaksi tapaa, ja kumpikin saa oman moduulinsa myöhemmin tässä luvussa.
Vastauksia on yleensä useampi kuin yksi. Salesforce antaa meille monta tapaa ratkaista ongelma, ja jotkin niistä ovat vääriä lähes heti. Toimivien vaihtoehtojen välillä valitseminen on kompromissien taitoa (moduuli 4).
Ja sinulle annetut vaatimukset eivät ole kaikki vaatimukset, jotka sinulla on. Kukaan ei sano ”varmista, että tämä toimii, kun yöllinen lataus onnistuu vain puoliksi”, mutta se on silti vaatimus. Katson jokaista suunnitelmaa kolmen linssin läpi: rakenna tätä päivää varten, suunnittele huomista varten, suunnittele virheitä varten (moduuli 5).
Ajattele jotakuta, joka palkkaa arkkitehdin suunnittelemaan rakennuksen. Hän ei pyydä palohälytintä tai sprinklerijärjestelmää eikä sitä, että rakennus pysyy pystyssä maanjäristyksessä. Hän odottaa niitä osana työtä pyytämättä. Meidän maailmamme toimii samalla tavalla. Kukaan ei pyydä hallittua virheenkäsittelyä, lokeja tai keinoa toipua, kun jokin pettää. Arkkitehdin tehtävä on tietää, mitkä näistä järjestelmistä kuuluvat suunnitelmaan, ja lisätä ne.
Tee päättelysi näkyväksi
Osio nimeltä “Tee päättelysi näkyväksi ”Arkkitehdin ei pitäisi vain kävellä huoneeseen ja ilmoittaa: ”Näin me teemme.”
Sinun tehtäväsi on myös selittää miksi. Haluan sidosryhmien ymmärtävän, mitä vaihtoehtoja harkitsimme ja mitä kompromisseja niihin liittyi. Se ei tarkoita 40-sivuisen suunnitteludokumentin antamista johtajalle. Se tarkoittaa, että pystyt selittämään saman arkkitehtuurin kehittäjälle, liiketoiminnalle ja johtajalle: eri keskustelut samasta päätöksestä.
Ja se onnistuu selkeillä piirustuksilla ja ohjeilla, kuten rakennustyömaalla piirustuksia kädessään pitävällä henkilöllä. Tietoarkkitehdille yksi tärkeimmistä piirustuksista on tietomalli.
Jos kukaan ei ymmärrä, miksi päätös tehtiin, on hyvä mahdollisuus, että joku lopulta purkaa sen. Ja hänellä voi olla siihen täysin järkevät syyt, koska kukaan ei koskaan selittänyt alkuperäistä päätöstä.
Arkkitehdin ei tarvitse rakentaa kaikkea
Osio nimeltä “Arkkitehdin ei tarvitse rakentaa kaikkea ”On toinenkin siirtymä, joka voi olla vaikea, etenkin niille, jotka tulevat arkkitehtuuriin kehittäjän taustalta.
Sinun ei tarvitse rakentaa kaikkea itse.
Pidän edelleen siitä, että ymmärrän, miten asiat toimivat hyvin teknisellä tasolla, ja se pohja on tärkeä. Mutta arkkitehtina vastuusi kasvaa omaa toteutustasi suuremmaksi. Sinun ei tarvitse rakentaa kaikkea; sinun täytyy osata antaa rakentajille oikea suunta ja oikeat reunaehdot. Se tarkoittaa, että ymmärrät tarpeeksi ohjataksesi heidän työtään, tunnistaaksesi, milloin ehdotettu toteutus luo arkkitehtuurisen ongelman, ja liikkuaksesi yksityiskohtien ja kokonaiskuvan välillä.
Joskus se tarkoittaa syvälle sukeltamista kyselyyn, API:in tai tietomalliin.
Joskus se tarkoittaa askelta taaksepäin ja kysymystä siitä, pitäisikö meidän tehdä mitään tästä ylipäätään.
Ja yhä useammin rakentajina eivät ole pelkästään ihmiset. Tekoälyn kanssa arkkitehti saattaa työskennellä suoraan sen työkalun kanssa, joka luo objektit, koodin ja näkymät. Silloin suunta, reunaehdot ja ohjeet menevät tekoälylle, ja niiden antaminen hyvin on yhä enemmän arkkitehdin vastuulla. Palaamme tähän moduulissa 7.
Se on osa matkaa rakentajasta arkkitehdiksi.
Sinun tehtäväsi on tehdä päätöksiä
Osio nimeltä “Sinun tehtäväsi on tehdä päätöksiä ”Lopulta arkkitehtuurissa on kyse päätöksistä.
Joitakin päätöksiä on helppo muuttaa. Toisia ei.
Sivun asettelun voi muuttaa. Otsikon voi nimetä uudelleen.
Mutta jos valitset väärän perustavan tietomallin, julkaiset tunnisteita, joista kymmenet järjestelmät alkavat riippua, tai sijoitat kriittisten tietojen pääkopion väärään paikkaan, mielen muuttamisesta tulee paljon kalliimpaa.
Ne ovat arkkitehtuurisia päätöksiä. Ja juuri sellaisiin päätöksiin tämä kurssi keskittyy.
Tietoarkkitehtina teet päätöksiä siitä, miten tieto on jäsennelty, missä se asuu, miten se kasvaa, miten se liikkuu, kuka pääsee siihen käsiksi ja miten muu yritys sen ymmärtää.
Teknologialla on merkitystä.
Mutta jokaisen Salesforce-ominaisuuden tunteminen ei ole tavoite.
Tavoite on kehittää harkintaa tietää, mitä työkalua käyttää, milloin sitä käyttää, mistä luovut ja mitä tapahtuu seuraavaksi.
Sitä on arkkitehdin tapa ajatella.
Ja nyt voimme alkaa ajatella kuin tietoarkkitehti.
Mitä arkkitehti tässä päättää
Osio nimeltä “Mitä arkkitehti tässä päättää ”- Onko pyyntö todellinen vaatimus vai yksi ehdotettu suunnitelma sen toteuttamiseksi.
- Mitä kysyä ennen kuin mitään rakennetaan: pitäisikö meidän, miksi näin, mitä muuta voisimme tehdä, mitä tapahtuu, kun se kasvaa tai pettää.
- Mitkä päätökset kuuluvat arkkitehdille ja mitkä rakentajille; ja millaisen suunnan ja reunaehdot rakentajat saavat, olivat he ihmisiä tai tekoälyä.
- Miten päätös selitetään niin, että kehittäjä, liiketoiminta ja johtaja kukin ymmärtävät sen.