Teknologiaprofiili
Tekninen perustamme yhdellä silmäyksellä
Emme ota teknologioita käyttöön trendien mukaan, vaan käyttö- ja operointitodellisuuden, elinkaaren, integraatiotarpeen ja tiimin kyvykkyyden perusteella. Ratkaisevaa ei ole iskusana, vaan se, pysyykö järjestelmä myöhemmin siististi operoitavana, laajennettavana ja ylläpidettävänä.
Vahva liiketoimintalogiikassa ja monialustaisissa clienteissä
Delphi on vahva siellä, missä vuosien varrella kasvanutta liiketoimintalogiikkaa, tietokantaläheisiä prosesseja, raportointia ja vakaita Windows-, macOS- ja Linux-client-sovelluksia halutaan ylläpitää ja kehittää pitkäjänteisesti.
Katso Delphi
C#
Vahva REST-ratkaisuissa, palveluissa ja portaaleissa
Otamme C# käyttöön, kun portaalien, modernien backend-palvelujen, REST-API-rajapintojen ja integraatioiden tulee kytkeytyä siististi olemassa oleviin yritysjärjestelmiin.
Katso C#
Arkkitehtuuri
Layer-3 monoliittisen taakkaperinnön sijaan
Erottamme käyttöliittymän, liiketoimintalogiikan ja tietojen käsittelyn tietoisesti, jotta muutokset pysyvät ennakoitavina eikä uusia palveluja tarvitse rakentaa olemassa olevaa vastaan.
Katso Layer-3
Alustat
Windows 11 ARM64 huomioidaan heti alusta alkaen
Klassisten x64-kohteiden lisäksi huomioimme varhain ajankohtaiset alustat kuten Windows 11 ARM64, jotta uusi laitteisto ja käyttöönotot eivät muutu myöhemmin erillisprojektiksi.
Katso ARM64
Milloin mikäkin suunta on järkevä
Delphi on järkevä, kun
- olemassa olevan toiminnallisen logiikan pitää jatkaa elämäänsä,
- monimutkaisten työpöytäprosessien on pysyttävä vakaina,
- Windows-, macOS- ja Linux-client-sovelluksia halutaan rakentaa yhteisen toiminnallisen perustan päälle.
C# on järkevä, kun
- rakennetaan REST-palvelimia ja -palveluja,
- API-rajapinnat ja ulkoiset integraatiot ovat keskiössä,
- tarvitaan moderneja palveluarkkitehtuureja.
Hybridi on järkevä, kun
- olemassa olevien sovellusten ja uusien portaalien on toimittava yhdessä,
- työpöytä, palvelut ja web käyttävät samaa tietopohjaa,
- modernisointi tulee tehdä vaiheittain ja Layer-3-rakenteena.
Delphi-modernisointi käytännössä
Jos vanha Delphi-sovellus on toiminnallisesti edelleen arvokas, emme modernisoi sitä sokkona. Analysoimme ensin, miten järjestelmä todellisuudessa toimii, mitä prosesseja se kannattelee, missä tietovirrat katkeavat ja mitkä perintörasitteet hidastavat operointia. Tämän pohjalta syntyy modernisointipolku, joka ei näytä siistiltä vain paperilla, vaan kestää arjessa.
Monissa ajan myötä kasvaneissa sovelluksissa todellinen arvo ei ole käyttöliittymässä, vaan vuosien aikana kertyneessä toiminnallisessa logiikassa, erityissäännöissä, poikkeuksissa ja kokemusperäisessä tiedossa. Tätä ydintä ei heitetä pois kevyin perustein. Erottamme vastuut selkeästi, järjestämme tietokannan uudelleen, korvaamme vanhat pääsytavat, luomme uudet REST-rajapinnat ja täydennämme tarvittaessa asiakkaat alustoille Windows, macOS ja Linux samalla toiminnallisella perustalla. Näin ei synny kova katkoksesta, vaan ymmärrettävä jatkokehitys selkeällä teknisellä rajauksella.
Usein tämä tarkoittaa myös sitä, että historiallisesti kasvaneet monoliitit tuodaan takaisin muotoon, joka on ylläpidettävä, testattava ja laajennettavissa. Datan käsittely vakautetaan, liiketoimintalogiikka irrotetaan käyttöliittymäkoodista, rajapinnoista tulee ennakoitavia eikä tulevia laajennuksia tarvitse enää taistella läpi olemassa olevan rakenteen kanssa. Tavoitteena ei ole kosmeettinen modernisointi, vaan järjestelmä, joka antaa yritykselle jälleen tilaa uusille vaatimuksille.
Services ja palvelimet osana samaa arkkitehtuuria
Monet yritysjärjestelmät tarvitsevat nykyään paitsi clientin, myös taustapalveluita, Windows- tai Linux-services-komponentteja sekä REST-serverin. Juuri siksi emme suunnittele näitä osia jälkikäteen lisättäväksi liitteeksi, vaan saman arkkitehtuurin osaksi. Service, joka vain myöhemmin jotenkin liitetään mukaan, päätyy lähes aina erikoistapaukseksi.
Kun dataa halutaan käsitellä hajautetusti, tarjota rajapintoja, ajaa vientitiedostoja, valvoa tuonteja tai suorittaa ajastettuja tehtäviä taustalla, tekninen vastuunjako on määriteltävä alusta alkaen. Mitkä osat toimivat clientissa, mitkä palvelussa, mitkä serverissä, miten virheet tulevat näkyviin, miten tilamuutokset tehdään jäljitettäviksi, miten toiminnallinen logiikka pysyy yhtenäisenä? Vastaamme näihin kysymyksiin varhain, jotta yksittäisistä rakennuspalikoista syntyy kestävällä tavalla toimiva kokonaisjärjestelmä.
Tämä on erityisen ratkaisevaa monialustaprojekteissa. Desktop-client Windows-, macOS- tai Linux-alustalla ei saa tarkoittaa toiminnallisesti jotain muuta kuin sitä täydentävä REST-server tai taustapalvelu. Siksi ajattelemme tietomallin, prosessit, oikeudet, integraatiot ja käytönvalvonnan aina yhdessä. Näin syntyy arkkitehtuuri, jossa clientit, services ja palvelimet puhuvat samaa kieltä.
Periaatteemme
Teknologia ei ole meille uskonkysymys. Ratkaisevaa on, että arkkitehtuuri, tiimissä tehtävä työ, operointi ja tulevat laajennukset sopivat yritykseen. Äänekkäin alusta ei voita, vaan se, jolla riskiä, ylläpidettävyyttä ja kasvua voidaan ohjata järkevästi.
Osan tehtävistä toteutamme tietoisesti Delphi:lla, koska siellä ajan myötä kertynyt business-logiikka, suorituskykyiset clientit ja monialustakyvykkyys pääsevät oikeuksiinsa. Toiset vaatimukset sopivat paremmin C#:ään, palveluihin, portaaliin tai näiden yhdistelmään. Hyvä arkkitehtuuri ei synny muodista, vaan selkeydestä: mikä vastuu kuuluu millekin järjestelmäosalle, millaista elinkaarta on odotettavissa, kuinka suuri tiimi on, kuinka kriittistä operointi on ja millaisia laajennuksia on realistisesti tulossa seuraavina vuosina?
Tästä alkaa meille ammattimainen ohjelmistokehitys. Emme halua toimittaa vain jotain, joka toimii tänään, vaan luoda teknisen perustan, joka on myöhemminkin ymmärrettävä, haltuun otettavissa ja taloudellisesti ylläpidettävissä.
Usein kysyttyjä kysymyksiä teknologiasta ja arkkitehtuurista
Teknologisten valintojen on sovittava tiimiin, toimialalogiikkaan ja tuotantokäyttöön. Juuri siksi emme käsittele näitä kysymyksiä abstraktisti, vaan aina konkreettisen järjestelmän kautta.
Milloin Delphi on järkevä vaihtoehto täydelle uudelleenplatformoinnille?
Aina silloin, kun vuosien aikana kasvanut toimialalogiikka, suorituskykyiset desktop-prosessit ja monialustatavoitteet halutaan säilyttää taloudellisesti järkevällä tavalla, sen sijaan että olemassa oleva substanssi korvattaisiin kevyin perustein.
Milloin otatte lisäksi käyttöön C#?
Ennen kaikkea portaaleihin, web-backendeihin, REST-palveluihin, integraatioihin ja palveluorientoituneen arkkitehtuurin osiin, jotka voidaan kytkeä hyvin olemassa oleviin desktop-järjestelmiin.
Kuinka tärkeä Layer-3 on käytännössä?
Erittäin. Vasta UI:n, liiketoimintalogiikan ja tietojen käsittelyn selkeä erottelu tekee modernisoinnista, testauksesta, palveluista ja tulevista alustasiirtymistä hallittavia.
Huomioitteko uudet alustat kuten Windows 11 ARM64 jo varhaisessa vaiheessa?
Kyllä. Uusi kohdelaitteisto ja deployment-polut arvioidaan varhain, jotta niistä ei myöhemmin synny kalliita erityisprojekteja.
Lue lisää koottuja kysymyksiä
Nämä lyhyet vastaukset säilyvät täällä sivulla. Keskus-FAQ-landingpagella jäsennämme aiheen lisäksi arkkitehtuurin, modernisoinnin, alustojen ja käytön kontekstissa.