Case Study: Anatomia systemu szytego na miarę. Techniczny Deep-Dive w architekturę transformacji HARMO [2/2]

Archeologia danych. Wyzwanie migracji

Budowa nowego systemu to czysta przyjemność w porównaniu z migracją danych ze starego, niedoskonałego rozwiązania. W przypadku HARMO, dane historyczne (z kilku lat!) były kluczowe dla ciągłości biznesowej. Stary system SaaS okazał się jednak „czarną skrzynką” z wieloma problemami.

Chaos w źródłach

Zastany system SaaS posiadał API, ale było ono limitowane (Rate Limiting) i nie zwracało wszystkich atrybutów danych. Część informacji musieliśmy odzyskiwać z ręcznych eksportów CSV/JSON, które generowali menedżerowie. Napotkaliśmy szereg problemów z jakością danych (Data Quality):

• Niespójne formaty identyfikatorów projektów.
• Brak jawnego rozróżnienia typów godzin (płatne/niepłatne) w starych rekordach.
• „Dziury” w historii wynikające z błędów ludzkich.
• Zmiany w słownikach (np. projekt X zmienił nazwę na Y dwa lata temu, ale w bazie starego systemu widniał pod dwiema różnymi nazwami).

Custom ETL Tool – Więcej niż skrypt

Szybko zrozumieliśmy, że prosty skrypt SQL nie wystarczy. Zespół GOTOMA SOFTWARE HOUSE zbudował dedykowane narzędzie ETL (Extract, Transform, Load) w .NET. Jego działanie opierało się na kilku krokach:

• Extract: Pobranie danych ze wszystkich źródeł (API, pliki) do surowej bazy stagingowej (Raw Data).
• Normalize: Ujednolicenie formatów dat, walut i identyfikatorów użytkowników.
• Map: Najtrudniejszy etap. Mapowanie starych projektów na nowe struktury. Tutaj zaimplementowaliśmy logikę Reguł Naprawczych.
• Load: Zasilenie nowej bazy produkcyjnej.

Reguły naprawcze i transparentność

Nie mogliśmy po prostu „zgadywać” brakujących danych. Wprowadziliśmy mechanizm kontrolowanych reguł:

• „Jeśli zadanie nie ma przypisanego projektu, przypisz je do projektu 'Migracja_Inne'”.
• „Jeśli brak typu godziny, ustaw domyślny typ 'Standard'”.
• Słownik aliasów dla zduplikowanych nazw projektów.

Kluczowa była transparentność. Narzędzie ETL generowało szczegółowy log błędów i zmian. Każdy rekord, który został zmodyfikowany przez „regułę naprawczą”, otrzymywał w nowej bazie specjalną flagę. Dzięki temu klient mógł wygenerować raport „Rekordy naprawione automatycznie” i zweryfikować, czy logika przyjęta przez algorytm była zgodna z rzeczywistością.

Strategia „Cut-Off” i migracja na raty

Uniknęliśmy pułapki „Big Bang” (przełączenia wszystkiego w jednej sekundzie bez testów) oraz pułapki „wiecznej synchronizacji” (dwukierunkowej wymiany danych między systemami). Zastosowaliśmy podejście „Migracji na raty”:

• Regularne importy danych historycznych na środowisko testowe (Sandbox) w celu walidacji raportów.
• W dniu wdrożenia (Go-Live) nastąpił Hard Cut-Off. Zablokowano możliwość dodawania nowych wpisów w starym systemie.
• Do nowego systemu zaimportowano „deltę” (dane z ostatnich dni) i uruchomiono go jako jedyne źródło prawdy.

Analityka w czasie rzeczywistym

Jednym z głównych wymogów HARMO była eliminacja Excela. System musiał generować raporty rentowności „na żądanie”. Jak to osiągnąć, gdy baza puchnie z każdym dniem?

Separacja odpowiedzialności (OLTP vs OLAP)

Systemy transakcyjne (OLTP), które obsługują bieżące logowanie czasu, nie lubią ciężkich zapytań agregujących. Dlatego zastosowaliśmy logiczny podział.

Raporty operacyjne: Bieżące zestawienia (np. „mój czas pracy w tym miesiącu”) są generowane bezpośrednio z bazy produkcyjnej. Dzięki indeksom jest to błyskawiczne.

Data Mart (Lekka Hurtownia): Dla cięższych analiz (roczne raporty dla zarządu, trendy wydajności) stworzyliśmy dedykowane struktury (widoki zmaterializowane lub osobne tabele analityczne). Są one zasilane przez procesy działające w tle (lub nocne joby), które przeliczają surowe logi na gotowe agregaty (np. dzienna suma godzin per projekt).

Optymalizacja SQL

Nie polegaliśmy wyłącznie na tym, co wygeneruje ORM. Krytyczne zapytania raportowe zostały ręcznie zoptymalizowane przez naszych ekspertów bazodanowych:

• Eliminacja zbędnych JOIN.
• Zastąpienie podzapytań (Sub-Selects) wydajnymi funkcjami okienkowymi (Window Functions).
• Filtrowanie w pierwszej kolejności po kolumnach z wysoką selektywnością (np. data), aby ograniczyć ilość przetwarzanych wierszy.
• Dzięki temu, wygenerowanie raportu rocznego dla 50-osobowego zespołu, które w Excelu zajmowało godziny (plus czas na eksport), w naszym systemie trwa poniżej 2 sekund.
• Bezpieczeństwo. Twierdza On-Premise

Fakt, że kod działa u klienta, wymusił dodatkowe warstwy zabezpieczeń. Nie mogliśmy polegać na tym, że „chmura to zabezpieczy”.

Tożsamość i dostęp

Nie chcieliśmy tworzyć kolejnej bazy loginów i haseł. Zintegrowaliśmy system z Active Directory (LDAP) klienta. Dzięki temu, onboardning nowego pracownika w dziale IT automatycznie nadaje mu dostęp do systemu czasu pracy, a zablokowanie konta w AD natychmiast odcina dostęp. Wdrożyliśmy zaawansowany RBAC (Role Based Access Control). Uprawnienia nie są binarne (admin/user). Mamy granularne role (np. Project Manager, Team Lead, External Client), które definiują dostęp do konkretnych endpointów API i widoków danych. Co ważne – walidacja uprawnień odbywa się zawsze na backendzie, nie tylko w UI.

Ochrona kodu i danych

Ponieważ binarki (pliki .exe/.dll) trafiają na komputery pracowników, zastosowaliśmy Code Signing (podpisywanie cyfrowe kodu) certyfikatem zaufanym w domenie klienta. Zapobiega to fałszywym alarmom antywirusowym i gwarantuje integralność aplikacji. Wrażliwe dane konfiguracyjne (np. connection stringi do bazy) są szyfrowane (DPAPI lub szyfrowanie na poziomie konfiguracji .NET), aby uniemożliwić ich łatwy odczyt przez osoby niepowołane mające dostęp do serwera plików.

Lekcje z pola bitwy i ślepe uliczki

Żaden projekt IT nie jest pasmem nieustających sukcesów. Szczerość inżynierska wymaga, aby wspomnieć o wyzwaniach.

Ślepa uliczka: Web-Only

Na wczesnym etapie rozważaliśmy architekturę czysto webową (tylko przeglądarka). Odrzuciliśmy ją. Praktyka pokazała, że brak stabilnego background trackingu i globalnych skrótów klawiszowych byłby „deal breakerem” dla deweloperów. Czasami stara, dobra aplikacja desktopowa (nawet jeśli pod spodem jest nowoczesna) jest najlepszym narzędziem do specyficznych zadań.

Wyzwanie supportu

On-Premises utrudnia support. Nie możemy po prostu „wejść na produkcję” i sprawdzić logów, gdy coś nie działa. Musieliśmy zainwestować w rozbudowany system logowania po stronie klienta (z anonimizacją danych wrażliwych) oraz mechanizm generowania „paczek diagnostycznych”, które klient może nam bezpiecznie przesłać. Posiadamy również w naszym labie środowisko „Mirror”, które pozwala symulować konfigurację klienta.

Co zrobilibyśmy inaczej? Event Sourcing

Gdybyśmy projektowali ten system dzisiaj, prawdopodobnie mocniej postawilibyśmy na architekturę Event Sourcing. Zapisywanie zmian jako sekwencji zdarzeń (zamiast tylko aktualnego stanu) ułatwiłoby audytowanie zmian, cofanie błędnych operacji (np. przy migracji) i integrację z innymi systemami w przyszłości. Jest to kierunek, w którym planujemy rozwijać ten system w kolejnych wersjach.

Podsumowanie

Projekt dla HARMO to dowód na to, że w inżynierii oprogramowania nie ma rozwiązań uniwersalnych. Wybór technologii .NET/WPF, wdrożenie On-Premises i budowa własnego narzędzia ETL były decyzjami podyktowanymi konkretnym kontekstem biznesowym i technicznym, a nie modą.

Jako GOTOMA SOFTWARE HOUSE nie sprzedajemy „technologii w pudełku”. Dostarczamy rozwiązania inżynierskie, które rozwiązują problemy – nawet jeśli wymaga to pójścia pod prąd. Połączenie desktopowej wygody, dockerowej elastyczności i solidnej inżynierii danych dało klientowi narzędzie, które nie tylko działa, ale realnie wspiera ich biznes na co dzień.

Jeśli stoisz przed wyzwaniem modernizacji systemów legacy, integracji on-premise lub budowy dedykowanego oprogramowania wspierającego unikalne procesy – zapraszamy do kontaktu z naszymi specjalistami.

Chcesz dowiedzieć się więcej o biznesowych aspektach tego wdrożenia? Przeczytaj nasze Case Study poświęcone strategii General Contractor IT.