Low Code Development Services Program: Ostajan opas

Low-code-kehityspalveluohjelma on jäsennelty tapa ostaa sovellustoimituksia, yhdistäen visuaalisen alustan, asiantuntijapalvelut ja jatkuvan tuen noin neljään sitoutumismalliin: henkilöstöresurssien lisääminen (staff augmentation), kiinteän laajuuden projektitoimitus, hallitut sovelluspalvelut sekä alusta- ja käyttöönottokumppanuudet. Gartner loi termin “low-code” vuonna 2014, ja markkinat ovat sittemmin jakautuneet erillisiin palvelukategorioihin, jotka eroavat merkittävästi kustannusten, hallinnan ja toimittajalukituksen (lock-in) suhteen.

Low-code-kehityspalveluohjelmat yhdistävät kolme asiaa, jotka perinteisessä IT-maailmassa myydään yleensä erikseen: visuaalisen kehitysalustan, asiantuntijapalvelut sen päälle rakentamiseen sekä jatkuvan tuen sovellusten toimivuuden varmistamiseksi. Ostajat, jotka ymmärtävät tämän paketoinnin, voivat neuvotella jokaisesta kerroksesta itsenäisesti – ja juuri tässä vaiheessa suurin osa arvosta joko saavutetaan tai menetetään.

Alustakerros koostuu työkaluista: vedä-ja-pudota-lomakerakentajista, tietomallisuunnittelijoista, työnkulkukoneista, API-liittimistä ja käyttöönottoputkistoista. Esimerkkeinä mainittakoon Microsoft Power Apps, OutSystems, Mendix, Appian, Retool, Budibase ja – 4D-ekosysteemiin jo panostaneille tiimeille – 4D:n omat lomake-, metodi- ja tietomallityökalut.

Palvelukerros on inhimillistä työtä: määrittelytyöpajoja, tietomallinnusta, integrointia, testausta ja luovutusta. Tukikerros on se, mitä tapahtuu käyttöönoton jälkeen: valvontaa, muutospyyntöjä, versiopäivityksiä ja käyttäjäkoulutusta.

Low-code-kehityspalveluohjelma eroaa kertaluonteisesta projektista yhden tärkeän asian suhteen: se olettaa toistuvat toimitukset. Yhden sovelluksen tilaamisen sijaan ostaja luo pysyvän kyvykkyyden – hallintamallin, uudelleenkäytettävän komponenttikirjaston ja toimitustahdin – jotta toisen sovelluksen kustannukset olisivat huomattavasti pienemmät kuin ensimmäisen. Tämä uudelleenkäytön talous on koko “ohjelma”-ajattelun peruste.

Neljä palvelumallia vertailussa

Low-code-kehityspalveluita on eri muodoissa, jotka sopivat hyvin erilaisille organisaatioille. Alla oleva taulukko on päätöksentekoa helpottava apuväline, jonka useimmat ostajat tarvitsevat ennen keskusteluja toimittajien kanssa.

Aiheeseen liittyvä: Claris FileMaker Pro — Pitkäaikainen relaatiotietokanta-alusta tiimeille, jotka tarvitsevat mukautettuja sovelluksia työpöydälle, verkkoon ja mobiililaitteille yhdestä tiedostosta..

Malli	Tyypillinen ostaja	Hallinta	Kustannusprofiili	Pääriski
Henkilöstöresurssien lisäys	IT-tiimi, jolla on osaamisaukkoja alustassa	Korkea — ohjaat työtä itse	Tunti- tai kuukausihinta	Tieto poistuu urakoitsijan mukana
Kiinteän laajuuden projekti	Osasto, jolla on yksi määritelty sovellus	Matala rakentamisen aikana	Kiinteä hinta per sovellus	Muutospyynnöt laskutetaan erikseen
Hallitut sovelluspalvelut	Operatiivinen tiimi, joka pyörittää live-sovelluksia	Matala tai keskisuuri	Toistuva retainer-maksu	Hidas reagointi uusiin vaatimuksiin
Alusta- ja käyttöönottokumppanuus	Organisaatio, joka rakentaa sisäistä kyvykkyyttä	Keskisuuri, kasvaa ajan myötä	Yhdistelmä: alusta, koulutus, rakentaminen	Vaatii sisäisen henkilöstön aikaa omaksumiseen

Henkilöstöresurssien lisäys sopii tiimeille, joilla on jo alustastandardi ja backlog. Kiinteän laajuuden projektit sopivat yhteen korkean arvon työnkulkuun, jossa on vakaat vaatimukset. Hallitut palvelut sopivat säänneltyihin ympäristöihin, joissa käyttöaste ja auditointijäljet ovat tärkeämpiä kuin nopeus. Käyttöönottokumppanuudet sopivat organisaatioille, jotka aikovat rakentaa kymmeniä sovelluksia ja haluavat kyvykkyyden talon sisälle.

Käytännön sääntö: jos ostaja ei pysty nimeämään henkilöä, joka omistaa sovelluksen kahden vuoden kuluttua, ohjelma ostetaan väärästä syystä. Low-code-kehityspalveluohjelmat epäonnistuvat useimmiten ei siksi, että alusta oli väärä, vaan koska sisäistä omistajaa ei koskaan nimetty.

Miten low-code- ja no-code-palvelut eroavat käytännössä

Low-code- ja no-code-kehityspalveluita markkinoidaan usein yhtenä kategoriana, mutta nämä kaksi puoliskoa asettavat erilaisia rajoituksia palvelusitoumukselle. No-code-työkalut on suunnattu liiketoimintakäyttäjille, jotka konfiguroivat sovelluksia kirjoittamatta logiikkaa; low-code-työkalut olettavat, että kehittäjä laajentaa alustaa koodilla, kun visuaalinen rakentaja ei enää riitä.

Meidän valintamme: Airtable — Yksinkertainen laskentataulukkokäyttöliittymä, joka sijaitsee todellisen relaatiotietokannan päällä, jossa on automaatioita, näkymiä ja jaettavia käyttöliittymiä..

Tämä ero muuttaa palvelusopimusta. No-code-sitoumus on pääasiassa konfigurointia, koulutusta ja hallintoa – toimittajan tehtävänä on pitää “citizen developerit” turvallisten rajojen sisällä. Low-code-sitoumus lisää integraatiotekniikan, mukautetut komponentit, suorituskyvyn optimoinnin ja CI/CD-asetukset, koska sovellusten odotetaan yhdistyvän tuotantojärjestelmiin ja skaalautuvan.

Useimmat yritysohjelmat päätyvät hybrideiksi. No-code-taso hoitaa osastokohtaisia seurantalistoja, hyväksyntävirtoja ja tiedonkeruuta. Low-code-kehityspalveluohjelman taso hoitaa kaiken, mikä kirjoittaa ydinjärjestelmään, valvoo monimutkaisia liiketoimintasääntöjä tai vaatii auditointijäljen. Toimittajat, jotka myyvät vain yhtä tasoa, pyrkivät ajamaan kaikki vaatimukset kyseiselle tasolle, mikä on syytä seurata määrittelyvaiheessa.

Miltä todellinen sitoumus näyttää vaihe vaiheelta

Low-code-kehityspalveluiden toimitus noudattaa tunnistettavaa kaarta, ja vaiheiden tunteminen auttaa ostajaa havaitsemaan toimittajan, joka ohittaa kalliit vaiheet.

Määrittely ja tietomallinnus. Toimittaja kartoittaa liiketoimintaprosessin, tunnistaa entiteetit ja suhteet sekä päättää, mikä sijaitsee low-code-alustalla ja mikä jää perusjärjestelmään (system of record). Tietomallinnus on vaihe, josta suurin osa uudelleenkirjoituksista saa alkunsa; väärän entiteettimallin päälle rakennettu lomake joudutaan rakentamaan uudelleen, ei vain paikkaamaan.

Prototyyppi ja validointi. Toimiva prototyyppi esitellään todellisille käyttäjille ensimmäisten viikkojen aikana. Low-code-alustat tekevät tästä kustannustehokasta, ja toimittaja, joka ei pysty nopeasti luomaan klikattavaa prototyyppiä, ei hyödynnä alustan pääetua.

Rakentaminen ja integrointi. Näytöt, työnkulut, arvolistat ja API-yhteydet kootaan. Integrointi on yleensä suurin erä rehellisessä kustannusarviossa, koska todennus, virheiden käsittely ja tietojen synkronointi eivät ole koskaan niin yksinkertaisia kuin demossa esitetään.

Aiheeseen liittyvä: Knack — Kooditon tietokannan rakentaja, joka on tarkoitettu portaaleihin, hakemistoihin ja sisäisiin työkaluihin – kiinteähintaisella hinnoittelulla käyttäjäkohtaisten maksujen sijaan..

Testaus ja kovettaminen. Roolipohjainen käyttöoikeus, syötteiden validointi, samanaikaisuus ja suorituskyky realistisilla tietomäärillä tarkistetaan. Low-code-alustat piilottavat monimutkaisuuden, mikä tarkoittaa, että suorituskykyongelmat tulevat usein esiin myöhään.

Käyttöönotto ja luovutus. Sovellus siirtyy tuotantoon ja – kriittisesti – dokumentaatio, ylläpitäjän koulutus ja muutospyyntöprosessi siirtyvät sisäiselle tiimille.

Käyttö ja iterointi. Low-code-kehityspalveluohjelma jatkuu backlogin, julkaisutahdin ja säännöllisten alustapäivitysten avulla. Alustatoimittajat julkaisevat uusia versioita omassa aikataulussaan, ja jonkun on huolehdittava näiden muutosten omaksumisesta.

Jos olet ostoksilla: Zoho Creator — Halpakoodisovellusten rakentaja, joka liitetään laajempaan Zoho-sviittiin ja hinnat käyttäjää kohti sovelluksen sijaan..

Valintakriteerit, jotka todella ennustavat menestystä

Low-code-kehityspalveluiden toimittajien arvioiminen pelkän brändin tunnettuuden perusteella johtaa kalliisiin virheisiin. Alla olevat kriteerit korreloivat low-code-kehityspalveluohjelmien kanssa, jotka selviävät toisen vuoden yli.

• Alustan poistumiskustannukset. Kysy, mitä sovellukselle tapahtuu, jos yhteistyö päättyy. Voidaanko tiedot viedä käyttökelpoiseen muotoon? Voiko joku muu lukea logiikan? Proprietaarinen visuaalinen logiikka on suurin yksittäinen lukittumisriski tällä markkinalla.
• Integraatiohistoria. Pyydä kaksi referenssiä, jotka koskevat samaa järjestelmäluokkaa, johon tarvitset yhteyden – ERP, CRM, legacy-tietokanta tai on-premise-hakemisto.
• Nimattu tiimi, ei vain osaamisesitys. Kysy, kuka työn todellisuudessa tekee ja ovatko kyseiset henkilöt työntekijöitä vai alihankkijoita.
• Hallintoartefaktit. Vakavasti otettava ohjelma tuottaa ympäristöstrategian, käyttöoikeusmallin ja nimeämiskäytännön. Toimittajat, jotka pitävät näitä valinnaisina, rakentavat tulevaa ylläpitovelkaa.
• Luovutussitoumus. Sopimuksessa tulee määritellä dokumentaatio, ylläpitäjän koulutus ja määritelty jälkitoimen tuki julkaisun jälkeen.
• Hinnoittelun läpinäkyvyys. Käytössä on sovellus-, käyttäjä-, tunti- ja retainer-hinnoittelua. Mallilla on vähemmän merkitystä kuin sillä, osoittaako toimittaja, miten loppusumma on muodostunut.

Alustotason due diligence -tutkimuksessa Gartnerin ja Forresterin kaltaisten yritysten julkaisemat analyysit ovat kohtuullinen lähtökohta, ja Wikipedia-artikkeli low-code-kehitysalustoista antaa neutraalin yleiskatsauksen kategorian historiasta ja määritelmistä. Säänneltyjen toimialojen ostajien tulisi myös tarkistaa toimittajan suhtautuminen NIST Cybersecurity Frameworkiin, jota monet yritysten hankintatiimit käyttävät nykyään yhteisenä sanastona tietoturvakysymyksissä.

Missä low-code-ohjelmat todella kannattavat – ja missä eivät

Low-code-kehityspalveluohjelmat tuottavat parhaan hyödyn sovelluksista, jotka ovat lukuisia, samankaltaisia ja lyhytikäisiä. Sisäiset pyyntölomakkeet, hyväksyntätyönkulut, tarkistuslistat, varastonseurantalistat ja osastokohtaiset hallintapaneelit sopivat tähän malliin: jokainen on pieni, jokainen jakaa komponentteja sisarsovellustensa kanssa, ja jokainen istuisi muuten kuukausia IT-jonossa.

Ohjelmat kohtaavat vaikeuksia, kun sovellus on aidosti monimutkainen. Suuren volyymin transaktiojärjestelmät, sovellukset, joissa on monimutkaisia samanaikaisuusvaatimuksia, ja kaikki raskaan reaaliaikaisen laskennan vaativat ratkaisut palvelevat yleensä paremmin perinteistä kehitystä – tai hybridiä, jossa low-code-kerros hoitaa käyttöliittymän ja perinteinen palvelu hoitaa ydinlogiikan.

Toinen epäonnistumismalli on hylätty pilotti. Organisaatiot toteuttavat usein onnistuneen konseptitodistuksen (PoC), mutta pysähtyvät sitten, koska kukaan ei rahoittanut hallintakerrosta. Pilotti todistaa, että alusta toimii; se ei todista, että ohjelma toimii. Tylsien osien – ympäristönhallinnan, tietoturvatarkastelun, koulutuksen ja tuen – budjetointi on se, mikä muuttaa pilotin ohjelmaksi.

Kolmas malli on “varjojen leviäminen” (shadow sprawl). Kun citizen developerit rakentavat vapaasti ilman komponenttikirjastoa tai tarkistusprosessia, organisaatiolle voi kertyä satoja lähes identtisiä sovelluksia ilman tietoa siitä, mitä on olemassa. Palveluohjelman tulisi sisältää sovellusrekisteri ensimmäisestä päivästä alkaen.

Build Versus Buy: Kun sisäinen ohjelma voittaa ulkoisen

Organisaatiot, joilla on jo kehityskapasiteettia, kysyvät joskus, tarvitsevatko ne ulkopuolisia low-code-kehityspalveluita lainkaan. Rehellinen vastaus riippuu kolmesta muuttujasta: kuinka monta sovellusta on suunniteltu, kuinka epätavallisia integraatiovaatimukset ovat ja onko alusta jo standardoitu.

Sisäinen ohjelma on järkevä, kun organisaatio on sitoutunut yhteen alustaan, suunnittelee enemmän kuin kourallisen sovelluksia ja voi osoittaa vähintään yhden kokeneen kehittäjän alustan omistajaksi. Ulkopuolisen toimittajan rooli kutistuu tällöin alkuvaiheen käyttöönottoon ja satunnaiseen asiantuntijatyöhön.

Ulkoinen ohjelma on järkevä, kun alustapäätös on vielä avoin, kun ensimmäiset sovellukset sisältävät tuntemattomia integraatioita tai kun sisäistä henkilökuntaa ei yksinkertaisesti voida vapauttaa nykyisistä sitoumuksista. Tällöin sopimukseen tulisi kirjoittaa selkeä poistumisreitti – piste, jossa sisäinen tiimi ottaa vastuun – avoimen retainer-sopimuksen sijaan.

4D-alustalla rakentavat tiimit sijoittuvat usein välimaastoon. Tietomalli, lomakkeet ja metodit ovat jo tuttuja sisäiselle kehittäjälle, joten ulkoiset palvelut ovat arvokkaimpia integraatiotyössä, käyttöönottoarkkitehtuurissa ja vanhojen binäärirakenteiden modernisoinnissa. Tämä on suppeampi sitoumus kuin täysi ohjelma, ja se tulisi hinnoitella sen mukaisesti.

Lähteet ja lisälukemista

• Low-code development platform — Wikipedia: Low-code-kehitysalusta (LCDP) tarjoaa ohjelmistokehitysympäristön – tyypillisesti graafisen käyttöliittymän (GUI) – joka vaatii vähän tai ei lainkaan koodin kirjoittamista…

Usein kysytyt kysymykset

Mikä on low-code-kehityspalveluohjelma?

Low-code-kehityspalveluohjelma on pysyvä järjestely, jossa toimittaja tarjoaa sekä low-code-alustan että asiantuntijapalvelut sovellusten rakentamiseen, käyttöönottoon ja ylläpitoon. Se eroaa yksittäisestä projektista, koska se olettaa toistuvat toimitukset, yhteiset komponentit ja jatkuvan hallintamallin. Ostajat valitsevat yleensä henkilöstöresurssien lisäyksen, kiinteän laajuuden projektien, hallittujen palveluiden ja käyttöönottokumppanuuksien väliltä.

Kuinka paljon low-code-kehityspalvelut maksavat?

Hinnoittelu vaihtelee liikaa, jotta voitaisiin antaa yksi luotettava luku, koska se riippuu alustan lisenssistä, sitoutumismallista ja integraatioiden monimutkaisuudesta. Toimittajat laskuttavat tunnin, sovelluksen tai käyttäjän mukaan tai kuukausittaisena retainer-maksuna, ja alustan lisensiointi laskutetaan yleensä erikseen palveluista. Hyödyllisin vertailukohta on toimitetun sovelluksen kokonaiskustannus usean sovelluksen tiekartalla, ei pelkkä tuntihinta.

Sopiiko low-code yrityssovelluksiin?

Low-code sopii yrityssovelluksiin, jotka ovat lukuisia, työnkulkulähtöisiä ja integraatiopainotteisia – kuten hyväksyntäjärjestelmät, seurantalistat, portaalit ja osastotyökalut. Se sopii heikommin suuren volyymin transaktiokerjastimille, reaaliaikaiselle laskennalle ja järjestelmille, joissa on epätavallisia samanaikaisuusvaatimuksia. Monet yritykset käyttävät hybridimallia: low-code käyttöliittymä- ja työnkulkukerrokselle ja perinteistä koodia ydinlogiikalle.

Mitä eroa on low-code- ja no-code-kehityspalveluilla?

No-code-palvelut keskittyvät konfigurointiin ja hallintaan, jotta liiketoimintakäyttäjät voivat rakentaa turvallisesti ilman ohjelmointia. Low-code-palvelut lisäävät integraatiotekniikan, mukautetut komponentit, suorituskyvyn optimoinnin ja käyttöönottoputkistot, koska sovellusten odotetaan yhdistyvän tuotantojärjestelmiin. Useimmat yritysohjelmat hyödyntävät molempia tasoja reitittäen yksinkertaiset sovellukset no-codeen ja monimutkaiset low-codeen.

Kuinka kauan sovelluksen toimittaminen low-code-palveluohjelman kautta kestää?

Prototyyppi voidaan usein näyttää ensimmäisten viikkojen aikana, ja yksinkertainen osastosovellus saavuttaa tuotannon tyypillisesti muutamassa kuukaudessa eikä vuosineljänneksissä. Aikajanat venyvät, kun integraatiot ovat monimutkaisia, tietoturvatarkistus on raskas tai vaatimukset muuttuvat kesken rakentamisen. Ohjelman todellinen nopeusetu näkyy toisessa ja kolmannessa sovelluksessa, kun komponentit ja hallinta ovat paikoillaan.

Mitä low-code-palvelusopimuksen tulee sisältää?

Sopimuksessa tulee määritellä nimetty toimitustiimi, alusta- ja lisensointivastuut, integroinnin laajuus, dokumentaatio ja järjestelmänvalvojan koulutus, määritelty julkaisun jälkeinen tukijakso sekä ehdot, joilla ostaja voi ottaa työn itse. Tiedonvientioikeudet ja mukautetun logiikan luettavuus on määriteltävä selkeästi, koska ne määräävät, kuinka kallista on jättää toimittaja myöhemmin.