Ko želi razvijati poslovni softver koji podržava više zakupaca, donosi rane arhitektonske odluke koje se kasnije teško mogu „ukloniti konfiguracijom“. Sposobnost podrške višestrukim zakupcima nije samo pitanje licence ili korisničkog sučelja, već utiče direktno na model podataka, ovlaštenja, sučelja, procese ažuriranja, podršku i, ne na kraju, na dokazivanje sigurnosti. U praksi projekti sa više zakupaca rijetko propadaju zbog same poslovne logike, već zbog nejasnih granica: Gdje tačno počinje zakupac? Kako se podaci izoliraju? Koje komponente smiju raditi preko zakupaca (npr. monitoring, backup, slanje e‑pošte) – i kako se to audituje?
Ovaj članak je namijenjen IT‑rukovodstvu, 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 rada i daljeg razvoja. Fokus je namjerno na posljedicama u svakodnevnom radu: provisioniranje novih zakupaca, modeli uloga i prava, migracija podataka, rad sučelja, logovanje, backup/RESTore i sposobnost za ažuriranja. Cilj je arhitektura koja ostaje dugoročno održiva – neovisno o tome da li se rješenje koristi kao interni sustav, u više konzernskih jedinica ili kasnije kao hostana platforma.
Šta sposobnost podrške više zakupaca u korporativnom kontekstu zaista znači
Sposobnost podrške više zakupaca (često i Multi-Tenancy nazvana) znači da softver modelira više organizacijski odvojenih jedinica („zakupaca“) na jednoj tehničkoj platformi. Zakupac može biti kompanija, podružnica, lokacija, klijent ili poslovna jedinica. Ključno je: zakupci ne smiju vidjeti ili utjecati na podatke ili funkcije drugog zakupca, osim ako to nije izričito predviđeno i provjereno (npr. grupno izvještavanje).
U projektima je korisno definirati sposobnost za više zakupaca duž tri ose:
- Izolacija podataka: Kako se osigurava da su podaci čitljivi i zapisivi samo u odgovarajućem kontekstu zakupca?
- Identitet & ovlaštenja: Kako se korisnik pridružuje zakupcu i kako se provjeravaju uloge/oblasti pristupa?
- Operativna izolacija: Koliko snažno zakupci smiju međusobno utjecati na opterećenje, kvarove, ažuriranja i termin održavanja?
Ove ose vode ka različitim varijantama. Rješenje može, na primjer, strogo odvojiti podatke (odvojene baze podataka), a opet biti pod operativnog aspekta snažno povezano (zajednički deploymenti, zajednička queue, zajednički indeksi pretrage). Za donosioce odluka važno je razumjeti da sposobnost za više zakupaca nije „prekidač“, već spektrum sa troškovnim i rizicima implikacijama.
Arhitektonske odluke za softver koji podržava više zakupaca
Prije nego što proširite tablice ili učinite korisnička sučelja „prikladnim za zakupce“, trebate razjasniti granice sustava: koje komponente pripadaju platformi, koje se konfiguriraju po zakupcu, i koji podaci smiju biti centralno analizirani? U već postojećim korporativnim okruženjima važni su i priključci na ERP, DMS, CRM ili Identity Provider (IdP).
Single‑Tenant vs. Multi‑Tenant: funkcionalno isto, tehnički vrlo različito
Single‑Tenant znači: po zakupcu vlastita instanca (najmanje vlastita baza podataka, često i vlastiti aplikacijski stack). Multi‑Tenant znači: više zakupaca dijeli instance i infrastrukturu – uz logičko odvajanje. Multi‑Tenant često smanjuje napor za rollout i operacije, ali povećava zahtjeve za izolacijom, opsegom testiranja i observability (promatranje putem logova/metrika/tracinga).
Pragmatičan pristup je često: „Multi-Tenant u kodu, Single-Tenant u radu“ za kritične mandante. To znači: kod pravilno podržava kontekste mandanta, ali pojedinačni mandanti se opcionalno mogu pogoniti odvojeno (npr. iz razloga usklađenosti ili performansi). Za to je neophodno da su konfiguracija, deployment i monitoring od početka pripremljeni za obje varijante.
Mandantenkontext kao provodljivo arhitektonsko načelo
Mnoge greške nastaju zato što se kontekst mandanta samo na pojedinim mjestima „dodaje“ (npr. filteri u SQL-u, dodatni parametri u servisima). Stabilnije je ako kontekst mandanta postane provodljivo načelo:
- Svaki zahtjev ima jednoznačno utvrđenog mandanta (iz Token/SSO, subdomene, zaglavlja, klijentskog certifikata ili konfiguriranog endpointa).
- Kontekst mandanta se u serverskoj logici tretira kao obavezna informacija (nema default-mandanta, nema „ako je prazno, onda…“).
- Slojevi pristupa podacima i interfejsi forsiraju filtere po mandantu ili vezivanje mandanta, umjesto da ih čine opcionalnim.
- Logging i audit uključuju mandanta, korisnika/servisni račun i korelacijsku ID, kako bi operacije i podrška mogli rekonstruisati šta se desilo.
Ovaj pristup „kontekst mandanta prvo“ smanjuje skup grešaka koje se otkriju tek u radu: netač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 podršku više mandanata je način čuvanja podataka. To oblikuje backup/RESTore, migraciju, performanse i dokazivanje sigurnosti. U suštini postoje tri obrasca, koji se mogu i kombinovati.
1) Baza podataka po mandantu
Svaki mandant ima svoju vlastitu bazu podataka (ili vlastiti klaster baza). Prednosti: vrlo jasna izolacija, jednostavan RESTore po mandantu, dobra osnova za diferencirane prozore održavanja. Nedostaci: veći napor oko provisioninga, više veza, više migracija sheme i veća složenost u radu (npr. monitoring preko mnogih baza).
Tipični slučajevi upotrebe: vrlo strogi zahtjevi usklađenosti, mandanti sa značajno različitim količinama podataka ili slučajevi u kojima mandanti trebaju različite release-cikluse. Administrativno relevantno: potreban vam je robusna automatizacija za schema-updates, index-management, backups i rechte – inače se napor eksponencijalno povećava s brojem mandanata.
2) Shema po mandantu
Jedan serverski DB, ali po mandantu vlastita shema (ili namespace). To je srednji nivo izolacije: bolje od čistih row-filtera, ali manje „težak“ od kompletnih baza podataka. Backup/RESTore po mandantu je, ovisno o tehnologiji baze, moguć, ali ne uvijek trivijalan. Migracije je lakše koordinisati nego kod „DB po mandantu“, ali broj objekata ostaje visok.
Važno za rad: provjerite rano kako alati za monitoring, backup i migraciju rade s mnogim shemama, i da li standardno izvještavanje i BI pristupi mogu shema-preko-shema pravilno raditi bez narušavanja sigurnosnog okvira.
3) Zajedničke tabele s Tenant-ID (redom zasnovana separacija)
Svi mandanti dijele tabele; svaki red nosi Tenant-ID. To je u mnogim slučajevima efikasno, smanjuje broj objekata i pojednostavljuje globalne migracije. Istovremeno raste odgovornost aplikacije i/ili baze da pouzdano provodi separaciju.
Ako koristite razdvajanje po redovima, trebate posebno ozbiljno shvatiti dvije stvari:
- Tehnička provedba: Ne oslanjajte se samo na „mi svugdje filtriramo prema Tenant-ID“. Koristite, gdje je moguće, mehanizme baze podataka kao što su Row-Level Security (RLS; filtriranje redova na strani baze podataka zasnovano na kontekstu sesije ili ulogama), Views ili Security-Policies. Koja opcija odgovara, ovisi o bazi podataka.
- Međumandantske nuspojave: Veliki mandanti mogu utjecati na indekse, stopu pogodaka u cacheu i ponašanje zaključavanja. To nije kriterij za odbacivanje, ali mora se uzeti u obzir pri planiranju kapaciteta i testiranju.
Hibridni modeli: češće realističniji od „entweder/oder“
U praksi su uobičajeni hibridni modeli: ključne transakcije u zajedničkim tablicama (za jednostavna ažuriranja), posebno osjetljivi podaci u odvojenim bazama podataka ili shemama, kao i centralno područje „Control Plane“ za upravljanje mandantima, naplatu, feature-flagove i globalnu konfiguraciju. Bitno je da su te granice dokumentirane i tehnički osigurane.
Dozvole i identiteti: Mandant, Rolle, Scope
Sposobnost rada sa mandantima stoji ili pada s pouzdanim konceptom autorizacije. Za operativu manje je važno koliko je model elegantan, a više je važno je li u svakodnevnom radu provjerljiv i dijagnosticiran: Zašto je korisnik X mogao izvršiti akciju Y? Koja uloga je djelovala? Koja politika je odlučila?
SSO i dodjela mandanta: SAML 2.0, OIDC i direktoriji
U enterprise okruženjima često se koristi Single Sign-on (SSO). SSO znači da se autentikacija odvija preko centralnog Identity Provider-a, a aplikacija samo provjerava Token-e/Assertion-e. Uobičajeni su SAML 2.0 (zasnovano na assertion-ima, često u klasičnim enterprise setup-ima) ili OpenID Connect (OIDC; bazirano na tokenima, često u modernijim IdP stogovima). Važno je: Dodjela mandanta mora biti nedvosmislena i otporna na manipulaciju.
Provjerene opcije:
- Mandant preko Issuer/IdP (po jedan IdP po mandantu) – vrlo jasno, ali organizacijski zahtjevnije.
- Mandant preko Claim/Attribut (npr. Tenant-ID u tokenu) – fleksibilno, zahtijeva čistu validaciju i mapiranje.
- Mandant preko Subdomain ili odvojenih endpoint-a – dobro za portale, smanjuje pogrešne upotrebe, ali mora uredno raditi s SSO-Redirect-ima.
Model uloga i administracija mandanta bez „Support-Tickets“
Čest izvor troškova je da svaka promjena mandanta (novi korisnik, nova uloga, nova dodjela lokacije) završi kao ručna intervencija. Cilj treba biti: Mandanti mogu sami upravljati svojim korisnicima i ulogama u definiranom okviru, bez potrebe da centralni administratori diraju svaku sitnicu.
U praksi su prikladne višeslojne uloge:
- Plattform-Admin (upravljaju okruženjem, vide metapodatke o mandantima, ne nužno podatke mandanta).
- Mandanten-Admin (upravljaju korisnicima, ulogama i konfiguracijom unutar mandanta).
- Fachrollen (npr. referent, voditelj tima, odobravanje).
- Tehnička servisna konta (za integracije, jobove, automatizaciju) s minimalnim pravima.
Operativno važno: Uloge trebaju biti verzionirane i auditabilne. Ako se dozvole „samo tako“ mijenjaju direktnim updateom ili netrakiranom konfiguracijom, gubite sljedivost – i time vrijeme pri auditima i incidentima.
Schnittstellen und Integration: Multitenant podrška ne završava na API-Gateway
Mnoge digitalne poslovne solucije žive od integracija: ERP, DMS, CRM, Data Warehouse, partner portali, povezivanje mašina. Multitenant podrška mora zato biti dosljedno provedena i na interfejsima. To se tiče REST-APIs (HTTP-bazirani interfejsi), Eventing/Queues, datotečnih interfejsa i E-Mail-/Webhook-procesa.
REST-API: Tenant-Scoping kao ugovor
Kod REST-API-ja ključno je kako se tenant određuje u requestu. Uobičajeni obrasci su subdomain/host, header s tenantom ili claim u Access Tokenu. Važno je da to ne ostane samo konvencija, nego bude dokumentirano i server-side nametnuto kao sastavni ugovorni dio API-ja.
Za operativni rad je također važno: 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 reproducibilno razjasniti slučajeve, a da ne diraju podatke drugih tenant-a.
Asynchrone Prozesse: Jobs, Queues und Scheduler mandantenfähig planen
Batch-Jobs, importi, generisanje izvještaja ili noćna usklađivanja često se izvršavaju asinkrono. Tu se miješanje tenant-a pojavljuje posebno lako, jer worker radi „u pozadini“ bez aktivnog korisničkog konteksta. Planirajte stoga:
- Veza posla s tenantom: Svaki job nosi Tenant-ID i „okidački kontekst“ (korisnik ili servisni račun).
- Ograničenja resursa: Veliki tenanti ne smiju potpuno dominirati obradom poslova (fairness, kvote, prioriteti).
- Tenant-odvojeni artefakti: Privremene datoteke, exporti, S3-buckets/putanje za share, e-mail templati i webhook-sekreti moraju se upravljati specifično po tenantima.
Betrieb und Sicherheit: Was Admins später wirklich brauchen
Multitenant podrška djeluje u operacijama kao multiplikator: jedna greška, loš deployment ili nejasan alarm može utjecati na mnoge tenante. Suprotno tome, platforma koja se uredno održava može brže i konzistentnije distribuirati nadogradnje. Ključno je da operacije i sigurnost ne budu „naknadno ugrađivane“, nego dio arhitektonskog dizajna.
Logging, Audit und Nachvollziehbarkeit
Za poslovni softver treba razlikovati dvije vrste logova:
- Tehničko logiranje: Greške, performanse, problemi pri integraciji, timeouti. Treba sadržavati tenant i korelacijsku ID kako bi se u distribuiranim komponentama transakcija mogla ponovno pronaći.
- Audit-logiranje: Tko je koju poslovnu akciju izvršio (npr. promjena osnovnih podataka, pokretanje exporta, dodjela prava)? Audit-logovi su sigurnosno relevantni i zahtijevaju jasne politike čuvanja i pristupa.
Važno: Audit nije „još jedan log“. Audit mora biti otporan na manipulacije, sljediv i moguće ga je analizirati. Istovremeno vrijedi načelo minimizacije podataka: ne svaka detaljna informacija treba trajno ići u audit, već činjenice potrebne za dokaz i rekonstrukciju.
Backup/Restore: Mandanten selektiv wiederherstellen können
Pitanje RESTore-a je lakmus test za vaš podatkovni model. Globalni backup se brzo kreira, ali šteta nastaje kada pojedinačni tenant prijavi gubitak podataka, a vi možete vratiti samo „sve ili ništa“. Ovisno o obrascu izolacije, različite strategije su smislenije:
- DB po tenantu: Vraćanje je najjasnije, ali zahtijeva orkestraciju kada se više baza podataka mora konzistentno vratiti (npr. baza podataka + pretraživački indeks + spremište datoteka).
- Shared DB: Vraćanje po tenantu je znatno složenije. Ovde pomažu tenant-specifični mehanizmi za izvoz/snapshot, pristupi Event-Sourcing-a ili dodatne zaštitne mjere (Soft-Deletes, verzioniranje, procesi odobrenja).
Za administratore je važna dokumentirana procedura: Koliko dugo traje RESTore? Koji sistemi su uključeni? Kako se testira da tenant ponovo radi „ispravno“ (Smoke-Tests, integracijske provjere)?
Patching i strategija nadogradnje: migracije šeme bez zastoja
Ključna prednost platformskih pristupa je sposobnost jedinstvenog izvođenja nadogradnji. To uspijeva samo ako planirate migracije šeme (izmjene struktura baze podataka) i nadogradnje aplikacija kao povezan proces. Dobra praksa je:
- Forward-kompatibilna Deployments: Nove verzije softvera mogu raditi sa starom šemom (kratko vrijeme), i/ili stari softver može raditi sa novom šemom. To smanjuje vrijeme zastoja.
- Migracije u malim koracima: Umjesto „Big Bang“ preslagivanja: dodavanje novih kolona, postupno backfill-anje podataka, tek kasnije uklanjanje starih struktura.
- Feature-Flags po tenantu: Funkcije se mogu aktivirati za odabrane tenante kako bi se ograničili rizici i omogućili kontrolisani rollout-i.
Za IT-upravu je važno: sposobnost ažuriranja je investicija. Ona štedi vrijeme kasnije kod sigurnosnih ažuriranja, promjena operativnog sistema, nadogradnji baza podataka i promjena integracija – dakle upravo u područjima koja tokom godina stvaraju troškove.
Provisioning i životni ciklus tenanta: od onboardinga do deaktivacije
Sposobnost za više tenanta je dovršena tek kada je životni ciklus u potpunosti promišljen. U svakodnevnom radu nisu važne samo nove instalacije, već i promjene: dodatne lokacije, novi Identity-Provideri, promjene ugovora, izvoz podataka i deaktivacije.
Onboarding: Šta bi trebalo biti automatizovano
Čist onboarding-proces smanjuje greške i opterećenje podrške. Tipične komponente:
- Kreirati tenanta (Tenant-ID, naziv, kontakt, status).
- Podesiti konfiguraciju (regija, jezik, vremenska zona, E-Mail-Domänen, branding ako je predviđen).
- Konfigurisati povezivanje identiteta (SSO-Metadaten, certifikati, Redirect-URLs).
- Obezbijediti inicijalne uloge i administratorske korisnike.
- Provisionirati tehničke resurse (Datenbank/Schema, Storage, Suchindex, Queues).
- Aktivirati monitoring i alarmiranje za tenanta.
Što je više toga reproducibilno automatizovano, to nastaje manje „posebnih slučajeva“. To nije samo efikasnost, već i redukcija rizika: ručni koraci su najčešći izvor nekonzistentnih konfiguracija.
Izvoz podataka i offboarding: potcijenjeno, ali sigurnosno kritično
Offboarding je pitanje sigurnosti i usklađenosti: koji podaci moraju biti izvozivi (npr. za primopredaju), koji podaci moraju biti izbrisani ili anonimizirani i kako se to dokazuje? Čak i bez specifičnog pravnog savjeta tehnički vrijedi: trebate jasne odgovornosti, definirane rokove i proces koji je reprodukovan.
Ako se podaci nalaze u više sistema (baza podataka, spremište datoteka, indeks pretrage, logovi, backupi), offboarding mora uzeti u obzir te slojeve. Posebno su backupi osjetljivi: potpuni brisanje iz historijskih backupova često praktično nije moguće. Tim važniji je koncept koji to transparentno opisuje (čuvanje, kontrola pristupa, rotacija) i koji podatke klijenata izvan produkcijskih sistema ipak adekvatno štiti.
Tipični problemi iz prakse – i kako ih izbjeći
Podrška za više klijenata rijetko zakaže spektakularno, češće zbog mnogih malih dizajnerskih propusta. Sljedeći obrasci grešaka redovno se pojavljuju u projektima:
- Tenant-ID kao „opciona“: Pojedini endpointi, jobovi 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 u prekidačima funkcionalnosti kasnije nisu rekonstruabilne. Rješenje: verzionirati konfiguraciju, auditirati promjene.
- Keševi koji prelaze granice klijenata: Keširanje bez Tenant-Key vodi do curenja podataka. Rješenje: ključ keša uvijek osjetljiv na klijenta; osjetljive podatke keširati kratko.
- Podrška ne može ograničiti problem: Nedostaje korelacija i metrike po klijentu. Rješenje: Korrelations-ID, tagovi klijenta u logovima/metrikama, jasni dashboardi.
- Migracije traju predugo: Velike preinake tablica blokiraju rad. Rješenje: inkrementalne migracije, procesi u pozadini, planiranje vremenskih prozora.
Ovi su punktovi manje „detalji za developere“ nego stvarnost operacija. Ko ih rano adresira, smanjuje kasnije troškove za hotfixove, hitne intervencije i nejasne odgovornosti.
Razvijanje poslovnog softvera s podrškom za više klijenata: kontrolna lista za pouzdane odluke
Ako u projektu postavljate smjernice, pomažu konkretna pitanja koja čine arhitekturu i operabilnost vidljivima:
- Koja izolacija je potrebna: tehnički (podaci), organizacijski (pristupi), operativno (prozori održavanja/opterećenje)?
- Kako se klijent jednoznačno određuje (SSO-Claim, poddomena, vlastiti endpoint)?
- Kako se izolacija provodi (mehanizmi u bazi podataka, centralni pristupni sloj, Policies)?
- Kako izgleda slučaj RESTore-a: po klijentu, s kojim zavisnostima, u kojem roku?
- Kako se izvode nadogradnje: migracija sheme, strategija rollbacka, feature-flagovi?
- Koja observability postoji: metrike po klijentu, audit, alarmiranje, runbookovi?
- Kako se integracije pokreću u multitenant režimu (servisni računi, secrets, ograničenja brzine, webhooks)?
Ova su pitanja namjerno formulirana iz operativne perspektive. Ako ih možete odgovoriti, obično ste i arhitektonski na stabilnom putu.
Zaključak: Podrška za više klijenata je operativno obećanje, a ne UI-funkcija
Višekorisničnost odlučuje o tome može li poslovni softver godinama biti ekonomski održiv i sigurno dalje razvijan. Srž posla leži u jasnim linijama razdvajanja: kontekst klijenta kao obaveza, pouzdana izolacija podataka, provjerljive ovlasti, sučelja koja podržavaju višekorisničnost i životni ciklus koji obuhvata provisioniranje, ažuriranja i offboarding. Ko postavi ove temelje uredno, dobiva u praksi: manje prekida zbog drifta konfiguracije, brža ažuriranja, jasniji procesi podrške i pouzdani dokazi prema internim i eksternim zahtjevima.
Ako želite konkretno procijeniti višekorisničnost za postojeće ili novo digitalno poslovno rješenje ili izraditi koncept migracije i arhitekture, prođimo zajedno strukturirano kroz okvirne uvjete:
U stručnom okruženju također značajnu ulogu igraju multi-tenant arhitektura i izolacija tenanta kada integracije, tokovi podataka i dalji razvoj moraju neometano surađivati.