SaaS: oprogramowanie plus usługi

Zakup infrastruktury, aplikacji, wdrożenie systemu i jego dostosowanie są tylko środkiem, który ma usprawnić procesy zachodzące w firmie. Celem jest potrzeba rozwiązania problemów biznesowych. Ta prawda leży u podstaw koncepcji SaaS, czyli Software as a Service oraz S+S, czyli Software + Service.

Zakup infrastruktury, aplikacji, wdrożenie systemu i jego dostosowanie są tylko środkiem, który ma usprawnić procesy zachodzące w firmie. Celem jest potrzeba rozwiązania problemów biznesowych. Ta prawda leży u podstaw koncepcji SaaS, czyli Software as a Service oraz S+S, czyli Software + Service.

Założenie SaaS jest proste. Tworzymy system, którego funkcjonalność dostępna jest za pośrednictwem Internetu. Klient nie instaluje infrastruktury, wszystkie informacje są dostępne u dostawcy aplikacji SaaS. Na pierwszy rzut oka taka koncepcja przypomina znany model ASP, w którym usługodawca udostępnia serwery z aplikacjami. Różnica polega na tym, że SaaS zakłada, iż w ramach jednej instalacji (jednego serwera, procesu w pamięci, jednej bazy danych itp.) realizowana jest obsługa wielu klientów.

Załóżmy, że wdrożenie aplikacji w firmie wymaga instalacji serwera bazodanowego. Jeśli podobną potrzebę ma 50 firm, to każda z nich musi kupić 50 serwerów, zatrudnić administratorów, wykonać wdrożenie. W efekcie okaże się, że sumaryczne obciążenie generowane przez użytkowników tych wszystkich firm mogłoby być obsłużone nie przez 50 serwerów, ale przez 4 o większej mocy. Wiedzą o tym doskonale dostawcy SaaS.

Oczywiście, aby model SaaS był możliwy, aplikacja musi być napisana tak, by w ramach jednej instancji mogło działać wiele niezależnych podmiotów, a przechowywane w bazach dane każdej z firm były naprawdę prywatne. Ponadto rozwiązanie musi mieć taką architekturę, aby można było łatwo ją rozszerzać i rozbudowywać. Model SaaS bardziej przypomina sprzedawanie dzwonków do telefonów komórkowych niż dużych systemów ERP z pełną asystą sprzedawcy i zewnętrznych konsultantów. W istniejących implementacjach SaaS stosunkowo rzadko udostępniane są "zintegrowane pakiety do rozwiązywania wszelkich problemów w przedsiębiorstwie". Zwykle producent aplikacji wybiera dla siebie pewną niszę i z myślą o niej opracowuje rozwiązanie, które może być rozbudowywane przez odpowiednią konfigurację.

Wygoda dla użytkownika

Bez wątpienia na modelu SaaS dużo zyskuje klient. Po pierwsze, aplikacje można zwykle wypróbować przed zakupem, bez konieczności instalacji jakiegoś oprogramowania w istniejącej infrastrukturze IT. Po drugie, klient zwykle płaci tylko za to, czego się używa. Po trzecie, proces wdrażania jest z reguły błyskawiczny - sprowadza się do konfiguracji i drobnych dostosowań procesu biznesowego. Dodatkowo w przypadku SaaS można podpisać "gwarancję na działanie" usługi, co jest bardzo kosztowne w tradycyjnym modelu sprzedaży oprogramowania. Z punktu widzenia kupującego ryzyko jest niższe - zawiera umowę na określoną niezawodność i dostępność procesów.

Rozwiązanie SaaS może być albo monolitem, albo agregacją innych usług dostępnych w tym modelu. Dostawca SaaS nie musi wszystkich elementów (modułów) systemu pisać samodzielnie, ale może wykorzystać ofertę innych dostawców. Obok dostawcy SaaS pojawia się grupa zwykle luźno z nim współpracujących firm wdrożeniowych i konsultantów, którzy doradzają przy strojeniu systemu, konfiguracji dodatkowych pul w bazie itp. Warto podkreślić, że co prawda czyste koncepcje SaaS zakładają, iż użytkownicy nie rozwijają własnego kodu, jednakże czasami możliwe jest dopuszczenie takich modyfikacji. Technologia .Net pozwala na silną izolację kodu, dzięki czemu konsultanci mogą dostarczyć klientowi moduły plug-in rozszerzające funkcjonalność systemu.

Oprogramowanie SaaS musi być uruchomione w ramach pewnej oferty hostingowej. Taka oferta oprócz bazowych możliwości (ASP .Net, , pasmo itp.) może też oferować komponenty wyższego poziomu. Należy zauważyć, że każda aplikacja SaaS musi mieć pewne wspólne elementy, by model biznesowy mógł działać prawidłowo. Jest to np. billing, mechanizmy odblokowywania/blokowania poszczególnych funkcjonalności, dodawanie użytkowników w ramach podmiotu, pomiary SLA itp. Oprócz takich komponentów "hoster" może oferować więcej usług, np. centralne rejestrowanie wyjątków, mechanizmy logowania czy nawet biznesowy "databinding". Warto podkreślić, że w takim układzie także dostawca usług korzysta z efektu skali, oferując infrastrukturę wielu autorom aplikacji SaaS.

Na marginesie warto wspomnieć, że obecnie już niektórzy dostawcy prostego hostingu ASP .Net przyciągają deweloperów i klientów tym, że np. oferują dodatkowe kontrolki czy aplikacje ułatwiające konstrukcję podstawowych stron. Wzbogacanie infrastruktury związanej z SaaS jest naturalną ewolucją (na polskim rynku elementy do hostingu aplikacji SaaS oferuje warszawska firma DCS).

Jeden system dla wielu

Głównym wyzwaniem przy pisaniu oprogramowania SaaS jest taka konstrukcja, by aplikacja mogła równocześnie obsługiwać różne podmioty, każdy o trochę innych potrzebach. Problem ten można podzielić na trzy elementy - adaptacja interfejsu użytkownika, procesu biznesowego i danych.

Stworzenie modyfikowalnego interfejsu użytkownika jest stosunkowo najprostsze. Praktycznie wszystkie jego elementy mogą być sterowane przez metadane, które określają, że np. na formatce będzie dostępna nowa kolumna w siatce (sama kontrolka potrafi dostosować się do listy pól). W ASP .Net można użyć stylów CSS, skórek (definiowanych w warstwie metadanych) lub dodać własne handlery modyfikujące renderowane dokumenty HTML, tak by część obsługiwana przez dostawców SaaS nie różniła się graficznie od pozostałych elementów strony firmowej.

Dostosowywanie procesu biznesowego także nie jest zbyt skomplikowane. Jeżeli twórca rozwiązania wykorzysta Windows Workflow Foundation (API pozwalające realizować przepływy), to główny przebieg procesu może być sterowany za pośrednictwem dokumentu XAML, określającego orkiestrację (czy przejścia stanów) między akcjami zdefiniowanymi w ramach systemu SaaS. Tak samo można wymieniać wszelkiego rodzaju reguły definiujące np., kiedy wykonywany jest dany przepływ, albo jaką postać ma warunek używany w ramach procesu biznesowego. Wszystko to sprawia, że wystarczy w warstwie metadanych właściwych dla danego podmiotu zapisać specyficzne dla niego dokumenty XML.

Najwięcej problemów związanych jest z danymi. Wynika to z dwóch czynników - potrzeby zachowania wysokiego poziomu ich izolacji, a równocześnie zapewnienie mechanizmów pozwalających na niezależne rozszerzanie schematu bazy o dodatkowe pola.

Izolacje można zapewnić, wykorzystując oddzielne "pojemniki" dla każdego podmiotu korzystającego z ofert SaaS. Takim pojemnikiem może być oddzielna baza danych czy schemat w ramach jednej bazy, gdzie tylko uprawniony podmiot ma dostęp. Wtedy rozbudowa o dodatkowe kolumny jest dosyć prosta, ale całe rozwiązanie nie jest wydajne w sensie ekonomicznym. Znacznie lepiej jest umieszczać dane różnych podmiotów w jednej tabeli. Dzięki temu mamy jedną aplikację, jedną bazę itp. Aby zapewnić izolację, można np. zdefiniować widoki, gdzie obowiązkowym warunkiem jest sprawdzenie, czy SID (identyfikator używany przy logowaniu zintegrowanym i dostępny w danej sesji) jest taki sam jak wpisany w kolumnie. Jeżeli dostęp do danych odbywa się zawsze za pośrednictwem widoku, to nie ma możliwości, by inny podmiot uzyskał dostęp do informacji posiadanych przez konkurenta. Dane szczególnie krytyczne mogą być dodatkowo szyfrowane przez serwer bazodanowy.


TOP 200