Praktyczny przewodnik po architekturze rezydencji danych

Aby przygotować raport finansowy, jeden z kolegów pobiera arkusz z chmury, inny prosi o dane z ERP, a trzeci kopiuje dane z portalu zewnętrznego partnera. Proces działa - aż do momentu, gdy pojawia się pytanie: gdzie dokładnie znajdują się te dane, kto ma do nich dostęp i co się stanie, jeśli system lub dostawca przestanie działać?

Praktyczny przewodnik po architekturze rezydencji danych nie dotyczy przede wszystkim lokalizacji serwerów według krajów. Chodzi o to, aby przechowywanie, przetwarzanie, przesyłanie i odzyskiwanie informacji ważnych dla biznesu było kontrolowane. W firmie zatrudniającej od 20 do 500 osób ma to bezpośredni wpływ na ciągłość operacyjną, wiarygodność raportów, zaufanie partnerów i ryzyko zgodności.

Czym właściwie jest rezydencja danych?

Rezydencja danych odnosi się do tego, w jakim środowisku geograficznym, prawnym i operacyjnym dane są fizycznie i logicznie zlokalizowane. Nie wystarczy wiedzieć, że aplikacja działa „w chmurze”. Warto wyjaśnić, w jakim regionie przechowywane są dane podstawowe, gdzie tworzone są kopie zapasowe, dokąd trafiają wiadomości integracyjne i w jakim kraju działa personel wsparcia, który może uzyskać dostęp do systemu w razie potrzeby.

Pytanie staje się szczególnie namacalne, gdy sklep internetowy przesyła dane zamówienia do ERP, ERP przekazuje informacje do fakturowania, a następnie partner logistyczny otrzymuje dane potrzebne do dostawy. Dane jednego zamówienia mogą pojawić się w wielu systemach, w wielu kopiach, a nawet w wielu krajach. Jeśli nikt tego świadomie nie zaplanował, firma tak naprawdę nie wie z pełną pewnością, gdzie zarządza swoimi danymi.

Dlatego rezydencja danych nie jest wyłącznie kwestią prawną lub informatyczną. To także kwestia operacyjna. Jeśli lokalizacja, właściciel lub sposób odzyskiwania krytycznych informacji nie są jednoznaczne, codzienna działalność opiera się na ukrytej zależności.

Architektura rezydencji danych: najpierw zmapuj ścieżkę danych

Częstym błędem jest wybór dostawcy lub platformy chmurowej przez organizację przed zbadaniem przepływu danych. To jak budowanie nowego magazynu bez wiedzy, jakie towary, jak często i skąd tam trafiają.

Dobrym punktem wyjścia jest kilka kluczowych procesów biznesowych. Mogą to być realizacja zamówień, zarządzanie kartami produkcyjnymi, fakturowanie, przekazywanie danych do płac lub tworzenie raportów zarządczych. W każdym procesie należy zrozumieć, skąd pochodzą dane, kto je modyfikuje, które systemy otrzymują ich kopie i gdzie są przechowywane długoterminowo.

Nie wszystkie dane wymagają takiej samej ochrony lub takiego samego traktowania geograficznego. Publiczny katalog produktów, wewnętrzny raport o stanie zapasów, umowa i dokument HR zawierający dane osobowe stanowią różne ryzyko. Zbyt rygorystyczne przepisy mogą niepotrzebnie podnosić koszty i spowalniać operacje. Zbyt luźne podejście może prowadzić do niekontrolowanego dostępu i trudnych do zarządzania sytuacji zgodności.

Stwórz inwentaryzację danych z odpowiedzialnym za biznes

Inwentaryzacja danych to nie techniczna tabela wypełniona przez dział IT. Każda ważna grupa danych powinna mieć odpowiedzialnego za biznes, który może powiedzieć, dlaczego dane są potrzebne, jak długo należy je przechowywać, jaki błąd spowodowałby problem biznesowy i kto może z nich korzystać.

Warto zarejestrować typ danych, system podstawowy, docelowe systemy integracyjne, region przechowywania, miejsce tworzenia kopii zapasowych, czas przechowywania i role dostępu. Jeśli informacja istnieje w tej samej formie w trzech-czterech systemach, również należy to odnotować. Duplikacja nie zawsze jest błędem: może być potrzebna ze względu na dostępność, wydajność lub przepisy prawne dotyczące przechowywania. Ale każda kopia powinna mieć uzasadnienie i właściciela.

Decyzje powinny być kierowane ryzykiem i potrzebami operacyjnymi

Rzadko istnieje jedna uniwersalna odpowiedź na decyzję dotyczącą rezydencji danych. Dla firmy działającej wyłącznie z krajowymi systemami może być uzasadnione, aby pewne dane pozostały w infrastrukturze krajowej. Natomiast firma e-commerce sprzedająca w kilku krajach może potrzebować przetwarzania w kilku regionach ze względów wydajnościowych, obsługi klienta lub partnerskich.

Kluczowe jest, aby decyzja była udokumentowana. Kierownictwo musi rozumieć, dla których danych wymagana jest określona lokalizacja geograficzna, dla których akceptowalne jest inne umiejscowienie i jakie kontrole zmniejszają ryzyko. Takimi kontrolami mogą być szyfrowanie, ścisły dostęp oparty na rolach, logowanie, regularne przeglądy uprawnień oraz przetestowany plan odzyskiwania.

Sama lokalizacja geograficzna nie zapewnia bezpieczeństwa. System przechowywany lokalnie również może być ryzykowny, jeśli z jednego konta administratora korzysta wiele osób, nie ma prób tworzenia kopii zapasowych lub logi dostępu są nieczytelne. Podobnie odpowiednio zaprojektowane i regulowane środowisko chmurowe może być kontrolowanym rozwiązaniem, jeśli organizacja zna granice odpowiedzialności.

Oddziel dane podstawowe, kopie i kopie zapasowe

Wiele problemów z niezawodnością operacyjną wynika z tego, że firma nie potrafi odróżnić tych trzech pojęć. Dane podstawowe to autentyczne źródło, z którego rozpoczyna się codzienna działalność. Kopia może być egzemplarzem utworzonym z powodu integracji w innym systemie. Kopia zapasowa nie służy do codziennej pracy, lecz do odzyskiwania.

Jeśli dane finansowe są uznawane za autentyczne przez ERP, ale raport zarządczy jest tworzony z ręcznie aktualizowanego arkusza, to arkusz nie może stać się cicho drugim źródłem prawdy. W takim przypadku najpierw należy uporządkować proces raportowania: dlaczego potrzebne jest ręczne kopiowanie, jakie dane brakuje w ERP i z którego systemu raport powinien być generowany automatycznie?

To mniej widoczna, ale ważna część architektury rezydencji danych. Nie tylko określa, gdzie znajdują się dane, ale także, którym danym można ufać.

Integracje często są ukrytymi ścieżkami danych

Na liście systemów firmy zwykle znajdują się ERP, CRM, sklep internetowy, system fakturowania i magazynowy. Mniej widoczne są krytyczne z punktu widzenia przepływu danych elementy pośrednie: usługi integracyjne, eksporty e-mailowe, zautomatyzowane przekazywanie plików, zewnętrzne narzędzia raportujące i środowiska testowe dla programistów.

Na przykład dane zamówienia pochodzące ze sklepu internetowego mogą przejść przez platformę integracyjną, trafić do dziennika błędów, a następnie pojawić się w powiadomieniu e-mailowym. Jeśli zamówienie zawiera dane osobowe lub wrażliwe biznesowo, to wszystkie te ścieżki są częścią architektury. Nie wystarczy sprawdzić, gdzie działa sklep internetowy i ERP.

Dlatego przy każdej ważnej interfejsie warto zbadać, jakie dane przez niego przechodzą, czy są tymczasowo przechowywane, jak długo są przechowywane, jak odbywa się obsługa błędów i kto widzi logi. Źle skonfigurowany raport błędów może przez lata przechowywać dane, które nie są już potrzebne w operacjach.

Planuj na wypadek awarii, nie tylko normalnej pracy

Prawdziwa wartość decyzji dotyczących rezydencji danych ujawnia się w sytuacjach awaryjnych. Co się stanie, jeśli podstawowy region nie będzie dostępny? Ile utraty danych jest akceptowalne? Jak szybko musi zostać przywrócone przetwarzanie zamówień, dane produkcyjne lub fakturowanie?

To nie są wyłącznie kwestie techniczne. Jeśli magazyn przez cztery godziny nie widzi zamówień do realizacji, jakie opóźnienia, nadgodziny lub skargi klientów to spowoduje? Jeśli produkcja przez jeden dzień nie ma dostępu do dokumentacji technicznej, czy może pracować bezpiecznie? Cele odzyskiwania należy wyprowadzać z takich konsekwencji biznesowych.

Kopia zapasowa zapewnia ochronę tylko wtedy, gdy można ją przywrócić. Regularne próby odzyskiwania nie są więc obciążeniem administracyjnym, lecz walidacją. Pokazują, czy dokumentacja jest prawdziwa, czy uprawnienia są dostępne i czy firma rzeczywiście jest w stanie uruchomić krytyczne systemy.

Nie traktuj tego jako jednorazowego projektu

Nowy partner, nowy kraj, nowy sklep internetowy, przejęcie lub wymiana starego systemu mogą zmienić ścieżkę danych. Raz stworzona architektura szybko się starzeje, jeśli nie ma za nią zarządzania zmianami.

Przed każdą większą implementacją systemu lub integracją powinien istnieć prosty, ale obowiązkowy punkt kontrolny: jakie dane obsługuje nowe rozwiązanie, gdzie je przechowuje, komu udziela dostępu, jacy dodatkowi dostawcy biorą udział i jak wpisuje się w plan tworzenia kopii zapasowych, logowania i odzyskiwania. To niekoniecznie spowalnia rozwój. Zapobiega późniejszym niespodziankom, ręcznym obejściom i kosztownym przekształceniom.

Dobra architektura rezydencji danych nie jest widoczna dzięki dużej ilości dokumentacji. Jest widoczna, gdy lider może szybko uzyskać odpowiedź na pytanie dotyczące krytycznej grupy danych: gdzie się znajdują, kto za nie odpowiada, kto ma do nich dostęp, co jest z nimi związane i co się stanie, jeśli system podstawowy nie będzie dostępny. Jeśli dziś odpowiedzi na te pytania wymagają zaangażowania wielu osób, wielu arkuszy i długiej wymiany e-maili, warto zacząć od mapowania ścieżki danych.