Persony i role

DataFlow AI jest zaprojektowany wokół czterech głównych person — inżyniera danych, analityka biznesowego, administratora platformy oraz stewarda danych. Każda persona ma w dokumentacji projektowej swojego nazwanego reprezentanta, a interfejs platformy jest adaptacyjny względem roli: układ, widżety, nawigacja i treść zmieniają się tak, aby pasować do pracy, którą dana persona faktycznie wykonuje. Ta strona przedstawia każdą personę, a następnie godzi trzy odrębne słowniki ról istniejące w kodzie.

Cztery persony

Doświadczenie użytkownika platformy zbudowano dla czterech osób. Każda ma nazwanego reprezentanta, dział, próbny adres e-mail oraz kolorowy znacznik roli widoczny w całym interfejsie.

Aktywna persona jest przechowywana w trwałym personaStore Zustand (klucz localStorage dataflow-persona) i odczytywana przy każdym renderowaniu, dzięki czemu panele renderują się ponownie w miejscu po przełączeniu persony — bez konieczności ponownego uwierzytelniania.

Inżynier danych — Anna Kowalska

Anna buduje i utrzymuje ponad 500 potoków danych ETL dla zespołu DWH. Jest zaawansowanym użytkownikiem platformy, pracując codziennie z płótnem wizualnym, SQL-em i Pythonem.

Cele

• Niezawodne potoki danych, które działają zgodnie z harmonogramem bez niespodzianek.
• Szybkie debugowanie, gdy coś zawiedzie w nocy.
• Czysty, wersjonowany w Git kod, który przejdzie przegląd kodu.

Punkty bólu (stan obecny)

• Informatica PowerCenter jest wolna w tworzeniu rozwiązań.
• Brak integracji z Git w starszym oprzyrządowaniu.
• Rozproszone narzędzia rozrzucają jej pracę po wielu niepołączonych aplikacjach.

Obowiązki

• Projektowanie potoków danych we wszystkich trzech trybach — wizualnym, SQL i Python.
• Zarządzanie połączeniami do Teradata, Snowflake, Databricks, SAP HANA, MSSQL i innych.
• Planowanie potoków danych za pomocą wyrażeń cron.
• Debugowanie awarii i stosowanie poprawek sugerowanych przez AI.
• Przegląd kodu i promocja między środowiskami (Dev → Staging → Prod).
• Migracja starszych rozwiązań za pośrednictwem Centrum Migracji.

Adaptacyjny pulpit

Pulpit główny Anny korzysta z układu grid-cols-3 z niebieskim gradientowym banerem powitalnym. Prezentuje PipelineStatusCard (np. „487/500 sprawnych” z segmentowanym zielono-czerwono-żółtym paskiem), RecentFailuresCard z klikalnymi pozycjami awarii, AIInsightsCard z niebieskim lewym obramowaniem i wskazówkami w formie żarówki, QuickActionsBar (Nowy potok / Wyświetl uruchomienia / Design Studio / Czat AI) oraz RecentActivityFeed wraz z 7-dniowym wykresem PipelineHealthTrend.

Kluczowe metryki

Analityk biznesowy — Marek Nowicki

Marek tworzy doraźne ekstrakty danych i raporty. Nie jest programistą, a platformę zbudowano tak, by tak pozostało.

Cele

• Samoobsługowy dostęp do danych bez konieczności programowania.

Punkty bólu (stan obecny)

• Licencja Alteryx jest droga.
• Ograniczona współpraca z resztą zespołu analityki.

Obowiązki

• Budowanie ekstraktów za pomocą czatu AI lub projektanta wizualnego.
• Planowanie potoków danych raportowych.
• Monitorowanie świeżości danych.
• Eksplorowanie katalogu danych poprzez Przeglądarkę danych.

Adaptacyjny pulpit

Pulpit główny Marka korzysta z układu grid-cols-2 ze szmaragdowym banerem gradientowym. Pokazuje MyPipelinesCard (znacznik „5/5”, wiersze ostatniego/następnego uruchomienia), AIChatQuickEntry (pole tekstu swobodnego oraz pigułki szybkich podpowiedzi otwierające AI Copilot), DataFreshnessCard z paskami świeżości dla poszczególnych źródeł, RecentExtractsCard z pobraniami Excel/CSV/Parquet oraz ScheduledPipelinesTable.

Kluczowa metryka

Administrator platformy — Katarzyna Zielińska

Katarzyna zarządza infrastrukturą, bezpieczeństwem i użytkownikami, którzy utrzymują DataFlow AI w działaniu.

Cele

• Stabilna platforma z przewidywalnym czasem dostępności.
• Łatwe skalowanie podczas szczytowego obciążenia (koniec miesiąca).
• Kontrola kosztów względem miesięcznego budżetu.

Punkty bólu (stan obecny)

• Ręczne zarządzanie serwerami.
• Brak elastyczności chmury.

Obowiązki

• Provisioning infrastruktury (Terraform, GKE Autopilot, Cloud SQL).
• Federacja Keycloak i Active Directory.
• Mapowanie ról RBAC (grupy AD → role platformy).
• Rejestracja konektorów i testowanie łączności.
• Konfiguracja monitorowania i alertowania (Grafana, PagerDuty).
• Zarządzanie użytkownikami i obszarami roboczymi.
• Śledzenie kosztów, reagowanie na incydenty i skalowanie.

Adaptacyjny pulpit

Pulpit główny Katarzyny korzysta z układu grid-cols-3 z fioletowym banerem gradientowym. Prezentuje SystemHealthCard (paski CPU/Pamięć/Dysk/Sieć oraz czas dostępności), CostTrackerCard (dziś/miesiąc/budżet z prognozą), ActiveUsersCard (liczba oraz paski dla poszczególnych ról), InfrastructureAlertsCard z przyciskami potwierdzenia, ScalingEventsCard oraz ServiceStatusTable.

Steward danych — Tomasz Wiśniewski

Tomasz zapewnia jakość danych i ład danych w całym majątku danych Polkomtela.

Cele

• Kompletne, godne zaufania pochodzenie danych.
• Ciągłe monitorowanie jakości.
• Wykazywalna zgodność z regulacjami.

Punkty bólu (stan obecny)

• Rozproszone pochodzenie danych rozrzucone po Informatica, Teradata i narzędziach BI.

Obowiązki

• Badanie pochodzenia danych w całym majątku danych.
• Przegląd ładu i zatwierdzanie potoków danych przed wdrożeniem.
• Zarządzanie regułami jakości i ich monitorowanie.
• Utrzymywanie słownika biznesowego.
• Przegląd ścieżki audytu i raportowanie zgodności (mapy danych RODO, inwentarz PII, audyty dostępu).

Adaptacyjny pulpit

Pulpit główny Tomasza korzysta z bursztynowego banera gradientowego i prezentuje kolejkę przeglądu ładu, wyniki jakości oraz punkty wejścia do pochodzenia danych. GovernanceQueueCard wyświetla potoki danych oczekujące na certyfikację, QualityScoreCard pokazuje ogólny procentowy wskaźnik jakości danych z deltą tydzień do tygodnia, a bezpośrednie odnośniki otwierają Eksplorator pochodzenia danych oraz Ścieżkę audytu.

Trzy taksonomie ról

Kod zawiera trzy nakładające się słowniki ról, które nie są w pełni zgodne. Jest to znane źródło zamieszania, dlatego warto powiedzieć to wprost.

1. Persony UX (4)

Warstwa produktowa i UX korzysta z czterech person: engineer, analyst, admin, steward. Sterują one adaptacyjnym względem roli interfejsem oraz strażnikami tras frontendu.

2. Role realmu Keycloak (5–6)

Realm Keycloak dataflow dostarcza sześć ról realmu: org_admin, workspace_admin, developer, analyst, operator, viewer. org_admin jest rolą złożoną, która obejmuje pozostałe pięć. Zauważ, że nie ma roli realmu steward ani engineer — developer zastępuje inżyniera.

Przewodnik administratora opisuje również pięciorolowy widok powiązany z grupami AD:

3. Role RBAC RFI (6 + OPA)

Odpowiedź RFI opisuje bardziej szczegółowy model z sześcioma wbudowanymi rolami plus Open Policy Agent do kontroli dostępu opartej na atrybutach:

Sam backend korzysta z hierarchicznego modelu DataFlowRole — ADMIN(100) > ENGINEER(75) > ANALYST(50) > STEWARD(40) > VIEWER(25) — w którym rola nadaje każde uprawnienie, którego wymagany poziom jest równy jej własnemu lub niższy.

Jak odwzorowują się taksonomie

Trzy słowniki są godzone przez zakodowane na sztywno tabele mapowania w RBACService, KeycloakJwtConverter oraz frontendowym keycloak.ts.

Nie ma persony dla MANAGER, Operator ani Viewer. Rola MANAGER ujawnia się wyłącznie w przepływie przeglądu i zatwierdzania w ramach ładu.

Rozwiązywanie nazw ról na bramie

Brama API odwzorowuje każdy surowy ciąg roli — role realmu, role klienta, nazwy grup, ścieżki grup — na pojedynczą DataFlowRole, przy czym wygrywa najwyższy poziom. Kilka przykładów:

Jeśli JWT nie ma odwzorowywalnych ról, zbiór uprawnień jest pusty, a żądanie zostaje odrzucone — celowy wybór przeciw eskalacji uprawnień. Członkostwo w grupach AD synchronizuje się automatycznie z propagacją trwającą pięć minut lub krócej.

Zakres obszaru roboczego i środowiska

RBAC zagnieżdża się w hierarchii:

Organization
  └─ Workspace
       └─ Environment (Dev / Staging / Prod)
            └─ Resources (Pipelines, Connections, Datasets)
                 └─ Permissions (R / W / X / Admin)

Każdy obszar roboczy jest izolowanym środowiskiem z własnymi definicjami potoków danych, połączeniami, regułami jakości, politykami ładu oraz grafami pochodzenia danych. Użytkownik może należeć do wielu obszarów roboczych i przełącza się między nimi za pomocą selektora obszaru roboczego w górnym pasku.

Persona → widoczność nawigacji

Pasek boczny jest adaptacyjny względem roli: elementy, których dana persona nie może użyć, są całkowicie ukryte, a nie wyszarzone.

Samo filtrowanie nawigacji okazało się niewystarczające — późniejsze działania naprawcze dodały strażnika ProtectedRoute, moduł RBAC tras permissions.ts oraz stronę AccessDenied, aby do adresów URL nie dało się dotrzeć przez zwykłe ich wpisanie. Frontendowy RBAC dotyczy wyłącznie UX; prawdziwe egzekwowanie odbywa się po stronie serwera na bramie oraz w każdej usłudze.

Dokąd dalej

• Ścieżki użytkownika — indeks głównych ścieżek od początku do końca wraz z mapami ASCII.
• Przewodnik inżyniera danych — wdrożenie, codzienny przepływ pracy, budowanie i debugowanie potoków danych.
• Przewodnik analityka i stewarda — samoobsługowe ekstrakty, eksploracja katalogu oraz ład danych.
• Przewodnik administratora — konfiguracja platformy, codzienne operacje oraz migracja starszych rozwiązań.