?Termin SaaS pocho­dzi z języ­ka angiel­skie­go i jest skró­tem wyra­że­nia ?Software as a Service?. W języ­ku pol­skim jego odpo­wied­ni­kiem jest ter­min ?Oprogramowanie jako usłu­ga?. SaaS pole­ga na zdal­nym udo­stęp­nie­niu opro­gra­mo­wa­nia poprzez Internet. W mode­lu SaaS udo­stęp­nia­na jest nie tyle sama apli­ka­cja (nie nastę­pu­je uru­cho­mie­nie peł­nej apli­ka­cji na kom­pu­te­rze użyt­kow­ni­ka), lecz umoż­li­wia się inte­rak­cję z nią poprzez inter­fejs prze­glą­dar­ki inter­ne­to­wej. Sama apli­ka­cja znaj­du­je się na ser­we­rach dostaw­cy SaaS.?

Jednak w pra­sie i nie tyl­ko poja­wia­ją się pew­ne mity o zale­tach tej archi­tek­tu­ry. Jakie?

Model aplikacji w architekturze SaaS

Zanim wgłę­bi­my się w niu­an­se zalet i dema­go­gii SaaS powie­my sobie co nie­co o mode­lu archi­tek­tu­ry opro­gra­mo­wa­nia i integracji.

Praktycznie każ­de opro­gra­mo­wa­nie moż­na zapre­zen­to­wać w posta­ci jak na powyż­szym dia­gra­mie, od naj­niż­szej war­stwy kolej­no mamy:

1. Dane ? skła­do­wa­ne infor­ma­cje o prze­twa­rza­nych przez opro­gra­mo­wa­nie fak­tach (np. nazwa fir­my, adres, telefon, …)

2. Model dzie­dzi­ny ? model infor­ma­cyj­ny repre­zen­tu­ją­cy poję­cia i związ­ki pomię­dzy poję­cia­mi, któ­ry­mi ope­ru­je fir­ma korzy­sta­ją­ca z opro­gra­mo­wa­nia, poję­cia wyma­ga­ją­ca zacho­wa­nia (np. reje­stru­je­my to, że kon­tra­hen­ci skła­da­ją zamówienia)

3. Logika opro­gra­mo­wa­nia ? to kom­plet reguł i pro­ce­sów biz­ne­so­wych, któ­re cechu­ją daną fir­mę a tak­że regu­ły prze­twa­rza­nia danych i współ­pra­cy pojęć w mode­lu dzie­dzi­ny (np. spo­so­by nali­cza­nia rabatów)

4. Interfejs użyt­kow­ni­ka ? to część opro­gra­mo­wa­nia, z któ­ra bez­po­śred­nio ma do czy­nie­nia użyt­kow­nik, ostat­nio naj­czę­ściej jest to prze­glą­dar­ka internetowa.

Powyższy dia­gram przed­sta­wia dwa pakie­ty opro­gra­mo­wa­nia, jeden poza fir­mą ozna­czo­ny SaaS. Interfejs użyt­kow­ni­ka to prze­glą­dar­ka inter­ne­to­wa użyt­kow­ni­ka więc umiesz­czo­ny został na dia­gra­mie został poza obsza­rem SaaS.

Dwie czer­wo­ne linie z gro­ta­mi poka­zu­ją dwie klu­czo­we rela­cje pod­czas ewen­tu­al­nej integracji.

Modele dzie­dzi­ny opi­su­ją naszą fir­mę dla­te­go powin­ny być takie same w każ­dej uży­wa­nej wewnątrz jed­nej fir­my apli­ka­cji. W prze­ciw­nym wypad­ku wymia­na danych (inte­gra­cja róż­nych sys­te­mów) będzie utrud­nio­na lub wręcz nie­moż­li­wa. W wie­lu przy­pad­kach inte­gra­cję opro­gra­mo­wa­nia nadal reali­zu­je się poprzez się­ga­nie jed­nej apli­ka­cji do danych dru­giej (tam gdzie nie ma innej moż­li­wo­ści i jest to legal­ne!, pra­wi­dło­wą for­mą inte­gra­cji jest jed­nak sto­so­wa­nie stan­dar­do­wych inter­fej­sów np. udo­stęp­nio­nych przez pro­du­cen­ta dane­go opro­gra­mo­wa­nia inter­fej­sów komunikacyjnych).

Tyle na wstę­pie. Pozostałe poka­za­ne rela­cje poka­zu­ją ogól­nie komu­ni­ko­wa­nie się warstw opro­gra­mo­wa­nia o czym w dal­szej części.

Mity SaaS

W sie­ci uka­za­ło się pew­ne opra­co­wa­nie, nie przy­ta­czam tego źró­dła gdyż nie jest moim celem kry­ty­ka tej kon­kret­nej pra­cy a pole­mi­ka z tego rodza­ju opi­sa­mi. Ale po kolei

Mit 1

?Główną zale­tą SaaS jest moż­li­wość natych­mia­sto­we­go roz­po­czę­cia korzy­sta­nia z apli­ka­cji bez koniecz­no­ści zaku­pu ser­we­rów, opro­gra­mo­wa­nia i żmud­ne­go pro­ce­su jej wdrożenia?

Prawdą jest, że nie ma potrze­by zaku­pu ser­we­rów i opro­gra­mo­wa­nia ale stwier­dze­nie, że nie potrzeb­ny jest pro­ces wdro­że­nia jest już fał­szy­we gdyż każ­dy pro­gram nale­ży spa­ra­me­try­zo­wać wpro­wa­dza­jąc dane zwią­za­ne z kon­ta­mi użyt­kow­ni­ków i ich upraw­nień oraz, na ile to moż­li­we, dopa­so­wać model danych (dzie­dzi­ny).

Często sły­szę, że ?nasze opro­gra­mo­wa­nie ma już wbu­do­wa­ny refe­ren­cyj­ny model danych Państwa bran­ży powsta­ły na pod­sta­wie naszych wie­lo­let­nich doświad­czeń?. Co nie zmie­nia fak­tu, że mało znam wdro­żeń, w któ­rych nie kory­go­wa­no i nie doda­wa­no lub mody­fi­ko­wa­no by pól w bazach danych. Do tego docho­dzi inte­gra­cja nowe­go opro­gra­mo­wa­nia z już wyko­rzy­sty­wa­nym w fir­mie co rzad­ko kie­dy jest try­wial­nym zajęciem.

Mit 2

?Prostota pra­cy z apli­ka­cją i zarzą­dza­nia nią; apli­ka­cje SaaS są dobrze zapro­jek­to­wa­ne pod wzglę­dem uży­tecz­no­ści, co pozwa­la skon­cen­tro­wać się na wyko­na­niu zada­nia, a nie na ?wal­ce z aplikacją?

Te apli­ka­cje niczym się nie róż­nią od tych, któ­re mamy już wewnątrz fir­my (zakła­da­jąc, że nie są to roz­wią­za­nia z przed wie­lu lat). Ok kil­ku już lat nowo­cze­sne opro­gra­mo­wa­nie coraz czę­ściej two­rzo­ne jest do pra­cy przez prze­glą­dar­kę i jest dobrze zapro­jek­to­wa­ne. Sugerowanie, że inne niż SaaS jest złe to demagogia.

Mit 3

?Oszczędność na kosz­tach wspar­cia i ser­wi­su ? fir­ma korzy­sta­ją­ca z SaaS nie musi utrzy­my­wać roz­bu­do­wa­ne­go dzia­łu IT czy korzy­stać z zewnętrz­nych usług tego typu.?

Jeżeli mamy już jakie­kol­wiek opro­gra­mo­wa­nie w fir­mie to mamy tak­że dział IT (nie waż­ne czy wła­sny czy w posta­ci umo­wy z fir­ma zewnętrz­ną), tak więc to stwier­dze­nie doty­czy wyłącz­nie przy­pad­ku gdy całe opro­gra­mo­wa­nie mamy w mode­lu SaaS. Nie zmie­nia to fak­tu, że pro­sty tak zwa­ny help-desk i tak fir­ma powin­na posiadać.

Mit 4

?Dostęp do zawsze aktu­al­nej wer­sji opro­gra­mo­wa­nia ? brak koniecz­no­ści doko­ny­wa­nia aktu­ali­za­cji apli­ka­cji na kom­pu­te­rach użytkowników?

Każde opro­gra­mo­wa­nie wyma­ga od cza­su do cza­su wymia­ny na now­sze, nawet to od dostaw­cy SaaS. Tu co naj­wy­żej pro­ces ten może prze­bie­gać spraw­niej ale występuje.

Mit 5

?Możliwość korzy­sta­nia z apli­ka­cji z dowol­ne­go kom­pu­te­ra i z dowol­ne­go miejsca?

Jeżeli posia­da­ne na wła­sność opro­gra­mo­wa­nie wyma­ga do pra­cy tyl­ko prze­glą­dar­ki WWW to tak­że może­my je udo­stęp­nić poza sie­dzi­bą fir­my przez Internet.

Mit 6

?Gwarancja bez­pie­czeń­stwa ? usłu­gi SaaS świad­czo­ne są przez sys­te­my infor­ma­tycz­ne zabez­pie­czo­ne fizycz­nie i logicz­nie tak, by spro­stać naj­bar­dziej wyma­ga­ją­cym klien­tom (z cze­go korzy­sta­ją tak­że mniej wyma­ga­ją­cy klienci).?

Tu podob­nie jak mit 5, nie ma żad­nych prze­sła­nek by twier­dzić, że tyl­ko zewnętrz­na fir­ma może zapew­nić bez­pie­czeń­stwo. Po dru­gie zgod­nie z zasa­dą ?to cze­go uży­wa­my w fir­mie powin­no być wystar­cza­ją­co dobre a nie naj­lep­sze? doty­czy tak­że opro­gra­mo­wa­nia, nie ma potrze­by prze­pła­ca­nia dla idei.

Mit 7

?Bezpieczeństwo danych ? dostaw­ca SaaS two­rzy kopie bez­pie­czeń­stwa danych klientów?.

A my nie two­rzy­my (jeśli tyl­ko chcemy)?.

Mit 8

?Skalowalność ? roz­wią­za­nia SaaS łatwo ska­lu­ją się wraz ze wzro­stem zapo­trze­bo­wa­nia ze stro­ny klien­ta, ponie­waż dzia­ła­ją na plat­for­mie zapro­jek­to­wa­nej do obsłu­gi tysię­cy użytkowników?.

Mało któ­ra fir­ma tak uro­śnie w cią­gu okre­su użyt­ko­wa­nia jed­nej wer­sji opro­gra­mo­wa­nia. Ten argu­ment tak­że jest trosz­kę na wyrost.

Mit 9

?Duża dostęp­ność ? SaaS to usłu­gi, któ­re muszą być dostęp­ne bez przerwy.?

Usługodawca fak­tycz­nie musi mieć taka nie­za­wod­ność ale czy każ­dy jego tak­że klient musi? Bo na pew­no tu za to zapłaci.

Mit 10

?Dostawcy zapew­nia­ją naj­wyż­szy poziom nie­za­wod­no­ści łącz­nie z sys­te­ma­mi zapew­nie­nia cią­gło­ści pra­cy na wypa­dek klęsk żywio­ło­wych lub poważ­nych awa­rii (sys­te­my typu disa­ster recovery).?

To praw­da ale czy każ­da fir­ma tego wyma­ga? Swego cza­su ten argu­ment pod­no­szo­no przy pro­mo­wa­niu out­so­ur­cin­gu i opro­gra­mo­wa­nia w mode­lu ASP (w zasa­dzie ten sam model nie licząc technologii).

Mit 11

?SaaS spraw­dza się tak­że dla­te­go, że ofe­ru­je dużą moc obli­cze­nio­wą ? moc, na któ­rej budo­wę i utrzy­ma­nie fir­my MSP nie mogą sobie czę­sto pozwolić.?

To stwier­dze­nie mnie naj­bar­dziej zasta­na­wia gdyż SaaS na ryn­ku dale­ko ma do ?spraw­dze­nia się?.

No więc co z tym SaaS?

Przytoczmy dla uła­twie­nia model:

Nieomówiona wcze­śniej zie­lo­na linia pomię­dzy blo­ka­mi Logika apli­ka­cji to zale­ca­na meto­da (komu­ni­ko­wać się powin­ny ze sobą war­stwy logi­ki inte­gro­wa­nych apli­ka­cji) inte­gra­cji opro­gra­mo­wa­nia np. w posta­ci webse­rvi­sów czy tak zwa­ne­go API. Nie wgłę­bia­jąc się w szcze­gó­ły pojęć webse­rvi­ce czy API co do zasa­dy popraw­na inte­gra­cja opro­gra­mo­wa­nia pole­ga na komu­ni­ko­wa­niu się logi­ki opro­gra­mo­wa­nia a nie ?zaglą­da­niu do cudzych danych? (to temat na osob­ny esej).

Popatrzmy na nasze, posia­da­ne już opro­gra­mo­wa­nie. Niewątpliwie ma sens roz­wa­ża­nie naby­cia (uży­wa­nia) kolej­ne­go w try­bie SaaS w przy­pad­ku gdy mamy pew­ność, że:

• inte­gra­cja nowe­go SaaS i już posia­da­ne­go opro­gra­mo­wa­nia będzie prze­bie­ga­ła na linii ozna­czo­nej zie­lo­no czy­li za pośred­nic­twem mecha­ni­zmów wbu­do­wa­nych w oprogramowanie

• mode­le dzie­dzi­ny (bazy danych) będą na tyle zbli­żo­ne (bo na iden­tycz­ność bym nie liczył), że moż­li­wa będzie wymia­na danych bez utra­ty infor­ma­cji (np. jed­na apli­ka­cja prze­cho­wu­je dane mia­sto i kod w jed­nym polu a dru­ga w osob­nych polach).

Trudno tu opi­sać wszyst­kie niu­an­se tech­nicz­ne w korzy­sta­niu z opro­gra­mo­wa­nia w mode­lu SaaS jed­nak po pierw­sze korzy­ści nie są oczy­wi­ste po dru­gie te korzy­ści mogą być praw­dzi­we ale nale­ży to sprawdzić.

Powyższy model wska­zu­je na klu­czo­we pro­ble­my do roz­wią­za­nia, mam nadzie­ję każe się zasta­no­wić i kry­tycz­nie podejść do ofert. Nie jestem prze­ciw­ni­kiem SaaS jestem prze­ciw­ni­kiem kate­go­rycz­nych stwier­dzeń, że ?SaaS jest dobre? a po dru­gie jako ana­li­tyk zasta­na­wiam się dla­cze­go to ?jedy­nie słusz­ne roz­wią­za­nie? nadal nie zawo­jo­wa­ło rynku.

Podsumowując wyda­je mi się, że w przy­szło­ści SaaS zaist­nie­je rów­no­le­gle z opro­gra­mo­wa­niem śred­niej kla­sy sprze­da­wa­nym maso­wo, czy­li opro­gra­mo­wa­niem z pudeł­ka. Skoro moż­na kupić i uży­wać opro­gra­mo­wa­nie za kil­ka­set zło­tych bez żad­ne­go ?wdro­że­nia? to zna­czy, że moż­na to opro­gra­mo­wa­nie tak­że wydzier­ża­wić. Jednak nie liczył bym na to, że lide­rzy w swo­ich seg­men­tach ryn­ku, budu­ją­cy swo­ją prze­wa­gę na róż­ni­cach w sto­sun­ku do kon­ku­ren­tów sko­rzy­sta­ją takich gotowców.

Jest oczy­wi­ście pew­na sfe­ra zasto­so­wań nie klu­czo­wych, takich jak np. ser­we­ry pocz­ty elek­tro­nicz­nej, któ­ra dosko­na­le nada­je się do ofe­ro­wa­nia w ten spo­sób ale tak to jest już od lat robio­ne od lat. Korzystanie z kon­ta pocz­to­we­go u pro­vi­de­ra inter­ne­to­we­go to nic inne­go jak SaaS, w szcze­gól­no­ści gdy z pocz­ty korzy­sta­my przez WWW. Podobnie jak z Google docs.

Kończąc, moim zda­niem SaaS to zna­czą­ca alter­na­ty­wa dla zaku­pu opro­gra­mo­wy­wa­nia in-house (do zain­sta­lo­wa­nia ?u sie­bie?) ale war­to takie wdro­że­nie prze­ana­li­zo­wać dokład­nie tak samo jak każ­de inne czy­li wyko­nać ana­li­zę wyma­gań na opro­gra­mo­wa­nie i dopu­ścić tak­że dostaw­ców SaaS koniecz­nie jed­nak nale­ży prze­pro­wa­dzić ana­li­zę dzie­dzi­ny sys­te­mu i upew­nić się, że ofe­ro­wa­ne opro­gra­mo­wa­nie pozwa­la na inte­gra­cję a już posia­da­ny­mi roz­wią­za­nia­mi gdyż tu moż­li­wo­ści dopa­so­wa­nia są z regu­ły znacz­nie mniejsze.

Notatka: Minąl mie­siąc od cza­su gdy napi­sa­łem ten arty­kuł i widze nie ja jeden mam podob­ne wat­pli­wo­ści, (treśc j.ang.): SaaS chal­len­ge – Who’s data is it anyway?