W dzisiejszym odcinku gościmy Andrzeja Sobczaka – specjalistę z zakresu Enterprise Architecture. Andrzej, doktor habilitowany, profesor w Szkole Głównej Handlowej, łączy wiedzę akademicką z praktycznym doświadczeniem w nowoczesnych technologiach.
Podczas rozmowy z Łukaszem i Szymonem, Andrzej skupia się na kluczowych aspektach takich jak znaczenie modelowania, rola Enterprise Architecture w podejmowaniu strategicznych decyzji dotyczących rozwoju systemów i technologii, oraz przyszłe trendy i ewolucja roli architektury w dynamicznie zmieniającym się świecie technologii.
WAŻNE INFO!! Zmieniamy termin MeetUp z okazji setnego odcinka Patoarchitektów! Niestety nie znaleźliśmy sali na 10 stycznia, więc spotykamy się online 17 stycznia o 15:00! Link znajdziesz poniżej.
Słuchasz Patoarchitektów dzięki Protopii. Sprawdź, jak Patoarchitekci i Protopia mogą Ci pomóc ➡️ protopia.tech
Linki i ciekawe znaleziska:
Łukasz Kałużny: Cześć, słuchacie Patoarchitektów. Prowadzą Łukasz Kałużny…
Szymon Warda: I Szymon Warda. Wszystkie linki do odcinków oczywiście na patoarchitekci.io gdzieś na górze, dole, w linkach, opisie. Wierzymy, że ogarniecie takie tematy.
Łukasz Kałużny: Dobra, słuchajcie, pierwsze ogłoszenie parafialne to takie, że niestety musimy przełożyć meetup z okazji setnego odcinka na formułę online. Odbędzie się to 17 stycznia w godzinach popołudniowych. Informacje znajdziecie w opisie podcastu. A musimy słuchajcie to przełożyć, bo nie mogliśmy znaleźć odpowiedniej sali, żeby połączyć to wydarzenie z nagraniem live, więc zrobimy to tym razem w formule online’owej.
Szymon Warda: I drugie ogłoszenie parafialne, mianowicie Patoszkolenia, dwa dni pod rząd. Zaczynamy 21.02. Ja się powymądrzam odnośnie modelowania danych praktycznie. Chodzi o to, żeby zrozumieć jak ważne jest modelowanie danych. Przy okazji powiemy sobie jak to wygląda w bazach nosqlowych, ale to będzie głównie po to, żebyśmy zrozumieli, jak one działają, jakie mają ograniczenia, jakie mają możliwości, czemu tak działają i potem tą wiedzę przełożyć na bazy relacyjne tak naprawdę. Kolejny dzień, Łukasz wchodzi ze swoim szkoleniem “Kubernetes the hard way”. Będzie konkretnie, będzie mięsiście. Jaki jest cel szkolenia? Zrozumienie, jak działa Kubernetes, żebyście nie widzieli go jako magiczną zabawkę, tylko faktycznie zrozumieli internalse. I tyle.
Łukasz Kałużny: Dobrze, przejdźmy do rozmowy z naszym gościem. Dzisiaj będzie osoba, którą ja kojarzę na temat tego pojęcia, o którym będziemy rozmawiać z 2013/2014 rokiem. Jest z jednej strony doktorem habilitowany, profesorem w Szkole Głównej Handlowej. Z drugiej strony, mimo backgroundu akademickiego, co jest ważne, jest bardzo dużym praktykiem i popularyzatorem nowoczesnych technologii, więc nasz gość mimo akademickiego backgroundu nie jest oderwany od rzeczywistości. I chcielibyśmy Wam przedstawić Andrzeja Sobczaka, z którym dzisiaj porozmawiamy na temat Enterprise Architecture.
Andrzej Sobczak Cześć Łukaszu! Cześć Szymonie! Bardzo miło mi za zaproszenie. Witam wszystkich serdecznie słuchaczy i mam nadzieję, że nie zniechęcę do Enterprise Architecture Was, a być może przekonam, że warto pewne elementy z tej koncepcji wdrażać u Was w firmach.
Szymon Warda: Dobrze. Zacznijmy może od samego początku. Czyli zdefiniujmy sobie w ogóle czym jest Enterprise Architecture, bo każdy to pojęcie mniej więcej kojarzy, ale jaka jest taka poprawna definicja? W jakim kontekście będziemy rozmawiali dzisiaj?
Andrzej Sobczak Wokół Enterprise Architecture, w szczególności w Polsce, narosło, wydaje mi się, wiele mitów i wiele nieporozumień. Pierwsze takie skojarzenie, które kojarzy się ludziom z Enterprise Architecture, to bardzo, bardzo duża ilość formalizmów i dokumentacji. W wielu organizacjach tak się przyjęło, że dobry architekt robi dużo diagramów i najlepiej jak najbardziej szczegółowych tych diagramów. I to jest pierwsze nieporozumienie. Drugie nieporozumienie jest takie, że Enterprise Architecture kojarzona jest tylko z rozwiązaniami informatycznymi klasy enterprise, czyli takimi dużymi systemami informatycznymi, które są wykorzystywane w bankach, ubezpieczeniach, Telco, w dużym retailu. Natomiast ja od razu chcę powiedzieć, że jeden i drugi, perspektywa częściowo jest prawdziwa, ale jest to bardzo, bardzo wąskie spojrzenie, bo po pierwsze Enterprise Architecture, w tej koncepcji bardzo dużą rolę odgrywa ta warstwa biznesowa. Czyli nie można mówić o architekturze korporacyjnej ograniczając się tylko i wyłącznie do zagadnień związanych z technologiami, czy to na poziomie aplikacji, przetwarzania danych, infrastruktury. Tutaj przede wszystkim musielibyśmy zacząć od warstwy biznesowej, od modelu biznesowego firmy, od celów biznesowych, od sposobu poukładania procesów biznesowych. I to jest pierwsze wyzwanie. Dlaczego? Pewnie potem będziemy jeszcze mieli okazję porozmawiać. I druga rzecz, o której chciałbym tutaj od razu uspokoić słuchaczy, uspokoić Was, że tak naprawdę w architekturze korporacyjnej nie chodzi o tworzenie jak największej liczby diagramów, bo to jeszcze mogę sobie wyobrazić, żeby było stosunkowo proste do zrobienia, ale potem też trzeba diagramy wykorzystywać, aktualizować. Tylko tak naprawdę w architekturze korporacyjnej chodzi o podejmowanie decyzji, decyzji dotyczących rozwoju strategicznego systemów, rozwiązań, infrastruktury w kontekście potrzeb, możliwości biznesowych. Ja zawsze mówię, że dobra architektura korporacyjna to jest taka architektura, z którą połączone są pieniądze, na której są podejmowane pewne decyzje mające jakiś taki impakt na dłuższą perspektywę działania organizacji. I to jest jeden z tych ważnych wymiarów rozumienia architektury korporacyjnej. Jak byśmy tak chcieli już po akademicku zdefiniować, ale tak, żeby każdy to zrozumiał, ta architektura korporacyjna to jest pewien sposób poukładania organizacji zarówno w warstwie biznesowej, jak i technologicznej, które pokazuje, jak organizacja działa obecnie i jak ma działać w przyszłości, aby osiągać, adresować cele biznesowe. I taka roadmapa dojścia od stanu AS-IS, do stanu TO-BE. Natomiast mówię, dla mnie najważniejsze w architekturze to są te decyzje, które są podejmowane w oparciu o modele, o standardy, o pewne pryncypia, które trzeba sobie wypracować.
Łukasz Kałużny: Andrzej, jedno takie pytanie, które mi się od razu nasuwa, patrząc się trochę z poziomu akademickiego, ale zawsze to zdefiniuje, czy architektura korporacyjna jest bardziej informatyką czy rzeczą zarządczą? Bo jak słuchasz Twojej wypowiedzi, to od razu się patrzy, że to de facto zarządzanie, a nie taka czysta stricte rzecz informatyczna.
Andrzej Sobczak Odpowiedź jest chyba najlepsza: to zależy. W krajach, które architekturą korporacyjną się interesują, wdrażają przedsiębiorstwa od wielu, wielu lat, takich jak Belgia, Holandia, Wielka Brytania, Ameryka, to tam architektura korporacyjna jest jednak bardzo mocno utożsamiana z tą warstwą zarządczą. Czyli np. jest uczona na uczelniach ekonomicznych, zarządczych. Natomiast w Polsce architektura korporacyjna najczęściej jest utożsamiana z tą warstwą technologiczną i jeżeli już jest gdzieś uczona, to bardziej na politechnikach czy na Wacie. Czyli jest zupełnie inne postrzeganie i rozumienie architektury korporacyjnej. Można by się było zastanawiać, z czego to wynika. Odpowiedź jest taka: jeżeli mamy podejmować pewne decyzje, to centrale firm, które o tym decydują, o przyszłości firm, o kierunkach rozwoju, o wyborach pewnych strategicznych, mieszczą się za granicą i tam jest łatwy mix technologiczno-zarządczy, żeby podejmować tego typu decyzje. W Polsce większość decyzji ma charakter na poziomie projektów, na poziomie technologii, bo u nas w wielu wypadkach jest wykon pewnych rozwiązań i wtedy my siłą rzeczy jesteśmy ograniczeni do tej warstwy informatycznej. To też jeszcze warto popatrzeć, jak w Polsce rozmawiamy o architekturze korporacyjnej, to w 95-98% przypadków ja rozmawiam z działami IT, CEO z dyrektorami IT, z architektami zajmującymi się technologią. Na Zachodzie o architekturze korporacyjnej rozmawia się z osobą odpowiedzialną za cyfrową transformację, osobą odpowiedzialną za operacje, osobą odpowiedzialną za strategię firmy. Więc zupełnie inni interesariusze, zupełnie inny impakt, zupełnie inne pozycjonowanie pojęcia ‘architektura korporacyjna’.
Szymon Warda: Tak podsumowując właśnie to, co powiedziałeś, tak naprawdę i dla mnie najważniejszy element Twojej wypowiedzi to jest to, że architektura enterprise’owa, korporacyjna, to jest posiadanie strategii rozwoju IT tak naprawdę. To jest wiedzenie gdzie się jest teraz i gdzie się chce być za powiedzmy rok, dwa, pięć lat. To jest taka wizja długofalowa tak naprawdę. I to jest ten kluczowy element. To nie są te wszystkie upierdliwe rzeczy, które po prostu musimy zgodzić, żeby być zgodni z czymś tam de facto. To jest clue, jakby to w jednym zdaniu zamknąć. Czy w miarę by się z tym zgodził?
Andrzej Sobczak Dokładnie tak, przy czym architektura korporacyjna już tak mówiąc książkowo, by the book, to niekoniecznie są cele, bo najpierw mamy cele, mamy strategię IT, strategię technologii, albo szerzej strategię organizacji, a architektura pozwala to zoperacjonalizować. Czyli zamienić na pewną roadmapę, sprecyzować pewne działania i spowodować, żeby te wszystkie nasze pomysły, które firma ma, szły mniej więcej w jedną stronę. Czyli tak naprawdę pozwala bardziej efektywnie realizować prace transformacyjne. Bo tak naprawdę w architekturze korporacyjnej chodzi o wprowadzenie zmian, czy to średnich, czy dużych, ale skoordynowanie i efektywna realizacja zmian.
Szymon Warda: Jasne. Dotykamy trochę innego tematu, że mówimy sobie zdefiniowaliśmy sobie wszystko fajnie, ale trochę byśmy chodzili naokoło pewnego tematu negatywnego, że Architecture Enterprise nie kojarzy się zbyt pozytywnie. To jest takie, mówimy, że jak nazywamy coś Enterprise, to z reguły nazywamy jakąś wielką krową albo coś, co jest upierdliwe.
Andrzej Sobczak Prawda. Architektura korporacyjna ma fatalne skojarzenia, nie bójmy się tak nazwać. Z czym jest kojarzona? Kojarzona jest z kupą, kupa tu jest istotna, diagramów w ArchiMat’cie czy UML-u, bo czy w jednym czy w drugim, w notacji można sobie to rysować. Po drugie, kojarzona jest właśnie z takimi panami, którzy przychodzą i mówią: nie, nie, nie, nie możesz iść w tą stronę, nie możesz iść tą drogą, bo to jest niezgodne z jakimiś tam standardami, pryncypiami architektonicznymi. No i nomen omen kojarzona jest z pewnym frameworkiem, zwłaszcza w Polsce, który nosi nazwę Toga, który od wielu lat jest pewnego rodzaju takim punktem odniesienia, jeśli chodzi o wdrażanie architektury korporacyjnej. I to jest takie rozumienie architektury korporacyjnej, które było 15-20 lat temu, takie bardzo konsultanckie. Mam nadzieję, że tak jak wszystko się zmienia, panta rhei, tak również w myśleniu o architekturze korporacyjnej będzie się zmieniać. Być może pod inną nazwą. Być może tutaj część np. firm zaczyna mówić, że już nie chce architektury korporacyjnej, ale chce mieć cyfrowego bliźniaka, Digital Twins. Czyli tak naprawdę pewne spojrzenie na procesy, systemy, które są aktualizowane w czasie rzeczywistym, jak one wyglądają, jak są realizowane i pewien pomysł, jak one mogą być zmieniane w czasie. A jeżeli dojdzie do tego chmura, gdzie od pomysłu do realizacji jest stosunkowo krótki okres czasu, to mamy zupełnie inne możliwości pozycjonowania architektury korporacyjnej. Ale Szymonie, zgadzam się, tak, architekt korporacyjny to jest kojarzony facet z brodą, taki już starszy, z brzuszkiem, albo młody, konsultant, który niekoniecznie dużo umie, ale przychodzi i bardzo rzuca wysokopoziomowe hasła, typu nie wiem: cloud first. I kurde co my w tej organizacji mamy zrobić? Albo: multikanałowość. I teraz co to znaczy w praktyce? Więc nie, myślę, że architekci doszli do wniosku, że bycie w takiej wieży z kości słoniowej zupełnie się nie sprawdza, a jeszcze bycie takim showstoperem pewnych rzeczy. Czyli tak jak wcześniej powiedziałem, idą trzy projekty i albo architekt mądrzy się i narzuca pewne technologie, pewne standardy na poziomie tych projektów, albo mówi: nie, nie, nie wolno tego robić, bo to nie jest zgodne z naszymi tam wytycznymi. To już się zmienia. Mam nadzieję, że architekci doszli do tego, że powinni być takimi zaufanymi doradcami wewnątrz organizacji, takimi trochę konsultantami wewnętrznymi, którzy w przypadku sytuacji trudnych, złożonych są wzywani na pomoc, na styku właśnie tej sytuacji biznesu i IT.
Łukasz Kałużny: Właśnie i teraz powiedziałeś taką ciekawą rzecz na temat bycia właśnie tymi stoperami w projektach, wejściu w technologie. Jak Twoim zdaniem, czy architektura korporacyjna powinna być bliżej tej części biznesowej i mapować tą rzeczywistość biznesową pomagając IT? Czy w tej roli architektury korporacyjnej będzie wchodzenie w to IT i narzucanie tych rzeczy?
Andrzej Sobczak Zdecydowanie ten pierwszy przypadek Łukaszu. To znaczy wydaje mi się, że samo sedno i stąd, skąd się wzięła architektura korporacyjna, jakby to sięgnąć trochę historycznie, to ona adresowała od samego początku dwa duże problemy, które myślę, że z biegiem lat wcale się nie zmniejszyły, a wręcz narosły. Pierwszy problem to był taki, że mamy silosowość po stronie biznesu. A my, jako informatycy, patrzymy bardzo chętnie na całość pewnych rozwiązań, na rozwiązania, które wspierają skrośnie procesy, na rozwiązania, które mają charakter platformowy. Czyli staramy się, bo jako informatycy działamy racjonalnie, staramy się dostarczyć pewne rozwiązania reużywalne, takie rozwiązania, które mają trochę dłuższy okres czasu, są parametryzowalne, itd, itd. I tutaj biznes często tego nie widzi. Biznes często jest zamknięty w swoich silosach, w swoich obszarach, swoich domenach biznesowych. I tu architektura korporacyjna od samego początku miała pomóc. Druga rzecz, z czym architektura korporacyjna bardzo mocno stara się jak gdyby tutaj współdziałać czy minimalizować, to złożoność. Bo oczywiście zbyt duża złożoność na poziomie procesów, na poziomie technologii to długi time to market, to kwestie związane z bardzo wysokimi kosztami utrzymania, to kwestie związane z problemami, potem posiadaniem pewnych zasobów umiejących utrzymać te rozwiązania. Ludzie odchodzą, technologie się bardzo szybko zmieniają, więc dla mnie architektura, po pierwsze, powinna zaadresować odpowiedź, jak biznes chce się zmienić, uchwycić to w jakiś sposób, skodyfikować. Czasami to mogą być racjonalnie przygotowane modele, czasami to mogą być pewne standardy, ale mówię cały czas słowo ‘racjonalnie’, to jest bardzo, bardzo istotne i to przełożyć na pewne działania już na poziomie technologicznym. Pewnie można by się było zastanawiać, na ile architektura i architekci mogą wpływać na konkretne wybory technologiczne, bo dawno temu to było tak, że architekt mówię przychodził, jest w banku, w którym współpracowałem, zamknięta lista standardów i jak się coś nie ma na tym standardzie, to fajne rozwiązanie jest na rynku, ale nie można go wprowadzić, bo to nie wynika ze standardów. No i czekamy. Pół roku to jest bardzo szybko, albo rok, co jest normalnym tempem, żeby wprowadzić to na listę standardów. Tak można było działać powiedzmy 15 lat temu, kiedy ta zmienność otoczenia, zmienność rynkowa, zmienność legislacyjna była dużo mniejsza. Teraz to architekt raczej, tak jak powiedziałem, powinien pokazać konsekwencje pewnych wyborów - krótkoterminowe, to pewnie wszyscy rozumieją, ale średnio i długoterminowe. I dlatego niektórzy mówią, że architekt to jest taki gościu, który widzi, co się dzieje za zakrętem. Ma szerszą perspektywę, być może trochę wyższego lotu ptaka, ale rozumie pewne konsekwencje i stara się przekonać organizacje do pewnego działania, ale też mówi: to jest Wasz wybór, pokazując np., że potem będą np. droższe koszty integracji, koszty droższe utrzymania. Więc absolutnie tak bym patrzył teraz na architekta i jego działania.
Szymon Warda: Czyli urealnia wszystkie zapędy technologiczne i bawienie się nowymi zabawkami i powie: to jest nowe, więc musi być lepsze.
Andrzej Sobczak Dokładnie. To znaczy pewnie znacie to hasło CV Driven Development, to tutaj chyba architekt powinien powiedzieć stop, w rozsądny sposób oczywiście. Natomiast ja też bardzo silnie uważam, że architekt korporacyjny może być nośnikiem innowacji wewnątrz firmy, bo on często chodzi po różnych organizacjach, ma duże doświadczenie, chodzi po rynku, chodzi po konferencjach, przynosi pewne pomysły, a jednocześnie zna uwarunkowania, które są wewnątrz firmy. Wiecie, przyjdzie konsultant i może ma świetny pomysł na technologię, na rozwiązanie, ale która nie pasuje albo do procesów, albo do tego, co firma posiada obecnie. Architekt korporacyjny powinien być wewnątrz firmy, powinien być wiele lat z nią związany, powinien mieć zaufanie i to w dziale technologicznym i dziale biznesowym i to on może powiedzieć: słuchajcie, ale taka fajna innowacja się pojawiła. Sprawdźmy ją, zweryfikujemy. W niektórych organizacjach architekci korporacji nie mają budżetu na to, żeby testować pewne innowacyjne rozwiązania i to już zupełnie ich rola się troszeczkę zmienia z takich showstoperów na takich popychających organizację do przodu.
Szymon Warda: Czyli realnie widzisz rolę tego enterprise architekta obecnie jako osobę de facto mediującą pomiędzy biznesem i kasą biznesu, gdzie organizacja chce pójść, kasę włożyć, a powiedzmy ludźmi w technologii, którzy chcą się bawić nowymi zabawkami. I on mając te dwa światy łączy sobie tych architektów, łączy wszystkie zespoły deweloperskie z tym, powiedzmy, gdzie kasa idzie i może to ładnie sobie ułożyć w jakąś spójną roadmapę, gdzie my w ogóle chcemy pójść i powiedzieć też może: okay, tam kasy nie inwestujemy, ale tu zainwestujemy, chcecie mieć zabawki, pogadamy, zobaczymy, gdzie to generalnie wchodzimy.
Andrzej Sobczak Dokładnie. Tu, ja uważam, że jeżeli o kasie, o przejrzystości na koszt utrzymania rozwiązań, na koszt zbudowania rozwiązań nie mówimy i firmy tego nie chcą pokazywać, to nie są gotowe na wdrożenie architektury korporacyjnej. Ja zawsze mówię, że żeby architektura korporacyjna zadziałała, to nie może być architekt, który ma nawet dwóch ludzi pod sobą, siedzi z boku i rysuje coś w Enterprise Architect’cie albo nawet [niesłyszalne 00:16:46], żeby nie było, albo w Miro rysunki, których potem nikt nie czyta. Tak naprawdę architekt korporacyjny powinien wiedzieć o projektach, pomagać w ich priorytetyzacji, być może wycenie pewnych rzeczy. Tak jak powiedziałeś mediator, ja czasami używam słowa facylitator, pomiędzy różnymi stronami, to jest jego główne zadanie też w wielu wypadkach i trochę mieć jednak ten nadzór, ale taki lekki, governance’owy. Wszyscy mówią o AADR-ach. Też mamy tutaj na poziomie enterprise takie zapisy decyzji architektonicznych, żeby zrozumieć rok, półtora później, dlaczego takie, a nie inne wybrano technologie, takie inne podejście czy produkt, czy wprowadzenie pewnego rozwiązania do organizacji. Natomiast druga perspektywa, ja uważam, to połączenie architektury korporacyjnej z portfelem projektów. Ja wiem, że to jest troszkę wyższe niż normalnie developerzy pracują, ale jak dyskutujemy w wielu firmach o time to market, że developerzy są zarobieni, nie mają usiąść czasu, bo jest bardzo dużo prac, to tak naprawdę praszczurem wszystkich problemów jest zła priorytetyzacja. To znaczy biznes chce za dużo, chce naraz i ciężko jest to w dobry sposób poukładać. I tutaj myślę, że architekt mógłby pomóc, doradzić pewne działania - kto, w której kolejności, jakie projekty, jakie inicjatywy realizować, czy jest gdzieś jakaś synergia pomiędzy nimi, a może powinny pewne projekty być wzięte na wstrzymanie, albo z części projektów np. zrezygnować, bo one gdzieś tam się nie wspinają w roadmapę realizacyjną.
Szymon Warda: Poruszyłeś fajny temat, bo cały czas mówimy o technologiach, mówimy o zabawkach różnych, a ruszyłeś temat AADR-ów tak naprawdę. Więc na ile architekt korporacyjny, enterprise’owy powinien dotykać samego procesu wytwórczego? Czyli nie tylko technologii, ale też jak do niej podchodzimy, jak zbieramy wymagania, wszystkiego dookoła de facto, bo to jest też ogromny obszar.
Andrzej Sobczak Ja uważam, że na pewno architekt korporacyjny powinien być wpięty w proces wytwórczy, w SDLC, czyli tak naprawdę powinien być na jego początku, kiedy pojawiają się pewne inicjatywy, pozwolić je lepiej, tak jak powiedziałem, spriorytetyzować, wycenić, zobaczyć, na ile one pasują do tego krajobrazu technologicznego, który firma gdzieś ma. Powinien występować w trakcie realizacji projektu, żeby projekt za bardzo nie odjechał, w szczególności jak jest realizowany dostawcami zewnętrznymi, bo często dostawcy idą na skróty, bo się dogadali z biznesem, bo to czasami time to market jest ważniejszy niż quality długookresowa. I powinien być na końcu, żeby złapać tą wiedzę, faktycznie co zostało dostarczone, żeby zasilić z powrotem repozytorium. Oczywiście tutaj jest cały zestaw tricków jak to zrobić sprytnie. Więc to są te miejsca, gdzie architekt korporacyjny powinien się pojawić. Czy architekt korporacyjny powinien ustalać SDLC? To pewnie jest odpowiedź: to zależy, bo w części organizacji są tacy inżynierowie procesu i pewnie architekt wtedy byłby jednym z interesariuszy, a jeżeli nie ma takich osób, które odkładają proces, to być może architekt korporacyjny powinien wyjść z taką inicjatywą, w szczególności, żeby złapać trochę szerzej samo dostarczanie rozwiązania. Czyli zacząć od tego pomysłu biznesowego, który jest na początku, bo to często SDLC nie obejmuje, bo często SDLC zaczyna się: to zbierzmy wymagania. No dobra, ale przed wymaganiami jest jakaś faza incepcji, faza pewnej kreatywności biznesowej, którą trzeba w jakiś sposób poukładać. I później na koniec, kiedy już praktycznie przekazujemy rozwiązanie do wdrożenia, to trzeba potem to też umieć utrzymać, odebrać i zapewnić, żeby na końcu to też działało zgodnie z jakimiś tam standardami architektonicznymi.
Łukasz Kałużny: Dobra Andrzeju, jedna taka rzecz, która się przewija i złapała mnie taka myśl, powiedziałeś o wdrażaniu architektury korporacyjnej. Czy nadal w ogóle mamy do czynienia z tym na rynku? Bo moje postrzeganie jest takie, że jest troszeczkę jak z chmurą w tym momencie, kto miał to zrobić, to zrobił.
Andrzej Sobczak To może się nie zgodzę, bo to jest tak, architektura korporacyjna na pewno, jeżeli chodzi o branże, jest najbardziej dojrzała, w Polsce mówimy, w bankowości, ubezpieczeniach. Dlaczego? Bo rekomendacja D wymusza, którą wszyscy pewnie tutaj słuchacze znają, kojarzą, pewne elementy architektury korporacyjnej. W rekomendacji D nie pada pojęcie Enterprise Architecture, ale jak się tak to poczyta całościowo, to bardzo jest to bliskie temu pojęciu. A poza tym banki i ubezpieczalnie mają cały czas kasę. Nie ukrywajmy, wdrożenie architektury korporacyjnej jest pewnym przedsięwzięciem, które trzeba sfinansować na początku przynajmniej. Potem architektura korporacyjna w wielu firmach w Polsce była kojarzona z Telcomami, czyli duże Telco sobie układały świat technologii i biznesu przy pomocy tego podejścia. Natomiast teraz to, co zauważam, te firmy, które osiągnęły pewien poziom dojrzałości architektonicznej, się zatrzymały albo nawet z niego schodzą. Nie ukrywam też są firmy, które wycofują się z takiego sensu stricte podejścia architektury korporacyjnej na bazie jakichś zamkniętych, sztywnych frameworków. Natomiast firmy, które wcześniej nie miały tego podejścia, typu sektor cały utilities, energetyka zwłaszcza wchodzą w te zagadnienia. Nie mówię tutaj o public’u, któremu cały czas myślenie architektoniczne jest takie bliskie, bo to pozwala zarządzać wieloma dostawcami, lepiej zarządzać outsourcingiem, itd., itd. Bardzo mocno się obudził retail, jeżeli chodzi o wdrażanie architektury korporacyjnej. Gdzie nie ma architektury korporacyjnej, w Polsce przynajmniej? To przemysł, bo jest stosunkowo mała liczba systemów w przemyśle, jeszcze jest też mała taka złożoność technologiczna. I myślę, że tam zarządzanie architekturą korporacyjną się odbywa w taki bardziej uproszczony sposób.
Szymon Warda: Mówimy sobie kto ma, kto nie ma tak naprawdę. A załóżmy, że np. ktoś chciałby. Słucha, słucha, stwierdza, że: ok, to mi brzmi fajnie. To jest obszar, w którym chciałbym się odnaleźć. Jaka jest droga do stania się enterprise architektem? Bo software, powiedzmy architektem zwykłym w miarę wiemy. Ale jak zostać enterprise architektem?
Andrzej Sobczak Architekt korporacyjny to jest taka osoba, która na pewno łączy ze sobą świat biznesu i świat technologii. Oczywiście musi rozumieć nowe rozwiązania, które się dzieją na rynku, czyli cloud czy mikroserwisy, czyli gdzieś tam pewnie IoT, machine learning, AI. Musi też znać i wiedzieć o dużych systemach enterprise’owych, RP-y, CRM-y, Big Daty, systemy bilingowe, czy centrale bankowe, polisowe. Musi rozumieć proces wytwórczy, musi rozumieć specyfikę zarządzania projektami, wyceny pewnych działań, ale przede wszystkim musi też, moim zdaniem, lubić ludzi i rozmawiać z ludźmi, zwłaszcza po stronie biznesowej. Znałem osoby, które były świetnymi architektami software’owymi, architektami infrastrukturalnymi, bo architektów, jak wiecie, jest całe mnóstwo i próbowali stać się architektami korporacyjnymi. Ale oni mi wręcz mówili: Andrzej, wiesz, ale my tak do tych ludzi to niekoniecznie, a biznesu to już w ogóle. To nie jest dobra rekomendacja. Oczywiście jak ktoś się przełamie i wyjdzie poza swoją strefę komfortu, to jest doskonała droga. Natomiast na pewno architekt korporacyjny, tak jak powiedziałem, musi czuć, rozumieć biznes. Bo jak nie, to co go czeka? To albo będzie architektem enterprise’owym dużych systemów, bo to, na chwilę nawiążę do początku, że w Polsce ludzie Enterprise Architecture utożsamiają w 90% z Enterprise System Architecture, czyli architekturą systemową dużych rozwiązań albo IT Architecture, czyli taką architekturą technologiczną obejmującą aplikacje, dane, infrastrukturę bez tego komponentu biznesowego. A jeżeli my mamy iść do biznesu i porozmawiać z biznesem, to my musimy czasami trafić, nie wiem, do dyrektora działu marketingu, dyrektora operacji, wiceprezesa, a czasami nawet prezesa i pokazać, i przekonać do pewnych rzeczy. I tutaj kwestia komunikacji jest niezmiernie istotna. Taka anegdotka, najlepszym architektem korporacyjnym jakiegokolwiek spotkałem w życiu, to była osoba, która oczywiście gdzieś tam miała wykształcenie technologiczne, ale z pasji była aktorem i grała w różnego rodzaju takich półprofesjonalnych teatrach. I on po prostu wchodząc za każdym razem do biznesu robił show. I biznes był zakochany w tym, co on mówił. A kwestie charakterologiczne, jeszcze taka komunikatywność powodowała, że o wiele łatwiej było przekonać biznes do pewnych decyzji. Bo to, co chyba my wszyscy cierpimy, to to, że biznes patrzy krótkoterminowo, a architekt musi spowodować, żeby biznes spojrzał troszkę dłużej, w dłuższej perspektywie, żeby nie występowało coś co się ładnie nazywa krótkowzroczność managerska.
Szymon Warda: Mówisz - dużo rozmawiać z biznesem w takim razie. A jak rozmawiać z ludźmi o technologii? Bo to też czasami są ciężkie rozmowy, szczególnie jak mówimy: żegnaj, tego nie możecie mieć, albo: tu się tym zajmijcie. To taki długi ogon utrzymania, albo generalnie po prostu zabieranie zabawek, albo ubijanie hype trainu. To też są ciężkie tematy.
Andrzej Sobczak Dokładnie. Ja teraz nawet mam wrażenie, że biznes widząc wzrost roli technologii cyfrowych u siebie w firmie, coraz chętniej słucha architektów, czy osoby, które przychodzą i mają taką szerszą perspektywę, bo pokazują nowe możliwości, nowe rozwiązania. Absolutnie tak. Natomiast to, co żeś powiedział, to rzeczywiście wielokrotnie ja, dla mnie głównym takim showstopperem byli ludzie z IT. Pracujemy 5, 10, 15 lat tak samo, dlaczego mamy coś zmieniać? To jest pierwsza rzecz. Albo jeżeli mamy coś zmieniać, to weźmy sobie najnowsze zabawki technologiczne z rynku i je wdrożmy. A tu przychodzi taki gościu i mówi: wiesz, ale to nie tak, to nie tędy. Tu jest sytuacja trudna, bo zwróćcie uwagę ja cały czas mówię, że architekt często jest takim doradcą, zaufanym konsultantem, komunikuje, łączy światy, ale ktoś mi ostatnio powiedział: Andrzej, a jaką ma architekt korporacyjny odpowiedzialność? Za co on tak naprawdę bierze kasę? I tutaj się zaczyna robić problem, bo architekt korporacyjny nie zakasa rękawów i nie wejdzie w buty architekta rozwiązania i nie zaprojektuje konkretnego rozwiązania w konkretnym przypadku, bo by utknął w projekcie. Bo najczęściej architektury rozwiązań powstają w projektach. Nie zakoduje czegoś, chociaż dobrze by było właśnie, żeby architekt korporacyjny miał wiarygodność dla ludzi po stronie technologii. Czyli tutaj na chwilę jeszcze wracając do tego, co Szymonie Ty mówiłeś, chyba dobrą taką ścieżką architekta korporacyjnego jest to, że osoba ma takie ciągoty biznesowe, ale była wcześniej developerem, przynajmniej przez jakiś etap czasu, ja miałem coś takiego, była testerem, ja też przez jakiś czas testowałem, gdzieś tam dotknęła kierowania projektami, programami dużymi, transformacyjnymi, a potem wybrała ścieżkę nie dyrektora, CIO, bo to wiadomo, że Chief Information Officer często jest tłumaczone jako career is over, tylko bardziej wybrała tą stronę właśnie taką układanie organizacji. Czyli wiarygodność jak się przychodzi do ludzi od technologii, a z drugiej strony chyba niezmuszanie. W wielu firmach jest tak, gdzie my dyskutujemy jak wdrożyć architekturę korporacyjną, że my mówimy, że to tak naprawdę ostateczna decyzja o wyborze technologii, o podejściu pewnych problemów, nie wiem, integracyjnych, kwestii połączenia czy włączenia pewnych kwestii związanych z bezpieczeństwem, bo tutaj jeszcze w ogóle tego tematu nie dotknęliśmy, jest po stronie projektu, po stronie projektanta, po stronie senior engineera, a architekt korporacyjny tak naprawdę pokazuje konsekwencje, dyskutuje i na miękko zachęca, żeby rozważyć inne rozwiązanie. Ale mówię, jak projekt wybierze inne podejście, to potem musi już niestety konsekwentnie ten projekt to dowozić. I tutaj architekt mówi: sorry, my pokazywaliśmy coś innego, to jest ryzyko projektowe, wy musicie sobie z tym radzić. To, co może też pomóc w wielu firmach, to przejście z myślenia projektowego na produktowe. Bo jeżeli mamy dobrego Product Ownera, to architekt korporacyjny może być taką osobą, która może mu podpowiedzieć szerzej i dłuższe konsekwencje pewnych rzeczy. Bo dobry Product Owner to nie jest Proxy Product Owner ani Product Owner po stronie IT, ani Tech Product Owner, jak to takie byty spotykam. Tylko to jest Product Owner po stronie biznesowej. On jest wszystkim, musi konsekwencje rozumieć, widzieć pewne zależności. I tutaj architekt korporacyjny go może wspierać, doradzać. Jeżeli jest zaufanie, to pojawia się tu efekt synergii.
Łukasz Kałużny: Dobra, czyli jedną z rzeczy, którą od ciebie mogę wyciągnąć z tej rozmowy, architekt korporacyjny to nie jest rola, do której można powiedzieć, że od początku kariery dążymy, tylko jedna z wypadkowych - co dalej, kiedy zostałem solution architektem?
Andrzej Sobczak Tak, potwierdzam. Natomiast od razu już tak skontruję, może się narażę wielu znajomym, ale dla mnie architekt korporacyjny powinien bardziej mieć background taki właśnie solution architekta, IT architekta, nawet senior developera, niż kierownika projektu. Bo kierownik projektu ma cały czas, mam wrażenie, mindset dowożenia, a architekt ma mindset budowania i rozwoju, zupełnie inne perspektywy.
Szymon Warda: To jest dobre ujęcie w ogóle całego problemu, to jest ciągłe budowanie, to nie jest zamknięty temat. To niestety się skończy.
Andrzej Sobczak A czy organizacja przestanie się zmieniać?
Łukasz Kałużny: Nie.
Andrzej Sobczak Architekt cały czas jest, mówię, to jest change manager w wielu wypadkach, tak często go też postrzegam.
Łukasz Kałużny: Drugą perspektywę, którą ciekawą trochę nawiązałeś, bo architektura korporacyjna nie jest osadzona sama w sobie, gdzieś tam w swoim świecie, tylko mamy cały ten trend, aktualnie skupienie się właśnie na developer experience, wszystkich, nazwijmy to, metodykach zwinnych, których Agile is dead któryś raz z kolei, jak popatrzymy sobie na to, co piszą różne raporty i co ludzie pokazują na konferencjach. I powiedziałeś o ciekawym połączeniu, w którym to idzie, czyli że np. architekt korporacyjny w dzisiejszych czasach może wspierać te nowe role, które zaczęły powstawać, takie jak Product Ownera. Czyli jak to się teraz ta architektura korporacyjna wpasowuje w te trendy i kierunki, które mamy na rynku wokół? Jak wspomagamy firmę jako IT?
Andrzej Sobczak Uśmiecham się pod nosem, bo bardzo często nawiązując do Łukasza słyszę tą wypowiedź: ale my nie będziemy mieli architektury korporacyjnej, bo my to działamy Agile’owo, scrumowo. Więc nie, u nas architektura korporacyjna to nie ma mowy. Wiesz Andrzej, nie. To jedna rzecz, dla mnie to, że organizacja działa scrumowo wcale nie oznacza, że nie może mieć architektury. Wręcz moim zdaniem musi mieć, bo jeżeli nie ma, to chyba w organizacji dzieje najgorsza rzecz, która może być, czyli architektura wyłania się z projektów realizowanych scrumowo. I w tym momencie, co prawda te projekty fajnie działają, ale skoordynowanie pewnych rzeczy, zbudowanie jakiejś synergii, efektywność kosztowa w dłuższej perspektywie czasu jest dramatyczna. Bo jak doskonale wiecie, działając głównie Agile’owo myślimy o funkcjonalnościach, a nie wymaganiach niefunkcjonalnych. A przecież architektura dotyka głównie wymagań niefunkcjonalnych. Więc ja mówię sorry, to jest nieporozumienie. Architektura, zwłaszcza korporacyjna i projekty zwinne to są dwa różne poziomy. Czyli najpierw my mamy poukładanie świata wysokopoziomowo, a potem, jak te projekty zrealizujesz, które wynikają z architektury, na ile tam pewnych funkcjonalności dołożysz, wprowadzisz pewnych zmian, to to już tylko wasza wyobraźnia tutaj ogranicza was. Natomiast cały czas tutaj architekt jednak czuwa i wie, w którą stronę te projekty zwinne idą, żeby one nie poszły w maliny. Druga rzecz, tak jak to powiedziałeś, developer experience, DevOpsy czy mikroserwisy, wydaje mi się, że to jest bardzo fajne spięcie tego z governancem architektonicznym, ale robionym w sposób mądry. Dawno, dawno temu wszystkie firmy wdrażały governance architektoniczny na jedno kopytko. Czyli były jedne standardy, jedne pryncypia jednej procedury kontroli czy ewaluacji architektury. A teraz przecież wiemy, że mamy różne systemy, różne projekty, różny stopień zmienności i ja mówię: podzielcie sobie wasz świat IT na kilka prędkości, na kilka perspektyw i dobierzcie mechanizmy governance’owe w zróżnicowany sposób. Bo wiadomo, jeżeli eksperymentujemy z nowymi technologiami, to tam governance architektoniczny to będzie tylko zarządzanie wyjątkami, odstępstwami. Jeżeli mamy centralny system, wokół którego działa firma i on nie może stanąć, to tam nie ma za bardzo miejsca na eksperymenty, bo jest duże ryzyko, że po prostu procesy operacyjne firmy przestaną działać. To jest coś, za co szybko cały dział IT może mieć nowego szefa. Więc tutaj wydaje mi się, że ten governance jest istotny. Czy mamy powiązanie z developer experience architekta korporacyjnego? Dotknąłbym jednego punktu. Jednym z elementów czy wymiarów developer experience jest dług technologiczny, czy dług architektoniczny szerzej. I tutaj architekt korporacyjny moim zdaniem to jest ta rola, która bardzo silnie działa w tym obszarze. Czyli próbuje oszacować dług technologiczny, próbuje go zakomunikować biznesowi, bo często developerzy nie są przekonywujący dla biznesu, bo dług często technologiczny jest to odpowiedzialność działu IT, ale trzeba mieć pieniądze, żeby go zminimalizować albo walczyć, żeby on nie narastał. I tutaj architekt korporacyjny może się bardzo przydać. I tutaj widzę pewien punkt styku. I takie, wiecie, kwestie w ogóle pewnych projektów transformacyjnych, czyli On-prem przechodzi do clouda, Monolit przechodzi do mikroserwisów i jeżeli to jest sensowne, to tutaj też architekt może pomóc. Więc tutaj w tych wymiarach jak najbardziej widzę działanie architekta. I jeszcze jedna rzecz, radar technologiczny. Coś co ja bardzo lubię i co w wielu wypadkach promuję. Wydaje mi się, że to architekt może tutaj inspirować do powstania czegoś takiego i pokazywać co on może zawierać ściągając nowinki z rynku i weryfikując to jak to sprawdza się wewnątrz firmy.
Szymon Warda: Ja tylko dodam, że przed nagrywaniem nie zgrywaliśmy się odnośnie wspomnienia tego tematu, bo też mocno promujemy właśnie radar, więc jest to totalnie przypadkowe.
Łukasz Kałużny: Tak i ADR-y też. Jednym z kilka narzędzi, które można zachęcić ludzi do zarządzania architekturą jako w przyjemny sposób. Dobra, powiedzieliśmy sobie Technology Radar, ADR-y. I teraz jak Twoim zdaniem trzeba się patrząc na to skupić, czy ciężkie framework, czy narzędzia, czym powinna być teraz architektura korporacyjna? Jak na to patrzymy?
Andrzej Sobczak Ja przede wszystkim, jeżeli chodzi o frameworki i takie wdrażanie architektury, to rozróżniam dwie rzeczy. Takie podejścia sformalizowane, dobrze udokumentowane i w niektórych organizacjach one jeszcze to cenią, zwłaszcza public, zwłaszcza bardzo duże międzynarodowe banki, gdzie używają, nie wiem, frameworku Gartnerowskiego, Togafa. I to jest… Czy [niesłyszalne 00:35:04] frameworków dostarczanych przez firmy konsultingowe i to jest jak gdyby jedna rzecz. Natomiast inne organizacje, bardziej zwinne, które chcą działać bardziej elastycznie, uważam, że powinny promować wewnątrz siebie pewne myślenie architektoniczne. Część organizacji wdraża gildie architektoniczne. Część organizacji mówi, że jest takie podejście - każdy jest architektem, W pewien sposób oczywiście, taka demokratyzacja, myślenie o architekturze, tak aby każdy dobudowywał przez swoje działania kawałek, który składa się na całościowy rozwój firmy. Ja mówię, że dobra architektura korporacyjna powoduje wzrost wartości czy to IT, czy wartości szerzej organizacji. I to jest to takie myślenie zwinne, lekkie, mało sformalizowane, gdzie oczywiście robimy pewne modele, ale tych modeli nie ma za dużo. One mają charakter albo takich właśnie wysokopoziomowych obrazków do komunikacji z biznesem. Bardzo dobrze sprawdza się wdrożenie architektury w oparciu o podział na domeny biznesowe czy technologiczne. Czyli bardziej mamy ujęcie takie domenowe. Dobrze się też sprawdza, jeżeli firma świadomie tym zarządza, wprowadzenie pewnych standardów technologicznych. Z drugiej strony - narzędzia. Najczęściej w Polsce do architektury korporacyjnej używamy Sparx Enterprise Architecta. Robiliśmy takie badania, to jest 80-90% organizacji. Dobry, bo chyba nie za specjalnie drogi, a ma całkiem spore możliwości i pozwala łączyć świat architektury korporacyjnej z architekturami rozwiązań. W firmach, które bardziej stać na to, wdrażają narzędzia bardziej rozbudowane typu Abaqus, Alphabet, [niesłyszalne 00:36:41] Design czy Mega, ale to najczęściej firmy zagraniczne, które działają tutaj w Polsce. I oczywiście część organizacji eksperymentuje z rozwiązaniami opensource’owymi typu Archi Tools. Przy czym wtedy już bym proponował to zintegrować z GitHubem, żeby było wersjonowanie modeli, które gdzieś tam się pojawia, ale to już są pewne szczegóły, szczegóły techniczne. Więc narzędzia są, myślenie warto rozwijać w organizacji, budować community wokół tego, a wręcz w niektórych organizacjach, my mówimy, żeby mówić o architekturze nie używając w ogóle słowa architekt, a np. mówić senior principal engineer. I wtedy nagle ludzie z IT bardziej lubią to stanowisko i te myślenie, które on przynosi.
Szymon Warda: Brzmi Google’owo, że tak powiem, bo tak jest nazywane z [niesłyszalne 00:37:26].
Łukasz Kałużny: Wracamy do pierwotnych korzeni. Słuchaj, to jedno jeszcze takie pytanie a propos wchodząc w detale pracy, powiedziałeś o modelach, bo to się wybrzmiewa, są diagramy i modele, wybrzmiewa od samego początku. Wolę chyba w tym miejscu określenie modele, mimo że wyglądają jak diagramy. Jak wygląda to modelowanie, którego używamy w architekturze korporacyjnej? Bo już wspomniałeś o podziale domenowym, technologicznym, które się pojawiają, odwzorowaniu tych silosów. Ale de facto czym jest to modelowanie, które kończy na tych diagramach w architekturze korporacyjnej?
Andrzej Sobczak Jasne, to tutaj kilka rzeczy. Pierwsza rzecz, architekt korporacyjny tworzy modele korporacyjne, tworzy modele na poziomie architektury biznesowej i architektury IT. To jest pierwsza perspektywa. Druga, architekt korporacyjny tworzy modele dla stanu AS-IS, TO-BE i ewentualnie tzw. transition, czyli stanów pośrednich. To jest druga perspektywa. Od strony narzędziowej, takiej notacyjnej, to bardzo często językiem, który my używamy, to jest ArchiMate. Nie tak popularny w Polsce, ale to jest język dla architektów korporacyjnych, tak został pierwotnie wymyślony. Część osób używa UML-a z odpowiednimi stereotypami, bądź tworzy własne profile architektoniczne. Tutaj często pada pytanie: a model C4? Model C4 to nie jest architektura korporacyjna, to jest jednak poziom niżej. Bardzo często robimy śladowanie, trace’owanie tego najwyższego poziomu modelu C4 na architekturę obszarowo. Czyli widzimy taką zależność, że widzimy big picture na jednym obrazku do komunikacji głównie z biznesem czy na poziomie CIO, potem mamy architektury obszarowe do komunikacji z poszczególnymi liderami, tech leadami, albo business leadami, w zależności od świadomości po stronie biznesowej. I potem są architektury rozwiązań. I tutaj możemy zacząć już myśleć o modelu C4. Oczywiście tutaj cała jest kwestia w jaki sposób to modelować, żeby pewne rzeczy sobie automatyzować, bo kiedyś się wszystko rysowało ręcznie. Teraz np. bardzo często my tworzymy modele w sposób zautomatyzowany, np. zaciągając pewne informacje chociażby z CMDB. Ale także na poziomie modeli architektonicznych łączymy dane ze świata projektów, ze świata finansów, IT, ze świata procesowego. Trzeci taki wątek, który tutaj warto poruszyć, to to, że jednak architektura korporacyjna może być wspierana sztuczną inteligencją. I tutaj jednak taka sztuczna, generatywna inteligencja wchodzi do świata architektów korporacyjnych. Czyli ostatnio robiliśmy eksperyment w jaki sposób połączyć enterprise architekta z właśnie generatywnym AI-em, żeby oszacował dług technologiczny portfela aplikacji i przygotował rekomendacje dotyczące podejść do transformacji tych aplikacji. Czyli łączyliśmy się z bazą Enterprise Architecta, ściągaliśmy stamtąd dane, wrzucaliśmy do narzędzia, który pozwalał użyć scustomize’owanego LLM-a i sobie coś tam wypluwał w formie takiego opisu tekstowego. Odpowiedzi były nienajgorsze, chociaż oczywiście jeszcze ta ręka człowieka, finalny touch i przygotowanie prezentacji była potrzebna. Ale to też pokazuje, że architekt korporacyjny nie może się bać nowości, a wręcz musi zachęcać, żeby wchodzić w tego typu nowe rzeczy i nowe modele.
Szymon Warda: Bo może stać się dziadkiem leśnym tak naprawdę.
Andrzej Sobczak Tak, bo będzie dziadkiem leśnym. I tu jest duża obawa, że po prostu w którymś momencie architektowi korporacyjnemu, który nie jest blisko technologii, to tak trochę zaczyna odstawać. Więc ja uważam, że to jest rola, która cały czas musi się uczyć i podążać za nowymi trendami i mieć też trochę przestrzeń, żeby eksperymentować i przynosić pewne fajne pomysły do organizacji i do projektów.
Szymon Warda: Dobrze, żeby tak powoli zbierać ten odcinek, bo mówimy o tym, gdzie jesteśmy, mówiliśmy dużo o tym, gdzie byliśmy, mówiliśmy też o tym, gdzie nie chcielibyśmy, jak widzimy zmianę. A tak naprawdę gdzie będziemy w przyszłości, jakie są przewidywania i w którym kierunku w ogóle ta dziedzina, rola właśnie organizacji idzie? Bo wybrzmiewa z naszej rozmowy, że ona jest ważna, bo [niesłyszalne 00:41:25] i wybrzmiewa z tego, że ma też dużo negatywnego bagażu, który jest zebrany. Gdzie to się będzie działo w przyszłości, czy może w jakim kierunku, jakie trendy, co nas czeka tak naprawdę?
Andrzej Sobczak Sama idea architektury korporacyjnej, jak tutaj wybrzmiewało, nie jest nowa. Jakbym sięgnął historii, ma 35 lat. Natomiast tak jak się świat zmienia, tak myślenie o architekturze korporacyjnej, podejście do niej się absolutnie zmienia i musi się zmieniać, bo jak nie, to ten obszar umrze. Na pewno warto by było popatrzeć na zmiany technologiczne i zadać sobie pytanie, czy firmy, które są coraz bardziej złożone, które są coraz bardziej uzależnione od technologii, gdzie biznes zaczął rozumieć, że to jest źródło ich mocy i przewagi konkurencyjnej, mogą działać bez architektury i myślenia architektonicznego? I moim zdaniem odpowiedź brzmi: nie, bo jest tak dużo zależności biznesowo-technologicznych pomiędzy poszczególnymi technologiami, time to market jest tak duży, że bez takiego spojrzenia całościowego to w wielu wypadkach nastąpi przepalanie pieniędzy. Mamy teraz okres taki trochę trudniejszy gospodarczo i wiele firm zaczyna mówić: sprawdzam, czy te inwestycje, które w technologie były poczynione kilka lat temu w czasie pandemii, rzeczywiście przynoszą pewien uzysk. I kiedy wiecie, w IT jest za dużo pieniędzy, a był taki moment, to to myślenie architektoniczne, taka racjonalizacja działania nie zawsze się sprawdzała. Teraz to jest ten moment, kiedy firmy będą chciały spojrzeć na portfel projektów, portfel produktów, które mają i zracjonalizować pewne rzeczy. Dwa, mamy na horyzoncie cloud wszechobecny, mamy na horyzoncie AI-a, mamy na horyzoncie IoT, mamy na horyzoncie komputery kwantowe. Wiem, że to brzmi abstrakcyjnie, ale część firm już zaczyna myśleć o wykorzystaniu przynajmniej pewnych tych elementów, bo Cloud + mikroserwisy + AI + machine learning + IoT to nie jest w wielu firmach dużych międzynarodowych coś zupełnie odjechanego. To się dzieje.
Łukasz Kałużny: Andrzej, ja raczej powiedziałbym może z naszej perspektywy to jest praca, którą na co dzień się zajmujemy w naszym kraju, więc jest to buzzword, ale on się dzieje.
Andrzej Sobczak Tak. I w związku z tym, żeby nad tym zapanować, rozsądnie wydawać pieniądze firmowe, żeby lepiej wprowadzać te zmiany, architekt albo rola, która będzie pełnić rolę architekta, niekoniecznie musi się tak nazywać i niekoniecznie on musi wykonywać coś, co nazywamy Enterprise Architecture, bo być może konsultanci z Gartnera albo z Forrestera wymyślą inną sexy nazwę, to to będzie się musiało dziać. I ja jestem absolutnie przekonany. Tutaj też rozmawialiśmy, że Agile is dead absolutnie. Myślę, że tak jak Agile się przepotworzy, tak architektura korporacyjna się przepotworzy. W którą stronę to pójdzie? Myślę, że dużym sprzymierzeńcem prac architektów korporacyjnych będzie automatyzacja, IA, które te najbardziej mozolne działania wykonywane ręcznie, czyli rysowanie diagramów, przerysowywanie diagramów, aktualizacja diagramów zostanie mocno, że tak powiem, wsparta rozwiązaniami informatycznymi. Architekt korporacyjny będzie robił to, co powinien. Czyli powinien będzie podejmować lepsze decyzje wewnątrz organizacji, doradzać, wprowadzać innowacje i rozmawiać z biznesem. I myślę, że to jest nasza przyszłość. Oczywiście, już tak na koniec, tego typu rozmowy nie zawsze się będą odbywać w Polsce. Te rozmowy będą się odbywać na poziomie umocowania budżetów na technologie. I tam w wielu organizacjach będzie architektura korporacyjna, myślenie architektoniczne, a w Polsce po prostu będzie wykon tych decyzji, które zapadły na poziomie międzynarodowym.
Szymon Warda: Też takie moje wrażenie, bo wydaje mi się, że jednym z tych strumieni, które w mojej perspektywie będą wdrażały architekturę korporacyjną, to będą regulacje. Bo mam wrażenie, że po Unii Europejskiej jest coraz więcej regulacji odnośnie przetwarzania danych, bezpieczeństwa, AI-a, itd. I to będzie takie bycie zgodnym z regulacjami prawnymi, będzie wymuszało wejście w architekturę korporacyjną. Bo np. czemu banki mają? Bo muszą mieć, bo mają tyle procesów, że po prostu muszą to ogarnąć. I coraz więcej będziemy nabierali. Czy to też jest coś, co widzisz?
Andrzej Sobczak Szymonie, z jednej strony rozumiem i z jednej strony widzę taki trend, że architektura pozwala ogarnąć regulacje, ale z drugiej strony jest bardzo duże ryzyko, że architektura korporacyjna i pan architekt korporacyjny stanie się panem od regulacji i nie będzie w tym wartości. Bo w wielu firmach niestety regulacje kojarzone są nie z minimalizację ryzyka, czy tylko ze spełnieniem smutnego obowiązku, który kosztuje, a nie przynosi wartości biznesowej. Więc tu widzę zagrożenie, że jeżeli tylko postawimy znak równości, architektura ułatwia wdrożenie regulacji albo jest po to, żeby spełnić pewne regulacje, to to jest duży risk. To tak jak np. AI [niesłyszalne 00:46:10] wdraża pewne elementy governance’owe w obszarze AI. I teraz jest ryzyko, że jeżeli to potraktujemy właśnie, że to może pomóc nam tutaj, elementy architektury korporacyjnej, to to się skończy tylko na regulacjach. Ja chciałbym raczej pozycjonować architekturę jako coś, co pozwala budować wartość organizacji i zarabiać pieniądze. Przynajmniej może nie bezpośrednio, ale pośrednio, żeby i biznes i IT do tego przekonać.
Szymon Warda: Jasne. Dobrze, to w takim razie zbieramy i dziękujemy. Dzięki wszystkim. Dzięki Andrzeju.
Andrzej Sobczak Dzięki Łukaszu, dzięki Szymonie za zaproszenie. Mam nadzieję, że nie zniechęciłem do architektury i myślenia architektonicznego. Jeszcze raz powtórzę, architekt to nie ten co rysuje dużo modeli, może rysować mało, ale niech te modele wpływają na działanie organizacji, na rozwój technologii, na budowanie systemów. I architekt nie jest wrogiem, a przyjacielem i ludzi z biznesu i technologii.
Łukasz Kałużny: Dobre podsumowanie. Dziękujemy, trzymajcie się.
Andrzej Sobczak Dzięki, do zobaczenia. Cześć!