Autor: Marek Mühlberg • 24. mai 2018
Tähelepanu! Artikkel on enam kui 5 aastat vana ning kuulub väljaande digitaalsesse arhiivi. Väljaanne ei uuenda ega kaasajasta arhiveeritud sisu, mistõttu võib olla vajalik kaasaegsete allikatega tutvumine.

Organisatsioonide muutmine tarkvara-jurakaid ei kannata

Siseministeeriumi infotehnoloogia- ja arenduskeskuse (SMIT) tehnoloogiaarhitekt Kristo Vaher.
Foto: Erakogu
Kui agiilne arendus annab raamistiku võimalikult efektiivsele ja pidevale äriväärtuse tootmisele võimalikult väikeste riskidega, siis domeenist juhinduv disain annab võimekuse ehitada sillad ärivajaduste ja arendatavate tarkvarakomponentide vahele. Täna on see üks parimaid viise jõudmaks hea ja kestliku arhitektuurilise lahenduseni, mis vastab organisatsioonide muutustele, tõdeb siseministeeriumi infotehnoloogia- ja arenduskeskuse (SMIT) tehnoloogiaarhitekt Kristo Vaher.

12. juunil Äripäeva ITuudiste korraldataval parimate praktikate seminaril „Kuidas edukalt rakendada tulevikutehnoloogiaid ja nutikalt juhtida strateegilisi IT projekte?

Vaata lähemalt ja registreeru SIIN!

Mis on täna suurimad väljakutsed tarkvaraarenduses?

Öeldakse, et tarkvaraarenduses eksisteerib püramiid, millel on kolm tippu: kiiresti, odavalt ja hästi - ning sa ei saa kunagi valida kõiki kolme korraga. Huvitav on see, et meil eksisteerib sarnane probleem tarkvaraarenduses üldisemalt: kiire arendus pole võimalik, sest IT-tööjõudu on turul liiga vähe ja odavalt pole võimalik, sest IT-tööjõu palgad on nõudluse tõttu krõbedad. Ainus, mis alles jääb on 'hästi' ning parem oleks, et nii kitsas olukorras me siis sellele selga ei keeraks.

Kuna rahakott on lõppkasutajal, siis sellises piiratud ressurssidega konkurentsirohkel maastikul on kriitiliselt tähtsal kohal see, et me mõistaks kasutajat ja tema vajadusi ning oskaks neid kaardistada nii, et sellel oleks seos arendatava tarkvara ja selle arhitektuuriga. Viimastel aastatel on selliste murede lahenduseks pakutud pea eksklusiivselt äri poolel agiilset arendust ja tehnoloogia poolel detsentraliseeritud arhitektuuri, aga ma leian, et puudu on jäänud sellest liimist, mis aitaks neil kahel koos püsida ning selle puudus on minu arvates põhjus, miks mõlemad lahendused on ka kriitikat saanud.

Mida tähendab domeenist juhinduv disain ja millistel organisatsioonidel seda kõige rohkem vaja on?

Kui agiilne arendus annab raamistiku võimalikult efektiivsele ja pidevale äriväärtuse tootmisele võimalikult väikeste riskidega, siis domeenist juhinduv disain annab võimekuse ehitada sillad ärivajaduste ja arendatavate tarkvarakomponentide vahele. Sõna 'domeen' tähendab antud mõistes mingit kindlat ärilist funktsiooni omavate teadmiste või tegevuste kogumit - mida mina isiklikult inimkeeli nimetaks lihtsalt rolliks või ametiks, mida tarkvara automatiseerib.

Ma leian, et pole organisatsiooni, kellel ei oleks kasu domeenist juhinduvast disainist, et seeläbi planeerida ja arendada ise või tellida korduvkasutatavaid tarkvaralahendusi. Esmajärjekorras soovitaksin sellesse sukelduda igal ettevõttel, kes on tajunud vajadust tükeldatud ja väiksemate sõltuvustega tarkvaralahenduste järele või kellel on täna sellega raskuseid olnud. Ma ei leia, et täna leiduks paremat meetodit hea arhitektuurini jõudmiseks.

Miks peaks sellele teemale tähelepanu pöörama ja mis võib juhtuda kui teemat ignoreerida?

Tarkvara arendaja Melvin Conway defineeris aastal 1967 'seaduse', et iga organisatsioon, millele anda ülesanne disainida omaenda süsteem lõpetab kohas, kus selle süsteemi ülesehitus on üks-ühele sarnane organisatsiooni kommunikatsioonistruktuuriga ja iga erinevus selles tekitab hõõrdumist. Ning olgugi, et see on öeldud viiskümmend aastat tagasi, siis kehtib see seadus tänaseni. See on näiteks põhjus, miks mitmed tarkvarad muutuvad ebamugavaks ja raskesti kasutatavaks - maailm pidevalt muutub ja tehnoloogia enam ei klapi seda kasutava organisatsiooniga. Kui tarkvara arenduses seda paratamatust arvesse ei võeta, siis võib öelda, et mis iganes uhiuue programmeerimiskeele ja pilvelahenduse peale ehitatud tarkvara oleks juba paari aasta pärast vaja ümber ehitada ja välja vahetada täies mahus, et organisatsioon ei kannataks.

Mida on domeenist juhinduva disaini rakendajatel võita ja kui palju kokku hoida?

Domeenist juhinduva disaini põhimõtted annavad võimekuse disainida lõpplahendused - protsessidest tehnoloogiateni - kujul, mis on paindlikumad ja sobituvad sellega, kuidas muutuvad ajas organisatsioonid ja nende tooted ning teenused. Kuna organisatsioonide ja toodete muutus vastavalt turule on elukriitiline ellujäämiseks, siis on tähtis, et tehnoloogia arhitektuur saaks ehitatud kujul, mis seda toetab. Seda eriti ajastul, kus tehnoloogiamaastik ja võimalused on rikkalikumad, kui kunagi varem ja tihti on kiusatus kõike uut proovida.

Näiteks üks suurimaid ootamatuseid, mis on juhtunud API-kesksete mikroteenuste arhitektuuri ehitamisega on see, et probleem on enamasti jäetud ainult inseneridele lahendada. Insenerid on tihti kõige helgemad pead terves majas, aga kui nende arenduses pole lähedast seost arendatava ärilise funktsiooniga nii, et nad seda terviklikult mõistaksid, siis ei saa olema ka arendatav tarkvara selline. Domeenist juhinduv disain aga välistab olukorra, kus arendusmeeskonnas oleks keegi, kes ei tunne 'toodet' põhjalikult ja pika elutsükliga tarkvara puhul on see hindamatu väärtus.

Kas avalikus sektoris saab üldse agiilset arendust teha ja millised on rakendamise eripärad võrrelduna erasektoriga?

Avalikus sektoris saab kindlasti teha agiilset arendust ning ma ei kahtle, et sama hästi, kui erasektoris, aga tänane suurim takistus selle eduks on minu arvates see, et kui erasektoris on lõppkasutaja rahakotil üks-ühele seos ettevõtte edukusega, siis avalikus sektoris - kus maksumaksja on samuti ju raha allikas - ei maksa lõppkasutaja teadlikult toote eest ja on sellest samm kaugemal.

See tähendab, et kui erasektoris on ülimalt tähtis see, et kaevata juurteni lõppkasutaja eluliste probleemide lahendamiseks, et ikka valitaks nende telefon või nende takso-app või nende kino, siis avalikus sektoris on puudu sellesarnane konkurents ning arenduses on suurimad mõjutajad rahastamise saanud projektide juhid ja asutused. Sellises mudelis paratamatult võivad minna udusemaks lõppkasutaja vajadused ja mugavus, kui neid just teadlikult ja pidevalt ei kaasata või see poliitilist tähelepanu ei saa. Nii agiilsus, kui ka domeenist juhinduv disain aga eeldavad, et lõppkasutaja vajadused ja nende mõistmine on üle kõige esimesel kohal.

Kui me seda teadlikult väärtustame, on palju häid asju võimalikud. Kuna Eesti on maailma mastaabis hästi väike riik, siis parim meetod, kuidas me saame kõrgemale ja kaugemale jõuda kasutades lõpmatult laiendatavat tehnoloogiat on selle abil kõige efektiivsem rutiini automatiseerimine - läbi agiilse arenduse ja domeenist juhinduva disaini - et eestlane saaks päeva lõpuks tegeleda päris probleemidega, mis vajavad kastist väljas mõtlemist, loomingut ja uudseid lähenemisi, kus tehnoloogia veel ei aita.

Siseministeeriumi infotehnoloogia- ja arenduskeskuse (SMIT) tehnoloogiaarhitekt Kristo Vaher (varasemalt BIGBANK-i tarkvaraarhitektuuri juht, BIGBANK-i tarkvaraarenduse tiimijuht, Mailbow vanemarendaja) esineb 12. juunil Äripäeva ITuudiste korraldataval parimate praktikate seminaril „Kuidas edukalt rakendada tulevikutehnoloogiaid ja nutikalt juhtida strateegilisi IT projekte?“ Registreeru sündmusele siin: http://www.ituudised.ee/ITprojektid

Liitu ITuudiste uudiskirjaga!
Liitumisega nõustud, et Äripäev AS kasutab sinu e-posti aadressi sulle uudiskirja saatmiseks. Saad nõusoleku tagasi võtta uudiskirjas oleva lingi kaudu. Loe oma õiguste kohta lähemalt privaatsustingimustest
Indrek KaldITuudised.ee toimetajaTel: 511 1112
Anne WellsReklaami projektijuhtTel: 5880 7755