Klassiset työelämän sovellukset muutoksen edessä

IT-maailma on monen muutoksen edessä, ja perinteiset liiketoimintasovellukset siinä samalla. Tehdäänkö kaikki jatkossa vain ERP-moduuleina tai low code -sovelluksina, vai onko räätälöidyille ratkaisuille vielä sijaa?

Lyhyt vastaus on, että tietenkin klassinen koodaaminen on edelleen arkea, mitenkäs muutenkaan. Ajatus siitä, että ERP-laajenteet tai pikkusoftat korvaisivat räätälöidyt järjestelmät, voi olla totta vain riittävän pienessä ja vakiomuotoisessa liiketoiminnassa. Samaan aikaan muutoskin on todellisuutta: Moni sellainen järjestelmä, joka tehtiin 10 vuotta sitten alusta alkaen käsin, korvautuu nyt älykkäillä lomakkeilla, kevyesti skriptatuilla automaatioilla ja joustavilla tietovarastoilla.

Vanhan liiton devaajalle asetelma ei ole helppo. Access-tunkit, Visual Basic -rävellykset ja PHP-sotkut ovat elävä osa alan legendaa – niitä kauhutilanteita, joihin päädytään, kun ei osata oikeasti koodata. Klassinen tekijä vääntää softansa eeppistä C#:ia hioen ja SQL-lauseita optimoiden. Mutta samalla hän on haasteen edessä: Tuottavuus ei riitä, räätälöintien ylläpito on haastavaa ja kollegoita on ihan liian vähän kaikkiin digitalisaatiotarpeisiin.

Kohti ohjelmistotyön uusjakoa

Joidenkin arvioiden mukaan seuraavan viiden vuoden aikana tullaan tekemään enemmän softaa kuin edellisten neljän vuosikymmenen. Tämä muutos ei voi tapahtua ilman, että ohjelmistokehityksen menetelmät uudistuvat radikaalisti. Ainakin seuraavat muutokset näkyvät kristallipallossa:

  1. Sovellukset koostuvat yhä pienemmistä integroitavista palasista
  2. Low code -ratkaisut hoitavat osan perinteisestä devauksesta
  3. Tarkkaa hiomista korvataan nopeilla kokeiluilla – iterointi korostuu
  4. Tekoäly vauhdittaa isoa osaa nykyisestä kehitystyöstä ja muuttaa työnjakoa
  5. Myös kevytsovellusten on osallistuttava organisaation yhteiseen datamalliin

Kokonaisuuden kannalta näillä on suuri merkitys, sillä näennäisesti kapeat muutokset haastavat monta perinteisen IT-ratkaisukehityksen aksioomaa. Muutama esimerkki:

Datan omistajuus hajautuu, kun liiketoiminnan prosesseja tukee yhä suurempi joukko järjestelmiä. Integraatiot joutuvat siirtelemään dataa hyvin erilaisten järjestelmien välillä, jolloin datan muotomuunnokset nousevat vielä aiempaa suurempaankin rooliin.

Tekoälyavusteinen low code -lähestymistapa vaikuttaa järjestelmäkehityksen vastuunjakoon. Liiketoiminnan asiantuntijat voivat halutessaan ottaa itselleen merkittävänkin roolin esimerkiksi prototyyppien teossa. Jo nyt valkotaululle piirretystä kuvasta saa generoitua käyttöliittymää ja jopa toimivaa sovellusta.

Softakehitys ei korvaudu low codella, mutta Power Platformin kaltaiset alustat tekevät monista räätälöinneistä kustannustehokkaampia. Alusta on rajoitetumpi, mutta samalla sovelluksissa on vähemmän hajoavia paikkoja. Toisaalta: Sovellusten määrä kasvaa, liiketoimintalogiikka on entistä hajautuneempaa, ja integraatioiden määrä kasvaa jälleen – eihän saa käydä niinkään, että organisaation toiminnan kannalta keskeinen data jää jumiin jonkin pikkusovelluksen omaan kantaan.

”Mikrosovellusmalli” tukee yritys-IT:n nopeaa ja ennen muuta hajautettua evoluutiota. Teknologiatyön rooli siirtyy taustalle – esimerkiksi rajapintatoteutuksiin – ja itse käyttöliittymäkerroksen evoluutiota voidaan levittää ihmisille, jotka ovat hyvin syvällä itse tekemisen arjessa. Vastahaaste tulee koordinaation myötä: Jos jokainen tekee itse omat sovelluksensa, kuka huolehtii siitä, että esimerkiksi liiketoimintasäännöt pysyvät hallussa? Entä miten paljon liiketoiminta-asiantuntijoiden aikaa on perusteltua käyttää sovelluskehitykseen?

Tekoäly lisää kaikkeen vielä yhden vaikeuskertoimen. Yhtäältä se lisää vauhtia ja laajentaa tekijöiden porukkaa – low code -sovelluksiakin voi tehdä yhä enemmän ilman täsmällistä teknologiatuntemusta – mutta samalla se altistaa aivan uusille virhekategorioille. Kielimallin generoimasta ratkaisusta, oli se sitten Power App tai perinteinen sovellus, saattaa löytyä kaikenlaisia yllätyksiä, joita malli on nähnyt tarpeelliseksi. Ylivoimaisen valtaosan ajasta tekoälyavusteinen kehitys on hyvä, mutta miten tunnistaa ne tilanteet, joissa ongelmia on syntynyt?

IT:n on löydettävä uusi roolinsa

Uutta roolia tarvitsee niin perinteinen organisaation oma hallinnoiva IT kuin myös toimittajakenttä. ”Tämä on tekninen asia”-tyyppistä jakolinjaa on käytetty helposti pilkkomaan keskusteluita liiketoiminta-asiantuntijoiden ja tietotekniikan ammattilaisten välille, mutta tällainen puolittaminen on ollut illuusio jo pitkään. Parhaat ohjelmistokonsultit perehtyvät liiketoimintaan, ja yhä useammat liiketoiminnan tekijät tarttuvat myös Pythonin tai Power Appsin kaltaisiin perusvälineisiin – ja hyvä niin.

Toimittajakentän on löydettävä uusi paikkansa: Pitkästä tavarasta tehtäviä ohjelmistoprojekteja tulee jatkossa olemaan vähemmän, ja erilaiset räätälöinnit, integraatiot ja piensovellukset yleistyvät. Ohjelmistotekniikan lisäksi on hyvä tuntea myös tuotteita – esimerkiksi low code -alustoja – jotta tunnistaa ne paikat, joissa perinteinen koodi on juuri se oikea vasara. Odotus liiketoiminnan ymmärtämisestä kasvaa, joten sosiaaliset taidot muuttuvat entistä tärkeämmiksi. Arkkitehtien on kyettävä miettimään rahaa entistä moniulotteisemmin: Missä paikoissa investointi räätälöityyn ratkaisuun on oikeasti kannattava verrattuna kevyesti rakennettuun low code -sovellukseen, erityisesti ylläpitovaihe huomioiden?

Organisaation oman IT:n on tässä roolissa otettava vahva ohjaajan paikka. Ehkä liiketoiminta tekee osan sovelluksistaan itse, ja ehkä SaaS-ostot vievät osan perinteisistä sopimusvastuista luottokorttilaskujen taakse. Tämän vastineeksi on löydyttävä rautaista osaamista datan hallinnasta, kokonaisuuden valvonnasta, riskienhallinnasta ja monesta muusta.

Samalla ennakkokontrollin käyttökelpoisuus IT:ssä vähenee, sillä tekoälyassistenttien kaltaiset ratkaisut ovat aika isoja päätöksiä: Kun avaat oven esimerkiksi nopeasti kehittyville välineille, on vaikea tietää, mitä kaikkea oikeastaan sallit. Jos vaikka sallitkin ChatGPT:n viime joulukuussa hyvänä apuvälineenä tekstintuottoon, tänä vuonna sitä käytetäänkin tietojohtamiseen lähettelemällä yrityksen ydindataa Advanced Data Analytics -laajenteelle. Ohjausvälineistä on tultava myös tilastollisia ja jälkikäteisiä: järjestelmien käyttöä on ymmärrettävä ja osattava seurata, sillä pelkkä otsikkotaso ei kerro käytetyistä ratkaisuista mitään.

Puhumme isoista muutoksista. Perinteinen softakehitys ei kuole, mutta klassiset ison tiimin ohjelmistoprojektit kohdentuvat entistä tarkemmin. Laadukkaan teknologiaosaamisen tarve ei vähene mihinkään. Osaajan on vain muistettava, että yhä isompi osa loppukäyttäjäyrityksen kilpailukyvystä rakentuu jonkun muun tekemälle koodille, jota sitäkin pitää ymmärtää.

Mietityttääkö sovelluspaletti? Haluatko luoda eheää IT-strategiaa tulevaisuuteen? Ota yhteyttä!