Teknologiaprofiili
Tekninen perustamme – yleiskatsaus
Delphi. C#. SQL. API:t.
Teknologiat, jotka sopivat liiketoimintalogiikkaan, dataan ja käyttöön.
Teknologia kuvina
Teknologiavalinnat näkyvät meillä tavoitearkkitehtuurin kautta.
Ratkaisevaa ei ole iskusana, vaan se, miten alusta, palvelut ja kerrokset myöhemmin toimivat yhdessä. Nämä luonnokset tekevät suunnan konkreettiseksi.
Jaettu ydin useille kohteille
Monialustaisuus on perusteltua, kun useat asiakasohjelmat käyttävät samaa liiketoimintalogiikkaa, eivätkä ala poiketa toisistaan.
* Käytetyt alustanimet ja tavaramerkit kuuluvat asianomaisille oikeudenhaltijoille.
C# ja palvelut täydennyksenä
Portaalit, REST ja palvelut täydentävät ydintä siellä, missä verkko- ja käyttölogiikka korostuvat.
Huomioi kohdelaitteisto ajoissa
Alustamuutokset, kuten ARM64, kuuluvat arkkitehtuuriin ja käyttöönottovaiheeseen ennen kuin niistä tulee tukiongelma.
Sopivat palvelu- ja teknologiapolut
Tärkeitä syventäviä näkökulmia tähän aiheeseen
Emme käytä teknologioita muodin mukaan, vaan käyttötilanteen, eliniän, integraatiotarpeen ja tiimin osaamisen perusteella. Tärkeää ei ole iskusana, vaan se, säilyykö järjestelmä myöhemmin ylläpidettävänä, laajennettavana ja siirrettävänä.
Vahva liiketoimintalogiikalle ja monialustaisille asiakasohjelmille
Delphi on vahva siellä, missä vakiintunutta liiketoimintalogiikkaa, tietokantaläheisiä prosesseja, raportteja ja vakaiden clienttien käyttöä Windows, macOS ja Linux-ympäristöissä halutaan jatkaa pitkällä aikavälillä.
Tutustu 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.
Tutustu C#
Arkkitehtuuri
Layer-3 monoliittisen perintökuorman sijaan
Erotamme käyttöliittymän, liiketoimintalogiikan ja tietojen käsittelyn tietoisesti, jotta muutokset pysyvät ennakoitavina eikä uusia palveluja tarvitse rakentaa ristiriitaan olemassa olevan kanssa.
Tutustu Layer-3
Alustat
Ota Windows 11 ARM64 jo suunnittelussa huomioon
Perinteisten x64‑kohteiden lisäksi huomioimme nykyiset alustat kuten Windows 11 ARM64 varhain, jotta uusi laitteisto ja käyttöönotot eivät myöhemmin muutu erikoishankkeiksi.
Tutustu ARM64:ään
Milloin mikä lähestymistapa on tarkoituksenmukainen
Delphi on järkevä, kun
- olemassa oleva liiketoimintalogiikka halutaan säilyttää,
- monimutkaiset työpöytäprosessit on pidettävä vakaina,
- Windows-, macOS- ja Linux-asiakasohjelmien tulee rakentua yhteisen toiminnallisen pohjan varaan.
C# on järkevä, kun
- REST-palvelimia ja palveluja rakennetaan,
- APIt ja ulkoiset integraatiot ovat keskiössä,
- modernit palveluarkkitehtuurit ovat tarpeen.
Hybridimalli on järkevä, kun
- olemassa olevien sovellusten ja uusien portaaleiden on toimittava yhdessä,
- työpöytä, palvelut ja web käyttävät samaa tietopohjaa,
- modernisointi toteutetaan vaiheittain ja Layer-3-rakenne huomioiden.
Delphi-modernisointi käytännössä
Jos vanha Delphi-sovellus on toiminnallisesti vielä arvokas, emme modernisoi sokeasti. Analysoimme ensin, miten järjestelmä todellisuudessa toimii, mitä prosesseja se toteuttaa, missä tietovirrat katkeavat ja mitkä perintöongelmat hidastavat sen tuotantokäyttöä. Näin syntyy modernisointipolku, joka ei ole vain paperilla siisti, vaan kestävä arjessa.
Monissa pitkään kehittyneissä sovelluksissa todellinen arvo ei ole käyttöliittymässä vaan vuosien aikana kertynyssä toiminnallisessa logiikassa, erityissäännöissä, poikkeuksissa ja kokemusperäisessä tiedossa. Tätä substanssia ei hylätä kevyesti. Erotamme vastuualat selkeästi, järjestämme tietokannan uudelleen, korvaamme vanhat pääsynpolut, luomme uusia REST-rajapintoja ja täydentämme tarvittaessa asiakasohjelmilla Windows, macOS ja Linux samalla toiminnallisella perustalla. Näin syntyy ei niin radikaali irtautuminen vaan jäljitettävä jatkokehitys selkeällä teknisellä rajauksella.
Usein tämä tarkoittaa myös historiallisesti kasvaneiden monoliittien palauttamista muotoon, joka on ylläpidettävissä, testattavissa ja laajennettavissa. Tietokantakäsittely vakautetaan, liiketoimintalogiikka irrotetaan käyttöliittymäkoodista, rajapinnat tulevat suunniteltaviksi ja tulevia laajennuksia ei enää tarvitse taistella sisäisten rakenteiden kanssa. Tavoitteena ei ole kosmeettinen modernisointi, vaan järjestelmä, joka antaa yritykselle tilaa uusille vaatimuksille.
Palvelut ja serverit osana samaa arkkitehtuuria
Monet yritysjärjestelmät tarvitsevat nykyään eivät ainoastaan yhtä asiakasohjelmaa, vaan myös taustapalveluita, Windows- tai Linux-palveluja ja REST-palvelimia. Siksi emme suunnittele näitä osia jälkikäteen liitettävinä lisäyksinä, vaan osana samaa arkkitehtuuria. Palvelu, joka liitetään mukaan vasta myöhemmin, muuttuu lähes aina erityistapaukseksi.
Kun tietoja käsitellään hajautetusti, rajapintoja tarjotaan, vientiä suoritetaan, tuontia valvotaan tai tehtäviä ajoitetaan taustalla, tekninen vastuu on selvitettävä alusta lähtien. Mitkä osat ajetaan asiakasohjelmassa, mitkä palvelussa, mitkä palvelimella; miten virheet tehdään näkyviksi, miten tilamuutokset ovat jäljitettävissä, miten toiminnallinen logiikka pysyy konsistenttina? Näihin kysymyksiin vastaamme varhain, jotta yksittäisistä palasista muodostuu kestävä kokonaisjärjestelmä.
Tämä on erityisen tärkeää monialustaprojekteissa. Työpöytäasiakas Windows, macOS tai Linux -ympäristössä ei saa toiminnallisesti tarkoittaa eri asiaa kuin sitä tukeva REST-palvelin tai taustapalvelu. Siksi suunnittelemme tietomallin, 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 dogma. Ratkaisevaa on, että arkkitehtuuri, tiimin kyvykkyys, käyttö ja tulevat laajennukset sopivat yrityksen tarpeisiin. Ei se äänekkäin alusta ratkaise, vaan se, jolla riskejä, ylläpidettävyyttä ja kasvua voidaan hallita järkevästi.
Joissain tehtävissä valitsemme tietoisesti Delphi, koska siellä kertynyt liiketoimintalogiikka, suorituskykyiset asiakasohjelmat ja monialustatuki pääsevät oikeuksiinsa. Toiset vaatimukset soveltuvat paremmin C#, palveluille, portaaliin tai niiden yhdistelmään. Hyvä arkkitehtuuri ei synny muodista, vaan selkeydestä: mikä järjestelmäosa kantaa mitä vastuuta, millainen elinkaari on odotettavissa, kuinka suuri tiimi on, kuinka kriittinen käyttö on ja millaisia laajennuksia realistisesti tulee seuraavien vuosien aikana?
Juuri siellä alkaa meille ammattimainen ohjelmistokehitys. Emme halua vain toimittaa jotain, joka toimii tänään, vaan luoda teknisen perustan, joka on myös myöhemmin ymmärrettävä, siirrettävä ja taloudellisesti ylläpidettävä.
Usein kysytyt kysymykset teknologiasta ja arkkitehtuurista
Teknologiset päätökset on sovitettava tiimiin, toiminnallisuuteen sekä käyttöön ja ylläpitoon. Juuri siksi emme käsittele näitä kysymyksiä abstraktisti, vaan aina konkreettisen järjestelmän kohdalla.
Milloin Delphi on perusteltu verrattuna täysin uuteen alustaan?
Aina, kun olemassa oleva liiketoimintalogiikka, suorituskykyiset työpöytäprosessit ja monialustatavoitteet halutaan säilyttää taloudellisesti kannattavasti sen sijaan, että ydintoiminnallisuuksia korvattaisiin huolettomasti.
Milloin otatte lisäksi käyttöön C#?
Erityisesti portaaleissa, web-backendeissä, REST-palveluissa, integraatioissa ja palvelukeskeisen arkkitehtuurin osissa, 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 tietojen käytön puhdas erottelu tekee modernisoinnista, testeistä, palveluista ja tulevista alustavaihdoista hallittavia.
Otatteko uudet alustat kuten Windows 11 ARM64 varhaisessa vaiheessa huomioon?
Kyllä. Uusi kohdelaitteisto ja käyttöönoton polut tarkistetaan varhain, jotta niistä ei muodostu myöhemmin kalliita erikoishankkeita.
Lisäkysymykset koottuna
Nämä lyhyet vastaukset pysyvät tällä sivulla. Keskisellä FAQ-aloitussivulla käsittelemme aiheen lisäksi suhteessa arkkitehtuuriin, modernisointiin, alustoihin ja käyttöön.
Seuraava vaihe
Jos teillä on konkreettinen modernisointi-, API- tai alustakysymys, meidän tulisi varhaisessa vaiheessa määritellä tekninen arkkitehtuuri selkeästi.
Net-Base arvioi olemassa olevia järjestelmiä, tietopolkuja, rajapintoja ja kohdealustoja ei erillisinä, vaan toiminnallisen logiikan, käytön ja myöhemmän laajentamisen kontekstissa.
- Nykytila, tavoitetila ja tekniset riskit arvioidaan yhdessä.
- REST, datan käyttö, portaalit ja käyttöönotto eivät jätetä myöhempien seurausten varaan.
- Näette ajoissa, mikä ratkaisu on taloudellisesti ja toiminnallisesti kestävä.