Środowisko aplikacji potrzebne przez 18 miesięcy można oprzeć na kupionym serwerze albo prywatnej usłudze; uczciwe porównanie obejmuje więcej niż cenę urządzenia i sumę abonamentu, bo uwzględnia uruchomienie środowiska, jego administrację, backup, pracę przy zmianach oraz wyłączenie po projekcie. Zestawienie kosztów całego cyklu przypisuje te czynności do okresu i wykonawcy. Zakup nadal może być właściwym wyborem, jeżeli klient ma plan dalszego użycia sprzętu i zasoby do jego obsługi po zakończeniu aplikacji.
Koszt zaczyna się przed uruchomieniem
Kupiony serwer wymaga zamówienia, odbioru, miejsca, zasilania, sieci, systemu operacyjnego, dostępu administracyjnego i kopii. Firma ponosi również koszt czasu oczekiwania oraz pracy wykonanej przed instalacją aplikacji. Część tych wydatków trafia do innych budżetów, dlatego łatwo pominąć je w wycenie projektu.
Wariant usługowy skupia rozmowę na środowisku potrzebnym aplikacji. W NSIX może ono korzystać z prywatnej chmury i serwerów wirtualnych dla aplikacji, bazy danych, dostępu zdalnego, backupu, zapór sieciowych oraz VPN. Serwery G2E stanowią warstwę infrastruktury, natomiast instalacja aplikacji, migracja bazy i integracje należą do zakresu software house'u lub klienta.
Przed pierwszym miesiącem trzeba więc wycenić udostępnienie środowiska, konfigurację wejściową, konta, reguły dostępu i przekazanie do prac aplikacyjnych. Osobno liczy się instalację, migrację danych, zadania cykliczne i monitoring aplikacji. Ogólna pozycja „serwer” nie wyjaśnia, kto wykona te czynności ani ile pracy naprawdę obejmuje.
Osiemnaście miesięcy utrzymania
W każdym miesiącu klient płaci za usługę albo ponosi część kosztu własnego sprzętu. Do porównania dochodzą administracja systemem, aktualizacje, monitoring, kopie, certyfikaty, obsługa kont i czas poświęcony na incydenty. Przy własnym urządzeniu energia, miejsce i części mogą być rozliczane poza projektem, ale nadal obciążają firmę.
Środowisko zmienia się wraz z aplikacją. Przybywają konta, integracje, zadania cykliczne oraz dane, a niektóre funkcje wymagają innych zasobów. Każde rozszerzenie ma datę, zamawiającego, wykonawcę i wpływ na dalsze opłaty lub pracę administratora.
Przewidywalny koszt nie oznacza niezmiennej konfiguracji. Zakres serwerów wirtualnych może być dostosowywany do potrzeb aplikacji, a własny sprzęt również bywa rozbudowywany. W drugim wariancie firma częściej ponosi osobne koszty części, zaplanowanych prac technicznych i czasu administratorów zamiast jednej miesięcznej opłaty.
Po kilku miesiącach można porównać założenia z rzeczywistą obsługą. Liczą się godziny administracji, zmiany wymagające udziału infrastruktury, użycie kopii oraz praca przy dostępach. Nie są potrzebne zewnętrzne benchmarki ani niepotwierdzone ceny; firma korzysta z własnych danych projektu.
Zmiany i awarie liczone osobno
Środowisko klienta jest oddzielone pod względem danych, konfiguracji i kont, zwłaszcza gdy software house prowadzi kilka wdrożeń równolegle. Przed większą aktualizacją można wykonać migawkę, aby w razie problemu szybko wycofać konkretną zmianę. Migawka nie zastępuje jednak backupu ani planu przywrócenia po awarii, błędzie użytkownika lub uszkodzeniu danych.
Przed startem projektu klient ustala, ile może trwać przerwa i z jakiego momentu trzeba umieć odzyskać dane. Te wymagania wynikają z pracy aplikacji, nie z samego wyboru sprzętu, prywatnej chmury czy kopii. Pokazują, jak przygotować środowisko na awarię, ale nie dają automatycznej gwarancji technicznej.
Przy incydencie trzeba oddzielić pracę przy serwerze, sieci i kopiach od diagnozy kodu, zgodności aplikacji z bazą oraz korekty danych. Zestawienie kosztów pokazuje, która czynność mieści się w umowie infrastrukturalnej, która w utrzymaniu aplikacji, a która wymaga osobnego zlecenia.
Co zostaje po zakupie serwera
Po 18 miesiącach własne urządzenie nadal istnieje. Klient może przeznaczyć je do innego systemu, sprzedać albo dalej utrzymywać. Każdy wariant wymaga konkretnego planu: zgodności z nowym zastosowaniem, administracji, miejsca, aktualizacji oraz osoby, która przejmie sprzęt po projekcie.
Jeżeli dalsze użycie jest realne i zostało wycenione, wartość serwera może przemawiać za zakupem. Sama możliwość wykorzystania kiedyś nie wystarcza. Bez wskazanego systemu i budżetu urządzenie pozostaje kosztem utrzymywanym dłużej niż aplikacja, dla której je zamówiono.
Przeniesienie sprzętu do nowej roli również wymaga pracy. Klient ocenia zgodność z kolejnym systemem, dostępność aktualizacji, potrzebne zasoby i miejsce dla kopii, a administrator przygotowuje zmianę bez zakłócania innych usług. Jeżeli tych czynności nie ma w budżecie następnego projektu, przyszłe użycie pozostaje założeniem, nie policzoną korzyścią.
Wyłączenie zamyka porównanie
Środowisko usługowe można wyłączyć po zakończeniu umowy i wykonaniu uzgodnionych czynności. Zakres zamknięcia obejmuje format eksportu danych, termin ostatniej wersji, integracje do wyłączenia, odebranie kont i przekazanie materiałów klientowi. Dla danych roboczych, logów oraz kopii ustala się okres przechowywania i termin usunięcia.
Trzeba również zamknąć zależności spoza serwera: domeny, certyfikaty, konta usługowe, powiadomienia i zadania cykliczne. Pozostawione elementy mogą nadal generować opłaty albo otwierać niepotrzebny dostęp. Samo wyłączenie maszyny nie kończy projektu aplikacyjnego.
Własny serwer wymaga podobnego porządku, a dodatkowo planu dla urządzenia. Po wykonaniu uzgodnionych czynności zamykających można zakończyć usługę infrastrukturalną i jej rozliczanie. Dane i dokumentacja trafiają do klienta w ustalonym zakresie. Oba warianty można porównać dopiero po dopisaniu ostatniego miesiąca oraz czynności końcowych.
O wyborze rozstrzyga koszt całych 18 miesięcy wraz z pracą przed uruchomieniem i po wyłączeniu. Zakup broni się konkretnym dalszym zastosowaniem sprzętu. Prywatne środowisko lepiej pasuje do projektu o określonym końcu, gdy klient chce zamknąć usługę razem z aplikacją bez przejmowania kolejnego urządzenia do utrzymania.