Case study, które publikuję ostatnio na Rudej Stronie Zarządzana, spotykają się z Waszym bardzo ciepłym odbiorem. Tym razem, w ramach poznawania jak inni prowadzą projekty, rozmawiam z Arturem Gułą z IT PROJECT MAKERS.  Miało być głównie o projektach integracyjnych, ponieważ pomyśleliśmy, że warto przybliżyć innym ich specyfikę. I było, ale potem zeszliśmy na tematy zarządzania ogólnie i rozmawialiśmy o roli project managera. Wyszła z tego tak obszerna rozmowa, że podzieliłam ją na dwa osobne materiały. Dzisiaj prezentuję część pierwszą – o integracji systemów IT. Już wkrótce druga część wywiadu, czyli rozmowa o zarządzaniu i o tym, dlaczego lepiej robić projekty niż nimi zarządzać.

Zobacz moje poprzednie wywiady:

Artur Guła

„Specjalizuję się w dostarczaniu projektów IT spełniających oczekiwania użytkowników. Konkretnie, pragmatycznie i bez niepotrzebnych działań oraz kosztów. Zwinnie, lub tradycyjnie, a przede wszystkim skutecznie. Konkretne rozwiązania publikuję na blogu https://projectmakers.pl a także dzielę się nimi w trakcie spotkań online. Mam również przyjemność współtworzyć społeczność https://storymapping.pl, czyli grupę skupioną na budowaniu produktów IT. Zapraszam do dołączenia!”

O co chodzi z tą integracją?

– Na początek spotkania pytam Artura jakimi projektami obecnie się zajmuje?

Artur Guła: Bardzo różnymi. Współpracuję z firmą, która realizuje różne projekty na zamówienie. W tej chwili wszystko co robię, robię wokół wytwarzania oprogramowania. Od projektów klasy enterprise dla ogólnoświatowych korporacji po bardzo małe aplikacje. Ostatnio zacząłem przygodę z oprogramowaniem produkcyjnym, czyli takim, które działa w fabrykach. Wcześniej były to też aplikacje mobilne (w tym jedna popularna, z której wielu ludzi korzysta w Polsce), a także aplikacje SaaS’owe –  więc cały przekrój oprogramowania.

– A nad czym teraz pracujesz?

Artur Guła: Obecnie pracuję nad małą aplikacją z obszaru szkoleniowego, która pozwala pracownikom zdobywać nowe umiejętności.

– Myślę, że większość osób potrafi sobie wyobrazić, przynajmniej dość ogólnie, na czym polega projekt wytwarzania oprogramowania. Rozumieją ścieżkę od pomysłu do gotowego produktu. Przypuszczam jednak, że nie jest to tak łatwe, kiedy mówimy o projektach integracyjnych. Czy możesz nam więc przybliżyć co to są projekty integracyjne?

Artur Guła: Do integracji, jak sama nazwa wskazuje, potrzebujemy minimum dwóch systemów. Ten etap następuje najczęściej później niż samo wytwarzanie, bo dopóki nie wytworzymy systemów, to nie mamy czego integrować. Natomiast, ważna wskazówka zanim przejdę dalej.

Kiedy budujemy oprogramowanie, to warto mieć z tyłu głowy te przyszłe integracje, które trzeba będzie wdrożyć, żeby jak najwcześniej dostosować np. standardy komunikacji czy struktury danych.

Spotkałem się z tym, że duży system, taki ogólnoświatowy, powstawał pomijając to, w jaki sposób będzie się później dogadywał z całym światem. To ma swoje konsekwencje. Potem trzeba robić obejścia. Trzeba dodawać niepotrzebne elementy, które mogły być domyślnie zrobione gdybyśmy pomyśleli o tym wcześniej. Więc integracje, to jest etap późniejszy, ale trzeba go mieć najlepiej na uwadze już od początku.

Same projekty integracyjne sprowadzają się najczęściej do tego, że wymieniamy dane. Czyli mamy dwa systemy, które muszą się dogadać. Ta wymiana może być w czasie rzeczywistym, może być cyklicznie synchronizowana, może to być jednorazowa operacja czyli te dane przesyłamy raz i potem zapominamy o integracji.

Brzmi to prosto natomiast cała trudność sprowadza się do tego, że mamy wiele różnych standardów komunikacji, wiele różnych struktur danych. Te dane są czasami nieprzygotowane odpowiednio, mają błędy, powtórzenia itp. Trzeba nad tym zapanować. Jest wiele różnych wyzwań

Te projekty są też inne od standardowych, bo nie mają często warstwy UI – interfejsu użytkownika. To jest taki plus, że unikamy rozmów typu, „ale mi się nie podoba, ja bym chciał coś innego”, „to jest nieładne, powinno być bardziej niebieskie”. Minus jest taki, że systemy w przeciwieństwie do ludzi muszą się dogadać zero-jedynkowo. Jak systemy się nie dogadają, gdzieś będzie choćby drobna różnica, to najczęściej po prostu przestaną działać.

Po co nam ta cała integracja?

– Wiemy już co się robi w projektach integracyjnych. Cofnijmy się teraz o jeden krok i porozmawiajmy o tym PO CO się to robi. Wnioskuję, że pracowałeś raczej przy dużych integracjach, w skali korporacyjnej. Po co więc robimy integrację (oprócz tego, żeby nie wklepywać tych samych danych w kilku różnych systemach?)

Artur Guła: Przy dużych projektach systemy, które integrujemy, są często zoptymalizowane pod operacje, które wykonują. Operacje te są bardzo złożone i nie ma sensu replikować tej samej logiki w kilku innych systemach.

Jeżeli np. pomyślimy o systemie, który rezerwuje bilety na samolot, to mamy pewnie jakiś inny system, który może mu pomagać optymalizować ceny tych biletów. Koszt biletu może zależeć od tego jaki jest ruch, jaki sezon albo np. że jest ładna pogoda w danym miejscu i będzie duże zainteresowanie. Wtedy trzeba te ceny odpowiednio podnieść.

Jeżeli spojrzymy z perspektywy nowego przewoźnika, to nie musi on budować takiego systemu od zera. Może skorzystać z gotowego rozwiązania z półki i wtedy musi się właśnie zintegrować z tym istniejącym rozwiązaniem. Musi się połączyć, wysłać swoje dostępności miejsc w samolotach. System zewnętrzny odpowie mu, jakie powinien ustawić ceny. Taka wymiana jest więc po to, żeby sobie ułatwiać życie.

Jak dany system już się w czymś specjalizuje, w konkretnej dziedzinie, to niech się w tym specjalizuje, a ja się będę specjalizował w swoim obszarze. Szukamy właśnie tych specjalności. Korzystamy z tego, że ktoś już coś wymyślił, żeby nie wyważać otwartych drzwi.

Wydaje mi się, że to jest właśnie ten cel: ułatwianie sobie życia, korzystanie z tego co jest w świecie, łączenie się, wymiana danych.

Czasami też jest tak, że mamy stare systemy np. klient korzystał z jakiegoś systemu, a teraz chce się przepiąć na inny, nowszy. Wtedy musimy z tamtego systemu pobierać i przetwarzać pewne dane. Może być też przypadek integracji wielu istniejących, starych systemów, co się często dzieje zwłaszcza w firmach produkcyjnych, które rozwijały się przez lata. Były to tego typu scenariusze: zbudujmy jakiś mały system, tu wrzućmy jakiś dodatkowy element, tu kolejny kafelek. No i w końcu przydałoby się to wszystko połączyć, żeby łatwiej tym zarządzać. I wtedy przez jakiś czas być może ten nowy system też będzie zbierał dane z różnych źródeł, integrował je i z czasem stanie się jedynym źródłem prawdy.

– Powiedziałeś nam już, że w projekcie integracyjnym odchodzi problem interfejsu użytkownika i kłopotów z nim związanych. Jak więc, poza tym wspomnianym aspektem, wygląda proces wytwórczy? Innymi słowy, jak wygląda praca nad takim projektem?

Artur Guła: Nie robimy warsztatów z użytkownikami końcowymi, którzy będą z tego korzystać. Przynajmniej na poziomie wymiany danych, bo to dzieje się „pod spodem”, bez warstwy UI. Zastępujemy to pracą z dokumentacją. Dokumentacja jest podstawą – trzeba wiedzieć jak ten system działa, jaką ma logikę, jakie ma interfejsy. Co będzie jak wyślemy mu gdzieś jedynkę, a co się stanie jak wyślemy dwójkę.

Ważne staje się mapowanie danych, czyli takie dogłębne zrozumienie jakie my mamy dane, jakie ma drugi system i czy te dane pasują nawzajem do siebie. Są pewne standardy, np. my w naszym systemie będziemy używać kodów do określania nazw krajów, a drugi system pełnych nazw. Jak my wyślemy im „PL” to oni powiedzą, że nie rozumieją bo powinniśmy wysłać „POLAND”. Pomimo tego, że to pole w obu przypadkach to jest nazwa kraju, to nie wiemy czy oba systemy jednak tak samo je zrozumieją. A jeżeli nie, to powstaje pytanie – co możemy z tym zrobić?

Te systemy same z siebie nie wymyślą co mają zrobić, jeżeli dostaną błędne dane. Trzeba wtedy „pomyśleć za nie”. Jeżeli wyślemy inne dane, albo ten drugi system zmieni format danych i zamiast „POLAND” prześle nam coś innego, stosując inny standard, to co my z tym zrobimy? Czy my mamy jakiś sposób, żeby ten błąd obsłużyć, czy może mamy gdzieś go szybko wysłać (np. do działu help desk)? I czy będzie tak, że jak otrzymamy informację, która jest mało istotna, ale jest błędna, to czy od razu zignorujemy i odrzucimy całą wiadomość, a czy np. zapiszemy ją i tylko zgłosimy gdzieś błąd z informacją, że trzeba coś poprawić.

To są częste problemy biznesowe. Pytania – kiedy otrzymana wiadomość jest jeszcze prawidłowa, a kiedy już nie? Co jest priorytetem, czy samo zapisanie, czy np. to żeby wiadomość była w pełni prawidłowa?

– Po tym co powiedziałeś nasuwa mi się pytanie. Czy myślisz, że w takich projektach większą trudnością są problemy i ograniczenia technologii, czy jednak jest to kwestia uzgodnienia standardu przesyłanych danych, protokołu komunikacji i poprawności komunikatu?

Artur Guła: Myślę, że technologia jak ją opanujemy na początku, czyli zrobimy jakiś Proof Of Concept, wypracujemy sobie standardy to często już jest potem powielaniem tego co już mamy. Problemem staje się detaliczna analiza, zgłębienie tego jakie tam mogą być jeszcze problemy. No i testowanie. Testowanie jak najwcześniej – to myślę jest ważne. Pomimo tego że spodziewamy się, że jakoś ten system z którym się integrujemy będzie działał, to jednak sprawdzenie tego w praktyce nawet na etapie analizy jest niezwykle ważne.

I to jest wydaje mi się duża różnica między projektami „tradycyjnymi” a integracyjnymi. W integracjach analityk powinien móc sobie taki system uruchomić, zobaczyć czy rzeczywiście działa tak, jak twierdzi dokumentacja. Nie zawsze przecież tak jest. Miałem taką sytuację, że z dokumentacji i opowieści tej drugiej strony, która była właścicielem systemu, wynikało, że pewne identyfikatory, które będą nam przysyłali, są standardowe. Potem okazało się, że to co nam przysyłają, to jest identyfikator tymczasowy i potem go podmieniają na inny. Że stoją za tym złożone procesy. Musieliśmy poświęcić kilka tygodni na analizę i na zmiany, bo od początku nie było wszystko precyzyjnie powiedziane. A gdybyśmy tego nie testowali przed dewelopmentem, to potem trzeba by było robić jeszcze bardziej czasochłonne poprawki. Dzięki temu, że testowaliśmy komunikację już na samym początku, to zaoszczędziliśmy sporo czasu.

Zawsze więc stawiam za cel, żeby jak najszybciej mieć coś co już będzie działało i można będzie to testować.

Ważne, żeby znaleźć co jest takim minimum, choćbyśmy mieli przesyłać tylko imię i nazwisko klienta, ale żeby już zacząć to przesyłać, a potem dobudowywać do tego kolejne funkcjonalności. Bo może być dużo problemów na samym początku, na jakichś wyjątkach, na komunikacji. Komunikacja może się zawieszać z jakiegoś powodu. Dlatego dążę do zrobienia minimum, przetestowania, a potem dopiero dokładam resztę.

– I tym samym przechodzimy do następnego pytania, które przygotowałam, czyli jakie są zagrożenia i ryzyka w czasie takiego projektu. Mówiłeś już o zmieniających się danych, słownikach, które trzeba dopasować. Na co jeszcze należy zwracać uwagę?

Artur Guła: Dokumentacja jest mimo wszystko zagrożeniem. Nikt nie lubi pisać dokumentacji. Skoro my jej nie lubimy, to prawdopodobnie po stronie tego drugiego systemu też jest ktoś, kto nie lubi jej pisać i aktualizować. Tak więc ona jest często nieaktualna, niepełna, czasami jest pisana od niechcenia. Więc stosuję ograniczone zaufanie, jak na drodze. Ufać, ale najlepiej sprawdzić.

Komunikacja na pewno też jest wyzwaniem, bo nigdy nie wiem, kto będzie po drugiej stronie. Np. taka realna sytuacja projektowa. Przenosimy dane z systemu, którego klient używał do tej pory, ale zdecydował się przesiąść na inny system, który my będziemy dostarczać. No i teraz my się musimy dogadać z ludźmi z tamtego systemu, żeby te dane jakoś od nich pobierać. Istniejący system będzie jeszcze przez jakiś czas brał udział w procesie, ale oni wiedzą, że im nam pójdzie lepiej, tym szybciej oni nie będą potrzebni. W ich interesie w ogóle nie jest współpraca z nami i nasze powodzenie.

W takich sytuacjach nie ma zazwyczaj ścisłej współpracy. Trzeba samemu sporo wymyślać, a jak trzeba wprowadzić jakąś zmianę po stronie zewnętrznego systemu, to nie jest to proste.

Dlatego takie kwestie miękkie jak komunikacja, jak najbardziej mogą być ryzykiem w projekcie.

Może to być nawet taka banalna kwestia jak język komunikacji. Takie sytuacje też już miałem. Istniała bardzo wąska grupa osób, która była w stanie być pośrednikiem na spotkaniach między przedstawicielami dwóch systemów. Tylko ta grupa znała te dwa języki, a przy okazji była merytorycznie przygotowana w temacie. To też było spore ryzyko, bo gdyby tych kilku osób brakło, to nie byłoby łatwo o porozumienie.

– Jak widać, dużą rolę odgrywa tu połączenie wiedzy technicznej i umiejętności miękkich. Czy w takim wypadku uważasz, że project manager, który czuwa nad tą komunikacją i nad tym, żeby projekt został „dowieziony” w projektach integracyjnych potrzebuje większej wiedzy technicznej niż w innych obszarach IT?

Artur Guła: To zależy trochę od skali. Bo jeżeli to jest w miarę mały zespół, to rola PM może też wymagać tego, żeby zaglądać w szczegóły techniczne. Bardziej rozumieć co się dzieje, z czym się wiążą różne problemy. Jeżeli ktoś zupełnie nie rozumie czym jest REST API a ma integrować dwa systemy właśnie przez to API, to może to być problemem, bo będzie to dla niego pewna abstrakcja.

Chyba, że to jest duży projekt, w którym pracują dziesiątki osób. Mamy wtedy analityków i  poziom zrozumienia ze strony PMa może być mniejszy. Wszystko zależy od skali, jak głęboko musimy wchodzić i rozumieć co się dzieje. Jeśli to jest mały zespół i nie mamy dedykowanych analityków to może być tak, że to PM będzie musiał obsługiwać jakieś skrypty, testować i wywoływać zapytania, żeby prowadzić sprawą komunikację z drugą stroną i nie zawsze angażować w nią programistów.

– To było takie trochę zaczepne pytanie ponieważ są różne szkoły zarządzania. Jedni eksperci twierdzą, że nie trzeba się znać na tej dziedzinie, w której prowadzi się projekt. Moim zdaniem jednak IT pokazuje, że dobrze mieć zrozumienie technologii na poziomie pozwalającym przynajmniej na zrozumienie o czym rozmawiają programiści. A jak Ty uważasz? Zgadzasz się czy masz inne zdanie w tej kwestii?

Artur Guła: Myślę, że tak. Ten język jest ważny. Tak jak wspominałem, jeżeli będziemy mówić o tych rzeczach technicznych np. integracji, to w zasadzie byśmy nie mieli o czym rozmawiać jak byśmy kompletnie nie wiedzieli co tam się dzieje pod spodem. Bardzo często rozmawiałem z osobami, które opiekują się produktem po „drugiej stronie” i one też są zwykle bardzo dobrze zorientowane jak działa ich system. Potrafią wygenerować wiadomości, wysłać je i odczytać. Wiedzą o co chodzi. Z taką osobą byłoby nam ciężko porozmawiać bez odpowiedniej wiedzy. Coś jednak powinniśmy wiedzieć. No chyba że jesteśmy wysoko w złożonej strukturze, jakimś np. program managerem i wyłącznie zarządzamy.

– A czy wiedza z zakresu biznesu, którego dotyczy projekt jest bardzo przydatna przy integracji? Jak tworzysz jakąś aplikację to zazwyczaj znajomość procesów i zrozumienie biznesu pomaga w lepszym zrozumieniu wymagań. A jak dobrze trzeba znać biznes w takim projekcie integracyjnym?

Artur Guła: Znowu, to zależy od tego na ile mamy wsparcie analityków. Mimo wszystko na wysokim poziomie zrozumienia wydaje mi się, że to jest niezwykle ważne. Jeżeli mówimy o dużych systemach, z którymi się integrujemy, to one najczęściej mają bardzo szeroki zakres funkcjonalności, którą oferują.

Jak sobie pomyślimy o czymkolwiek z czym się możemy integrować, to najczęściej potrzebujemy tylko jakiś wycinek funkcjonalności oferowanych przez inne systemy, żeby osiągnąć swój cel. Jeżeli nie będziemy wiedzieć dokładnie czego potrzebujemy, co będzie dla nas wystarczające i nie będziemy tego rozumieć, to ciężko będzie nam rozmawiać z partnerem, z którym się integrujemy.

Wydaje mi się, że pomimo, że z jednej strony jest to techniczny aspekt to koniec końców chodzi o biznes i wykonanie określonej logiki biznesowej.

– Czy integracja to tylko duże projekty korporacyjne?

Artur Guła: Mówiliśmy dużo o systemach klasy enterprise, o dużych systemach, o wymianie informacji. Warto pokazać jak to wygląda na mniejszą skalę i że te integracje są wszędzie. Chociaż czasami możemy nawet nie myśleć, że one tam są.

Jako przykład podam aplikację do słuchania muzyki. Wydaje się, że tam nie ma nic poza puszczaniem muzyki. Ale, jeżeli ta aplikacja jest częścią jakiegoś większego ekosystemu, to musi być np. integracja z czymś co uwierzytelni użytkownika, potwierdzi że on ma opłacony dostęp do aplikacji. Dalej mamy integrację z bramką do płatności, gdzie ten użytkownik może sobie opłacić abonament.

Nagrania, których słuchamy nie znajdują się przecież w naszym telefonie. Musimy je pobierać z serwerów, które gromadzą te wszystkie możliwe nagrania z całego świata. Najczęściej trzeba się podłączyć do jakiegoś systemu BI. Do silnika, który podpowie, że temu użytkownikowi trzeba zaserwować te konkretnie piosenki, bo jemu to się na pewno spodoba. Można się połączyć ze sklepem internetowym, w którym będą sprzedawane jakieś fizyczne gadżety, koszulki itp.

Te integracje są wszędzie i teraz cały świat dąży do tego żeby się integrować. Wyzwania niezależnie od skali pozostają podobne.