Tko želi razvijati poslovni softver s podrškom za više najmoprimatelja, donosi rane arhitekturne odluke koje se kasnije teško mogu „ukloniti konfiguracijom“. Podrška za više najmoprimatelja nije samo pitanje licence ili UI-a, već utječe izravno na model podataka, ovlasti, sučelja, procese ažuriranja, podršku i, ne manje važno, na dokazivanje sigurnosti. U praksi projekti s više najmoprimatelja rijetko zapnu zbog same domenjske logike, već zbog neuresenih razgraničenja: Gdje točno počinje najmoprimatelj? Kako se podaci izoliraju? Koje komponente smiju raditi preko najmoprimatelja (npr. monitoring, backup, slanje e‑pošte) – i kako se to auditira?
Ovaj članak namijenjen je IT‑vodstvu, administratorima i tehnički odgovornim osobama u projektima. Opisuje provjerene obrasce, tipične pogrešne pretpostavke i konkretna pitanja za donošenje odluka u pogledu operacija i daljnjeg razvoja. Fokus je namjerno na svakodnevnim posljedicama: provisioning novih najmoprimatelja, modeli uloga i prava, migracija podataka, pogon sučelja, logiranje, backup/RESTore i mogućnost nadogradnje. Cilj je arhitektura koja ostaje dugoročno održiva – neovisno o tome je li rješenje namijenjeno internom sustavu, za više područja u koncernu ili kasnije kao hostana platforma.
Što podrška za više najmoprimatelja zapravo znači u kontekstu poduzeća
Podrška za više najmoprimatelja (često nazvana Multi-Tenancy) znači da softver modelira više organizacijski odvojenih jedinica („najmoprimatelji“) na zajedničkoj tehničkoj platformi. Najmoprimatelj može biti poduzeće, podružnica, lokacija, klijent ili poslovna jedinica. Presudno je: najmoprimatelji ne smiju vidjeti ili utjecati na podatke ili funkcije drugog najmoprimatelja, osim ako je to izričito predviđeno i provjereno (npr. konsolidirano izvještavanje).
U projektima je korisno definirati podršku za više najmoprimatelja duž tri osi:
- Dojenisolacija: Kako se osigurava da su podaci dostupni za čitanje i zapis samo u ispravnom kontekstu najmoprimatelja?
- Identitet & ovlasti: Kako se korisnik povezuje s najmoprimateljem i kako se provjeravaju uloge/opsezi?
- Betriebsisolation: Koliko snažno trebaju najmoprimatelji utjecati jedni na druge u pogledu opterećenja, kvarova, ažuriranja i prozora održavanja?
Te osi vode do različitih varijanti. Rješenje može, primjerice, strogo razdvajati podatke (odvojene baze podataka), a istovremeno biti snažno povezano u pogledu operacija (zajednička deployment‑pipline, zajednični queue, zajednički indeksi za pretraživanje). Za donositelje odluka važno je shvatiti da podrška za više najmoprimatelja nije „prekidač“, već spektar s posljedicama za troškove i rizik.
Arhitekturne odluke za poslovni softver s podrškom za više najmoprimatelja
Prije nego što proširite tablice ili učinite sučelja „prilagođenima najmoprimateljima“, trebate razjasniti granice sustava: koje komponente pripadaju platformi, koje se konfiguriraju po najmoprimatelju i koji se podaci smiju centralno analizirati? U zrelim korporativnim okruženjima važna su i povezivanja na ERP, DMS, CRM ili Identity Provider (IdP).
Single-Tenant vs. Multi-Tenant: funkcionalno jednako, tehnički vrlo različito
Single‑Tenant znači: po najmoprimatelju vlastita instanca (najmanje vlastita baza podataka, često i vlastiti aplikacijski stack). Multi‑Tenant znači: više najmoprimatelja dijeli instance i infrastrukturu – uz logičko razdvajanje. Multi‑Tenant često smanjuje napor za rollout i operacije, ali povećava zahtjeve za izolacijom, testnom pokrivenošću i observabilnošću (vidljivost putem logova/metrika/tracinga).
Često pragmatičan pristup je: „Multi-Tenant u kodu, Single-Tenant u radu“ za kritične tenante. To znači: kod dosljedno upravlja kontekstima tenanta, ali pojedini tenanti se mogu opcionalno pokretati odvojeno (npr. iz razloga usklađenosti ili performansi). Za to je međutim potrebno da konfiguracija, deployment i monitoring od početka budu pripremljeni za obje varijante.
Kontekst tenanta kao dosljedno arhitektonsko načelo
Mnoge pogreške nastaju zato što se kontekst tenanta samo na pojedinim mjestima „dodaje“ (npr. filteri u SQL-u, dodatni parametri u servisima). Stabilnije je kad kontekst tenanta postane dosljedno načelo:
- Svaki zahtjev ima jednoznačno utvrđenog tenanta (iz tokena/SSO, poddomene, headera, klijentskog certifikata ili konfiguriranog endpointa).
- Kontekst tenanta se u serverskoj logici tretira kao obavezna informacija (nema podrazumijevanih tenanta, nema „ako je prazno, onda…“).
- Slojevi pristupa podacima i sučelja nameću tenant-filtre ili vezu za tenanta, umjesto da ih čine opcionalnima.
- Logging i audit sadrže tenanta, korisnika/servisni račun i ID korelacije, kako bi operacije i podrška mogli rekonstruirati što se dogodilo.
Ovaj pristup „kontekst tenanta prvo“ smanjuje skupinu pogrešaka koje se otkriju tek u radu: netočni izvještaji, slučajno miješanje podataka, teško objašnjivi slučajevi autorizacije i nepotpuni audit-trailovi.
Model podataka: Tri uobičajena obrasca izolacije i njihove posljedice
Najvažnija tehnička odluka za višekorisničnost je pohrana podataka. Ona određuje backup/RESTore, migracije, performanse i dokazivanje sigurnosti. U osnovi postoje tri obrasca, koji se mogu i kombinirati.
1) Baza podataka po tenantu
Svak tenat ima vlastitu bazu podataka (ili vlastiti database-cluster). Prednosti: vrlo jasna izolacija, jednostavan RESTore po tenantu, dobra osnova za diferencirana održavanja. Nedostaci: veći napor provisioniranja, više konekcija, više migracija shema i veća složenost u radu (npr. monitoring preko velikog broja baza podataka).
Tipični slučajevi upotrebe: vrlo strogi zahtjevi usklađenosti, tenanti s vrlo različitim količinama podataka, ili situacije u kojima tenanti trebaju različite cikluse izdanja. Administrativno važno: potrebna vam je solidna automatizacija za ažuriranja sheme, upravljanje indeksima, sigurnosne kopije i prava – inače će se napor drastično povećavati s brojem tenanata.
2) Shema po tenantu
Jedan database-server, ali po tenantu zasebna shema (ili namespace). To je srednji oblik izolacije: bolje odvojivo od čistih filtera na razini retka, ali manje resursno zahtjevno od kompletnih baza podataka. Backup/RESTore po tenantu je, ovisno o tehnologiji baze podataka, moguć, ali ne uvijek trivijalan. Migracije je jednostavnije koordinirati nego kod „DB po tenantu“, no broj objekata ostaje visok.
Važno za rad: provjerite rano kako alati za monitoring, backup i migraciju postupaju s mnogim shemama, i mogu li standardni reporting i BI-pristupi između shema čisto prikazati podatke bez narušavanja sigurnosnog okvira.
3) Zajedničke tablice s Tenant-ID (odvajanje na razini retka)
Svi tenanti dijele tablice; svaki red nosi Tenant-ID. To je za mnoge slučajeve primjene učinkovito, smanjuje broj objekata i pojednostavljuje globalne migracije. Istovremeno raste odgovornost aplikacije i/ili baze podataka da odvajanje pouzdano provodi.
Ako koristite razdvajanje po retcima, obratite posebnu pozornost na sljedeće dvije točke:
- Tehničko provođenje: Ne oslanjajte se samo na „sve filtriramo prema Tenant-ID“. Koristite, gdje je moguće, mehanizme baze podataka poput Row-Level Security (RLS; filtriranje redaka na strani baze podataka temeljeno na kontekstu sesije ili ulogama), pogleda (Views) ili sigurnosnih politika. Koja opcija odgovara, ovisi o bazi podataka.
- Međumandantne nuspojave: Veliki mandanti mogu utjecati na indekse, stopu pogodaka cachea i ponašanje zaključavanja. To nije presudan kriterij, ali se mora uključiti u planiranje kapaciteta i testiranje.
Hibridni modeli: često realniji od „ili/ili“
U praksi su hibridni modeli uobičajeni: ključne transakcije u zajedničkim tablicama (za jednostavna ažuriranja), posebno osjetljivi podaci u odvojenim bazama podataka ili shemama, kao i središnje „Control Plane“ područje za upravljanje mandantima, naplatu, feature-flagove i globalnu konfiguraciju. Presudno je da su te granice dokumentirane i tehnički osigurane.
Dozvole i identiteti: Mandant, Rolle, Scope
Mandantenfähigkeit stoji ili pada s pouzdanim konceptom dozvola. Za rad je manje važno koliko je model elegantan, a više je važno je li u svakodnevnoj upotrebi provjerljiv i diagnosticiran: Zašto je korisnik X smio izvršiti radnju Y? Koja je uloga bila uključena? Koja je politika donijela odluku?
SSO i dodjela mandanta: SAML 2.0, OIDC i direktoriji
U poslovnim okruženjima često se koristi Single Sign-on (SSO). SSO znači da se prijava odvija preko centralnog Identity Providera, a aplikacija samo provjerava tokene/asserte. Uobičajeni su SAML 2.0 (temeljen na assertion-ima, često u klasičnim enterprise postavkama) ili OpenID Connect (OIDC; temeljen na tokenima, često u modernijim IdP-stackovima). Važno je: dodjela mandanta mora biti jednoznačna i zaštićena od manipulacije.
Provjerene opcije:
- Mandant preko Issuer/IdP (po jedan IdP po mandantu) – vrlo jasno, ali organizacijski zahtjevnije.
- Mandant preko Claim/Attributa (npr. Tenant-ID u tokenu) – fleksibilno, zahtijeva čistu validaciju i mapiranje.
- Mandant preko poddomene ili odvojenih endpointa – dobro za portale, smanjuje pogrešne operacije, ali mora uredno surađivati sa SSO-redirectima.
Model uloga i administracija mandanta bez „Support-Tickets“
Čest izvor troškova je da svaka promjena kod mandanta (novi korisnik, nova uloga, nova dodjela lokacije) završi kao ručni zahvat. Cilj bi trebao biti: mandanti mogu sami upravljati svojim korisnicima i ulogama u definiranom okviru, bez da centralni administratori moraju dirati svaki detalj.
U praksi su korisne višestupanjske uloge:
- Plattform-Admin (održava okruženje, vidi metapodatke mandanta, ne nužno podatke mandanta).
- Administrator mandanta (upravlja korisnicima, ulogama, konfiguracijom unutar mandanta).
- Stručne uloge (npr. referent, voditelj tima, odobrenja).
- Tehnička servisna konta (za sučelja, jobove, automatizaciju) s minimalnim pravima.
Operativno važno: uloge trebaju biti verzionirane i podložne reviziji. Ako se dozvole „samo tako“ mogu promijeniti direktnim ažuriranjem ili nepraćenom konfiguracijom, gubi se sljedivost – a time i vrijeme pri auditima i otklanjanju kvarova.
Sučelja i integracija: multitenancija ne završava na API-Gatewayu
Mnogi digitalni poslovni sustavi ovise o integracijama: ERP, DMS, CRM, Data Warehouse, partner portali, povezivanje strojeva. Multitenancija stoga mora biti dosljedno primijenjena i u sučeljima. To se odnosi na REST-APIs (HTTP-bazirana sučelja), eventing/queues, datotečna sučelja i e-mail-/webhook-procese.
REST-API: Tenant-Scoping kao ugovor
Kod REST-API-ja presudno je kako se tenant u zahtjevu određuje. Česti obrasci su subdomain/host, header za tenant ili claim u Access Tokenu. Važno je da to ne ostane samo konvencija, nego da bude dokumentirano i izvršavano na serverskoj strani kao ugovorni sastavni dio API-ja.
Za operativu je također bitno: API treba jasne poruke o greškama i log-podatke koji sadrže tenant, endpoint, korisnika/klijenta, Request-ID i relevantne parametre – bez nepotrebnog logiranja osobnih podataka. Tako administratori i podrška mogu reproducirati i razjasniti slučajeve, bez diranja podataka drugih tenant-a.
Asinkroni procesi: planirati poslove, redove i raspoređivače s podrškom za multitenanciju
Batch-jobs, importi, generiranje izvještaja ili noćna usklađivanja često se izvršavaju asinhrono. Tu se posebno lako događa miješanje tenant-a, jer worker „u pozadini“ radi bez aktivnog konteksta korisnika. Stoga planirajte:
- Povezanost posla s tenantom: Svaki posao nosi Tenant-ID i „pokretački kontekst“ (korisnik ili servisni račun).
- Ograničenja resursa: Veliki tenant-i ne smiju u potpunosti dominirati obradom poslova (pravednost, kvote, prioriteti).
- Artefakti odvojeni po tenantu: Privremene datoteke, eksporti, S3-buckets/putanje za dijeljenje, e-mail predlošci i webhook-sekreti moraju se upravljati specifično po tenantu.
Operacija i sigurnost: što administratori zaista trebaju
Multitenancija djeluje u pogonu kao multiplikator: jedna pogreška, loš deployment ili nejasan alarm može utjecati na mnoge tenant-e. Suprotno tome, pravilno upravljana platforma može brže i konzistentnije isporučivati nadogradnje. Ključno je da operacije i sigurnost nisu „naknadno ugrađivani“, nego dio dizajna arhitekture.
Logiranje, audit i sljedivost
Za poslovni softver treba razdvojiti dvije vrste logova:
- Tehničko logiranje: greške, performanse, problemi integracije, timeouti. Mora sadržavati tenant i korrelacijsku ID kako bi se u distribuiranim komponentama transakcija mogla pronaći.
- Audit-logiranje: Tko je izvršio koju poslovnu akciju (npr. promjenu matičnih podataka, pokretanje eksport-a, dodjelu prava)? Audit-logovi su sigurnosno relevantni i zahtijevaju jasne koncepte čuvanja i pristupa.
Važno: audit nije „još jedan log“. Audit mora biti otporan na manipulacije, sljediv i analizabilan. Istovremeno vrijedi minimizacija podataka: ne svaka detaljna informacija treba trajno ući u audit, već činjenice potrebne za dokazivanje i rekonstrukciju.
Backup/Restore: mogućnost selektivnog vraćanja tenant-a
Pitanje vraćanja podataka (RESTore) je lakmus-test za vaš model podataka. Globalna sigurnosna kopija se brzo napravi, no šteta nastaje kad pojedini zakupnik prijavi gubitak podataka, a možete vratiti samo „sve ili ništa“. Ovisno o obrascu izolacije, primjenjuju se različite strategije:
- DB po zakupniku: Vraćanje je najjasnije, ali zahtijeva orkestraciju kada je potrebno dosljedno vratiti više sustava (npr. baza podataka + indeks pretraživanja + spremište datoteka).
- Zajednička DB: Vraćanje po zakupniku je znatno složenije. Pomažu mehanizmi specifični za zakupnika za izvoz/snapshot, pristupi Event-Sourcinga ili dodatne mjere zaštite (soft-deletes, verzioniranje, procesi odobravanja).
Za administratore je bitna dokumentirana procedura: Koliko traje vraćanje? Koji su sustavi uključeni? Kako se testira da zakupnik ponovno „ispravno“ radi (Smoke Tests, integracijski provjeri)?
Strategija patchiranja i ažuriranja: migracije sheme bez zastoja
Jedna od ključnih prednosti platformskih pristupa je mogućnost jedinstvenog izvođenja ažuriranja. To funkcionira samo ako planirate migracije sheme (izmjene struktura baze podataka) i ažuriranja aplikacija kao povezan proces. Dobra praksa je:
- Unaprijed kompatibilna deployanja: Nove verzije softvera mogu raditi sa starom shemom (kratko vrijeme), i/ili stari softver može raditi s novom shemom. Time se smanjuje vrijeme nedostupnosti.
- Migracije malim koracima: Umjesto „Big Bang“ preinaka: dodati nove stupce, postepeno popuniti podatke (backfill), tek kasnije ukloniti stare strukture.
- Feature-Flags po zakupniku: Funkcije se mogu aktivirati za odabrane zakupnike kako bi se ograničio rizik i učinili uvođenja kontroliranima.
Za IT-upravu je važno: sposobnost ažuriranja je investicija. Ona kasnije štedi vrijeme kod sigurnosnih ažuriranja, promjena operativnog sustava, nadogradnji baze podataka i promjena integracija – dakle u točno onim područjima koja tijekom godina stvaraju troškove.
Provisioniranje i životni ciklus zakupnika: od Onboarding-a do deaktivacije
Podrška za više zakupnika smatra se „dovršenom“ tek kada je životni ciklus u potpunosti promišljen. U praksi nisu važna samo nova kreiranja, već i promjene: dodatne lokacije, novi Identity-Provideri, promjene ugovora, izvoz podataka i deaktivacije.
Onboarding: Što bi trebalo biti automatizirano
Ispravan proces Onboardinga smanjuje pogreške i opterećenje podrške. Tipične komponente:
- Kreirati zakupnika (Tenant-ID, naziv, kontakt, status).
- Postaviti konfiguraciju (regija, jezik, vremenska zona, e‑mail domene, branding ako je predviđeno).
- Konfigurirati povezivanje identiteta (SSO‑metapodaci, certifikati, Redirect‑URL‑ovi).
- Osigurati inicijalne uloge i administratorske korisnike.
- Provisionirati tehničke resurse (baza podataka/shema, spremište, indeks pretraživanja, redovi poruka/queues).
- Aktivirati nadzor i alarme za zakupnika.
Što je veći dio toga reproducibilno automatiziran, to je manje „posebnih slučajeva“. To nije samo učinkovitost, već i smanjenje rizika: ručni koraci su najčešći izvor nedosljednih konfiguracija.
Izvoz podataka i Offboarding: podcijenjeno, ali kritično za sigurnost
Offboarding je pitanje sigurnosti i usklađenosti: koji podaci moraju biti izvozivi (npr. za predaju), koji se moraju izbrisati ili anonimizirati, i kako se to dokazuje? Čak i bez specifičnog pravnog savjeta tehnički vrijedi: trebate jasne odgovornosti, definirane rokove i proces koji je reproducibilan.
Ako se podaci nalaze u više sustava (baza podataka, spremište datoteka, indeks pretraživanja, logovi, backupi), offboarding mora uzeti u obzir te razine. Posebno su backupi osjetljivi: potpuno brisanje iz povijesnih backupova često je praktički nemoguće. Time je važniji koncept koji to čini transparentnim (čuvanje, zaštita pristupa, rotacija) i koji podatke zakupaca izvan produktivnih sustava ipak adekvatno štiti.
Tipične pogreške iz prakse – i kako ih izbjeći
Podrška za više zakupaca rijetko propada spektakularno, već zbog mnogo malih dizajnerskih nedostataka. Sljedeći obrasci pogrešaka redovito se pojavljuju u projektima:
- Tenant-ID kao „opcionalna“: Pojedini endpointi, poslovi ili izvještaji zaborave filter. Rješenje: tehničko prisiljavanje (Policies/RLS), testovi i dosljedna arhitektonska pravila.
- Dijeljena konfiguracija bez verzioniranja: Promjene u modelu uloga ili na prekidačima značajki kasnije nisu rekonstruabilne. Rješenje: verzionirati konfiguraciju, auditirati promjene.
- Keševi koji dijele podatke među zakupcima: Keširanje bez ključa zakupca dovodi do curenja podataka. Rješenje: ključ keša uvijek ovisan o zakupcu; osjetljive podatke keširati kraće.
- Podrška ne može suziti problem: Nedostatak korelacije i metrike po zakupcu. Rješenje: korelacijska ID, oznake zakupaca u logovima/metrikama, jasni dashboardi.
- Migracije traju predugo: Velike preinake tablica blokiraju rad. Rješenje: inkrementalne migracije, pozadinski procesi, planiranje vremenskih prozora.
Ove točke su manje „detalji za developere“ nego operativna realnost. Tko ih rano adresira, smanjuje kasnije troškove za hotfixove, hitne intervencije i nejasne odgovornosti.
Razvijanje poslovnog softvera prilagođenog za više zakupaca: kontrolna lista za pouzdane odluke
Kad u projektu donosite ključne odluke, pomažu konkretna pitanja koja čine arhitektonsku i operativnu sposobnost vidljivom:
- Koja izolacija je potrebna: tehnička (podatci), organizacijska (pristupi), operativna (prozor za održavanje/opterećenje)?
- Kako se zakupac jednoznačno određuje (SSO-Claim, subdomena, vlastiti Endpoint)?
- Kako se izolacija provodi (mehanizmi baze podataka, centralni sloj pristupa, politike)?
- Kako izgleda slučaj obnavljanja: po zakupcu, s kojim ovisnostima, u kojem roku?
- Kako se provode nadogradnje: migracija sheme, strategija povrata (rollback), feature-flagovi?
- Koja observabilnost postoji: metrike po zakupcu, audit, alarmiranje, runbookovi?
- Kako se integracije vode za više zakupaca (servisni računi, secrets, ograničenja stope, webhooks)?
Ova su pitanja svjesno formulirana iz operativne perspektive. Ako ih možete odgovoriti, obično ste i arhitektonski na stabilnom putu.
Zaključak: Podrška za više zakupaca je operativno obećanje, a ne UI-značajka
Sposobnost rada s više zakupnika odlučuje hoće li se poslovni softver tijekom godina moći ekonomski održavati i sigurno dalje razvijati. Osnovni posao leži u jasnim linijama razdvajanja: kontekst zakupnika kao obaveza, pouzdana izolacija podataka, provjerljiva prava pristupa, sučelja prilagođena višekorisničkom radu i životni ciklus koji uključuje provisioniranje, nadogradnje i deprovisioniranje. Tko pravilno postavi te temelje, ima koristi u svakodnevnom radu: manje prekida zbog driftanja konfiguracije, brže nadogradnje, jasniji procesi podrške i pouzdani dokazi u odnosu na interne i vanjske zahtjeve.
Ako želite konkretnu procjenu sposobnosti rada s više zakupnika za postojeće ili novo digitalno poslovno rješenje ili želite izraditi migracijski i arhitektonski koncept, prođimo zajedno strukturirano kroz okvirne uvjete:
U stručnom kontekstu važnu ulogu imaju i multi-tenant arhitektura i izolacija zakupnika kada integracije, tokovi podataka i daljnji razvoj moraju besprijekorno surađivati.