Za duża baza

Czasami Czytelnicy dzielą się ze mną pouczającymi historiami z dziedziny informatyki, zawsze przy tym zastrzegając sobie anonimowość. Oto jedna z takich historii, po koniecznych zmianach chronią-cych tożsamość autora opowieści i jego pracodawcę.

Czasami Czytelnicy dzielą się ze mną pouczającymi historiami z dziedziny informatyki, zawsze przy tym zastrzegając sobie anonimowość. Oto jedna z takich historii, po koniecznych zmianach chronią-cych tożsamość autora opowieści i jego pracodawcę.

Do informatyków pewnego przedsiębiorstwa wpłynęło oczekiwanie użytkowników: baza danych musi zostać zmniejszona. Uzasadnienie: bo aktualna jest zbyt duża. Wymaganie użytkownika rzecz święta, więc analitycy zakasali rękawy i za-częli kombinować.

Informatycy to ludzie kreatywni, więc już po kilku dniach pracy na stole leżały naprawdę fantasty-czne pomysły. Zaproponowano kompresję danych i oszaco-wano wpływ na czas odpowiedzi oraz moc obliczeniową, którą trzeba by przeznaczyć na kompresję i dekompresję w locie. Pierwsze estymacje wyglądały zachęcająco, więc resztę czasu poświęcono na znalezienie właściwych algorytmów kompresji, które przy tej specyfice danych dałyby optymalny efekt.

Ktoś wtedy wpadł na inne rozwiązanie: zarchiwizować część danych historycznych. Ceną za radykalne zmniejszenie objętości bazy byłoby co prawda ograniczenie możliwości analitycznych, ale i z tym sobie poradzono poprzez stworzenie tzw. agregatów, czyli specjalnych tabel grupujących dane historyczne w postaci przetworzonej. Zamiast trzymać wszystkie transakcje sprzed pięciu lat, obliczano ich wartość, liczbę, rozkład itd. (wszystko, co aktualnie raportowano i co najprawdopodobniej byłoby raportowane w przyszłości) i umieszczono tę informację w owych agregatach.

Wymyślono również podział jednej, dużej bazy na kilka mniejszych. Aby zmiany w kodzie były możliwie niewielkie, wstępnie zaprojektowano warstwę pośrednią. Dzięki niej dla większości aplikacji nowy podział baz byłby całkowicie "przeźroczysty".

Dopiero kiedy wszystko to było dopracowanym projektem, ktoś zapytał przytomnie: po co baza miałaby być mniejsza? Jaki problem lub jaka potrzeba użytkownika (określana w kategoriach biznesowych, nie technicznych) tkwią u podstaw wymagania? I wtedy okazało się, że prawdziwym problemem nie był rozmiar bazy danych, a bliski brak miejsca na dyskach serwera. Poprzez prosty upgrade sprzętu oraz objęcie zajętości dysków monitoringiem rozwiązano problem. A przy okazji nie omieszkano przeprowadzić krótkiej analizy, dlaczego objętość przyrasta tak szybko. Wynikiem tej analizy był zestaw drobnych i tanich zmian w aplikacjach, zapobiegający redundancji danych.

Opisana powyżej historia to tylko jeden z przykładów, gdzie bardzo fachowo rozwiązano źle sformułowany problem. Błąd tkwił u zarania: stwierdzenie "baza musi zostać zmniejszona, bo jest za duża" nie ma charakteru wymagania użytkownika, bo posługuje się terminami i kategoriami ze świata techniki. Na samym początku analityk powinien był zapytać: ale po co? Gdzie jest korzyść klienta i czego on tak naprawdę oczekuje?

Rzekłbym, że w projektach informatycznych rozwiązywanie niewłaściwego problemu to grzech numer jeden, ważniejszy nawet od opóźnionych dostaw i marnej jakości produktów. Uczy się nas spełniania wymagań użytkowników, ale nie uczy się kwestionowania ich. Albo zniechęcamy się, kiedy klient, użytkownik (który naczytał się w mądrych czasopismach, że "IT doesn't matter", ma rolę pomocniczą i musi iść za biznesem) powie nam: to nie twoja sprawa, jesteś przecież tylko inżynierem, rób, co ci każą.

Mam nadzieję, że ta krótka, choć pouczająca historia sprawi, że zaczniemy częściej kwestionować oczekiwania i dociekać prawdziwych źródeł wymagań. Jestem pewien, że w ten sposób dobrze przysłużymy się swoim organizacjom.