Cloud Computing – architektura a ryzyko

Cloud Computing to temat mający już ok. 10 lat… w 2012 roku na jednej z konferencji temu poświęconej…

…Starałem się wskazać istotną ?jakość? i ?nowość? jaką wnosi CloudComputing (CC) do procesu projektowania architektury systemów IT. Zwróciłem także uwagę, że samo pojęcie CC, jeżeli ma być czymś nowym na rynku, to nie jest to typowy outsourcing rozumiany jako dzierżawa zamiast zakupu aplikacji. Innymi słowy, jeżeli CC ma coś nowego oznaczać to znaczy, że nie jest to ani ASP ani SaaS, ani inne… (źr. : Cloud Computing we Wrocławiu | | Jarosław Żeliński IT-Consulting)

Tym razem krótka wzmianka o ciekawym opracowaniu:

The Practical Guide to Cloud Computing was written to help enterprise information technology (IT) and business decision makers adopt cloud computing to solve business challenges.This guide will help you evaluate the cloud computing market from the point of view of your organization?s needs and contains information that is helpful in selecting a cloud architecture and an implementation approach through the use of in-house staff, cloud vendor(s) or both. (żr. Practical Guide to Cloud Computing Version 3.0 | Cloud Standards Customer Council)

Autorzy porządkują pojęcia, wpisując je w referencyjny model architektury:

Od czasów mojego referatu technologia poszła do przodu. W 2012 roku pisałem:

Na czym polega różnica pomiędzy architekturą a usługą? Jeżeli mowa o architektura to mamy na myśli kwestie integracji, gdyż architektura to opis struktury komponentów. Tam gdzie mowa o usługach czyli związku używam-płacę, pojawia się różnica, którą dzisiaj opisał bym jako:

  • XAAS wymaga integracji czyli do skorzystania z usługi wymagane jest wsparcie (praca) administratora systemu IT.
  • Cloud Computing to “czysta usługa” skorzystanie z niej wymaga praktycznie wyłacznie zawarcia umowy z usługodawcą, i może to zrobić każdy z nas indywidualnie.

Różnica nie jest duża ale z perspektywy prawa i nadchodzącego RODO staje bardzo istotna, bo to między innymi umowy licencyjne precyzują kto, co i gdzie przetwarza i kto komu za co płaci.

Dlatego, nie tylko z powodu RODO, warto bardzo dokładnie zastanowić się nad tym co się ma w serwerowni i na pulpitach komputerów, a wskazany na początku artykuł porządkuje wiele pojęć. Owszem można mieć problem pojęciowy w nazywaniu usług, dlatego w umowach nie należy (odradzam) używać pojęć definiowanych różnie, polecam analizę architektury i związków licencyjnych opisanych w umowach. Brak takiej analizy grozi kłopotami czysto prawnymi:

Po niedawnym orzeczeniu brytyjskiego Sądu Najwyższego, który potwierdził prawo firmy SAP do naliczania opłat za pośrednie korzystanie z systemów SAP przy użyciu takich aplikacji innych firm jak Salesforce, WorkDay i QlikView, korzystanie pośrednie jest obecnie wymieniane przez klientów firmy SAP jako główna obawa w obszarze zarządzania licencjami SAP i kontrolowania ich kosztów. [?] W ostatnich tygodniach ryzyko związane z korzystaniem pośrednim ? dotychczas głównie teoretyczne ? stało się rzeczywistością, która może zmusić wiele przedsiębiorstw do poniesienia milionowych niezabudżetowanych kosztów dodatkowych licencji SAP. (Źródło: Korzystanie pośrednie główną obawą klientów SAP ? ERP-view.pl) 

Cóż to jest to ?korzystanie pośrednie? i w czym problem?

In this instance, the third party systems are accessing the SAP environment, pulling data and often writing it back via a connection to the SAP environment. Here a ?user? must be set up to gain access to the SAP system. On the surface then it can appear like only one user (or a small number of users) is performing actions on the SAP system. In reality though, the ?user? will be performing far more tasks than is possible for a single person to undertake. (Źródło: SAP Audits ? Is it impossible to gauge financial exposure? ? IT Asset Knowledgebase) 

Generalnie chodzi o to, że integrowane ze sobą aplikacje wymieniają dane i ?zlecają sobie? usługi, i tu warto wiedzieć co (dane, logika aplikacyjna) jest chronione prawami autorskimi i co stanowi know how. Problem tkwi w poprawnym zdefiniowaniu przedmiotu (obiektu) przetwarzania, przedmiotu prawa autorskiego i tego co stanowi know-how. (czytaj dalej Korzystanie pośrednie…).

Dlatego tak bardzo ważne jest, na etapie poprzedzającym zakup usługi, zdefiniowanie przedmiotu zamówienia a potem umowy, bo…

…Na rynku spotykamy pojęcia ?oprogramowanie w chmurze?, SaaS (Software as a Service), outsourcing.  Pojęcia te, w swych nazwach, nie mają żadnego umocowania w prawie. Czym więc są? Osobiście jestem zwolennikiem nieużywania ich inaczej niż jako komentarza. Innymi słowy Umowa powinna być skonstruowana z terminów prawnych (użytych i zdefiniowanych w Ustawach), terminy stworzone na użytek komunikacji rynkowej (np. ?cloud computing?) powinny być w tych umowach każdorazowo definiowane z użyciem terminów prawnych. (źr.: Przedmiot Zamówienia ? instrukcja nie tylko dla prawników, na zupę pomidorową | | Jarosław Żeliński IT-Consulting)

Dlatego polecam zawsze analizę architektury systemy wraz z analizą praw autorskich i licencji dla każdego komponentów, spójności tych umów oraz ocenę ryzyka zawarcia kolejnej umowy…

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).