Alusta ja tekninen hallinta

Lähestymistapamme on koodilähtöinen low-code, ei ”mustan laatikon” low-code.

Alustassa on kahdenlaista koodia: peruskoodia (uudelleenkäytettävät komponentit ja palvelut) ja automaattisesti generoitua projektikoodia. On tärkeää huomata, että kaikki koodi (perus- tai generoitu koodi) on alun perin ohjelmistokehittäjien kirjoittamaa. Kehittäjä toteuttaa ensin komponentin, moduulin tai palvelun sisäisen koodityylimme ja alan standardien mukaisesti, minkä jälkeen se katselmoidaan ja testataan. Sen jälkeen komponentti muunnetaan käsin malliksi, joka soveltuu generaattorille ja sovellusmalliin sisällytettäväksi.

Asiakasratkaisun ensimmäisen käyttöönoton aikana (tyypillisesti noin 20–40 minuuttia) generaattori mukauttaa (refaktoroi) mallikoodin vastaamaan asiakasprojektia (esim. nimeäminen, etuliitteet, nimiavaruudet, tekijänoikeusotsakkeet jne.). Osana tätä prosessia komponentista tai mallista tuotetaan kopio, joka tallennetaan erilliseen, juuri kyseistä asiakasta ja projektia varten luotuun omaan repositorioon. Tämä refaktoroitu kopio noudattaa samoja koodistandardeja ja samaa koodityyliä, ja se on käytettävissä manuaaliseen kehitykseen ja muutoksiin käyttöönoton jälkeen.

Automaattisesti generoitu koodi on käytettävissä virheenjäljitykseen ja laajentamiseen (esim. osittaisten luokkien ja periytymisen avulla), ja se pysyy luettavana ja standardien mukaisena.

Esimerkkejä automaattisesti generoidusta koodista (valtaosa):

• Frontendin TypeScript-mallit, jotka generoidaan C#-taustajärjestelmän tietomalleista ja rajapinnoista
• Frontendin lokalisoinnin apuvälineet (käännösmuuttujat), joita monikielinen käyttöliittymä edellyttää
• Perusapu- ja muunnosluokat yleisiä käyttöliittymäesityksiä varten (merkkijonot, listan alkiot jne.)

Esimerkkejä (uudelleenkäytettävästä) peruskoodista:

• AuthService – tunnistautuminen ja valtuutus
• NotificationService – ilmoitukset (sähköposti, tekstiviesti, push-ilmoitukset, sovelluksen sisäiset ilmoitukset)
• FileService – tiedostojen ja kuvien tallennus ja hallinta
• SyncService – uudelleenkäytettävät integraatiomekanismit ERP-järjestelmiin liittymistä varten (ml. synkronointimallit)

Täsmennyksiä (riskien pienentäminen)

Ei ajonaikaista ”taikuutta”

Koodin generointi tapahtuu pystytyksen ja toteutuksen aikana; tuloksena on tavallinen koodikanta, ei suljetun moottorin sisällä ajettavaa piilotettua logiikkaa.

Ylläpidettävyys

Generoitu ja refaktoroitu koodi noudattaa yhtenäistä koodityyliä ja yhtenäisiä arkkitehtuurikäytäntöjä.

Turvalliset laajennuskohdat

Laajennamme ratkaisua vakiomekanismeilla (osittaiset luokat, periytyminen, erilliset laajennustiedostot), jotta päivitykset tai uudelleengenerointi eivät korvaa asiakaskohtaista logiikkaa.

Mallissamme räätälöity kehitys alkaa heti projektin ensimmäisen käyttöönoton jälkeen.

Kun asiakas on rekisteröity ReApptor Portaliin, teemme ensimmäisen käyttöönoton (tyypillisesti noin 20–40 minuuttia). Sen aikana luomme täysin toimivan, eristetyn asiakasympäristön ja asiakaskohtaisen sovelluksen koodikannan:

• Koodi luodaan valittujen mallien ja moduulien refaktoroituna kopiona
• Kaikki tarvittavat CI/CD- ja käyttöönottoskriptit ovat mukana
• Kaikki tallennetaan erilliseen, juuri tätä asiakasta ja projektia varten luotuun omaan repositorioon

Siitä eteenpäin kehitystyö etenee kuten tavallisessa ohjelmistoprojektissa: kehittäjämme yhdistävät vasta luotuun asiakkaan repositorioon ja hakevat refaktoroidun projektikoodin. Kaikki myöhemmät muutokset toteutetaan asiakasprojektin koodikantaan, ja niitä hallitaan tavanomaisilla ohjelmistokehityksen käytännöillä (versionhallinta, koodikatselmointi, CI/CD, julkaisut).

Toisin sanoen käyttöönoton jälkeen emme enää ”konfiguroi mustan laatikon alustaa” – kehitämme ja viemme eteenpäin ratkaisuasi sen omassa repositoriossa ja ympäristössä.

Alusta on optimoitu transaktiopohjaisiin liiketoiminnan työnkulkuihin, kuten tilauksiin, tehtäviin, tarkastuksiin, dokumentteihin, työntekijöihin jne.

Sitä ei ole tarkoitettu:

• Reaaliaikaiseksi 3D-CAD-moottoriksi
• Täysimittaiseksi MES/PLC-ohjausjärjestelmäksi
• Yksinään raskaaksi datatieteen tai big datan analytiikka-alustaksi

Integroimme ratkaisun tarvittaessa tällaisiin järjestelmiin (esim. CAD, BI-työkalut, ERP), mutta emme pyri korvaamaan niitä.

Erikoistunut järjestelmä sopii paremmin, kun vaatimuksena on:

• Koneiden reaaliaikainen ohjaus millisekuntitasolla
• Erittäin monimutkainen, matalan tason CAD-käsittely selaimessa

Kaikessa, mikä liittyy tilaustenhallintaan, suunnitteluun, työmääräimiin, digitaalisiin laatutarkastuksiin, dokumenttien käsittelyyn ja mobiilityöhön, monimutkaisuus on selvästi sen rajoissa, minkä alusta käsittelee tehokkaasti.

Mallissamme ei ole perinteisen low-coden kaltaista kovaa toiminnallista ”alustan kattoa”, koska käyttöönoton jälkeen ratkaisu toimii tavallisena, itsenäisenä koodikantana (kopioidut palvelut ja komponentit + asiakkaan repositorio). Emme toimi ”alustan ajonaikaisen laatikon” sisällä, joten ei ole toiminnallista ”kattoa”, jonka kohdalla alusta ei enää pystyisi tukemaan monimutkaisuutta.

Käytännössä kysymys kuuluu: missä vaiheessa ratkaisun tekemistä eivät enää pääosin nopeuta uudelleenkäytettävät moduulit ja mallit, vaan työ muuttuu pääosin räätälöidyksi kehitystyöksi – niin, että ratkaisu pysyy silti täysin tuettuna, skaalautuvana ja ylläpidettävänä?

Tämä piste saavutetaan vasta, kun vaatimukset siirtyvät ”liiketoimintajärjestelmän monimutkaisuudesta” (jota varten ratkaisumme on suunniteltu) erikoistuneisiin, tutkimus- ja kehitystason reunaehtoihin, esimerkiksi:

Optimointimoottorin laajuus

Jos tuotannonsuunnittelu kehittyy täysimittaiseksi rajoiteratkaisijaksi, jossa on jatkuva automaattinen uudelleensuunnittelu ja monitavoiteoptimointi (ei pelkkä aikataulutus ja näkyvyys).

Äärimmäiset ei-toiminnalliset vaatimukset

Erittäin suuri samanaikaisuus ja läpimeno yhdistettynä tiukan reaaliaikaisiin käyttöliittymäpäivityksiin ja alle sekunnin vasteaikavaatimuksiin erittäin suuressa mittakaavassa.

Raskaat CAD- ja visuaalisen laskennan käsittelyketjut

Jos tarvitset suurten CAD-aineistojen palvelinpuolen renderöintiä, muuntamista ja käsittelyä ydinominaisuutena (piirustusten tallennuksen, versioinnin ja hyväksynnän lisäksi).

Näissäkin tapauksissa vastaus on edelleen ”voimme toteuttaa sen” – mutta käsittelemme sen erillisenä, nimenomaisesti rajattuna kehityskokonaisuutena, jolla on selkeät hyväksymiskriteerit ja suorituskykytestaus, jotta se ei huomaamatta kuluta budjettia tai aikataulua.

Tilauksiin, työtehtäviin, suunnittelunäkymiin, toimituksiin, tarkastuksiin, integraatioihin, tiedostojen käsittelyyn ja skaalautuvaan kasvuun liittyvät vaatimukset kuuluvat täsmälleen siihen luokkaan, jota varten alusta on rakennettu.

Teknisesti ratkaisu on tavallinen pilvinatiivi verkkosovelluspino, joka otetaan käyttöön asiakkaan omana ympäristönä:

Taustajärjestelmä

.NET (C#) ja relaatiotietokanta (MySQL / Aurora).

Frontend

React / TypeScript (verkko- ja mobiiliystävällinen käyttöliittymä).

Tiedostot (lomakkeet, tilaukset, piirustukset/CAD ja muut liitteet)

Tallennetaan objektitallennukseen (AWS S3) suoratoistoa ja allekirjoitettuja URL-osoitteita käyttäen (ei ”tiedostoja tietokannan kautta”).

Käyttöönotto

Kontitetut palvelut, joissa on horisontaalinen skaalaus, kuormantasaus ja tuotannon valvonta.

Tekoäly

Dokumenttien, puheen, videon, kuvien, auditointien ja piirustusten käsittelyyn sekä muihin älykkäisiin käsittely- ja automaatiotehtäviin käytetään sisäisten ja ulkoisten tekoälypalvelujen yhdistelmää.

Kapasiteetin näkökulmasta kaupalliseen malliimme kuuluvat ennalta määritellyt infrastruktuuritasot (Standard / Medium / Extra), joiden sovelluskohtainen kuukausikustannus on ennustettava ja riippuu tasosta.

Tyypillisellä aloituslaajuudella ja suuntaa-antavilla kapasiteettioletuksilla (yksi maa, alle 1 000 aktiivista käyttäjää ja alle 1 000 000 tilausta vuodessa) suosittelemme Standard-tasoa. Jos määrät kasvavat, voit nostaa tasoa muuttamatta sovellusarkkitehtuuria. Hinta on kiinteä sovitun kauden ajan.

Kyllä. Kaikkia ympäristöjä valvotaan jatkuvasti (infrastruktuurin ja sovelluksen mittarit), mukaan lukien resurssien käyttöaste, vasteajat, tietokannan kuorma sekä tiedostojen ja tallennustilan käyttö. Voimme jakaa vertailutietojen tilannekuvia ja trendiraportteja vastaavista tuotantojärjestelmistä (NDA:n nojalla).

Tuotantoesimerkkejä (Standard-taso)

Terveydenhuollon tilaukset

Resurssien keskimääräinen käyttöaste noin 30 %; 494 496 tilausriviä; 582 aktiivista käyttäjää; 9 338 eri tuotetta; 96 809 valikoimaa; 84 215 tiedostoa; 330 asiakastoimipistettä (sairaalat).

Lipunmyynti ja varaukset

Resurssien keskimääräinen käyttöaste noin 10 %; 1 517 varausta; 4 737 matkustajaa; 5 112 aktiivista käyttäjää.

Satamapalvelujen ja tehtävien hallinta

Resurssien keskimääräinen käyttöaste noin 3 %; 3 358 palvelua; 363 aktiivista käyttäjää; 6 451 dokumenttia.

Hissipaneelien valmistus

34 774 tilausta; 953 tuoteryhmää; 9 659 tuotevalikoimaa.

Teknistä velkaa hallitaan kuten missä tahansa ammattimaisessa ohjelmistotuotteessa:

• Jaetut alustamoduulit versioidaan ja testataan, ja niitä refaktoroidaan jatkuvasti
• Asiakaskohtainen logiikka on erillisissä repositorioissa, joissa on koodikatselmointi, automaattiset testit ja CI/CD
• Jokainen muutos on jäljitettävissä tikettiin (Jira) ja dokumentoitu

Low-code ei meidän tapauksessamme tarkoita ”ei koodia eikä hallintaa”; se tarkoittaa, että vähennämme päällekkäisyyttä ja keskitämme yleiset mallit, jolloin velka on helpompi havaita ja hallita.

Kaikki räätälöity koodi on:

• Tavallista C# / .NET- ja React / TypeScript -koodia
• Järjestetty selkeäksi kerrosarkkitehtuuriksi
• Ylläpidetty tavallisessa Git-repositoriossa (Bitbucket)
• Dokumentoitu koodin ja ratkaisun tasolla

Käytössä ei ole suljettua skriptikieltä, jota vain ReApptor ymmärtää.

Koska kaikki generoitu koodi tuotetaan malleista, jotka ohjelmistokehittäjät ovat alun perin kirjoittaneet, se noudattaa samaa sisäistä koodityyliä ja samoja kehitysstandardeja kuin käsin kirjoitettu koodi.

Alustan toiminnalliset päivitykset ja tietoturvapäivitykset viedään asiakasratkaisuun vain hallitun, manuaalisesti hyväksytyn julkaisuprosessin kautta: muutos dokumentoidaan Jiraan, katselmoidaan ja hyväksytään, testataan testi- ja staging-ympäristöissä, regressiotestataan ja julkaistaan sen jälkeen tuotantoon uudella käyttöönotolla.

Noudatamme versioitua, taaksepäin yhteensopivaa julkaisutapaa:

• Alustakirjastot julkaistaan versioituina paketteina (NuGet / npm).
• Yhteensopivuuden rikkovia muutoksia vältetään, ja jos niitä joskus tarvitaan, ne tuodaan vain pääversioissa.
• Asiakasratkaisut kiinnitetään tiettyihin alustaversioihin, ja ne päivitetään hallitusti.
• Uusi toiminnallisuus otetaan tyypillisesti käyttöön erikseen valitsemalla konfiguraation ja/tai ominaisuuslippujen avulla.

Näin voimme kehittää alustaa jatkuvasti ja pitää asiakaskohtaisen logiikan vakaana ja ennustettavana.

Alusta on jo tuotantokäytössä seuraavissa:

• Tilaus- ja tehtäväohjattu toiminta
• Huolto- ja kunnossapitotyönkulut
• Turvallisuusraportoinnin työnkulut
• Liikkuvat kenttätyöntekijät (esim. logistiikka, rakentaminen, terveydenhuolto)

Näissä ratkaisuissa on käytössä SLA:t, valvonta ja jatkuvat päivitykset.

Suurimpia käyttötapauksiamme ovat tällä hetkellä useita vuosia käytössä olleet operatiiviset järjestelmät, joissa on:

• Tuhansia loppukäyttäjiä ajan mittaan
• Satojatuhansia tilauksia ja tehtäviä
• Integraatiot ERP-järjestelmään ja muihin ydinjärjestelmiin

Yksi suurimmista asiakasratkaisuistamme on terveydenhuollon alalta, ja se on ollut tuotantokäytössä useita vuosia. Päivättyihin tuotantokäytön mittareihin voi tutustua NDA:n nojalla.

Voimme jakaa NDA:n nojalla konkreettisia asiakasreferenssejä ja anonymisoituja mittareita tarkemman kuvan antamiseksi.

Tekninen skaalautuvuus saavutetaan seuraavilla:

• Horisontaalisesti skaalautuvat sovellussolmut
• Erilliset tietokannat asiakas- ja sovelluskohtaisesti
• Erillinen pilven objektitallennus tiedostoille asiakas- ja sovelluskohtaisesti
• Taustatyöprosessit pitkäkestoisia ajoja varten

Arkkitehtuuri on suunniteltu niin, että jos asiakkaan volyymi kasvaa (enemmän tilauksia, enemmän työntekijöitä, enemmän asiakkaita), voimme laajentaa infrastruktuuria suunnittelematta sovellusta uudelleen.

Kaupallisen skaalautuvuuden malli on:

• Kiinteä kuukausittainen alusta- ja infrastruktuurimaksu
• Läpinäkyvät kehitysvaihtoehdot (kiinteä laajuus tai tilauspohjainen malli)
• Kolme lisenssiin sisältyvää pientä parannusta kuukaudessa aktiivisen kehitysvaiheen jälkeen

Kun käyttösi kasvaa, emme ota käyttöön käyttäjä- tai tilauskohtaisia lisämaksuja. Jos infrastruktuurikustannukset nousevat olennaisesti (esim. selvästi suurempien volyymien vuoksi), asia hoidetaan selkeiden kynnysarvojen ja keskustelujen kautta, ei yksipuolisilla muutoksilla.

Varmistamme taaksepäin yhteensopivuuden:

• Versioimalla rajapinnat ja tietorakenteet
• Tuomalla uudet ominaisuudet valinnaisina laajennuksina
• Ylläpitämällä migraatioskriptejä skeemamuutoksia varten

Asiakkaalle tämä tarkoittaa, että tulevina vuosina voimme:

• Lisätä uusia moduuleja
• Kehittää olemassa olevia näkymiä
• Parantaa suorituskykyä

Kaikki tämä ilman, että pakotamme häiritseviin uudelleensuunnitteluihin tai pitkiin muutoskatkoihin.

Lisäksi kuukausilisenssiin sisältyy aktiivisen kehitysvaiheen jälkeen kolme pientä parannusta tai ominaisuutta kuukaudessa, millä varmistetaan ratkaisun toiminnallisuuden ja liiketoiminta-arvon jatkuva ja ennustettava kasvu.

Voimme tarjota tuotantoreferenssejä ja läpikäyntejä (tarvittaessa NDA:n nojalla) kolmelta alueelta, jotka voidaan sovittaa asiakkaan vaatimuksiin:

• Tilaus- ja työnkulkuohjattu toiminta (tilaukset, tehtävät, roolipohjaiset käyttöliittymät, hyväksynnät, raportointi).
• Aikataulutus ja suunnittelu sekä operatiivinen toteutus (työmääräimet, tehtävien jako, kapasiteetin näkyvyys).
• Tarkastus-, laatu- ja huoltotyönkulut (vaiheittaiset tarkistuslistat valokuvineen ja kommentteineen, mobiili edellä toteutettu työ).

Esimerkkeinä ovat terveydenhuollon tarviketoimitusten työnkulut, kuluttajille suunnatut tilauskonfiguraattorit ja hintalaskurit muuttopalveluihin sekä operatiivinen tehtävien ja palvelujen hallinta satamapalveluille – kaikki tuotantokäytössä samalla alustaperustalla.