Jakie powinno być oprogramowanie dla dużych organizacji?

Ponieważ od wielu lat zajmuję się realizacją i wdrożeniami oprogramowania wspierającego procesy biznesowe w dużych organizacjach zebrało mi się sporo przemyśleń na temat specyfiki tej pracy, trudności które najczęściej wdrożeniowców czekają oraz sposobów radzenia sobie z typowymi przy takich projektach problemami. Dziś zatem będzie o tym w jaki sposób dobrze zaprojektowane oprogramowanie może pomagać nam w realizacji skomplikowanych projektów. Artykuł ten jest wyjaśnia też dlaczego projektując NGinn starałem się uwzględnić pewne cechy oprogramowania które uważam za pomocne przy realizacji potrzeb naszych klientów.

Wdrożenie

Mówiąc o wdrożeniu systemu w dużej organizacji mam na myśli firmy liczące kilka tysięcy pracowników gdzie wdrażany system ma spory ‘zasięg rażenia’, czyli obejmuje istotną część personelu firmy i w jakiś sposób dotyczy istotnych dla biznesu tej firmy procesów. Przykładem takiego oprogramowania są systemy CRM, wsparcia klientów, obsługi zamówień/zleceń lub też systemy wspierające wewnętrzne procesy w dużych firmach – HR, zakupy wewnętrzne, helpdesk IT etc. W takim środowisku wymagania najczęściej nie pochodzą od jednej osoby ale są jakąś wypadkową potrzeb i planów rozwojowych wielu osób z różnych działów danej firmy. Oznacza to że prowadząc wdrożenie musimy współpracować z wieloma ‘właścicielami biznesowymi’ jednocześnie, najczęściej będą to managerowie jednostek organizacyjnych w których wprowadzamy nasz system. Wiele źródeł wymagań oznacza potencjalne rozbieżności w specyfikacji potrzeb no i różne sposoby interpretacji tego co zostało ustalone - prawdopodobnie nie da się wszystkiego uzgodnić tak żeby specyfikacja była spójna, kompletna, niesprzeczna i na dodatek tak samo rozumiana przez wszystkie strony. Oczywiście należy do tego dążyć, ale wg mnie trzeba na jakimś etapie odpuścić i uznać że tak po prostu jest że każdy chce czego innego i na co innego zwraca uwagę. Problem jest taki że system musi być oparty na niesprzecznej wewnętrznie logice no i zapewnienie logiczności tej logiki to właśnie nasze zadanie, ale myślę że aby pracę w ogóle dało się zacząć to wystarczy ustalić kwestie podstawowe, złapać jaki-taki obraz całości i pilnować żeby każdy właściciel biznesowy na końcu dostał to na czym mu zależy. Przy takim podejściu musimy dopuścić możliwość robienia wyjątków od ustalonych przez wszystkich reguł, na przykład ustalając że system zaoferuje inną niż dla całej reszty firmy procedurę pracy lub zawartość formatki dla pracowników jakiegoś działu X bo akurat manager tego działu chce inaczej zarządzać u siebie pracą. Zamiast zmuszać wszystkich właścicieli biznesowych do uzgodnienia jednego wspólnego stanowiska w tej sprawie po prostu uwzględniamy potrzeby X w budowanym systemie tak aby nie miało to wpływu na pozostałych.

A co ze stroną techniczną przy takim podejściu? W sumie to każdy system może uwzględnić rozbieżne wymagania i wyjątki (oraz wyjątki od wyjątków) w logice biznesowej, różnice są tylko w sposobie implementacji takich wymagań, stopniu komplikacji wynikowego systemu oraz nakładzie pracy koniecznym do implementacji i późniejszego utrzymania systemu. Jest natomiast kilka cech oprogramowania które takie zadania ułatwiają:

oddzielenie logiki biznesowej od infrastruktury. Oprogramowanie powinno w przejrzysty sposób dzielić się na infrastrukturę (czyli komponenty odpowiedzialne za podstawowe funkcje systemu które się nie zmieniają z wdrożenia na wdrożenie) oraz na ‘logikę biznesową’ czyli specyficzne dla klienta struktury danych, GUI, formularze, szablony dokumentów i reguły według których system realizuje funkcje uzgodnione z klientem. Najlepiej żeby podział na infrastrukturę i logikę był silny, tzn każdy komponent powinien być jednoznacznie przypisany do jednej z tych grup, a dodatkowo infrastruktura powinna być na tyle dobrze zaprojektowana żeby implementacja kolejnych funkcji biznesowych nie wymagała omijania ani modyfikacji infrastruktury.
możliwość wprowadzania lokalnych zmian w logice. To szeroki temat, ale chodzi o to aby uwzględniając czyjeś specjalne potrzeby można było działać ‘lokalnie’ nie wpływając na pozostałe funkcje systemu, na przykład zaoferować dla wybranych użytkowników specjalną wersję formatki bez modyfikowania formatki ‘ogólnej’, tj tej dostępnej dla wszystkich, albo zmienić reguły rządzące przepływem określonego typu dokumentów bez modyfikowania reguł ogólnych którym podlegają wszystkie inne dokumenty. I odwrotnie - system w którym cała logika jest zapisana w jednym pliku z kodem źródłowym w postaci gigantycznego i wielokrotnie zagnieżdżonego if-else na pewno nie spełnia tej reguły i jest bardzo trudny do modyfikacji.
zwięzły, przejrzysty i najlepiej samo-dokumentujący się sposób zapisu logiki biznesowej. Struktura musi być łatwa do zrozumienia i zobrazowania, dzięki temu będziemy w stanie zapanować nad wielością reguł i wyjątków od nich. Można taki cel osiągnąć np przez wprowadzenie specjalizowanego języka ‘wyższego poziomu’ do zapisywania logiki biznesowej, np w postaci reguł if-then-else albo procesów w określonej notacji, tudzież opartego o XML języka opisu wyglądu formatek

Zmiana

Wracając do samego wdrożenia, chyba najważniejszym problemem z którym sobie musimy poradzić jest zmiana. Zmiany w dużych organizacjach to norma, możemy być pewni że w momencie uruchomienia systemu po raz pierwszy zacznie płynąć strumyczek wniosków racjonalizatorskich, żądań zmian i pomysłów na kolejne zastosowania systemu. Dla nas powinna to być okazja do robienia biznesu a nie rzecz z którą należy walczyć – należy klienta zachęcać do zmian i je realizować, problem tylko w tym jak to zrobić żeby nie wpaść przy okazji po szyję w bagno. A bagno pojawia się kiedy na skutek radosnej twórczości klienta (przy naszym współudziale) system robi się bardzo skomplikowany, reguły niejasne, niespójne i czasami się wykluczające i pojawiają się dziwne ‘błędy’ za które jesteśmy obarczani odpowiedzialnością. A wina nie zawsze jest po naszej stronie – no bo po kilku latach rozwoju systemu w firmie sytuacja zwykle przedstawia się tak:

nikt po stronie klienta nie ma pełnego obrazu tego jakie funkcje i w jaki sposób system realizuje. Po prostu nie ma takiej osoby bo różne wymagania pochodziły od różnych ludzi, w różnym czasie i nie ma nikogo kto by to potrafił albo chciał uzgodnić
ludzie którzy definiowali jakieś funkcje i ustalali z nami sposób ich działania albo już nie pracują, albo nie pamiętają, albo nie chcą pamiętać, albo dostali inne zadania i już nie biorą udziału w projekcie
nowi managerowie nie biorą odpowiedzialności za nic bo ‘to nie oni ustalali’. Mówią tylko że w systemie jest błąd bo nie pasuje do ich koncepcji.
Dokumentacja nic nam nie pomoże, po prostu jest zbyt ogólna i fragmentaryczna. Nie sposób spisać każdego szczegółu.
Jeśli się pilnowaliśmy to mamy rejestr wprowadzanych zmian. Świetnie, ale to nic nam nie pomoże bo jest tego tyle że trzeba nadludzkich możliwości żeby analizując poszczególne zmiany ustalić jaki powinien być aktualny stan systemu. Poza tym wiele drobiazgów było załatwiane na gębę/telefon/maila i nie ma już po tym śladu
Może nawet mamy specyfikację systemu i wiemy co i dlaczego w nim działa tak jak działa (o, super!) ale system i tak ‘źle działa’ bo w międzyczasie u klienta była reorganizacja, np cześć procesu została ‘outsorcowana’, wprowadzono nowe grupy, inne zasady rozliczeń itp itd. Oczywiście to nasz problem a nie klienta, no bo przecież wymagania mówią że system ma realizować jakiś tam cel a nagle przestał.

Właściwie wszystkie powyższe punkty przerabiałem, myślę że każdy informatyk który pracuje z klientami również byłby gotów się z większością zgodzić. I myślę też że nie ma skutecznego sposobu który by pozwalał sobie z tym poradzić. Ale trzeba zacisnąć zęby i z tym żyć (albo zmienić pracę na jakąś mniej stresującą), dobrze też jest mieć jakieś oparcie w oprogramowaniu – a oto cechy które uważam za bardzo pożądane w takiej sytuacji:

Wszystkie 3 punkty o których pisałem wyżej przy okazji specyfikacji wymagań, oraz:
Możliwość współistnienia kilku wersji logiki biznesowej. Na przykład jednoczesnego działania w oparciu o starą logikę i nową logikę – po prostu, stare sprawy biegną wg starych reguł, nowo zakładane – wg nowych. To bardzo ułatwia migracje. To pozwala też na robienie zmian lokalnych o których pisałem wcześniej – czyli takich co obejmują tylko niektórych użytkowników nie wprowadzając zamieszania u pozostałych. No i ułatwia ewentualny rollback do poprzednich wersji jeśli nowa nie okaże się takim sukcesem jak się wydawało.
Samo-dokumentacja (również wspomniany wcześniej). Logika biznesowa powinna być zapisana tak, żeby łatwo można było ustalić aktualny sposób działania systemu. Na przykład strukturalny zapis w postaci reguł if-then-else pozwala nam narysować drzewo decyzyjne wg którego system podejmuje jakieś działania, a np zapis procesów biznesowych w jakiejś strukturalnej notacji pozwala uzyskać diagram aktualnego przepływu dokumentów w firmie.
Możliwość wprowadzania zmian w locie. To jest istotne bo duże organizacje często pracują 24×7 i system jest tak samo potrzebny zarówno w dzień jak i w nocy. Nie można sobie pozwolić na długie przestoje, zwłaszcza kiedy zmian jest dużo i są wprowadzane bardzo często, nawet ad-hoc gdy ktoś zaobserwuje że system działa niezgodnie z oczekiwaniami i trzeba to szybko naprawić.
Możliwość wprowadzania zmian lokalnie, bez zatrzymywania pozostałych komponentów systemu – trochę związane z poprzednim, ale chodzi o to aby do wprowadzenia zmian w jakiejś funkcji systemu nie trzeba było wyłączać całego systemu a zasięg naszych działań był tak mały jak to tylko możliwe.
Cała logika biznesowa powinna być przechowywana w postaci plików tekstowych. Dlatego że w ten sposób łatwo śledzić zmiany np za pomocą systemu kontroli wersji. Wszelkie formaty binarne (np z graficznych designerów), bloby w bazie danych, bardzo utrudniają pracę.
Strukturalny podział logiki biznesowej według funkcji realizowanych przez system a nie czegoś innego (chociażby np obiektów w bazie relacyjnej). Biznesowo widziane funkcje systemu mają charakter przekrojowy – obejmują wiele fragmentów aplikacji, takich jak struktura danych w bazie, GUI, uprawnienia, specyficzną dla danej funkcji logikę, powiadomienia email, szablony dokumentów, raporty itp itd. Wszystko to może składać się na jedną logiczną funkcję, o nazwie np ‘obsługa płatności’ albo ‘obsługa komunikacji z dostawcami’. Dobrze by było żeby struktura systemu grupowała te elementy w pakiety według logicznych funkcji, wtedy łatwo ustalić które elementy systemu biorą udział w realizacji określonych wymagań i jaki będzie zakre zmian w systemie przy modyfikacji określonej funkcji. Istotna jest też separacja – dwie różne funkcje raczej nie powinny wykorzystywać tych samych fragmentów logiki biznesowej czy GUI, nawet jeśli są one bardzo podobne. A to dlatego że wprowadzając zmiany dla jednej grupy użytkowników nie chcemy przy okazji psuć czegoś pozostałym. ‘Code reuse’ to dobra rzecz ale nie tutaj.
Preferuję systemy ‘miękkie’ – tzn skryptowe, interpretowane, dynamiczne – w przeciwieństwie do statycznie typowanych, kompilowanych, buildowanych, package’owanych i deployowanych. Chodzi o modyfikacje logiki biznesowej, konfiguracji, uprawnień czy GUI. Infrastruktura może być kompilowana i niezmienialna po wdrożeniu, ważne aby logika była modyfikowalna. Dzięki temu możemy dokonywać szybkich poprawek, mini-wdrożeń, szybkich testów nowej funkcjonalności itp. Generalnie uważam że logika biznesowa powinna być zapisywana w językach skryptowych (przy czym wybieramy takie języki które najlepiej się nadają do określonego celu), zaś infrastruktura w językach niższego poziomu – C#, C++, Java itp.
Cechy powyższe pozwalają nam też zmienić podejście do testowania i prototypowania nowych funkcji. Mając możliwość wrzucenia nowej wersji logiki bez wyłączania starej możemy przeprowadzać testy nowych czy zmodyfikowanych funkcji na produkcji – po prostu udostępniając je wybranej grupie testerów. Po potwierdzeniu poprawnego działania włączamy funkcję dla wszystkich użytkowników. Bardzo często testy obejmują nie tylko zmiany w systemie, ale również zmiany w organizacji – klient po prostu chce realizować nowy proces posługując się naszym narzędziem i chce go sobie przetestować na jakiejś małej grupie ludzi. W takim przypadku testowanie na produkcji jest czymś naturalnym i bardzo ułatwia późniejsze uruchomienie ‘oficjalne’. Jest to też zachęta dla klienta do eksperymentowania – zwykle sprawdzenie czegoś ‘na żywo’ jest lepsze, szybsze i tańsze niż pisanie dokumentów z wymaganiami i analizowanie tematu ‘na sucho’.

Wydajność

Sprawa wydajności jest bardzo ważna – możemy dowolnie rozwijać i modyfikować nasz system, ale musi on zapewniać wydajność wystarczającą do obsłużenia wszystkich nowych pomysłów. A jeśli odnieśliśmy sukces to klient będzie chciał objąć wdrożeniem jakieś nowe obszary organizacji co oznacza więcej danych, więcej użytkowników no i więcej funkcji w aplikacji. W niektórych przypadkach rozwój systemu jest tak szybki że przerasta to nasze oczekiwania oraz możliwości systemu który nie był projektowany do tak dużego obciążenia. W tym miejscu kilka uwag na temat potencjalnych ‘min’ wydajnościowych:

Uwaga na relacyjne bazy danych. Mimo że relacyjna baza danych to podstawa bez której nikt nie wyobraża sobie aplikacji biznesowej to jednak jest to narzędzie które ma swoje ograniczenia. Po pierwsze jest ’sztywna’ – wymaga uzgodnienia struktur danych i trzymania się ich. Tabela w bazie jest taka sama dla wszystkich przechowywanych w niej obiektów, nawet jeśli różnią się one od siebie na poziomie aplikacji. Bazy danych nie obsługują dziedziczenia. Nie można wprowadzać zmian lokalnie – albo zmieniasz całą tabelę albo nic, zmiana struktury danych dotyczy wszystkich miejsc systemu które się do niej odwołują. Druga sprawa to wielkość bazy danych – jeśli chcesz wprowadzić zmiany w tabeli która liczy sobie miliony rekordów licz się z tym że może to być bardzo długotrwały proces albo nawet i niewykonalny (!). Na przykład dodanie nowej kolumny do rekordu aktualizuje nam wszystkie stare rekordy które już są w bazie – rozmiar rekordu się zwiększa i następuje reorganizacja całej tabeli która może trwać nawet kilka godzin. A nasz czas na serwis to 30 minut… niby prosta zmiana a nie do zrobienia. Trzecia sprawa to wydajność samej bazy – rozwój systemu to coraz większa jego komplikacja i coraz bardziej złożone transakcje w bazie danych. Transakcyjność to bardzo fajna rzecz ale potrafi również mocno ograniczyć wydajność aplikacji poprzez nakładanie blokad wykluczających współbieżne wykonywanie operacji. Na dodatek nie bardzo można zwiększać wydajność systemu przez dołożenie kolejnej bazy danych – najczęściej baza musi być jedna no bo chcemy działać na jednej, aktualnej wersji danych a nie na kilku niezsynchronizowanych kopiach. Dobrze jest przemyśleć te rzeczy na jakimś wczesnym etapie bo im więcej danych się nagromadzi tym mniejsze mamy możliwości manewru.

Kolejna sprawa to komunikacja między komponentami systemu oraz między systemem a innymi aplikacjami z którymi jest zintegrowany. Należy uważać na komunikację synchroniczną – mimo że wydaje się fajnym pomysłem na początku to może nam mocno obciąć wydajność całej aplikacji. Kluczowe operacje w systemie należy rozbić na jak najmniejsze kawałki, tak aby transakcje miały niewielki zasięg i wykonywały się szybko. Resztę operacji można dokończyć asynchronicznie. Przykład: podczas rejestracji nowego dokumentu przez użytkownika pozyskujemy wymagane dane od użytkownika i rejestrujemy dokument w bazie. Wszelkie operacje dodatkowe, takie jak powiadomienie o nowym dokumencie innych systemów, wysłanie emaili, indeksowanie dokumentu itp robimy później, offline, po zakończeniu interakcji z użytkownikiem i zamknięciu tej pierwszej transakcji w bazie danych. Komunikację z systemami zewnętrznymi robimy w tle bo nigdy nie wiadomo jak długo przyjdzie nam czekać na odpowiedź. Tak samo jeśli oferujemy jakąś usługę (np web service) dla systemów zewnętrznych – gdy zrobimy to w wersji synchronicznej może się okazać że zewnętrzne aplikacje po prostu ‘zarzynają’ nasz system. Bardzo dobrym pomysłem jest wykorzystanie architektury opartej o ‘message bus’ tj mechanizm asynchronicznego przekazywania komunikatów między komponentami systemu – w takiej architekturze naturalne jest podejście asynchroniczne. Temat jest godny jakiegoś rozwinięcia, ale to kiedy indziej.

NGinn

Oczywiście nie mogę tutaj pominąć NGinn – jest to narzędzie które projektowałem biorąc pod uwagę wszystko co napisałem wyżej (i pewnie jeszcze trochę spraw o których nie napisałem). NGinn jest moją odpowiedzią na problem realizacji skomplikowanych i ciągle zmiennych wymagań w rozbudowanych systemach. Oczywiście jeden NGinn nie załatwi wszystkiego, jest to tylko workflow engine i nie obejmuje na przykład GUI systemu, ale skutecznie stosuje opisane tu reguły do realizacji logiki biznesowej systemu. A to dlatego że:

Proces w NGinn opisuje nam logikę systemu potrzebną do realizacji określonego procesu biznesowego, tj zawiera opis konkretnej funkcji biznesowej systemu, od początku do końca. Procesy grupowane są w pakiety które oprócz samej definicji procesu mogą przenosić dodatkowe elementy potrzebne do realizacji danej funkcji biznesowej – np szablony powiadomień, logikę integracyjną, etc
NGinn obsługuje wersjonowanie procesów – procesy mogą współistnieć w wielu wersjach jednocześnie, wprowadzanie nowej wersji procesu nie wymaga wyłączenia starej ani migracji
Można modyfikować istniejące procesy bez zatrzymywania systemu.
Struktury danych w NGinn są dynamiczne – modyfikując proces można zmieniać definicję jego danych, nie pociąga to za sobą konieczności modyfikacji struktury bazy danych lub aktualizacji innych procesów które już się toczą.
Asynchroniczny w założeniach – NGinn polega głównie na asynchronicznej komunikacji między komponentami oraz między NGinn a światem zewnętrznym. Wewnętrznie NGinn używa kolejki komunikatów do przesyłania informacji pomiędzy procesami.
Definicja procesu jest jednocześnie dokumentacją logiki systemu – mając definicję można wygenerować graficzny schemat procesu.
NGinn pozwala używać ‘rules engine’ do zapisu drzew decyzyjnych w postaci reguł if-then-else. Może się to przydać tam gdzie istnieje potrzeba podejmowania różnych działań w oparciu o rozmaite atrybuty danych wejściowych.
W jasny sposób oddzielona jest infrastruktura NGinn od logiki biznesowej. Logika biznesowa jest przechowywana w definicji procesu w oparciu o którą infrastruktura ten proces realizuje.

Na koniec…

Podsumowując to wszystko, myślę że najefektywniejszą techniką tworzenia oprogramowania na zamówienie dla wymagających klientów (hm, czy są klienci niewymagający?) jest szybkie prototypowanie wsparte odpowiednio dostosowanym narzędziem. Pomaga to zarówno przy ustalaniu wymagań jak i przy późniejszej ich realizacji. Klientom bardzo przydaje się możliwość zobaczenia tego co chcą zamówić i skonfrontowania swoich wyobrażeń z rzeczywistością, a my dzięki temu mamy wymagania lepszej jakości i bardziej odpowiadające możliwościom systemu. No i szybciej możemy wystawić fakturę.

Oczywiście nie jest to jakieś rewolucyjne podejście – w świecie informatyki funkcjonują rozmaite metodyki prowadzenia projektów mające w założeniach szybkie prototypowanie – na przykład Extreme Programming czy rozmaite Agile – ale zostawmy ten temat, w końcu nie zajmujemy się tu teorią tylko robieniem softu. Reprezentuję punkt widzenia gościa który własnymi (lub zespołu) rękami tworzy oprogramowanie a własną głową odpowiada za dostarczenie go klientowi zgodnie z zamówieniem i w terminie i mam nadzieję że takie spojrzenie od strony warsztatu jest dobrym uzupełnieniem ‘best practices’ prowadzenia projektów informatycznych.

środa, Październik 14th, 2009, by nginn and is filed under "Bez kategorii, prowadzenie projektów, Wdrożenia Projekty Realizacja, wymagania biznesowe ". You can leave a response here, or send a Trackback from your own site.

« Wyszukiwanie danych w procesach || Jak wywołać dowolny web service bez WSDL i bez generowania kodu »

NGinn BPM