Entä jos pyramidi olisikin rakennettu lowcode-mallilla?

Egyptin pyramidit ovat yksi maailman seitsemästä ihmeestä. Kokoluokassaan pyramidi on hervoton ponnistus, varsinkin, kun otetaan huomioon aikakauden teknologia(?) ja työvälineiden taso.

Voisi kuitenkin olettaa, että jotkut fiksummat ja styranki-ohjatun laatikon ulkopuolelta ajattelevat kyseenalaistivat tekemisen järkevyyden ja tehokkuuden: täytyyhän tähän olla joku parempikin tapa.

Ripauksella mielikuvitusta kuuluisien monitahokkaiden rakentamista voisi verrata vaikka sovelluskehitykseen ja sitä kautta toimitusprojektiin. Pyramidin palasten valmistamiseen, kuljetukseen ja kasaan latomiseen – eli kehitysprosessiin, toimitukseen ja versiojulkaisuun.

Luultavasti Egyptin projekteissa suosittiin vesiputousmallia eikä väliversioista tai toimitussisällöistä juuri ääntä pidetty. Saati retusoitu aikaansaannoksia yhteistuumin lyhyemmillä aikaväleillä ja mietitty, että saisikohan giganttisia lohkareita kenties jotenkin helpommin paikalleen.

Murikoiden tuottamista aikalaisten toimesta voisi joku levoton myös verrata ohjelmistokehitykseen/koodaamiseen ja pyramidien tapauksessa "pitkästä tavarasta tekemiseen". Silloin lähdetään ns. nollasta, kääritään parin ammattilaisen C#-hihat, kutsutaan frontti-devari, sekä tietokantaguru mukaan joukkoon tummaan, sovitaan tilaajan kanssa, että asiaan palataan ja tuotoksia esitellään pikapuoliin.

Hieman ennen joulupukin tuloa järkätystä kick-offista onkin äkkiä kulunut sen verran aikaa, että leskenlehtiä poksahtelee jo näkösälle, ensimmäinen POC/Proto/Alfa-version itu on saatu uunista ulos ja tilaajan odottavien silmien alle.

Entä jos sitten käykin niin, että tilaaja ei innostukaan näkemästään ja pahimmillaan selviää, että uutuuttaan kiiltelevä sovellushelmi ei vastaakaan odotuksia, saati määrityksiä?

Hiekkakivestä tilattu pyramidi ei näytäkään tarpeeksi arvokkaalta siellä tontilla. Mahtipontisempaa olisi ollut tehdä se marmorista ja ehkä suunnikas olisi ollutkin muotona parempi... Mutta olkoon nyt, kun kerran tuli rakennettua, muutetaan sitten myöhemmin.

Lowcode on toimiva – mutta ei hopealuoti

Moderni ja visuaalinen lowcode on jalkautunut nopeasti sovelluskehitykseen. Lähivuosina lowcoden rooli kasvaa merkittävästi erityisesti liiketoimintakriittisten ratkaisujen kehityksessä, sillä se tuo uusien ratkaisujen hyödyt nopeasti ja edullisesti liiketoiminnan käyttöön.

Lowcoden avulla sovellusten kehitykseen tarvitaan aiempaa vähemmän perinteistä koodausta, joten sovelluskehitys on helpompaa ja nopeampaa kuin perinteisessä koodaamisessa.

Lowcode-kehitys ja saavutettava hyöty ei kuitenkaan tulkkaudu "hopealuodiksi" tai kaikenratkaisevaksi ilmastointiteipiksi sovelluskehityksen saralla. Silti se parantaa tekemistä merkittävästi ja tuo ennen kaikkea etuja tilaajalle.

Jargon-bingossakin varman nakin saavuttanut "time to market" ei tässä kohtaa olekaan sanahelinää. Lowcode-kehittäminen on aidosti ja myös tutkitusti huomattavasti nopeampaa kuin aiemmin mainittu pitkästä tavarasta tekeminen. Samoin ensimmäisen POC:n tekeminen hoituu parhaimmillaan tunneissa, jolloin voidaan myös tunnistaa ensimmäiset mahdolliset väärinymmärrykset tai huomioida riittävän nopeasti myös tilaajan ja toimittajan "ai niin eiku joo sehän pitää ollakin näin" -tyyppiset ahaa-elämykset.

“Organizations are increasingly turning to low-code development technologies to fulfill growing demands for speed application delivery and highly customized automation workflows” Varsha Mehta, Senior Market Research Specialist at Gartner

Lowcode on ohjelmistokehityksen saralla tunnistettu terminä jo pidemmän aikaa. Kuitenkin vasta viime aikoina se on alkanut saada tuulta alleen, kun suuri yleisö on huomannut sen edut ja arkaillen startatuista ensikokeiluista on saatu hyviä tuloksia.

Kiinnostusta lowcode-alustoihin lisää myös se, että tuotteet ovat kehittyneet ja toimittajien välinen kilpailu toimii asiakaskunnan eduksi.

Tutkimusten ja raporttien kärkeä tähdittävät pääsääntöisesti OutSystems ja Microsoft Power Platform. Kentällä on useita muitakin pelureita, jotka satsaavat jatkuvasti (kuten myös nämä nimeltä mainitut) alustojensa kehittämiseen ja ominaisuuksien parantamiseen. Kaikki alustat eivät sovellu kaikkeen ja olennaista onkin evaluoida alustan natsaaminen tarpeeseen.

Mitäpä jos tekisitkin itse?

Tvins-maailmassa ylivirittynyt, maneereilla kuorrutettu tuote-esittelijä, lisäisi tässä kohtaa vettä myllyyn ilmoittamalla leveän posliinihymyn kera, ettei tässä suinkaan ole vielä kaikki.

Termi ”kansalaiskehitys” (citizen development) on mielenkiintoinen kulma lowcode-kehitykseen. Kynnys ottaa sovelluskehitin haltuun ja päästä tuottavaan moodiin on huomattavasti matalampi, kuin laittaa vaikkapa tietyn osa-alueen substanssiosaajat opiskelemaan Javaa muiden töidensä ohessa. Tilaajalla on siis halutessaan mahdollista hoitaa osa sovellusmuutoksista itsenäisesti perehdytyksen myötä, verrattain pienen oman tekijätiimin avulla.

Toki kehittäminen on jouhevinta silloin, kun tekijät omaavat jonkinlaisen ohjelmointitaustan tai tietämyksen koodaamisesta, mutta lowcode-alusta avaa mahdollisuuksia osallistaa projekteihin enemmän tilaajan omia asiantuntijoita ja samalla parantaa yhteistyötä toimittajan kanssa.

Ohjelmistotuotannossa lowcode on jo aidosti varteenotettava vaihtoehto. Uusien tuulien haistelu saattaa hyvinkin maksaa itsensä monin kerroin takaisin sekä talouslukuina, että aikataulussaan pysyneinä projekteina.

Gartner estimates that “By 2025, 70% of new applications developed by enterprises will use low-code or no-code technologies, up from less than 25% in 2020.”

>Päräytä Lowcode-moottori käyntiin järeissä sovellushankkeissa