Business Case dla Cloud Computing?

Data: 2016-05-16
Autor: Sebastian Konkol
Business Case dla Cloud Computing?

Od kilku miesięcy krążą po Internecie grafiki prezentujące oszczędności wynikające z przeniesienia systemów „do chmury”. Szczególnie LinkedIn obfituje w takie rewelacje, a wizualizacje przedstawiają się cudnie, prawda? Próbowałem się dowiedzieć od publikujących, na czym budują ten optymistyczny obraz świata, ale – poza zdawkowymi, ogólnikowymi odpowiedziami – żadnych konkretów nie uzyskałem. Spróbowałem więc podsumować to, co dotychczas wiem.

Temat Cloud Computing, Storage i tak dalej jest obecnie bardzo modny. Bez wątpienia, rozwiązania „w chmurze” mają swoje zalety – mają jednak także wady… Pominę zagadnienia bezpieczeństwa, zarówno teleinformatycznego (systemów powierzanych operatorom chmury), biznesowego (dostęp do danych o charakterze poufnym) jak i społecznego i terrorystycznego (dostęp do wielu źródeł danych, których łączenie z wykorzystaniem narzędzi BigData daje potężne możliwości wywierania globalnego wpływu). Skupię się jedynie na aspektach finansowych, ale w rozumieniu TCO (Total Cost of Ownership).

Zacznijmy od prostej arytmetyki wynikającej z tej wizualizacji. Po obu stronach mamy ten sam składnik kosztu, Implementation, Customization & Training. Skoro porównanie dotyczy dokładnie takich samych wdrożeń, jedynie realizowanych w różnych trybach, to zakres i wartość tego składnika kosztu powinny być takie same, prawda? Jeśli tak, to składnik ten w projekcie On-Premises stanowi 44% budżetu projektu, a w wersji On-Demand – mniej, bo 32%. Skoro tak, to budżet projektu realizowanego w wersji On-Demand – nadal przy porównywalnym efekcie dla fundatora projektu i uwzględniając wszystkie koszty ponoszone w czasie życia systemu – musi być większy o proporcję 44% do 32%, czyli o 38%! Sporo. Czy aby na pewno o to chodziło?…

Przejdźmy jednak do klasyki, czyli struktury kosztów statycznego „posiadania” systemu informatycznego. Rozumiem, że w wersji On-Demand klient nie ponosi kosztów sprzętu (zakupu, prądu i klimatyzacji, utrzymania data centre), kosztów związanych z personelem IT (osobowe i miejsce pracy, szkolenia i utrzymanie kompetencji, zwolnienia i urlopy, związki zawodowe, …) oraz opłat tzw. Maintenance. Tym zajmuje się dostawca usługi On-Demand w ramach opłat subskrypcyjnych. Rozumiem, że taki dostawca realizuje wszystko to, co generuje składniki kosztów Apply Fixes, Patches, Upgrade, a także Performance Tuning i Maintain/upgrade hardware / network. Są to wszak działania administracyjne, standaryzowalne, gdzie – dzięki efektowi skali – dostawcy usług On-Demand mogą obniżyć koszty jednostkowe takich prac. Choć z pewnymi wątpliwościami, potrafię sobie wyobrazić, że taki dostawca realizuje także zadania skutkujące składnikami kosztów Maintain/upgrade database (o ile chodzi po prostu o oprogramowanie serwera bazy danych, nie o dane w bazie danych) oraz Maintain/upgrade security (o ile chodzi o „łatanie” sprzętu oraz platformy operacyjnej i aplikacyjnej). Krótko mówiąc, dokąd mówimy o infrastrukturze, z definicji niezależnej od aplikacji i ich cech biznesowych, efekt skali pozwala na oszczędności. Nie rozumiem jednak, jakim cudem wersja On-Demand nie ma składnika kosztów Downtime – czyżby On-Demand oznaczało 100% dostępności zawsze? Chyba jednak nie, więc taki składnik – bardziej nawet utraconych korzyści, niż kosztów – został pominięty w wersji On-Demand. A szkoda, bo to dyskusja o koszcie jakości, która mogłaby stanowić właśnie mocny argument za Cloud Computing.

Wyjdźmy jednak nieco poza utopię „statycznego” wdrożenia i utrzymania niezmiennego systemu informatycznego. Według kolegów po fachu, koszty wprowadzania zmian w systemach potraktować benchmarkowo – co 3 lata tyle samo, co koszt wdrożenia. Idąc dalej, współczesne środowiska informatyczne są plątaniną bardzo zróżnicowanych systemów, a zmiana w jednym systemie często pociąga za sobą konieczność zmian w innych. Myślę, że to właśnie kryje się pod składnikami kosztów określonymi jako Rewrite customizations, Rewrite integrations oraz Upgrade dependent applications i Ongoing burden on IT (mój faworyt!). Nie rozumiem jednak zupełnie, w jaki sposób przeniesienie jednego systemu do trybu On-Demand miałoby pomóc w obniżeniu tych kosztów en masse. Widzę tu raczej zagrożenie monopolistyczne – skoro trzeba dokonać zmian w systemie On-Demand, to albo oznacza to uruchomienie oddzielnej, nowej usługi On-Demand, albo zmiany musi dokonać właśnie usługodawca. Moim zdaniem, ryzykowne, a co najmniej wątpliwe.

Zróbmy jeszcze jeden krok, oceńmy sprawę z perspektywy ryzyka i to jedynie wynikającego z uzależnienia od usługodawcy. Co się stanie, kiedy usługodawca zostanie przejęty przez innego, drapieżnego? Albo zmieni się zarząd usługodawcy, który postanowi doić klientów od niego uzależnionych? To są realia rynkowe, a kto ich nie wycenia, ten później płacze. Jaką część Ongoing burden on IT można powierzyć usługodawcy? Architekturę? Analitykę biznesową? Na pewno nie, bo ktoś musi w tym wszystkim reprezentować interesy usługobiorcy! Pozbycie się tego oznacza pozbawienie się kontroli nad zasadnością powstawania kosztów wskazywanych przez usługodawcę. A co zrobić, kiedy usługodawca – na zapytanie ofertowe dla realizacji zmiany – odpowie „nie złożymy oferty”? Może warto wycenić ryzyko uzależnienia rozwoju biznesu od takiego usługodawcy?

 

W ramach podsumowania, On-Demand jest fajowe, dokąd rozmawiamy o infrastrukturze (sprzęt, platforma operacyjna, platforma aplikacyjna). W tym zakresie obowiązują kanony ekonomii, z efektem skali na czele, zasadzające się na standaryzacji działań, procesów i rozwiązań. Każdy krok powyżej to wycieczka w sferę rozwiązań niestandardowych, gdzie potencjał oszczędności kurczy się drastycznie. Rzecz jasna, można wierzyć, że dostawca On-Demand będzie lepiej zarządzał projektem, skuteczniej testował, efektywniej realizował zmiany w oprogramowaniu. Pod względem kosztów są to jednak efekty drugorzędne. Przejście do rozwiązań „w chmurze” to nie jest decyzja opierająca się o analizę kosztów!

Żeby wszystko było jasne, podzielam w pełni opinię, że IT Doesn’t Matter (by Nicholas G. Carr), ale wyłącznie wraz z całą argumentacją za tym stojącą. Myślę, że każdy, kto – tak jak ja – tkwi w technologiach od kilku dekad, słysząc rewelacje o drastycznym obniżeniu kosztów dzięki zastosowaniu cudownych rozwiązań, staje się podejrzliwy. Wartość Cloud Computing jest bezdyskusyjna, ale w żaden sposób nie wynika ona z oszczędności kosztów. Sprzedawcy srebrnych kul, pokazujcie prawdę o tym, jak zapewnicie wzrost jakości, jak zredukujecie ryzyko, jak będziecie – partnersko – wspierać usługobiorców. Tylko, błagam, nie prezentujcie takich dyrdymałów, które obala każdy z doświadczeniem branżowym większym, niż 3 lata.

Pozostaw komentarz