To jest 242. odcinek podcastu Porozmawiajmy o IT, w którym z moimi gośćmi rozmawiam o S/4Hana i nowoczesnej architekturze SAP. 

Wszystko, co potrzebujesz: notatka, linki, transkrypcja czekają na Ciebie na porozmawiajmyoit.pl/242. Sponsorem tego odcinka jest Capgemini. 

Ja się nazywam Krzysztof Kempiński, ten podcast jest zupełnie darmowy. Zostaw ocenę lub podziel się nim w mediach społecznościowych, abym mógł zrealizować misję polegającą na poszerzaniu horyzontów ludzi z branży IT. To dla mnie wiele znaczy. A teraz zapraszam Cię już do odcinka. 

Odpalamy! 

 

Cześć! 

Dzisiaj moimi gośćmi są Wiktor Skawiński, SAP Cloud Developer w  Capgemini oraz Tomasz Wilk, SAP Developer Hero z 2018, specjalista SAP z 20-letnim stażem. Obronił pracę doktorską na Politechnice Wrocławskiej w obszarze sztucznej inteligencji. Zarządzający architekt oprogramowania w Capgemini Polska. W ostatnich latach silnie związany z architekturą rozwiązań SAP, był głównym projektantem technicznym i koordynatorem developmentu w projektach dla firm z obszarów usług publicznych, sprzedaży detalicznej i chemicznej. 

Wiktor, Tomasz, bardzo miło mi gościć Was w podcaście. 

 

Tomasz Wilk: Dzięki.

Wiktor Skawiński: Dzięki, cześć.

 

Postawiliśmy sobie dzisiaj taki temat, jakim jest nowoczesna architektura SAP i dosyć ważny komponent, jaki jest częścią tej architektury, jednocześnie gorący obecnie temat, czyli S/4HANA. 

Zanim do tego przejdziemy, to chciałbym Was zapytać, czy słuchacie podcastów, może znacie jakieś ciekawe audycje albo odcinki, które tutaj warto zarekomendować słuchaczom. 

 

WS: Może to być zaskoczeniem, ale typowo podcastów związanych z SAP-em nie słucham, nie widziałem ich zbyt dużo. Zdarzają się podcasty z IT, takie np. kanały jak Maciej Aniserowicz albo Hania, Analiza IT, czyli bardziej takie ogólne tematy związane również ze strefą biznesową. Oprócz tego zdarzają się też podcasty związane z przedsiębiorczością, ekonomią i polityką. 

TW: Ja również takich typowych podcastów nie słucham, natomiast jestem zainteresowany tematami z gospodarki, z polityki. Lubię portal bankier.pl, a także prezentacje TED-a. Naprawdę osoby tam prezentujące to są profesjonaliści. Lubię obserwować, w jaki sposób to robią i także treści są dla mnie osobiście niezwykle ciekawe. Tutaj np. Simon Sinek jest taką osobą, którą także śledzę na LinkedInie. 

 

Tak, zdecydowanie warte rekomendacji. Dzisiaj postawiliśmy sobie temat nowoczesnej architektury SAP, ale myślę sobie, że taką ważną częścią tego, żeby użyć nowoczesnej architektury, żeby skorzystać z tych różnych elementów czy komponentów, o których dzisiaj będziemy mówić, jest to, żeby ludzie w organizacji, którzy są związani z tym tematem, mieli wiedzę, mogli się dzielić swoimi doświadczeniami i też czerpać z wiedzy innych. 

Dlatego, może tak dosyć niestandardowo, ale chciałbym Was zapytać o to, jak w Capgemini, właśnie w tym obszarze SAP, dzielicie się wiedzą, w jaki sposób korzystacie ze swoich doświadczeń. 

 

TW: W Capgemini mamy prężną społeczność SAP-ową. Mamy SAP Community pod wodzą obecnie Anny Wilk. Mamy grupę architektów, gdzie wymieniamy się wiedzą z zakresu architektury. Prezentujemy rozwiązania z projektów, rozwiązujemy wspólne problemy. Uczestniczymy także w globalnej społeczności SAP-owej. Tutaj taką osobą, która integruje tę społeczność, jest Witalij Rudnicki z SAP-a. Chciałbym go tutaj gorąco pozdrowić. 

Więc uczestniczymy w spotkaniach SAP Meetup. Są to takie spotkania współorganizowane przez różne firmy, w tym przez Capgemini, na których są prelegenci prezentujący tematy z zakresu innowacji, ciekawe tematy technologiczne, sesje Inside Tracks (to są takie bardziej rozbudowane meetupy, gdzie jest więcej prelegentów, tematy są bardziej dopracowane) oraz SAP Code Gems, gdzie każdy może spróbować zaimplementować jakieś rozwiązanie, przyjeżdża specjalista w danej dziedzinie, mamy dostęp do systemów SAP-a, do których normalnie często nie ma takiego dostępu, nie można tych rzeczy przetestować, i można się czegoś ciekawego nauczyć, powymieniać doświadczeniami z innymi specjalistami, ale także napisać jakiś kawałek kodu. 

Jako Capgemini mamy także taką inicjatywę, która się nazywa TechnoVision – nasi najlepsi architekci z całego świata co roku przygotowują tematy, które w najbliższym czasie czy też w dłuższej perspektywie będą tematami wiodącymi w zakresie tworzenia systemów, architektury, innowacji. I w 2023 roku, 2024 roku rozwiązania generative AI były tutaj tematami nawiązującymi. Nas to oczywiście też dotyczy, ponieważ SAP w tej chwili w obszarze BTP także wprowadza usługi związane z innowacją. Są też te rozwiązania generative AI tam dostępne. 

 

Myślę, że to jest też bardzo dobry moment do tego, żeby wspomnieć o Tech-Talku, który jest tutaj na horyzoncie, niedługo się faktycznie odbędzie. Wiem, że też obydwaj do tego Tech-Talku wnosicie swoją wiedzę, swoje doświadczenie, więc myślę, że warto o tym tutaj powiedzieć. 

 

TW: I serdecznie zapraszamy. 

 

Tak jest. Tomku, chciałbyś więcej na ten temat może powiedzieć? Na czym to polega? Czym to jest? Jakie treści można tam usłyszeć, zobaczyć? 

 

TW: Obaj będziemy z Wiktorem mieć prezentację. Wiktor może zaraz sam powie, o czym będzie prezentował, ja natomiast będę prezentował właśnie tworzenie nowoczesnych aplikacji w środowisku S/4HANA. I nie chciałbym zdradzać tutaj zbyt wiele szczegółów, natomiast odpowiemy sobie także na pytanie: dlaczego? 

WS: Tak, a moim tematem będzie SAP BTP Workflow i na tym wykładzie postaram się przedstawić trochę tej nudnej teorii i konfiguracji, wejść trochę bardziej w szczegóły każdej funkcjonalności, poopowiadać również o tym, jakie są możliwości danej technologii oraz jakie możemy napotkać problemy. 

 

I kiedy to wydarzenie, kiedy ten Tech-Talk się odbędzie? 

 

WS: Odbędzie się on 18 kwietnia w Hard Rock Cafe we Wrocławiu. 

TW: O godzinie 17. 

 

Wszelkie tutaj dodatkowe jeszcze informacje będą w notatce do odcinka, gdyby ktoś był zainteresowany, to tam odsyłamy. Świetnie, to teraz proponuję przejść do omówienia kilku takich niezbędnych, czy też istotnych klocków, elementów, z jakich, można powiedzieć, architektura, nowoczesna architektura SAP się składa i zacznijmy może od SAP Fiori, jaką rolę sprawuje właśnie w tej nowoczesnej architekturze aplikacji SAP. 

 

TW: Moje pierwsze zetknięcie z SAP Fiori miało miejsce ok. roku 2011. Była to wtedy bardzo świeża technologia. Roman Bartlok, który jest obecnie architektem w SAP-ie i pracował przy tematach także BTP S/4HAN-y, pracował wtedy w Capgemini i poszukiwał osoby, która pomogłaby mu przygotować workshopy dla klienta, właśnie z tego obszaru z SAP Fiori. Była to technologia nowa, jeszcze nie było specjalistów w tej dziedzinie. 

Zdecydowałem się podjąć wyzwanie, nauczyłem się tej technologii, skonfigurowałem systemy, a także przygotowałem live demo dla klienta. I od tamtego czasu słyszałem wiele rzeczy, czym SAP Fiori teoretycznie jest. Według niektórych są to po prostu aplikacje napisane w SAP UI5, jeszcze inni kojarzą, że jest coś takiego jak Fiori Launchpad, więc wyobrażają sobie, że jest to taki punkt dostępowy do tych aplikacji. A jeszcze inni kojarzą, że na stronach można znaleźć informacje o tym, jak te aplikacje powinny wyglądać. 

I to jest wszystkiego po trochu. De facto jest to właśnie User Experience, UX. Jest to myśl przewodnia SAP-a, jak powinno wyglądać wprowadzanie danych i prezentacja tych danych. 

Dawno, dawno temu, kiedy zaczynaliśmy jeszcze z systemem R1, widoki wyglądały zupełnie inaczej, te wszystkie aplikacje. Potem przyszło SAP GUI i była duża krytyka, że sposób wprowadzania danych jest nieintuicyjny, że trzeba pracować w SAP-ie, żeby rozumieć SAP-a. I SAP Fiori jest odpowiedzią SAP-a na te wszystkie zarzuty. Więc jest to według SAP-a, ale także w mojej opinii, rozwiązanie dużo bardziej takie intuicyjne, dużo ładniejsze i dużo bardziej przyjazne użytkownikowi. 

Jest tam też szereg innych konceptów, co się w tych aplikacjach powinno znajdować, żeby to miało sens. W SAP GUI często mieliśmy transakcje, w których było po kilkadziesiąt pól i wiele z nich nie było istotnych dla użytkownika. SAP Fiori także daje nam scenariusze, w jaki sposób powinniśmy budować aplikacje, żeby nie było zbędnych danych i żeby te dane były wprowadzane w sposób przejrzysty. 

 

Czy dobrze rozumiem, że to jest swego rodzaju frontend? Jak gdyby elementy frontendu plus wytyczne, jak je budować? 

 

TW: Tak.

 

Okej, to mamy tutaj słowo na temat frontendu. Myślę, że jako taką przeciwwagę teraz warto powiedzieć co nieco o backendzie, a szczególnie o ważnym dla klientów, ale też dla deweloperów temacie S/4HANA. Dlaczego w ogóle S/4HANA? 

 

TW: Żeby powiedzieć, dlaczego S/4HANA, musimy się cofnąć do historii SAP-a, a mianowicie SAP jako firma powstała już ponad 50 lat temu. Utworzyło ją pięciu byłych pracowników IBM-a i początkowo był to system składający się z jednej warstwy. Wszystko było w jednym miejscu, baza danych, część tzw. frontendowa, backendowa. Potem była wersja R2, w której już były dwie warstwy, R3, w której były trzy warstwy klasyczne, i wszystkie te wersje przynosiły pewną rewolucję. W 2005 roku był NetWeaver, w którym SAP bardziej się otworzył na bardziej otwarte technologie. Była próba przepisania SAP-a na wersję Javową. Były wtedy stacki ABAP-owy i Javowy. 

Teraz jesteśmy świadkiem kolejnej takiej rewolucji. Z jednej strony są to systemy, które są dużo bardziej wydajne, ponieważ pod spodem znajduje się baza danych HANA. Jest to baza danych, w której przetwarzanie odbywa się w pamięci RAM, przechowywanie tych danych także odbywa się w RAM-ie. I mamy różnego typu tabele. Mamy tego starego typu tabele typu row-based, w których kiedyś, jak robiliśmy selecta z bazy danych w SQL-u, to stosowało się select gwiazdka i to było normalne. 

Natomiast w HAN-ie nie jest to wydajne polecenie. Powinno się czytać poszczególne kolumny, ale za to są same benefity, ponieważ jest to rozwiązanie dużo szybsze, dużo lepsze do rozwiązań analitycznych i dodatkowo w S/4HAN-ie to, co jest ważne, zmienił się model danych. Więc jest to rewolucja techniczna. W jednym z projektów, w których stosowaliśmy S/4HAN-ę, tworzyliśmy przetwarzanie danych masowych, dużych ilości i zeszliśmy z przetwarzania danych, które odbywało się wiele dni, do godzin, więc naprawdę wydajność była tutaj dużo lepsza, ale także model danych jest inny, ponieważ skoro już mamy bardziej wydajną bazę danych, w której zasady funkcjonowania są inne niż w tych poprzednich, to także model danych musiał zostać zmieniony, żeby bardziej korzystać z tej mocy obliczeniowej i być bardziej dopasowany do tej sytuacji. 

Ponadto są tutaj nowe koncepty, o których myślę, że jeszcze będziemy mówić. 

 

Powiedziałeś tutaj o wielu benefitach, które mam wrażenie, dotykają albo docierają do developerów, związane chociażby z wydajnością, związane z tym, że inaczej się dane pobiera, inaczej się je reprezentuje. Czy jednak dla klienta, dla użytkownika takiej aplikacji przejście czy też zmiana właśnie na HAN-ę cokolwiek wnosi, cokolwiek zmienia, jakieś korzyści są? 

 

TW: Samo w sobie może nie zmieniać dla użytkownika nic. Niemcy mają na to piękne słowo, które brzmi Jajn, Czyli i tak, i nie, bo to zależy. Tutaj, jeżeli będziemy mówić o transformacji do S/4HAN-y, to mamy różne scenariusze. Mamy np. scenariusz Brownfield, w którym bierzemy aplikacje takie, jakie mieliśmy i staramy się przenieść na S/4HAN-ę z minimalnymi zmianami. Zmieniamy tylko to, co jest konieczne, żeby to rozwiązanie działało. Zaletą dla klientów jest to, że jest to rozwiązanie tanie, natomiast wada tego rozwiązania jest taka, że kompletnie nie korzystamy z możliwości, które daje S/4HANA i te aplikacje już na samym początku są przestarzałe. Więc jest to tak naprawdę taki krok pośredni. 

Druga kwestia, drugi sposób transformacji to jest Greenfield. Musimy znać nasze procesy, musimy mieć od tego ekspertów, musimy przeanalizować, co potrzebujemy na nowym systemie, czyli projektujemy to od nowa i implementujemy to od nowa. I to rozwiązanie w teorii ma same zalety, ponieważ tworzymy aplikacje, które są dedykowane na S/4HAN-ę, w teorii są zoptymalizowane, ale po pierwsze mamy tutaj ryzyko, ponieważ wszystko tworzymy od nowa, a po drugie inicjalny koszt dla klienta jest większy. 

Więc jest jeszcze rozwiązanie typu curve out, takie rozwiązanie hybrydowe, w którym w części systemu tworzymy kod od początku, od zera, a część kodu staramy się przenieść. I jeżeli chodzi o zmiany dla takiego użytkownika, to są to zmiany wynikające też w dużej mierze z konceptów. Jeśli chodzi o model danych, kiedyś były aplikacje, transakcje do vendora. Następnie teraz mamy biznespartnera, którego możemy oznaczyć, że on pełni funkcje vendora, ale to są inne transakcje, inne aplikacje, więc dla developera, dla użytkownika funkcjonuje to w sposób inny. 

Druga zmiana konceptu jest taka, że kiedyś większość tych wszystkich aplikacji, to kiedyś jeszcze trwa, bo SAP GUI wciąż jest w mocnym użyciu, ale standardem de facto są aplikacje napisane przy użyciu SAPUI5, Fiori i w wielu jeszcze firmach użytkownicy są przyzwyczajeni do SAP GUI i nie korzystają jeszcze z SAP Fiori, wciąż tutaj dużo aplikacji powstaje i są wciąż rozwijane, więc tutaj na pewno jest duży przeskok dla klientów, którzy już zaczynają korzystać z tych aplikacji Fiori więcej niż to było w przeszłości. 

 

Dużo się mówi właśnie o S/4HAN-ie również w kontekście tej transformacji, tego przejścia. Dlaczego ten temat jest właśnie gorącym tematem i jak się mówi o SAPie, to od razu właśnie pojawia się ten temat S/4HAN-y i migracji do tej bazy właśnie? 

 

TW: Wiktor jeszcze poopowiada o BTP. Bo kiedy mówimy o SAPie, to jest to taki słoń. Nie wiem, czy znasz opowieść o ślepcach i słoniu, że ślepcy podchodzili do słonia i potem rozmawiali ze sobą. Pierwszy powiedział, że słoń to jest taki skórzany pasek, który luźno dynda na wietrze. Drugi powiedział, że to jest taka gruba, pionowa kolumna. Trzeci powiedział, że jest to coś nie do ogarnięcia. I tak właśnie jest z SAP-em. Kiedyś był to system, na którym mieliśmy tylko finanse, a teraz technologicznie i funkcjonalnie SAP pokrywa olbrzymie spektrum możliwości. 

Jest to gorący temat dlatego, że jest to kolejna ewolucja Enterprise Resource Planningu, systemów do tego służących, ale także, że jest to część wciąż rozwijającego się środowiska SAP, w którym mamy także rozwiązania w chmurze, Ale też jest powód taki bardzo przyziemny, a mianowicie taki, że początkowo datą, do której rozwiązania SAP Business Suite miały być utrzymywane, te poprzednie rozwiązania przed S/4HAN-ą, to był 2025. Ostatecznie jest to przesunięte na rok 2027. I S/4HANA, przynajmniej na ten moment, powinna być utrzymywana do roku 2040. 

Ja w przeszłości pracowałem na systemie 4.6c. To był już wtedy system leciwy i już nie był utrzymywany przez SAP-a. Natomiast tamta firma dogadała się z SAP-em, że SAP dalej utrzymywał ten system, co powodowało po prostu dodatkowe koszta. 

Problem był też taki, że z każdym kolejnym miesiącem, kiedy trzeba było coś poprawić, dodać jakąś funkcjonalność, coś zmienić, przeniesienie aplikacji na wersję wyżej systemu stawało się po prostu droższe. 

Bo kiedy mówimy o SAPie, to jest to taki słoń. Nie wiem, czy znasz opowieść o ślepcach i słoniu, że ślepcy podchodzili do słonia i potem rozmawiali ze sobą. Pierwszy powiedział, że słoń to jest taki skórzany pasek, który luźno dynda na wietrze. Drugi powiedział, że to jest taka gruba, pionowa kolumna. Trzeci powiedział, że jest to coś nie do ogarnięcia. I tak właśnie jest z SAP-em. Kiedyś był to system, na którym mieliśmy tylko finanse, a teraz technologicznie i funkcjonalnie SAP pokrywa olbrzymie spektrum możliwości.

 

Czyli mamy takie powody biznesowe, użytkowe, ale też właśnie związane z tym terminem, o którym tutaj wspomniałeś. Właśnie, kiedy mówi się o SAP-ie, który, tak jak tutaj bardzo dobrze powiedziałeś, jest takim słoniem, to też często przychodzą na myśl projekty, które są projektami dużymi, które są związane z dużym, ciężkim biznesem, które trwają długo i te instancje tych aplikacji faktycznie mają już swoje lata. Pojawia się pytanie, jak w tej nowoczesnej gospodarce, kiedy tak bardzo walczymy o jednak iście do przodu, o to, żeby ciągle coś urozmaicać, coś zmieniać, coś dokładać, jak tutaj w kontekście rozwoju aplikacji SAP-owych i w ogóle pewnie biznesu znaleźć czas na innowacje w tym obszarze? 

 

TW: To jest bardzo fajne pytanie. Ale zacząłeś tutaj wprowadzeniem właśnie odnośnie do dużych projektów i każdy zakłada, że jak mamy takie duże projekty, duże firmy, one muszą się udać. Ale mamy przykład Lidla, który próbował wprowadzić SAP-a, wydali 500 milionów euro na projekt i ponieśli porażkę. To nie zawsze jest tak, że to się udaje. 

Jeśli chodzi o innowacje, właśnie wdrożenie zmian, to jest taka konferencja SAP-a, nazywa się TechEd. Ona jest organizowana dorocznie i na niej SAP prezentuje, co w najbliższym czasie będzie najistotniejsze, na co SAP stawia, jakie rozwiązania SAP będzie rozwijał, co próbuje zaoferować klientom. W okolicach 2010, 2011, wtedy kiedy też się pojawiała baza danych HANA, SAP zaprezentował na TechEdzie slajd, w którym odnosili się do innowacji i de facto korzystali z reguły Parreto. Jest to reguła, którą deweloperzy z reguły kojarzą, ponieważ przyjęło się, że 80% funkcjonalności realizuje się w 20% czasu, a potem w 80% czasu realizuje się pozostałe 20% funkcjonalności. 

I tę regułę także możemy odnieść do innowacji. SAP przyjął, że taka klasyczna firma przeznacza 80% budżetu, czasu na utrzymanie swoich systemów. 20% przeznacza na innowacje i SAP chciałby zaoferować klientom możliwość odwrócenia tych tendencji, żebyśmy byli w stanie przeznaczyć 80% budżetu na innowacje, a 20% na utrzymanie systemów. 

Kiedy mówimy innowacja, myślimy z reguły o technologiach, właśnie o generative AI, o AI, o dronach IoT, Ale de facto, jeżeli ja teraz bym Ci dostarczył drony, jakieś rozwiązania AI, generative AI to są po prostu fontanny, wodotryski, ale one tak de facto nic nie wnoszą, jeżeli nie mają wpływu na możliwości firmy w konkurowaniu na rynku. 

Tak naprawdę w kontekście biznesowym innowacją jest, i to było też często rewolucją, że kiedy wcześniej paczka szła tydzień, dwa, to zeszliśmy teraz do sytuacji, że jesteśmy w stanie paczkę wysłać w ciągu dnia. To jest rewolucja, to jest innowacja, to naprawdę miało olbrzymi wpływ na biznes. Drony same w sobie nie przynoszą nic, ale jeżeli np. Amazon jest w stanie wykorzystać drony, żeby dostarczyć paczki tam, gdzie nie było to wcześniej możliwe, to znów jest to innowacja, jest to rozwój biznesu. 

Mikro serwisy same w sobie jest to rozwiązanie architektoniczne, ale jak np. Netflix wykorzystał je w ten sposób, żeby być w stanie szybko reagować na zmiany, żeby szybko być w stanie te aplikacje deployować bez ryzyka uszkodzenia innych elementów systemu, to to także miało wpływ na rozwój biznesu. 

Więc wszystkie te rzeczy muszą odpowiadać potrzebom biznesu i wtedy możemy mówić o innowacji. Jest zasada dotycząca S/4HAN-y, która się nazywa Keep Decor Clean. Sama w sobie brzmi niewinnie, ale w niej też kryje się innowacja, ponieważ jeżeli zostawimy sobie standardowe procesy na S/4HAN-ie, jeżeli jesteśmy w stanie nasze rozszerzenia przenieść na BTP, to utrzymanie takiej S/4HAN-y jest dla nas tańsze. 

Wciąż możemy stosować rozszerzenia w sposób, jaki to proponuje SAP, który także powinien być wydajny i jesteśmy w stanie ten zaoszczędzony budżet przeznaczyć w tych obszarach innowacyjnych. Czyli jeżeli mamy jakieś procesy, które są standardowe dla nas, dla konkurencji, zostawiamy je standardowe, staramy się przy nich nie grzebać. Jeżeli mamy jakieś procesy, które stanowią o naszej przewadze konkurencyjnej, wtedy oczywiście inwestujemy w nie. 

 

Rozumiem. Czy na bazie tych projektów, które do tej pory już zrealizowaliście, udało Wam się wypracować w Capgemini jakiś rodzaj sugestii, jakiś rodzaj dobrych praktyk, jak tworzyć nowoczesne oprogramowanie na S/4HANA? 

 

TW: Tak, oczywiście. Nazywa się to Multipillar S/4HANA Architecture. Dla osób, które tego rozwiązania nie kojarzą, wróćmy do rozwiązania, czy też do architektury, o jakiej pisał Gartner. Gartner jest to firma, technologiczna, zajmująca się consultingiem, researchem. Można ją kojarzyć np. z Magic Quadrantu od Gartnera. Przygotowali opis Composable Architecture. 

Mamy tutaj trzy warstwy. Platforma, na której mamy procesy rdzenne, gdzie ważna jest dla nas standaryzacja i żeby to wszystko było zgodne z prawem, żeby te kwestie regulacyjne nie były dla nas problemem. Potem mamy warstwę, która nam przynosi, można powiedzieć, przewagę kompetencyjną oraz na ostatniej warstwie mamy platformy innowacyjne, które wspierają nasze możliwości biznesu i umożliwiają nam lepsze prowadzenie biznesu. 

I dlaczego o tym wszystkim mówię? Ponieważ to, co właśnie przedstawił Gartner i to, co my prezentujemy w MPSA, obie te rzeczy powstawały mniej więcej w tym samym czasie. I to, co my utworzyliśmy w Multipilar S/4HANA Architecture jest zgodne z tym, co proponuje Gartner. Nasze rozwiązanie jest dopasowane do świata SAP-owego. 

Na pierwszej kolumnie mamy S/4HAN-ę, Możemy mieć też Aribę, Success Factors. Są to te obszary, gdzie chcemy mieć standardowe procesy. Mamy drugą kolumnę, w której jako Capgemini dopuszczamy różne platformy. SAP rekomenduje BTP i nazywa to Side-by-Side Extensions, czyli jeżeli mamy jakieś właśnie przewagi kompetencyjne, musimy rozwinąć nasz proces, to robimy to w BTP. I staramy się nie dotykać standardowych procesów w pierwszej kolumnie. 

I jest ta kolumna trzecia, w której mamy aplikacje luźno związane ze światem SAP-owym. Możemy mieć np. modele generative AI zdeployowane na Azure i poprzez API możemy się komunikować z tym, co się tam znajduje. Możemy mieć jakieś inne usługi, może Databricks, może coś innego ze sztucznej inteligencji, może po prostu jakieś nawet składowanie danych, w zależności od potrzeb, w zależności od tego, co chcemy mieć. 

Więc mamy te trzy kolumny i to jest sposób, w jaki rekomendujemy klientom, żeby tę infrastrukturę właśnie kształtować. Mamy też sposoby, jak oszacowywać koszta, w jaki sposób decydować, gdzie powinny być poszczególne zmiany. I oczywiście mamy też referencje projektowe. 

 

Tutaj, Tomek, kilka razy wspomniałeś o BTP. Myślę, że to jest teraz dobry moment, żeby opowiedzieć właśnie, czym jest Business Technology Platform, jaką rolę będzie sprawowało to narzędzie właśnie we wspomaganym AI procesie tworzenia rozwiązań w SAP-ie. 

 

WS: Tak, to zaczynając od tego, co to jest BTP. Jak sama nazwa wskazuje, jest to platforma w modelu PAS, czyli Platforma as a Service i oferuje nam ona szereg narzędzi niezbędnych do tworzenia oprogramowania, ale również do jego rozwoju i utrzymywania oraz monitorowania. Oprócz tego otrzymujemy również dostęp do przeróżnych modułów czy serwisów, które wspierają cały cykl życia aplikacji. 

A w kontekście AI platforma posiada usługi związane ze sztuczną inteligencją oraz właśnie uczeniem maszynowym, które umożliwiają integrację funkcji AI w aplikacje biznesowe. AI również wykorzystywane jest w przeróżnych narzędziach, o których właśnie wspominałem i żeby nie być gołosłownym, to posłużę się przykładem. SAP Build Process Automation. Pokrótce jest to takie narzędzie, w którym tworzymy w pełni zautomatyzowane procesy i dzięki wbudowanym AI możemy wykorzystać to do np. ekstrakcji danych. I to zarówno z ustandaryzowanych plików takich jak excelowych, właśnie CSV-ek, czy również nieustandaryzowanych, takich jak PDF-y czy JPG-i. 

Więc tak podsumowując, wpływ AI możemy zauważyć na całej platformie, na całym BTP. Tak jak mówiłem, od możliwości integracji po gotowe rozwiązania typu jakieś chatboty lub właśnie AI służące do pewnych predykcji czy prognozy. 

 

Już się troszkę obawiałem, że powiesz, że za chwilę nas AI zastąpi kompletnie, a na szczęście okazuje się, że jest tylko wspomagającym narzędziem, co jak najbardziej ma sens. Czyli okazuje się, że developerzy, programiści będą jednak potrzebni, dlatego chciałbym Was zapytać tutaj o dwa takie modele właśnie programowania aplikacji i zacznijmy może od Cloud Application Programming Model, czym on jest, dla kogo powstał, po co został stworzony? 

 

WS: Cloud Application Programming Model, czyli CAP, jest zestawem narzędzi i reguł, które mają ułatwić i usprawnić proces tworzenia aplikacji biznesowych w chmurze. Kto na tym korzysta? Tak naprawdę wszyscy, od biznesu, który dostaje dane rozwiązania szybciej, po developerów, którzy jak sam SAP twierdzi, mogą bardziej się skupić na tej stronie biznesowej niż na technicznej. 

Więc CAP oferuje spójny model programowania, szczególnie w kontekście integracji z różnymi systemami oraz zarządzania danymi biznesowymi. 

Taką podstawą CAP-a są CDS, czyli Core Data Services, które pozwalają nam zdefiniować modele danych oraz zdefiniować serwisy, do których następnie możemy później dodać własną, jakąś customową logikę, używając Node.js lub Java. Tak że CAP powstał w celu zaoszczędzenia czasu nad developmentem, tak aby na ogół proste, jednak powtarzalne taski zniknęły i aby developer czy programista nie tworzył wszystkiego od początku, nie wymyślał tego przysłowiowego koła na nowo, przez co może skupić się bardziej na tym rzeczywistym problemie biznesowym, który dana aplikacja ma rozwiązać. 

Taką podstawą CAP-a są CDS, czyli Core Data Services, które pozwalają nam zdefiniować modele danych oraz zdefiniować serwisy, do których następnie możemy później dodać własną, jakąś customową logikę, używając Node.js lub Java. Tak że CAP powstał w celu zaoszczędzenia czasu nad developmentem, tak aby na ogół proste, jednak powtarzalne taski zniknęły i aby developer czy programista nie tworzył wszystkiego od początku, nie wymyślał tego przysłowiowego koła na nowo, przez co może skupić się bardziej na tym rzeczywistym problemie biznesowym, który dana aplikacja ma rozwiązać. 

 

Drugim z takich modeli jest model o bardzo dźwięcznie brzmiącej nazwie RAP, czyli ABAP RESTful Application Programming Model. Powiedz, proszę, Wiktor, więcej na ten temat. 

 

WS: Tu akurat opowie Tomek. 

TW: Jest to ABAP RESTtful Application Programming Model. Także jest to koncept bliźniaczy do tego, co już opisał Wiktor w CAP-ie. RAP powstał jako dziecko BOPF-a czyli Business Objects Processing Framework. 

Był to framework w SAP-ie, w ABAP-ie, który miał być także takim docelowym frameworkiem, natomiast miał pewne wady i SAP zdecydował się wtedy wprowadzić RAP-a, ale oba frameworki mają walidację, determinację, ackję, wiele rzeczy jest rozwiązywanych w sposób podobny. Można więc stwierdzić, że RAP w niektórych obszarach wprowadził nowe rozwiązania, jak np. Entity Modeling Language, ale także korzysta z tego, co jego ojciec miał już wypracowane. Bo już w BOPF-ie były właśnie Core Data Services, tworzyliśmy web serwisy przy wykorzystaniu BOPF-a, i była możliwość łatwego wykorzystania tych web serwisów w aplikacjach zgodnych z Fiori. 

Tutaj też należałoby wspomnieć o Fiori Elements, bo jest to rozwiązanie low-code od SAP-a, w którym poprzez anotację można wygenerować aplikację frontendową, którą także można rozszerzać, bo jest to aplikacja bazująca na SAPUI5, można ją rozszerzać, pisząc kod w JavaScript, więc RAP umożliwia stworzenie nam kompletnego rozwiązania, tak  samo jak zresztą CAP. 

Ja z RAP-em spotkałem się po raz pierwszy kilka lat temu, gdzie tworzyliśmy prototypy, mieliśmy nasze aplikacje napisane przy użyciu BOPF-a. Potem u jednego z klientów w obszarze ABAP-a w Cloudzie Dalej korzystaliśmy już z RAP-a i tworzyliśmy rozszerzenia typu side-by-side w chmurze. 

Jest to rozwiązanie, które może być też ciekawe pod względem integracji z innymi rozwiązaniami, bo tak jak w świecie SAP-owym duża zmiana zaistniała też w kontekście API. Kiedyś były web serwisy SOAP-owe, teraz mocno bazujemy na OData. Natomiast w wielu zastosowaniach, np. w przypadku mikroserwisów, stosujemy eventy. Tutaj także pisząc usługi w RAP-ie, możemy także obsługiwać albo triggerować eventy i jest taka usługa w BTP Event Mesh, możemy się z nią także integrować. 

 

W nazwie tego modelu mamy ABAP. Zastanawiam się, czy developer, który działa w tym obszarze, jest w stanie polegać tylko i wyłącznie na ABAP-ie. Czy to daje mu wystarczająco narzędzi, aby budować rozwiązania? 

 

TW: Znowu mamy tutaj do czynienia ze słoniem i w teorii, jeżeli byśmy np. pracowali w stoczni i byśmy całe życie wkręcali śrubki, moglibyśmy w teorii działać tak do końca świata. Natomiast żyjemy w świecie, który mocno się zmienia. Co oznaczają rozwiązania generative AI dla nas, to dopiero pokaże czas, ale już teraz widać, że zmiany na rynku są nieuchronne i warto jednak śledzić te zmiany. Dobrze jest nie zamykać się w samym ABAP-ie. 

Jeszcze w czasie tych poprzednich wersji systemu była np. potrzeba dla developerów ABAP-a, żeby znali SQL-a. To jest tak naprawdę zintegrowane z tym językiem, więc każdy developer ABAP-a, SQL-a dobrze zna. Było kiedyś SAP GUI, teraz jest SAP Fiori. Jeżeli osoba, która pracuje w ABAP-ie, chciałaby także zajmować się frontendem, to ABAP już nie wystarczy. 

Kolejna rzecz jest taka, że jeżeli chcemy się rozwijać jako developerzy, powinniśmy wiedzieć, w jaki sposób tworzy się oprogramowanie. Dawno, dawno temu, to był bodajże 2005 rok, wszedł koncept obiektówki do ABAP-a. Zmierzam do tego, że jest szereg wzorców projektowych, które zaadaptowaliśmy w ABAP-ie z Java. Np. model View Controller, który był zinterkorporowany np. w Web Dynpro. Tam wszystko opierało się na Model View Controller. Aplikacje z budowało się jako Model View Controller. 

Tych wzorców projektowych jest wiele, cały czas powstają nowe i dobrze jest je znać, a dodatkowo właśnie, jeżeli byśmy chcieli pracować z rozwiązaniami związanymi ze sztuczną inteligencją, może się okazać, że może np. musimy się nauczyć Pythona, ale przynajmniej powinniśmy wiedzieć, jakie typy są API, że mamy właśnie OData, mamy web serwisy restowe. W jaki sposób mamy się komunikować ze światem zewnętrznym, bo z tego też wynika, w jaki sposób my możemy tworzyć te usługi lepiej. 

 

Co powiedzielibyście osobie, która chce pracować przy aplikacjach SAP, ale właśnie w tym nowoczesnym wydaniu niekoniecznie przykręcać śrubki, tylko faktycznie mieć do czynienia z tymi nowoczesnymi rozwiązaniami, technologiami i architekturami? Co doradzilibyście w kontekście kompetencji, w kontekście tego, co taka osoba musi umieć, żeby właśnie taką przygodę rozpocząć? 

 

TW: Konsultanci SAP-a zawsze mieli większy kontakt z klientami. I dlatego bardzo ważne są także soft skille, skille analityczne i rozwiązywanie problemów. Wiedza modułowa. Otóż pracując w danym kontekście, lepiej będzie przebiegała nasza współpraca, jeżeli po pierwsze wiemy, nad czym pracujemy, w jaki sposób np. funkcjonują finanse, ale jaki jest także słownik pojęć, bo jeżeli rozmawiamy z klientem lub z osobą funkcjonalną w sposób zbyt techniczny, ona może nas nie zrozumieć, a my możemy też mieć problemy ze zrozumieniem klienta czy naszych funkcjonalnych. 

Kolejna ważna sprawa jest taka, że pracujemy coraz bardziej w środowisku, w którym powstają zespoły, praca jest bardziej powiązana z agilem, więc dobrze jest znać Scrum, wiedzieć, w jaki sposób pracować w środowiskach, które na nim bazują i powinniśmy też być w stanie zawsze szukać sobie wiedzy. 

Kiedy właśnie pracowaliśmy nad tym BOPF-em, to były lata bodajże 2017, to wtedy nie było żadnych informacji na temat tych frameworków. Byliśmy jednymi z pierwszych, którzy z tymi BOPF-ami powiązanymi z Core Data Services pracowali i wiele problemów, na które napotykaliśmy, odkrywaliśmy po raz pierwszy. 

Mówię 2017, teraz mamy 2024. Teoretycznie nie minęło dużo czasu, a już mamy nowy framework, nowe wyzwania i jeżeli pracujemy w tym obszarze nowych technologii, powinniśmy się liczyć z tym, że to my będziemy prekursorami i to my będziemy napotykać na problemy po raz pierwszy. 

WS: Tak, ja bym chciał się jeszcze dodać, albo może przypomnieć, że aby pracować w aplikacjach SAP, nie trzeba wcale znać ABAP-a. Tak że to może być świetna informacja dla kogoś, kto by się chciał np. przebranżowić, a ma doświadczenie z tak zwaną webówką, czyli właśnie tworzenie jakichś stron internetowych, to już jest świetny punkt zaczepienia. 

Konsultanci SAP-a zawsze mieli większy kontakt z klientami. I dlatego bardzo ważne są także soft skille, skille analityczne i rozwiązywanie problemów. Wiedza modułowa. Otóż pracując w danym kontekście, lepiej będzie przebiegała nasza współpraca, jeżeli po pierwsze wiemy, nad czym pracujemy, w jaki sposób np. funkcjonują finanse, ale jaki jest także słownik pojęć, bo jeżeli rozmawiamy z klientem lub z osobą funkcjonalną w sposób zbyt techniczny, ona może nas nie zrozumieć, a my możemy też mieć problemy ze zrozumieniem klienta czy naszych funkcjonalnych. 

 

Super, dzięki za te wskazówki. No i myślę sobie, że żeby się rozwijać w tym kierunku, to trzeba czerpać wiedzę, ale też doświadczenie, najlepiej od praktyków. Tutaj myślę, że możemy naszą rozmowę zamknąć klamrą przypominającą o zbliżającym się Tech-Talku – 18 kwietnia we Wrocławiu. Wszelkie informacje znajdziecie w notatce do odcinka. 

Wiktor, Tomasz, a ja Wam bardzo dziękuję za spotkanie i za tę rozmowę. 

 

TW: Dziękujemy bardzo. 

 

Powiedzcie jeszcze na koniec, gdzie Was można znaleźć w internecie, gdzie możemy słuchaczy odesłać. 

 

WS: Na pewno mnie można znaleźć na LinkedInie. Wiktor Skawiński. 

TW: Ja także tam jestem, mój profil na Linkedinie: Tomasz Wilk. Teraz w ramach społeczności architektów organizujemy kursy z architektury na Politechnice Wrocławskiej, więc być może tam też się zobaczymy. 

 

Super. Oczywiście wszystkie informacje i wszelkie linki będą w notatce do odcinka. Dziękuję Wam jeszcze raz bardzo za rozmowę. 

Do usłyszenia, cześć! 

I to na tyle z tego, co przygotowałem dla Ciebie na dzisiaj. Więcej wartościowych treści znajdziesz we wcześniejszych odcinkach. 

Masz pytania? Napisz do mnie na krzysztof@porozmawiajmyoit.pl lub przez social media. Ja się nazywam Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o S/4HANA i nowoczesnej architekturze SAP. 

Do usłyszenia w następnym odcinku. Cześć!