„Aplikacja działa.” Często słychać to zdanie chwilę po tym, jak ktoś zbudował coś w narzędziu AI. I to prawda. Klikasz, coś się dzieje, pojawiają się dane. Tyle że „działa” na własnym ekranie znaczy coś innego niż „działa w codziennej pracy firmy”.
Aplikacja jest gotowa do pracy w firmie, gdy zespół może na niej polegać także wtedy, gdy osoba, która ją zbudowała, jest na urlopie. Gdy coś się zmienia. Gdy ktoś odchodzi z firmy. Gdy ktoś pyta, kto i kiedy co zmienił.
Spisaliśmy, po czym to poznajemy. Lista obowiązuje niezależnie od tego, w czym aplikację zbudowano.
1. Zna ludzi w firmie
Aplikacja gotowa do pracy nie ma własnego zarządzania użytkownikami z własnymi hasłami. Ludzie logują się kontami, które i tak mają. Kto odchodzi z firmy i zostaje usunięty z workspace, traci też dostęp do aplikacji, i nikt nie musi o tym pamiętać.
W Openbase.one logujecie się przez Google Workspace, Microsoft Entra ID, kod z e-maila albo hasło. Administratorzy mogą wyłączyć hasła dla całego workspace.
2. Uprawnienia działają przy każdym dostępie
Ukryty przycisk to nie jest model uprawnień. Jeśli przełożony nie powinien widzieć wynagrodzeń, te dane w ogóle nie mogą do niego trafić, niezależnie od tego, jaką drogą o nie pyta.
Dlatego aplikacje w Openbase.one nie piszą SQL. Każdy dostęp do danych przechodzi przez SDK i bramę, która sprawdza każde wywołanie względem workspace, aplikacji i uprawnień. Workspace’y są od siebie oddzielone na poziomie bazy danych.
3. Sprawdzana jest każda wersja, nie tylko pierwsza
Pierwszej wersji aplikacji zwykle przygląda się ktoś uważnie. Piątej zmianie już nie. I właśnie tam zdarzają się nieprzyjemne błędy: drobna poprawka listy przy okazji odsłania kolumnę, która miała zostać ukryta.
W Openbase.one przy każdej wersji sprawdzane są model danych i reguły dostępu, a rekordy są klasyfikowane: wewnętrzne, osobowe, wrażliwe, podatkowe. Potem każda strona jest otwierana w prawdziwej przeglądarce jako każda osoba testowa. „Jako przełożony: wynagrodzenia niewidoczne.” „Jako HR: wszystkie wynagrodzenia widoczne.” Wersja trafia na produkcję dopiero po pozytywnym sprawdzeniu. Jeśli budowanie albo sprawdzenie się nie powiedzie, dalej działa obecna wersja.
4. Działa w odcięciu
Aplikacja, która pracuje na danych firmy, nie powinna móc dowolnie łączyć się z internetem. Nie dlatego, że każdy kod jest złośliwy, ale dlatego, że nikt nie czyta każdej linijki wygenerowanego kodu.
Kod aplikacji w Openbase.one działa w izolowanym środowisku uruchomieniowym bez dostępu do sieci. Nie sięga ani do internetu, ani do innych workspace’ów. O tym, co aplikacja może zrobić z danymi, nie decyduje jej kod, tylko sprawdzenie każdego pojedynczego wywołania.
5. Jest droga powrotu
Błędy się zdarzają. Liczy się to, jak szybko można się ich pozbyć. Aplikacja gotowa do pracy ma wersje, a poprzednia może szybko wrócić na produkcję, bez odtwarzania czegokolwiek późnym wieczorem.
W Openbase.one każda wersja zostaje zachowana. Poprzednią wersję produkcyjną przywracacie jednym kliknięciem. Potem możecie spokojnie opisać, co ma się zmienić.
6. Aktualizacje według waszych zasad
Aplikacje, które zespół instaluje, a nie buduje sam, rodzą osobne pytanie: kto decyduje, kiedy coś się zmienia? W niektórych obszarach automatyczne aktualizacje są w sam raz. W innych, na przykład w płacach, chcecie najpierw zobaczyć, co nowego.
W Openbase.one zainstalowane aplikacje aktualizują się automatycznie albo dopiero po waszej akceptacji, osobno dla każdej aplikacji. Kto dostosowuje zainstalowaną aplikację, dostaje własną kopię i nie zmienia wersji innych.
7. Kod i dane należą do firmy
Aplikacja, która istnieje tylko na jednym koncie, w praktyce należy do tego konta. Gotowość do pracy w firmie oznacza też, że firma może zabrać aplikację ze sobą.
Kod każdej waszej aplikacji leży jako repozytorium Git w workspace, a dane można wyeksportować. Dziennik audytu zapisuje, kto co zmienił, i również da się go wyeksportować.
8. Ktoś odpowiada merytorycznie
Ostatni punkt nie jest techniczny. Każda aplikacja potrzebuje zespołu, który merytorycznie za nią odpowiada: decyduje, co aplikacja ma robić, i zatwierdza zmiany. Sprawdzenie może wykazać, że uprawnienia są przestrzegane. Na pytanie, czy zasada urlopowa albo limit akceptacji są merytorycznie poprawne, nie odpowie żadne sprawdzenie.
Uważamy ten podział za uczciwy. Openbase.one odpowiada za środowisko: izolację, uprawnienia, sprawdzenia i wersje. Zespół odpowiada za treść. Administratorzy widzą każdą aplikację w workspace.
Czego to nie oznacza
Gotowość do pracy nie oznacza, że nic nigdy nie pójdzie źle. Żadne środowisko nie zamieni niejasnego wymagania w poprawną aplikację. Oznacza, że błędy wychodzą na jaw wcześnie, wyrządzają niewiele szkody i szybko znikają.
I oznacza, że nikt nie zostaje sam. Wsparcie platformy jest w cenie każdego planu. W ramach umowy wsparcia pomagamy przy waszych własnych aplikacjach, a w Premium przeglądamy też nowe aplikacje przed wdrożeniem. Jeśli wolicie zbudować aplikację razem z nami, możecie zamówić to jako pakiet jednorazowy.
Wypróbujcie
Pierwszą aplikację możecie zbudować za darmo, z kredytem AI 15 € i bez karty kredytowej. Plany i umowy wsparcia znajdziecie na stronie z cennikiem.
Opiszcie swoją pierwszą aplikację i zobaczcie, jak sprawdzona trafia na produkcję.
Zacznij za darmo