GOAAS – Zarys koncepcji

Chciałbym przedstawić wam pewien pomysł, który urodził się w wyniku walk z różnymi serwisami publicznymi.

Government Oriented Architecture Application and Services

Każda nowoczesna administracja publiczna by wykonywać swoje zadania potrzebuje dobrze zorganizowanej struktury. Struktura ta służy w ogólności do przetwarzania danych i udostępniania ich zainteresowanym podmiotom, najczęściej innym organom administracji lub obywatelom. Wraz z rozwojem gospodarki pojawiła się potrzeba szybszego dostępu do coraz większej ilości danych. Proces ten nie ominął i administracji publicznej. Oznacza to, że musi ona wytworzyć odpowiednie narzędzia, które będą mogły sobie poradzić z coraz większymi ilościami danych.

Zastanówmy się jakie wyzwania stoją przed administracją publiczną we współczesnym świecie. Niewątpliwie największym wyzwaniem jest przestawienie się na elektroniczną obsługę petenta w typowych sprawach. Idealnym rozwiązaniem jest możliwość obsłużenia go metodą „one click”, ale nie ma ono w obecnej chwili racji bytu. Dlaczego opowiem za pewien czas. Drugim istotnym wyzwaniem jest stworzenie uwarunkowań prawnych tak by jak największa część spraw była załatwiana drogą elektroniczną. Tu istotnym elementem jest uwierzytelnienie dokumentów, czyli przede wszystkim podpis elektroniczny. Trzecim wyzwaniem jest promocja nowych form komunikacji petent-urząd, tak aby wytworzona została nie tylko atmosfera wzajemnego zaufania, ale też chęci współpracy.

Patrząc na projekty dla administracji w których uczestniczyłem i uczestniczę dochodzę do wniosku iż istnieją pewne standardowe problemy z którymi borykają się zarówno zleceniodawcy (urzędy) jak i wykonawcy (firmy, ale też programiści, projektanci i architekci). Dlatego też chciałbym przedstawić bardzo ogólną koncepcję prowadzenia tego typu projektów, tak aby były one obarczone jak najniższym ryzykiem.

GOAAS nie jest formalną koncepcją czy też wzorcem, ale raczej swobodnym zbiorem przemyśleń na temat projektowania systemów od a do z.

Trzy obszary działania

Projekty dla administracji publicznej, rządowej, samorządowej lub szeroko rozumianych instytucji państwowych nie są typowymi projektami biznesowymi. Wyróżnia je znacznie większy stopień złożoności i znacznie większy wpływ czynników politycznych na przebieg całego procesu projektowego. Jednak już na wstępie możemy wyróżnić trzy podstawowe obszary w których przyjdzie nam działać. Pierwszy z nich to Prawo (przez wielkie P). Administracja czy też urzędy i instytucje działają w oparci o dobrze zdefiniowane procesy, które są zapisane w prawie. Drugi obszar, moim zdaniem najważniejszy, to opinia publiczna. Tak naprawdę to właśnie elektorat decyduje o powodzeniu lub porażce projektu. Trzeci obszar to technologie począwszy od architektury, poprzez aplikacje, a skończywszy na udostępnionych usługach. Wchodzą tu też zagadnienia związane z zarządzaniem projektami.

Omówię teraz każdy z tych obszarów, ale skupię się dokładniej tylko na ostatnim (koniec, końców moja branża). Jako przykładowy projekt wezmę ewidencję ludności.

Prawo

Jeżeli prowadzimy projekt biznesowy to zazwyczaj wystarczy nam do szczęścia jak nie łamiemy prawa. Możemy je omijać, interpretować na swój sposób czy też naginać i dopóki nie łamiemy prawa wprost do puty nie musimy się przejmować. W przypadku produktu „dla rządu” nie dość, że prawo musi być stosowane w pełni i klarownie to jeszcze zazwyczaj nakłada ono na nas pewne ograniczenia. W trakcie tworzenia oprogramowania i infrastruktury wychodzą zazwyczaj wszelkie niedoróbki i sprzeczności w prawie. Odwołując się do naszego przykładu z ewidencją ludności możemy wyróżnić dwa podstawowe akty prawne. Pierwszy to Ustawa z dnia 10 kwietnia 1974 r. o ewidencji ludności i dowodach osobistych (Dz.U. 1974 nr 14 poz. 85 z późniejszymi zmianami), która to nakazuje prowadzenie ewidencji ludności gminom oraz stworzenie centralnego rejestru dowodów osobistych (Rozdział 8a). Jest to bardzo jasny przepis prawa, który mówi iż Gmina musi niezwłocznie drogą elektroniczną uaktualnić rejestr centralny. wszystko bangla, ale… no właśnie, ale mamy jeszcze Ustawę z dnia 29 sierpnia 1997 r. o ochronie danych osobowych (Dz.U. 1997 nr 133 poz. 883), która wymaga, aby obywatel wyraził zgodę na przetwarzanie jego danych (sic!). Zresztą sama ustawa jest sprzeczna w art 23 pkt 1 ppkty 1 i 4 wykluczają się wzajemnie. Projektanci systemu muszą zapewnić zarówno ochronę danych jak i możliwość ich transferu. W takiej sytuacji wymaga to dużo cwaniactwa i dość dużej liczby uzgodnień. Cóż jak widać prawo nas nie rozpieszcza, ale zawsze można przekonać „Wybrańców Narodu” do jego zmiany…

Co ludzie powiedzą, czyli aspekt społeczny

Najistotniejsza część całej tej zabawy. Dlaczego? ponieważ to właśnie ludzie płacą podatki, które finansują nasze przedsięwzięcie oraz to ludzie głosują na polityków firmujących swoimi nazwiskami projekt. Sam projekt musi zapewnić poczucie bezpieczeństwa obywatela. Nikt nie chciałby, żeby osoby niepowołane miały dostęp do danych osobowych. Przykładem pięknej katastrofy i złego projektu jest system austryjacki w którym urzędnik ma dostęp do wszystkich danych obywatela. Ma to dwie poważne wady, raz urzędnik ma za dużo nieistotnych danych do przetworzenia, dwa zbyt łatwo jest posiąść pełnię wiedzy o obywatelu i wykorzystać ją w niecnym celu. Obywatel nie czuje się bezpieczny, a to źle. Z tego też powodu projekt musi uwzględniać jak największe rozproszenie i rozdrobnienie informacji. W ten sposób można w miarę łatwo kontrolować dostęp do danych i pozwalać na dojście tylko do niezbędnego minimum informacji.

Technologia

Na technologii skupię się w tym i w następnych postach. Dziś wspomnę jedynie, iż na etapie projektowania musimy pamiętać o dwóch zasadach. Po pierwsze niezależnie co będzie wynikiem końcowym opis i definicje muszą być jak najbardziej uniezależnione od konkretnej technologii. Tu świetnym przykładem jest dostarczenie modelu danych jako XMLa/XSD, a nie UMLa lub implementacji w konkretnym języku (najgorsze rozwiązanie). Drugim jest zapewnienie elastyczności tak by zmiany w prawie nie powodowały problemów z wymianą implementacji. Pamiętacie zapewne tłumaczenia Prokomu, że zmiana wysokości stawki ubezpieczenia powoduje, że trzeba przepisać częściowo system. Śmieszne to i straszne. Technologia to nie tylko oprogramowanie, ale też infrastruktura sieciowa, serwery i usługi. O tym jak podejść do projektowania tych elementów opowiem za jakiś czas. Obecnie trzeba tylko wiedzieć, że zazwyczaj jest tak, że odbiorcy naszej usługi będą używali kilkunastu różnych technologii i musimy tak zaprojektować całość by była jak najbardziej uniwersalna.

Na dziś tyle. W następnych tekstach opiszę typowe błędy i to jak ich uniknąć.

Napisz odpowiedź

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax