Wyobraź sobie taką sytuację. Twój dział marketingu jest gotowy na wejście w nowy kanał sprzedaży. Produkty przygotowane, kampanie ustawione, ludzie pełni energii i nagle słyszysz od IT Nie da się, nasz system tego nie obsłuży albo nasz system tego nie dźwignie. To zdanie słyszę bardzo często w 2025 roku. I wiesz co jest w tym najgorsze? Wcale nie technologia. Najczęściej problemem jest zła architektura IT.

Problemy wynikające ze złej architektury IT

Systemy, które zamiast wspierać biznes, zwyczajnie go ograniczają. Dziś pokażę Ci 5 kluczowych zasad planowania architektury IT, które pozwolą Ci skalować biznes i zatrzymać najlepszych ludzi w zespole. Nie przedłużając, serdecznie zapraszam. Cześć, dzień dobry. Z tej strony Grzegorz Tabor, a to jest podcast IT i biznes, gdzie jako dyrektor technologiczny pomagam przedsiębiorcom i menedżerom realizować projekty IT, które wspierają cele biznesowe skutecznie i w terminie. Jeśli napotykasz na swojej drodze wyzwania i potrzeby wsparcia Twojego biznesu świadomie z użyciem technologii, ten podcast jest dla Ciebie.

Architektura IT jako fundament biznesu

Architektura IT jest jak fundament pod budynek. Jeśli zaplanujesz go dobrze, możesz dobudowywać piętra, zmieniać układ ścian, otwierać nowe przestrzenie, czy robić wszelkiego rodzaju dobudówki. Jeżeli zaplanujesz źle, każdy remont, każda rozbudowa skończy się katastrofą. W biznesie jest podobnie. Systemy, które dziś wybierasz mogą być Twoim największym akceleratorem wzrostu albo najcięższą kotwicą, która zatrzyma Twój rozwój na lata. Problem w tym, że wielu właścicieli firm myśli o systemach jak o narzędziach, które punktowo mają rozwiązać jakiś problem. W 2025 roku architektura IT powinna wspierać strategię biznesową i powinna być traktowana jako systemowe rozwiązanie, a nie rozwiązanie punktowe, które naprawia tylko jakiś jeden określony obszar. Z tym wylewaniem fundamentów pod budynek jest o tyle ciekawa historia, że często w budownictwie jednak wyburza się budynek i buduje zupełnie od podstaw właśnie po to, żeby ten fundament był dobry. Natomiast w przypadku rozwiązań IT jest tak, że można architekturę IT zmapować taką jaka ona jest w chwili obecnej, zastanowić się jaka ona powinna być i można dużo prościej niż w budownictwie przejść z punktu A do punktu B według określonego planu tak zwanej roadmapy. I w dzisiejszym odcinku tak jak obiecałem zwrócę uwagę na pięć istotnych czynników kiedy wybierasz nowe systemy IT, które chcesz umieścić w ramach swojej architektury, czyli w ramach tej swojej podstawy, fundamentu. 

Zasada 1: Vendor lock-in – cichy zabójca wzrostu

Zasada pierwsza. Vendor locking to cichy zabójca wzrostu. Vendor locking czyli takie pojęcie, które mówi o tym, że nie powinniśmy uzależniać się od jednego określonego dostawcy lub np. od jednego określonego systemu jest jednym z najdroższych błędów jakie możesz popełnić. I wbrew pozorom to nie zaczyna się w momencie podpisania umowy czy uruchomienia danej aplikacji. To zaczyna się właśnie na etapie projektowania architektury. Przykład z życia. Firma dystrybucyjna zaufała znanej firmie udostępniającej system do integracji sklepów z przeróżnymi hurtowniami, market placami, taki hub do integracji dostępny w formie abonamentowej. Wszystko było dobrze do czasu zmiany strategii cennika tej firmy. I okazało się, że w wielu biznesach oprogramowanie to było tak dogłębnie wykorzystywane, tak bardzo zakorzenione w procesach, że jest ogromną trudnością z niego zrezygnować, a z drugiej strony cena wzrosła nawet dziesięciokrotnie. Zatem pamiętaj, aby decydując się na rozwiązania gotowe, abonamentowe, zwrócić uwagę na to, aby mieć zapisane pełne prawo do eksportu danych, aby w razie kiedy chciałbyś zrezygnować z takiego rozwiązania, to abyś zwyczajnie był w stanie to zrobić. Abyś sprawdził jak system integruje się z innymi narzędziami. Czy udostępnia tzw. API, o którym za chwilę powiem trochę więcej. Warto też zwrócić uwagę na to, aby traktować każdy tego typu system abonamentowy, który szybko jesteś w stanie wdrożyć, w pewnym sensie jak klocek Lego, taki, który można w każdej chwili wymienić na jakikolwiek inny klocek, czy to większy, czy w innym kolorze. Mam na myśli, że jeżeli wybierzesz tego typu system, wdrożysz go do firmy, to miej to świadomość, że jesteś w stanie go wymienić na jakikolwiek inny system tej samej klasy. Jeżeli cokolwiek pójdzie nie tak z tym jednym konkretnym dostawcą, od którego w pewnym sensie się uzależnisz, ale w pełni świadomie. Jeśli to zaniedbasz, po kilku latach taki system może hamować rozwój twojej firmy. 

Zasada 2: API First jako strategia biznesowa

Zasada druga. API First to strategia biznesowa. Wielu właścicieli firm myśli, że API First to technologia. Nie do końca. Uważam, że to jest przede wszystkim mądre podejście do rozbudowy i w ogóle podejście do działania z rozwiązaniami gotowymi. Czym to API czy też API jest? Jest to taka metoda, interfejs, dzięki któremu systemy informatyczne są w stanie między sobą wymieniać dane. Taka wtyczka, trochę taki most, który pozwala na dodanie albo pobranie jakichś informacji, danych z danego systemu. Czyli zwyczajnie w świecie pozwala ci na integrowanie tego konkretnego systemu z innymi systemami i aplikacjami, które będziesz chciał wdrażać w ramach swojej architektury. Jeśli projektujesz architekturę IT tak, żeby wszystkie systemy komunikowały się poprzez API, to dzięki temu możesz łatwo wdrożyć AI, bo dane są dostępne do zasilania tego AI. Możesz podłączyć nowe kanały sprzedaży w kilka dni. Możesz na przykład wymieniać pojedyncze moduły bez paraliżowania całej firmy. Przykład z życia. System, który przejęliśmy po innym software house'ie u klienta, firma z branży e-commerce, stary system, który został napisany dobre kilkanaście lat temu, działał, natomiast wymagał stanowczo rozbudowy, aktualizacji i zadbania o niego, ale miał on też dostęp do API. No i to, co było ważne, to to, że klient chciał bardzo szybko wdrożyć nowe rzeczy, w związku z czym zbudowaliśmy obok drugi system, który tak naprawdę najpierw zawierał te rzeczy, na których najbardziej zależało klientowi, a które było problematyczne, żeby dodać do tego starego systemu, więc dodaliśmy je w tym nowym systemie, który tam, gdzie było to konieczne, właśnie po API wymieniał dane z tym starym systemem. Jednocześnie później rozbudowywaliśmy ten nowy system do tego stopnia, że finalnie ten stary system, działający już zdecydowanie wcześniej, pozostał w pewnym sensie jako takie źródło danych archiwalnych, które to właśnie są synchronizowane wtedy, kiedy tylko są potrzebne. Dzięki temu też sam proces migracji i wyjścia z tej starszej aplikacji był dla klienta znacznie prostszy. API First to wolność wyboru, a wolność w IT to na pewno dobra rzecz pod kątem osiągania przewagi konkurencyjnej.

Zasada 3: Systemy wspierające ludzi obniżają rotację

Zasada trzecia. Systemy wspierające ludzi to niższa rotacja. I to jest coś, o czym rzadko się mówi, ale twoje systemy IT mają wpływ na rotację pracowników w firmie. Zespół, który codziennie walczy z niewydolnymi narzędziami, traci motywację. Ludzie szukają pracy tam, gdzie mogą działać szybciej, sprawniej, z mniejszą frustracją. Mam tu jeden przykład, niestety negatywny. Firma posiadała mnóstwo starych systemów, one były kilkanaście lat temu, czy już nawet ponad dwadzieścia lat temu. W obecnych czasach działały one już wolno, nieefektywnie. I pewnego dnia zespół ludzi pracujących na tych systemach postanowił się zwolnić. Dosłownie cały zespół, to było kilkanaście osób. I powodów było oczywiście sporo znacznie innych, ale jednym z wymienionych w feedbacku na odchodne większa część z tego zespołu, który się zwolnił, podała właśnie to, że firma w ogóle się nie rozwija, co ci pracownicy rozumieli jako brak inwestycji w nowoczesne technologie i brak wsparcia pracownika nowoczesnymi narzędziami, nowoczesnymi rozwiązaniami, które faktycznie usprawniałyby pracę. No i przez to było to dla nich frustrujące i było jednym z powodów, dla których odeszli. Wniosek, systemy IT nie tylko wspierają biznes. One wspierają przede wszystkim ludzi. A to ludzie budują twój biznes.

Zasada 4: Dane jako serce architektury IT

Zasada czwarta. Dane jako serce architektury. W 2025 roku systemy są wymienne, ale dane bezcenne. Jeśli chcesz korzystać z jaja personalizacji czy na przykład predykcji popytu, czy planowania produkcji, musisz mieć spójne dane. Dlatego potrzebujesz centralnej warstwy danych, takiego miejsca, które scala informacje z wszystkich systemów, takiej hurtowni danych. Dzięki temu możesz szybko generować przeróżne raporty. Unikasz duplikacji, powielania, czy też, jeżeli jest to dobrze zaprojektowane, to zwyczajnie bałaganów danych. A twoja firma będzie gotowa na przyszłe technologie, które będą potrzebowały zasilenia tymi właśnie danymi. Firmy, które tego nie zaplanują, po kilku latach będą w pewnym sensie technologicznymi dinozaurami i warto na to zwrócić uwagę.

Zasada 5: Ewolucyjna, nie rewolucyjna modernizacja

I zasada piąta, ostatnia w tym odcinku. Architektura ewolucyjna, nierewolucyjna. Wielu prezesów myśli, nasze systemy są stare, niewydolne, więc co? Pora na nowy system. I zaczynają gigantyczny, jednorazowy, rewolucyjny projekt. Jaki jest problem? Według badań nawet 70% takich rewolucji kończy się opóźnieniem, przekroczeniem budżetu albo zwyczajnie chaosem w zespole. Kolejne podejście to projekt architektury ewolucyjnej, gdzie zaczynasz od najważniejszych obszarów, wdrażasz systemy moduł po module albo usprawniając według określonej kolejności na przykład dane obszary firmowe i przede wszystkim zachowujesz ciągłość pracy i stabilność, jednocześnie przyzwyczajając też ludzi do procesu zmiany. Przykład, mieliśmy też taką sytuację, gdzie przejmowaliśmy współpracę pod opiekę, to były stare systemy oparte o architekturę akurat mikroserwisową, natomiast bardzo dużo bibliotek znowu do aktualizacji, systemy tak zwane legacy, czyli takie właśnie już z przeszłością i które trzeba było szybko zorganizować. Natomiast był to e-commerce ogromny i miał ogrom dużej ilości integracji, naprawdę sporej. No i teraz pojawiła się sytuacja, że tak, z jednej strony technicznej warto byłoby się tym zająć, warto byłoby to wszystko poaktualizować, poorganizować, ale oczywiście cel biznesowy był zupełnie inny. Trzeba było jak najszybciej poprawić doświadczenia użytkowników na tej stronie, w tym sklepie, gdzie jednym z powodów, dla których te doświadczenia były negatywne, była bardzo kiepska wyszukiwarka. Zatem co zrobiliśmy? Zamiast wgryzać się w ten kod jeszcze głębiej i przebudowywać wyszukiwarkę, która wiedzieliśmy, że będzie bardzo trudno to zrobić, bo technologia używana już w tym systemie była zwyczajnie zbyt stara i trzeba było ją i tak wymienić na nowszą, czy przynajmniej zaktualizować, co niestety nie było takie proste, bo tych aktualizacji nie było tam realizowanych na bieżąco od już kilku dobrych lat, raczej górnych kilku lat. Więc napisaliśmy wyszukiwarkę jako osobny mikroserwis, zbudowaną od podstaw, która była podpięta pod stare okienko do wyszukiwania na froncie tego sklepu, ale jednocześnie miała mocno odświeżoną logikę, nowoczesne biblioteki, nowoczesne narzędzia i przede wszystkim było to rozwiązanie znacznie szybsze do wdrożenia. Dzięki temu rozwiązaniu z jednej strony ze starego systemu wyłączyliśmy po prostu tą starą wyszukiwarkę, usunęliśmy tę część kodu i zastąpiliśmy ją tą nową wyszukiwarką i przede wszystkim zrealizowaliśmy sprawnie cel biznesowy, poprawy rentowności dzięki między innymi właśnie lepszej wyszukiwarce wdrażanej w ramach takiej architektury ewolucyjnej uwzględniając pomysł na całą architekturę i roadmap działań, bo to co było ważne tutaj to to, że powiedziałem o tym aspekcie wyszukiwarki, natomiast z klientem mieliśmy po prostu zaplanowany roadmap działań, gdzie ta wyszukiwarka i inne zmiany UX-owe, czyli właśnie poprawiające doświadczenia były jednymi z najważniejszych rzeczy na start, które trzeba było zwyczajnie jak najszybciej domknąć. \

Podsumowanie i zaproszenie do współpracy

Podsumowując dzisiejszy odcinek, architektura IT to dziś strategiczna decyzja biznesowa, źle zaprojektowana, blokuje rozwój i frustruje ludzi. Dobrze zaprojektowana, daje wolność, skalowalność i wspiera przewagę konkurencyjną. Pięć najważniejszych zasad. Chroń się przed vendor lock-inem, myśl API first, buduj systemy, które wspierają ludzi, pamiętaj, że dane to serce Twojego biznesu i powinieneś lub powinnaś o nie dbać, modernizuj systemy ewolucyjnie, etapami, a raczej nierewolucyjnie. Jeśli zastanawiasz się, czy Twoje systemy wspierają Twój biznes i ludzi, czy może ich blokują, zapraszam serdecznie na konsultację. Razem zaplanujemy architekturę IT, która będzie motorem wzrostu, a nie przeszkodą. Dzięki za wysłuchanie dzisiejszego odcinka, do usłyszenia za tydzień. Cześć.