Teknologiaprofiili
Tekninen perustamme yhdellä silmäyksellä
Emme valitse teknologioita trendien mukaan, vaan käyttöympäristön realiteettien, elinkaaren, integraatiotarpeiden ja tiimin osaamisen perusteella. Ratkaisevaa ei ole iskusana, vaan se, säilyykö järjestelmä myöhemmin siististi operoitavana, laajennettavana ja ylläpidon kannalta siirrettävänä.
Vahva liiketoimintalogiikassa ja monialustaisissa client-sovelluksissa
Delphi on vahva siellä, missä vuosien myötä kertynyt liiketoimintalogiikka, tietokantaläheiset prosessit, raportit ja vakaat clientit Windows-, macOS- ja Linux-ympäristöihin halutaan viedä eteenpäin pitkäjänteisesti.
Katso Delphi
C#
Vahva REST-ratkaisuissa, palveluissa ja portaaleissa
C# otamme käyttöön, kun portaalit, modernit backend-palvelut, REST-API:t ja integraatiot pitää liittää siististi olemassa oleviin yritysjärjestelmiin.
Katso C#
Arkkitehtuuri
Layer-3 monoliittisen perintötaakan sijaan
Erotamme käyttöliittymän, liiketoimintalogiikan ja tietokantakäytön tietoisesti, jotta muutokset pysyvät suunniteltavina eikä uusia palveluja tarvitse rakentaa olemassa olevaa vastaan.
Katso Layer-3
Alustat
Windows 11 ARM64 huomioidaan heti alusta alkaen
Perinteisten x64-kohteiden lisäksi huomioimme varhain ajankohtaiset alustat kuten Windows 11 ARM64, jotta uusi laitteisto ja käyttöönotot eivät muutu myöhemmin erilliseksi erityisprojektiksi.
Katso ARM64
Milloin mikäkin suunta on järkevä
Delphi on järkevä, kun
- olemassa olevan liiketoimintalogiikan pitää jatkaa elämäänsä,
- monimutkaisten desktop-prosessien on pysyttävä vakaina,
- Windows-, macOS- ja Linux-clientit halutaan rakentaa yhteiselle toiminnalliselle perustalle.
C# on järkevä, kun
- rakennetaan REST-palvelimia ja -palveluja,
- API:t ja ulkoiset integraatiot ovat keskiössä,
- tarvitaan moderneja palveluarkkitehtuureja.
Hybridi on järkevä, kun
- olemassa olevien sovellusten ja uusien portaaleiden on toimittava yhdessä,
- desktop, palvelut ja web käyttävät samaa tietopohjaa,
- modernisointi halutaan toteuttaa vaiheittain ja Layer-3-rakenteena.
Delphi-modernisointi käytännössä
Kun vanha Delphi-sovellus on toiminnallisesti edelleen arvokas, emme modernisoi sitä sokkona. Analysoimme ensin, miten järjestelmä oikeasti toimii, mitä prosesseja se kantaa, missä tietovirrat katkeavat ja mitkä perintötaakat jarruttavat käyttöä. Tämän pohjalta syntyy modernisointipolku, joka ei näytä siistiltä vain paperilla, vaan kestää arjessa.
Monissa vuosien varrella kasvaneissa sovelluksissa varsinainen arvo ei ole käyttöliittymässä, vaan vuosien aikana kertyneessä liiketoimintalogiikassa, erityissäännöissä, poikkeuksissa ja kokemustiedossa. Tätä substanssia ei heitetä pois kevyin perustein. Erottamme vastuut selkeästi, jäsennämme tietokannan uudelleen, korvaamme vanhat käytännöt tiedonhakemiseen, luomme uusia REST-rajapintoja ja täydennämme tarvittaessa asiakkaat kohteille Windows, macOS ja Linux samalla liiketoiminnallisella perustalla. Näin ei synny kovaa katkoa, vaan ymmärrettävä jatkokehitys, jossa tekninen rajaus on selkeä.
Usein tämä tarkoittaa myös sitä, että historiallisesti kasvaneet monoliitit saatetaan 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ää vääntää väkisin olemassa olevaa vastaan. Tavoite ei ole kosmeettinen modernisointi, vaan järjestelmä, joka antaa yritykselle jälleen liikkumatilaa uusille vaatimuksille.
Palvelut ja palvelin osana samaa arkkitehtuuria
Monet yritysjärjestelmät tarvitsevat nykyään asiakkaan lisäksi myös taustapalveluja, Windows- tai Linux-services-komponentteja ja REST-server-komponentteja. Juuri siksi emme suunnittele näitä osia jälkikäteen lisättäväksi liitteeksi, vaan saman arkkitehtuurin osaksi. Palvelu, joka tulee mukaan vasta myöhemmin “jotenkin”, muodostuu lähes aina poikkeustapaukseksi.
Kun dataa käsitellään hajautetusti, rajapintoja tarjotaan, vientejä ajetaan, tuonteja valvotaan tai tehtäviä suoritetaan ajastetusti taustalla, tekninen vastuu on määriteltävä alusta alkaen. Mitkä osat toimivat clientissä, mitkä palvelussa, mitkä serverissä, miten virheet tehdään näkyviksi, miten tilamuutokset ovat jäljitettävissä, miten liiketoimintalogiikka pysyy yhdenmukaisena? Vastaamme näihin kysymyksiin varhain, jotta yksittäisistä rakennuspalikoista muodostuu kestävä kokonaisjärjestelmä.
Tämä on ratkaisevaa erityisesti monialustaprojekteissa. Desktop-client kohteessa Windows, macOS tai Linux ei saa liiketoiminnallisesti tarkoittaa jotain muuta kuin sitä tukeva REST-server tai taustapalvelu. Siksi ajattelemme aina tietomallin, prosessit, käyttöoikeudet, integraatiot ja operoinnin kokonaisuutena. Näin syntyy arkkitehtuuri, jossa clientit, services-komponentit ja server puhuvat samaa kieltä.
Periaatteemme
Teknologia ei ole meille uskonkysymys. Ratkaisevaa on, että arkkitehtuuri, tiimin toimivuus, 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.
Joihinkin tehtäviin valitsemme tietoisesti Delphi-ratkaisun, koska siellä pitkään kehittynyt liiketoimintalogiikka, suorituskykyiset clientit ja monialustakyvykkyys pääsevät vahvuuksiinsa. Toiset vaatimukset sopivat paremmin C#-ratkaisuihin, services-komponentteihin, portaaliin tai näiden yhdistelmään. Hyvä arkkitehtuuri ei synny muodista, vaan selkeydestä: mikä vastuu kuuluu millekin järjestelmän osalle, millaista elinkaarta voidaan odottaa, kuinka suuri tiimi on, kuinka kriittistä operointi on ja millaisia laajennuksia on realistista odottaa seuraavina vuosina?
Juuri tästä meille alkaa ammattimainen ohjelmistokehitys. Emme halua toimittaa vain jotain, joka toimii tänään, vaan luoda teknisen perustan, joka on myöhemminkin ymmärrettävä, siirrettävissä ja taloudellisesti ylläpidettävissä.
Usein kysyttyjä kysymyksiä teknologiasta ja arkkitehtuurista
Teknologisten päätösten on sovittava tiimiin, substanssiin ja operointiin. Juuri siksi emme käsittele näitä kysymyksiä abstraktisti, vaan aina konkreettisen järjestelmän pohjalta.
Milloin Delphi on järkevä valinta verrattuna kokonaan uuteen alustaan?
Aina silloin, kun vuosien mittaan kertynyt toiminnallinen logiikka, suorituskykyiset työpöytäprosessit ja monialustatavoitteet halutaan jatkaa kustannustehokkaasti sen sijaan, että olemassa oleva perusta korvataan kevyin perustein.
Milloin otatte lisäksi käyttöön C#?
Erityisesti portaaleihin, web-taustajärjestelmiin, REST-palveluihin, integraatioihin ja palvelukeskeisiin arkkitehtuuriosiin, jotka on helppo kytkeä toimimaan yhteen olemassa olevien työpöytäjärjestelmien kanssa.
Kuinka tärkeä Layer-3 on käytännössä?
Erittäin. Vasta UI:n, liiketoimintalogiikan ja tietojen käsittelyn siistin erottelun avulla modernisointi, testaus, palvelut ja tulevat alustavaihdokset pysyvät hallittavina.
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 erillisprojekteja.
Lue lisää kysymyksiä koottuna
Nämä lyhyet vastaukset pysyvät täällä sivulla. Keskus-FAQ-landingpagella jäsennämme aiheen lisäksi osaksi kokonaisuutta arkkitehtuurin, modernisoinnin, alustojen ja operoinnin näkökulmasta.