Miksi integraatiokehittäjän kannattaa sukeltaa syvälle asiakkaan liiketoimintaan?

Integraatiokehittäjänä tekninen osaaminen on tärkeää, mutta se on vain osa kokonaisuutta. Devikoneella olemme huomanneet, että todellinen arvo syntyy, kun yhdistämme teknisen osaamisemme syvälliseen ymmärrykseen asiakkaidemme liiketoiminnasta. Mutta miksi tämä on niin tärkeää, ja miten voimme kehittää tätä ymmärrystä?

Liiketoimintaymmärrys on avain onnistuneisiin integraatioihin

Integraatiokehittäjämme Marjut Mikkola tiivistää asian osuvasti:

"Integraatiokehittäjän työ ei ole pelkästään koodaamista. Tässä työssä täytyy ymmärtää asiakkaan prosessia siellä toisessa päässä. Kun lähdetään rakentamaan integraatiota, täytyy ymmärtää mitä tietoa halutaan kuljettaa, mistä ja mihin sekä miltä sen tulee näyttää määränpäässä."

Marjutin näkemys kiteyttää, miksi liiketoimintaymmärrys on niin kriittistä:

Miten sukeltaa syvälle asiakkaan liiketoimintaan?

Devikoneen CTO ja perustajajäsen Tuomas Palenius korostaa, että liiketoiminnan ymmärtäminen on jatkuva prosessi:

"Jokaisen rakennetun integraation jälkeen osaaminen kehittyy, vaikka sitä ei juuri siinä hetkessä ymmärtäisi."

Centaur Programming

Vuonna 1998 Garry Kasparov esitteli konseptin nimeltä "Advanced Chess" tai "Centaur Chess". Tässä pelimuodossa ihmispelaaja ja tietokoneohjelma tekevät yhteistyötä shakkipelin aikana. Aluksi tämä yhdistelmä oli vahvempi kuin pelkkä tietokone tai ihminen yksin. Ihminen pystyi hyödyntämään tietokoneen laskentakykyä ja tarkkaa taktista analyysiä, mutta samalla tuomaan strategista ymmärrystä ja intuitiota, jota tietokoneilla ei vielä ollut. Ajan myötä shakkitietokoneet ovat kehittyneet niin pitkälle, että ne ovat nyt täysin ylivoimaisia sekä ihmisiin että ihmisen ja tietokoneen yhdistelmiin verrattuna. Nykyään huipputason shakkitekoäly, kuten AlphaZero, pystyy voittamaan parhaat ihmispelaajat ja Advanced Chess -yhdistelmät helposti.

LLM ja ohjelmoijan yhteistyö

Samankaltainen kehitys on nähtävissä ohjelmoinnin alalla. Kokenut ohjelmoija voi hyödyntää LLM:ää (esim. GPT-4) tehokkaasti työkaluna, samaan tapaan kuin shakkimestari aikaisemmin hyödynsi tietokonetta Advanced Chess -pelissä. Ohjelmoija ymmärtää, mitä on mahdollista tehdä, osaa muotoilla oikeat kysymykset ja arvioida LLM:n tuottamaa koodia kriittisesti. Toisaalta jos henkilöllä ei ole ohjelmointiosaamista, LLM:n hyödyntäminen ohjelmointitehtävissä voi olla haastavaa. Ilman ymmärrystä koodin toiminnasta ja ohjelmoinnin periaatteista, on vaikea arvioida LLM:n tuottaman koodin laatua, toimivuutta tai turvallisuutta. Lisäksi voi olla vaikeaa ymmärtää, mikä ylipäätään on mahdollista toteuttaa koodilla.

Vaikka LLM:t kehittyvät jatkuvasti, on todennäköistä, että lähitulevaisuudessa ihmisen ja tekoälyn yhteistyö ohjelmointitehtävissä pysyy tehokkaimpana lähestymistapana. Kutsutaan tätä nyt vaikka nimellä "Centaur Programming". Toisin kuin shakissa, ohjelmoinnissa on paljon kontekstuaalisia, luovia ja ongelmanratkaisuun liittyviä elementtejä, joissa ihmisen panoksella on edelleen suuri merkitys. Näin ollen arvioin, että ohjelmoijia tarvitaan edelleen lähitulevaisuudessa (viiden vuoden tarkastelujakso).

Historian kautta asioiden tarkastelu ja kontekstointi auttaa ymmärtämään kuinka tärkeää on ylläpitää ja kehittää omaa osaamistaan, jotta voi ymmärtää ja suunnitella ratkaisuja sekä tehokkaasti ohjata tekoälyn työskentelyä. On huomattavissa selkeä paine siirtää kehittäjän osaamista enemmän arkkitehtisuunnittelun tasolle, asia johon olemme Devikoneelle vahvasti panostaneet. Integraatioiden parissa työskentely antaa mielestäni parhaat eväät tällaiselle ylätason arkkitehtuuripatternien ymmärtämiselle ja niiden käytännön soveltamiselle, ja näin ollen mahdollistaa että olemme alalla edelleen vuosien päästä relevantteja.

Hieno aikakausi meneillään ohjelmoinnissa

Uskon vahvasti, että nyt on mielettömän hieno aika tehdä integraatiotöitä, olemme mukana suuressa murroksessa. Centaur Programming -aikakaudesta kannattaa nauttia niin kauan kuin se kestää. Tämän aikakauden jälkeen on vaikea ennustaa mitä tulevaisuus tuo, mutta tässä kaksi skenaariota: 1) tekoäly jatkaa kehittymistä ja saavuttaa ihmisen tason (AGI, Artificial General Intelligence). 2) ihminen ja tekoäly integroituvat tiiviimmin (BMI, Brain machine interface).

Uskon, että näistä skenaario 2) on vääjäämätön lopputulema nykyisellä kehitysradalla, perustuen jatkuvaan tehostamisen tarpeeseen (lopputulemana "cyborg"). Ne jotka voivat olla jatkuvassa vuorovaikutuksessa (nykyistä vielä älykkäämmän) tekoälyn kanssa saavat vääjäämättä itselleen suuren kilpailuedun, mikä tarkoittaa että kaikkien tulee adaptoitua tähän malliin. Itsessään teknologian kehitys tähän suuntaan on neutraalia, mutta sen vaikutukset voivat olla positiivisia tai negatiivisia. On helppo kuvitella miten töiden tehostuminen sujuvoittaa arkea, poistaa aikaa vieviä rutiineja ja vapauttaa aikaa luovuudelle ja meille ihmisille mielekkäälle ajankäytölle. Toisaalta on myös helppo kuvitella miten tällainen yhdistelmä tulee syömään meiltä kaiken vapaa-ajan. Dystooppisessa skenaariossa on vaikea sanoa onko henkilö oikeasti läsnä ihmisten välisessä vuorovaikutustilanteessa, vai antaako hän samaan aikaan ohjeita tekoälylle esim. päivittää jotakin softapalasta (vrt. tämän päivän kännykän näprääminen)...

Haluaisin uskoa, että olemme yhteiskuntana niin valveutuneita, että osaisimme keskustella tällaisesta skenaariosta, ennen kuin se yllättää meidät. Tämä olkoon siis keskustelun avaus. Kerro Linkkarissa tai suosikkiSOMEssasi mitä ajatuksia kirjoitukseni herättää.

Kolme periaatetta integraatiotiimin ohjaamiseen - CTO Tuomas Paleniuksen näkemys

Integraatioarkkitehtuurin ja -projektien johtaminen vaatii vahvaa kokonaisnäkemystä ja kykyä ohjata tiimiä kohti yhteisiä tavoitteita. Devikoneen CTO ja pääarkkitehti Tuomas Palenius jakaa kolme keskeistä periaatetta, joilla hän varmistaa tiiminsä onnistumisen haastavissa integraatioprojekteissa.

1. Kokonaiskuvan jakaminen

"Arkkitehtuurisuunnitelman ja periaatteiden ymmärtäminen on kaiken a ja o", Tuomas painottaa. "Kun itsellä on kirkas kuva tavoitteista, vaatimuksista ja toimintaympäristön rajoitteista, pystyn ohjaamaan tiimiä määrätietoisesti kohti päämäärää."

Tuomas korostaa avoimen kommunikaation merkitystä: "Pyrin jakamaan kokonaiskuvaa aktiivisesti kaikille projektiin osallistuville. Arkkitehtuuritiimissä käymme läpi erilaisia skenaarioita ja pohdimme, miten erilaiset parametrit vaikuttavat kokonaisuuteen."

"Tavoitteeni on, että kaikilla olisi mahdollisimman kattava näkemys niin arkkitehtuurista kuin siihen vaikuttavista tekijöistä", Tuomas jatkaa. "Uskon, että tiedon avoin jakaminen mahdollistaa erilaisten näkökulmien löytämisen ja parhaan mahdollisen ratkaisun kehittämisen yhdessä."

2. Avoin kommunikaatio ja dialogi

Integraatioprojekteissa nousee usein esiin yllättäviä kysymyksiä ja haasteita. Tuomaksen mukaan avoin dialogi on avainasemassa näiden ratkaisemisessa:

"Kun kommunikoimme arkkitehtuurisuunnitelmista, vastaan tulee väistämättä tilanteita, joissa joudumme miettimään, miten tietty ratkaisu sovitetaan käytäntöön. Tällöin on ensiarvoisen tärkeää, että itsellä on vankka kokonaiskuva, jotta voin joko vastata kysymykseen heti tai ohjata tiimiä lyhyen yhteisen analyysin kautta oikeaan suuntaan."

Tuomas korostaa myös joustavuuden merkitystä: "Joskus kohtaamme tilanteita, joihin emme löydä vastausta yhdessäkään. Silloin hyvää johtajuutta on käynnistää tarvittava selvitystyö, joka voi vaatia kommunikaatiota eri sidosryhmien suuntaan, teknistä lisäselvitystä tai toimintaympäristön tarkentamista. Tärkeää on myös osata delegoida ja ohjata tätä selvitystyötä tehokkaasti."

3. Kaikkien mielipiteiden huomiointi

"Kokemukseni mukaan kaikkien mielipiteillä on merkitystä", Tuomas painottaa. "Pyrin aina pyytämään ryhmän jokaiselta jäseneltä ajatuksia käsiteltävään asiaan. Hyvistä huomioista ja nostoista annan kiitosta kaikkien kuullen."

Tuomas uskoo, että tämä lähestymistapa kannustaa tiimiä aktiiviseen osallistumiseen ja innovointiin. "Kun jokainen kokee tulevansa kuulluksi, se lisää sitoutumista ja motivaatiota yhteisiin tavoitteisiin", hän toteaa.

Jatkuva kehittyminen pääarkkitehdin roolissa

Lopuksi Tuomas korostaa pääarkkitehdin roolin jatkuvaa luonnetta: "Pääarkkitehdin tulee olla jatkuvasti kartalla kokonaiskuvasta ja siihen tapahtuvista muutoksista. Vaatimusten analysointi ja arkkitehtuurisuunnitelmien työstäminen on jatkuvaa tekemistä, samoin kaikkien selvityksen alla olevien säikeiden seuraaminen, yhdistely ja analysointi."

Tuomas painottaa myös tiimityön merkitystä: "Tähän työhön pitää saada mahdollisimman paljon tukea muilta. Pyrin käyttämään aikaa myös teknisten tuotosten läpikäyntiin ja kommentointiin, jotta voimme yhdessä varmistaa parhaan mahdollisen lopputuloksen."

Nämä kolme periaatetta - kokonaiskuvan jakaminen, avoin kommunikaatio ja kaikkien mielipiteiden huomiointi - muodostavat Tuomas Paleniuksen johtamisfilosofian ytimen. Niiden avulla Devikone pystyy toteuttamaan vaativia integraatioprojekteja tehokkaasti ja laadukkaasti, samalla varmistaen tiimin jäsenten ammatillisen kehittymisen ja työtyytyväisyyden.

Lue myös Agile-integraatiokehityksen avaimista.

Agile-integraatiokehityksen avaimet Devikoneella

Integraatioiden kehittäminen on yksi ohjelmistokehityksen haastavimmista osa-alueista. Devikoneella hyödynnämme ketteriä menetelmiä (agile-menetelmät) integraatiokehityksessä, mikä on osoittautunut erittäin tehokkaaksi lähestymistavaksi. Tässä blogissa avaamme viisi keskeistä periaatetta, joihin Devikoneen CTO:n mukainen näkemys agile-integraatiokehityksestä perustuu. Käydään läpi mitä siis agile tarkoittaa Devikoneelle?

1. Joustava arkkitehtuuripohja

Integraatiokehityksen kulmakivi on hyvä ja joustava arkkitehtuuripohja. Tämä tarkoittaa, että järjestelmämme on suunniteltu alusta alkaen mukautumaan erilaisiin integraatiotarpeisiin. Joustava arkkitehtuuri mahdollistaa nopean reagoinnin muuttuviin vaatimuksiin ja mahdollistaa tulevatkin muutokset. Ilman joustavaa teknistä arkkitehtuuria agile yleisestikin jää vain sanahelinäksi. Open source -integraatioratkaisut toteuttavat parhaiten tätä mallia, jolloin myös monimutkaisimmat tarpeet saadaan toteutettua aikaa kestävällä tavalla, muutoksia kun aina kuitenkin tapahtuu integraation koko elinkaaren aikana.

2. Iteratiivinen suunnittelu

Vaikka aloitamme tuottamalla hyvän integraatiosuunnitelman, ymmärrämme, että se tarkentuu tekemisen aikana. Agile-periaatteiden mukaisesti emme lukitse kaikkia yksityiskohtia etukäteen, vaan annamme suunnitelman elää ja kehittyä projektin edetessä. Tämä mahdollistaa joustavan reagoinnin uusiin oivalluksiin ja muuttuviin tarpeisiin. Integraation valmistuttua voimme esittää asiakkaalle integraatiosta kattavan ja ajantasaisen dokumentaation.

3. Kattavat integraatiotestit

Laatu on meille ensiarvoisen tärkeää. Siksi panostamme kattaviin integraatiotesteihin. Nämä testit varmistavat, että kaikki järjestelmän osat toimivat saumattomasti yhteen ja että muutokset yhdessä osassa eivät aiheuta odottamattomia ongelmia toisaalla. Kun testit ovat tällä tasolla kunnossa voi integraatioon luottaa täysin eri tavalla ja tulevatkin muutostarpeet saadaan luotettavasti vietyä läpi.

4. Päivittäinen tehtävien synkronointi

Tiimimme kommunikoi tehokkaasti käyttämällä Kanban-taulua. Käymme päivittäin läpi jokaisen tehtävän statuksen, mikä auttaa meitä pysymään ajan tasalla projektin etenemisestä ja mahdollisista pullonkauloista. Tämä käytäntö edistää läpinäkyvyyttä ja mahdollistaa nopean reagoinnin haasteisiin.

5. Säännöllinen asiakaskommunikaatio

Pidämme asiakkaan tiiviisti mukana kehitysprosessissa kommunikoimalla viikkotasolla. Tämä varmistaa, että pysymme linjassa asiakkaan odotusten kanssa ja voimme nopeasti mukautua mahdollisiin muutoksiin vaatimuksissa tai prioriteeteissa.

Näiden viiden periaatteen avulla olemme Devikoneella onnistuneet luomaan tehokkaan ja joustavan agile-integraatiokehityksen prosessin. Tämä lähestymistapa ei ainoastaan paranna kehitystyömme laatua ja nopeutta, vaan myös lisää asiakastyytyväisyyttä ja tiimimme työtyytyväisyyttä.

Optimaalinen integraatioiden projektinhallintametodologia

Perinteisessä ohjelmistokehityksessä käytetty projektinhallintametodologia Scrum ei sovellu hyvin integraatioiden rakentamiseen. Scrumin oletuksena on, että jokaisen sprintin jälkeen asiakas saa käyttöönsä sovelluksesta päivitetyn version, joka tuottaa uutta lisäarvoa. Scrumin sprinteissä kehitetään lisää ominaisuuksia, joten Scrum toimii hyvin suhteessa perinteiseen ohjelmistokehitykseen. Integraatiot ovat kuitenkin binäärisempiä; ne joko toimivat tai eivät. Osittain toiminnassa olevat ja osissa tuotettavat integraatiot ovat ääriharvinaisia. Millainen sitten on optimaalinen integraatioiden projektinhallintametodologia?

Scrum ei siis ole optimaalinen integraatioiden projektinhallintametodologia. "Vesiputousmallin" perustana taas on ohjelmiston tarkka suunnittelu. Tämä on myös integraatioiden kanssa oleellista. Vesiputousmallilla on kuitenkin tapana epäonnistua katastrofaalisesti toteutusvaiheessa. Kuitenkin yhdistämällä tämän suunnitteluun liittyvän johtoajatuksen ketteriin menetelmiin saavutetaan jotain mikä toimii erittäin hyvin integraatioiden kanssa.

Scrum ja Kanban yhdessä

Devikoneen käyttämä menetelmä on käytännössä Scrum-menetelmän ja Kanban-menetelmän yhdistelmä, joka poimii molemmista menetelmistä ominaisuuksia. Scrumista poimitaan päivittäiset palaverit ja Kanbanista tehtävien visuaalinen hallintataulu, jolla seurataan työn etenemistä. Karkealla tasolla taulu näyttää, mitä töitä on tekeillä, mitkä ovat valmiina ja mitkä ovat vielä aloittamatta. Taulu on jaettu asiakaskohtaisiin osioihin. Jokaisella asiakkaalla on eri määrä integraatioita työn alla tai monitoroitavana. Taulut käydään päivittäin läpi ko. asiakkuudessa toimivan Devikoneen asiantuntijan kanssa ja päivitetään työn alla olevien tehtävien status ja käydään läpi mikäli vastaan on tullut mahdollisia ongelmatilanteita.

Tehtävien standardisointi

Integraatioiden toteutukseen liittyy oleellisesti tehtävien standardisointi, ja tietyt oletetut asiat tuodaan tehtävienhallintatauluun kun integraatiota aletaan rakentamaan. Esimerkiksi integraation suunnittelu ja teknisten yhteyksien testaaminen tehdään ennen toteutustehtäviä. Tehtäviin liittyy myös integraation käynnistymiseen liittyvä osuus, prosessiohjauskerros, tietojen yhteensovittaminen (datamäppäys) ja kirjoittaminen kohdejärjestelmään. Näistä eri kerroksista voidaan muodostaa pienempiä tehtäviä tarpeen mukaisesti kun tilanne tarkentuu.

Työmääräarviot

Integraation vaatima työmäärä on yleensä arvioitu ennen toteutuksen aloittamista, ja eri vaiheisiin kuluva aika on usein melko hyvin tiedossa ja ennustettavissa. Osana projektinhallintaa seurataan toteutuneita työtunteja suhteessa asiakkaalle annettuun arvioon, ja jos huomataan mahdollista heittoa, voidaan tästä asiakasta varoittaa jo etukäteen. Tällaisiä tilanteita tulee erityisesti silloin kun suunnittelua on jouduttu tekemään puutteellisilla tiedoilla, ja näissä tapauksissa asiakkaalle onkin ilmoitettu työmääräarvio ajallisena haarukkana, esim. 10-13 htp.

Viikkopalaverit

Asiakkaan kanssa sovimme yleensä viikottaiset seurantapalaverit, jolloin Devikone mm. informoi asiakasta miten integraatio on edistynyt ja missä olemme suhteessa aikatauluun ja budjettiin. Asiakkaalla on mahdollisuus esittää kysymyksiä ja myös muutospyyntöjä integraation toimintoihin.

Laadunhallinta mukaan

Jotta voidaan saavuttaa optimaalinen integraatioiden projektinhallintametodologia, uskomme että taustalla pitää olla myös tiukat laatuun liittyvät standardit. Devikoneen projektinhallinnan rinnalla kulkee laadunhallintaan liittyvä metodologia, mikä varmistaa että Devikoneen tuottamat integraatiot sisältävät kaikki sovitut asiat laadukkaasti toteutettuina. Kun projektinhallinta ja laadunhallinta ovat kytketty yhteen syntyy toimivia, luotettavia ja aikaa kestäviä integraatioita.

Kirjoitimme myös, mitkä ovat Agile-integraatiokehityksen avaimet, joten siitä kannattaa jatkaa!

Yrityksen täsmäkielellä lisää kilpailuetua

Devikoneella teemme töitä "domain spesifien kielten" (DSL, tai täsmäkieli) kanssa, mutta mitä nämä ovat ja mitä etua niillä saavutetaan verrattuna yleisiin ohjelmointikieliin ja mitä hyötyä niistä on asiakkaillemme?

DSL:ät ovat ohjelmointikieliä, jotka on suunniteltu tiettyyn sovellusalueeseen (domain) tai -käyttötarkoitukseen. DSL:llä voidaan esimerkiksi kuvata tiettyjä prosessien vaiheita tai määritellä tiettyjä käsitteitä ja rakenteita. Ne ovat yleensä yleisiä ohjelmointikieliä selkeämpiä ja tarkemmin määriteltyjä, ja niiden avulla voidaan ratkaista tehtäviä tehokkaammin ja luotettavammin. Tämä tekee niistä helpommin ymmärrettäviä ja käytettäviä ihmisille, jotka ovat erikoistuneet tiettyyn sovellusalueeseen tai -tehtävään.

Alla on esimerkki DSL:stä, jollainen voidaan rakentaa Devikoneen kielialustan päälle:

Suorita:
Tee vastaanotto: {rahti: 12400}

  Jos virhe niin lähetä sähköposti: {to: "aspa@munlogistiikka.fi", body: "Rahdin vastaanotossa tapahtui virhe"};

  Muuten tee lokimerkintä: {rahti: 12400, vastaanotto: "OK"};

DSL:t tarjoavat useita laadullisia hyötyjä niitä käyttäville yrityksille:

DSL:ien kanssa ongelmia voi syntyä käytännössä lähinnä silloin kun yrittää ratkaista ongelmia joihin kieltä ei ole suunniteltu. Tällöin ratkaisuna on yhdistää eri kieliä, jolloin vaativatkin ongelmat saadaan ratkaistua.

Integraatiot ovat se ylätason sovellusalue, jossa teemme töitä. Tällä alueella pääasiallinen integraatiovälineemme on Apache Camel, joka toteuttaa integraatiospesifin kielen. Integraatioiden alla on kuitenkin myös muita sovellusalueita, joissa käytämme muita kieliä (esim. rajapintojen suunnitteluun ja niiden vastausten purkuun on omat hyvin tehokkaat kielensä). Tehokas toimintamme perustuu siihen, että osaamme hyödyntää erilaisia tehokkaita kielityökaluja tarpeen mukaisesti. Integraatiovälineenä Camel mahdollistaa hienosti eri kielien yhdistelyn, esim. yllä oleva esimerkki DSL voidaan ajaa suoraan osana integraatiota.

Devikoneen kielialustan avulla voimme luoda kielityökalut joilla asiakkaan omat asiantuntijat voivat ratkaista nopeasti oman sovellusalueensa ongelmia. Tämä on erilainen lähestymistapa kuin perinteinen käyttöliittymäsuunnittelu- tai RPA-käyttöönottoprojekti. Esimerkkinä voimme rakentaa työkalun, joka auttaa käyttämään varastonhallintajärjestelmää lyhyillä tekstimuotoisilla komennoilla. Esim. rahdin saapumiskuittaksen voi tehdä yhdellä tekstimuotoisella komennolla, sen sijaan että muistelee ehkä monimutkaisen klikkailusekvenssin. Taustalla mahdollistajana ovat tietysti rajapintoja vasten rakennetut integraatiot. Annetut komennot voidaan tallentaa ja nähdä niihin liittyvän historialokin. Tämä lähestymistapa on mainio silloin kun lyhyemmistä komennoista halutaan muodostaa yhdistelemällä monimutkaisempia sarjoja, joita on kuitenkin helppo muuttaa ja yhdistellä uudelleen tapauskohtaisesti.

Integraatiot mahdollistavat yrityksen oman DSL:n rakentamisen. Kun integraatiot suunnitellaan alusta asti tämä asia mielessä (mikä ei ole itsestään selvää), on olemassa vahva pohja myös rakentaa yritykselle oma DSL-kieli, joka tuo kilpailuetua suhteessa muihin saman toimialan yrityksiin.

Kyseessä ei ole pelkkä RPA- tai integraatioprojekti

RPA (Robotic Process Automation) on ohjelmistojen käytön automatisointia ohjelmistorobottien avulla. Tällöin jokin työprosessin osa voidaan automatisoida ja käynnistää tietystä syötteestä. Integraatiot käynnistyvät samoin tietystä syötteestä ja toimivat taustalla täysin automaattisesti, usein siirtäen sanomia järjestelmien välillä. DSL-kielityökalun avulla ei kuitenkaan pyritä täyteen työnkulun automatisointiin, vaan tavoite on automatisoida yksittäisiä hyvin pieniä tehtäväpalasia. Ajatus on, että näistä pienistä palasista voidaan koota aina uuden näköisiä kokonaisuuksia kun palat yhdistellään eri tavoin. Yksittäinen tehtäväpalanen voidaan automatisoida monella eri tavalla (RPA, integraatio, skripti). Yritykselle DSL-kielityökalu on tehokkaampi ja enemmän arvoa tuottava tapa kuin RPA-toiminnot, sillä juuri tällainen kielen joustavuus antaa mahdollisuuden yrityksen omille asiantuntijoille määrittää nopeasti eri tehtäviin muuntuvia pieniä skriptejä. Skriptejä on helppo ylläpitää, versioida, muokata, kopioida ja ajaa.

Miten alkuun?

Käydään ensin yhdessä läpi onko tämä malli teille paras vaihtoehto tuottamaan lisäarvoa. Jos päädymme jatkamaan työtä, määritellään yhdessä asiantuntijoidenne kanssa ne tehtävät, joiden automatisointi kielityökalun avulla tuo hyötyä. Kun komennot on suunniteltu hyvin, on yrityksen omalle DSL:lle olemassa vahva pohja. Tämän päälle on helppo rakentaa muita työkaluja, jotka mahdollistavat Low-code ympäristön, jolloin komentoja voidaan kategorisoida, konfiguroida, yhdistellä ja ajaa myös visuaalisen käyttöliittymän kautta. Devikoneella on valmis kielialusta ja osaaminen joilla tällainen projekti saadaan nopeasti toteutettua. Mikäli käytössänne on jo jokin integraatiotyökalu, voimme hyödyntää olemassa olevia integraatiokulkuja, mahdollisesti hieman niitä muokkaamalla malliin sopivaksi, tai voimme hyödyntää tähän tarkoitukseen Devikoneen Kubernetes-pohjaista integraatioalustaa.