Sarjan ensimmäisessä osassa Vladislav Ivanov käsitteli yleisesti uusien tekoälyteknologioiden, erityisesti kielimallien, vaikutusta arkkitehtuurityön käytäntöihin. Tässä toisessa osassa tiivistän, miten arkkitehtuurityössä voidaan tänään käyttää kielimalliteknologiaa: mikä toimii ja mikä ei (ainakaan vielä). Ovatko tekoälyagentit jo korvanneet kokonaisarkkitehdit? Onko hype ollut täysin katteetonta? Vai onko totuus jotain tältä väliltä, pientä arkista tehostamista?
Kielimalleja on nyt maailmalla kokeiltu eri tarkoituksiin muutamia vuosia. Jo jonkin aikaa kokeiluilta on odotettu tuloksia ja jonkin verran niitä on saatukin. On houkuttelevaa ajatella, että arkkitehtuurityö voitaisiin ulkoistaa tekoälylle: jos kerran kielimallit pystyvät tuottamaan tekstiä, mikseivät ne pystyisi tuottamaan myös arkkitehtuurikuvauksia?
Ja pystyväthän ne, se on kokeiltu. Uusimmat pilvi-LLM:t (käytän tätä termiä puhuessani sellaisista kielimalleihin perustuvista generatiivisista palveluista kuin Anthropicin Claude ja OpenAI:n ChatGPT) pystyvät huolellisesti ohjastettuina tuottamaan melko laajankin kuvauksen jonkun organisaation toiminnan, tietojen ja tietojärjestelmien muodostamasta kokonaisuudesta. Kuvaus on myös suoraan ladattavissa koneluettavassa muodossa mallinnustyökaluun käytettäväksi ja jatkotyöstettäväksi. Erityisen hyvin tämä toimii organisaatioille, joista on paljon tietoa avoimessa Internetissä.
Generoitu arkkitehtuuri vaatii aina validointia
Arkkitehdeille ei kuitenkaan ihan vielä voi antaa potkuja. Kuvausten tekeminen on vain yksi osa arkkitehdin toimenkuvasta. On hienoa, että kuvauksia voidaan generoida, mutta niillä pitää tehdäkin jotain. Niitä pitää käyttää kehittämistyössä nyky- tai tavoitetilan aineistona. Tätä varten on hyvä varmistaa, että ne vastaavat tosiasioita. Oletetaan, että kielimalli pullauttaa meille kuvauksen, jonka mukaan:
- meillä on 189 prosessia
- meillä on 79 tietojärjestelmää
- tietojärjestelmiemme välillä on 395 integraatiota ja
- toimintaamme ohjaa 63 kansallisen tai EU-tasoisen säännöksen kokonaisuus.
Miten lähtisimme varmistamaan, että kuvaus on totta, eli että kukin näistä asioista on oikeasti olemassa? Voimme katsoa Intranetistä, mutta saatamme huomata, että sieltäkään ei saa lopullista varmuutta. Se Pertin vuonna 2019 tekemä Intranet-sivu näyttäisi kyllä vahvistavan osan tiedoista, mutta osa tiedoista näyttää vanhentuneen. Harmillisesti Perttikin jäi pari vuotta tuon jälkeen eläkkeelle. Ja hetkinen, missä muuten teknologiat ovatkaan, löysikö tekoäly edes niitä mistään? Ainakin Liisan vuonna 2023 tekemässä PowerPointissa puhutaan pilvitransformaatiosta, mutta toteutuikohan Liisan kuvaama tavoitetila sellaisenaan? Pitäisiköhän tilanteen selventämiseksi kutsua palaveri ja alkaa koota uutta PowerPointia?
Ihmisarkkitehdin vahvuus on vuorovaikutuksessa
Kielimallilta voi yrittää kysyä lisää, mutta ne alkavat nopeasti kiertää kehää. Niitä voi yrittää ohjastaa ”yrittämään kovempaa”, mutta usein tilanne on se, että generoinnin pohjaksi ei ole tarjolla riittävästi ajantasaista, kattavaa ja laadukasta aineistoa.
Ihmiset usein tietävät asioita, mutta eivät ole kirjanneet tietojaan minnekään. Se, mitä jo löytyy kirjattuna, saadaan usein hämmentävänkin nopeasti tiivistettyä ihan siistiksi kokonaisuudeksi, mutta eväät on nopeasti syöty. Vastaavia pyrähdyksiä ei ole yhtä helppo tehdä, kun esimerkiksi kehittämisen tavoitteista täytyy alkaa sopia eri osapuolten välillä, tai kun organisaatiossa on kielimuureja. Kärsivällinen ja ymmärtäväinen ihmisarkkitehti voi saada aikaan asioita, joihin kielimallin on vaikea päästä. Kuten ennenkin, on jatkossakin hyötyä siitä, että ihmisten kanssa keskustellaan, heiltä saatuja tietoja kerätään yhteen ja jäsennetään kokonaisuuksiksi.
Lisäksi tullaan nopeasti myös kysymyksiin siitä, luotetaanko pilvi-LLM-palveluntarjoajaan niin paljon, että sille halutaan antaa kaikki arkkitehtuurin kannalta relevantti tieto johtoryhmän kokousten pöytäkirjoista sopimusrekisterin ja CMDB:n sisältöön asti. Riskejä voidaan yrittää hallita sopimuksilla, mutta on syytä varautua siihen, että tietovirtojen hallinta osoittautuu varsin monimutkaiseksi.
Paikalliset kielimallit tuovat kontrollia
Kokeilunhaluinen arkkitehti voi myös asentaa omalle työasemalleen (tai organisaation konesaliin tai riittävän turvalliseksi arvioituun pilvipalveluun) paikallisen kielimallin ja vibekoodata sen kylkeen agentin, jolla on pääsy haluttuun dataan. Näin saadaan enemmän kontrollia siihen, mihin organisaation data liikkuu ja mitä sillä tehdään.
Haasteena tässä on, että paikalliset kielimallit eivät ainakaan vielä ole samalla tasolla kuin pilvi-LLM:t.
Tekoälystä eniten hyötyä arjen työn tehostajana
Käytettiin pilvi-LLM-palvelua tai paikallisesti asennettua kielimallia, haasteeksi jää joka tapauksessa tiedon käsittely. Vaikka kielimallit osaavatkin tuottaa arkkitehtuurikuvauksia, ilman ohjausta niillä on vaikeuksia käsitellä kuvauksia organisaation rakenteista.
Pilvi-LLM-palveluilla voidaan tehdä muutakin kuin kaavioita. Voidaan tehdä myös skriptejä, joita ajamalla mallinnustyökalujen ominaisuuspalettia voidaan laajentaa. Arkkitehti voi siis vibekoodata työkaluunsa uusia ominaisuuksia.
Arkkitehtien skriptit ovat tyypillisesti kompakteja kokonaisuuksia, joiden hallintaan vibettäminen voi hyvinkin riittää. Esimerkiksi laatikoiden asetteluun olen itse saanut paljon apua tekemistäni skripteistä; se ei ole vielä disruptiivinen game changer, mutta auttaa merkittävästi päivittäisessä työssä.
Milloin tekoälystä saadaan suurin hyöty?
Mallinnustyökalujen kehittäjät ovat ymmärrettävästi myös liikkeellä. Isoista läpimurroista ei vielä tätä kirjoittaessani ole tietoa, mutta luultavasti ennemmin tai myöhemmin johonkin mallinnustyökaluun tulee ominaisuuksia, jotka auttavat arkkitehtuurityössä merkittävästi. Ja luultavasti ne kopioidaan nopeahkolla aikataululla muihin arkkitehtuurityökaluihin.
Koska arkkitehtuurityössä aikajänteet ovat pitkiä, ei yleensä tarvita uusimpia ominaisuuksia: en siis itse neuvoisi ostamaan kallista tekoäly-arkkitehtuurityökalua, vaikka toimittaja sen varmasti mielellään myisi.
Tilanne on siis sanalla sanoen mielenkiintoinen. Tekoäly vaikuttaa arkkitehtuurityöhön jo tänään, mutta varauksin. Kielimalleihin perustuvat palvelut eivät vielä ole varsinaisia työkaluja siinä merkityksessä, että niitä voisi vain vakioidusti käyttää ja että ne tuottaisivat systemaattisesti odotettuja lopputuloksia. Parhaimmillaan ne ovat hapanjuurta, josta saa sopivissa olosuhteissa ihan maistuvia lopputuotteita.
Mitä ovat sopivat olosuhteet? Ehkä jotain tällaista:
- Paljon ja hyvää, yksiselitteistä, mahdollisimman ajantasaista ja ristiriidatonta tietoa organisaatiosta ja erityisesti sen rakenteista. Ilman tätä tietoa kielimalli vetää yhteen nykyiset ja vanhentuneet käsitykset, oikeat tiedot ja pelkät luulot.
- Selvä ”liukuhihna”, jossa on määritelty käytettävät teknologiat ja niihin liittyvät rajoitteet sekä käytettävät tiedot ja niiden käsittelyyn liittyvät rajoitteet. Jos tämä puuttuu, päädymme helposti jarruttelemaan liikaa tai jaamme organisaatiostamme sellaisiakin tietoja, joita emme ole halunneet jakaa.
Arkkitehdin rooli muuttuu, ei katoa
Uusista teknologioista toivotaan usein ihmelääkkeitä. Niin myös kielimalleista. Harva teknologia on kyennyt lunastamaan kaikkia lupauksiaan, mutta tulevaisuuden ennustaminen on tällä hetkellä tavanomaistakin vaikeampaa.
Joka tapauksessa ne organisaatiot, jotka ovat tehneet kotiläksynsä ja onnistuneet pitämään palveluksessaan osaavia arkkitehteja, saavat erilaisista teknologioista uusia mahdollisuuksia. Ne, jotka ovat vasta alkuvaiheessa arkkitehtuurin kanssa, voivat saada näistä teknologioista vauhtia alkutaipaleelle.
Goforen arkkitehtuuriasiantuntijat auttavat rakentamaan kestävää kokonaisarkkitehtuuria, hyödyntämään tekoälyn mahdollisuuksia turvallisesti sekä luomaan pohjan pitkäjänteiselle kehittämiselle.
