Integrować

O tym, że trzeba coś zrobić z brakiem spójności identycznych co do rodzaju danych, występującym w różnych systemach informatycznych, mówiło się głośno już pod koniec lat siedemdziesiątych, a może nawet i jeszcze wcześniej. Same takie, nic o sobie nie wiedzące systemy zaczęto wtedy określać mianem wysp informatycznych. Wyspy te należały, co prawda, do tych samych archipelagów, każda z nich żyła jednak własnym życiem i rytmem.

O tym, że trzeba coś zrobić z brakiem spójności identycznych co do rodzaju danych, występującym w różnych systemach informatycznych, mówiło się głośno już pod koniec lat siedemdziesiątych, a może nawet i jeszcze wcześniej. Same takie, nic o sobie nie wiedzące systemy zaczęto wtedy określać mianem wysp informatycznych. Wyspy te należały, co prawda, do tych samych archipelagów, każda z nich żyła jednak własnym życiem i rytmem.

Pierwszym na to antidotum miały być łatwiejsze w aktualizacji dyskowe zbiory danych. Gdy okazało się, że z ich udziałem też niewiele w zajmującym nas tu zakresie zmieniło się na lepsze, zaczęto głosić wiarę w komputerowe repozytoria opisujące struktury komputerowych danych, wspólne dla wszystkich systemów informatycznych stosowanych w danej organizacji. W powiązaniu z narzędziami określanymi mianem języków programowania czwartej generacji, miały one wyeliminować problem raz na zawsze, przybliżając jednocześnie proces tworzenia systemów do samych zainteresowanych, czyli użytkowników.

Jeżeli jednak pod tym względem do jakiegoś zbliżenia w ogóle doszło, to było ono - jak to określają Brytyjczycy - na odległość wyciągniętych rąk i w sumie też niewiele zmieniło.

Kolejną radykalną poprawę miały dać same relacyjne bazy danych, przynosząc tak upragnioną łatwość zmiany struktury danych. Skutek był częstokroć odwrotny do zamierzonego, gdyż względna łatwość zmian w strukturach owocowała brakiem dbałości podczas ich tworzenia, bo przecież - w razie przeoczenia - wszystko można później dodać i dorobić.

Powstające jeden obok drugiego systemy powierzano do realizacji odrębnym, bo jakże inaczej, serwerom i teraz mówi się o "morzach" serwerów, które znów są wyspami, cząstkami archipelagów. I znowu pojawiają się wezwania do konsolidacji i integracji, tym razem pod hasłem ograniczania kosztów, bo przecież tańszy jest jeden duży serwer niż kilkanaście mniejszych.

Wszystko jednak ma swoje granice. Aby to sobie lepiej uzmysłowić, spróbujmy sprowadzić sprawę do absurdu. Biorąc pod uwagę stopień nasycenia współczesnych samochodów elektroniką, nietrudno sobie wyobrazić, że już niebawem każdy pojazd będzie miał zamontowany, w sposób trwały, układ pozwalający go nie tylko zidentyfikować, ale również śledzić i rejestrować zachowanie.

Nie miałbym nic przeciwko wykrywaniu w ten sposób np. każdego przekroczenia dopuszczalnej prędkości, ale... Jeżeli system taki miałby wykrywać i rejestrować przekroczenia prędkości, to musiałby znać jej aktualne, dozwolone w danym miejscu granice oraz decyzje o tymczasowych ograniczeniach. Te ostatnie, w większości krajów, są wynikiem decyzji władz drogowych, czyli nasz hipotetyczny system należałoby połączyć z ich systemami.

Dlaczego jednak nie pójść dalej i nie przekazywać informacji o poszczególnych przekroczeniach, np. do systemu w sądzie grodzkim, który to system, również automatycznie, aplikowałby odpowiednią taryfę kar, wysyłając stosowne nakazy płatnicze i dane do rejestru kierowców.

Można próbować integrować jeszcze bardziej i włączyć w to system wyszukiwania stosownego rachunku bankowego i automatycznego pobierania automatycznie naliczonej kary.

Absurdalne? Być może. Ale widać z tego, że i integracja ma swoje granice, i łączenie wszystkiego z wszystkim nie zawsze jest najlepszym pomysłem.

Na same wykroczenia drogowe są jednak i inne, prostsze metody. Policja włoska często ustala szybkość jazdy na autostradach, sprawdzając przy bramkach karty opłat, na których widnieje godzina przekroczenia poprzedniej bramki. Prostą tę metodę można by polecić i naszej policji. Tylko gdzie te bramki?