W firmach często spotykam dwa skrajne odruchy. Pierwszy brzmi: „zróbmy to w korporacyjnym systemie, bo jest zatwierdzony”. Drugi: „napiszmy szybko własną aplikację, będzie prościej”. Oba mogą być dobre — i oba potrafią stworzyć kłopot, jeśli wybierzemy je zanim zrozumiemy zadanie.
Ja zaczynam od pytania, które brzmi mniej technologicznie: kto ma z tego korzystać, jak często, na jakich danych i kto będzie dbał o rozwiązanie, gdy autor projektu zajmie się czymś innym?
Kiedy lepiej pasuje Power Platform?
Jeśli firma już pracuje w ekosystemie Microsoft 365, a problem dotyczy wewnętrznego formularza, obiegu zatwierdzeń lub prostej aplikacji dla pracowników, Power Apps i Power Automate mogą skrócić drogę od potrzeby do użytecznego narzędzia. Zespół może pracować w znanym środowisku, a administratorzy mają do dyspozycji mechanizmy środowisk, ról i polityk połączeń.
To nie znaczy, że każda aplikacja „low-code” jest automatycznie tania i bezpieczna. Trzeba sprawdzić licencje, źródła danych, sposób udostępniania oraz to, kto zarządza środowiskiem. Microsoft opisuje w dokumentacji Dataverse m.in. role, granice środowisk i kontrolę dostępu. Dla użytkownika biznesowego ważny wniosek jest prosty: nawet narzędzie łatwe do zbudowania potrzebuje właściciela i zasad.
SharePoint, Dataiku i inne narzędzia mają swoje zadania
SharePoint dobrze sprawdza się jako miejsce na dokumenty, wspólną wiedzę i proste procesy powiązane z pracą zespołu. Nie traktowałbym go jednak jako domyślnego zamiennika każdej aplikacji. Gdy pracownicy zaczynają prowadzić tę samą informację w kilku listach, arkuszach i prywatnych kopiach, warto wrócić do projektu procesu.
Dataiku może być sensownym środowiskiem, gdy w centrum są dane, przygotowanie analiz i współpraca między osobami biznesowymi oraz technicznymi. Jeśli potrzebny jest głównie prosty formularz dla kilku osób, pełna platforma analityczna może być przerostem formy. Z drugiej strony ręcznie sklejony skrypt nie zastąpi środowiska pracy, jeśli rozwiązanie wymaga współdzielenia, nadzoru i powtarzalnych procesów.
Kiedy napisać coś własnego?
Własny kod rozważam wtedy, gdy proces ma nietypowe reguły, musi połączyć kilka systemów albo gotowa platforma utrudnia ważną część doświadczenia użytkownika. Mała aplikacja w Pythonie i FastAPI może udostępnić potrzebne API. Kontener Docker pomaga spakować aplikację wraz z jej środowiskiem, ale sam kontener nie zapewnia monitoringu, kopii zapasowych, kontroli dostępu ani dyżuru osoby, która naprawi awarię.
Podobnie prosta strona w PHP — jak mój projekt PulseVote Live — może być dobrym wyborem dla ograniczonego, jasno opisanego zastosowania. Własne rozwiązanie daje swobodę, ale wraz z nią przychodzą aktualizacje, testy, bezpieczeństwo, hosting i odpowiedzialność za utrzymanie. Koszt nie kończy się w dniu, kiedy działa pierwsza wersja.
Pięć pytań przed wyborem
- Czy zadanie jest podobne do tego, co organizacja już robi w swoich systemach?
- Czy znamy liczbę użytkowników, wrażliwość danych i potrzebne uprawnienia?
- Kto będzie właścicielem rozwiązania i pomoże użytkownikom po wdrożeniu?
- Jak często zmienią się reguły procesu i kto może te zmiany wprowadzać?
- Czy istnieje prosty sposób, by wycofać zmianę, gdy test pokaże, że nie pomaga?
Jeśli odpowiedzi są niejasne, zaczynam od krótkiego prototypu i rozmowy z przyszłymi użytkownikami. Dopiero po tym porównuję platformę low-code, narzędzie do pracy z danymi i własny kod. Celem nie jest wybranie najbardziej imponującej technologii. Celem jest rozwiązanie, które zespół rozumie, firma potrafi nadzorować, a ktoś będzie chciał utrzymywać.