Czym się różni FlowDog...?

​

Kamienie milowe tworzenia systemu

Projektowanie i tworzenie systemu dla biznesu zazwyczaj składa się z kilku faz. Dość ogólnie, można wyróżnić takie kamienie milowe jak analiza wymagań, kodowanie wraz z modelowaniem danych domeny i określeniem procesów (tworzenie oprogramowania), testy i wdrożenie. I o ile każdy z tych elementów jest niezbędny dla zapewnienia końcowego sukcesu (lub porażki ), to z racji wykonywanych obowiązków (jestem koderem), chciałbym bliżej przyjrzeć się etapowi programowania. Weźmy pod lupę uproszczony system dla wypożyczalni samochodów. Po analizie zespół developerski dostaje „na stół” wymagania.

Wymagania klienta

Klient potrzebuje systemu dla wypożyczalni samochodów. System powinien gromadzić informacje o pojazdach możliwych do wypożyczenia, aktualnych wypożyczeniach, rejestrować polisy ubezpieczeniowe dla pojazdów oraz terminy wymaganych przeglądów technicznych. Samochody mogą być wypożyczone zarówno osobom fizycznym jak i podmiotom gospodarczym. Wynajem może trwać od 1 do 30 dni – z możliwością przedłużenia. Cena wynajmu jest uzależniona od klasy samochodu i naliczana za każdy dzień… (oczywiście w rzeczywistości taka analiza jest znacznie bardziej szczegółowa i obszerna jednak tu chodzi o przykład).

Zebrane oczekiwania „na produkcji”

Zespół developerski rusza do pracy, product owner odpowiada na pytania, powstaje backlog produktu, rozpisują pierwszy sprint. To co na początku jest potrzebne to model danych domeny. W zależności od przyjętego trybu pracy zespołu albo najpierw powstają diagramy ERD i z nich generowane są tabele dla bazy danych i później powstają modele danych dla aplikacji lub na podstawie modeli danych aplikacji powstają tabele danych. Skoro model danych gotowy i aplikacja go zna, czas na interface użytkownika. System trzeba „ubrać” w jakąś ładną skórkę – wchodzą eksperci od UX. Powstają kolejne ekrany: logowanie, lista wypożyczeń, formularz nowego wypożyczenia, wydruk umowy, lista pojazdów, formularz dodania nowego pojazdu, szczegóły pojazdu, polisy dla pojazdu, lista klientów, historia wypożyczeń itd… Część CRUD za nami pora na procesy – wyliczenie ceny, przypomnienie sms’em o zwrocie pojazdu, przedłużenie wynajmu, notyfikacje o wygasającej polisie czy zbliżającym się terminie badań technicznych i pewnie trochę wyjątków typu awaria/kolizja wypożyczonego samochodu.

Jeden „change request” potrafi wiele zmienić…

Wszystko idzie zgodnie z planem, product owner na kolejnych prezentacjach sprintu jest zachwycony, powoli zaczynają się testy z użytkownikami i change requesty. Taki jeden specyficzny change request czasem potrafi nieźle „namieszać” w projekcie. W zależności od kalibru, może wymagać głębokich zmian w modelu danych, co ciągnie za sobą zmiany w formatkach i procesach, kolejne testy. I nie ma w tym nic niezwykłego – ot po prostu codzienność programisty, natomiast z pkt. widzenia projektu konsumuje czas potrzebny na dostarczenie funkcjonalnego rozwiązania.

Sposób podejścia do produkcji oprogramowania przedstawiony powyżej jest dość często spotykany na rynku – sami jeszcze jakiś czas temu tak realizowaliśmy nasze projekty ale zaczęliśmy dostrzegać pewne ograniczenia związane z czasem dostarczania funkcjonalności, utrzymania jej i dalszego rozwoju. Dlatego we FlowDog postawiliśmy na coś innego.

Nic na sztywno, czyli jak?

FlowDog nie posiada hardcodowanego modelu danych dziedziny, nie ma hardkodowanych list danych, widoków ani formularzy, logiki biznesowe również nie są programowane „na sztywno”. Hmm, w zasadzie nic nie jest hardcodowane…. no może z wyjątkiem poszczególnych komponentów systemu realizujących konkretną konfigurację.  Poszczególne encje, ich wzajemne relacje, walidatory, listy, widoki, formularze itd. opisujemy json’em a logiki biznesowe modelujemy w podsystemie procesowym za pomocą bpmn. Co nam to daje? Przede wszystkim znacznie krótszy czas realizacji projektów. Oczywiście wspomniany powyżej projekt modelu zawsze powstaje, ale czas jego implementacji wraz z elementami obsługującymi nie zależy od programowania (encje, listy, widoki, formularze, logiki biznesowe) – wystarczy zasilić system konfiguracją. Podobnie obsługa change requestów, zmieniamy konfigurację.

Zmiany są możliwe – Szybciej niż myślisz

Przyjrzyjmy się jeszcze jednemu aspektowi. Nasza wypożyczalnia samochodów rozwija się, flota rośnie pojawiają się partnerzy biznesowi, którzy chcą rezerwować nasze auta do wynajmu ale ze swoich programów – potrzebny jest rozwój, stworzenie warstwy integracji. I ponownie, po analizie wymagań, doprecyzowaniu szczegółów z partnerem biznesowym wypożyczalni (co oni mają zrobić u siebie), nasz zespół developerski siada do pracy, tworzą potrzebne struktury danych, wystawiają endpointy api – w sumie niewielka zmiana a jednak cały projekt. We FlowDog – zmieniamy konfigurację, api już jest (jak cały szereg różnych innych ciekawych elementów) i możemy uruchomić taką funkcjonalność w czasie liczonym w godzinach – nie dniach.

W innowatorskim stylu

Podsumowując, przedkładając konfigurację nad „programowanie biznesu” FlowDog z powodzeniem działa w kilku dużych ogólnokrajowych marketach, firmach produkcyjnych, ogólnopolskich firmach branży FM, medycynie i pewnie kilku innych obszarach, których jako programista nie do końca jestem świadomy.