Citizen developer to pracownik działu biznesowego, który bez przygotowania programistycznego buduje aplikacje i automatyzacje na platformie low-code. Zarządzanie takim rozwojem nie polega na jego blokowaniu, tylko na wyznaczeniu ram: kto może tworzyć, w jakim środowisku, z jakimi danymi i jak aplikacja przechodzi od prototypu do produkcji.
Na skróty
Czego dowiesz się z artykułu:
- Kim jest citizen developer i skąd biorą się ryzyka rozwoju bez nadzoru
- Jakie role są potrzebne, żeby ład nad low-code działał
- Jak ustawić środowiska, zasady dotyczące danych i cykl życia aplikacji
- Od czego zacząć, gdy aplikacje już powstają bez wiedzy IT
Dla kogo jest ten artykuł:
- Kierownicy IT i architekci odpowiedzialni za platformy low-code
- Administratorzy Power Platform i zespoły bezpieczeństwa
- Kierownicy działów biznesowych, w których powstają własne aplikacje
Czas czytania: 7 minut
Kim jest citizen developer
Według aws.amazon.com low-code to podejście do tworzenia oprogramowania, w którym aplikacje powstają przy minimalnej ilości kodu, z gotowych narzędzi, komponentów i szablonów. Użytkowników biznesowych z niewielkim doświadczeniem programistycznym albo bez niego, którzy sami budują aplikacje, nazywa się tam citizen developerami. Dokumentacja Microsoft Power Platform na learn.microsoft.com używa szerszego pojęcia „twórcy” (makers), obejmującego zarówno citizen developerów, jak i zawodowych programistów.
Siła tego modelu jest zarazem jego ryzykiem. Pracownik działu zakupów, który sam zbuduje aplikację do zatwierdzania zamówień, zna proces lepiej niż ktokolwiek w IT. Nie musi jednak wiedzieć, że jego aplikacja łączy dane kadrowe z zewnętrzną usługą albo że po jego odejściu nikt nie będzie umiał jej poprawić. Przewodnik Microsoft po rolach w adopcji Power Platform wymienia skutki słabego ładu wprost: luki bezpieczeństwa, wycieki danych, niezgodność z regulacjami, powielanie pracy i projekty niezgodne z celami organizacji.
Kto za co odpowiada
Microsoft zaleca opisanie odpowiedzialności macierzą RACI (odpowiedzialny, rozliczany, konsultowany, informowany). Przewodnik adopcji Power Platform wymienia między innymi takie role:
- Centrum doskonałości (Center of Excellence, CoE) — zespół, który wyznacza standardy, prowadzi szkolenia i wspiera twórców. Dokumentacja nazywa je też centrum umożliwiania (Center of Enablement), bo jego zadaniem jest rozwój, a nie sama kontrola. Na jego czele stoi lider CoE.
- Sponsor z kierownictwa — wyznacza kierunek, zapewnia zasoby i komunikuje wizję.
- Właściciel produktu Power Platform — odpowiada za kierunek rozwoju platformy, plan zmian i ramy ładu.
- Administratorzy platformy i środowisk — konfigurują zabezpieczenia, monitorują platformę i wdrażają ograniczenia.
- Zespół bezpieczeństwa informacji i zgodności — sprawdza, czy platforma spełnia polityki wewnętrzne i wymagania regulacyjne.
- Twórcy (makers) — budują rozwiązania w wyznaczonych ramach.
- Ambasadorzy (champions) — entuzjaści w działach biznesowych, którzy przekazują CoE informację zwrotną o tym, co działa, a co nie.
Na początku jedna osoba może łączyć kilka ról. Przewodnik zaznacza, że wraz z dojrzewaniem adopcji role trzeba doprecyzować i rozdzielić.
Trzy mechanizmy ładu
Strategia środowisk. Według Microsoft wiele organizacji zaczyna od jednego wspólnego środowiska domyślnego, w którym każdy tworzy i udostępnia aplikacje. Microsoft zaleca odejście od tego modelu. Funkcja routingu środowiska domyślnego (default environment routing) kieruje twórców do ich osobistych środowisk deweloperskich. Środowiska testowe (sandbox) służą do testów i budowania wydań, a produkcyjne do pracy, od której zależy organizacja. Grupy środowisk pozwalają objąć te same reguły wiele środowisk naraz.
Zasady dotyczące danych. Konektory to sposób, w jaki aplikacja sięga do danych, od poczty po system ERP. Zasady dotyczące danych (data policies) w centrum administracyjnym Power Platform pozwalają zablokować cały konektor albo jego wybrane akcje. Twórca nie zapisze wtedy aplikacji ani przepływu z zablokowanym konektorem, a istniejące zasoby, które go używają, zostaną wstrzymane. Każdą zmianę zasad warto więc najpierw przeanalizować pod kątem działających aplikacji.
Cykl życia aplikacji (ALM). Aplikacja, od której zależy proces, potrzebuje wersji, testów i kontrolowanego wdrożenia. W Power Platform służą do tego rozwiązania (solutions), przenoszone między środowiskami przez eksport i import, oraz potoki (pipelines), które promują zasoby z rozwoju do testów i produkcji. Dokumentacja zaleca, żeby źródłem prawdy dla komponentów była kontrola wersji, a wszystkie środowiska uczestniczące w ALM miały bazę Dataverse.
Od czego zacząć
- Inwentaryzacja. Ustal, kto już tworzy aplikacje i z jakich konektorów korzysta. Zestaw CoE Starter Kit nie jest już aktywnie rozwijany, a jego główne funkcje są dostępne w centrum administracyjnym Power Platform, więc punktem wyjścia są wbudowane raporty.
- Role przed regułami. Wyznacz właściciela platformy i lidera CoE, zanim powstaną pierwsze zasady.
- Środowisko domyślne. Obejmij je zasadami dotyczącymi danych i przekieruj twórców do środowisk deweloperskich.
- Ścieżka do produkcji. Zdefiniuj przejście „prototyp — test — produkcja” dla aplikacji, od których zależy proces biznesowy.
- Społeczność twórców. Przewodnik Microsoft wymienia tu szkolenia i dokumentację dla twórców, bibliotekę zasobów, takich jak własne konektory, oraz wewnętrzną społeczność ambasadorów.
Czytaj także
- Low-code/no-code — kiedy to dobry wybór dla firmy — kiedy platforma, a kiedy programowanie
- Bezpieczeństwo aplikacji low-code w organizacji — lista kontrolna zabezpieczeń
- Power Automate w automatyzacji procesów firmowych — wdrożenie automatyzacji krok po kroku
Rozwijaj kompetencje
Temat rozwijają szkolenia Citizen Development — tworzenie aplikacji bez kodowania oraz Low-Code/No-Code — Power Platform, Mendix, OutSystems. Pierwsze obejmuje zasady citizen development, zarządzanie danymi, uprawnieniami i cyklem życia aplikacji, drugie porównanie platform oraz projektowanie modelu ładu i centrum doskonałości. Skontaktuj się z nami, żeby dopasować zakres do swojego zespołu.
Najczęściej zadawane pytania (FAQ)
Czym jest low-code?
Według aws.amazon.com low-code to podejście, w którym aplikacje powstają przy minimalnej ilości kodu, z gotowych narzędzi, komponentów i szablonów. Dzięki temu aplikacje mogą budować także specjaliści z działów biznesowych, a zawodowi programiści — według tej samej strony — korzystają z takich narzędzi przy powtarzalnych zadaniach.
Jakie są platformy low-code?
Platforma low-code łączy edytor aplikacji, automatyzację przepływów pracy, konektory do systemów firmowych i narzędzia administracyjne. Przykładem jest Microsoft Power Platform z Power Apps, Power Automate i Copilot Studio. Przy wyborze platformy warto sprawdzić nie tylko edytor, ale też mechanizmy ładu: środowiska, zasady dotyczące danych i obsługę cyklu życia aplikacji.
Czym różni się low-code od no-code?
AWS zaznacza, że low code bywa określany jako „low code or no code”, i opisuje to wyrażenie jako ogólną nazwę narzędzi, które pomagają użytkownikom biznesowym projektować i budować aplikacje. W ocenie autora różnica dotyczy przede wszystkim tego, czy platforma przewiduje dopisanie własnego kodu, gdy gotowe elementy nie wystarczą. Z punktu widzenia ładu obie grupy wymagają tych samych zasad.
Jak zacząć wdrożenie Power Platform w firmie?
Zacznij od celów i ról: kto jest właścicielem platformy, kto ją administruje i kto wspiera twórców. Następnie zabezpiecz środowisko domyślne zasadami dotyczącymi danych, przygotuj środowiska deweloperskie, testowe i produkcyjne, a pierwsze aplikacje produkcyjne przeprowadź przez potok wdrożeniowy. Microsoft opisuje te kroki w przewodniku adopcji Power Platform.