Valmis sovellus jopa 80 % nopeammin SC Softwaren sovelluskehitysalustalla low-codea ja perinteisiä menetelmiä yhdistäen 

Digitalisaatiosta odotetaan ratkaisua liiketoiminnan tiukentuviin tuottavuusodotuksiin kaikilla toimialoilla. Liiketoiminnan järjestelmiltä odotetaan korkeaa suorituskykyä, tietoturvaa ja käytettävyyttä sekä joustavaa kehitysprojektia ja käyttöönottoa, mutta maltillisella kustannuksella.

Ohjelmistopalvelujen kova kysyntä sekä IT-alan kiihtyvä kilpailu ovat saaneet softatalot etsimään tehokkaampia ratkaisuja ohjelmistokehitykseen; on kehitetty parempia ohjelmointikieliä, -ympäristöjä, menetelmiä ja työkaluja, teetetty työtä ulkomailla sekä rekrytoitu lisää seniorikehittäjiä.

Vaikka kehitystä tapahtuu jatkuvasti, monien IT:n ostajien kokemukset ovat silti tyypillisiä: valmiit SaaS-tuotteet eivät vastaa omia tarpeita, ja perinteisen ohjelmistokehitysprojektien hinta ja aikataulu venyvät jatkuvasti alkuperäisistä arvioista. Näkyvyys kehitystyöhön on olematonta, mikä voi johtaa kalliisiin muutoksiin ohjelmiston käyttöönoton jälkeen. Lisäksi ohjelmiston lopputuloksen laatu on usein pettymys tilaajalle.

Koodittomuus nousussa – ratkaiseeko se softakehityksen ongelmat?

Yksi yleistyvä ohjelmitotuotannon kehityssuunta Rapid Application Development (RAD) -lähestymistapaan kuuluvat koodittomat (no-code) tai vähäkoodiset (low-code) sovelluskehitysalustat. Niiden avulla ohjelmistoja rakennetaan visuaalisilla elementeillä koodin kirjoittamisen sijaan. Koodittomat metodit kehittyvät ja kypsyvät kovaa vauhtia; vielä muutama vuosi sitten mm. Gartner puhui High Productivity Application Platform -palveluista (hpaPaas), mutta on sittemmin 2023 Gartner Magic Quadrant for Enterprise Low-Code Application Platforms -raportissaan päivittänyt termejään, puhuen nyt ”Enterprise Low-Code” -alustoista.

Low-code/no-code-alustoilla pyritään nopeaan räätälisovellusten kehittämiseen ja käyttöönottoon korottamalla sovelluskehityksen abstaktiotasoa ja minimoimalla ohjelmointityön määrää. Alustoilla on myös pyritty parantamaan lopputuotteen osuvuutta antamalla käyttäjien rakentaa sovelluksensa itse, ilman ohjelmistotalon väliintuloa.

Siinä missä täysin koodittomat alustat ovat usein suunnattu koodaustaidottomille kansalaiskehittäjille, enemmän teknistä osaamista vaativat low-code-työkalut ovat yleensä ammattilaiskäyttöön tarkoitettuja. Näillä enterprise low-code-alustoilla generoidaan sovelluskoodia esimerkiksi toimialakohtaiseen tietomalliin (domain-specific modeling, DSM) perustuen, ja generoidun sovelluksen kehitystä voidaan jatkaa manuaalisesti koodaten. Tarkoituksena on siis lisätä ammattilaiskehittäjän tuottavuutta, antaen samalla vapauksia sovellusten laajempaan räätälöintiin.

No-code/low-code-alustat ovat saaneet myös kritiikkiä. Etenkin no-code-alustoilla koodin manuaalinen editointi on usein hyvin rajoitettua, jolloin ne soveltuvat lähinnä yksinkertaisten täsmäsovellusten tekoon. Alustojen tarjoamat sapluunat kattavat yleisimmät bisnesprosessit, mutta monipuolisempia työnkulkuihin, integraatioihin tai analytiikkaan ne eivät taivu. Monesti äärimmäistä nopeutta ja helppouta lupaavat alustat vaativat myös enemmän teknistä osaamista, kuin niiden markkinoinnissa annetaan ymmärtää.

Low-code ja no-code-alustat poistavat siis monia perinteisen sovelluskehityksen ongelmia tekemällä kehityksestä intuitiivisempaa, tuomalla substanssiosaajat sovellusten rakentajiksi ja vähentämällä ohjelmoinnin määrää. Alustojen puutteellisuuksista johtuen on kuitenkin edelleen yleistä toteuttaa vaativammat liiketoiminnan järjestelmät yhdessä asiantuntevan ohjelmistotoimittajan kanssa. Toimittaja voi kuitenkin hyödyntää enterprise low-code-alustoja onnistuneesti omassa toiminnassaan, tuoden sen hyödyt myös asiakkaan saataville.

Automatisointi ja manuaalinen koodaus yhdistyvät sulavasti SC Softwaren sovellustuotannossa

Sekä perinteisissä, että lähes huippuunsa asti automatisoiduissa sovelluskehityksen menetelmissä on omat hyvät ja huonot puolensa. Olemmekin SC Softwarella lähestyneet ongelmaa valitsemalla molempien tapojen parhaat puolet ja kehittämällä niiden ympärille oman SoulGen-ohjelmistotuotantoalustamme. Kun asiakas haluaa tietynlaisen järjestelmän, mallinnamme sen sisältämät käsitteet sovellusmalliksi, jonka pohjalta generoimme toimivan perussovelluksen. Mallinnuksessa hyödynnämme määrittelemäämme toimialakohtaista kieltä (domain-specifin language, DSL), johon olemme valikoineet yleisiä, kaikissa järjestelmätoimituksissamme toistuvia sovelluksen rakenteita ja toiminnallisuuksia. Jatkamme tästä sovelluksen kehittämistä manuaalisesti asiakkaan tarpeiden mukaisesti. Liian pitkälle automatisointi vie lopputulosta usein vain kauemmas asiakkaan tarpeesta.

SoulGen-alustamme on verrattavissa enterprise low-code-alustoihin, mutta käyttölisenssien myymisen sijaan käytämme sitä oman tuottavuutemme nostamiseen ohjelmistoja rakennettaessa. Tällä tavoin standardoimme ja nopeutamme ohjelmistotoimituksiamme, mikä näkyy asiakkaillemme lopputuloksen laadukkuutena sekä aikataulun ja budjetin pitävyytenä. Samalla pystymme toimimaan täyden palvelun kehityskumppanina, joka pitää huolta järjestelmien tietoturvasta, toimivuudesta, ylläpidosta, ajoalustoista ja muista teknisistä asioista, joihin asiakkaat eivät yleensä halua käyttää aikaansa.

Tietomallista generoidaan toimiva sovellus, jonka kehittämistä jatketaan käsin koodaamalla 

Teknologiaamme on helppo ajatella vain uusien räätälisovellusten tuottamisen kautta, mutta käytännössä se istuu hyvin myös legacy-järjestelmien uudistamiseen (katso esimerkiksi Teollisuusliitolle toimittamamme hanke), laajojen tehtäväkriittisten järjestelmäkokonaisuuksien toteuttamiseen, olemassa olevien järjestelmien laajentamiseen tai tuoteinnovaatioiden nopeaan kehitykseen ja markkinoille vientiin. Näin pystymme ketterään toimintamalliin, jossa kaikki edellä mainitut palvelut ovat osa tarjoamaamme. 

Alusta taklaa organisaatioiden muuttuvia digitarpeita – nyt ja tulevaisuudessa 

Laura Fadjukoffin SC Softwaren kanssa yhteistyössä tekemässä diplomityössä verrattiin toimialakohtaisen mallinnuksen ja perinteisen ohjelmointityön tehokkuutta sovelluskehityksessä. Case-tutkimuksen lopputuloksena todettiin, että sovelluksen tuottaminen mallista generoimalla vei jopa 80 % vähemmän kokonaisaikaa verrattuna samanlaisen sovelluksen käsin ohjelmointiin. Tutkimuksen mukaan työaikaa säästyi erityisesti tietokannan luomisessa, sovelluslogiikan ohjelmoinnissa ja käyttöliittymän muokkauksessa. Vaikka tutkimus oli vain yksi case-esimerkki, jota ei sellaisenaan voi yleistää jokaiseen projektiin, sen tulokset antavat kuitenkin jonkinlaista osviittaa teknologiamme tuottamasta ajansäästöstä. 

Oma filosofiamme ei kuitenkaan perustu äärimmäiseen nopeuden tavoitteluun, vaan asiakkaan tarpeiden täyttämiseen annetuissa raameissa. Teknologiamme mahdollistaa sen, että projektibudjetista suurempi osa voidaan käyttää ns. korkeamman lisäarvon työhön rutiinikoodaamisen sijaan, tarkoittaen esimerkiksi prosessien ja käytettävyyden hiomista, laajempaa päätelaitetukea tai parempia raportointivälineitä.  Ajansäästön lisäksi olemme havainneet muitakin kehitysalustamme tuomia etuja:

  • Pystymme tarkempaan arvioon projektiin käytetystä ajasta ja resursseista, jolloin antamamme budjetti- ja aikatauluarvio on kohdillaan lähes kaikissa toimituksissamme. 
  • Asiakas ymmärtää sovelluskokonaisuutta paremmin nähdessään visuaalisen mallinnuksen ja siitä generoidun sovelluksen. Määrittelyjä päästään tarkentamaan jo aikaisessa vaiheessa, jolloin tulevaisuuden korjaustarpeet vähenevät. 
  • Koodi on aina yhdenmukaista ja laadukasta, sillä sitä on testattu kaikissa toimitusprojekteissamme. Lisäksi alustaa kehitetään jatkuvasti eteenpäin. 
  • Jatkokehitämme järjestelmiä samalla teknologialla, ja muutostyöt ovat nopeita toteuttaa mallia editoimalla.  
  • Generoitu sovellus on tavallinen monikerrosarkkitehtuuria noudattava järjestelmä, jota voi kehittää eteenpäin perinteisinkin menetelmin. Näin asiakas välttyy vendor lock-in tilanteelta. 

SoulGen-alustamme tarjoaa myös monia tulevaisuuden mahdollisuuksia. Organisaatioiden toiminta vaatii yhä enemmän tietoon perustuvaa johtamista, ja siksi toiminnasta kerääntyvää dataa on oltava mahdollista yhdistellä, analysoida, jakaa, rikastaa ja puhdistaa monipuolisesti. Olemmekin tunnistaneet teknologiamme kyvykkyyksiä muun muassa valmiiden API-rajapintojen, räätälöityjen masterdatan hallintaratkaisujen sekä erilaisten BI-tietovarastojen ja niiden käyttöliittymien toteuttamiseen kehitysalustaamme hyödyntäen. Näin teknologiamme tukee liiketoiminnan ydinprosessien digitalisoinnin lisäksi ydindatan hyödyntämistä eri käyttötarkoituksiin – yli järjestelmärajojen. 

Asiakkaan tyytyväisyys ratkaisevaa

Kaikissa sovelluskehityksen tavoissa on omat hyvät ja huonot puolensa. SoulGen-teknologialla pyrimme vähentämään perinteisten sekä koodittomien menetelmien pullonkauloja, mutta minkä tahansa sovelluksen toteuttamiseen sekään ei sovellu. Osaavat ohjelmistokehittäjät ovat edelleen keskeinen voimavara järjestelmiemme toteuttamiseen sekä oman teknologiamme kehittämiseen. Lukuisat onnistuneet toimitukset ja asiakkailtamme saamamme palaute rohkaisee meitä eteenpäin tällä tiellä. Teknologia on meille työväline ja asiakkaidemme tyytyväisyys on se tärkein onnistumisen mittari. 

Katso webinaaritallenne: Mallipohjainen sovelluskehitys – huomispäivän softatyötä jo tänään

Huomispäivän softatyötä jo tänään – webinaaritallenne katsottavissa

SC Softwaren korkean tuottavuuden sovelluskehitys on herättänyt kiinnostusta niin asiakkaiden, työnhakijoiden kuin mediankin suunnalta. Siksi päätimmekin järjestää kaikille avoimen webinaarin ja toivottaa tervetulleeksi kaikki huomispäivän softatyöstä kiinnostuneet.

Webinaarissa kuulet mm. miten mallipohjaisuus vastaa ohjelmistokehitystyön haasteisiin ja näet, millaista käytännön työskentely on kyseisellä toimintamallilla. Webinaaria isännöi vanhempi konsulttimme Risto Pohjonen.

Webinaari järjestettiin ke 25.9.2019 kello 16.

Katso tallenne tästä linkistä

Automaatiolla kohti ohjelmistoteollisuutta – lue Tivin artikkeli!

Tivi on julkaissut artikkelin SC Softwaren (ent. SoulCore) mallipohjaisesta ohjelmistokehittämisestä. Automatisoidun ohjelmistotuotannon avulla pyrimme tarjoamaan asiakkaillemme perinteistä järjestelmätoimitusta moninkertaisesti tehokkaammat toimitusprojektit sekä helpottamaan ohjelmistokehittäjiemme työtä. Lue 9/2019 ilmestynyt artikkeli alta!

Sivu-36-38-_-09_2019-_-Tivi-2

Lisää aiheesta voit käydä kuuntelemassa Youtubessa webinaaritallenteestamme Mallipohjainen sovelluskehitys – huomispäivän softatyötä jo tänään.

Saavutettavuus osaksi ohjelmistotuotannon elinkaarta

Euroopan Unionin saavutettavuusdirektiivillä pyritään edistämään ihmisten yhdenvertaisuutta ja tasa-arvoa digitaalisessa yhteiskunnassa. Julkisten ja julkisrahoitteisten verkko-, asiointi-, ja mobiilipalveluiden tulee pian olla kaikille saavutettavia käyttäjien mahdollisista toimintarajoitteista riippumatta. Viimeistään nyt on siis hyvä aika järjestelmätoimittajankin tutustua saavutettavuuden periaatteisiin ja saavutettavien digipalvelujen kehittämiseen.

Mitä järjestelmätoimittajan tulee tietää saavutettavuudesta?

Saavutettavuuden periaatteena ovat havaittavuus, hallittavuus, ymmärrettävyys ja toimintavarmuus. Digipalvelu on saavutettava, kun sen käyttöä eivät estä tai rajoita käyttäjien mahdolliset toimintarajoitteet, kuten näkö-, kuulo-, fyysiset tai kognitiiviset vammat tai kielelliset esteet. Yli 1,2 miljoonaa ihmistä Suomessa tarvitsee saavutettavuutta, sekä 20-25 % suomalaisista hyötyisi selkokielisyydestä.

Saavutettavuus ei kuitenkaan ole pelkästään toimintarajoitteisten asia – helppokäyttöisyydestä ja selkeydestä hyötyvät kaikki digipalvelujen ja -tuotteiden käyttäjät. Näin ollen saavutettavuuden huomiointi on eduksi kaikille digipalveluita kehittäville tai tarjoaville yrityksille.

”Saavutettavuudella luodaan kaikille parempi asiakaskokemus. Lisäksi digipalvelun asiakaskunta laajenee, kun suurempi osa potentiaalisista asiakkaista pystyy käyttämään sitä”, kertoo SC Softwaren Senior UX designer Pauliina Kähäri.

”Tukipyyntöjen määrä vähenee, kun palvelua on helppo käyttää itse, ja myös epäonnistuneiden käyttötapausten määrä pienenee. Lisäksi esimerkiksi saavutettavan verkkosivun näkyvyys hakutuloksissa paranee, sillä hakukoneet suosivat samoja sisällöllisiä ominaisuuksia, kuten selkeää dokumentin rakennetta, mitä ruudunlukuohjelmatkin vaativat”, Kähäri listaa.

Saavutettavuusdirektiivi ei kuitenkaan ole ensimmäinen yhdenvertaisuuteen ja saavutettavuuteen kantaaottava asetus. Jo perustus- ja yhdenvertaisuuslaki velvoittavat ihmisten yhdenvertaiseen kohteluun esimerkiksi ikään tai vammaan katsomatta. Hallintolaki määrää viranomaisen käyttämään selkeää ja ymmärrettävää kieltä, kun taas julkisia hankintoja koskeva hankintalaki edellyttää ottamaan huomioon mm. kaikkien käyttäjien vaatimukset täyttävän suunnittelun.

Sekä julkisia että yksityisiä palveluntarjoajia koskeva, kehitteillä oleva EU:n esteettömyysdirektiivi puolestaan asettaa esteettömyysvaatimukset erilaisille fyysisille laitteille ja automaateille, mutta myös esimerkiksi käyttöjärjestelmille ja verkkokaupoille. Lain nojalla siis muidenkin kuin julkisten digipalvelujen tulisi pyrkiä saavutettavuuteen.

Järjestelmätoimittajan työkalut saavutettavuuden toteuttamiseksi

Miten siis järjestelmätoimittaja voi ottaa saavutettavuuden paremmin huomioon käytännön työssä?

”Meillä SC Softwarella Design For All -suunnitteluperiaatetta toteutetaan osallistamalla käyttäjiä järjestelmätoimitusprojektin jokaisessa vaiheessa aina määrittelystä kehitykseen ja testaukseen”, kertoo Kähäri. ”Saavutettavuus tulee ottaa huomioon jo ennen palvelun teknisen toteuttamisen aloittamista. Tähän avuksi voidaan käyttää esimerkiksi saavutettavuussuunnitelmaa”, Kähäri jatkaa.

Myös Softwaren korkean tuottavuuden kehitysalusta mahdollistaa teknisten saavutettavuusrakenteiden tuottamisen sovelluksiin automaattisesti. Näin ollen kakki kehittämämme sovellukset ovat lähtökohdiltaan teknisesti saavutettavia.

Saavutettavuus syntyy teknisten ratkaisujen ja sisällön kautta

Ohjelmistojen teknisen toteutuksen kriteeristönä toimivat WCAG 2.1 verkkosisällön saavutettavuusohjeet. ”Ohjelmistokehittäjät pystyvät arvioimaan teknistä saavutettavuutta koneellisesti esimerkiksi Chrome -selaimen kehittäjien työkalujen avulla. Automaattisilla työkaluilla voidaan kuitenkin arvioida vain murto-osa digipalvelun saavutettavuudesta.

Saavutettavuuteen vaikuttaa teknisen toteutuksen lisäksi sisällön ymmärrettävyys ja palvelun helppokäyttöisyys, joiden arviointi on mahdollista vain manuaalisesti:

”Vielä ei esimerkiksi pystytä koneellisesti tutkimaan, vastaako vaikkapa kuvan sisältö alt-tekstin kuvausta”, Kähäri kuvailee. ”Lisäksi sisällön saavutettavuudelle on vaikea määritellä mitattavia kriteerejä. Tällä hetkellä paras vaihtoehto saavutettavuuden arviointiin on koneellisen testauksen lisäksi asiantuntija-arvioinnit ja käytettävyystestaus. Käyttöliittymä- ja käytettävyyssuunnittelijoille on siis luvassa lisää töitä. Apuna olisi hyvä käyttää myös ulkopuolista saavutettavuusasiantuntijaa”, Kähäri jatkaa.

Saavutettavuutta voi arvioida testikäyttäjien avulla

Käyttäjien todelliset tarpeet pystytään arvioimaan kuitenkin vain erilaisista ja eritasoisista käyttäjistä koostuvan, kyseistä digipalvelua arjessaan käyttävän käyttäjäryhmän avulla.

”Saavutettavuuden toteutumisesta on vastuussa myös palveluntarjoaja, ei pelkästään järjestelmätoimittaja. Palveluntarjoajan olisi hyvä valita määrittely- ja testiryhmiin eri-ikäisiä ja -toimintarajoitteisia loppukäyttäjiä. Usein määrittelemässä ovat yrityksen esimiesvastuussa olevat henkilöt ja varsinaiset loppukäyttäjät ovat vähemmistönä”, mainitsee Kähäri.

”Järjestelmätoimittajan on osattava neuvoa asiakasta sopivan määrittely- ja testiryhmän valinnassa. Tärkeää on opastaa myös digipalvelun sisällöntuotannossa: saavutettavuusvaatimukset on huomioitava järjestelmän koko elinkaaren ajan sisältöä tuotettaessa” jatkaa Kähäri.

Järjestelmätoimittajalle oleellista on siis jalkauttaa saavutettavuutta tukeva toiminta koko yritykseen sekä kaikkiin ohjelmistokehityksen elinkaaren vaiheisiin. ”Saavutettavuus on kuitenkin ennen kaikkea arvovalinta – haluamme palvella kaikkia käyttäjiä ja olla tekemässä maailmasta yhdenvertaista kaikille”, Kähäri päättää.



mari niemelä

Mari Niemelä

Head of Business Unit, Trade Union Solutions & Custom ERP mari.niemela@scsoftware.fi +358 50 567 5491

Ota yhteyttä tai varaa esittely!

Matkakertomus #2: Malli, koodi, generaatio, automaatio..?

Viimeviikkojen aikana olen laittanut copywriterin lasit päähän ja kirjoitellut niin SC Softwaren palvelukuvausta, asiakastarinoita kuin uutisia uusista yhteistyösopimuksista. Sisällöntuotannon lisäksi olen ajautunut sivussa myös mm. testaushommiin ja saanut muutenkin pyöritellä eri sovellusten testiympäristöjä. Samalla olen päässyt aika hyvin jyvälle siitä, kuinka erilaisten ratkaisujen rakentamiseen mallipohjainen sovellustuotanto taipuu.

Osallistuin menneellä viikolla myös Jyväskylän Crazy Townilla järjestettyyn mallipohjaista sovellustuotantoa ja koodigeneraatiota käsitelleeseen tapahtumaan, jossa SC:n asiantuntijat olivat kertomassa teknologiastamme ja sen tuomista hyödyistä. Siinä kuunnellessa ja pitsaa mässyttäessä tuli mieleen, että onneksi en itse ole tuolla stagella, sen verran teknistä kysymystä pommitettiin enimmäkseen .NET.JKL -jäsenistä koostuvan yleisön joukosta.

Toisaalta juurikin korkean tuottavuuden sovellustuotanto ja erityisesti siitä saadut edut ovat se asia, mikä on toimintamme ytimessä ja tekee meistä erityislaatuisen järjestelmätoimittajan (ja on siten tärkeää oppimateriaalia tälle yhden naisen markkinointiosastolle). Olen kuitenkin moneen otteeseen joutunut miettimään, kiinnostaako asiakkaitamme oikeasti se, miten järjestelmä toteutetaan, kunhan lopputulos on hyvä ja tarpeita vastaava. Tämä on itselleni ehkä se suurin viestinnällinen dilemma.

”Automatisoitu sovellustuotanto for dummies”

Olen kuitenkin tullut siihen tulokseen, ettei automatisoidusta sovellustuotannosta tarvitse välttämättä ymmärtää mitään. Sen sijaan asiakkaan kannalta kiinnostavaa on tehokas ja nopea toimitus (johtuen yksinkertaisesti siitä, ettei kehittäjiemme tarvitse naputella riviäkään joka projektissa toistuvaa rutiinikoodia).

Tuotantoprosessimme on myös hyvin visuaalinen ja osallistava: mallista saadaan generoitua heti toimivia sovelluksen osia. Asiakkaamme pääsevät siis näkemään ja vaikuttamaan reaaliaikaisesti siihen, millaiseksi ohjelmisto rakentuu. ”Asiakas puhuu käyttöliittymää”, todettiin Crazy Townin tapahtumassakin: asiakkaan on helppo osallistua sovelluksen kehittämiseen, kun samalla näkee heti, minkälaisia kenttiä ym. toiminnallisuuksia sovellukseen voidaan lisätä. Sovellustuotannon automatisointi mahdollistaa juuri tämän.

Kyseistä sovellustuotannon prosessia on todella hauskaa seurata. Saamiemme asiakaskommenttienkin perusteella sovelluskehitysprojektimme ovat olleet hyvin innostavia, myös tietotekniikasta vähemmän ymmärtäville. ”Tämä teidän tekemisen tapa on aivan fantastinen” on loistava esimerkki näistä työpajoissa kuulluista, elämään jääneistä asiakaskommenteista. Tätä tekemisen tapaa on kuitenkin haastavaa tuoda kompaktisti esille, kuten SC Softwarella on aiemminkin huomattu. Mielestäni pulma vaatii visuaalisia ratkaisutoimenpiteitä.

Pääsovellusarkkitehtimme Jarno Leikas on kirjoittanut hyvän artikkelin automatisoidusta sovellustuotannosta ja sen eroista ja yhtäläisyyksistä perinteiseen sovellustuotantoon. Käykäähän lukemassa!

Janita Kingelin, markkinoinnin trainee

***

Lue matkakertomuksen muut osat:

Matkakertomus #1: Ensiaskeleet

Matkakertomus #3: Kokemuksiani SC Softwarella työskentelystä

Matkakertomus #4: Vuosi SC Softwarella – matka jatkuu

Tarina kehittäjästä, josta tuli yhdessä yössä kertaluokkaa tuottavampi

Jarno Leikas

CTO


Kun minua pyydettiin SoulCorelle (nyk. SC Software) pääarkkitehdiksi lokakuussa 2014, en meinannut pysyä tuolillani. Tiimi oli vanhastaan tuttu, ja olin ollut kiinnostunut sovellustuotannon automatisoinnista jo opiskeluajoistani lähtien. Olinkin siihen mennessä harmitellut, että automatisoitu sovellustuotanto oli aina ollut eräänlainen ”ikuinen lupaus”, joka ei koskaan oikein ollut realisoitunut. Nyt sain mahdollisuuden selvittää mihin asti ajatus lentää.

Ja lentäähän se. Pitkälle.

Mitä automatisoidulla sovellustuotannolla sitten tarkoitetaan?

Lyhyesti, automatisoimme sovelluskoodin tuotantoa, tavoitteenamme nostaa sovelluskehityksen tuottavuutta nykyisin käytössä olevia keinoja paremmalla tavalla.

Heti alkuun on tärkeää ymmärtää, että korkean tuottavuuden sovelluskehityksen lopputuloksena on aivan tavallinen järjestelmä. Siis sellainen, jonka olisi voinut koodata käsinkin (ei tosin läheskään samassa ajassa). Olennaisena erona on se, että meillä kerrosarkkitehtuurin eri kerrosten lähdekoodi syntyy automaattisesti sovellusmallin perusteella. Tästä saatava tehokkuuden lisäys on niin suuri, että sen kerrannaisvaikutukset koko projektin elinkaareen ovat jopa laadullisia, eivät pelkästään määrällisiä.

Korkean tuottavuuden kehityksessä ei siis ole ”mustana laatikkona” toimivaa monimutkaista ajoalustaa, tai toimialakohtaista valmislogiikkaa, jota pyritään parhaan mukaan taivuttamaan asiakastarpeisiin (eikä muuten näihin liittyviä lisenssimaksujakaan). Kuten tavanomaisessa web-pohjaisessa tietokantasovelluksessa, automaation avulla tuotettu sovellus tarvitsee ajoalustaksi tavanomaisen sovelluspalvelimen ja tietokantapalvelimen. Käyttäjät tarvitsevat päätteekseen esimerkiksi tabletin tai työpöytäselaimen. Mielestäni tämä on aika yksinkertainen juttu.

Myöskään generoidun sovelluksen integrointitarinassa ei ole magiaa: koska ratkaisu vastaa rakenteeltaan tavanomaista monikerrosarkkitehtuuria noudattavaa sovellusta, voidaan sitä vasten toteuttaa juuri ne integraatiot mitä tarvitaan – niillä tekniikoilla joita tarvitaan.

Miten korkean tuottavuuden sovelluskehitys eroaa muista menetelmistä?

Olen urani aikana toiminut sovelluskehityksessä useissa eri rooleissa ja monenlaisissa ympäristöissä: perinteisessä tuotekehityksessä, täysin räätälöidyissä projekteissa, sekä toteuttamassa ns. ”low-code” –ratkaisuja kolmannen osapuolen tuotteilla. Kaikille edellisille on olemassa paikkansa, mutta omat kokemukseni niistä eivät ole olleet täysin positiivisia:

  • Toimialakohtainen, perinteinen tuotekehitys ei läheskään aina lunasta sille asetettuja lupauksia, koska tuotteet ovat usein liian jäykkiä, tai niiden räätälöinti on kallista
  • Räätälöidyissä projekteissa, huolimatta ketteristä menetelmistä ja moderneista kehitystyökaluista, on edelleen liikaa käsityötä. Puhumattakaan perinteisten vesiputousprojektien ongelmista.
  • Kustannusongelmia on ratkottu ulkoistamalla työtä matalan kustannuksen maihin, mutta kokemukset kustannuksista ja lopputuloksesta eivät usein vastaa asiakkaan tavoitteita
  • Low-code –tyyppiset työkalut, joiden tavoitteena on ”helppo” sovelluskehitys, ovat yleensä ei-triviaaleissa toteutuksissa liian rajoittuneita ja/tai epäkäytännöllisiä. Usein todetaan, että homma olisikin ollut tehokkaampaa koodata käsin.

Korkean tuottavuuden kehittämisen parissa työskenneltyäni olen löytänyt mm. seuraavia etuja:

  • Mallinnusmenetelmässämme ei ole toimialakohtaisia toimintoja, joita on pakko yrittää taivuttaa puoliväkisin eri käyttötarkoituksiin sopivaksi
  • Korkean tuottavuuden kehitysalusta mahdollistaa sen, että ihmistyötä käytetään vain lisäarvon tuottamiseen, ei matalan jalostusasteen koodin tuottamiseen (me ulkoistamme tätä työtä siis tietokoneelle, emme meren taa)
  • Lisäarvoa asiakkaillemme koodaamme standardeilla ohjelmistokehitysvälineillä, joissa ei ole tyypillisiä low code –ratkaisuiden rajoitteita.

Malli on paitsi asiakkaillemme, myös meille hyvin innostava. On hieno tunne saada aikaan asiakkaalle näytettäviä ratkaisuja nopeasti, ja saada myös välitöntä palautetta toteutuksesta, koska voimme esitellä ratkaisua paljon entistä nopeammin. Minun onkin helppo yhtyä uusimman kehittäjämme spontaaniin kommenttiin: ”paluu vanhaan tapaan tuntuu aika vieraalta”.

Pilvi on kehittäjän ja käyttäjän paras ystävä

Olemme iloksemme huomanneet, että asiakkaamme ovat ottaneet käyttöön Microsoft Azure –pilvipalveluita, ja itsekin hyödynnämme niiden vaivattomuutta ja kustannustehokkuutta jatkuvasti. Omia suosikkejamme ovat SaaS-palveluiden, kuten Office 365, lisäksi Microsoft Azuren PaaS-palvelut, jotka ovat yksinkertaisia ja nopeita ottaa käyttöön. Samalla ne ovat tarvittaessa skaalautuvia ja varmistettuja.

Vaikka itse työskentelemmekin päät ja jalat pilvissä, ratkaisumme toimivat yhtä lailla paikalisillakin palvelimilla. Esimerkiksi Microsoft-pohjaisessa toteutuksessa paikallinen IIS-palvelin ja Microsoft SQL Server –palvelin ovat ihan yhtä tuettuja, kuin Azure Web Application ja Azure SQL.

Miksi kaikki eivät tee näin?

Totta puhuen, en oikein ymmärrä miksi; nimittäin meillä kuulee usein lauseen ”eikös tänkin voisi generoida” – ja hyvin usein vastaus on myönteinen. On toki selvää, että räätälintyölle ja valmistuotteille on paikkansa – kaikkea kun ei kannata automatisoida. Toisinaan on tehokkainta koodata, mutta mielestämme olennaista on, ettei koodaajan tarvitsee toteuttaa sellaista koodia, jonka voi jättää koneelle. Järki siis mukana kaikessa.

Kaiken kaikkiaan, kokemusteni perusteella alamme tulevaisuus on korkean tuottavuuden ohjelmistotuotannossa. Onneksi se on meillä jo nyt arkipäivää.