Composable Microsoft Platform: rozwijaj platformę etapami

Co oznacza composable enterprise?

Composable enterprise to podejście do budowy środowiska IT z elementów, które mają jasno określone zadania i uzgodnione sposoby współpracy. Zamiast umieszczać procesy, dane i interfejsy w jednym rozbudowanym rozwiązaniu, organizacja może rozwijać osobno aplikacje biznesowe, integracje, analitykę oraz automatyzację.

Nie oznacza to jednak, że każdy ekran czy funkcja musi być osobną usługą. Granice modułów powinny odpowiadać rzeczywistym odpowiedzialnościom. Moduł obsługi reklamacji może mieć własny interfejs i reguły procesu, ale nie powinien samodzielnie utrzymywać drugiej, niezależnej wersji danych klienta, jeśli źródłem tych danych pozostaje CRM.

W podejściu modułowym korzyścią nie jest sama liczba komponentów. Liczy się to, czy zmianę w jednym obszarze można wprowadzić bez nieprzewidzianych skutków w pozostałych oraz czy organizacja wie, kto odpowiada za każde połączenie.

Najpierw odpowiedzialności, potem technologie

Przed wyborem produktów warto rozpisać, które systemy odpowiadają za zapis danych, gdzie przebiega logika procesu i jak inne elementy mają otrzymywać aktualne informacje. Dla przykładu system ERP może pozostać miejscem obsługi zamówień, a nowa aplikacja jedynie udostępniać pracownikowi prostszy sposób wykonania wybranych czynności.

Kluczowe są tu trzy decyzje: kto jest właścicielem danych, przez jaki interfejs systemy się komunikują oraz co dzieje się, gdy jedno z połączeń przestaje działać. Bez tych uzgodnień modułowość szybko sprowadza się do kolejnych integracji punkt-punkt, których nikt nie potrafi utrzymać.

Jaką rolę mogą pełnić usługi Microsoft?

Ekosystem Microsoft pozwala połączyć gotowe usługi, lecz nie wymaga wdrożenia wszystkich naraz. Przykładowy podział odpowiedzialności może wyglądać następująco:

• Microsoft Fabric - integracja i analiza danych z różnych źródeł. OneLake ułatwia ich udostępnianie na potrzeby analityki; wybór Lakehouse lub Warehouse zależy od sposobu przetwarzania i pracy zespołu.
• Power BI - modele semantyczne i raporty wykorzystujące uzgodnione definicje wskaźników. Warstwa raportowania nie powinna zastępować systemu transakcyjnego.
• Power Apps - interfejsy dla konkretnych zadań, np. rejestracji zgłoszeń lub obsługi procesu zatwierdzania. Aplikacja może korzystać z danych i funkcji udostępnionych przez inne systemy.
• Power Automate - automatyzacja etapów procesu, powiadomień i integracji obsługiwanych przez dostępne konektory. Krytyczne przepływy wymagają przemyślanego modelu właścicielstwa oraz obsługi błędów.
• Usługi Azure - integracja przez API, kolejki i komunikaty, gdy potrzebna jest większa kontrola nad komunikacją, odpornością lub logiką rozwiązania.

Rola sztucznej inteligencji (AI) pojawia się tam, gdzie istnieje konkretne zadanie: wyszukiwanie informacji w dokumentacji, klasyfikacja zgłoszeń lub wsparcie pracownika w podjęciu decyzji. Model AI powinien korzystać z danych i uprawnień odpowiednich do tego zadania, a jego wynik nie musi automatycznie uruchamiać zmian w systemach.

Przykład: od zgłoszenia reklamacji do raportu

Wyobraźmy sobie firmę, w której reklamacje klientów są obsługiwane w ERP, ale pracownicy terenowi potrzebują prostego formularza. Power Apps może udostępniać interfejs zgłoszenia. Automatyzacja w Power Automate albo usługa integracyjna przekazuje dane do ERP przez zatwierdzony mechanizm, a ERP pozostaje systemem odpowiedzialnym za status reklamacji.

Osobno można pobierać historię zgłoszeń i dane o realizacji do warstwy analitycznej. Power BI pokazuje wówczas czas obsługi, liczbę ponownych zgłoszeń czy opóźnienia według produktu. Jeśli firma korzysta z Fabric, dane te mogą zostać przygotowane we wspólnej warstwie analitycznej; nie jest to jednak wymóg samego podejścia composable.

Przy takim podziale zmiana formularza nie powinna wymagać przebudowy raportowania, a nowy raport nie ingeruje w mechanizm zapisu reklamacji. Warunek jest jeden: identyfikator zgłoszenia, znaczenie statusów i zasady aktualizacji muszą być uzgodnione pomiędzy komponentami.

Granice, bez których moduły przestają współpracować

Rozdzielenie odpowiedzialności zmniejsza część zależności, ale tworzy nowe punkty styku. Dlatego architektura potrzebuje wspólnych zasad, zanim liczba aplikacji i przepływów zacznie rosnąć:

• Kontrakty integracyjne. API i zdarzenia powinny mieć uzgodnione formaty, sposób wersjonowania oraz obsługę błędów i ponowień. Powtórzony komunikat nie może np. bez kontroli utworzyć drugiego zamówienia.
• Tożsamość i dostęp. Microsoft Entra ID może wspierać zarządzanie tożsamościami, ale uprawnienia do danych i czynności nadal trzeba określić w poszczególnych usługach.
• Governance i ochrona danych. W Power Platform polityki danych pomagają ograniczać niedozwolone połączenia między konektorami. Nie zastępują jednak właściwych uprawnień w systemach źródłowych.
• Utrzymanie i zmiany. Właściciel komponentu, monitoring, środowiska testowe i proces wdrożenia muszą być znane. W Power Platform rozwiązania (solutions) wspierają zarządzanie cyklem życia aplikacji i przepływów.

Przy kilku modułach brak tych zasad bywa mało widoczny. Problem pojawia się później, gdy przepływ zależy od konta byłego pracownika, API zmieni strukturę odpowiedzi lub raport korzysta z danych o innym znaczeniu niż aplikacja operacyjna.

Jak rozwijać platformę etapami?

Najrozsądniej zacząć od jednego procesu, w którym obecne zależności rzeczywiście utrudniają pracę. Nie trzeba równocześnie przenosić wszystkich danych, przebudowywać ERP i uruchamiać kompletnej platformy analitycznej.

1. Ustal problem i systemy odpowiedzialne za dane. Zidentyfikuj ręczne operacje, miejsca powielania informacji i wymagane rezultaty.
2. Zaprojektuj granice pierwszego modułu. Określ uprawnienia, sposób wymiany danych, właściciela oraz zachowanie w przypadku awarii integracji.
3. Sprawdź cały proces, a nie tylko ekran aplikacji. Przetestuj zapis, aktualizację statusu, obsługę błędów i zgodność wyników raportowych. Dopiero potem rozszerzaj rozwiązanie.

Modułowość nie zawsze będzie tańsza. Dodatkowe usługi, integracje, licencje i monitoring mają własny koszt. Dla niewielkiego, stabilnego rozwiązania prostsza architektura może okazać się lepszym wyborem niż rozbudowany zestaw osobno utrzymywanych komponentów.

Najczęstsze pytania

Dokumentacja Microsoft

Więcej o projektowaniu usług, zarządzaniu danymi i wdrażaniu komponentów opisuje dokumentacja Microsoft Learn:

• Style architektury w Azure - różne sposoby podziału odpowiedzialności i ich konsekwencje.
• OneLake w Microsoft Fabric - wspólna warstwa danych dla analityki.
• Solutions w Power Platform - komponenty i zarządzanie cyklem życia rozwiązania.
• Polityki danych w Power Platform - kontrola wykorzystania konektorów i przepływu danych.

Powiązane materiały