Wprowadzenie

W 2021 roku, w artykule Transformacja Cyfrowa a dziedzictwo IT pisałem:

Aby transformacja cyfrowa była w ogóle możliwa, musimy przenieść te dane (treści, informacje) z papieru „do komputera”, w sposób nieniszczący obecnych możliwości i pozwalający na tworzenie nowych.

Trzeba też zniwelować posiadany dług technologiczny. Dług technologiczny to posiadane dziedzictwo, to zapóźnienie, to pozostawanie w tyle za trwającym postępem technologicznym. Dług taki ma bardzo wiele firm

https://it-consulting.pl/2021/11/21/cyfrowa-transformacja-a-dziedzictwo-it/

W tym tekście poruszam pokrewny temat jakim jest zabezpieczenie się bo kluczowe pytanie brzmi: co zabezpieczyć mają “wszystko w wersji elektronicznej”?

Bardzo często jestem pytany o to jak się zabezpieczyć kupując lub zamawiając oprogramowanie. Wielu prawników zaleca depozyt kodu źródłowego.

Zdjęcie po prawej to przykładowy fragment takiego kodu. Kto zrozumiał?

Często czytam:

Depozyt kodu źródłowego – niezawodny sposób zabezpieczenia systemu IT

https://szolajski.com/depozyt-kodu-zrodlowego-niezawodny-sposob-zabezpieczenia-systemu-it/

albo:

Depozyt kodu źródłowego (ang. software escrow) jest jednym z najlepszych środków ochrony przed skutkami upadłości producenta oprogramowania.

https://pbrd.pl/#:~:text=Depozyt%20kodu%20%C5%BAr%C3%B3d%C5%82owego%20(ang.,prawn%C4%85%20i%20techniczn%C4%85%20takiego%20procesu.

albo to samo inna kancelaria (skopiowali treść cudzej strony?) :

Depozyt kodu źródłowego (ang. source code escrow) jest jednym z najlepszych środków ochrony przed skutkami upadłości producenta oprogramowania.

https://axteon.pl/depozyt-kodu/depozyt-kodu-%C5%BAr%C3%B3d%C5%82owego/

Takich ofert kancelarii prawnych jest wiele. Niestety bywa to kosztowne i jest to bardzo złe rozwiązanie, bo w zasadzie przed niczym nie zabezpiecza. Depozyt kodu źródłowego jest jedną najbardziej bezwartościowych metod ochrony. Dlaczego?

1. Są to tysiące lub setki tysięcy linii kodu, nie raz bardzo niskiej jakości, napisanego niechlujnie przez różnych ludzi (rotacja prcowników dewelopera).
2. Bywa że celowo utrzymywana jest jego niska zrozumiałość (by utrudnić innym jego zrozumienie).
3. Wiele aplikacji nadal jest pisanych z użyciem relacyjnych baz danych (setki połączonych tabel) i języka SQL, więc wraz z tym kodem należało by mieć także detalicznie opisaną strukturę tych tabel i zapisane (ich treść) wszystkie zapytania SQL użyte w tym kodzie, a także detaliczny opis środowiska tej bazy danych.

Zrozumienie mechanizmu działania aplikacji tylko na bazie jej kodu źródłowego, struktury tabel baz danych i zapytań SQL do tej bazy, graniczy z cudem i zajmuje nie raz lata. To pomysł na poziomie tezy, że można zrozumieć jak działa samolot rozbierając go na detale. W 2012 napisałem artykuł: Sprzedam Ci prawa do kodu czyli wielka ściema. Niedawno napisałem tekst: Mechanizm działania vs model systemu vs diagram. Tu ich kontynuacja w kontekście tego co należy chronić mówiąc o kodzie źródłowym.

Dlatego jedynym skutecznym sposobem zabezpieczenia się, jest posiadanie archiwum dokumentów, które przetwarzała ta aplikacja oraz dokumentacji opisującej mechanizm (architekturę, algorytmy, procedury) realizacji funkcjonalności tego oprogramowania.

Metoda

Standardowo stosuję idealizację i modelowanie zarówno w pracy naukowej ja i w projektach komercyjnych. Dlatego tu także opiszę model architektury systemu informatycznego, jako idealizację takiej architektury, a potem posługując sie nim, przetestuję ideę depozytu kodu źródłowego.

Czym jest system i po co go mamy czyli co to jest komputer

Jest to kluczowe pytanie na jakie trzeba sobie odpowiedzieć. Popatrzmy:

Kluczowy fakt: my jako ludzie używamy komputera a nie kodu źródłowego. To znaczy, że sam kod źródłowy to nie jest to, czego używamy. Kod źródłowy to fragment “systemu”:

Patrząc na powyższy diagram łatwo zauważyć, że sam kod źródłowy, bez pozostałych elementów, jest w zasadzie bezwartościowy. Co z tego że mamy mityczny kod źródłowy, skoro możemy mieć poważny problem z pozyskaniem pozostałych elementów wymaganych do tego, by nasz Działający Komputer odtworzyć? Czego tak na prawdę używamy używając komputera? Używamy określonego mechanizmu przetwarzania danych. Za Słownikiem Języka Polskiego: mechanizm to sposób, w jaki coś powstaje, przebiega lub działa.

Co więc tak na prawdę należy udokumentować i chronić? Opis mechanizmu działania naszego komputera. Problem w tym, że mając wyłącznie kod źródłowy jesteśmy w trudnej sytuacji bo nadal zrozumienie tego mechanizmu wymaga “inżynierii wstecznej”, jedyna różnica to ta, że materiałem źródłowych jest nie kod maszynowy a kod w określonym języku programowania, co niestety niewiele poprawia sytuację:

Kolejne kluczowe pytanie to: Co jest celem zakupu komputera? Otóż celem jest “to do czego on nam służy” a nie “on sam jako taki”.

Cała nasza działalność, do której używamy komputera, to wprowadzanie danych i uzyskiwany efekt. Bardzo często komputer to także archiwum historii naszych “dokonań” (przy okazji prosze zwrócić uwagę na to, że obecnie nie ma znaczenia gdzie on faktycznie stoi bo liczy się komunikacja).

Co faktycznie należy chronić

Kolejne ważne pytanie: czy produkty naszej pracy, nasz dorobek, który powstał z użyciem tego komputera, jest dla nas dostępny bez Tego komputera? Jeżeli nie, to brak tego komputera nie tylko powoduje, że nie mamy narzędzia pracy, to także przepadek całego dorobku jaki powstał z jego pomocą. Jeżeli ten Komputer przechowuje dane w postaci czytelnej tylko dla kodu Tego oprogramowania, to utrata Tego oprogramowania jest równoznaczna z utratą dotychczasowego dorobku (np. najgorszą formą archiwizowania danych jest relacyjna baza danych i zapytania SQL do niej, sytuacja w jakiej jest większość posiadaczy systemów ERP).

Komputer bez udokumentowanego mechanizmu działania to dla nas wyłącznie “czarna skrzynka”. Wobec tego jak się zabezpieczyć, skoro depozyt kodu to zabezpieczenie fikcyjne? Należy zabezpieczyć:

• nasz dotychczasowy dorobek (stanowiące naszą własność archiwum z dokumentami w uniwersalnym formacie, łatwym do odczytania, np. XML+PDF),
• mechanizm działania (udokumentowany np. w UML).

Poniżej idealna bezpieczna architektura: mamy komputer i mamy archiwum oraz mamy “na boku” udokumentowany mechanizm powstawania (przetwarzania) naszych danych.

Innymi słowy: nie tylko mamy archiwum dokumentów, ale mamy także wiedzę jak one powstawały, i możemy tej wiedzy użyć do zbudowania kolejnego “działającego komputera”, bez względu na to w jakiej technologii zrobimy to kolejnym razem. Poniżej zilustrowano podstawowe zalecane zasady zarzadzania danymi:

Dodam tu, że ochrona know-how to nic innego jak posiadanie ww. udokumentowanego mechanizmu. Kod źródłowy nie daje takiej ochrony.

Czym jest wiedza o produkcie?

Opis produktu powinien przedstawiać (ujawniać) go na tyle jasno i wyczerpująco, aby znawca mógł go urzeczywistnić. Za „znawcę z danej dziedziny” uważa się przeciętnego praktyka dysponującego przeciętną, ogólnie dostępną wiedzą z danej dziedziny w odpowiednim czasie, który dysponuje typowymi środkami i możliwościami prowadzenia prac. Przyjmuje się, że specjalista taki ma dostęp do stanu techniki; tzn. informacji zawartych w podręcznikach, monografiach, książkach. Zna także informacje zawarte w opisach patentowych i publikacjach naukowych, jeżeli jest to rozwiązanie, które jest na tyle nowe, że stosowne opisy nie są zawarte w książkach. Ponadto, potrafi korzystać ze stanu techniki w działalności zawodowej do rozwiązywania problemów technicznych. Produkt powinien nadawać się do odtworzenia (na podstawie dokumentacji) bez dodatkowej twórczości wynalazczej. Pod pojęciem tym należy rozumieć dodatkową działalność umysłową, eksperymentalną związaną z niepełną informacją techniczną zawartą w opisie produktu, a także konieczność dodatkowych uzupełniających badań naukowych, niezbędnych do wytworzenia produktu według tego opisu. (na podstawie Pyrża, 2006)

Na bazie poprawnie wykonanej dokumentacji technicznej (opis mechanizmu działania, opis produktu) można aplikację odtworzyć wielokrotnie niższym nakładem środków w porównaniu z analizą cudzego kodu źródłowego, którego dalszy rozwój w postaci i technologii w jakiej pierwotnie powstał, nie raz może nie mieć sensu (postęp technologii w IT jest dość szybki).

Dlatego od wielu zalecana architektura systemów ERP to także osobna zintegrowane własne hurtownia danych i archiwum dokumentów jako np. dokumentowa baza danych NoSQL:

Ważna rzecz na koniec tej części:

1. jeżeli oprogramowanie jest dedykowane to właścicielem i posiadaczem praw majątkowych do kodu i wszelkiej jego dokumentacji powinien być jego użytkownik,
2. jeżeli oprogramowanie jest licencjonowane to użytkownik powinien znać mechanizm jego działania,
3. jeżeli ktoś używa oprogramowania, którego dziania nie rozumie, to może to mieć sens tylko w przypadkach gdy użytkownik wymaga wyłącznie efektu i nie musi rozumieć tego jak powstał: np. oprogramowanie OCR czy retusz zdjęć.

Dlatego tak ważne jest posiadanie archiwum “trwałych nośników dokumentów” (Documents na powyższym schemacie):

Za trwały nośnik można uznać m.in. dokument papierowy, kartę pamięci, pendrive, wiadomość mailową lub załączony do niej plik, np. w formacie pdf. Samo hiperłącze przekierowujące na stronę internetową nie spełnia wymogów trwałego nośnika, jeżeli tego rodzaju strona internetowa nie spełnia cech trwałego nośnika. [zotpressInText item=”{5085975:7L99WLMW}”]

Co radzą prawnicy

Co to jest depozyt kodu źródłowego ?

Depozyt kodu źródłowego (ang. source code escrow) jest jednym z najlepszych środków ochrony przed skutkami upadłości producenta oprogramowania. W praktyce depozyt kodu źródłowego polega na złożeniu przez Licencjodawcę / Deponenta (firmę produkującą oprogramowanie) kodów źródłowych u depozytariusza (tzw agenta depozytu), przy równoczesnym upoważnieniu licencjobiorcy (kupca oprogramowania) do pobrania i dalszego wykorzystania kodów źródłowych w określonych w umowie depozytowej w przypadkach, takich jak np. upadłość, wrogie przejęcie, likwidacja producenta oprogramowania, zaprzestanie rozwoju aplikacji, zaprzestania świadczenia usług serwisowych i wsparcia przez licencjodawcę.

https://axteon.pl/depozyt-kodu/depozyt-kodu-%C5%BAr%C3%B3d%C5%82owego/

Podsumuję to tak:

1. jeżeli oprogramowanie jest dedykowane to właścicielem i posiadaczem praw majątkowych do kodu i wszelkiej jego dokumentacji powinien być jego użytkownik,
2. jeżeli oprogramowanie jest licencjonowane, to użytkownik powinien znać mechanizm jego działania, co pozwala w dowolnym momencie kupić na rynku analogiczne, lub w skrajnym przypadku zlecić napisanie.
3. jeżeli ktoś używa oprogramowania, którego dziania nie rozumie, to może to mieć sens tylko w przypadkach gdy użytkownik wymaga wyłącznie efektu i nie musi rozumieć tego jak powstał: np. oprogramowanie OCR czy retusz zdjęć.

Podczas negocjacji na temat kupna oprogramowania w pewnym momencie rozważny licencjobiorca może zapytać: Co się stanie, jeśli dostawca oprogramowania zakończy swój biznes? Zazwyczaj następuje żądanie dostępu do kodu źródłowego i wszelkich innych krytycznych materiałów używanych do utrzymania oprogramowania.

https://axteon.pl/depozyt-kodu/depozyt-kodu-%C5%BAr%C3%B3d%C5%82owego/

Co do zasady: oprogramowanie się licencjonuje (brak jakichkolwiek praw do niego) lub zleca jego wykonanie (wtedy jest się jego właścicielem, także kodu).

Umowa depozytu kodu źródłowego znana jest w Stanach Zjednoczonych od około 50 lat pod nazwą software escrow. Już wtedy była wykorzystywana do zabezpieczenia oprogramowania tworzonego przez wyspecjalizowane firmy z branży IT. Na początku XXI w. konstrukcja zaczęła upowszechniać się w Europie, ale w Polsce dla wielu przedsiębiorców nadal stanowi całkowicie obce zagadnienie. Po co deponować kod źródłowy i jak prawidłowo skonstruować taką umowę?

https://rpms.pl/depozyt-kodu-zrodlowego-oprogramowania/

50 lat temu, miało to sens bo czasy były takie, że oprogramowanie to były relatywnie małe monolity, kodu było nie wiele, a języków programowania kilka. Obecnie stopień złożoności oprogramowania oraz mnogość technologii powoduje, że kod z zasady nie jest swoją dokumentacją.

Kod źródłowy to nic innego jak zbiór poleceń napisanych w określonym języku programowania, które pozwalają zarządzać zgromadzonymi i wprowadzanymi danymi. Aby kod źródłowy mógł działać, niezbędna jest jego kompilacja, czyli przekształcenie w kod wynikowy, który następnie może zostać zastosowany przez procesor. Efekt takiego działania użytkownik widzi na monitorze komputera. Kod źródłowy zazwyczaj ma postać pliku tekstowego i jako taki może on zostać zapisany na trwałym nośniku, np. płycie CD lub pamięci nieulotnej typu FLASH.

https://rpms.pl/depozyt-kodu-zrodlowego-oprogramowania/

I to jest prawda, jednak problem w tym, że konkretny kod, to jedno z dziesiątek możliwych metod odwzorowania mechanizmu przetwarzania danych (co opisano wcześniej) i niestety bardzo trudne do zrozumienia przez osoby inne niż autor twego kodu.

Każdy dostawca oprogramowania w nieco inny sposób tworzy dokumentację software’u, dlatego warto zadbać o to, aby w umowie były wymienione wszystkie konieczne elementy, które znajdą się u depozytariusza. Co powinno się wśród nich znaleźć?

– aktualizowana karta wersji wraz ze wskazaniem wszystkich wprowadzonych zmian,
– opis struktur katalogów kodów źródłowych wraz ze wskazaniem standardu nazewnictwa plików źródłowych i wynikowych,
dokładny opis procedury kompilacji,
– opis środowiska kompilacyjnego i zdefiniowane biblioteki programistyczne,
– dokumentacja techniczna baz danych wraz ze wskazaniem nazw tabel i relacji między nimi oraz podaniem ewentualnych atrybutów,
– narzędzia do przygotowania wersji instalacyjnej, czyli takiej, która będzie się nadawała do wgrania na twardy dysk oraz do samej instalacji.
W ten sposób licencjobiorca ma gwarancję, że po zwolnieniu kodu będzie dysponował wszystkimi narzędziami, za pomocą których samodzielnie obsłuży otrzymany kod źródłowy.

https://rpms.pl/depozyt-kodu-zrodlowego-oprogramowania/

Niestety nie ma żadnej gwarancji, gdyż narzędzia kompilacji, w tym ich wersje, mogą być niedostępne na rynku, i nadal pozostaje kwestia tego, że nabywca “nie wie jak to działa” bo dla niego kod źródłowy jest niezrozumiały, a zlecenie innemu deweloperowi tworzy konflikt interesu i bardzo duże koszty.

A czym więc jest oprogramowanie?

Jedną z najbardziej szkodliwych działań na rynku jest lansowanie tezy, że kod źródłowy to jakieś wartości intelektualne, i wie o tym każdy kto z takim kodem został sam. Jest to nie prawda: polecam publikacje Urzędów Patentowych na świecie [zotpressInText item=”{5085975:Y86V5TMQ}”].

Kod źródłowy to co najwyżej “kołka zębate maszyny” [zotpressInText item=”{5085975:QAHTAUZ4}”]. Kod źródłowy, jako wartości intelektualne, jest bezwartościowy bez jego autora, tak samo jak bezwartościowy jest tort bez recepty na jego wykonanie. Wie o tym każdy kto został z kodem źródłowym bez dewelopera, który go napisał.

Oprogramowanie to skrypt konfigurujący komputer zas jako ludzie używamy komputera a nie “kodu źródłowego” [zotpressInText item=”{5085975:ZCXJ2S7U}”]. Dlatego w IT raczej należy skupić się na ochronie know-how: chronimy projekt buta a nie buty, chronimy receptury dań a nie to co podamy na stół. W fabryce samochodów chronione know-how to dokumentacja techniczna samochodu, a nie samochody na parkingu.

Jako użytkownik cudzego (licencja) oprogramowania powinniśmy chronić to co z jego pomocą tworzymy. Mając swoje dedykowane oprogramowanie należy chronić opis mechanizmu jego działania, który możemy zaimplementować kiedykolwiek z pomocą dowolnego języka programowania.

Podsumowanie

Więc jak? Użytkownik oprogramowania:

1. albo licencjonuje od dostawcy oprogramowanie standardowe i nie kastomizuje go, tu wymaganie kodu źródłowego jest kuriozalne, a sytuację “awaryjną” leczy zakup analogicznego, standardowego oprogramowania od innego producenta (Finanse i księgowość, itp.).
2. albo posiada prawa majątkowe do dokumentacji i oprogramowania wykonanego specjalnie dla niego, i firma – deweloper – która to wykonała nie ma nic do gadania.

Każda inna forma to szukanie kłopotów. Więcej o kastomizacji i dlaczego jest ona poważnym błędem: Kastomizacja oprogramowania standardowego, aspekty ekonomiczne: Recenzja i rekomendacje. Samodzielne, ponowne, po kilku latach, uruchomienie “starego” kodu źródłowego graniczy z cudem.

Nie jest też możliwe by jakaś jedna aplikacja obsłużyła cała firmę. Nie ma czegoś takiego jak “jedna wspólna baza danych” jako “jedno źródło prawdy”, bo dane są zawsze kontekstowe. Dlatego system IT to raczej kilka tematycznych źródeł prawdy (dziedzinowe oprogramowanie zintegrowane w jeden system), a nie jedno centralne. Wielkie wdrożenia kastomizowanych (nieudokumentowane kastomizacje) monolitów ERP kończą sią zawsze porażką.

Jak udokumentować oprogramowanie: Analiza Biznesowa i Opis Techniczny Oprogramowania – moja rola w projekcie.

P.S.

Przykład. W powyższy sposób opracowałem i udokumentowałem logikę działania systemu Generator Ofert dla Kancelarii Senatu. Jest to oprogramowanie obsługujące dofinansowanie projektów dla polonii na całym świecie: od naboru wniosków, przez ich procesowanie, zatwierdzanie, podpisywanie umów aż do rozliczenia. Aplikacja dwa razy zmieniała firmę, która obsługiwała jej utrzymanie i rozwój, później została przepisana w nowej technologii w toku przejścia z chmury na hosting dedykowany. Dzięki temu, że zastosowano dokumentowy model danych, migracja do nowej wersji odbyła praktycznie bez kosztowo.

Czarny humor na zakończenie

Poniższy mem jest dość popularny w sieci:

Jego parafraza:

Koder: Tylko kod źródłowy jest dokumentacją oprogramowania.

Użytkownik: To oprogramowanie nie działa poprawnie, gdzie jest opis poprawnego (oczekiwanego) działania tego programu?

Koder: Opisem jest ten kod źródłowy….

(autor mema nie znany)

Źródła

[zotpressInTextBib style=”apa” sortby=”author” sort=”ASC”]

Wprowadzenie

API to skrót od Application Programming Interface, i jest to niestety bardzo myląca nazwa. Dlaczego? Bo to nie jest “coś do programowania”. API to po prostu usługa aplikacji udostępniana nie (ludzkim) użytkownikom na ekranie komputera, a innym aplikacjom.

Dwa lata temu opisywałem projektowanie API i integracji, pisałem też, dlaczego od integracji obecnie nie ma już ucieczki:

Mamy ogólnoświatową sieć Internet, aplikacje lokalne i w chmurze, aplikacje naszych kontrahentów i aplikacje centralnych urzędów. Wszystkie one współpracują i wymieniają dane, czyli są zintegrowane. Dlatego integracja stała się cechą każdego systemu informatycznego. […] Czym jest obecnie integracja? To wymiana danych a nie ich współdzielenie: dane z urzędem wymieniamy, dane z kontrahentem wymieniamy, nie współdzielimy żadnych danych z tymi podmiotami, każdy ma swoje własne, bezpieczne bazy danych, i to wszystko ładnie działa! Idea zbudowania wszystkich funkcjonalności jako zintegrowanej aplikacji na jednej współdzielonej bazie danych w czasach obecnych jest utopią. Taką samą jak hipotetyczna centralna baza danych dla wszystkich sklepów internetowych, firm kurierskich i banków, a one są jednak zintegrowane: one wymieniają dane a nie współdzielą!

https://it-consulting.pl/2022/02/21/integracja-jako-zrodlo-przewagi-rynkowej-czyli-jak-projektowac-rest-api-z-visual-paradigm/

Artykuł powyższy polecam osobom zainteresowanym stroną techniczną projektowania integracji i API. Dzisiaj odpowiem na problemy jakie zgłaszają prawnicy, czyli co jest przedmiotem umowy gdy przedmiotem tym jest mityczne API.

Aplikacja i jej API – co to takiego

API to nic innego jak przypadki użycia (każda operacja to osobny use case) tyle, że tu aktorem jest inna aplikacja a nie człowiek.

Generalnie każda aplikacja (komputerowy program użytkowy) świadczy swoim użytkownikom określone usługi, w notacji UML aplikacja to ‘system’. Użytkownikiem aplikacji jest każdy zewnętrzny byt, mający z tą aplikacją interakcje, w notacji UML jest to aktor. Aktorem jest zarówno nasz usługodawca jak i usługobiorca. Jeżeli aktorem jest człowiek, jako interfejsu używa on GUI (Graphical User Interface). Jeżeli aktorem jest aplikacja, używa ona API (Application Programming Interface). Ta nieszczęsna nazwa: programming interface, ma swój rodowód w tym, że adresatem opisu tego interfejsu jest programista/projektant, a nie ludzki użytkownik aplikacji.

Poniższy diagram (diagram przypadków użycia notacji UML) obrazuje wyżej opisane role:

Diagram ten pokazuje kontekst czyli kto jest użytkownikiem i czego, dlatego pokazane elementy różnią sie kształtem (różne ikony). Jednak powyższa architektura, pokazana na diagramie komponentów, który nie niesie informacji o kontekście “ja/ty”, wygląda tak:

Tak zwane “lizaczki” na tym diagramie to interfejsy oferowane, “klieliszki” to interfejsy wymagane. Tak więc API1 to: interfejs oferowany przez System Usługodawcy i jednocześnie interfejs wymagany przez System. API2 to interfejs oferowany przez System i jednocześnie interfejs wymagany przez System Usługobiorcy. GUI to interfejs oferowany przez System (ludzkiemu) Użytkownikowi.

Co do zasady, bez względu na to czy oferowany czy wymagany, interfejsy definiujemy jako:

• nazwa polecenia (opcja w menu użytkownika),
• jego parametry,
• odpowiedź,
• struktury parametrów i odpowiedzi (formularz ekranowy, komunikat).

Całość to zawsze dialog: wywołanie usługi z ewentualnym parametrem, odpowiedź z ewentualnym parametrem. Te parametry to dane, mogą być zebrane jako nazwany komunikat i jego struktura (zalecane). Ważne jest to, że tak na prawde nie ma znaczenia czy aktorem jest człowiek czy aplikacja, bo mechanizm generowania odpowiedzi, realizowany przez System, jest taki sam.

Widać to np. na poniższym diagramie pokazującym przykładowe wnętrze aplikacji:

To czy aplikacja będąca usługodawcą jest w naszej serwerowni czy w chmurze, nie ma żadnego znaczenia.

Prawnik zgłasza problem

Na portalu LinkedIn, pojawiają sie różne ciekawe wpisy, szczególnie ciekawe są te na styku IT i prawa. Tym razem prawniczka zgłasza problemy:

Obecnie duża część biznesów opiera się na produktach API. Udostępnienie czy sprzedaż API nie jest dokładnie jednak taka sama jak sprzedaż produktu Software-as-a-Service lub licencjonowanego oprogramowania. Istnieją pewne specyficzne niuanse, które muszą zostać umownie określone w umowach licencyjnych API.

[LINK do źródła]

?Problem pierwszy. Jak dobrze zdefiniować czym jest API? I klucz API?

API to usługa, klucz to hasło/kod dostępu do niej,

?Problem drugi. Zakres udzielanych licencjobiorcy praw

identyczny jak dla człowieka: może korzystać albo nie, pozyskana treść może być chroniona innym prawem (np. API udostępniające eBooki),

?Problem trzeci. Zakres obowiązków dostawcy API

identyczny jak każdego innego dostawcy oprogramowania,

?Problem czwarty. Kod API informacją poufną czy nie?

nie ma żadnego “kodu API”, jest kod aplikacji (jest także mechanizm działania tej aplikacji),

?Problem piąty. Standardy bezpieczeństwa w korzystaniu z API, potrzebne?

tak samo jak dla każdej aplikacji,

?Problem szósty. Zbieranie informacji na temat korzystania z API przez licencjobiorcę, potrzebna zgoda czy nie?

tak samo jak zbieranie każdych innych statystyk, dodam, że użytkownik może sobie robić dowolne statystyki po swojej stronie i nikogo nie musi pytać o zgodę na to,

?Problem siódmy. Użytkownicy dalsi, jak oni korzystają z API?

co to za cudo Ci “Użytkownicy dalsi”?

?Problem ósmy. Czy umowę można wypowiedzieć?

a dlaczego nie? Umowa jak każda inna,

?Problem dziewiąty. Przekazywanie danych poprzez API, potrzebna zgoda użytkowników aplikacji czy nie?

nie da się używać API nie przekazując danych 🙂

?Problem dziesiąty. Gwarancja na API, dawać czy nie dawać?

tak samo jak jak na każde oprogramowanie,

?Problem jedenasty. Odpowiedzialność, ograniczać? I co z odpowiedzialnością za aplikacje wykorzystujące API?

nic, robią co chcą,

?cachowanie, logowanie ruchu i wyjątków dostępu, forward i reverse proxy na dane dostępne z API

to wewnętrzne funkcje systemu a nie cecha API (SLA)

?sandbox testowy API vs produkcyjny (mockowanie API)

to dodatkowa oferta, taka sama jak np. “testowe używanie ERP przez księgową”

?SLA + healthChecki

jak wyżej

?rozliczenie i monitorowanie płatności / subskrybcji dostępów do api + ograniczenia z tym związane: dostępu, ilości wysłanych i odebranych danych, prędkość wysyłania i odbierania danych, przetwarzanie masowe, maksymalne rozmiary wysyłanych i odbieranych danych, dopuszczalna ilość żądań/s, timeout-y

jak wyżej

?walidacja i gwarancja poprawności danych (jedno źródło prawdy)

a kto chce niepoprawne?

?wersjonowanie API, kompatybilność wsteczna z elementami “legacy API”

to jakoś systemu i jego dostawcy,

?retencja danych

to wymaganie i cecha oprogramowania a nie cecha API.

Podsumuję to tak

“Udostępnienie czy sprzedaż API nie jest dokładnie jednak taka sama jak sprzedaż produktu Software-as-a-Service lub licencjonowanego oprogramowania. “

To nie jest prawda, to jest to samo.

“Istnieją pewne specyficzne niuanse, które muszą zostać umownie określone w umowach licencyjnych API.”

to też nie jest prawda, nie istnieją takie.

To co istnieje, to oprogramowanie, które:

– oferuje usługi (funkcjonalności)

– oferuje pewien poziom jakości (SLA) i kontroli dostępu do niego.

tak jak każde oprogramowanie.

Prawnicy: nie zmyślajcie problemów na siłę.

Wprowadzenie

Od kilku już lat jestem, jako ekspert, angażowany jako rzeczoznawca do sporządzania opinii na zlecenie sądów (opinia biegłego) lub jednej ze stron sporu (opinia prywatna). Są to spory dotyczące nieudanych dostaw i wdrożeń oprogramowania, nie tylko ERP, bardzo często także dedykowanego.

Po tych latach wyłania się pewien wspólny mianownik, łączący te porażki scenariusz:

1. firma dostaje ofertę na dostarczenie i wdrożenie oprogramowania,
2. ma miejsce prezentacja pomysłu, jakieś makiety, jakaś działająca funkcjonalność,
3. przedmiotem oferty jest prezentowane istniejące oprogramowanie z obietnicą jego dostosowania (kastomizacji), lub oferta wykonania dedykowanego oprogramowania,
4. projekt przyjmuje formę umowy T&M, podane są stawki wykonawcy,
5. prawa autorskie (osobiste i majątkowe) do tego co powstaje w toku projektu, są “z zasady” należne wykonawcy, z możliwością przekazania praw majątkowych zamawiającemu (często za dodatkową opłatą),
6. prawnicy obu stron nie mają do powyższego żadnych zastrzeżeń, skupiają na formalnościach: zawarcie umowy, jej rozwiązanie, przekazanie praw majątkowych do kodu, warunki płatności itp… w zasadzie nic co dotyczy przedmiotu umowy, bo nie istnieje opis przedmiotu umowy (nie licząc licencji na standardowe oprogramowanie i ogólnego celu zamawiającego),
7. początek projektu, szybko powstaje (albo jest gotowe) tak zwane MVP (Minimum Valuable Product), zamawiający nabiera zaufania do dostawcy, uwierzył w zwinne projektowanie,
8. kolejne funkcjonalności zaczynają nastręczać problemów, ale wszyscy są dobrej myśli, zamawiający zaczyna coraz częściej słyszeć, że to on jest problemem bo zmienia wymagania i wierzy, że to on jest powodem problemów, dostawca mówi że tak (długo i drogo) ma być to biznes się zmienia i trzeba płacić,
9. zależnie od cierpliwości zamawiającego, zaczyna sie eskalacja problemu, w zasadzie nic nie jest tak jak powinno być, zamawiający zaczyna ponosić straty,
10. zamawiający wstrzymuje płatność za ostatnią fakturę (z powodu umowy T&M, poprzednie są już w praktycznie nieodzyskiwalne), zaczyna sie spór, zaczynają zarabiać kancelarie prawne, często te same, które wspierały projekt na etapie zawierania umowy.

Mityczne MVP?

Co jest problemem wielu firm? Zarząd, który nie ma pomysłu na rozwój. Czy musi go mieć? Nie, może zaangażować analityka, który opracuje model działania organizacji i wskaże na nim możliwe usprawnienia. Jednak wielu nie robi tego wierząc, że dobrym pomysłem jest już samo rozpoczęcie metodą prób i błędów.

Generalnie więc powodem problemów jest zupełny brak pomysłu na to czym ma być rozwiązanie, a sam problem jest zarysowany ogólnie i często do końca niezrozumiany. Mimo to obie strony – firma i deweloper – są pełne zapału.

Jednym z typowych argumentów deweloperów na etapie ofertowania i prezentowania “metodyki pracy” jest mityczne MVP, często prezentowane jak poniżej:

Rysunek ten, w tej i podobnych wersjach krąży po stronach WWW deweloperów i jest chyba jednym najbardziej manipulacyjnych i nieprawdziwych schematów. Deweloperzy często argumentują, że ścieżka dolna jest długa i kosztowna, trzeba płacić i długo czekać na ostateczną wersję produktu, bo najpierw trzeba ponieść koszty projektowania, a do tego czasu “nic nie ma”. Sugerują, że szybko coś przydatnego dostarczą (MVP). W czym problem?

W tym, że:

1. faktycznie rozwiązaniem problemu (potrzeba biznesowa) jest ostatnia pozycja po prawej,
2. wszystkie kolejne pośrednie urządzenia powstają na koszt zamawiającego, są odrzucane (nie spełniają wymagań) a realnie w niczym nie pomagają, no bo rozwiązaniem (potrzebą) jest ostateczny produkt,
3. zamawiający nie ma kompetencji (a nie raz nie ma dostępu do kodu) i nie wie, że realnie płaci za kod, który jest zastępowany kolejnym pomysłem, i tak wiele razy, cały czas na jego koszt,
4. dolna ścieżka realnie, jest znacznie krótsza, bo projektowanie produktu na modelach jest co najmniej o rząd wielkości tańsze i znacznie szybsze, nie realizowane zbędne prace na odrzucanych prototypach,
5. praktyka pokazuje, że w dniu podpisania umowy zamawiający też nie wie (nie ma pomysłu, koncepcji) co ma ostatecznie powstać, więc generalnie projekt sie toczy bez żadnego planu i kontroli kosztów,
6. autorzy tego obrazka całkowicie pominęli fakt, że dzisiejsze aplikacje, podobnie jak ten samochód, w 90% powstają z gotowych i dostępnych na rynku komponentów, więc realnie raczej nie wymyślamy koła na nowo.

Tak więc cała powyższa “metoda” to całkowicie nieplanowany, bardzo kosztowny proces z dużym ryzykiem, że nie powstanie nic wartościowego bo braknie czasu i środków. I tak właśnie wyglądają te sporne projekty.

Troszkę teorii: Komponenty i Paradygmat Obiektowy

Paradygmat obiektowy to hermetyzacja i wymiana komunikatów, a nie “dziedziczenie i łączenie funkcji i danych w obiekty”, które jest cechą pierwszych języków obiektowych i stosowanych w nich wzorcach (C++/Java). W zasadzie JavaEE/Spring to framework oparty na antywzorcach (anemiczny model dziedziny, set/get, brak separacji logiki od backendu, patrz artykuł: Ten straszny diagram klas).

Popatrzmy na to:

Diagram powyżej pokazuje typową monolityczną architekturę po lewej stronie. Kluczowe cechy monolitu to fakt, że każda zmiana funkcjonalności wymaga refactoringu kodu i migracji danych do nowej, większej bazy o nowej strukturze. Za każdym kolejnym razem jest to trudniejsze i kosztowniejsze. Jeżeli zaś jest to np. kastomizowany system ERP, to praktycznie na większą skalę jest to niemożliwe (dlatego producenci tych systemów odradzają takie podejście, patrz artykuł: Kastomizacja oprogramowania standardowego, aspekty ekonomiczne: Recenzja i rekomendacje).

Po prawej stronie mamy architekturą komponentową, potocznie i powszechnie określaną jako mikro-serwisy, czasami jako mikro-aplikacje. Jest to tak na prawde znana od lat 90-tych architektura komponentowa [zotpressInText item=”{5085975:HPRRUHDL},{5085975:NSJBENX9}”], patrz także [zotpressInText item=”{5085975:SVEGIS7Q},{5085975:6WMWKUT4}”].

Kluczową cechą tej architektury jest wzajemna komunikacja komponentów (integracja) jako wymiana komunikatów, a nie współdzielenie jednej bazy danych (wtedy realnie nadal byłby to monolit). Ta komunikacja to na powyższym diagramie szare linie z grotami. Integracje opisałem w artykule Integracja systemów ERP jako źródło przewagi rynkowej. Projektowanie REST API i scenariuszy. Dzisiaj skupie się tu na wyjaśnieniu jak komunikaty zastępują centralne współdzielone bazy danych.

Podstawowym elementem komunikacji są komunikaty. Z uwagi na to, że organizacja to system komunikujących się między sobą ludzi, ludzi z komputerami i komputerów między sobą, pojęcia “dokument” i “komunikat” należy uznać za tożsame, gdyż komunikacja człowiek-człowiek, niczym się nie różni od komunikacji człowiek-komputer czy kompoter-komputer [zotpressInText item=”{5085975:DQ85BDLN}”].

Powyższy schemat to przykład współpracy kilku komponentów: każdy z nich wykonuje jakieś czynności, są one inicjowane otrzymanym komunikatem, wynik działania także jest przekazywany jako komunikat. Każdy z tych komponentów może przechowywać historie tych komunikatów (lokalne repozytorium komponentu). Takie komunikaty mogą zawierać różne treści, nie raz nadmiarowe z perspektywy jednego komponentu, ale zawsze spójne kontekstowo. Bardzo często w systemach występują komponenty, których celem jest kolekcjonowanie danych, a odbywa się to po prostu jako zbieranie określonych komunikatów (dokumentów).

Np. faktura to dokument/komunikat niosący dane o dokonanej transakcji. Jest on nośnikiem danych dla działu księgowości, dla klienta, na żądanie dla Urzędu Skarbowego, itp.. Mimo tego, że każdy z wymienionych korzysta tylko z części treści faktury, przekazywana jest zawsze cała faktura, bo to upraszcza cały system.

Kluczem jest zrozumienie tego, że komputery przetwarzają i wymieniają dane a ludzie przetwarzają i wymieniają informacje. Sztuką projektowania systemów informacyjnych jest dekompozycja problemu, projektowanie komunikatów (treści dokumentów) oraz zrozumienie i opisanie mechanizmów ich powstawiania i korzystania z nich. Potem pozostaje już tylko implementacja: zbudowanie systemu informatycznego (patrz: Architektura informacji, system informacyjny a system informatyczny w organizacji).

Powyższy diagram pokazuje także, że próba budowania architektury, w której kilka, kilkanaście wymienianych komunikatów miało by być zamienionych na jeden współdzielony stos wszystkich danych, będzie bardzo trudna do zbudowania i jeszcze trudniejsza do wprowadzania w niej zmian.

Podsumowując: każda organizacja i jej otoczenie to “system wymiany danych” a nie “system współdzielenia danych”. Dlatego świat od dawna odchodzi od monolitów na rzecz komunikujących sie komponentów (mikro-serwisy, mikro-aplikacje, komponenty). Budowanie wspólnego, centralnego modelu danych dla wielomodułowych systemów w zasadzie nigdy nie miało sensu ani szans powodzenia:

Dlaczego problemy pojawiają sie “dopiero później”, na początku było dobrze i klient był zadowolony

Paradoksalnie wyjaśnienie jest dość proste: u deweloperów nadal dominują metody oparte o monolityczne architektury. Głoszenie stosowania “obiektowych metod programowania” oznacza tylko tyle, że zastosowano tak zwany “obiektowo zorientowany język programowania”, co absolutnie nie oznacza, że architektura tego co powstanie będzie nowoczesna. Praktyka audytów pokazuje, że raczej będzie to skansen architektoniczny oparty o relacyjny model danych, wielopoziomowe dziedziczenie i najgorsze praktyki modelowania danych jakimi są anemiczny model dziedziny i płytkie płaskie klasy z ogromna liczbą operacji (w tym set/get dla każdego atrybutu klas reprezentujących tabele bazy danych, patrz artykuł: Ten straszny diagram klas).

Dlatego ten scenariusz często wygląda tak, że na początku powstaje oprogramowanie realizujące jedną określoną funkcję, to często zarodek monolitu. Wszystko ładnie działa, klient się cieszy, zawiera (przedłuża) umowę. Kolejne funkcjonalności to początek dramatu: rozbudowa monolitycznego modelu danych, migracje ze starego modelu do nowego, narastające problemy monolitycznej architektury: wszystko się sypie bo wszystko zależy od wszystkiego, i nie wiadomo jak, bo nie ma żadnej dokumentacji mechanizmu działania aplikacji, zaś kod od dawna nie nadaje się już czytania. Próba naprawy tego też zaczynam być gonieniem króliczka…. i jest spór.

ZARZĄDZANIE PROJEKTEM WE WŁASNYM ZAKRESIE JEST KRYTYCZNE: Integratorzy systemów mogą być cennym elementem cyfrowej transformacji, ale nigdy nie powinni mieć całkowitej, niekontrolowanej władzy nad całym przedsięwzięciem

(źr. PORAŻKA CYFROWEJ TRANSFORMACJI W FIRMIE HERTZ, oryg. : THE HERTZ VS. ACCENTURE DISASTER)

Źródła

[zotpressInTextBib style=”apa” sort=”ASC”]