Początkowa sytuacja wygląda jak na poniższym obrazku.
Pewna firma zbudowała sobie pewien serwis, który rozwinął się bardzo pomyślnie. Żeby szybko wejść na rynek, w trakcie tworzenia swojego serwisu, firma skorzystała z API zewnętrznego dostawcy - odpłatnie rzecz jasna. Po jakimś czasie pojawiły się następujące problemy:
- serwis szybko się rozwija, ale cały czas musi się dostosowywać do API zewnętrznego dostawcy,
- chociaż zewnętrzny dostawca również rozwija swoje API, to każe sobie za nie słono płacić,
- im bardziej firma chce rozwijać swój serwis, tym bardziej uzależnia się od zewnętrznego dostawcy.
W takim miejscu zaczynamy.
Czy zależność od zewnętrznego API jest zawsze zła?
Myślę, że istotniejsze jest pytanie "kiedy" zależność jest zła, niż "czy" jest zła tak w ogóle. Moja obserwacja jest następująca: w początkowych etapach rozwoju biznesu, nie ma sensu zastanawiać się nad zależnościami. Zasada jest tu bardzo prosta, jeśli tylko możesz coś kupić zamiast pisać samemu - kupuj!. Na tym etapie kupowanie będzie zawsze tańsze, ponieważ pozwala skupić się na tym, co jest istotne - dopracowanie modelu biznesowego, a nie jakieś tam szczegóły implementacyjne.
Obserwuję wśród moich klientów, że w miarę rozwoju firmy i stabilizowania się modelu biznesowego, zależności zaczynają boleć. Trzeba jednak zrobić rozróżnienie na trzy rodzaje zależności:
- zewnętrzne API - np. usługa, która pozwala na zaawansowane wyszukiwanie ofert hoteli; gdy wewnątrz systemu, który rozwijasz, potrzeba takiej funkcjonalności, kupujesz usługę i sprawa załatwiona.
- technologiczne - gdy używasz danej technologii, dostajesz w pakiecie paczkę zależności, np. na różnych etapach rozwoju technologii .NET razem z nią w transakcji wiązanej można było dostać zależność do: ASP.NET, partial clasess, Entity Framework, MSTest itd.
- infrastrukturalne - np. storage, hosting, streaming.
Zależności infrastrukturalne bolą najmniej. Z firm które znam, te które doszły do etapu stawiania własnych centrów danych, mogę policzyć na palcach jednej ręki wojowniczych żółwi ninja. Zostawmy więc ten temat.
Zależności technologiczne są ciekawsze. Bardzo często spotykam się z sytuacją, gdy ograniczenia technologii lub frameworka zaczynają mocno uwierać i firmy decydują się na przepisanie tego i owego.
Lata temu w artykule Generowanie danych dla widoku, opisałem ciekawe rozwiązanie architektoniczne, w skrócie polegające na oddzieleniu stosu do zapisu danych od stosu do odczytu danych. Powodem tej zmiany były kłopoty wydajnościowe ORMa, które zniknęły po rozdzieleniu zapisu od odczytu. Dziś taki zabieg nazywamy CQRS, ale zanim CQRS stał się bywalcem konferencji, zaimplementował je dziarski zespół z pewnej instytucji finansowej w Poznaniu i wcale nie uznał za stosowane, żeby się tym chwalić. True story.
Przed erą Java Script bardzo częstym zabiegiem było wyrzucanie ze stosu technologicznego wszystkich frameworków GUI. Przy rozległych systemach i dużej liczbie widoków, skomplikowane frameworki zaczynają przeszkadzać zamiast pomagać i okazuje się, że jest sens napisać coś własnego.
Dlaczego biznes chce przepisać moduł?
Uzależnienie od zewnętrznego API, do którego delegujemy część przetwarzania, można odczuć najszybciej. Chodzi o koszty, a właściwie o zyski, a właście to chodzi o dobranie się do fajnego kawałka biznesu.
Pamiętasz moment, kiedy pojawiły się w Polsce przelewy natychmiastowe? Pionierem była firma Blue Media i stworzony przez nią system Blue Cash. Można było zapłacić parę złotych i w razie konieczności przelać pieniądze bez czekania dnia roboczego, aż kasa dotrze tam, gdzie powinna. Opłata od osoby zlecającej przelew to jedno, lecz przypuszczam, że dany bank również musiał uiścić opłatę na rzecz Blue Media za udostępnienie API do przelewów natychmiastowych. No, bo jakby to wyglądało, gdyby bank nie dawał możliwości takich przelewów, skoro konkurencja dawała?
Blue Media to spółka komercyjna, od której banki zmuszone były kupować usługę. Zgaduję, że to bolało. W pewnym momencie powstał więc system Express Elixir. System został opracowany przez Krajową Izbę Rozliczeniową, której udziałowcami - a więc właścicielami - są: Związek Banków Polskich, banki komercyjne i siłą rzeczy NPB. Jak widzisz sprytne wyparcie Blue Cash przez Express Elixir, to absolutnie nic osobistego. To był po prostu fajny kawałek biznesu do zagospodarowania :).
Sprzedaj to dobrze
Twój klient, który zatrudnił Ciebie albo Twojego pracodawcę do przepisywania systemu, może mieć niewypowiedziane oczekiwanie, że skoro zatrudnił ekspertów, to sprawa załatwiona i można zapomnieć o temacie aż do momentu odbioru prac. W tej branży tak to nie działa. Wiemy to ja i Ty, więc nie będę się tutaj na tym rozwodził.
Tak jak pisałem w artykule Pytania, które zadaję klientowi na wstępie, postaraj się być w tym projekcie już od etapu przedsprzedażowego. Twoim zadaniem na tym etapie jest zadbać, aby w kontrakcie były wskazane konkretne osoby ze strony klienta dostępne do współpracy. Będziesz potrzebować:
- ekspertów dziedzinowych - osób, które znają ten biznes od poszewki i dokładnie rozumieją skąd się biorą i dokąd uciekają pieniądze w tym biznesie,
- ekspertów technicznych - osób, które znają zawiłości technologiczne i architektoniczne systemu,
- zagwarantowanej dostępności wymienionych osób.
Ja celuję w 2-3 osoby na tym etapie. Czasem w organizacjach wiedza jest mocno rozproszona i tych osób może być więcej. O ile te osoby są dostępne, to nie stanowi ty dużego problemu - komunikacja będzie wymagać więcej wysiłku i tyle. Poważnym problemem jest brak ww. osób. Jeśli nie ma eksperta technicznego, jeszcze raz przemyśl wycenę. Jeśli nie ma eksperta dziedzinowego - odpuść ten projekt.
Powyższe zasady są surowe, ale praktyczne. Przede wszystkim mają one zastosowanie do sytuacji, gdy pracujesz dla klienta zewnętrznego. W przypadku klienta wewnętrznego, gdy biznesem są osoby z Twojej organizacji, może się zdarzyć, że rzeczywiście nie będzie eksperta dziedzinowego do jakichś kawałków biznesu. O tym, jak sobie w tej sytuacji radzić, pogadamy kiedy indziej, OK? :)
Zaczynaj od ASIS
Zawsze zaczynaj od określenia stanu obecnego - ASIS. Bardzo sugeruję, żeby zdefiniować stan ASIS całego obszaru biznesowego, którego dotyczy wasza współpraca, a nie tylko do jednego wybranego modułu, który - tak jak zaanonsowałem we wstępnie - będzie przepisywany. Powód jest prosty - ten moduł mógł zostać źle wydzielony. Jak pokazałem na początkowym rysunku, jest to obcy moduł, wokół którego Twój klient zbudował swoją usługę. W miarę rozrostu systemu, zewnętrzne API jest obudowywane różnego rodzaju fasadami i adapterami. Tworzenie rzeczonego modułu po stronie klienta oraz rezygnacja z zewnętrznego dostawcy, jest dobrą okazją do zaprojektowania go lepiej. Dodatkowo opisanie stanu ASIS pokaże, w jaki konkretnie sposób ten nasz moduł przyczynia się do biznesu Twojego klienta.
Jeśli szczęśliwie udało Ci się zagwarantować sobie współpracę klienta - tak jak wskazałem to w akapicie "Sprzedaj to dobrze" - to najlepszą metodą, aby zabrać się do pracy jest Event Storming. W kolejnym mailu wyjaśnię Ci dlaczego oraz w jaki sposób, krok po kroku, się do tego zabrać.
