Interno orodje ali SaaS produkt? Arhitekturne odločitve niso enake

Interno orodje in SaaS produkt lahko uporabljata podobne zaslone in tehnologije, vendar nimata enakih arhitekturnih zahtev. Interno orodje deluje za znano skupino znotraj nadzorovanega procesa. SaaS mora samostojno sprejemati neznane uporabnike, ločevati organizacije, obravnavati zaračunavanje, zlorabe, podporo in spremembe produkta.

Odločitev zato ni samo, kdo bo aplikacijo uporabljal danes. Pomembno je, kakšno zaupanje, izolacijo in operativno odgovornost mora sistem zagotavljati.

Znani uporabniki in odprt trg

Pri internem orodju običajno poznate organizacijo, način dela in odgovorne osebe. Uporabnike lahko doda administrator, usposabljanje pa je del internega procesa.

Javni SaaS mora predvidevati, da uporabnik:

• nima osebnega uvajanja;
• ne pozna notranje terminologije;
• lahko napačno razume funkcijo;
• pričakuje samostojno obnovitev dostopa;
• lahko pride iz drugega jezika ali časovnega pasu;
• lahko sistem uporablja na nepričakovan način.

To vpliva na onboarding, pomoč, preverjanje vnosov, sporočila ob napakah in dokumentacijo.

Interno orodje sme odražati specifičen proces ene ekipe. SaaS mora dovolj jasno opisati pravila, da jih lahko razume širša skupina.

Prijava in model zaupanja

Pri internem sistemu je lahko dostop vezan na službeni račun, povabilo ali omrežje organizacije. Kljub temu potrebuje ustrezne pravice in sledljivost.

SaaS običajno zahteva širši nabor poti:

• registracijo;
• potrditev identitete ali e-naslova;
• obnovitev dostopa;
• pridružitev organizaciji;
• odstranitev uporabnika;
• prenos lastništva;
• obravnavo sumljive uporabe.

Ne začnite pri zaslonu za prijavo. Najprej določite model zaupanja: kdo lahko ustvari organizacijo, kdo povabi druge, kdo vidi katere podatke in kdo lahko izvede nepovratno dejanje.

Ena organizacija ali več najemnikov

Interno orodje lahko uporablja eno podatkovno okolje za eno organizacijo. SaaS praviloma potrebuje večnajemniški model, v katerem so podatki posameznih strank dosledno ločeni.

Izolacija ne sme biti samo vizualni filter v uporabniškem vmesniku. Pravila morajo veljati tudi v bazi, strežniških funkcijah, datotekah, iskanju, poročilih in administraciji.

Vprašanja vključujejo:

• Kako je vsak zapis povezan z organizacijo?
• Ali lahko uporabnik pripada več organizacijam?
• Kdo lahko podatke izvozi?
• Kako deluje brisanje organizacije?
• Ali podpora lahko dostopa do podatkov in pod katerimi pogoji?
• Kako so ločene varnostne kopije ali obnovitve?

Odgovori oblikujejo podatkovni model, zato jih je drago dodajati šele po tem, ko je produkt že zgrajen kot enouporabniško orodje.

Vloge naj opisujejo dejanska pooblastila

Nazivi »admin«, »član« in »gledalec« niso dovolj, dokler ni jasno, kaj lahko vsak stori.

Za vsako pomembno dejanje določite:

• kdo ga lahko vidi;
• kdo ga lahko izvede;
• kdo ga lahko potrdi;
• ali je dejanje zabeleženo;
• ali ga je mogoče razveljaviti.

Interno orodje lahko sledi obstoječi organizacijski strukturi. SaaS mora vloge oblikovati dovolj splošno, da ustrezajo različnim strankam, ne da bi vsaka potrebovala razvoj po meri.

Zaračunavanje spremeni več kot checkout

Interno orodje običajno nima produktnega obračunavanja. SaaS lahko potrebuje pakete, preizkusna obdobja, omejitve uporabe, račune, menjave naročnine in obravnavo neuspešnih plačil.

Zaračunavanje vpliva na dostop:

• Kaj se zgodi ob poteku naročnine?
• Ali podatki ostanejo dostopni?
• Kdo lahko spremeni paket?
• Katere funkcije ali količine so omejene?
• Kako sistem obravnava zamudo pri plačilu?

Če plačila niso del prve izdaje, mora biti odlog zavesten. Pri načrtovanju SaaS MVP-ja jih vključite le, kadar preverjajo bistveno predpostavko ali so nujna za realen potek.

Revizijska sled in odgovornost

Pri pomembnih podatkih ni dovolj poznati trenutnega stanja. Vedeti morate, kdo je spremembo izvedel, kdaj in včasih tudi kaj je bilo prej.

Interno orodje potrebuje revizijsko sled glede na tveganje procesa. SaaS jo lahko potrebuje za podporo, varnost, reševanje sporov in zahteve strank.

Beležite pomembna dejanja, ne vsakega premika miške. Posebej pomembne so spremembe pravic, brisanje, izvoz, finančna dejanja in posegi podpore.

Podpora je del arhitekture

Interna ekipa lahko težavo sporoči neposredno razvijalcu ali skrbniku. Pri SaaS-u mora obstajati operativni način za:

• prepoznavanje prizadetega uporabnika;
• varen vpogled v stanje;
• pregled napak in dogodkov;
• ponovno izvedbo varnega postopka;
• obveščanje o incidentu;
• omejitev zlorabe.

Administratorska orodja, beleženje napak in uporabniški kontekst zato niso samo dodatki po objavi. So del sposobnosti produkta za delovanje.

Različna sta tudi objava in razvoj produkta

Interno orodje se lahko uvaja usklajeno z eno ekipo. Spremembe je mogoče napovedati, uporabnike usposobiti in proces začasno prilagoditi.

SaaS potrebuje previdnejše migracije, združljivost obstoječih podatkov, postopno uvajanje in jasna sporočila ob spremembah. Vsaka nova funkcija poveča tudi dokumentacijo, podporo in površino za napake.

Pred začetkom zato določite, ali gradite rešitev za znano organizacijo ali produkt za več neodvisnih strank. Prehod je mogoč, vendar zahteva več kot spremembo domače strani in dodajanje naročnine.

Izdelava web aplikacij lahko obseg razdeli glede na uporabnike, podatkovni model in operativne zahteve. Za presojo konkretnega modela pošljite kratek opis prek kontakta.

← Nazaj na blog