Business Case dla Open Source – część druga, twarda

Data: 2013-12-31
Autor: Sebastian Konkol

Porządki i remanenty przed końcem roku trwają – u mnie także. Obiecałem – już, niestety, dość dawno – opublikowanie drugiej części Business Case dla Open Source. Obiecałem wtedy twarde, ilościowe podsumowanie dla dwóch, stosunkowo skrajnych modeli COTS (Commercial Off-the-Shelf) oraz OS (Open Source). Do dzieła więc.

Zakładając, że powód dla wdrożenia określonego rozwiązania informatycznego jest tak samo zasadny, bez względu na sposób realizacji takiego rozwiązania, sfera korzyści nie powinna różnicować dokonywanych wyborów. Sfera kosztów i ryzyka natomiast zależy silnie od tego wyboru. Skupię się więc na porównaniu COTS i OS w tej właśnie sferze. Podejście „prostolinijne” (żeby nie nazwać go naiwnym) jest skazane na porażkę – nie ma co porównywać kosztów licencji COTS z „bezpłatnością” OS lub kosztów maintenance COTS z „własną obsługą” OS. Uczciwe dokonanie takiego porównania wymaga wspięcia się na wyższy poziom abstrakcji, np. powodów dla których ponosi się koszty maintenance, czyli zabezpieczenia ciągłości wykorzystania rozwiązania informatycznego.

Jak dla każdego uzasadnienia biznesowego, należy przyjąć jakiś horyzont czasu, w którym warto rozpatrywać zwrot z inwestycji. W konsekwencji galopującego rozwoju technologii informatycznych, każde wdrażane rozwiązanie jest marketingowo przestarzałe już w momencie wdrożenia. Pozostawmy jednak w naszych rozważaniach minimum zdrowego rozsądku. Według praktyk szefów działów IT, spoglądając na informatykę z perspektywy inwestycji, struktura kosztów rzeczywiście ponoszonych ma pewną powtarzalność – średnio po trzech latach należy zainwestować tyle samo, ile inwestowało się podczas wdrożenia. Jeśli tak, to próba konstruowania uzasadnienia biznesowego zawierającego składnik rozwiązania informatycznego z horyzontem dłuższym niż 3 lata, jest po prostu nieuczciwa.

Jak wygląda wspólny mianownik kosztów, który pozwoli porównać OS i COTS? W mojej ocenie (szczegółowe „definicje” w poprzednim wpisie) powinien on wyglądać następująco:

  • Koszt sprzętu. Potraktujmy ten składnik kosztów jako referencyjny (X) – będę odnosił inne składniki do niego. Od projektu do projektu może się to różnić, ale zgrubne oszacowanie uśrednione można do niego odnosić. Teoretycznie koszt sprzętu powinien być porównywalny dla obu przypadków, ale zakup sprzętu w projektach COTS jest traktowany nieco inaczej, niż w projektach OS. Sprzęt „pod COTS” jest często dedykowany pod konkretne rozwiązanie, bo i tak stanowi nie tak wielką część sumy kosztów wdrożenia (sprzęt, licencje, usługi), a dodatkowo wdrażający obniżają swoje ryzyko przewymiarowując sprzęt (dorzucając moc obliczeniową „na wszelki wypadek” – wszak to oni później będą ponosić koszty prac utrzymaniowych). Efektem jest podniesienie kosztów sprzętu o średnio 10%, a dodatkowo brak możliwości jego wykorzystania przez inne systemy zamawiającego wdrożenie.
  • Licencje. Tutaj jest „nieuczciwie”, bo po stronie OS jest zero, a po stronie COTS – średnio – między 1,5X a 2X.
  • Usługi projektowe. Ten składnik jest najbardziej dyskusyjny i podlega największej zmienności. W dużej mierze zależy on od oczekiwanego przez zamawiającego poziomu „kupowanego” bezpieczeństwa po wdrożeniu – im wyższe, tym kosztowniejsze wdrożenie. W przypadku projektu OS ten składnik wynosi między 1X a 1,5X. W przypadku projektów COTS – od 0,5X do 1X.
  • Utrzymanie własne. Ten składnik kosztów dla COTS, w horyzoncie 3 lat, wynosi zwykle 0,1X, podczas gdy dla OS – 0,3X.
  • Utrzymanie zewnętrzne. Dla OS oznacza on zwykle ok. 30% sumy kosztów projektowych rocznie, czyli w horyzoncie 3 lat wynosi między 11X a 16X. Dla COTS zwykle jest to między 12% a 20% tej sumy, co daje w horyzoncie 3 lat między 9X a 22X.
  • Pozostałe koszty bezpośrednie i koszty pośrednie. Tutaj niewiele różnicuje projekty OS i COTS, a średnio można przyjąć, że każdy z nich oznacza X w horyzoncie 3 lat – w sumie 2X.

Grand Total? OS między 15X a 21X, podczas gdy COTS między 14X a 28X. Średnio więc są rozwiązania, których – w przypadku przyjęcia najbardziej optymistycznych założeń odnośnie wdrożenia – sumaryczne koszty są nieznacznie niższe, niż OS. W przypadku przyjęcia pesymistycznych założeń, COTS jest sumarycznie droższe od OS o ponad 30%.

Przy tej okazji warto podkreślić istotną cechę OS. OS jest określany jako Free Software. Nie odnosi się to jednak do kosztów, gdyż nie to było fundamentem ruchu, na którym „wyrosły” – mimo sprzeczności ideologicznych pomiędzy nimi – BSD, FSF, GNU i wiele innych. OS powinien być rozumiany jako wolne oprogramowanie – takie, którego wykorzystanie nie jest ograniczane warunkami komercyjnymi i walkami prawników. Bo oprogramowanie powinno być wolne – i tak w końcu się stanie.

Jeszcze trudniej, niż w odniesieniu do kosztów, jest w przypadku oszacowania ryzyka i wynikających z niego ewentualnych kosztów. W mojej opinii porównawczą ocenę ryzyka wdrożenia OS i COTS należy oprzeć na następujących kategoriach czynników ryzyka:

  • Rekompensata strat realnych. W przypadku strat finansowych, w których poniesienie był „zamieszany” system informatyczny, chciałoby się uzyskać od odpowiedzialnego za nie (często dostawcy systemu) pokrycie poniesionych strat. W przypadku OS nie ma takiej możliwości. Kropka. W przypadku COTS jednak taka możliwość jest czysto teoretyczna. O ile bowiem dostawca COTS w ogóle do czegoś się zobowiązuje (czytajcie licencje i regulaminy!), koszty ryzyka są wkalkulowane w wydatki na COTS (licencja, utrzymanie). Koszty zarządzania takim ryzykiem są więc realnie i tak ponoszone przez zamawiającego (bez względu na to, czy w konkretnym przypadku ryzyko się zmaterializuje), a możliwości odzyskania strat są wykluczane licencjami i regulaminami.
  • Potencjał rozwoju. Takie cechy oprogramowania jak modyfikowalność, interoperacyjność, elastyczność technologiczna to – w dzisiejszych warunkach – nie slogany marketingowe, ale twarda konieczność. W przypadku OS dostępne są wszystkie możliwości. W przypadku COTS – w najlepszym wypadku mocno ograniczone, a zwykle żadne.
  • Jakość działania. Wszystko to, co składa się na dostępność, stabilność, wydajność rozwiązań informatycznych – a co zależy od błędów w oprogramowaniu i sprawności ich usuwania – silnie warunkuje zdolności uzyskiwania korzyści z jego wdrożenia. Uzyskanie naprawy wymaga zgłoszenia błędu przez zamawiającego i usunięcia błędu przez dostawcę. W przypadku OS nie ma KPI na ten proces, a nawet nie ma gwarancji, że błąd zostanie naprawiony. W przypadku COTS wiadomo, gdzie zgłosić błąd. I tyle. Statystyki gromadzone od ponad dekady i często „prześwietlane” są tu bezlitosne – błędy w OS usuwane są w czasach wielokrotnie krótszych, niż błędy w COTS.
  • Bezpieczeństwo danych i systemu. Bardzo podobna sytuacja dotyczy problemów z bezpieczeństwem danych, szczelnością systemów i ich odpornością na „włamania”, wirusy itp. Tu znów statystyki są nieubłagane, ale skrócenie czasów usunięcia błędu w OS w stosunku do COTS mierzone jest często w rzędach wielkości (słynne są porównania bezpieczeństwa systemów operacyjnych Windows i Linux – zarówno w kategoriach liczby dziur w zabezpieczeniach jak i tempa ich usuwania).
  • Ciągłość usług. System informatyczny musi działać, a gwarantem ciągłości jego działania jest dostawca systemu. Wdrożenia poważnych systemów, szczególnie w bankowości, muszą zapewniać zdolność utrzymania ciągłości działania systemu nawet po „zniknięciu” jego dostawcy (np. bankructwo firmy). Najskuteczniejszym środkiem zapobiegawczym, jaki – pragmatycznie – daje się stosować, jest zdeponowanie kodu źródłowego systemu, choć jest to „na granicy wykonalności” w przypadku COTS. Ten najskuteczniejszy, „najostateczniejszy” środek w stosunku do COTS daje więc w efekcie tyle, ile dostaje się „w pakiecie” od OS.

Spoglądając więc na porównanie ryzyka, to nie widać istotnych punktów przewagi COTS nad OS – oczywiście, jeśli dokonać tej analizy rzetelnie, nie przez pryzmat zamykania oczu na powody, dla których coś się robi. Wybór rozwiązania oparty o analizę kosztów jest właśnie zamykaniem oczu – bez oceny ryzyka i zdolności jego obsługi w kontekście konkretnego rozwiązania. Wybór dostawcy podyktowany kosztem jest tym samym – iluzoryczne bezpieczeństwo za „duże pieniądze”. Poziom ryzyka zapewnienia ciągłości oprogramowania OS można bardzo łatwo zmierzyć – wystarczy prześledzić aktywność na serwisach internetowych tych projektów, skalę zaangażowania, szybkość reakcji, liczbę ludzi zaangażowanych w projekt (nie za pieniądze, tylko naprawdę, z wewnętrznej potrzeby).

Jeśli potraktować poważnie zagregowane doświadczenia ludzkości, OS już wygrało – Linux, Apache, MySQL, PHP, Firefox (i długo można wyliczać inne) są wszędzie. Istnieje jednak zasadnicza różnica między światem OS a światem COTS. Świat OS charakteryzuje się transparentnością – projekty nietransparentne nie są realizowane przez społeczność i zamierają bardzo szybko.

Pewną ciekawostką jest fakt, że oprogramowanie wykorzystywane do realizacji najnowszych trendów rozwoju informatyki stosowanej (Utility Computing, Cloud Computing) opiera się właśnie na OS. Jeśli zamawiający dojrzał już do tego, aby skorzystać z tych trendów (o ile głupia legislacja mu tego nie zabrania), dostępne są rozwiązania SaaS, dzięki którym nic nie musi interesować zamawiającego. A budowane są one w większości przypadków na OS. Jeśli zamawiający odnajduje rozsądek w powyższej argumentacji, ale – z różnych powodów – jest „przywiązany” do płacenia za licencje i utrzymanie, coraz więcej klas systemów udostępnia wersję Commercial OS, czyli OS wsparty firmą, do której „można wysłać zgłoszenie o błędzie”.

Ta ostatnia możliwość jest szczególnie interesująca i jej poświęcę ciąg dalszy rozważań o uzasadnieniu biznesowym dla oprogramowania Open Source. Będzie więc ciąg dalszy, przy czym obiecuję, że nie tak „wkrótce”, jak w tym przypadku.

Pozostaw komentarz