Arkkitehtuuri on kompromissien taitoa
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 4/7 luvussa Ajattele kuin tietoarkkitehti, Data Architect -kurssin luku 1. Jokainen moduuli on itsenäinen. Edellinen: Peruttavuustesti · Seuraava: Rakenna tätä päivää varten. Suunnittele huomista varten. Suunnittele virheitä varten.
Kysymys, johon tämä moduuli vastaa: Kun useampi ratkaisu voisi toimia, miten arkkitehti valitsee ja perustelee valintansa?
Jos arkkitehtuurissa olisi kyse vain oikean vastauksen tunnistamisesta, se olisi paljon helpompaa. Opettele alusta, opettele mallit, opettele rajat, valitse oikea, valmis.
Todellinen arkkitehtuuri ei toimi niin. Vaikeat päätökset eivät yleensä ole selvästi hyvän ja selvästi huonon ratkaisun välillä. Ne ovat useiden toimivien ratkaisujen välillä, joista jokaisella on etunsa ja haittansa ja joista jokainen vie arkkitehtuuria hieman eri suuntaan. Siinä arkkitehti ansaitsee paikkansa pöydän ääressä.
Monta tapaa ratkaista ongelma
Osio nimeltä “Monta tapaa ratkaista ongelma ”Olen käyttänyt versiota tästä esimerkistä monta kertaa opettaessani arkkitehteja.
Salesforcessa ongelman voi usein ratkaista monella tavalla. Joskus annan sille luvun, vaikkapa kymmenen, mutta se on vertaus, ei laskelma. Monissa vaihtoehdoissa on ongelmia alusta asti: ne törmäävät alustan rajoitukseen, eivät täytä kriittistä vaatimusta tai luovat tietoturva- tai suorituskykyongelman, jota emme voi hyväksyä. Ne voimme siirtää sivuun nopeasti. Jotkin toiset toimivat tänään, mutta niissä tulee ongelmia, kun tietomäärä kasvaa. Ne toimivat teknisesti, mutta eivät kestä kasvua, jonka jo tiedämme olevan tulossa.
Jäljelle jää pieni määrä vaihtoehtoja, jotka pystyvät kantamaan tarpeesi myös jatkossa, ja nyt asiat muuttuvat kiinnostaviksi. Jokainen niistä saattaa toimia, skaalautua ja täyttää vaatimukset. Mikä niistä on siis oikea? Ehkä kaikki. Arkkitehdin tehtävä on ymmärtää erot.
Jopa niin yksinkertainen asia kuin valintaluettelo toimii tänään ja voi tuottaa ongelmia tietomäärän kasvaessa. Valintaluettelo on käyttäjille helppo. Mutta kysy, mistä arvot tulevat ja kuinka monta niitä voi olla. Valintaluettelot toimivat parhaiten, kun arvoja on alle noin 20. Joskus mennään 50:een, kuten Yhdysvaltain osavaltioissa, ja harvoin yli sadan, kuten maissa, ja ne käyvät kömpelöiksi. Tiedä siis jokaisen valintaluettelon yläraja. Ja valintaluettelon arvojen muuttaminen on metatietomuutos, ei tietomuutos.
Käytä sen sijaan lookup-suhdetta, niin käyttöliittymästä tulee hieman monimutkaisempi. Mutta luettelo voi kasvaa ilman ylärajaa, ja uusia arvoja voi tulla integraatiosta. Se on kompromissi käytettävyyttä vastaan. Se on tasapainoilua.
Optimaalinen ei tarkoita täydellistä
Osio nimeltä “Optimaalinen ei tarkoita täydellistä ”Käytän sanaa optimaalinen harkiten. Optimaalinen arkkitehtuuri ei ole sellainen, jossa jokainen yksittäinen päätös on täydellinen; sellaista arkkitehtuuria tuskin on olemassa. Se on sellainen, jossa kokonaisratkaisu on tasapainossa.
Oletetaan, että ratkaisu A antaa parhaan suorituskyvyn, mutta on kallis ja vaikea ylläpitää. Ratkaisu B maksaa vähemmän ja on helpompi pyörittää, mutta luopuu osasta suorituskykyä. Ratkaisu C on joustavampi tulevaisuutta varten, mutta lisää monimutkaisuutta tänään. Mikä on optimaalinen? En pysty vastaamaan pelkkien näiden tietojen perusteella. Minun täytyy tuntea liiketoiminta, vaatimukset ja prioriteetit sekä tietää, mitkä rajoitteet ovat todellisia ja mitkä mieltymyksiä. Arkkitehtuuri riippuu kontekstista. Siksi malli, joka oli oikea yhdelle asiakkaalle, voi olla täysin väärä seuraavalle.
Ja tietoarkkitehtina sinun tehtäväsi on tasapainottaa näitä päätöksiä. Teet niitä kymmeniä itse tai tiimisi kanssa. Tiedä, mitkä ne ovat, ja tiedä, milloin päätöksellä on suurempi vaikutus kustannuksiin, aikatauluun tai toiminnallisuuteen ja se täytyy viedä keskeisille päätöksentekijöille.
Epäoptimaalinen päätös voi olla osa optimaalista arkkitehtuuria
Osio nimeltä “Epäoptimaalinen päätös voi olla osa optimaalista arkkitehtuuria ”Tämä on yksi tämän luvun tärkeimmistä ajatuksista. Joskus teen tietoisesti epäoptimaalisen päätöksen arkkitehtuurin yhdessä osassa, koska se tekee koko ratkaisusta paremman.
Ehkä kahdennan pienen määrän tietoja, koska kahdennuksen poistaminen loisi tarpeetonta integraation monimutkaisuutta. Ehkä valitsen yksinkertaisemman tietomallin, koska teoriassa siistimpi tekisi raportoinnista ja arkikäytöstä paljon vaikeampaa. Ehkä hyväksyn pienen suorituskykyhaitan, koska vaihtoehto lisäisi infrastruktuuria, jonka pyörittämiseen organisaatio ei ole valmis.
Katso mitä tahansa näistä erikseen, ja sanoisit, ettei se ole optimaalinen. Aivan oikein. Mutta arkkitehtuurissa ei ole kyse jokaisen komponentin optimoimisesta erikseen; siinä on kyse järjestelmän optimoimisesta. Paikallisesti epäoptimaalinen päätös voi olla osa kokonaisuutena optimaalista arkkitehtuuria, kunhan ymmärrämme tekemämme kompromissin. Vaarallista on tehdä kompromissi tietämättä, että teet sen.
Tiedä, mistä luovut
Osio nimeltä “Tiedä, mistä luovut ”Aina kun joku sanoo minulle ”tämä on paras ratkaisu”, seuraava kysymykseni on ”paras missä?” Nopein? Halvin? Yksinkertaisin? Skaalautuvin, turvallisin, joustavin? Helpoin pyörittää, nopein toimittaa, vähiten riippuvainen erikoisosaamisesta? Lähes aina on jokin toinen ulottuvuus, jossa vastaus ei ole ”paras”. Se on kompromissi. Haluan tietää, mitä saamme, ja haluan myös tietää, mistä luovumme.
Otetaan kaksi vaihtoehtoa suurelle joukolle yrityksen tietoja. Toinen kopioi tiedot Salesforceen, mikä helpottaa Salesforcen omien ominaisuuksien käyttöä, mutta nyt olemme vastuussa tietojen siirtämisestä, tallentamisesta, synkronoinnista, yhden kopion lisää suojaamisesta ja viiveen hallinnasta. Toinen jättää tiedot paikalleen ja hakee ne tarvittaessa. Olemme poistaneet osan kahdennuksesta, mutta nyt saatavuus, kyselyjen suorituskyky, verkkoriippuvuudet ja etäjärjestelmän kyvyt painavat enemmän. Kumpikaan kuvaus ei kerro, kumpi valita. Se kertoo, mitä kysymyksiä kysyä.
Vaatimukset eivät ole samanarvoisia
Osio nimeltä “Vaatimukset eivät ole samanarvoisia ”Kompromissit pakottavat meidät myös näkemään, että jokainen vaatimus ei paina yhtä paljon.
Joku sanoo: ”Tietojen täytyy olla saatavilla heti.” Selvä, mitä heti tarkoittaa? Sekuntia, kymmentä sekuntia, minuuttia? Ja miksi? Ehkä kyse on petosten tunnistamisesta, jossa sekunneilla on väliä. Ehkä joku vain ei pidä yöllisen latauksen odottamisesta. Ne ovat hyvin erilaisia vaatimuksia, ja arkkitehti kysyy, kunnes tiedämme, kumpi meillä on.
Pidän vaatimuksista, jotka kestävät kysymyksiä: kuinka paljon, kuinka monta, kuinka nopeasti, kuinka usein, kenelle ja mitä tapahtuu, jos emme tee sitä? ”Nopea” ei ole arkkitehtuurivaatimus. ”95 % asiakaspäivityksistä on oltava palveluagentin saatavilla 30 sekunnin kuluessa” on jo paljon lähempänä sellaista. Nyt voimme arvioida kompromisseja.
Rajoitteet muuttavat vastauksen
Osio nimeltä “Rajoitteet muuttavat vastauksen ”Joskus arkkitehtuuria ei rajoita teknologia lainkaan. Sitä rajoittavat raha, ihmiset, aika, lisensointi tai organisaation kypsyys.
Arkkitehtuuri, joka on teknisesti erinomainen, mutta vaatii ylläpitotiimin, jota yrityksellä ei ole, ei ole hyvä arkkitehtuuri. Ominaisuus, joka ratkaisee ongelman tyylikkäästi, mutta vaatii lisensointia, jota asiakas ei aio ostaa, ei sekään ole ratkaisu. Eikä täydellinen kolmen vuoden muutosohjelma auta yritystä, jonka on päästävä tuotantoon kahdeksassa viikossa.
Mikään tästä ei tarkoita, että hylkäämme hyvän arkkitehtuurin määräajan takia. Se tarkoittaa, että ymmärrämme, mistä teemme myönnytyksiä, miksi ja mitkä seuraukset hyväksymme, ja mieluiten myös sen, miten pääsemme tämän päivän myönnytyksestä huomisen arkkitehtuuriin.
Arkkitehti tarvitsee kuvan ”optimaalisesta”
Osio nimeltä “Arkkitehti tarvitsee kuvan ”optimaalisesta” ”Tässä on kiinnostava jännite. Sanon sinulle, että usein ei ole yhtä täydellistä vastausta, ja samalla haluan sinun kantavan päässäsi kuvaa siitä, miltä optimaalinen ratkaisu näyttää. Ne eivät ole ristiriidassa. Tarvitset vertailukohdan.
Kun katson tietomallia, haluan tietää, mitä rakentaisin, jos voisin optimoida vaatimuksia varten ilman tarpeettomia rajoitteita. Sitten kun todelliset rajoitteet työntävät meitä pois siitä suunnitelmasta (litistämme osan mallista, kahdennamme tietoja, lykkäämme integraatiota, hyväksymme väliaikaisen manuaalisen prosessin), en tee satunnaisia myönnytyksiä. Tiedän, mihin suuntaan siirryn pois optimaalisesta ja miksi. Se on arkkitehtuurin taitoa, ja vaisto vaatii harjoittelua.
Piirrä se
Osio nimeltä “Piirrä se ”Yksi parhaista tavoista ymmärtää kompromissi on piirtää se. Arkkitehtuurikaaviot eivät ole diaesityksen koristeita; ne ovat ajattelun työkaluja. Jos valitsemme kahden lähestymistavan välillä, piirrä molemmat. Missä tiedot asuvat ja minne ne liikkuvat? Mikä ne omistaa? Missä rajat ovat ja missä tietoturvaa valvotaan? Mitä tapahtuu, kun jokin pettää, ja mikä muuttuu volyymin kasvaessa?
Kaavio pakottaa epäselvyydet esiin, ja se antaa kaikille saman kuvan, johon osoittaa.
Opin, kuinka tärkeää se on, projektissa energiayhtiön kanssa. Arviointi toisensa jälkeen huomasin selittäväni samoja käsitteitä uudelleen ja vetäväni keskustelua takaisin alkuperäiseen suunnitelmaan. Muutin siis tapaa, jolla vedin noita kokouksia: jokainen arviointi alkoi tietomallilla näytöllä. Ei sillä yksityiskohtaisella, jossa on joka kenttä. Tiivistetyllä mallilla: tilillä on yhteyshenkilöitä, tällä tietueella on lapsia, tässä työ roikkuu. Huoneessa oli enimmäkseen johtajia, ja se vei pari minuuttia.
Koska samat ihmiset istuivat kokouksesta toiseen, kaaviosta tuli yhteinen kielemme. Ihmiset alkoivat käyttää sen nimiä. Toistuvat kysymykset hiipuivat, ja kokoukset helpottuivat paljon. Kutsun sitä kokouksen ankkuroimiseksi (grounding the meeting): yksinkertainen kaavio, joka näytettiin joka kerta, oli arvoltaan paljon tekemisen vaivaa suurempi.
Tavoite ei ole taiteellinen täydellisyys. Joskus kyse on yksityiskohtaisesta kaaviosta insinööreille, joskus viidestä laatikosta ja kuudesta nuolesta johtajalle. Tavoite on selkeys.
Selitä kompromissi
Osio nimeltä “Selitä kompromissi ”Hyvä arkkitehti esittää asian järjestyksessä: nämä vaihtoehdot harkitsimme, tämän kukin antaa meille, tämän kukin maksaa meille, tätä vaihtoehtoa suosittelen, ja tästä syystä.
Huomaa, että suositus tulee kompromissien jälkeen. En halua, että arkkitehtuurista tulee ”olen tehnyt tämän ennenkin, luota minuun”. Kokemus on valtavan tärkeää; se auttaa tunnistamaan malleja nopeammin ja näkemään ongelmat aiemmin. Mutta kokemuksesi pitäisi parantaa päättelyäsi, ei korvata sitä. Tehtävämme ei ole vain ymmärtää arkkitehtuuria. Se on auttaa organisaatiota ymmärtämään päätös, etenkin kun lopullisen ratkaisun tekijät eivät ole arkkitehteja.
Think Correct. Think Fast.
Osio nimeltä “Think Correct. Think Fast.”Sinulla ei aina ole kolmea viikkoa jokaisen vaihtoehdon analysointiin. Joskus sinulla on kolme minuuttia. Vaatimus muuttuu kokouksessa, joku mainitsee rajoitteen, josta et tiennyt, tai johtaja kysyy: ”Entä jos tarvitsemme tämän Euroopassa ensi vuonna?”
Olen käyttänyt ilmausta Think Correct. Think Fast. (ajattele oikein, ajattele nopeasti). Nopeus ei tule ajattelun ohittamisesta. Se tulee siitä, että olet ajatellut tarpeeksi ennen kuin hetki koittaa: olet oppinut mallit, tunnet alustan, olet nähnyt epäonnistumisia, tiedät, mitä kysyä ja mitkä päätökset on vaikea perua. Siksi käymme läpi skenaarioita koko kurssin ajan. Mitä enemmän päätöksiä analysoit, sitä nopeammin tunnistat seuraavan muodon.
Minulla oli asiakas, joka tarvitsi lomakkeiden täyttämistä. Lomakkeita oli kuitenkin paljon, ja kysymykset saattoivat muuttua ajan myötä. Tunnistin nopeasti tarpeen kyselyn tietomallille, mallille, johon palaamme myöhemmin kurssilla. Koska tunnistin mallin ja ratkaisun, pystyin tuomaan pöytään kattavamman tietomallin, joka hoiti myös tulevat vaatimukset eikä vain niitä, jotka olivat edessämme.
Arkkitehtuuri on tasapainoa
Osio nimeltä “Arkkitehtuuri on tasapainoa ”Kun syvennymme tietoarkkitehtuuriin, kohtaat valintoja, joissa vältän antamasta yksinkertaista sääntöä. Normalisoida vai litistää? Kopioida tiedot vai federoida ne? Synkroninen vai asynkroninen? Vakio-objekti vai mukautettu? Arkistoida vai pitää verkossa?
On periaatteita, malleja ja rajoja, ja joskus selvästi vääriä vastauksia. Mutta usein arkkitehdin tehtävä on löytää oikea tasapaino tälle järjestelmälle, tälle liiketoiminnalle ja tälle hetkelle.
Tiedä, miltä optimaalinen näyttää. Ymmärrä rajoitteet. Tunnista toteuttamiskelpoiset vaihtoehdot. Tee kompromissit näkyviksi. Tee sitten päätös.
Se ei ole päättämättömyyttä. Se on arkkitehtuuria.
Mitä arkkitehti tässä päättää
Osio nimeltä “Mitä arkkitehti tässä päättää ”- Mitkä vaihtoehdot ovat toteuttamiskelpoisia ja mitkä ovat vääriä nyt tai menevät huonoiksi vuodessa.
- Mitä kukin toteuttamiskelpoinen vaihtoehto antaa ja mistä se luopuu, mitattuna vaatimuksia vasten, jotka kestävät kysymyksiä.
- Mitkä rajoitteet ovat todellisia ja mitkä vain mieltymyksiä.
- Mitä vaihtoehtoa suositella, kun kompromissit on esitetty, ja miten se perustellaan.