Governance - rozwijaj platformę Microsoft bez utraty kontroli

Dlaczego governance staje się potrzebny?

Początkowo raport lub aplikacja często powstają z inicjatywy jednej osoby. Rozwiązują konkretny problem, zdobywają kolejnych użytkowników i stopniowo stają się częścią codziennej pracy. Z czasem mogą obsługiwać proces, którego zatrzymanie wpływa na cały dział.

Jeżeli wraz ze wzrostem znaczenia rozwiązania nie rozwijają się zasady jego utrzymania, pojawiają się problemy:

• raporty przedstawiają różne wartości tych samych KPI;
• aplikacje i przepływy nie mają wskazanego właściciela;
• istotne połączenia zależą od konta pracownika, który odchodzi z firmy;
• zmiany są wprowadzane bezpośrednio na produkcji;
• dane są udostępniane szerzej, niż wymaga tego proces;
• koszty rosną, ale trudno wskazać ich źródło;
• awarie są zauważane dopiero wtedy, gdy zgłoszą je użytkownicy.

Governance pomaga rozpoznać takie zależności i ustalić zasady odpowiednie do skali oraz znaczenia rozwiązania.

Sześć obszarów zarządzania platformą

Bezpieczeństwo

Tożsamość, role, RLS, dostęp do środowisk, zasobów i danych wrażliwych.

Polityki i środowiska

Segmentacja środowisk, DLP, Managed Environments i zasady tworzenia rozwiązań.

Monitoring

Inventory, usage, ownership, błędy, zależności i cykl życia aplikacji oraz flow.

Licencjonowanie

Kontrola licencji, capacity i rzeczywistego wykorzystania platformy.

ALM i deployment

Rozdzielenie development/test/production, solutions i kontrolowane wdrożenia.

Ownership

Jasna odpowiedzialność za aplikacje, przepływy, raporty, dane i produkty analityczne.

1. Bezpieczeństwo i dostęp do danych

Właściwe informacje dla właściwych osób

Bezpieczeństwo zaczyna się od tożsamości użytkownika, ale obejmuje również uprawnienia do środowisk, aplikacji, raportów, źródeł danych i integracji.

Microsoft Entra ID wspiera zarządzanie tożsamością, a mechanizmy poszczególnych usług określają zakres dostępu. W Power BI mogą to być role w obszarach roboczych i zabezpieczenia na poziomie wierszy, czyli RLS. W Dataverse - role bezpieczeństwa i uprawnienia do rekordów. W usługach Azure - uprawnienia do zasobów oraz dostępu do danych.

Te ustawienia powinny tworzyć spójny model. Samo ograniczenie widoczności raportu nie wystarczy, jeżeli użytkownik ma szerszy dostęp do danych przez inne narzędzie.

W praktyce warto ustalić:

• kto może tworzyć, edytować, publikować i udostępniać rozwiązania;
• jakie dane mogą widzieć poszczególne grupy użytkowników;
• jak obsługiwać dostęp partnerów i użytkowników zewnętrznych;
• kto zatwierdza dostęp do danych wrażliwych;
• jak często przeglądać i odbierać zbędne uprawnienia.

2. Polityki i środowiska

Jasne miejsce do eksperymentowania i pracy produkcyjnej

Strategia środowisk określa, gdzie powstają prototypy, gdzie prowadzone są testy i gdzie działają rozwiązania wykorzystywane biznesowo. Powinna uwzględniać zespoły, rodzaje danych oraz znaczenie procesów.

W Power Platform polityki danych, często określane jako DLP, pomagają kontrolować wykorzystanie konektorów i ich łączenie w aplikacjach oraz przepływach. Nie zastępują jednak uprawnień w systemach źródłowych ani pełnej ochrony informacji.

Możliwości zarządzania środowiskami, w tym Managed Environments, mogą wspierać egzekwowanie zasad i zwiększać widoczność wykorzystania platformy. Ich zastosowanie należy dopasować do potrzeb organizacji oraz wymagań licencyjnych.

Podobnej dyscypliny wymagają obszary robocze Fabric i Power BI oraz zasoby Azure. Są to różne mechanizmy organizacji zasobów, dlatego wspólna polityka powinna określać cel, a konfiguracja uwzględniać specyfikę każdej usługi.

3. Monitoring i widoczność środowiska

Wiedz, co działa, kto z tego korzysta i gdzie pojawiają się problemy

Podstawą zarządzania jest aktualna inwentaryzacja. Organizacja powinna wiedzieć, jakie aplikacje, przepływy, raporty i procesy danych istnieją, kto za nie odpowiada oraz jakie mają zależności.

Monitoring obejmuje zarówno działanie techniczne, jak i wykorzystanie biznesowe. Poprawnie wykonujący się przepływ może nie być już potrzebny, a rzadko otwierany raport może nadal mieć kluczowe znaczenie przy zamknięciu miesiąca.

Warto obserwować:

• błędy przepływów, integracji i odświeżania danych;
• czas wykonania oraz opóźnienia;
• aktywność użytkowników i wykorzystanie rozwiązań;
• zasoby bez właściciela lub z nieaktualnymi połączeniami;
• zależności między źródłami, modelami, raportami i aplikacjami;
• obciążenie platformy i dostępność zasobów.

Każdy istotny alert powinien mieć odbiorcę i określoną ścieżkę reakcji. Sam dashboard administracyjny nie zapewnia jeszcze obsługi incydentów.

4. Licencjonowanie i koszty

Kontroluj koszt całego rozwiązania

Koszt platformy obejmuje licencje użytkowników, zasoby obliczeniowe, przechowywanie danych oraz wykorzystanie poszczególnych usług. W architekturze modułowej koszty jednego procesu mogą być rozłożone między Power Platform, Fabric i Azure.

Dlatego przegląd powinien uwzględniać zarówno przypisane licencje, jak i rzeczywisty sposób korzystania z rozwiązania. Warto sprawdzać, które aplikacje są aktywne, jakie zadania zużywają najwięcej zasobów i kiedy występują największe obciążenia.

W Fabric aplikacja Capacity Metrics pomaga analizować wykorzystanie pojemności obliczeniowej. Takie informacje pozwalają ocenić, czy problem wymaga optymalizacji, zmiany harmonogramu, rozdzielenia obciążeń czy zwiększenia dostępnych zasobów.

Celem jest przewidywalny koszt przy zachowaniu jakości pracy użytkowników. Niewykorzystana licencja i przeciążona platforma wymagają innych działań, choć oba problemy dotyczą zarządzania kosztami.

5. ALM i kontrolowane wdrożenia

Zarządzaj rozwiązaniem od pierwszej wersji do wycofania

ALM, czyli zarządzanie cyklem życia aplikacji i rozwiązań, obejmuje rozwój, testowanie, wdrażanie, utrzymanie oraz zakończenie użytkowania.

Rozdzielenie środowisk development, test i production pozwala sprawdzać zmiany przed udostępnieniem ich użytkownikom. W Power Platform można wykorzystywać rozwiązania, czyli solutions, oraz mechanizmy wdrażania. Fabric i Power BI udostępniają własne możliwości zarządzania wersjami i przenoszenia obsługiwanych elementów między etapami.

Kontrolowane wdrożenie powinno obejmować:

• identyfikację wersji i zakresu zmiany;
• testy funkcjonalne, uprawnień i integracji;
• konfigurację połączeń oraz parametrów środowiska;
• zatwierdzenie odpowiednie do znaczenia rozwiązania;
• sposób postępowania w razie niepowodzenia;
• sprawdzenie działania po publikacji.

Automatyczny pipeline ułatwia wdrożenie, ale nie zastępuje testów ani planu przywrócenia działania.

6. Ownership i ciągłość działania

Każde rozwiązanie potrzebuje odpowiedzialnych osób

Właściciel techniczny i właściciel biznesowy pełnią różne role. Pierwszy odpowiada za działanie i utrzymanie, drugi za cel procesu, wymagania oraz ocenę przydatności rozwiązania.

Dla istotnej aplikacji, raportu lub produktu danych powinno być wiadomo:

• kto podejmuje decyzje o zmianach;
• kto reaguje na awarie;
• kto odpowiada za jakość danych i definicje KPI;
• kto kontroluje koszty i dostęp;
• kto przejmuje obowiązki podczas nieobecności lub odejścia pracownika.

Offboarding powinien obejmować przegląd własności zasobów, połączeń, uprawnień i zależności od kont osobistych. Samo przeniesienie własności aplikacji może nie wystarczyć, jeżeli jej przepływy nadal korzystają z połączeń poprzedniego właściciela.

Governance w podejściu modułowym

Gdy rozwiązanie składa się z wielu usług, trzeba zarządzać również ich współpracą.

Przykładowy proces reklamacyjny może wykorzystywać Power Apps, Dataverse, Power Automate i Power BI. Każdy komponent ma własne uprawnienia i sposób utrzymania, ale użytkownik ocenia działanie całego procesu.

Zmiana pola w bazie może wpłynąć na aplikację, przepływ i raport. Zmiana uprawnień może zatrzymać integrację. Uruchomienie nowej analizy może zwiększyć obciążenie wspólnych zasobów.

Dlatego governance powinien obejmować całe rozwiązanie biznesowe: jego komponenty, zależności, właścicieli i sposób obsługi problemów. Pozwala to rozwijać moduły bez tracenia kontroli nad procesem, który wspólnie realizują.

Governance nie powinien blokować rozwoju

Dobrze zaprojektowane zasady wyjaśniają użytkownikom, gdzie mogą eksperymentować, jakie dane mogą wykorzystywać i co jest potrzebne, aby udostępnić rozwiązanie innym.

Zakres kontroli powinien odpowiadać znaczeniu procesu. Prototyp na danych testowych może wymagać prostych zasad. Aplikacja obsługująca zamówienia lub dane wrażliwe potrzebuje dokładniejszej oceny, testów i planu utrzymania.

Praktyczne podejście rozróżnia:

• eksperymenty i prototypy - przestrzeń do sprawdzania pomysłów w określonych granicach;
• rozwiązania zespołowe - wskazany właściciel, zasady dostępu i podstawowy monitoring;
• rozwiązania krytyczne - kontrolowane wdrożenia, dokumentacja, testy i uzgodniona obsługa incydentów.

Zespół centralny może dostarczać standardy, wzorce i wsparcie, a zespoły biznesowe rozwijać rozwiązania w ramach ustalonych zasad.

Wykorzystaj natywne możliwości administracyjne

Power Platform Admin Center stanowi punkt wyjścia do zarządzania środowiskami, ustawieniami, politykami i dostępnymi informacjami administracyjnymi Power Platform.

Dla Fabric i Power BI potrzebne są również właściwe narzędzia administracyjne, monitoring wykorzystania i analiza pojemności. Zasoby Azure wymagają zarządzania w ramach mechanizmów tej platformy.

Warto najpierw wykorzystać możliwości dostępne w usługach, a dodatkową inwentaryzację i raportowanie budować tam, gdzie istnieje konkretna luka. Zakres informacji, historia i dostępność funkcji różnią się między produktami - jeden panel nie musi obejmować całej architektury.

Minimalny standard governance

Na początek warto ustalić wspólny zestaw zasad obejmujący:

• strategię środowisk i nazewnictwa - jasne przeznaczenie oraz sposób organizacji zasobów;
• polityki danych i konektorów - dopuszczalne integracje i sposób obsługi wyjątków;
• model dostępu - role, grupy użytkowników i regularny przegląd uprawnień;
• ownership i offboarding - odpowiedzialność biznesową, techniczną i zastępstwa;
• ALM i wdrożenia - sposób testowania, publikacji i reagowania na nieudaną zmianę;
• inwentaryzację i monitoring - widoczność zasobów, zależności, błędów oraz wykorzystania;
• przegląd licencji i pojemności - kontrolę kosztów oraz zapotrzebowania na zasoby;
• klasyfikację krytyczności - wymagania dopasowane do wpływu rozwiązania na biznes.

Standard powinien mieć właściciela i być regularnie aktualizowany. Wraz z rozwojem platformy zmieniają się procesy, skala wykorzystania i potrzeby użytkowników.

Od czego zacząć?

Pierwszym krokiem jest ocena obecnego środowiska: dostępnych zasobów, właścicieli, uprawnień, polityk i kosztów. Następnie warto wskazać procesy o największym znaczeniu i zależności, które mogą zagrozić ich ciągłości.

Na tej podstawie można przygotować plan działań: uporządkować odpowiedzialność, zabezpieczyć kluczowe połączenia, wdrożyć monitoring i ustalić standard nowych rozwiązań. Kolejne usprawnienia powinny wynikać z realnego wykorzystania platformy.