Emme käytä teknologioita muodin mukaan, vaan käyttörealiteettien, elinkaaren, integraatiotarpeen ja tiimin osaamisen perusteella. Tärkeää ei ole iskusana, vaan se, säilyykö järjestelmä myöhemmin siististi ylläpidettävänä, laajennettavana ja siirrettävänä.
Vahva liiketoimintalogiikalle ja monialustaisille asiakasohjelmille
Delphi on vahvoilla siellä, missä kehittynyt liiketoimintalogiikka, tietokantaläheiset prosessit, raportit ja vakaat asiakasohjelmat kuten Windows, macOS ja Linux halutaan ylläpitää pitkällä aikavälillä.
Katso Delphi
C#
Vahva REST palveluille ja portaaleille
C# käytämme, kun portaalit, modernit backend-palvelut, REST-APIt ja integraatiot pitää liittää siististi olemassa oleviin yritysjärjestelmiin.
Katso C#
Arkkitehtuuri
Layer-3 statt monolithischer Altlast
Erotamme käyttöliittymän, liiketoimintalogiikan ja tietojen käytön tietoisesti, jotta muutokset pysyvät ennakoitavina eikä uusia palveluja tarvitse rakentaa olemassa olevan järjestelmän kustannuksella.
Katso Layer-3
Alustat
Otamme Windows 11 ARM64 heti huomioon
Perinteisten x64-kohteiden lisäksi huomioimme varhain nykyiset alustat, kuten Windows 11 ARM64, jotta uusi laitteisto ja käyttöönotot eivät myöhemmin muutu erillisprojektiksi.
Katso ARM64
Milloin mikä lähestymistapa on järkevä
Delphi on järkevä, kun
- olemassa oleva liiketoimintalogiikka halutaan säilyttää,
- monimutkaiset työpöytäprosessit täytyy pitää vakaana,
- Windows-, macOS- ja Linux-asiakasohjelmat halutaan rakentaa yhteiselle toiminnalliselle pohjalle.
C# on järkevä, kun
- REST-palvelimet ja palvelut rakennetaan,
- APIt ja ulkoiset integraatiot ovat keskiössä,
- tarvitaan nykyaikaisia palveluarkkitehtuureja.
Hybrid on järkevä, kun
- olemassa olevat sovellukset ja uudet portaalit täytyy saada toimimaan yhdessä,
- työpöytä, palvelut ja web hyödyntävät samaa tietopohjaa,
- modernisointi toteutetaan vaiheittain ja Layer-3-rakenteena.
Delphi-modernisointi käytännössä
Kun vanha Delphi-sovellus on toiminnallisesti yhä arvokas, emme modernisoi sokkona. Analysoimme ensin, miten järjestelmä todellisuudessa toimii, mitä prosesseja se kantaa, missä tietovirrat katkeavat ja mitkä perintöongelmat hidastavat käyttöä. Tästä muodostuu modernisointipolku, joka ei näytä hyvältä vain paperilla, vaan on myös arjessa kestävä.
Monissa pitkäikäisissä sovelluksissa todellinen arvo ei ole käyttöliittymässä vaan vuosien aikana kertyneessä liiketoimintalogiikassa, erityissäännöissä, poikkeuksissa ja kokemustiedossa. Tätä substanssia ei hävitetä kevyesti. Erottamme vastuut selkeästi, järjestämme tietokannan uudelleen, korvaamme vanhat pääsypolut, luomme uusia REST-rajapintoja ja tarvittaessa täydentämme Windows-, macOS- ja Linux-asiakasohjelmia samalla toiminnallisella pohjalla. Näin ei synny jyrkkää katkoa, vaan jäljitettävä jatkokehitys selkeällä teknisellä rakenteella.
Usein tämä tarkoittaa myös historiallisesti muodostuneiden monoliittien saattamista muotoon, joka on ylläpidettävissä, testattavissa ja laajennettavissa. Tietojen käyttö vakautetaan, liiketoimintalogiikka irrotetaan käyttöliittymäkoodista, rajapinnat tehdään suunniteltaviksi, eikä tulevia laajennuksia tarvitse enää taistella olemassaolon kanssa. Tavoitteena ei ole kosmeettinen modernisointi, vaan järjestelmä, joka antaa yritykselle tilaa uusille vaatimuksille.
Palvelut ja palvelimet osana samaa arkkitehtuuria
Monet yritysjärjestelmät tarvitsevat nykyään muutakin kuin yhden asiakasohjelman: taustapalveluita, Windows- tai Linux-palveluja sekä REST-palvelimia. Siksi suunnittelemme nämä osat ei jälkiasennuksena, vaan osana samaa arkkitehtuuria. Palvelusta, joka liitetään mukaan vasta myöhemmin, tulee lähes aina poikkeustapaus.
Kun dataa käsitellään hajautetusti, rajapintoja tarjotaan, vientiä ajetaan, tuontia valvotaan tai tehtäviä suoritetaan ajoitetusti taustalla, tekninen vastuu on selvitettävä alusta lähtien. Mitkä osat ajetaan asiakasohjelmassa, mitkä palvelussa, mitkä palvelimella, miten virheet näkyvät, miten tilamuutokset ovat jäljitettävissä ja miten toiminnallinen logiikka pysyy konsistenttina? Näihin kysymyksiin annamme vastaukset varhain, jotta yksittäisistä osista muodostuu kestävä ja luotettava kokonaisjärjestelmä.
Tämä on erityisen tärkeää monialustaprojekteissa. Työpöytäasiakasohjelma (esim. Windows, macOS tai Linux) ei saa toiminnallisesti tarkoittaa eri asiaa kuin sitä tukeva REST-palvelin tai taustapalvelu. Siksi suunnittelemme datamallin, prosessit, käyttöoikeudet, integraatiot ja käytön aina yhdessä. Näin syntyy arkkitehtuuri, jossa asiakasohjelmat, palvelut ja palvelimet puhuvat samaa kieltä.
Periaatteemme
Teknologia ei ole meille uskomusasia. Ratkaisevaa on, että arkkitehtuuri, tiimin kyvykkyys, käyttö ja tulevat laajennukset soveltuvat yrityksen tarpeisiin. Ei äänekkäin alusta voita, vaan se, jonka avulla riskiä, ylläpidettävyyttä ja kasvua voidaan ohjata järkevästi.
Joihinkin tehtäviin valitsemme tietoisesti Delphi, koska siellä vuosien aikana kertynyt liiketoimintalogiikka, suorituskykyiset asiakasratkaisut ja monialustaisuus pääsevät oikeuksiinsa. Toiset vaatimukset sopivat paremmin C#, palveluiden, portaalin tai näiden yhdistelmän varaan. Hyvä arkkitehtuuri ei synny trendistä vaan selkeydestä: mikä järjestelmäosa kantaa minkä vastuun, millainen elinkaari on odotettavissa, kuinka suuri tiimi on, kuinka kriittinen käyttö on ja millaisia laajennuksia on realistista odottaa seuraavina vuosina?
Tästä lähtee ammatillinen ohjelmistokehityksemme. Emme pyri vain toimivaan toimitukseen tänään, vaan tekniseen perustaan, joka on myöhemmin ymmärrettävissä, siirrettävissä ja taloudellisesti ylläpidettävissä.
Usein kysyttyjä kysymyksiä teknologiasta ja arkkitehtuurista
Teknologiset päätökset on sovitettava tiimiin, toiminnallisuuteen ja ylläpitoon. Siksi emme käsittele näitä kysymyksiä abstraktisti, vaan aina konkreettisen järjestelmän yhteydessä.
Milloin Delphi on tarkoituksenmukainen verrattuna täysin uuteen alustaan?
Aina silloin, kun olemassa oleva liiketoimintalogiikka, suorituskykyiset työpöytäprosessit ja monialustaiset tavoitteet on taloudellisesti järkevämpää edelleen hyödyntää kuin korvata hätiköiden.
Milloin otatte lisäksi käyttöön C#?
Etenkin portaalien, web-backendien, REST-palveluiden, integraatioiden ja palvelukeskeisten arkkitehtuurikomponenttien yhteydessä, jotka integroituvat hyvin olemassa oleviin työpöytäjärjestelmiin.
Kuinka tärkeä Layer-3 on käytännössä?
Erittäin. Vasta käyttöliittymän, liiketoimintalogiikan ja datan käytön selkeä erottelu tekee modernisoinnista, testauksesta, palveluista ja tulevista alustanvaihdoista hallittavia.
Otatteko uudet alustat kuten Windows 11 ARM64 huomioon varhaisessa vaiheessa?
Kyllä. Uusi kohdelaitteisto ja käyttöönoton polut kartoitetaan aikaisin, jotta niistä ei muodostu myöhemmin kalliita erillishankkeita.
Lue lisää kysymyksiä koottuna
Nämä lyhyet vastaukset pysyvät tällä sivulla. Keskisellä FAQ-kohdesivulla asetamme aiheen lisäksi kontekstiin suhteessa arkkitehtuuriin, modernisointiin, alustoihin ja ylläpitoon.