6 najdziwniejszych języków programowania w historii IT - subiektywny ranking INCAT

Ktoś, kto powiedział, że przy programowaniu nie ma zabawy, z pewnością nie wiedział co mówi. Autorzy poniższych języków programowania potrafili połączyć przyjemne z pożytecznym i na kanwie szalonych pomysłów, stworzyli kody źródłowe, których składnia nie ma nic wspólnego z klasycznymi językami programowania, a mimo tego, może być wykorzystywana przy tworzeniu programów, komend i poleceń. Przed Wami 6 wyjątkowych języków programowania, które brzmią  i wyglądają nieco niepoważnie, ale za to całkiem poważnie działają: 

LOLCODE

Weteranem spośród specyficznych języków programowania jest niewątpliwie LOLCODE, język programowania stworzony w 2007 roku przez Adama Lindseya. Inspiracją do powstania tego języka, był Lolcat - zabawa, popularna swego czasu na forach internetowych, takich jak np. 4chan, która polega na tworzeniu memów, zawierających obraz kota, z zabawnym podpisem oraz nieprawidłową składnią, wraz z celowymi błędami w zapisie poszczególnych słów. 

To właśnie nietypowy zapis treści memów stał się podstawą języka LOLCODE, bowiem komendy pisane są slangiem i jeśli jest on zrozumiały dla odbiorcy, wystarczy do odczytania składni LOLCODE. Poniżej przykład zapisu “Hello World” w LOLCODE:

HAI - “Hello”

CAN HAS STDIO? - Odpowiada za załadowanie bibliotek z dodatkowymi funkcjami

VISIBLE "HAI WORLD!" - Odpowiada za widoczność tekstu

KTHXBYE - Komenda kończąca każdy program

Co ciekawe, język LOLCODE nadaje się do powszechnego użycia, ze względu na swoją komplementarność. W sieci można także znaleźć sporo tutoriali, dedykowanych różnym elementom LOLCODE. 

ARNOLD C

ARNOLD C to język programowania inspirowany...prawdziwym bohaterem. Nazwa pochodzi od imienia odtwórcy głównej roli w kultowej już serii “Terminator”, Arnolda Schwarzeneggera, a składnia języka zawiera cytaty pochodzące wyłącznie z tych filmów. Zatem jeśli jesteś za pan brat z historią o żądnym krwi androidzie, powinieneś także bez problemu zrozumieć w jaki sposób koduje się “Hello World” w ARNOLD C:

IT'S SHOWTIME

TALK TO THE HAND "hello world"

YOU HAVE BEEN TERMINATED

Do tego przykładu chyba nie potrzeba tłumaczenia, prawda? A dla wszystkich chętnych, którzy jeszcze nie znają kultowych tekstów z Terminatora, polecamy zbiór tych najlepszych, oczywiście w ramach nauki nowej technologii i poszerzania horyzontów: https://www.radiotimes.com/movies/arnold-schwarzenegger-quotes/

WHITESPACE

Whitespace opiera się na znakach, które reprezentują niewidoczne odstępy na stronie, czyli na spacjach, tabulatorach, lub nowych wierszach. Każde inne polecenie, czy znak są ignorowane. Ale jak to właściwie działa? Whitespace korzysta z kodu binarnego do reprezentowania danych ze spacjami jako zerami i tabulatorami jako jedynkami. Tak więc na przykład sekwencja tab-tab-tab-space-space przekłada się na 1100 w systemie dwójkowym lub „12” w systemie dziesiętnym. Ze względu na swoją specyfikę, oraz fakt, że do stworzenia klasycznego “Hello World” w Whitespace konieczne jest użycie niemal 1000 niewidocznych znaków, język ten, sam w sobie nie jest zbyt użyteczny, stanowi raczej coś w rodzaju ciekawostki programistycznej. 

VELATO

VELATO to język programowania, który został napisany przy użyciu plików MIDI. Pliki dźwiękowe pełnią w tym przypadku zarówno rolę utworu muzycznego, jak i komend programistycznych. Kluczowe w przypadku tego zapisu są wysokości nut i wielkości odstępów między nimi. Zapis “Hello World” w języku VELATO wygląda tak:

Źródło: http://velato.net/Language/HelloWorld/

reMORSE

Jak już można zauważyć, twórcy specyficznych języków programowania zazwyczaj czerpią inspirację z już istniejących elementów kultury czy nauki. W tym przypadku nie jest inaczej - jak można wnioskować z nazwy, reMORSE jest oparty na założeniach języka Morse’a. Istnieją w nim tylko cztery komendy: kropka (.), Kropka (.I spacja), myślnik (-) i kreska (- i spacja). Specyfikacja reMORSE jest niepełna, ponieważ sam autor jej nie ukończył. 

Na przestrzeni lat powstały odmiany języka reMORSE w postaci: reMorse2, reMorse2.- i reMorse4ever, które miały za zadanie wypełnić luki w pierwotnej wersji tego języka, niestety żadna z nich nie jest postrzegana jako kompleksowy, gotowy do potencjalnego wykorzystania, kod. Poniżej, zapis “Hello World” w reMORSE:

- - - ..- ...-.---.;newline

- - - .-. - ..-.- ...-. ---.;!

- - - ...- . . -.---.;d

----. . . -.---.;l

----. . -...---.;r

----. -...---.;o

----...-.- ..-. ---.;W

//author didn't feel like doing this part

-..............;output all characters

SHAKESPEARE

SHAKESPEARE to język programowania, który ma za zadanie sprawiać wrażenie, że jest wszystkim, tylko nie kodem źródłowym. Dlatego też, na pierwszy rzut oka, SHAKESPEARE wydaje się wyłącznie sztuką dramatyczną, a to dlatego, że jest zbudowany wyłącznie z aktów, scen i postaci, czyli elementów, które zwyczajowo tworzą dramat. Brzmi jak szaleństwo? Zdecydowanie tak, ale w tym szaleństwie jest metoda. 

W języku SHAKESPEARE, bohaterowie przyjmują rolę zmiennych, z kolei ich wypowiedzi, traktowane są jako wyrażenia o zmiennych wartościach. Pytania, zadawane sobie wzajemne przez postaci, to instrukcje warunkowe, natomiast wartości określają przymiotniki i rzeczowniki. Poza ewidentnym odwróceniem konwencji, charakterystyczne w języku SHAKESPEARE jest to, iż programy w nim pisane są bardzo długie. Poniżej fragment “Hello World”: 

To tylko mała próbka najdziwniejszych instrukcji “Hello World” na świecie - w sieci możecie znaleźć ich dużo więcej, a my wybraliśmy te, naszym zdaniem, najciekawsze. Zważywszy na to, że branża IT rozwija się w zawrotnym tempie, na świecie istnieje około 7 000 języków programowania, a w czasie gdy czytasz ten artykuł, powstały pewnie już trzy lub cztery nowe javascriptowe frameworki, takie drobne, dowcipne odstępstwa od normy nie stanowią żadnej przeciwwagi dla “poważnego” programowania. My jednak uważamy, że są potrzebne, bo wskazują, jak można bawić się kodowaniem i tworzyć coś, co może i nie jest specjalnie użyteczne, za to odsłania tę żartobliwą i humorystyczną stronę branży IT, o której tyle się mówi, a zdecydowanie zbyt rzadko pokazuje.


Historia kobiet w IT - najważniejsze dokonania

Choć coraz częściej kobiety decydują się na pracę w IT, statystyki wciąż są nieubłagane. Według raportu fundacji Carrots kobiety w Polsce stanowią jedynie 30% branży IT i nie wygląda na to, by ta tendencja miała się szybko zmienić. A przecież to właśnie kobiety w dużej mierze położyły podwaliny pod aktualny kształt technologii i dokonały odkryć, które do dziś wpływają na świat IT. Dlatego przygotowaliśmy zestawienie kobiet, które miały niebagatelny wpływ na rozwój branży IT, a swoją historią inspirują i pokazują, że technologia nie jest wyłącznie męską domeną.

Kobiety w informatyce – najbardziej znane nazwiska i ich osiągnięcia

Informatyka to dyscyplina naukowa kojarząca się zapewne większości z nas jako jedna z tych, która w zasadzie od zawsze pozostaje zdominowana przez mężczyzn. W takim jej postrzeganiu nie ma nic dziwnego, ponieważ rzeczywiście tak jest, czego potwierdzeniem są cykliczne badania przeprowadzane zarówno w Polsce, jak i innych krajach. Kobiety w informatyce, choć stosunkowo nieliczne, w niektórych przypadkach odgrywają jednak bardzo istotne role. Nie brakuje wśród nich autorek oprogramowania, inżynierek czy twórczyń gier, choć popularność ich nazwisk na pewno pozostaje nieporównywalnie mniejsza niż Steve’a Jobsa lub Billa Gatesa. Chcąc to zmienić, postanowiliśmy dziś przypomnieć o najważniejszych – naszym zdaniem – paniach, które dzięki swoim dokonaniom zaistniały w świecie informatyki, wpływając w niektórych przypadkach w znaczny sposób na jej rozwój. Mamy jednocześnie nadzieję, że w wyniku tego za jakiś czas będziemy mogli ponownie przedstawić kolejne znane kobiety w IT i ich osiągnięcia, stanowiące potwierdzenie tezy, iż płeć nie ma dużego znaczenia, jeśli chodzi o zdolność do wykonywania skomplikowanych operacji z wykorzystaniem komputera i coraz bardziej zaawansowanych technologii. Jeżeli więc jesteś kobietą i dotąd zastanawiałaś się, czy związać swoją karierę oraz przyszłości z informatyką, mając ku temu predyspozycje, niżej przedstawione sylwetki powinny pozwolić Ci skutecznie rozwiać Twoje wątpliwości.

Kobiety odegrały istotną rolę w dziedzinie informatyki i technologii informatycznych, opracowując niektóre z najważniejszych elementów nowoczesnego IT. Do najważniejszych kobiet w historii technologii należą niewątpliwie:

Ada Lovelace - pionierka programowania

Urodzona w Londynie lady Ada Lovelace (1815–1852), choć była córką poety lorda George’a Byrona, miała pasję i dar do matematyki od najmłodszych lat. Jest uznawana za pierwszą na świecie programistkę komputerową, ponieważ opracowała sposób w jaki maszyna zwana silnikiem analitycznym może wykonywać obliczenia. Maszyna ta, wynaleziona przez jej przyjaciela, matematyka i wynalazcę Charlesa Babbage'a, jest uważana za pierwszy komputer uniwersalny. Lovelace stworzyła algorytm, który wkrótce został uznany za pierwszy na świecie program komputerowy, a jego wciąż są wykorzystywane przy tworzeniu dzisiejszych aplikacji.

Edith Clarke - pierwsza kobieta - inżynier

„Zawsze chciałam zostać inżynierem, ale uważałam, że kobiety nie powinny zajmować się takimi rzeczami, jak studia inżynierskie.” - twierdziła Edith Clarke i...mocno się pomyliła, bowiem kilkanaście lat po tej wypowiedzi została pierwszym w historii inżynierem elektrykiem płci żeńskiej na świecie.

Edith Clarke w wieku 18 lat otrzymała niewielki spadek, który pozwolił jej przejść przez Vassar College, wówczas siostrzaną instytucję Yale; ukończyła studia w 1908 roku. Wkrótce rozpoczęła pracę na pełen etat jako menedżer całkowicie żeńskiego zespołu „ludzkich komputerów” w AT&T.

Zdeterminowana, aby kontynuować swoją karierę, robiąc to, czego „kobiety nie powinny robić”, zapisała się następnie na MIT i została pierwszą kobietą tej instytucji, która uzyskała tytuł magistra elektrotechniki. Ale nawet z dotychczasowymi osiągnięciami, żadna firma technologiczna nie chciała jej zatrudnić w roli kobiety - inżyniera. W związku z tym Clarke opuściła Stany Zjednoczone, aby uczyć fizyki w Women's College w Stambule. Nie porzuciła jednak swojego marzenia o karierze inżyniera i po kilku latach wróciła do USA, by pracować dla General Electric, co pozwoliło jej na osiągnięcie upragnionego celu. W General Electric Clarke stworzyła i opatentowała The Clarke Calculator, graficzne urządzenie rozwiązujące równania używane do przesyłania energii elektrycznej liniami przesyłowymi dłuższymi niż 250 metrów. Jej ogromny wkład w międzykontynentalną komunikację telefoniczną uciszył sceptyków; w 1922 roku, mając 38 lat, Edith Clarke została pierwszym zawodowym inżynierem elektrykiem.

Kobiety ENIAC: pionierki komputerów

W 1946 roku, w przeddzień swojego debiutu, pierwszy na świecie komputer ogólnego przeznaczenia zawiódł. W związku z tym, do ratowania projektu oddelegowano siedem kobiet - inżynierów, które miały jedną noc, by naprawić urządzenie o nazwie ENIAC (Electronic Numerical Integrator And Computer), który był przodkiem dzisiejszych komputerów. Do grona tych kobiet należały:

  • Betty Jean Jennings Bartik
  • Kathleen McNulty
  • Mauchly Antonelli
  • Ruth Lichterman Teitelbaum
  • Frances Bilas Spence
  • Marlyn Wescoff Meltzer
  • Frances Snyder Holberton

System nie był ani mały, ani prosty, ważył 30 ton i zajmował 140 metrów kwadratowych. Był wyposażony w 18 000 lamp próżniowych, 70 000 rezystorów, 10 000 kondensatorów i 5 milionów ręcznie lutowanych złączy. Biorąc pod uwagę jego zdolności do obliczania trajektorii balistycznych, potrzeba, by działał, była wielka - Stany Zjednoczone pogrążone były wtedy głęboko w II wojnie światowej.

Niestety, choć projekt się powiódł, bohaterki ENIAC, przez dłuższy czas nie otrzymały należnego im uznania. Dopiero w 1997 roku zostały wprowadzone do Hall of Fame Women in Technology International (WITI). W 2014 roku Walter Isaacson w swojej książce “Innowatorzy” zestawił Siódemkę ENIAC z takimi postaciami jak Steve Jobs i Nikola Tesla, a parę lat temu ukazał się film dokumentalny zatytułowany „Projekt Eniac Programmers”, w którym szczegółowo opisano, w jaki sposób kobiety wymyśliły sposób programowania tej maszyny.

Grace Hooper - ekspertka od bugów

Amerykanka Grace Hopper (1906-1992) była admirałem w marynarce wojennej Stanów Zjednoczonych i jedną z pierwszych programistek kalkulatora mechatronicznego Mark 1, protoplasty dzisiejszych komputerów, wykorzystywanego podczas działań II wojny światowej. Stworzyła także 500-stronicowy podręcznik, w którym wyszczególniono podstawowe zasady działania maszyn komputerowych. Ale to nie koniec jej zasług dla branży IT.

Hopper wraz ze swym zespołem stworzyła pierwszy w historii kompilator komputerowy, który stał się prekursorem dla języka programowania COBOL (Common Business Oriented Language). Niedługo potem COBOL miał się okazać jednym z najczęściej używanych języków w świecie informatyki i choć dziś część ekspertów uważa go za przestarzały, wciąż się z niego korzysta.

Grace Hopper jako pierwsza wprowadziła określenie “bug”, dla błędów w kodzie. Wiąże się z tym anegdota, jakoby któregoś razu do wnętrza sprzętu, na którym pracowała Hooper wleciała ćma, która spowodowała zwarcie. Od tego momentu Hopper spopularyzowała określenie "komputerowy bug" (bug z angielskiego to robak), które odnosi się do błędu programu komputerowego.

Margaret Hamilton - programowanie dla NASA

Margaret Hamilton to amerykańska programistka, inżynier systemów i założycielka dwóch firm technologicznych, która przez lata projektowała systemy NASA. Była dyrektorem działu inżynierii oprogramowania w MIT Instrumentation Laboratory, który stworzył pokładowe oprogramowanie lotnicze, umożliwiające realizację misji Apollo Neila Armstronga i Buzza Aldrina. 22 listopada 2016 roku Hamilton otrzymała od prezydenta Baracka Obamy Prezydencki Medal Wolności za pracę przy misjach NASA Apollo Moon.

Siostra Mary Kenneth Keller - pierwsza kobieta z tytułem doktora informatyki

Pierwszą kobietą, która otrzymała tytuł doktora informatyki, była zakonnica: Mary Kenneth Keller wstąpiła do „Sióstr Miłosierdzia” w 1932 roku, składając śluby w 1940 roku. Keller uzyskała tytuł magistra matematyki na Uniwersytecie DePaul w Chicago i krótko studiowała w Dartmouth. Tam odegrała znaczącą rolę w opracowaniu kluczowego języka komputerowego: uniwersalnego symbolicznego kodu instrukcji dla początkujących o nazwie BASIC.

Dzięki językowi BASIC pisanie oprogramowania nie było już ograniczone do matematyków i naukowców. Jej wkład sprawił, że korzystanie z komputera stało się znacznie bardziej dostępne dla szerszej populacji. Keller wróciła na Środkowy Zachód i w 1965 roku uzyskała tytuł doktora na Uniwersytecie Wisconsin, a następnie stanęła na czele wydziału informatyki Clarke College w Iowa, gdzie pracowała przez kolejne 20 lat.

Susan Kare - odkrycie Steva Jobsa

Chociaż na początku swojej kariery Susan Kare pracowała dla Microsoftu, jej największe osiągnięcia przypadają na okres, gdy współpracowała ze Stevem Jobsem w Apple.

Kare marzyła o karierze artystycznej i po ukończeniu szkoły przybyła do San Francisco, by tam odnaleźć swoją szansę. Przypadkowe spotkanie ze starą koleżanką z liceum zaowocowało rozmową o pracę w Apple. Steve Jobs, zainspirowany graficznym interfejsem użytkownika (GUI) firmy Xerox, poszukiwał artysty, który mógłby zaprojektować ikony Macintosha. Projekty Kare spodobały się Jobsowi na tyle, że zdecydował się podjąć z nią współpracę.

Używając bloku papieru milimetrowego, Kare zaprojektowała więc ikony do Maca, które spełniały trzy zasady: były proste, eleganckie i zrozumiałe. W ramach swojej pracy w Apple Susan stworzyła także krój pisma Chicago, używany w pierwszych czterech generacjach iPoda. Projekty Kare były wykonywane wręcz z obsesyjną i charakterystyczną dla Jobsa dbałością o szczegóły, która zresztą definiuje Apple do dziś.

Carol Shaw - twórczyni gier na Atari

Carol Shaw urodziła się i wychowała w Palo Alto w Kalifornii. Choć od początku świetnie radziła sobie z matematyką, dopiero gdy odziedziczyła model kolejki elektrycznej po swoich braciach, Shaw zaczęła majstrować przy elektronice.

Po ukończeniu programu dla absolwentów informatyki w Berkeley, Shaw przyjęła posadę w firmie produkującej gry Atari pod koniec lat 70. Nosząc okulary w grubych oprawkach i nieśmiertelną flanelową koszulę, rozpoczęła projektowanie i programowanie gier wideo. Shaw zaprogramowała jedną z najbardziej znanych strzelanek Atari, River Raid, która została uznana za najlepszą grę wojenną roku 1984, a praca Shaw jako pioniera w projektowaniu gier uczyniła z niej legendę dwóch pokoleń graczy.

Adele Goldberg

Bez Adele Goldberg pulpit Apple wyglądałby dziś zupełnie inaczej. Pracując w Xerox Palo Alto Research Center (PARC), Adele była jedyną kobietą w grupie, która stworzyła Smalltalk-80, jeden z najpopularniejszych i najbardziej wpływowych wczesnych języków programowania. Przedstawiła również Smalltalk Steve'owi Jobsowi, który zaimplementował sporo założeń tego języka w pierwszych produktach Apple. Poza Apple, wiele nowoczesnych graficznych interfejsów użytkownika (GUI) posiada standardy projektowe, które odnoszą się bezpośrednio do oryginalnej pracy Goldberg.

Radia Perlman - „Nie nazywajcie mnie matką Internetu”

Radia Perlman przez wielu jest uważana za założycielkę Internetu, choć ona sama mocno się od tego odżegnuje, podkreślając, że ​​„Internet nie został wymyślony przez jedną osobę”. Pewnym jest jednak, że to Perlman stworzyła algorytm stojący za protokołem Spanning Tree Protocol (STP), który jest istotną częścią fundamentów Internetu.

Perlman, jako jedna z nielicznych kobiet rozpoczęła karierę naukową na MIT, gdzie w 2000 roku opublikowała swój podręcznik „Połączenia międzysieciowe”, znacznie upraszczając routing sieci i mostkowanie. „Moja książka stworzyła porządek” - powiedziała później.

Pomimo swoich indywidualnych sukcesów, a zwłaszcza stworzenia protokołu STP Perlman podkreśla znaczenie pracy zespołowej w rozwoju technologii i nie chce skupiać się wyłącznie na swoich dokonaniach.

Kobiet, które w znaczący sposób przyczyniły się do rozwoju technologii jest oczywiście o wiele więcej, my jednak wybraliśmy sylwetki tych dziesięciu, które na przestrzeni lat udowadniały, że mogą przecierać szlaki w różnych obszarach IT i nie boją się wyzwań związanych z tworzeniem nowoczesnych rozwiązań informatycznych. Wszystkim kobietom, które mają aspiracje, by wejść do branży IT, życzymy, by nie wahały się i próbowały swoich sił, idąc za przykładem bohaterek naszego artykułu.


5 lat INCAT - co udało nam się osiągnąć?

W tym roku minęło pięć lat trwania naszej spółki, w związku z tym pokusiliśmy się o podsumowanie tego czasu. Choć za nami sporo trudnych chwil, wyzwań i wymagających klientów, dziś jesteśmy w miejscu, o którym nawet nie marzyliśmy, tworząc INCAT. Zaczynaliśmy od drobnego outsourcingu IT, a dziś jesteśmy jednym z nielicznych dostawców systemów transakcyjnych na świecie. Zrobiliśmy ogromny postęp i dziś chcielibyśmy go podsumować. Wybraliśmy więc 5 przełomowych momentów, które pozwoliły nam się mocno rozwinąć, choć czasami kosztowały nas kilka nieprzespanych nocy :).

Początek

Rozpoczęliśmy działalność w roku 2016, jako dostawcy body leasingu, udostępniając specjalistów IT naszym partnerom i klientom. Zaczynaliśmy skromnie, od kilku specjalistów i małych projektów, mając nadzieję, że na stałe zagrzejemy miejsce na rynku usług outsourcingowych. Z czasem pula naszych specjalistów sukcesywnie rosła, a liczba projektów, które obsługiwaliśmy, zapewniała nam tak potrzebny rozwój.

Rozwój outsourcingu i nowy model współpracy

Na przełomie 2017 i 2018 rozwinęliśmy zakres naszych usług outsourcingowych o team sharing i zaczęliśmy udostępniać naszym klientom całe zespoły projektowe. Jednocześnie rosnąca popularność body leasingu pozwoliła nam podjąć współpracę z kilkoma kluczowymi bankami w Polsce. To jednak nie wszystko. Wkrótce okazało się, że sporo naszych klientów, bardziej niż outsourcingu, potrzebuje bardziej kompleksowego wsparcia technologicznego w prowadzonych projektach IT. To dało nam przestrzeń do adaptacji modelu outsourcingowego o nazwie CoLab, w ramach którego przyjęliśmy rolę partnera technologicznego, oraz sporą część odpowiedzialności za prowadzone projekty. Wątki outsourcingowe rozwijały się bardzo sprawnie, tymczasem my nabraliśmy chęci, by nieco rozszerzyć zakres naszego portfolio - tym razem o rozwiązania dla branży finansowej.

Powstanie BOS Fintech

Wkrótce wraz z jednym z naszych kluczowych Klientów rozpoczęliśmy pracę nad naszym pierwszym  produktem, jakim jest kompleksowy system transakcyjny dla podmiotów finansowych BOS. Założyciele INCAT wywodzą się z branży bankowej, nic więc dziwnego, że nasze zainteresowanie skupiło się wokół zmian i rozwoju rynku finansowego. Wraz z rosnącą popularnością fintechów i pozabankowych podmiotów finansowych pojawiła się potrzeba stworzenia nowoczesnego i elastycznego systemu transakcyjnego, który, w przeciwieństwie do klasycznych systemów transakcyjnych, będzie szybki we wdrożeniu, oraz łatwy w modyfikacji. Stąd pomysł na BOS Fintech, system zarządzania rachunkami i transakcjami finansowymi. Od pomysłu do realizacji jednak długa droga, zwłaszcza, że systemy transakcyjne są niezwykle skomplikowane funkcjonalnie, a ekosystem finansowy obwarowany jest wieloma legislacyjnymi ograniczeniami. Dzięki wierze w końcowy sukces i ogromnej pracy naszych zespołów, udało nam się stworzyć projekt wykraczający poza pierwotne założenia. To oczywiście nie koniec. Dziś i przez kolejne lata będziemy rozwijać nasze rozwiązanie, zwłaszcza, że rynek usług finansowych zmienia się w zawrotnym tempie, a my zamierzamy dotrzymać mu kroku.

Pomysł na INCAT FaaS AI

Analizując potrzeby biznesowe nowoczesnych fintechów i challenger banków, uznaliśmy, że podmioty finansowe, które są w początkowej fazie rozwoju, potrzebują rozwiązania technologicznego, które będzie optymalne kosztowo i nie będzie wymagać znaczącego zaangażowania ze strony klienta. We współpracy ze specjalistami Politechniki rozpoczęliśmy projekt INCAT FaaS AI, czyli platformy transakcyjnej w formie usługi. Udało nam się jednocześnie otrzymać dofinansowanie przedsięwzięcia w ramach programów Narodowego Centrum Badań i Rozwoju, co znacząco zwiększyło nasz budżet projektowy i pozwoliło błyskawicznie rozpocząć pracę nad platformą. Co ciekawe, już po kilku miesiącach pracy nad projektem, mogliśmy rozpocząć pierwsze, komercyjne wdrożenie INCAT FaaS AI, w jednym z polskich fintechowych start up’ów, co potwierdziło słuszność naszego pomysłu.

Pandemia

Początek 2020 roku to oczywiście ogólnoświatowa pandemia, konieczność pracy zdalnej i spowolnienie gospodarcze. Na szczęście, zwłaszcza w porównaniu do innych branż, INCAT ominęły większe problemy. Udało nam się sprawnie przejść na całkowitą pracę zdalną i choć potrzebowaliśmy nieco czasu by poczuć się pewnie w takiej formule, wkrótce okazało się, że nasza efektywność i skuteczność nie zmalała. W tym niełatwym czasie kontynuowaliśmy współpracę naszymi Klientami bez zakłóceń.

Z kolei w listopadzie byliśmy świadkami triumfu jednego z naszych partnerów biznesowych. ZEN.COM, bo o nim mowa, wystartował komercyjnie ze swoją aplikacją do płatności mobilnych i dedykowaną kartą Mastercard. Dla nas był to także spory sukces, bowiem jesteśmy głównym dostawcą systemu transakcyjnego, na którym opierają się płatności ZEN. Rok udało nam się zamknąć jeszcze jednym, bardzo ciekawym projektem team sharingowym dla klienta z Bliskiego Wschodu, zatem grudniowe i świąteczne klimaty zostały odrobinę przytłumione intensywnymi negocjacjami umowy.

Co dalej?

Właściwie nasze plany na kolejne miesiące mogłoby oddać jedno zdanie: idziemy do przodu. Kontynuujemy współpracę z dotychczasowymi Klientami - pracujemy z ZEN nad rozwojem technologicznym ich oferty biznesowej, rozwijamy platformę podstawowych usług finansowych dla klientów inwestycyjnych, którą oferuje jeden z naszych fintechowych partnerów, a nasze zespoły projektowe wspierają budowanie innowacji w dużych polskich bankach. Wewnętrznie rozwijamy także nasze produkty i usługi, dodając do nich nowe moduły i mikroserwisy. O rozwoju systemu BOS i jego nowych funkcjonalnościach możecie przeczytać tutaj. Przed nami także rebranding produktowy, który wizualnie i komunikacyjnie ułatwi odbiór naszych produktów i usług.

Patrząc na najbliższe kilka miesięcy, widzimy, że czeka nas mnóstwo wyzwań i jeszcze więcej pracy, ale to dobrze, bo naszym celem jest stały rozwój.

 

 


Scrum w dużych projektach bankowych - pierwszy podcast!

W INCAT rozpoczęliśmy przygodę z podcastami. W efekcie przygotowaliśmy dla Was rozmowę z naszym incatowym Scrum Masterem, Karolem Kłaczyńskim, z którym omawiamy temat Scruma w dużych projektach bankowych. Odnośnik do podcastu znajdziecie poniżej, a jeśli nie macie tyle czasu by przesłuchać całość, zapraszamy do poniższego artykułu, w którym zebraliśmy dziesięć kluczowych wskazówek i ważnych stwierdzeń, które padły w podcaście. Bierzcie więc i czytajcie z tego wszyscy :).

O zwinności biznesowej

Zwinność biznesowa to swoisty mindset, sposób myślenia nastawiony na ludzi, na dostosowywanie się do zmian. Scrum z kolei to framework, który promuje podejście zwinne, czyli jest to zestaw pewnych zasad, zdarzeń, ról i artefaktów, które można obudowywać swoimi elementami i który pomaga sobie radzić ze skomplikowanymi projektami biznesowymi i tworzeniem rozbudowanych systemów. Zwinny sposób myślenia pomaga się dostosowywać do wymagań klienta i, w efekcie, tworzyć lepsze rozwiązania.

O zwinności w projekcie i zwinności na poziomie organizacji

Zwinność na poziomie tworzenia produktu jest kluczowa, ale równie ważne jest, aby zwinne podejście prezentowała cała organizacja. Najlepiej widać tę zależność na przykładzie. Problem, który może się pojawić, to na przykład kwestia tego, że potrzebujemy nowego sprzętu w projekcie. I jeśli organizacja nie działa zwinnie, a osoby, które odpowiadają za tego rodzaju sprawy są swoistym wąskim gardłem organizacji, to nawet jeśli na poziomie projektu zespoły działają zwinnie, niewiele to pomoże, jeśli na trzy monitory i dwa notebooki będziemy czekać trzy-cztery tygodnie. Zespół jest zblokowany zewnętrznymi zależnościami, co odbija się na powodzeniu projektu.

O transformacji w organizację zarządzaną zwinnie

Ważne jest zrozumienie i wola ze strony zarządu. Zrozumienie, że jeśli organizacja nie będzie działać zwinnie, to efekty będą ograniczone. Warto też wybrać “agentów zmiany”, czyli osoby, które mają doświadczenie w pracy zwinnej i mają na tyle duże poważanie oraz posłuch u pozostałych członków organizacji, by móc tę zmianę propagować i przeprowadzać. Na początku kluczowe jest jednak, aby ustalić zasady, reguły i proces przejścia na agile w organizacji, w taki sposób, by był on jak najbardziej dopasowany do specyfiki i wymagań danej firmy. Stworzenie kontraktu w takiej sytuacji może być dobrym pomysłem, natomiast warto pamiętać o tym, by raczej go nie spisywać - określić i zobowiązać się do jego przestrzegania, ale niekoniecznie traktować jak pisemnej umowy. To jest na początku bardzo trudne, ale z mojego doświadczenia wynika, że im większy poziom zaufania w zespole/ organizacji, tym z czasem jest łatwiej trzymać się opracowanych postanowień.

O projektach, w których scrum się nie sprawdza

Bardzo małe produkty, albo tworzenie proof of concept to coś, do czego scrum niespecjalnie przystaje i może być czymś w rodzaju armaty na wróble. Inwestycja w scruma w małych, niewymagających projektach może być wyższa niż oczekiwane korzyści. Jeśli produkt jest oczywisty i mamy bardzo dokładnie opisane wymagania i pewność, że założenia biznesowe raczej się nie zmienią, to w takiej sytuacji wprowadzanie scruma nie jest dobrym pomysłem. Scrum dobrze radzi sobie w projektach rozbudowanych, dynamicznych, z często zmieniającymi się zarówno oczekiwaniami klienta, jak i warunkami rynkowymi.

O narzędziach, które daje scrum

Scrum daje pewne zasady, definicje, nadaje role w projekcie. Cele poszczególnych ról i wydarzeń są dobrze i jasno opisane w Scrum Guide, co bardzo ułatwia promowanie zwinności w organizacji. Jeśli się wczytamy w Scrum Guide’a, zobaczymy w jaki sposób każdy ten element wspiera zwinność. Na przykład Daily Scrum tę zwinność wspiera w ten sposób, że de facto cały czas planujemy i mamy pod kontrolą to co robimy jako zespół na bieżąco, dostosowujemy się natychmiast do nowych wymagań, od razu rozwiązujemy problemy, wyciągamy je “na wierzch” każdego dnia, a nie raz na dwa tygodnie, gdy zdążą już urosnąć do niebotycznych rozmiarów. Backlog z kolei pokazuje jaki mamy plan na najbliższy czas, a dostosowanie backlogu do nowych warunków pomaga łapać szerszą perspektywę nie tylko na najbliższy sprint, ale także na miesiąc, czy dwa do przodu.

O relacji Scrum Mastera z Product Ownerem

Rola Scrum Mastera wobec Product Ownera to przede wszystkim nauka pracy w ramach zespołu scrumowego, wsparcie w kwestiach budowania backlogu i tworzenia analizy biznesowej. Product Owner to taka osoba, która musi dużo mówić “nie”, bo, zwłaszcza w dużych organizacjach, istnieje sporo stakeholderów i osób decyzyjnych, a każdy z nich jest tak samo mocno przekonany o tym, że jego pomysł, jego funkcjonalność jest kluczowa. I jakoś trzeba tym zarządzić, w czym czasami nieodzowna jest pomoc i wsparcie Scrum Mastera.

O wyzwaniach scruma w dużych projektach

Sporym problemem jest to, że wiele organizacji chce zbyt szybko skalować swoje bardzo zaawansowane produkty, bez podchodzenia do tematu iteracyjnie. Podejście iteracyjne to takie, w którym mamy jeden zespół, on pracuje na zwinnych zasadach, a następnie rozwijamy kolejny, w którym umieszczamy agentów zmiany i oni uczą ten nowy zespół przestrzegania zasad agile. Niestety, zazwyczaj jest tak, że mamy jeden zespół, dorzucamy osiem kolejnych, nikt nie rozumie na czym polega zwinność, ale liczy się sam fakt, że “pracujemy w scrumie”. Inna sprawa to fakt, że w dużych, wielozespołowych projektach planowanie odbywa się na wyższym poziomie, czasami trzeba je organizować pomiędzy reprezentantami poszczególnych zespołów. Jest też kwestia komunikacji wewnątrz zespołów - problemy jednego zespołu wpływają na pozostałe. Wyobraźmy sobie, że mamy jakiś wspólny komponent, czy bibliotekę z której korzystają wszyscy w projekcie i nagle zmieniamy jej wersję. Pozostałe zespoły muszą o tym wiedzieć, przygotować się na to, zsynchronizować działania. Jeśli komunikacja pomiędzy zespołami zawodzi, takich procesów nie da się przeprowadzić bez wpadek. Mówiąc krótko - wszystkie problemy, które występują na poziomie jednego zespołu, w przypadku kilku lub kilkunastu mocno się skalują - i to w postępie geometrycznym.

O zwinności w branży bankowej

Zwinność w branży bankowej już jest. Jeszcze nie na poziomie systemów centralnych, ale na poziomie np aplikacji czy portali, podejście zwinne całkiem nieźle się przyjęło. Klienci w branży bankowej niejako wymagają tych zmian - istnieją rozwiązania typu Revolut, które świetnie i szybko odpowiadają na zmiany w obrębie wymagań biznesowych i to sprawia, że branża bankowa musi się szybciej dostosowywać do klienta, bo konkurencja, nierzadko bardziej elastyczna, nie śpi.

O procedurach w bankowości

Zwinność i Scrum może w pewien sposób uświadomić decydentom w projektach bankowych po co istnieją wybrane procedury. I ze względu na transparentność, rozwiązywanie problemów i reagowanie na bieżąco, nierzadko może się okazać, że praca w Scrumie identyfikuje, które procedury są przestarzałe, nieadekwatne, niepotrzebne. Scrum pyta “dlaczego” i “po co” i dzięki temu pomaga uporządkować pracę, oszczędzać czas i w efekcie pieniądze.

O pogodzeniu monolitu ze Scrumem

Monolity nie lubią zmian, to rzecz oczywista. Ale, zazwyczaj monolity mają takie elementy, które można powoli wydzielać i przekształcać je w elementy zwinne. Oczywiście, można mieć ambicję, by projektem monolitycznym zarządzać całkowicie zwinnie, natomiast wiąże się z to dużymi wyzwaniami typu koszty, czas, nieodporność na zmiany. Wydaje się więc, że strategia wolniejsza, ale pozbawiona tych wszystkich ryzyk, polegająca na wydzielaniu modułów które da się elastycznie zarządzać jest lepszą opcją.

Chcesz sięgnąć po więcej? Całą rozmowę z Karolem znajdziesz tutaj:

https://soundcloud.com/user-381845270/scrum-w-duzych-projektach-bankowych


Rewolucja w podejściu do outsourcingu - teraz robi się to inaczej

Ostatnie tygodnie upłynęły pod znakiem negatywnych zmian i drastycznych, biznesowych ruchów - z uwagi na pandemię faktem stały się masowe zwolnienia, przesunięcia i ograniczanie kosztów prowadzenia biznesów. Choć w branży IT sytuacja pod wieloma względami jest bardziej stabilna, eksperci przewidują, że i tu można oczekiwać nieuchronnych, zmian. 

 

Choć jeszcze w lutym 2020 r. IDC przewidywało wzrost światowego rynku IT nawet o 4,3% w skali roku, marcowe prognozy sugerują, że przy końcu 2020 nastąpi spadek do poziomu 1,3% przy stałych kursach walutowych. Wszystko ze względu na trudną sytuację firm, które w obliczu ograniczonych budżetów szukają alternatyw w obszarze zatrudnienia oraz optymalizacji kosztów pozwalających na przetrwanie i wsparcie realizacji dalszych celów biznesowych.

 

Tymczasem, na co wskazują eksperci, w obliczu globalnych problemów związanych z koronawirusem, niektóre zmiany mogą przyjąć zaskakujący obrót. Bo choć aktualnie większość sektorów gospodarki znajduje się w bardzo ciężkim położeniu, może się okazać, że doświadczenia związane z epidemią będą dla sporej liczby firm motywacją do wdrożenia działań ułatwiających funkcjonowanie w sytuacji kryzysowej. Można w tym upatrywać szansy na spory rozwój obszarów automatyki i robotyzacji, a także, jak potwierdza w swoim badaniu Antal, liczyć na wzrost popularności usług outsourcingowych, przede wszystkim w obszarze IT.

Firmy zmieniają swoje podejście do outsourcingu

Wszystko zakiełkowało już w 2018 roku, kiedy firmy zaczęły zmieniać swoje postrzeganie roli usług zewnętrznych w biznesie. Wcześniej główną motywacją przy korzystaniu z outsourcingu była chęć redukcji kosztów i zwolnienia zasobów firmowych do innych celów. Dziś podejście to rewolucjonizuje się, bo jak wynika z raportu Deloitte, przedsiębiorcy przestali patrzeć na outsourcing wyłącznie w kategoriach wsparcia back-office, ale zaczęli go traktować jako sposób na zdobycie przewagi rynkowej - poprzez transfer wiedzy i technologii pomiędzy klientem a dostawcą usługi. I choć optymalizacja kosztów jest nadal niezwykle ważnym kryterium, przestała być kryterium kluczowym. Tę tendencję zdają się potwierdzać wnioski z raportu GSA (Global Sourcing Association) dotyczącego trendów w outsourcingu, zgodnie z którym dziś decydenci znacznie bardziej koncentrują się na ogólnej wartości dla organizacji, a nie tylko na redukcji kosztów. Głównym celem outsourcingu staje się więc wspieranie klienta w zdobyciu przewagi konkurencyjnej, poprzez zmianę sposobu funkcjonowania i wdrażanie działań zwiększających poziom elastyczności, wydajności i skuteczności organizacji.

 

Zmiany napędzane przez pandemię 

Choć zmiany w relacji dostawca outsourcingu - klient rozpoczęły się już wcześniej, aktualna sytuacja może przyspieszyć ich tempo. - Zastój gospodarczy spowodowany przez pandemię koronawirusa sprawił, że kontynuacja sporej liczby projektów w dotychczasowej formie stanęła pod znakiem zapytania. Dziś wiele firm boryka się też z sytuacją, której nie mogą nagle, z dnia na dzień, po prostu porzucić prowadzenia zaawansowanych technologicznie projektów, ze względu na umowy, terminy czy zewnętrzne finansowanie. W związku z tym w wielu z nich koniecznością stała się kontrola wydatków na zadania i bilansowanie firmowych zasobów, aby móc przetrwać najbliższe kilka miesięcy - mówi Piotr Hanusiak, CEO INCAT.

 

Jak tłumaczy, obecnie większość firm decyduje się na całkowite zawieszenie prowadzonych wewnętrznie tematów, wobec czego zespoły techniczne i projektowe zostają zwalniane, a działy HR i rekrutacji działają na zmodyfikowanych zasadach. To jednak rozwiązanie krótkofalowe - pozwala przetrwać trudny czas, ale generuje duży problem w momencie, gdy sytuacja z pandemią ustabilizuje się i nastąpi wznowienie działań projektowych. Wówczas może okazać się, że brakuje specjalistów IT, którzy poprowadzą projekt, co więcej - brakuje także rekruterów, którzy mieliby podjąć się ponownego kompletowania zespołów. A należy pamiętać, że rekrutacja, zwłaszcza w branży IT, jest wyjątkowo kosztowna, nie wspominając o konieczności dopasowania kandydatów do specyfiki projektu i stacku technologicznego, co jest nie tylko czasochłonne, ale i zwyczajnie trudne. Wówczas rozsądnym rozwiązaniem może okazać się outsourcowania projektów do zewnętrznego dostawcy, ale w taki sposób, by nie stracić wpływu na ich ostateczny kształt. I dlatego, dostępne do tej pory modele współpracy wydają się zdecydowanie niewystarczające. Piotr Hanusiak uważa, że aby przetrwać kryzys wywołany przez pandemię konieczne jest unowocześnienie podejścia usługodawców outsourcingu i modyfikacja oferowanych wcześniej modeli współpracy. Jak mówi: 

 

- Na przestrzeni ostatnich 20 lat dynamika rozwoju branży IT jest bardziej niż imponująca. Zmieniają się cele biznesowe, pojawiają nowe szanse i możliwości, ale przede wszystkim ewoluują potrzeby, które technologia sama kreuje. Uczestniczymy w tym procesie i dlatego dostrzegamy te momenty, w których konieczna jest zmiana utartych modeli współpracy. Teraz, jeszcze bardziej niż wcześniej, należy tworzyć rozwiązania jak najbardziej kompleksowe i elastyczne, by nie tylko oferować usługę, ale przede wszystkim wspierać klientów w procesie technologicznych zmian. Dlatego nowoczesne modele outsourcingowe muszą łączyć w sobie zalety klasycznych, znanych do tej pory form, dających klientowi kontrolę nad procesem, a jednocześnie zdejmować z niego obciążenie związane z tworzeniem oprogramowania czy produktu. W takim modelu usługodawca przestaje być wyłącznie dostawcą usługi - jego rola ewoluuje do roli partnera technologicznego.

 

Firmy outsourcingowe będą współdzielić odpowiedzialność

Tym, co ma odróżniać nowoczesny model współpracy od innych form outsourcingu, jest wzięcie przez dostawcę odpowiedzialności za projekt na równi z zamawiającym. W projektach technologicznych ryzyko biznesowe jest niemal z góry wkalkulowane w proces, bo nawet najlepiej zaplanowany projekt nie jest wolny od nieprzewidzianego. Przy czym to nieprzewidziane zwykle przyjmuje różnorakie formy: od błędów w kodzie, przez  niespodziewane koszty, aż po rotacje pracowników. Każdy taki problem oznacza dodatkowy stres, czas oraz pieniądze, a każda wdrożona zmiana wydłuża już i tak napięty do granic możliwości harmonogram prac. W nowoczesnych modelach ryzyko dotyczące projektu ma spoczywać na barkach dostawcy usługi, a po stronie klienta ma pozostać kontrola nad procesem. Takie dzielenie odpowiedzialności sprawi, że dostawca usługi bardziej niż podwykonawcą stanie się partnerem w projekcie, choć pełne prawo do wytworzonego oprogramowania nadal posiadać będzie tylko klient i tylko on będzie mógł modyfikować, rozwijać i czerpać korzyści finansowe z produktu. Także ze względu na to, coraz częściej odchodzić się będzie od modelu płatności na podstawie przepracowanego czasu i wartości wykorzystanych narzędzi, na rzecz stałej ceny za wykonanie projektu, co ma pozwolić optymalizować koszty i kontrolować wydatki.

 

- Przed branżą IT niewątpliwie czas zmian, których kierunek na razie trudno przewidzieć. To, co można z całą pewnością stwierdzić, to że sytuacja związana z epidemią już na przestrzeni najbliższych kilku miesięcy zmusi wielu przedsiębiorców do zmiany modelu biznesowego i przeorganizowania przepływu kosztów. I choć zmieniający się paradygmat outsourcingu stanowi duże wyzwanie zarówno dla klientów, jak i dostawców usług, to model nowoczesnej współpracy, w którym rozszerza się zakres działań i odpowiedzialności dostawcy, przy jednoczesnym zachowaniu nadzoru przez zamawiającego, będzie coraz popularniejszy - podsumowuje Piotr Hanusiak.

 

 


Co sprawia, że architektura mikroserwisów jest tak efektywna?

Od kilku lat na rynku IT możemy obserwować rosnącą popularność mikroserwisów, które powoli spychają na boczny tor dominującą do tej pory architekturę monolityczną. Struktura mikroserwisów, w przeciwieństwie do monolitu to zbiór wielu, niezależnych od siebie usług i procesów, które razem tworzą aplikację. Mikroserwisy to wygodne rozwiązanie przy tworzeniu zaawansowanego systemu lub dużych aplikacji - pozwala na szybkie wdrożenie projektu oraz równoległą pracę nad kilkoma modułami jednocześnie. Choć na mikroserwisach swoje rozwiązania oparli tacy giganci jak Netflix czy Uber, nie tylko to stanowi o niezwykłości tego podejścia.

Elastyczność
Mikroserwisy, w przeciwieństwie do architektury monolitów pozwalają na łatwą modyfikację funkcjonalności w projekcie. Ze względu na to, że każdy mikroserwis to niezależny element aplikacji, można zmieniać, dodawać i usuwać kolejne komponenty w taki sposób, by nie wpływało to na funkcjonowanie całości. Odpadają zatem takie problemy jak cykliczna zmiana testów automatycznych czy ryzyko zatrzymania całej aplikacji przy wdrożeniu następnego modułu.

Łatwa integracja
Otwarte API, wykorzystywane w architekturze mikroserwisów pozwala na szybką i bezproblemową integrację z innymi serwisami. Rozwiązanie takie jak API Gateway pośredniczy w komunikacji pomiędzy modułami, umożliwiając wygodne dostosowanie API pod konkretnych klientów, bez potrzeby umieszczenia go w każdym mikroserwisie.

Skalowalność
Podejście modułowe pozwala błyskawicznie i efektywnie reagować na dynamikę środowiska biznesowego - zmiana wymagań biznesowych nie oznacza restrukturyzacji całej aplikacji, a jedynie tego modułu, który dotyczy danej funkcjonalności. Ponadto w przypadku dużych obciążeń mikroserwisy pozwalają na sprawne zwiększenie liczby instancji, które balansują nadmiarowy ruch w aplikacji, co także adresuje problem wydajności.

Szybkie wdrożenie 
Mikroserwisy dają możliwość szybkiego releasu MVP systemu. Wdrożenie w pełni działającej, podstawowej i gotowej do dalszego rozwoju aplikacji jest przy tej architekturze kwestią kilku tygodni. Z kolei dodawanie kolejnych modułów i modyfikacja już istniejących nie komplikuje w żaden sposób możliwości korzystania z systemu przez klientów, ponieważ jest zwyczajnie mniej inwazyjne niż w przypadku monolitu i nie oddziałuje na core aplikacji.

Niezależny development i autonomia
Architektura rozproszona oznacza także niezależność zespołów projektowych. Nie ma tutaj centralnego ośrodka zarządzającego, dzięki czemu przepływ informacji jest płynniejszy. Każdy zespół pracuje nad “swoim” elementem aplikacji i nie musi brać pod uwagę baz danych czy architektury pozostałych modułów. Co ciekawe, mikroserwisy pozwalają na rozwijanie każdego elementu w innej technologii i języku, oraz utrzymanie serwisów na osobnych serwerach i w repozytoriach. Tak rozumiana niezależność rozwiązuje problem długu technicznego oraz zwiększa efektywność samego systemu.

 

Oczywiście, mikroserwisy nie są lekiem na całe zło. Póki co, nie istnieje architektura, która byłaby pozbawiona wad, a przy tym nadawałaby się do każdego typu aplikacji. Nie inaczej jest z mikroserwisami. W przypadku gdy rozważasz wdrożenie architektury mikroserwisów, kluczowym pytaniem, które powinieneś sobie zadać nie jest “Czy?”, tylko “Jak?”, bowiem nieprawidłowe opracowanie wymagań technicznych i struktury, czy brak przemyślanej obsługi ruchu pomiędzy serwerami, może wyrządzić ostatecznie więcej złego niż dobrego. Zaniedbanie tych kwestii na etapie planowania może spowodować klasyczne wylanie dziecka z kąpielą i w efekcie najprawdopodobniej okaże się, że architektura, która w założeniu miała wiele spraw ułatwić, tak naprawdę spędza sen z powiek wszystkim zainteresowanym. Warto wtedy rozważyć wsparcie partnera technicznego, który ma doświadczenie w tworzeniu rozwiązań opartych o mikroserwisy. Dzięki temu ominiesz wiele trudności związanych z wdrożeniem i jednocześnie będziesz mieć pewność, że czeka Cię sprawny release oraz system, który można modyfikować na tyle elastycznie, by na bieżąco dostosowywać się do szybko zmieniających się wymagań biznesowych.