Tehnološki profil
Pregled naše tehnične osnove
Tehnologij ne uporabljamo po modi, temveč glede na operativno realnost, življenjsko dobo, potrebo po integraciji in sposobnosti ekipe. Odločilno ni geslo, temveč ali sistem pozneje ostane čisto obvladljiv v obratovanju, razširljiv in prevzemljiv.
Močan za poslovno logiko in večplatformske odjemalce
Delphi je močan tam, kjer je treba dolgoročno nadaljevati razvito poslovno logiko, procese blizu podatkovni bazi, poročila in stabilne odjemalce za Windows, macOS in Linux.
Oglejte si Delphi
C#
Močan za REST, storitve in portale
C# uporabljamo, ko morajo portali, sodobne zaledne storitve, REST-API-ji in integracije čisto priklopiti na obstoječe poslovne sisteme.
Oglejte si C#
Arhitektura
Layer-3 namesto monolitne zapuščine
Zavestno ločimo uporabniški vmesnik, poslovno logiko in dostop do podatkov, da spremembe ostanejo načrtljive in novih storitev ni treba graditi proti obstoječemu stanju.
Oglejte si Layer-3
Platforme
Windows 11 ARM64 upoštevati že od začetka
Poleg klasičnih ciljev x64 zgodaj upoštevamo aktualne platforme, kot je Windows 11 ARM64, da nova strojna oprema in namestitve pozneje ne postanejo poseben projekt.
Oglejte si ARM64
Kdaj je katera smer smiselna
Delphi je smiseln, ko
- mora obstoječa poslovna logika živeti naprej,
- morajo kompleksni namizni procesi ostati stabilni,
- naj odjemalci za Windows, macOS in Linux nastanejo na skupni strokovni osnovi.
C# je smiseln, ko
- se vzpostavljajo REST-strežniki in storitve,
- so v središču API-ji in zunanje integracije,
- so potrebne sodobne storitvene arhitekture.
Hibrid je smiseln, ko
- morajo obstoječe aplikacije in novi portali sodelovati,
- namizje, storitve in splet uporabljajo isto podatkovno osnovo,
- naj modernizacija poteka postopno in kot struktura Layer-3.
Modernizacija Delphi v praksi
Če je stara aplikacija Delphi strokovno še vedno dragocena, ne moderniziramo na slepo. Najprej analiziramo, kako sistem dejansko deluje, katere procese nosi, kje se podatkovni tokovi pretrgajo in katere zapuščine zavirajo obratovanje. Iz tega nastane pot modernizacije, ki ne deluje čisto samo na papirju, temveč ostane vzdržna tudi v vsakdanji rabi.
V številnih z leti zraslih aplikacijah prava vrednost ne leži v uporabniškem vmesniku, temveč v letih domenske logike, posebnih pravil, izjem in izkušenj. Te substance ne zavržeš zlahka. Odgovornosti jasno ločimo, podatkovno bazo na novo uredimo, odpravimo stare načine dostopa, vzpostavimo nove REST-vmesnike in po potrebi dopolnimo odjemalce za Windows, macOS in Linux na isti domenski osnovi. Tako ne nastane trd prelom, temveč sledljiv razvoj z jasno tehnično zasnovo.
Pogosto to pomeni tudi, da zgodovinsko zrasle monolite ponovno spravimo v obliko, ki postane vzdržljiva, testabilna in razširljiva. Dostop do podatkov stabiliziramo, poslovno logiko ločimo od kode uporabniškega vmesnika, vmesnike naredimo predvidljive in prihodnjih razširitev ni več treba izbojevati proti obstoječemu stanju. Cilj ni kozmetična modernizacija, temveč sistem, ki podjetju ponovno da zračni prostor za nove zahteve.
Storitve in strežniki kot del iste arhitekture
Veliko poslovnih sistemov danes ne potrebuje le odjemalca, temveč tudi ozadne storitve, Windows- ali Linux-storitve in REST-strežnike. Prav zato teh delov ne načrtujemo kot naknadni dodatek, temveč kot del iste arhitekture. Storitev, ki se kasneje nekako priključi, skoraj vedno postane posebni primer.
Ko je treba podatke porazdeljeno obdelovati, zagotavljati vmesnike, izvajati izvoze, nadzorovati uvoze ali časovno vodeno izvajati opravila v ozadju, mora biti tehnična odgovornost razjasnjena od začetka. Kateri deli tečejo v odjemalcu, kateri v storitvi, kateri na strežniku, kako so napake vidne, kako so spremembe stanj sledljive, kako ostane domenska logika konsistentna? Na ta vprašanja odgovorimo zgodaj, da iz posameznih gradnikov nastane robusten celovit sistem.
To je odločilno predvsem pri večplatformskih projektih. Namizni odjemalec na Windows, macOS ali Linux strokovno ne sme pomeniti nečesa drugega kot spremljajoči REST-strežnik ali ozadna storitev. Zato podatkovni model, procese, pravice, integracije in obratovanje vedno obravnavamo skupaj. Tako nastane arhitektura, v kateri odjemalci, storitve in strežniki govorijo isti jezik.
Naše vodilo
Tehnologija za nas ni sistem verovanja. Odločilno je, da se arhitektura, sposobnost ekipe, obratovanje in prihodnje razširitve ujemajo s podjetjem. Ne zmaga najglasnejša platforma, temveč tista, s katero je mogoče smiselno upravljati tveganje, vzdrževanje in rast.
Nekatere naloge zavestno rešujemo z Delphi, ker tam zrasla poslovna logika, zmogljivi odjemalci in večplatformskost pokažejo svoje prednosti. Druge zahteve se bolje ujemajo z C#, s storitvami, s portalom ali s kombinacijo obojega. Dobra arhitektura ne nastane iz mode, temveč iz jasnosti: katera odgovornost pripada kateremu delu sistema, kakšna življenjska doba je pričakovana, kako velika je ekipa, kako kritično je obratovanje in katere razširitve bodo v naslednjih letih realno prišle?
Prav tam se za nas začne profesionalni razvoj programske opreme. Ne želimo dostaviti le nečesa, kar deluje danes, temveč ustvariti tehnično osnovo, ki bo tudi kasneje še sledljiva, prevzemljiva in ekonomsko vzdržljiva za vzdrževanje.
Pogosta vprašanja o tehnologiji in arhitekturi
Tehnološke odločitve se morajo ujemati z ekipo, strokovnim področjem in obratovanjem. Prav zato teh vprašanj ne obravnavamo abstraktno, temveč vedno na konkretnem sistemu.
Kdaj je Delphi smiselna v primerjavi s popolno novo platformo?
Vedno takrat, ko je treba ekonomsko nadalje uporabljati zraslo domensko logiko, zmogljive namizne procese in cilje več platform, namesto da bi se substanca nepremišljeno zamenjala.
Kdaj dodatno uporabite C#?
Predvsem za portale, spletne zaledne sisteme, REST-storitve, integracije in dele storitveno usmerjene arhitekture, ki se dobro povezujejo z obstoječimi namiznimi sistemi.
Kako pomemben je Layer-3 v praksi?
Zelo. Šele čista ločitev UI, poslovne logike in dostopa do podatkov omogoči obvladljivo modernizacijo, testiranje, storitve in prihodnje menjave platform.
Ali že zgodaj upoštevate nove platforme, kot je Windows 11 ARM64?
Da. Novo ciljno strojno opremo in poti uvajanja preverimo zgodaj, da iz tega kasneje ne nastanejo dragi posebni projekti.
Preberite zbrana dodatna vprašanja
Ti kratki odgovori ostanejo tukaj na strani. Na osrednji FAQ pristajalni strani temo dodatno umestimo v kontekst arhitekture, modernizacije, platform in obratovanja.