Cykl życia API w nieskończoności (batteries not included cause no needed)
Jak wygląda cykl życia API i jakie ma fazy? Gdy przyjrzeć się uważnie, zauważymy, że w niczym nie przypomina on standardowego cyklu życia produktu. Mimo różnych wizualizacji API Lifecycle, krążących w Sieci, nie znajdziemy tu ani fazy spadku ani fazy śmierci. Cykl życia dobrze zaprojektowanego API jest jak lemniskata — ciągnie się do nieskończoności.
Cykl życia API vs. cykl życia produktu
Słysząc wyrażenia cykl życia API tudzież (w większych korpo modniejsze) API Lifecycle, pierwsze co przychodzi do głowy (o ile oczywiście mieliśmy kiedykolwiek do czynienia z podstawami zarządzania, marketingu lub sprzedaży), to cykl życia produktu.
Rysowany jako funkcja, gdzie oś x oznacza czas, a y wielkość sprzedaży, standardowy cykl życia produktu zawiera IV fazy:
- Wprowadzenie na rynek (faza informowania klientów o istnieniu produktu, pożerająca ogromne nakłady finansowe na reklamę, dystrybucję i edukację klienta)
- Wzrost sprzedaży (produkt zaczyna przynosić zyski i tworzone są jego substytuty; celem firmy jest tutaj przejęcie jak największej części rynku)
- Dojrzałość produktu (w tej fazie mówimy już o istnieniu stałych klientów, którzy powtarzają zakup produktu; decyduje już nie reklama a cena, producent zaczyna bawić się nowymi odsłonami produktu, zmieniając detale i unowocześniając jego cechy)
- Spadek sprzedaży, który kończy definitywna śmierć produktu.
W modelu tym nie widać fazy projektowania produktu, choć doskonale wiemy, że ona istnieje i zwyczajowo wcale nie jest krótka. Jest po prostu produkt czary-mary już gotowy, który ma zacząć się sprzedawać i obserwujemy kolejne jego fazy.
Cykl życia produktu, to twór stricte marketingowy. Cykl życia API -jak zaraz się przekonacie- jest tworem projektowania i ciągłego udoskonalania. Wygląda zupełnie inaczej.
Cykl życia API
Cykl życia API nie przypomina swym wyglądem funkcji. Wprawdzie istnieje wiele różnych modeli API Lifecycle, jednak wszystkie one przypominają bardziej zaklęty krąg nieustannego życia rozwiązania.
Mamy oczywiście początek, którym jest faza projektowania, ale w żadnym miejscu nie wskazuje się jego końca. Ten koniec, ta naturalna śmierć API, kiedyś z pewnością nadejdzie i rozwiązanie zostanie wycofane z użycia (klient zdecyduje się je odciąć), jednak wydarzy się to kiedyś, kiedyś, hen hen, za odległą górą i za odległą rzeką.
Dlaczego? Można by zapytać. Otóż z prostej przyczyny — API nie jest rodzajem szybkiego produktu, który często kupujemy, on się zużywa i zastępujemy go kolejnym. Gdy dana firma decyduje się na wdrożenie API w swoich systemach, oczekuje że podziała ono minimum 5 lat, a może i więcej. Oczekiwania i potrzeby klienta w czasie mogą się zmieniać, jednak wpływają one na rodzaje zapytań, wywoływanych przez API, a nie samo API.
Innymi słowy, jak już raz podłączymy tubę API, to możemy zechcieć dostawać przez nią inne rodzaje danych, ale raczej nie zakładamy wymiany samej tuby.
Nacisk kładzie się nie tylko na samo zaprojektowanie, wyprodukowanie i sprzedaż API, ale i późniejsze, już posprzedażowe, utrzymywanie API przy życiu. Jasno i wyraźnie widać to nawet w konstrukcji umów sprzedażowych API — zwyczajowo płaci się za wdrożenie API, a później, za cyklicznie jego utrzymanie.
Nieśmiertelny cykl życia API (lemniskata)
Z wyżej opisanych powodów, cykl życia API nie przypomina swym wyglądem funkcji, jak w przypadku życia produktu, a charakterystyczną krzywą, którą większość nas zna jako symbol nieskończoności. Lemniskata, bo o niej właśnie mowa, doskonale ujmuje swym kształtem nieprzerwany proces egzystencji API.
Co istotne, jej lewa część ujmuje nakłady pracy i obowiązków dostawcy rozwiązania, a prawa uwzględnia klienta (użytkownika), jako osobę aktywnie uczestniczącą w cyklu życia API. Tak jak samo API w swej naturze pozwala na komunikację dwukierunkową między systemami, tak i w życiu API uczestniczy zarówno jego producent, jak i końcowy user.
I tu rzecz niezwykle istotna, cykle życia API będą się różnić od siebie w różnych firmach i organizacjach! Wiele zależy bowiem od tego, co dokładnie API dostarcza, jaki jest model biznesowy (czy np. jest to pudełkowe API, czy dedykowane, czy otwarte z myślą o rozwijaniu go przez innych programistów itp.).
Tutaj dzielimy się cyklem życia API, które my, jako Transparent Data, wystawiamy dla naszych Klientów (którzy mają już opracowaną strategię API, bo zgłaszają się do nas z konkretnymi potrzebami) i układa się on następująco:
Powyższy diagram cyklu życia API charakteryzuje się 7 etapami:
- Projektowanie | Design — etap ten obejmuje przede wszystkim spotkania z klientem, który opowiada nam o swojej strategii biznesowej. Kluczowe jest dla nas, aby poznać w jakim procesie klient chce wykorzystać API — może to być automatyzacja działania formularza rejestracyjnego, przygotowanie profesjonalnego scoringu czy też usprawnienie procesów due dilligence działu complience. To również na tym etapie dowiadujemy się jakiego typu dane są niezbędne dla naszego partnera. Następnie my mówimy co możemy mu dać, czyli które dane są możliwe do agregowania, a które nie oraz jaka jest ich jakość. Etap projektowania i designu API uwzględnia również nasze sugestie i propozycje, o których Klient mógł wcześniej nie wiedzieć (np. Klientom, którzy chcą usprawnić procesy związane z procedurami AML jesteśmy w stanie zaproponować dostęp do autorskiej, cyklicznie aktualizowanej listy PEPów, czyli osób zajmujących eksponowane politycznie stanowiska). Efektem pierwszego etapu jest kompletna lista wymagań względem API, która stanie się fundamentem II etapu cyklu życia API
- Development — czyli etap wytwarzania produktu. Ten etap, to już praktyczna budowa API i postawienie go w środowisku testowym, tak aby w kolejnej fazie można było sprawdzić czy działa właściwie. Kluczowym staje się tu precyzyjne i sprawne przełożenie projektu powstałego w fazie I na rzeczywiste rozwiązanie. To na tym etapie najbardziej zaangażowany jest dział techniczny (developerski) firmy, nad którym czuwa PM. Na tym etapie również często kontaktujemy się bezpośrednio z klientem, który jest cały czas zaangażowany w proces tworzenia API.
- Testowanie | Bezpieczeństwo — trzeci etap, to wielki moment narodzin API. Przed oddaniem API w ręce klienta testujemy je wewnętrznie pod względem funkcjonalnym i wydajnościowym. Niezwykle istotnym elementem układanki jest bezpieczeństwo, gdyż zapewniamy, żeby dane, które są przesyłane za pomocą naszego API były przekazywane w sposób bezpieczny, zgodny z najlepszymi standardami. Autentykacja i autoryzacja to czołowe słowa-klucze dbałości o bezpieczeństwo API. Oczywiście same testy wewnętrzne po naszej stronie to nie wszystko. Na tym etapie udostępniamy gotowy produkt w ręce klienta, który może sprawdzić jego działanie w specjalnie przygotowanym do tego środowisku. Ta faza to czas intensywnego kontaktu z klientem, z którego strony napływają do nas pytania dotyczące najróżniejszych kwestii związanych z implementacją API. Staramy się, aby rozwiązania, które dostarczamy były jak najbardziej przejrzyste a dokumentacja zrozumiała i wyczerpująca, jednak całkowicie normalne jest to, że wdrożenie jest intensywnym okresem, w którym klient zawsze może liczyć na nasze wsparcie. Więcej o wdrożeniu API w firmie bez bólu w artykule 10 cech dobrego API, które sprawią, że integracja będzie przyjemna
- Wdrożenie — czwarty etap, to wdrożenie API po stronie Klienta. Dostał on już od nas wszystkie dostępy produkcyjne i może pokazać całemu światu swój produkt, działający w oparciu o nasze API. Ten moment jest ukoronowaniem wcześniejszych trzech faz procesu i jest zwykle najbardziej istotny dla Klienta.
- Używanie API — piąty etap cyklu życiu API, to swoiste odkrywanie API przez użytkownika. Dane płynące przez API zasilają jego system, a on rzeczywiście doświadcza rozwiązania, poznaje w realnym świecie jakość danych i szybkość przesyłu. Ta faza, która odbywa się równolegle z fazą utrzymania i monitoringu (jedna po stronie Klienta, druga po stronie dostawcy API), to również etap zbierania przez klienta różnorakich spostrzeżeń, które z czasem mogą stać się podstawą przesłania dostawcy sugestii do zmian w API — innej prezentacji danych, dołożenia dodatkowych źródeł itp.
- Utrzymywanie | Monitoring — to niezwykle istotne, ciągłe, dbanie o jakość aplikacji i nie kończy się aż do momentu rzeczywistego wycofania API z użycia. To tutaj wyłapywane są wszystkie niewydolności API, odchylenia od normy, nieustannie monitorowana jest wydolność aplikacji. Niektóre błędy trafią do procesu zarządzania zmianami, a inne z powrotem uruchomią elementy planowania i strategii.
- Optymalizacja — ostatni etap cyklu życia API polega na modernizacji rozwiązań i zarządzaniu zmianami. Zadania na tym etapie, to sprawna koordynacja odpowiadania na nowe potrzeby użytkowników, zmiany regulacyjne, zmiany danych, aktualizowanie procesów, rozbudowę mikroserwisów, wypuszczanie nowych wersji API a czasem nawet i migrację aplikacji.
Cykl życia API (inne ujęcia)
Cykl życia API wersja 4-etapowa
Bardzo często spotkamy też 4-etapowe ujęcie API, które odnosi się głównie do otwartych API, które w swym zamiarze mają angażować innych programistów do jego ciągłego udoskonalania.
Taki cykl życia API składa się z następujących 4 faz:
- Projektowanie (wymyślenie i zaplanowanie API, które kończy się powstaniem dokładnej specyfikacji)
- Implementacja i testowanie (budowa API i postawienie go w środowisku testowym, tak aby można było sprawdzić czy działa właściwie)
- Wdrożenie oraz zarządzanie i monitoring (uruchomienie API oraz udostępnienie w bezpieczny sposób wykorzystując API Gateway. W ramach utrzymania API, często używa się ich wersjonowania, w szczególności utrzymania kilku różnych wersji API równolegle, oznaczania API jako przestarzałe lub testowe)
- Udostępnienie dla developerów i zaangażowanie ich w jego użycie.
Cykl życia API wersja 7-etapowa
Innym ujęciem, również nie pokazującym roli użytkownika w życiu API, jest wersja 7-etapowa, w której znajdziemy:
- Wymyślenie API (zebranie pomysłów na API, to czemu ma służyć i w jaki sposób)
- Design aplikacji (opracowanie szkieletu i struktury danych)
- Stworzenie prototypy i mockupu API
- Produkcja API i implementacja
- Testowanie
- Zarządzanie zmianami
- Monitoring backendu
Może Cię zainteresować również:
