„Co powinienem zrobić, żeby obciąć OPEX?”

Data: 2014-02-17
Autor: Sebastian Konkol
„Co powinienem zrobić, żeby obciąć OPEX?”

To jedno z pytań „tych pytań. Co ciekawe, w opracowanie odpowiedzi na to pytane nie są zazwyczaj angażowani architekci. W zrozumieniu ich roli w organizacji IT, biorą się oni do roboty wtedy, kiedy trzeba zrobić „coś dużego, nowego”. Jednocześnie, niemalże każda inicjatywa wdrożenia myślenia architektonicznego (EA, Enterprise Architecture), ma u swych podstaw optymalizację kosztów operacyjnych – tzw. budżetu lights-on.

Niemalże za każdym razem, kiedy rozpoczynam projekt w tej sferze, przeżywam déjà vu – dlaczego wysiłek oszczędności kosztów kierowany jest na „cięcia” w obszarach wsparcia (usługi konsultantów, utrzymanie, licencje, „etaty”), zamiast adresować elementy, które rzeczywiście stanowią o kosztach (cost drivers). Budżety IT dzielą się z grubsza według parytetu 70% lights-on i 30% rozwój – w podobnej proporcji możliwa jest optymalizacja, przy czym co najmniej 70% to podstawa technologiczna kosztów, a co najwyżej 30% to koszty wsparcia.

Możliwości wspierania działań optymalizacyjnych z wykorzystaniem Enterprise Architecture są ogromne, a podstawą dla ich prowadzenia są trzy podstawowe tryby działania:

  • Standaryzacja. Obejmuje identyfikowanie i wdrażanie wzorców konstrukcji systemów (technicznych, danych, aplikacyjnych), a następnie spójne i konsekwentne ich stosowanie. Standaryzacja umożliwia zwykle minimalizację zróżnicowania implementacji komponentu architektury (np. stos infrastruktury, serwer bazy danych, uwierzytelnienie użytkowników) – oszczędności wynikają z ponownego używania tych samych rozwiązań.
  • Wirtualizacja. W swej esencji polega na oddzieleniu dostępnego dla systemu zasobu (np. moc obliczeniowa, przestrzeń danych, desktop) od fizycznego zasobu. Wirtualizacja zmniejsza siłę powiązania między aplikacją a infrastrukturą, tworząc warunki dla bardziej zaawansowanych metod optymalizacji.
  • Konsolidacja. Zakłada uzyskanie obniżenia kosztu jednostkowego dzięki osiągnięciu ekonomicznego efektu skali. Implikuje zwykle przetransformowanie środowiska ICT do postaci „warstwowej” (np. infrastruktura, dane, logika biznesowa, prezentacja), umożliwiając niezależną optymalizację każdej z tych warstw.

Choć każdy z tych trybów działania jest skuteczny, najpełniejsze efekty uzyskuje się łącząc je. Dla przykładu, jeśli wdrożono standardy infrastruktury obliczeniowej, to wirtualizacja może być przeprowadzona w znacznie mniejszej złożoności środowiska, a konsolidacja może uzyskać większy efekt skali.

Typowe rozwiązania, jakie stosowałem w realizowanych projektach, dotyczyły działań na pojedynczych komponentach sprzętowych (pojedyncze urządzenia), całych stosach technologicznych (zbiór urządzeń pełniących określone funkcje, np. serwer bazy danych), platformach operacyjnych (system operacyjny, wirtualizacja, O&M) i platformach aplikacyjnych (środowiska wykonawcze dla logiki biznesowej, platformy integracyjne).

Przekładając to na liczby – wszak tego dotyczą budżety – posłużę się doświadczeniami z jednego z moich projektów dla klienta z branży mediów elektronicznych, który cierpiał na chroniczny niedobór infrastruktury. W jego przypadku skutkowało to „interwencyjnymi” zakupami czasami przypadkowego sprzętu, gdyż „tylko taki był dostępny”, a w tej pogoni nie było czasu na refleksję nad architekturą – w tym przypadku techniczną – tworzonych rozwiązań. Przeprowadzone analizy ujawniły, że nie tylko sprzęt jest zróżnicowany, ale jest go wręcz za dużo! Udało się ustalić, że kilkadziesiąt maszyn wirtualnych, jakie „zużywały” zasoby infrastruktury, udało się wyłączyć konsolidując rozwiązania aplikacyjne. Dzięki konsolidacji udało się zmniejszyć liczebność, a nawet zróżnicowanie rozwiązań platform aplikacyjnych. Po tej reorganizacji możliwa była zmiana schematu licencjonowania części rozwiązań na korzystniejszy dla mojego klienta. Standaryzacją objęto niemalże 75% infrastruktury i platform operacyjnych, co stanowiło roczne oszczędności 12% budżetu OPEX. Konsolidacja dotyczyła 35% infrastruktury serwerów HTTP, co przełożyło się na kolejne oszczędności OPEX w wysokości 7% w skali roku. Do tego wdrożone zostały standardy usług współdzielonych (np. SSO, zarządzanie preferencjami, mechanizmy dostarczania treści), skutkując kolejnymi oszczędnościami OPEX w wysokości 3%.

Podchodząc do optymalizacji kosztów od strony merytorycznej (rozwiązania ICT), nie zaś finansowej (pozycje budżetowe) przedstawia znacznie większy potencjał oszczędności. Architektura korporacyjna to wdzięczne narzędzie do wyszukiwania potencjału oszczędności w sferze OPEX, często przekładających się także na umożliwienie lepszej alokacji CAPEX. Jego podstawową cechą jest zdolność niemalże błyskawicznego odnajdywania prawdziwych problemów. Czy jest to zaleta, czy też wada, zależy od nastawienia otoczenia – czy celem jest rzeczywisty interes firmy. Ale to już jest inna historia…

Pozostaw komentarz