Dzisiaj vendor lock-in zaczyna być zjawiskiem dotyczącym również usług chmurowych, oferowanych cały czas przez stosunkowo wąskie grono dostawców tych usług. W istocie trudno się dziwić, że każdy biznes dąży do maksymalizacji swoich dochodów, a budowanie pozycji monopolistycznych, uzależniających lub zamykających swoich klientów w obrębie danego rozwiązania bądź usługi pozwala te dochody istotnie zwiększyć.

Vendor lock-in w trzech płaszczyznach

W przypadku usług chmurowych ryzyko zamknięcia lub istotnego ograniczenia klientów do korzystania tylko z jednego dostawcy objawia się na trzech płaszczyznach.

Zobacz również:

• Cyfrowa transformacja z AI - co nowego na Google Cloud Next 24
• Rosną wydatki na chmurę publiczną

Pierwsza z tych płaszczyzn to infrastruktura. Trzeba podkreślić, że akurat różnice wynikające z warstwy infrastrukturalnej nie stanowią największego wyzwania związanego z potencjalną zmianą dostawcy. Niemniej jednak, różnice co do wykorzystywanych przez dostawców maszyn wirtualnych, cenników i przeliczników korzystania z infrastruktury czy choćby preferowanego bądź narzuconego przez dostawców formatu danych mogą stanowić przeszkodę w procesie zmiany dostawcy.

Kolejna płaszczyzna jest znacznie poważniejsza, dotyczy bowiem danych i aplikacji. Problem cały czas sprowadza się do niskiej interoperacyjności oraz "przenoszalności" danych oraz aplikacji pomiędzy poszczególnymi dostawcami. Pomimo ciągle trwających dyskusji co do potrzeby standaryzacji API oraz formatu danych problem pozostaje, a jego skutkiem jest skuteczne zamknięcie klienta do ograniczonego kręgu rozwiązań oferowanych tylko przez jednego producenta.

Trzecia płaszczyzna to płaszczyzna kompetencyjna związana z brakiem po stronie klienta wystarczających kompetencji pozwalających korzystać z więcej niż jednego dostawcy usług. Z tym wyzwaniem można oczywiście poradzić sobie poprzez budowanie odpowiednich kompetencji po stronie klienta. Taki proces wymaga jednak czasu, w którym firma jest ograniczona do korzystania z wąskiego grona dostępnych rozwiązań.

Cloud Contract Exit Due Dilligence

Jak z prawnego punktu widzenia zabezpieczyć się przed opisanym zamknięciem? Trzeba – każdorazowo przed podjęciem decyzji o skorzystaniu w istotnym zakresie z usług chmurowych danego dostawcy – przeprowadzić tzw. Cloud Contract Exit Due Dilligence. To proces pozwalający zweryfikować jeszcze przed wyjściem do chmury, czy kontraktowo gwarantowane warunki umożliwiają potencjalnie szybką zmianę dostawcy. Oczywiście na potrzeby tego artykułu koncentrujemy się tylko na weryfikacji warunków kontraktowych, natomiast dobrą praktyką jest przeprowadzenie takiej weryfikacji również pod kątem technicznym oraz biznesowym.

Własność intelektualna i licencyjna

Prawna perspektywa każe zweryfikować w szczególności trzy obszary: własność intelektualną i licencję, dane oraz kontraktową strategię wyjścia. Zalecane jest, aby w pierwszej kolejności sprawdzić czy tzw. roll-back ze środowisk on-premise (czyli odwrócenie migracji do danej usługi chmurowej) jest w ogóle w umowie przewidziany. W drugiej kolejności sprawdza się, czy posiadane licencje chmurowe będą mogły zostać przekonwertowane na licencje on-premise, a jeśli tak, to na jakich warunkach i po jakich kosztach zakresu i metryk licencyjnych.

W ramach dobrych praktyk warto przez co najmniej jeden rok po migracji chmurowej zachować jeszcze odpowiednią liczbę licencji on-premise, które umożliwią bezpieczny i kontrolowany powrót ze środowisk chmurowych na wypadek konieczności przeprowadzenia roll-backu.

Vendor lock-in a zwrot danych

Jeżeli chodzi o dane, warto sprawdzić warunki kontraktowe regulujące zasady, w jakich danych będą zwracane lub niszczone. Dotyczy to, przykładowo, terminów zwrotu lub usunięcia danych, ich formatu, narzędzi migracyjnych oraz lokalizacji. Warto przy tym zwrócić uwagę, czy w razie zwrotu danych kontrakt przypadkiem nie pozwala dostawcy na zmianę ich lokalizacji oraz standardu szyfrowania – może to mieć szczególne znaczenie dla sektorów regulowanych np. bankowości albo ubezpieczeń.

Kolejna rzecz związana z danymi to weryfikacja ustaleń kontraktowych odnoszących się do ich właścicielstwa. Dotyczy to zarówno samych danych jaki metadanych. Szczególnie uczulam na zagadnienie struktury baz danych, które jako najbardziej dyskusyjny obszar co do właścicielstwa, w tym wątku powinno zostać jasno i ostatecznie rozstrzygnięty w ramach ustaleń kontraktowych.

Vendor lock-in. Strategia wyjścia

W zakresie strategii wyjścia warto skoncentrować się szczególnie na dwóch elementach. Pierwszy to weryfikacja warunków formalnych związanych z wypowiedzeniem umowy, to jest jej formy, procedury i terminów; drugi to związane z tym rozliczenia. Warto dobrze przyjrzeć się, jak wypowiedzenie ma się do cyklu życia kontraktu tzn. kiedy jego złożenie będzie dla nas optymalne z punktu widzenia kosztowego albo obowiązków serwisowych dostawcy.

Drugim elementem jest asysta wyjścia, świadczona przez dostawcę. Jest wysoce rekomendowane, aby szczegółowo zweryfikować zakres czynności świadczonych przez dostawcę w ramach asysty, jej koszty, czas trwania oraz odpowiedzialność za wykonanie konkretnych obowiązków.

Dobra praktyka kontraktowa podpowiada, aby zapewnić w sobie umowie obowiązek współdziałania aktualnego dostawcy z nowym dostawcą, do którego migrujemy, oraz zapewnić kontynuację wsparcia emigracyjnego aktualnego dostawcy nawet po upływie okresu wypowiedzenia, czyli aż do czasu pełnej migracji do nowego środowiska.

Na koniec warto również sprawdzić jak do terminów wypowiedzenia czy harmonogramu planu wyjścia mają się warunki serwisu świadczone przez aktualnego dostawcę. Pozwoli to uniknąć pułapki naliczenia wysokich opłat serwisowych w konsekwencji przedłużającego się wyjścia.

--

Autor jest prawnikiem, partnerem w kancelarii SSW Pragmatic Solutions i liderem praktyki Technologii tamże. Specjalizuje się w prawie nowych technologii oraz własności intelektualnej.