Architektura MACH vs Digital Experience Platform (DXP) / Dlaczego MACH wygrywa 

Przedstawiliśmy już nasze spostrzeżenia dotyczące niedoskonałości “monolitycznych” Digital Experience Platforms (DXP) oraz przewagi biznesowej i technologicznej, jaką nad DXP daje Architektura MACH .  

Poniżej zebraliśmy najważniejsze zalety i wady zarówno platform DXP, jak i architektury MACH, które pozwolą Wam odpowiedzieć na pytanie, co wybrać i dlaczego mikrousługi i headless w usłudze chmurowej (czytaj MACH) to najlepszy wybór. 

Dlaczego DXP przegrywa, czyli zalety i wady monolitów 

Zalety platformy DXP:  

• Relatywnie stabilne narzędzie używane w największych światowych korporacjach od lat.   
• Wbudowane komponenty i funkcje gotowe do użycia po zainstalowaniu i konfiguracji.  
• Łatwe zarządzanie uprawnieniami i dostępami w całej organizacji dzięki Single Source of Truth (SSoT).   

• Obsługa wielu marek na wielu rynkach i w wielu językach.  
• Struktura drzewiasta interfejsu użytkownika.  
• “Parasol ochronny” znanych brandów, takich jak Adobe, Sitecore, Salesforce, Episerver, Oracle.  

Wady platformy DXP: 

• Bardzo wysoki koszt zakupu, wdrożenia i utrzymania, nie wspominając o kosztach potencjalnych modyfikacji lub głębokich customizacji, które mogą być wręcz nieopłacalne.   
• Skomplikowany i złożony system, trudny w obsłudze, wymagający bardzo wąskiej specjalizacji.  
• Nieelastyczna, zamknięta i mało skalowalna infrastruktura.  
• Architektura stwarzająca spore trudności integracyjne.  
• System ukierunkowany na utrzymanie status quo, aniżeli na rozwój, zmianę czy budowanie przewagi konkurencyjnej.  

• Konieczność zaangażowania dużych i wykwalifikowanych zespołów deweloperskich do nawet niedużych zmian i customizacji.  
• Próg wejścia i krzywa nauczania najwyższa w klasie platform do zarządzania treścią.  
• System obarczony “vendor lock’iem” – silne, techniczne uzależnienie od dostawców platformy.  
• Problemy przy upgrade’ach i migracjach do nowszych i droższych wersji.  
• Zamiast usuwać kreują silosowość.  

• Mglista dokumentacja techniczna oraz realnie niezadowalający support dostawców  
• Wolny time–to–market. 

Nie chcesz zostać w tyle? Przejdź na MACH!

POROZMAWIAJMY

Co sprawia, że MACH wygrywa, czyli zalety i wady architektury mikroserwisów  

Zalety podejścia MACH :

• Mikrousługi i całe spektrum wysokiej jakości serwisów, które możemy dobrać według potrzeb i budżetu (w podejściu best-of-bread lub best-of-budget) i płacić tylko za to, z czego korzystamy.  
• API – siła w możliwościach integracyjnych i “plastyczności” połączeń wewnątrz i “na zewnątrz” systemu.  
• Chmura – jej skalowalność, bezpieczeństwo, stabilność i szybkość działania nieosiągalna dla rozwiązań on-premises.  
• Headless, który pozwala oddzielić frontend od backendu i stworzyć spersonalizowane narzędzie odpowiadające na realne potrzeby użytkowników.  
• Architektura otwarta, podatna na szybkie i zwinne modyfikacje infrastruktury w skali mikro i makro – system przygotowany na zmiany i ciągły rozwój inicjowany “business-driven”.  

• Możliwość redukcji, wymienialności i zastępowalności komponentów oraz (mikro)serwisów i kształtowania architektury w elastyczny sposób.  
• Upgrade’y są w pełni automatyczne i autonomiczne, przez co nie zakłócają integralności systemu.  
• Niski próg wejścia i realny support dostawców SaaS-owych.  
• Brak “vendor lock’a” i konieczności utrzymywania dużych zespołów developerskich   
  po stronie klienta i dostawcy platformy.    
• Spójność wizerunkowa na wielu rynkach, w wielu językach i we wszystkich kanałach komunikacyjnych.  

• Intuicyjny i prosty w zarządzaniu interfejs użytkownika.  
• Szybki time–to–market = szybsze ROI.  
• Sprawdzona i przeprowadzana z sukcesami transformacja do architektury MACH przez największe i najbardziej zaawansowane technologicznie marki, takie jak Netflix, Amazon, Coca-cola, Uber, Etsy, Spotify, Zalando, LEGO, MiT, PUMA, NASA, IBM, Societe Generale.

Wady podejścia MACH: 

• Brak 😉 przy zdecydowaniu się na to rozwiązanie, nie mając wcześniej “zastanej” architektury albo planując przetransformowanie obecnej.    
• Konieczność edukacji przed implementacją. I tu kilka słów wyjaśnienia:  
  
  Ze względu na to, że to rozwiązanie jest relatywnie nowe, może budzić niezrozumienie   
  i rodzić nieporozumienia. I mimo tego, że podejście dojrzało na tyle, że największe firmy zdecydowały się na jego przyswojenie, to nadal wśród tych, którzy rozważają rozmontowanie swoich monolitycznych platform istnieje niesłuszna obawa, że architektura MACH jest niezwykle trudna do osiągnięcia, długotrwała i kosztowna.  
• Nie każda już funkcjonująca infrastruktura z dużym długiem technologicznym może szybko i łatwo przejść transformację do pełnej architektury MACH. Aby w pełni zaadoptować podejście MACH w takim wypadku należałoby postawić nową architekturę obok obecnie działającej i krok po kroku przeprowadzać do niej migrację.   
• Nie każda firma decyduje się na zrezygnowanie z rozwiązania on-premises, co może komplikować założenia architektury MACH i niestety nie wykorzystywać całego potencjału, bezpieczeństwa i mocy obliczeniowej chmury.  

• Headlessowe serwisy czy mikrousługi wymagają przygotowania frontendowego, a więc i pracy u podstaw z klientem oraz większego zaangażowanie developmentu w początkowej fazie transformacji. Po to właśnie, aby dostosować i przygotować front tak, aby spełniał obecne i przyszłe wymagania organizacji i jej klientów.   

• Przed zdecydowaniem się na absorbcję MACH-a, w każdej organizacji należy przeprowadzić rzetelną analizę możliwości i ograniczeń obecnej infrastruktury. To wiąże się z poświęceniem dodatkowego czasu na przygotowanie i zaplanowanie transformacji. Dopiero po fazie takiego consultingu można określić, czy architektura MACH będzie w pełni możliwa do realizacji i czy będzie spełniać postawione przed nią zadania.   

Jak zacząć? Czyli droga w kierunku architektury MACH 

Pierwszym krokiem w kierunku adaptacji architektury MACH jest konsulting. Pozwala on na wyznaczenie obszarów działań, zweryfikowanie celów biznesowych i technologicznych, stworzenie ścieżek użytkownika i połączeń potencjalnej architektury. To również narysowanie roadmapy prowadzącej w kierunku architektury MACH i podzielenie transformacji cyfrowej organizacji na krótsze i przez to mniej wymagające etapy.  

Idąc dalej, możemy zadbać o przygotowanie paczek API, dzięki którym otworzymy nasz system na to, co nie tylko już teraz jest potrzebne, ale na to, co być może jest jeszcze nam nieznane, a co wkrótce będzie wysoce niezbędne i pożądane przez naszych klientów.  

Kolejnym krokiem może być odseparowanie warstwy frontowej od backendu w systemach naszej organizacji, co z kolei uwolni potencjał naszych narzędzi i pozwoli skupić się na kolejnych wyzwaniach biznesowych, a nie na spowalniającej nas, zabetonowanej infrastrukturze IT.   
  
Początki zawsze są trudne. Ale, aby rozpocząć zmianę i ruszyć z miejsca, trzeba postawić ten pierwszy, niekiedy mały krok. Tak, jak zrobiło to kiedyś LEGO, po tym, gdy wprowadzając zestawy klocków “Star Wars” do swojej oferty, cały ich system sprzedażowy przestał funkcjonować. By nie popełnić błędu LEGO, polecamy Waszą transformację zacząć już dziś . 

  

Jeśli masz pytania, chcesz porozmawiać i pogłębić temat architektury MACH, to skontaktuj się z nami!