Teknologiaprofiili
Tekninen perustamme – yleiskatsaus
Delphi. C#. SQL. API:t.
Teknologiat, jotka sopivat liiketoimintalogiikkaan, dataan ja käyttöön.
Emme valitse teknologioita muodin mukaan, vaan käyttötodellisuuden, elinkaaren, integraatiovaatimusten ja tiimin kyvykkyyden perusteella. Ratkaisevaa ei ole iskusana, vaan se, säilyykö järjestelmä myöhemmin siististi ylläpidettävänä, laajennettavana ja siirrettävänä.
Vahva liiketoimintalogiikkaan ja monialustaisiin asiakassovelluksiin
Delphi on vahva siellä, missä vakiintunutta liiketoimintalogiikkaa, tietokantaläheisiä prosesseja, raportteja ja vakaita asiakassovelluksia halutaan ylläpitää pitkäjänteisesti Windows, macOS ja Linux-ympäristöissä.
Näytä Delphi
C#
Vahva REST-ratkaisuihin, palveluihin ja portaaliratkaisuihin
C# käytämme, kun portaalit, modernit backend-palvelut, REST-API:t ja integraatiot pitää liittää selkeästi olemassa oleviin yritysjärjestelmiin.
Näytä C#
Architektur
Layer-3 monoliittisen perintökuorman sijaan
Erotamme käyttöliittymän, liiketoimintalogiikan ja tietojen käytön tarkoituksellisesti, jotta muutokset pysyvät suunniteltavina eikä uusia palveluita tarvitse rakentaa olemassa olevan järjestelmän kustannuksella.
Näytä Layer-3
Plattformen
Windows 11 ARM64 huomioidaan alusta alkaen
Perinteisten x64-kohteiden lisäksi otamme varhaisessa vaiheessa huomioon nykyiset alustat kuten Windows 11 ARM64, jotta uusi laitteisto ja käyttöönotot eivät myöhemmin muutu erikoishankkeiksi.
Näytä ARM64
Milloin mikäkin suunta on järkevä
Delphi on perusteltu, kun
- olemassa oleva liiketoimintalogiikka halutaan säilyttää,
- monimutkaisten työpöytäprosessien on pysyttävä vakaina,
- Windows-, macOS- ja Linux-asiakassovellukset halutaan rakentaa yhteiselle toiminnalliselle pohjalle.
C# on perusteltu, kun
- REST-palvelimia ja palveluita rakennetaan,
- API:t ja ulkoiset integraatiot ovat keskiössä,
- modernit palveluarkkitehtuurit ovat tarpeen.
Hybridiratkaisu on perusteltu, kun
- olemassa olevat sovellukset ja uudet portaalit täytyy saada toimimaan yhdessä,
- työpöytä-, palvelu- ja web-komponentit käyttävät samaa tietopohjaa,
- uudistuksen tulee tapahtua vaiheittain ja Layer-3-rakenteena.
Delphi-modernisointi käytännössä
Kun vanha Delphi-sovellus on edelleen toiminnallisesti arvokas, emme modernisoi sokeasti. Analysoimme ensin, miten järjestelmä todellisuudessa toimii, mitkä prosessit se toteuttaa, missä tietovirrat katkeavat ja mitkä perintöongelmat hidastavat käyttöä. Tästä muodostuu modernisointipolku, joka ei näytä hyvältä vain paperilla vaan on arjessa kestävä.
Monissa kehittyneissä sovelluksissa varsinainen arvo ei ole käyttöliittymässä vaan vuosien saatossa kertynyttä liiketoimintalogiikkaa, erityissääntöjä, poikkeuksia ja kokemusperäistä tietoa. Tätä substanssia ei heitetä kevyin perustein pois. Erottamme vastuut selkeästi, järjestämme tietokannan uudelleen, korvaamme vanhat pääsytavat, luomme uusia REST-rajapintoja ja tarvittaessa täydennämme asiakassovelluksia Windows, macOS ja Linux samalle toiminnalliselle pohjalle. Näin ei synny jyrkkää katkosta vaan jäljitettävä jatkokehitys selkeällä teknisellä rajauksella.
Usein tämä tarkoittaa myös historiallisesti kasvaneiden monoliittien muokkaamista jälleen muotoon, joka on ylläpidettävä, testattava ja laajennettava. Tietojen käyttö vakautetaan, liiketoimintalogiikka irrotetaan käyttöliittymäkoodista, rajapinnat suunnitellaan ennakoitaviksi ja tulevia laajennuksia ei enää tarvitse ajaa ristiriitaan olemassaolon kanssa. Tavoitteena ei ole kosmeettinen modernisointi vaan järjestelmä, joka antaa yritykselle jälleen tilaa uusille vaatimuksille.
Palvelut ja palvelimet osana samaa arkkitehtuuria
Monet yritysjärjestelmät tarvitsevat nykyään paitsi asiakasohjelman myös taustapalveluita, Windows- tai Linux-palveluita sekä REST-palvelimia. Juuri siksi emme suunnittele näitä osia jälkiasennuksina vaan osana samaa arkkitehtuuria. Palvelu, joka lisätään vasta myöhemmin jollain tavalla, muodostuu lähes aina poikkeustapaukseksi.
Kun tietoja käsitellään hajautetusti, rajapintoja tarjotaan, vientiä ajetaan, tuontia valvotaan tai tehtäviä suoritetaan taustalla ajastetusti, tekninen vastuu on selvitettävä heti alusta alkaen. Mitä ajetaan asiakkaassa, mitä palvelussa, mitä palvelimella, miten virheet tulevat näkyviksi, miten tilamuutokset voidaan jäljittää, miten liiketoimintalogiikka pysyy yhtenäisenä? Näihin kysymyksiin vastaamme varhain, jotta erillisistä palikoista syntyy kuormitusta kestävä kokonaisjärjestelmä.
Tämä on erityisen tärkeää monialustaisissa projekteissa. Työpöytäasiakas Windows, macOS tai Linux ei saa toiminnallisesti tarkoittaa eri asiaa kuin sitä tukeva REST-palvelin tai taustapalvelu. Siksi ajattelemme tietomallin, prosessit, käyttöoikeudet, integraatiot ja tuotannon yhdessä. Näin syntyy arkkitehtuuri, jossa asiakasohjelmat, palvelut ja palvelimet puhuvat samaa kieltä.
Periaatteemme
Teknologia ei ole meille uskonasia. Ratkaisevaa on, että arkkitehtuuri, tiimikyvykkyys, tuotanto ja tulevat laajennukset sopivat yritykseen. Ei se äänekkäin alusta voita, vaan se, jolla riskejä, ylläpidettävyyttä ja kasvua voidaan hallita järkevästi.
Joihinkin tehtäviin käytämme tarkoituksella Delphi:ä, koska siellä vakiintunut liiketoimintalogiikka, suorituskykyiset asiakasohjelmat ja monialustaisuus pääsevät esiin. Toiset vaatimukset sopivat paremmin C#:aan, palveluihin, portaaliin tai näiden yhdistelmään. Hyvä arkkitehtuuri ei synny muodista vaan selkeydestä: mikä järjestelmäosan vastuu on, mitä käyttöikää voidaan odottaa, kuinka suuri tiimi on, kuinka kriittinen tuotanto on ja millaisia laajennuksia käytännössä realistisesti tulee seuraavien vuosien aikana?
Juuri siellä alkaa meille ammattimainen ohjelmistokehitys. Emme halua vain toimittaa jotain, mikä toimii tänään, vaan luoda teknisen perustan, joka on myöhemminkin jäljitettävissä, siirrettävissä ja taloudellisesti ylläpidettävissä.
Usein kysytyt kysymykset teknologiasta ja arkkitehtuurista
Teknologiset päätökset on sovitettava tiimiin, toiminnallisuuteen ja tuotantoon. Siksi emme selvitä näitä kysymyksiä abstraktilla tasolla, vaan aina konkreettisen järjestelmän pohjalta.
Milloin Delphi on järkevä verrattuna täydelliseen uuteen alustaan?
Aina kun vakiintunutta liiketoimintalogiikkaa, suorituskykyisiä työpöytäprosesseja ja monialustatavoitteita halutaan jatkaa taloudellisesti kannattavasti sen sijaan, että substanssi korvattaisiin kevyin perustein.
Milloin otatte lisäksi käyttöön C#?
Erityisesti portaaleihin, web-backendeihin, REST-palveluihin, integraatioihin ja palveluarkkitehtuurin osiin, jotka kytkeytyvät 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 tietojen käytön selkeä erottelu tekee modernisoinnista, testeistä, palveluista ja tulevista alustamuutoksista hallittavia.
Otatteko uudet alustat kuten Windows 11 ARM64 huomioon varhain?
Kyllä. Uusi kohdelaitteisto ja käyttöönoton polut tarkistetaan varhain, jotta ne eivät myöhemmin muutu kalliiksi erikoishankkeiksi.
Lisää kysymyksiä koottuna
Nämä lyhyet vastaukset pysyvät tällä sivulla. Keskisellä FAQ-aloitussivulla käsittelemme aihetta lisäksi suhteessa arkkitehtuuriin, modernisointiin, alustoihin ja tuotantoon.