Rakenna tätä päivää varten. Suunnittele huomista varten. Suunnittele virheitä varten.

🌐 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 5/7 luvussa Ajattele kuin tietoarkkitehti, Data Architect -kurssin luku 1. Jokainen moduuli on itsenäinen. Edellinen: Arkkitehtuuri on kompromissien taitoa · Seuraava: Tunne työkalusi: yhdeksän kysymystä

Kysymys, johon tämä moduuli vastaa: Miten suunnittelet tämän päivän vaatimuksia varten ja varaudut samalla kasvuun ja virheisiin?

Yksi helpoimmista virheistä arkkitehtuurissa on suunnitella vain edessä olevia vaatimuksia varten. Meillä on projekti, työjono ja vaatimukset. Rakennamme jotain, joka täyttää ne. Se toimii, ja julistamme voiton. Puoli vuotta myöhemmin liiketoiminta muuttuu, tai tietomäärä kasvaa, tai toinen liiketoimintayksikkö haluaa käyttää ratkaisua, tai ostamme yrityksen, tai uusi järjestelmä täytyy integroida, tai jokin pettää tavalla, johon kukaan ei varautunut.

Minkään tästä ei pitäisi yllättää arkkitehtia. Emme voi ennustaa kaikkea, mitä tulee tapahtumaan, mutta voimme suunnitella tietäen, että jotain tapahtuu. Siksi katson arkkitehtuuria kolmen linssin läpi:

Rakenna tätä päivää varten. Suunnittele huomista varten. Suunnittele virheitä varten.

Tarvitset kaikki kolme.

Click to enlarge

Rakenna tätä päivää varten

Arkkitehtuuri alkaa siitä ongelmasta, joka meillä oikeasti on. Se kuulostaa itsestään selvältä, mutta arkkitehdit voivat tehdä lyhytnäköisyyden vastakkaisen virheen: voimme ylisuunnitella. Entä jos ostamme kaksitoista yritystä, saamme miljardi asiakasta, laajennamme 40 maahan ja jokainen järjestelmä tarvitsee reaaliaikaisen integraation? Ehkä. Mutta ovatko ne todellisia mahdollisuuksia, vai keksimmekö ongelmia? Arkkitehtuurissa ei ole kyse hienostuneimman kuviteltavissa olevan järjestelmän rakentamisesta. Siinä on kyse sopivan järjestelmän rakentamisesta.

Aloita siis tästä päivästä: mitä liiketoiminta tarvitsee, todelliset volyymit, käyttäjät ja transaktiot, kuinka usein tiedot muuttuvat ja kuinka nopeasti niiden täytyy liikkua, kuka tarvitsee pääsyn ja mistä tiedot tulevat ja minne ne menevät. Ja ennen kaikkea: miksi? Nämä vastaukset antavat meille jotain konkreettista suunniteltavaksi.

Etsi epäsuorat vaatimukset

Sinulle annetut vaatimukset eivät välttämättä ole kaikki vaatimukset, jotka sinulla on. Lähes aina on epäsuoria vaatimuksia.

Liiketoiminta sanoo: ”Tarvitsemme asiakastiedot Salesforceen.” Selvä. Sitten jonkun täytyy omistaa ne tiedot ja päättää, kuinka tuoreita niiden pitää olla. Meidän täytyy tietää, mitä tapahtuu, kun lähdejärjestelmä on alhaalla, miten huomaamme synkronoinnin epäonnistuvan ja kumpi voittaa, kun Salesforce ja lähde ovat eri mieltä. Tarvitsemme säilytysajan, pääsymallin, päätöksen arkaluonteisista kentistä ja keinon korjata virheelliset tiedot.

Mitään tästä ei ollut käyttäjätarinassa. Kaikki se on silti arkkitehtuuria. Suuri osa arkkitehdiksi kasvamista on oppia tunnistamaan kysymykset, joita ei ole vielä kysytty.

Tunne lukusi

Patistan arkkitehteja jatkuvasti määrällistämään. Älä sano, että tietoja on paljon; kerro, kuinka paljon. Kymmenentuhatta, kymmenen miljoonaa, sata miljoonaa, miljardi? Ne ovat hyvin erilaisia arkkitehtuureja. Älä sano, että integraatio ajetaan usein: kerran tunnissa, kerran minuutissa, tuhat kertaa sekunnissa? Älä sano, että kasvamme nopeasti. Kuinka nopeasti?

Kun minulla ei ole parempaa lukua, lähtötasoni on 30 % vuosikasvu. Se ei ole ennuste; se on pakottava keino. Jos joku sanoo, että meillä on tänään 10 miljoonaa tietuetta, en halua keskustelun pysähtyvän 10 miljoonaan. 30 %:n vuosikasvulla olemme ensi vuonna noin 13 miljoonassa, sitä seuraavana 17 miljoonassa ja sitä seuraavana noin 22 miljoonassa. Puhutaan nyt suunnitelmasta. Jos liiketoiminta sanoo, että 30 % on naurettava, hienoa: anna minulle todellinen luku. Tarkoitus on tehdä kasvusta osa arkkitehtuurikeskustelua.

Kutsun tätä Steven ”nollien määräksi” (Steve’s Number of Zeros). Yksi ylimääräinen nolla voi muuttaa arkkitehtuurisi täysin. Kymmenentuhatta, satatuhatta, miljoona, kymmenen miljoonaa, sata miljoonaa: ominaisuus ei muuttunut, eikä vaatimuskaan ehkä muuttunut, mutta arkkitehtuuri saattaa muuttua.

Muistatko ajanvaraukset moduulista 1? Laitetaan niihin oikeat luvut. Yli 1 200 toimipaikkaa, 100 ajanvarausta toimipaikkaa kohden päivässä, kuutena päivänä viikossa, noin 305 päivänä vuodessa. Se tekee yli 36 miljoonaa ajanvarausta ensimmäisenä vuonna. Jokainen käynti luo kaksi tietuetta, eli yli 73 miljoonaa tietuetta. Säilytä nyt viiden vuoden historia 30 %:n vuosikasvulla, ja tietueita on yli 650 miljoonaa. Sama ominaisuus, sama vaatimus. Pari nollaa lisää, ja aivan erilainen arkkitehtuuri.

Suunnittele huomista varten

Kun ymmärrän tämän päivän, katson eteenpäin: mikä todennäköisesti muuttuu? Volyymi on osa sitä, mutta huominen ei ole vain enemmän. Se voi tarkoittaa myös erilaista: lisää tuotteita, liiketoimintayksiköitä ja maita; erilaisia tietosuojavaatimuksia; uusia kanavia ja integraatioita; yrityskauppaa tai fuusiota; uutta perustietostrategiaa tai analytiikka-alustaa; tekoälyagenttia, joka käyttää tietoja, jotka suunniteltiin vain ihmisille.

Siksi välitän niin paljon siitä, pystyykö arkkitehtuuri kasvamaan lisäämällä eikä jatkuvalla muuttamisella. Jos liiketoiminta lisää tuotteen, pystyykö malli ottamaan sen vastaan? Jos toinen järjestelmä tarvitsee tiedot, voimmeko tarjota ne siististi? Jos volyymi hyppää, onko meillä minne mennä? Jos liiketoiminnan rakenne muuttuu, joudummeko repimään tietomallin palasiksi? Emme yritä ennustaa tulevaisuutta täydellisesti. Yritämme olla maalaamatta itseämme nurkkaan.

Älä rakenna huomista tänään

Tässä tarvitaan tasapainoa. Huomisen suunnittelu ei tarkoita huomisen järjestelmän rakentamista tänään. Jos meillä on 100 000 tietuetta ja viiden vuoden päästä ehkä 100 miljoonaa, se ei tarkoita, että rakennamme 100 miljoonan tietueen arkkitehtuurin nyt. Se voi tuoda kustannuksia ja monimutkaisuutta, joita emme vielä tarvitse.

Kysymys, johon haluan vastauksen, on: voiko tämän päivän arkkitehtuuri kehittyä huomisen arkkitehtuuriksi? Jos voimme aloittaa yksinkertaisesti ja selkeä polku eteenpäin on olemassa, se on usein parempi kuin maksaa monimutkaisuuden hinta vuosia etuajassa. Vaara ei ole pienestä aloittaminen. Vaara on aloittaa jostain, mistä ei pääse mihinkään.

Suunnittele virheitä varten

Nyt osa, josta kukaan ei mielellään puhu: asiat pettävät. En ole koskaan suunnitellut järjestelmää, jossa jokainen komponentti olisi pysynyt saatavilla ikuisesti, jokainen integraatio olisi onnistunut, jokainen käyttäjä olisi syöttänyt täydellisiä tietoja ja jokainen ulkoinen järjestelmä olisi käyttäytynyt täsmälleen dokumentaation mukaan. Älä siis suunnittele sellaista järjestelmää.

Kysy, mikä voi pettää, ja kysy sitten, mitä tapahtuu, kun se pettää. Integraatio aikakatkaistaan. API hylkää pyynnön. Yöllinen lataus käsittelee 800 000 tietuetta ja epäonnistuu 200 000:ssa. Lähdejärjestelmä kaatuu. Käyttäjä syöttää virheellisiä tietoja. Ulkoinen tunniste ilmestyy kahdesti. Ylävirran järjestelmä muuttaa arvon muotoa muuttamatta kentän nimeä. Prosessi onnistuu yhdessä järjestelmässä ja epäonnistuu toisessa. Nämä eivät ole harvinaisia erikoistapauksia. Tältä tuotanto näyttää.

Osittainen onnistuminen on silti virhe, joka sinun on ymmärrettävä

Osittaiset virheet ovat tietoarkkitehtuurissa erityisen vaarallisia. Kuvittele, että siirrät miljoona tietuetta, ja prosessi ilmoittaa valmistuneensa. Hienoa. Mutta saapuiko miljoona vai 999 997, ja mitkä kolme puuttuvat? Ehkä 200 000 epäonnistui, osa luotiin kahdesti, tai kaikki saapuivat, mutta joidenkin kenttien muunnos epäonnistui.

”Työ valmis” ei ole sama asia kuin tiedot ovat oikein. Tietoarkkitehti ajattelee täsmäytystä ja sovitusta: mistä tiedämme, minkä olisi pitänyt tapahtua, mitä oikeasti tapahtui ja mikä on ero? Ja mitä teemme asialle?

Näin teen, kun järjestelmät monimutkaistuvat. Tietueet kulkevat A:sta B:hen, vasemmalta oikealle. Sitten B lähettää jotain takaisin: kuittauksen jokaisesta tietueesta, jonka se vastaanotti ja tallensi. Nyt A voi verrata lähettämäänsä siihen, mitä kuitattiin. Jos jokaisella tietueella on kuittauksensa, ajo onnistui. Jos kuittauksia puuttuu, se ei onnistunut, sanoi työn tila mitä tahansa, ja tiedämme tarkalleen, mitkä tietueet pitää selvittää: yritä ne uudelleen, ohjaa ne ihmiselle tai nosta hälytys.

Click to enlarge

Epäonnistu hallitusti

Kun virhe tapahtuu, haluan tietää, mitä järjestelmä tekee seuraavaksi: yrittääkö se uudelleen, ja automaattisesti vai ei; mitä tapahtuu, jos sama transaktio käsitellään kahdesti; minne epäonnistuneet tietueet menevät ja jatkavatko hyvät tietueet kulkuaan huonon ohi; kuka saa hälytyksen, millä tiedoilla ja miten hän toistaa epäonnistuneen ajon; ja miten käyttäjä saa tietää, että jokin meni pieleen.

Ja ennen kaikkea: voimmeko toipua pahentamatta ongelmaa? Uudelleenyrityksen strategia, joka luo kaksoiskappaleita, ei ole kummoinen palautumisstrategia. Hyvä arkkitehtuuri olettaa virheitä ja antaa meille tien takaisin.

Valvo sitä, mikä on tärkeää

Virheisiin varautuminen ilman valvontaa ei oikeastaan ole varautumista. Jos integraatio pettää klo 2.00 yöllä eikä kukaan huomaa ennen kuin asiakas soittaa kolme päivää myöhemmin, meillä ei ollut toiminnallista arkkitehtuuria. Meillä oli toivo.

Päätä, minkä täytyy olla havaittavissa: ajettiinko prosessi, kuinka kauan se kesti, montako tietuetta käsiteltiin, montako onnistui ja montako epäonnistui? Poikkeavatko volyymit yhtäkkiä tavallisesta? Kasvaako jono, lisääntyvätkö virheet? Arkkitehtuuri ei pääty, kun käyttöönotto onnistuu. Jonkun täytyy pyörittää tätä järjestelmää huomenna, ja se on osa suunnitelmaa.

Ajattele kaikkiin kolmeen suuntaan

Käytä kolmea linssiä koko loppukurssin ajan. Kun suunnittelemme tietomallia: toimiiko se tänään, voiko se kasvaa huomenna ja mitä tapahtuu, kun tiedot ovat virheellisiä tai puutteellisia? Integraatio: siirtääkö se tämän päivän tiedot, kestääkö se huomisen volyymit ja järjestelmät ja mitä tapahtuu, kun toinen osapuoli on alhaalla? Suuret tietomäärät: mitä meillä on tänään, mihin luvut ovat menossa ja miten toivumme, kun suuri operaatio onnistuu vain osittain?

Teknologia vaihtuu luvusta toiseen. Kysymykset eivät.

Arkkitehtuuri elää ajassa

Kehittäjä voi joskus katsoa vaatimusta ja kysyä: ”Toimiiko tämä?” Arkkitehdin on kysyttävä enemmän: toimiiko se tänään, toimiiko se yhä huomenna ja mitä tapahtuu, kun se ei toimi lainkaan? Nämä kolme kysymystä vievät meidät toteutuksen tuolle puolen, järjestelmän elinkaareen.

Et pysty ennustamaan jokaista tulevaa vaatimusta tai estämään jokaista virhettä. Se ei ole tavoite. Tavoite on rakentaa jotain, mikä sopii siihen, mitä tiedämme tänään, jättää itsellemme tie eteenpäin huomiseen ja pitää suunnitelma valmiina sitä varten, kun todellisuus ei tee yhteistyötä.

Rakenna tätä päivää varten. Suunnittele huomista varten. Suunnittele virheitä varten. Käytämme näitä kolmea linssiä yhä uudelleen.

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

• Mitkä todelliset volyymit ja kasvu ovat, ja mitkä luvut muuttaisivat suunnitelmaa.
• Mitä epäsuoria vaatimuksia liiketoiminta ei ole vielä sanonut ääneen.
• Miten tämän päivän suunnitelma voi kehittyä huomisen suunnitelmaksi rakentamatta huomisen järjestelmää tänään.
• Mitä tapahtuu, kun jokin pettää: palautuminen, täsmäytys ja valvonta.