Jak śledzić pole danych w całym systemie przedsiębiorstwa

Pole danych to jedna z najmniejszych jednostek znaczeniowych w systemie oprogramowania, a mimo to jego śledzenie w całym przedsiębiorstwie to jedno z najtrudniejszych zadań, jakie można wykonać przed programistą, analitykiem lub specjalistą ds. zgodności. customer_id Istnieje gdzieś jako definicja. Jest przechowywana w jednej lub kilku tabelach. Jest odczytywana przez programy, przekazywana między usługami, transformowana przez zadania ETL, weryfikowana przez reguły biznesowe i ostatecznie renderowana w raportach, pulpitach nawigacyjnych lub odpowiedziach API, które są w całości przetwarzane przez inne systemy. Pytanie o to, skąd pochodzi to pole, dokąd trafia i co się z nim dzieje pomiędzy, nie jest pytaniem dotyczącym dokumentacji ani architektury. Jest to pytanie o rzeczywisty kod, rzeczywiste dane i rzeczywiste ścieżki wykonywania działającego systemu korporacyjnego. Aby na nie dokładnie odpowiedzieć, należy prześledzić pole na każdej warstwie, na której się pojawia, w każdym języku, na każdej platformie i w każdym repozytorium, w którym się znajduje.

W nowoczesnych organizacjach świadomych danych, zdolność ta znana jest pod nazwą „pochodzenia danych”, a narzędzia dla nowoczesnych stosów analitycznych, w tym chmurowych magazynów danych, potoków ETL i platform BI, znacznie się rozwinęły. Pochodzenie na poziomie kolumn jest standardem w wielu środowiskach analitycznych. Jednak systemy oprogramowania dla przedsiębiorstw to nie stosy analityczne. Są one heterogenicznymi kombinacjami programów mainframe, zadań wsadowych, relacyjnych baz danych, usług rozproszonych i nowoczesnych interfejsów API, z których każdy zarządzany jest przez inne narzędzia, inne zespoły i różne dekady decyzji projektowych. ACCT-BALANCE Zdefiniowane w copybooku COBOL nie występuje w Databricks ani dbt. Zadanie JCL, które generuje aktualizację wsadową dla tego pola, nie jest rejestrowane w żadnym narzędziu do analizy pochodzenia danych w chmurze. Usługa Java, która odczytuje wynikowy wiersz bazy danych i wypełnia obiekt odpowiedzi, to trzeci system z własną konwencją nazewnictwa dla tej samej wartości bazowej. Jak szczegółowo zbadano w kontekście Mapowanie JCL na COBOLTe trzy warstwy są ze sobą głęboko powiązane w sposób, którego żadne pojedyncze narzędzie nie jest w stanie rozwiązać, a brak ujednoliconego śladu nie jest niewielką luką, lecz strukturalną ślepą plamką, która wpływa na każde zadanie dotyczące współdzielonych danych.

W tym artykule znajdziesz praktyczny przewodnik po tym, na czym tak naprawdę polega śledzenie pól w systemie przedsiębiorstwa: warstwy, przez które przechodzi pole, dostępne metody jego śledzenia, powody, dla których te metody zawodzą na granicach warstw, wymagania prawdziwego śledzenia na poziomie pola oraz w jaki sposób organizacje inwestujące w tę możliwość wykorzystują ją do ograniczenia ryzyka, przyspieszenia dochodzenia i utrzymania kontroli nad danymi na dużą skalę.

Co oznacza śledzenie pola danych w systemie przedsiębiorstwa

Śledzenie pola danych oznacza śledzenie nazwanego elementu danych od punktu jego definicji, przez każde zdarzenie transformacji, ruchu, przechowywania i konsumpcji w systemie, w obu kierunkach: w górę rzeki do pierwotnego źródła wartości pola oraz w dół rzeki do każdego miejsca, które odczytuje, kopiuje, oblicza lub publikuje tę wartość. Pełny ślad pola to mapa całego cyklu życia pola: gdzie zostało utworzone, jak się zmieniło, kto je odczytuje i co z nim robi. Różni się to od prostego wyszukiwania nazwy pola, która jest użytecznym punktem wyjścia i zdecydowanie niewystarczającym punktem końcowym. Lista wyników wyszukiwania zawiera każde miejsce występowania ciągu znaków, w tym komentarze, komunikaty dziennika, zestawy testów i ciągi dokumentacji, pomijając jednak odniesienia do miejsc, w których pole zostało zmienione, aliasowane lub uzyskano do niego dostęp za pomocą obliczonego klucza. Śledzenie pola wymaga rozróżnień, których wyszukiwanie nie jest w stanie dokonać: definicji na podstawie użycia, odczytu na podstawie zapisu, transformacji modyfikującej wartość pola na podstawie prostego przejścia.

Pytanie, na które każdy ślad ma odpowiedzieć, określa jego wymagany kierunek i granularność. Analiza wpływu śledzi w dół strumienia: od definicji pola na zewnątrz do każdego konsumenta. Analiza przyczyn źródłowych śledzi w górę strumienia: od zaobserwowanej nieprawidłowej wartości wstecz, przez każdą transformację, do źródła błędu. Mapowanie zgodności śledzi w poprzek: które systemy przechowują lub przetwarzają pole, niezależnie od kierunku. Każdy kierunek śladu wymaga tej samej podstawowej możliwości: modelu systemu, który reprezentuje relacje na poziomie pola we wszystkich warstwach, a nie tylko w obrębie jednej. Jak zbadano w analizie danych i analizie przepływu sterowania , zrozumienie tego, co pole robi w systemie, wymaga wnioskowania zarówno o danych, które przenosi, jak i ścieżkach wykonywania, którymi się porusza, a te dwa typy wnioskowania muszą współdziałać, aby uzyskać dokładny i kompletny wynik.

Różnica między śledzeniem na poziomie tabeli i na poziomie pola

Literatura dotycząca pochodzenia danych rozróżnia dwa poziomy szczegółowości: pochodzenie na poziomie tabeli, które pokazuje, jak zestawy danych są ze sobą powiązane, oraz pochodzenie na poziomie kolumny, które pokazuje, jak poszczególne pola są tworzone, przekształcane i wykorzystywane. To rozróżnienie nie jest jedynie kwestią precyzji. Chodzi o różnicę między wiedzą, że system A zasila system B, a wiedzą, że wartość customer_segment w systemie B jest pochodną obliczeń zastosowanych do account_type oraz tenure_months w systemie A. Linia na poziomie tabeli informuje zespół, że zmiana w systemie A może wpłynąć na system B. Linia na poziomie pola informuje, które konkretne pole w systemie B jest dotknięte, jaka konkretna transformacja i w jakich konkretnych warunkach. Ta granularność przekształca linię z mapy kierunkowej w mapę umożliwiającą podjęcie działań.

W systemach korporacyjnych z komputerami mainframe i starszymi komponentami kwestia granularności jest dodatkowo skomplikowana ze względu na konwencje reprezentacji danych, które znacząco różnią się między warstwami. Pole pamięci roboczej w języku COBOL zdefiniowane jako WS-ACCT-BAL PIC S9(13)V99 zawiera tę samą koncepcję biznesową co zmienna Java accountBalance typu BigDecimal, który zawiera tę samą koncepcję co kolumna bazy danych ACCT_BALANCE DECIMAL(15,2)Ślad na poziomie tabeli obserwuje przepływ danych z programu COBOL do tabeli bazy danych, a następnie do usługi Java. Ślad na poziomie pola rozwiązuje ten problem. WS-ACCT-BAL, ACCT_BALANCE, accountBalance Wszystkie reprezentują tę samą koncepcję biznesową, z udokumentowanymi transformacjami między nimi. To właśnie ta rozdzielczość sprawia, że ​​ślad jest wykonalny.

Dlaczego śledzenie danych w terenie w przedsiębiorstwie jest trudniejsze niż analiza danych

Narzędzia analityczne, w tym nowoczesne platformy zbudowane wokół magazynów danych i frameworków transformacyjnych, takich jak DBT, działają w środowiskach, w których przenoszenie danych jest jawnie koordynowane poprzez zdefiniowane kroki potoku, a dane wejściowe i wyjściowe każdego kroku są rejestrowane w metadanych, które narzędzie DBT może odczytać. Dane wejściowe i wyjściowe są budowane na podstawie definicji potoku, które są artefaktami czytelnymi maszynowo, zaprojektowanymi specjalnie do obsługi tego rodzaju analiz. Systemy oprogramowania korporacyjnego nie działają w ten sposób. Program COBOL nie deklaruje danych wejściowych i wyjściowych w manifeście czytelnym maszynowo. Zadanie JCL nie publikuje schematu pól, które odczytuje i zapisuje w rejestrze metadanych. Usługa Java nie adnotuje każdego odwołania do pola jego koncepcyjnej relacji z kolumną bazy danych. Powiązania między odwołaniami do pól w różnych warstwach są wyrażone w samym kodzie: w poleceniach MOVE, w zapytaniach SQL osadzonych w programach, w definicjach układu plików, w sygnaturach metod usług. Śledzenie tych powiązań wymaga czytania i zrozumienia samego kodu, a nie korzystania z rejestru metadanych potoku. W kontekście analizy statycznej w systemach rozproszonych , wnioskowanie na temat przepływu danych pomiędzy komponentami złożonego systemu rozproszonego wymaga analizy strukturalnej samego kodu, a nie tylko obserwacji zewnętrznego zachowania systemu.

Warstwy, przez które przechodzi pole danych w systemie przedsiębiorstwa

Zanim możliwe będzie prześledzenie pola, konieczne jest zrozumienie warstw, przez które ono przechodzi. Systemy korporacyjne różnią się znacznie pod względem architektury, ale ruch pola przebiega zgodnie z rozpoznawalnymi wzorcami, które odpowiadają warstwom technicznym obsługiwanym przez większość dużych organizacji. Zrozumienie roli każdej warstwy w cyklu życia pola jest warunkiem wstępnym do stworzenia śladu, który jest rzeczywiście kompletny, a nie ograniczony warstwą, od której rozpoczęło się badanie.

Warstwa definicji: skąd pochodzi pole

Każde pole ma punkt początkowy: miejsce, w którym jest po raz pierwszy definiowane jako nazwany element danych z typem, długością i znaczeniem. W środowiskach COBOL jest to zazwyczaj definicja magazynu roboczego lub element copybook. W relacyjnych bazach danych jest to definicja kolumny w schemacie tabeli. W usługach Java lub .NET jest to deklaracja pola w klasie lub strukturze. W systemach opartych na komunikatach jest to pole w definicji schematu, niezależnie od tego, czy jest to JSON Schema, Avro, Protobuf czy XSD. Warstwa definicji ma znaczenie, ponieważ określa kanoniczną tożsamość pola. Pole o nazwie CUST-ID w podręczniku COBOL znajduje się autorytatywna definicja tej koncepcji w środowisku mainframe i wszystkiego, co odczytuje, zapisuje lub transformuje CUST-ID W tym środowisku jest konsumentem tej definicji. Śledzenie pola zaczyna się tutaj i podąża za odwołaniami na zewnątrz, poprzez kod, który go używa.

Pojedyncza koncepcja biznesowa często ma wiele definicji, po jednej na warstwę, połączonych transformacją. Zidentyfikowanie wszystkich reprezentacji tej samej koncepcji jest warunkiem wstępnym do pełnego śledzenia, ale nie zawsze jest to proste: konwencje nazewnictwa różnią się w zależności od zespołu i dekad, reprezentacje typów różnią się w zależności od języka, a granice koncepcyjne danej dziedziny wymagają osądu domeny, którego same zautomatyzowane narzędzia nie zawsze są w stanie zapewnić. To jeden z powodów, dla których śledzenie pól w środowiskach heterogenicznych wymaga czegoś więcej niż indeksowania. Wymaga modelu, który uwzględnia intencję, a nie tylko składnię.

Warstwa pamięci masowej: bazy danych, pliki i zestawy danych

Po wstępnym przetworzeniu wartość pola jest prawie zawsze utrwalana. W relacyjnych bazach danych znajduje się ona w kolumnie. W środowiskach mainframe może znajdować się w pliku VSAM, pliku płaskim o zdefiniowanym układzie lub bazie danych zarządzanej przez CICS lub IMS. W systemach rozproszonych może znajdować się w magazynie NoSQL, kolejce komunikatów, rozproszonej pamięci podręcznej lub systemie pamięci masowej obiektów blob. Warstwa pamięci masowej to miejsce, w którym odwołania do pól najczęściej zmieniają reprezentację: pole o nazwie CUST-ID w programie COBOL zapisuje do kolumny o nazwie CUSTOMER_ID w tabeli DB2, a usługa Java odczytuje CUSTOMER_ID z tej samej tabeli i zapisuje ją w polu obiektu o nazwie customerIdKażda z nich jest tą samą wartością, ale żadne zautomatyzowane narzędzie nie jest w stanie ustalić tej równoważności bez modelu łączącego odwołanie do pola COBOL z kolumną bazy danych i polem obiektu Java.

Warstwa pamięci masowej niesie ze sobą również ryzyko cichej transformacji. Pole przechowywane jako typ numeryczny w bazie danych i pobierane do zmiennej łańcuchowej w kodzie aplikacji przeszło transformację typu, która może, ale nie musi, zachować wszystkie informacje. Pole przechowywane w spakowanym formacie dziesiętnym w pliku COBOL i odczytywane do usługi Java wymaga jawnej konwersji, która może powodować błędy zaokrągleń, jeśli zostanie nieprawidłowo zaimplementowana. Pełny ślad pola zawiera te transformacje warstwy pamięci masowej jako jawne kroki, a nie tylko nazwy systemów po obu stronach.

Warstwa przetwarzania: programy, usługi i zadania wsadowe

Pomiędzy definicją a przechowywaniem oraz między przechowywaniem a zużyciem, wartości pól są przetwarzane. Programy obliczają z nich wartości pochodne. Usługi weryfikują je pod kątem reguł biznesowych. Zadania wsadowe agregują je, przekształcają ich format, filtrują rekordy na podstawie ich zawartości lub kierują przetwarzaniem na podstawie ich wartości. Każdy z tych kroków przetwarzania jest węzłem w śladzie pola i każdy z nich musi być zrozumiany, aby odpowiedzieć na pytania dotyczące poprawności wartości, logiki transformacji i kolejności przetwarzania. W środowiskach mainframe, warstwa przetwarzania jest miejscem, w którym znajduje się większość złożoności i, jak szczegółowo opisano w badaniu rozwiązań do analizy statycznej COBOL , rozumowanie na temat tego, co program COBOL faktycznie robi z polem, wymaga analizy składniowej i zrozumienia pełnej struktury programu, w tym logiki warunkowej, która określa, która ścieżka przetwarzania jest wykonywana dla danych wejściowych.

W warstwie przetwarzania najczęściej występują również granice międzyjęzykowe. Gdy zadanie wsadowe w języku COBOL zapisuje dane do bazy danych, a usługa Java je odczytuje, lub gdy zadanie ETL w Pythonie transformuje plik wygenerowany przez proces komputera mainframe, pole przechodzi z przetwarzania jednego języka do przetwarzania innego. Ślad pola obejmujący warstwę przetwarzania musi podążać za polem przez te przejścia, rozwiązując różne nazwy i reprezentacje, które zawiera w każdym języku, i robi to poprzez analizę strukturalną, a nie dopasowywanie ciągów znaków.

Warstwa konsumpcji: raporty, interfejsy API i systemy downstream

Na końcu podróży pola jego wartość jest konsumowana: wyświetlana w raporcie, zwracana w odpowiedzi API, wprowadzana do modelu uczenia maszynowego, publikowana w kolejce komunikatów innego systemu lub ujawniana w zgłoszeniu regulacyjnym. Te punkty zużycia mają znaczenie z dwóch powodów. Po pierwsze, definiują, kogo dotyczy, jeśli wartość pola jest nieprawidłowa lub niedostępna. Po drugie, definiują, które systemy zewnętrzne, użytkownicy i obowiązki regulacyjne zależą od pola, co określa zakres wpływu zmiany, gdy definicja lub przetwarzanie pola musi zostać zmodyfikowane. Śledzenie warstwy zużycia jest często tym, czego zespoły ds. zgodności i regulacji potrzebują najbardziej, a jak opisano w szerszym kontekście grafów zależności i ryzyka aplikacji , mapowanie tego, od czego zależy każdy komponent systemu, jest podstawą bezpiecznego zarządzania zmianą i spełniania obowiązków, które wymagają udowodnionej identyfikowalności.

Dlaczego standardowe metody śledzenia zawodzą w środowiskach korporacyjnych

Organizacje podejmujące próby śledzenia w terenie bez dedykowanych narzędzi zazwyczaj stosują połączenie wyszukiwania tekstowego, dokumentacji i ręcznej inspekcji. Każde z tych podejść ma swoje ograniczenia, które stają się dotkliwe w dużych, wielojęzycznych środowiskach korporacyjnych. Zrozumienie, gdzie i dlaczego każda metoda zawodzi, jest istotne, ponieważ metody te są tak często stosowane domyślnie, że ich przyczyny awarii często przypisuje się złożoności zadania, a nie niedoskonałościom narzędzia.

Wyszukiwanie tekstu generuje szum i pomija odniesienia

Najczęstszym punktem wyjścia do śledzenia pól jest wyszukiwanie tekstowe: znalezienie nazwy pola w kodzie źródłowym, skryptach SQL i plikach konfiguracyjnych. Wyszukiwanie tekstowe jest szybkie, dostępne wszędzie i nie wymaga specjalnych narzędzi. Jest jednak zawodne, jeśli chodzi o uzyskanie pełnego i dokładnego śledzenia pól. Problem niezawodności działa w obie strony. Wyszukiwanie tekstowe generuje zbyt wiele wyników: krótkie nazwy pól, takie jak ID, STATUSlub DATE pojawiają się w tysiącach niezwiązanych ze sobą kontekstów, a nawet w dłuższych nazwach, takich jak account_balance mogą pojawiać się w komunikatach dziennika, komentarzach i danych testowych, gdzie nie mają żadnego strukturalnego związku ze śledzonym polem. Jednocześnie wyszukiwanie tekstowe generuje zbyt mało wyników, brakuje odwołań, w których nazwa pola różni się między warstwami, odwołań wyrażonych za pomocą obliczonych kluczy lub aliasów, odwołań w generowanym kodzie oraz odwołań pośredniczonych przez dane, a nie bezpośrednio w kodzie.

Rozważ ślad WS-CUSTOMER-ID, pole w sekcji roboczej pamięci masowej języka COBOL:

kobol

WORKING-STORAGE SECTION.
   05 WS-CUSTOMER-ID   PIC X(10).

PROCEDURE DIVISION.
   MOVE CUSTOMER-RECORD-ID TO WS-CUSTOMER-ID.
   EXEC SQL
       INSERT INTO CUSTOMER_AUDIT
           (CUST_ID, AUDIT_TS)
       VALUES (:WS-CUSTOMER-ID, CURRENT TIMESTAMP)
   END-EXEC.

Wyszukiwanie tekstu WS-CUSTOMER-ID Znajduje definicję pamięci roboczej i odniesienia w tym programie. Nie znajduje:

• Kolumna bazy danych CUST_ID który odbiera wartość pola poprzez osadzony kod SQL INSERT
• Usługa Java, która odczytuje CUST_ID od CUSTOMER_AUDIT i zapisuje jako customerId
• Odpowiedź API, która serializuje customerId as customer_id w formacie JSON dla odbiorców końcowych
• Raport lub pulpit nawigacyjny, który ostatecznie przedstawia tę wartość użytkownikom końcowym

Każde z tych połączeń wymaga innego rodzaju analizy: analizy SQL, mapowania schematów, analizy Java AST i inspekcji kontraktów API. Wyszukiwanie tekstowe nie zapewnia żadnej z tych funkcji, a jego zestaw wyników nie wskazuje, że te połączenia istnieją i zostały pominięte.

Dokumentacja staje się nieaktualna zanim zostanie ukończona

W obliczu braku zautomatyzowanych narzędzi organizacje często polegają na ręcznie prowadzonej dokumentacji: słownikach danych, arkuszach kalkulacyjnych mapowania pól, diagramach przepływu danych i dokumentach architektonicznych. Te artefakty są cenne, gdy są dokładne i aktualne. Rzadko kiedy oba te elementy występują jednocześnie. Problem nie polega na tym, że zespoły dokumentacyjne są niedbałe. Chodzi o to, że tempo zmian w kodzie i pracochłonność ręcznej dokumentacji są zasadniczo niekompatybilne w skali przedsiębiorstwa. Pole dodane do trzech nowych usług w jednym sprincie wymaga aktualizacji każdego słownika danych, każdego diagramu przepływu i każdego arkusza kalkulacyjnego mapowania opisującego systemy, z którymi te usługi współdziałają. W praktyce niektóre z tych aktualizacji są pomijane. Dokumentacja odbiega od rzeczywistości, staje się niewiarygodna jako punkt odniesienia i jest stopniowo porzucana. Projekty modernizacji starszych systemów konsekwentnie identyfikują niedokładną lub brakującą dokumentację jako jeden z głównych czynników ryzyka, właśnie dlatego, że bezpieczna modernizacja wymaga znajomości funkcji każdego komponentu i jego zależności, a dokumentacji nie można ufać, że zapewni tę wiedzę w sposób niezawodny.

Ręczna inspekcja nie jest skalowalna

Ręczna inspekcja kodu to podejście o najwyższej wierności do śledzenia pól: programista czyta kod źródłowy, śledzi referencje i buduje mentalny model cyklu życia pola. W przypadku pojedynczego pola w pojedynczym programie, to rozwiązanie sprawdza się dobrze. W przypadku pola, które pojawia się w pięćdziesięciu programach w trzech językach i na dwóch platformach, ręczna inspekcja staje się wielodniowym ćwiczeniem, które wciąż jest niekompletne, ponieważ żadna osoba nie jest w stanie jednocześnie zrozumieć tak dużego kontekstu. W przypadku pola, które jest w produkcji od dwudziestu lat i z którym pracowały setki programistów, ręczna inspekcja nie jest realistyczną opcją dla żadnego zadania z terminami. Koszt organizacyjny wykracza poza czas, jaki pochłania: wiedza zdobyta dzięki ręcznej inspekcji znajduje się w osobie, która ją wykonała, a nie w artefakcie, który można udostępniać. Nie jest przeszukiwalna, niemożliwa do przeniesienia ani zweryfikowania. Następna osoba, która musi prześledzić to samo pole, zaczyna od tej samej pustej linii bazowej i powtarza tę samą pracę. To właśnie ten strukturalny schemat, który narzędzia do śledzenia pól mają na celu przełamać.

Jak w praktyce powinien działać ujednolicony ślad pola

Pełny ślad pola w systemie przedsiębiorstwa wymaga narzędzia, które zindeksowało cały system na poziomie strukturalnym: przeanalizowało każdy artefakt źródłowy w każdym języku, zbudowało model symboli i relacji zawartych w tych artefaktach oraz rozwiązało powiązania międzyjęzykowe i międzywarstwowe, które łączą odwołania do pól w granicach systemu. Po wdrożeniu tego modelu ślad pola to zapytanie grafu, które podąża za krawędziami zależności od węzła początkowego na zewnątrz, w dowolnym kierunku wymaganym przez pytanie. Zapytanie zwraca określone artefakty, określone odwołania do linii i określone typy relacji, a nie listę plików do ręcznej inspekcji.

Rozpoczęcie śledzenia: wybór właściwego punktu kotwiczenia

Ślad pola rozpoczyna się w punkcie zakotwiczenia: konkretnym odwołaniu do pola w konkretnym artefakcie. Kotwicą może być kanoniczna definicja pola, taka jak element copybook, schemat kolumny bazy danych lub deklaracja pola klasy Java, albo zaobserwowane użycie w konkretnym programie, który jest aktualnie przedmiotem badania. Wybór właściwej kotwicy ma znaczenie, ponieważ określa początkowy kierunek śladu. W analizie wpływu kotwicą jest zazwyczaj definicja, a śledzenie od niej w przód wylicza każdego konsumenta, na którego wpłynie zmiana. W analizie przyczyn źródłowych kotwicą jest zazwyczaj nieprawidłowa wartość zaobserwowana w punkcie konsumpcji, a śledzenie wstecz od niej podąża za łańcuchem przetwarzania w górę rzeki, w kierunku źródła błędu. W mapowaniu zgodności ślad jest dwukierunkowy: znajduje każdy system, który przechowuje, przetwarza lub udostępnia pole, niezależnie od kierunku.

Podążanie śladem przez każdą warstwę

Od punktu kotwicznego ślad podąża za odniesieniami pól przez każdą warstwę systemu w odpowiednim kierunku. Aby to przejście było dokładne i kompletne, musi być realizowanych kilka odrębnych kroków rozwiązywania:

W ramach jednego programu: rozwiązywanie odwołań do pól w jednym pliku źródłowym, w tym definicji, operacji odczytu, zapisu, transformacji i użycia warunkowego. W języku COBOL oznacza to zrozumienie instrukcji MOVE, COMPUTE, klauzul REDEFINES oraz przepływu danych na poziomie akapitu. W Javie oznacza to rozwiązywanie odwołań do pól, wywołań metod przekazujących lub zwracających pole oraz wyrażeń transformacyjnych.

Między programami w ramach tego samego języka: określanie, jak zmienia się wartość pola, gdy jeden program wywołuje inny, przesyła dane przez współdzielony plik lub zbiór danych lub zapisuje je do współdzielonej warstwy pamięci masowej. W środowiskach COBOL obejmuje to określanie odwołań do copybooków w celu znalezienia wszystkich programów, które współdzielą definicję pola, oraz śledzenie dostępu do plików VSAM w celu znalezienia wszystkich programów, które odczytują lub zapisują ten sam układ pliku.

Przekraczając granice językowe: rozwiązywanie powiązań międzyjęzykowych, w których wartość pola jest przenoszona z programu COBOL do kolumny bazy danych, z kolumny bazy danych do pola obiektu Java, z obiektu Java do odpowiedzi API JSON lub z dowolnej innej reprezentacji języka źródłowego do reprezentacji języka docelowego. Wymaga to ujednoliconego modelu, który reprezentuje odwołania do pól ze wszystkich języków we wspólnej strukturze i rozwiązuje równoważności koncepcyjne między różnymi reprezentacjami tej samej koncepcji biznesowej.

Ponad granicami systemów i platform: śledzenie pola poprzez interfejsy międzysystemowe, w tym kolejki komunikatów, transfery plików, przekazywanie zadań wsadowych i wywołania API. Te połączenia międzysystemowe są często najtrudniejsze do automatycznego śledzenia, ponieważ mogą być wyrażone w konfiguracji, a nie w kodzie, lub poprzez konwencje nazewnictwa środowiska wykonawczego, które nie są reprezentowane w żadnym statycznym artefakcie.

Rozwiązywanie ekwiwalencji pól międzyjęzykowych

Krokiem, który najczęściej zawodzi w praktyce, jest rozwiązanie równoważności pól międzyjęzykowych: ustalenie, że WS-CUSTOMER-ID w COBOL-u, CUST_ID w kolumnie DB2 i customerId W obiekcie Java wszystkie reprezentacje tej samej koncepcji biznesowej. Bez tej równoważności ślad, który dociera do granicy między COBOL-em a bazą danych, nie może kontynuować do warstwy Java. Najbardziej niezawodnym podejściem do ustalenia tych równoważności jest analiza strukturalna kodu wypełniającego pole docelowe. Podczas wykonywania programu COBOL INSERT INTO CUSTOMER_AUDIT (CUST_ID) VALUES (:WS-CUSTOMER-ID)analiza strukturalna instrukcji SQL bezpośrednio ustala, że CUST_ID otrzymuje swoją wartość z WS-CUSTOMER-IDTo połączenie staje się krawędzią w grafie śladu pola, a ślad jest kontynuowany po stronie bazy danych.

Poniższa tabela pokazuje, jak wygląda kompletny ślad pola jako ustrukturyzowana sekwencja kroków rozwiązywania dla reprezentatywnego pola:

Krok śledzenia	Artefakt źródłowy	Artefakt docelowy	Rodzaj połączenia
1. Zeszyt do programowania	CUSTCOPY członek kopii CUST-ID	Program COBOL CUSTINQ	Odniesienie do oświadczenia COPY
2. Program do bazy danych	Zmienna hosta COBOL :WS-CUSTOMER-ID	Kolumna DB2 CUST_ID in CUSTOMER_AUDIT	Wbudowany SQL INSERT
3. Baza danych do obsługi	DB2 CUST_ID	Pole Java customerId in CustomerAuditService	Mapowanie zestawu wyników JDBC
4. Usługa dla API	Java customerId	Pole JSON customer_id w odpowiedzi REST	Serializacja Jacksona
5. API do raportowania	JSON customer_id	Wymiar pulpitu nawigacyjnego Customer Identifier	Konsumpcja API przez warstwę BI

Najważniejsze przypadki użycia śledzenia danych w terenie w przedsiębiorstwie

Śledzenie w terenie nie jest ćwiczeniem akademickim. To praktyczna umiejętność, która określa, jak szybko i precyzyjnie organizacja może reagować na konkretne, ryzykowne sytuacje, które pojawiają się rutynowo w dużych, wielowarstwowych systemach korporacyjnych. Poniższe przypadki przedstawiają scenariusze, w których brak śledzenia w terenie wiąże się z najbardziej bezpośrednimi i mierzalnymi kosztami.

Analiza wpływu zmiany schematu

Zmiany schematu należą do najczęstszych źródeł incydentów produkcyjnych w systemach korporacyjnych. Zmiana nazwy kolumny, usunięcie kolumny, zmiana typu danych lub wydłużenie jej długości: każda z tych modyfikacji schematu bazy danych może dyskretnie przerwać działanie każdego programu, usługi lub raportu odwołującego się do danej kolumny, bez wcześniejszego ostrzeżenia o błędzie kompilacji. W dużym systemie, w którym do kolumny odwołują się dziesiątki programów w wielu językach, jedynym sposobem na bezpieczne wykonanie zmiany schematu jest enumeracja każdego odwołania przed wprowadzeniem zmiany i sprawdzenie, czy każdy konsument został zaktualizowany przed wdrożeniem. Śledzenie na poziomie pola zapewnia tę enumerację: ślad od kolumny bazy danych na zewnątrz przez cały kod konsumenta identyfikuje każdy program, usługę, zadanie wsadowe i raport, które należy przejrzeć, zwracając określone lokalizacje plików i numery wierszy, a nie listę systemów. Jak zbadano w kontekście analizy wpływu modernizacji przedsiębiorstwa , wiedza przed wprowadzeniem zmiany o tym, czego dokładnie ona dotyczy, stanowi fundamentalną możliwość prac modernizacyjnych, które nie stwarzają nowego ryzyka produkcyjnego, a jednocześnie rozwiązują istniejące problemy.

Zgodność z przepisami i prawa osób, których dane dotyczą

Przepisy dotyczące ochrony danych, w tym RODO, HIPAA i CCPA, nakładają obowiązki, które wymagają śledzenia na poziomie pól. Wniosek o prawo do usunięcia danych zgodnie z RODO wymaga zidentyfikowania i usunięcia każdego zbioru pól danych osobowych osoby wnioskującej we wszystkich systemach. Audyt HIPAA wymaga wykazania, że ​​pola chronionych informacji medycznych są dostępne wyłącznie dla upoważnionych systemów i personelu. Ocena BCBS 239 wymaga udowodnienia, że ​​określone metryki ryzyka są obliczane spójnie na podstawie udokumentowanych pól źródłowych poprzez udokumentowane transformacje. Żadnego z tych obowiązków nie można spełnić poprzez pochodzenie na poziomie tabeli, ponieważ obowiązek dotyczy określonych pól, a nie całych tabel. Śledzenie na poziomie pól informuje zespoły ds. zgodności, które kolumny, w których programach i w których systemach przechowują i przetwarzają określone pola będące przedmiotem wniosku, a ta szczegółowość decyduje o tym, czy odpowiedź na żądanie zgodności jest kompletna i możliwa do audytu, czy niekompletna i możliwa do obrony jedynie poprzez poświadczenie.

Analiza przyczyn źródłowych incydentów związanych z jakością danych

W przypadku wystąpienia incydentu związanego z jakością danych, niezależnie od tego, czy chodzi o pulpit nawigacyjny wyświetlający nieprawidłowe sumy, raport zawierający rekordy z nieprawidłowymi wartościami, czy API zwracające nieoczekiwane wartości null, dochodzenie rozpoczyna się od śledzenia wstecz: prześledzenia wartości pola od punktu wystąpienia błędu przez każdą transformację, która go wygenerowała, aż do zidentyfikowania źródła błędu. Bez narzędzi do śledzenia na poziomie pola, to dochodzenie jest zadaniem manualnym, które w dużym systemie może zająć kilka dni. Deweloper badający nieprawidłową wartość w odpowiedzi API Java musi ręcznie prześledzić kod Java, zapytanie do bazy danych, proces ETL lub zadanie wsadowe, które wypełniło kolumnę bazy danych, a potencjalnie także przetwarzanie wsadowe, zanim znajdzie obliczenie, które spowodowało błąd. Każde przejście między warstwami to ręczne przełączenie kontekstu na inną bazę kodu i potencjalnie inny zespół. Jak opisano w kontekście skrócenia średniego czasu odzyskiwania poprzez indeksowanie zależności , skrócenie czasu badania incydentu, możliwe dzięki automatycznemu śledzeniu zależności, jest najbardziej odczuwalne w dochodzeniach dotyczących jakości danych, gdzie czas badania ma znacznie większy wpływ na czas trwania incydentu niż czas naprawy.

Bezpieczna zmiana nazw i wycofywanie pól

Zmiana nazwy pola lub wycofanie definicji pola wymaga znajomości każdej lokalizacji używającej bieżącej nazwy przed wprowadzeniem zmiany. W kodzie jednojęzycznym i jednorepozycyjnym narzędzia refaktoryzacji IDE radzą sobie z tym niezawodnie. W wielojęzycznym systemie korporacyjnym zmiana nazwy przekracza granice językowe, gdzie żadne pojedyncze narzędzie nie ma pełnego wglądu: pole przemianowane w copybooku COBOL musi zostać zaktualizowane w każdym programie COBOL odwołującym się do copybooka, w każdym zapytaniu SQL używającym odpowiedniej nazwy kolumny, w każdej usłudze Java, która mapuje kolumnę na pole obiektu, oraz w każdym odbiorcy tych usług. Ślad na poziomie pola dostarcza pełną listę odniesień przed rozpoczęciem zmiany nazwy, umożliwiając zespołom programistycznym wcześniejsze przejrzenie listy odniesień i wdrożenie z pewnością, że zmiana nazwy została ukończona. To samo dotyczy wycofywania pól: ślad wycofanego pola identyfikuje, którzy odbiorcy nadal od niego zależą, a zatem których odbiorców należy zmigrować, aby bezpiecznie zakończyć proces wycofywania.

W jaki sposób SMART TS XL Buduje kompletny ślad na poziomie pola

SMART TS XL Konstruuje ujednolicony model odwołań krzyżowych całego systemu przedsiębiorstwa, pobierając kod źródłowy z każdego języka i platformy w środowisku i analizując każdy z nich za pomocą analizy specyficznej dla danego języka. Programy COBOL, strumienie zadań JCL, schematy DB2 i SQL, usługi Java, aplikacje .NET, skrypty Pythona oraz artefakty konfiguracji XML i JSON są przetwarzane na wspólny graf symboli i relacji. Odwołania do pól w każdym języku są reprezentowane jako węzły na tym grafie, a relacje między nimi, w tym definicje, odczyty, zapisy, transformacje i równoważności międzyjęzykowe, są reprezentowane jako krawędzie typizowane. Ten graf stanowi podstawę każdego śledzenia pól wykonywanego przez platformę.

Śledzenie na poziomie pola w SMART TS XL to przejście grafu od dowolnego węzła odniesienia pola na grafie, podążające krawędziami w kierunku odpowiednim dla zadawanego pytania. Śledzenie do przodu z elementu copybook języka COBOL zwraca każdy program zawierający copybook, każde polecenie SQL w tych programach, które odwołuje się do odpowiedniej kolumny, każdą tabelę, która otrzymuje wartość kolumny, każdą usługę odczytującą z tej tabeli oraz każdą odpowiedź API lub raport, który udostępnia pole zewnętrznym użytkownikom. Przejście automatycznie przekracza granice językowe, ponieważ równoważności międzyjęzykowe są ustalane podczas indeksowania, a nie w trakcie zapytania. Funkcja wyszukiwania korporacyjnego platformy stanowi punkt wejścia do śledzenia pól: programista lub analityk wyszukujący nazwę pola w indeksowanym systemie otrzymuje wyniki uporządkowane według typu artefaktu, języka i typu relacji, z definicjami, odczytami, zapisami, odwołaniami SQL, inkluzjami copybook i ekspozycjami API, wyróżnionymi w zestawie wyników. Jak opisano w rozwiązania wyszukiwania korporacyjnego Platforma została zaprojektowana specjalnie z myślą o wyszukiwaniu wszystkich miejsc, w których używane jest pole, w całym portfolio aplikacji. Jest to funkcja, która bezpośrednio i na dużą skalę rozwiązuje problem śledzenia pól w przedsiębiorstwie.

SMART TS XLAnaliza wpływu kończy proces śledzenia pól, automatycznie odpowiadając na pytanie „w przód”. Gdy pole w kopii zapasowej, schemacie bazy danych lub interfejsie usługi zostanie oznaczone do zmiany, platforma oblicza pełny wykres wpływu i prezentuje go w postaci nawigowalnego raportu z odniesieniami, uporządkowanego według warstw i konkretnych lokalizacji odniesienia. To przekształca najbardziej czasochłonną część śledzenia pól, czyli wyliczenie każdego odbiorcy przed wprowadzeniem zmiany, z ręcznego dochodzenia w ustrukturyzowany wynik zapytania, który może uruchomić, zinterpretować i na podstawie którego może działać każdy członek zespołu. Jak zbadano w kontekście topologia zależności i sekwencjonowanie modernizacji, możliwość dokładnego określenia skutków zmiany przed jej wprowadzeniem jest podstawowym wymogiem prac modernizacyjnych, które polegają na zarządzaniu ryzykiem, a nie na jego tworzeniu.

Śledzenie w terenie jako zdolność ciągła, a nie działanie projektowe

Najważniejszą kwestią dotyczącą śledzenia zdarzeń w terenie w przedsiębiorstwie jest to, że musi ono stanowić ciągłą funkcjonalność wbudowaną w proces rozwoju i operacji, a nie dochodzenie w trybie projektowym, uruchamiane przez incydenty lub terminy zgodności. Gdy śledzenie zdarzeń w terenie ma charakter reaktywny, koszt dochodzenia spada na zespoły znajdujące się pod największą presją czasu: programistów rozwiązujących incydent produkcyjny, zespół ds. zgodności przygotowujący się do audytu, architektów planujących migrację w ramach terminu dostawy. Dochodzenie pochłania czas potrzebny na naprawę, wzmacniając wpływ każdego zdarzenia, które tego wymaga.

Gdy śledzenie pól jest funkcją ciągłą, utrzymywaną w zawsze aktualnym modelu systemu, badanie zostało już przeprowadzone. Relacje pól we wszystkich warstwach są dostępne natychmiast, bez wstępnej fazy analizy. Zmiany schematu są oceniane przed wdrożeniem, a nie wykrywane po nim. Odpowiedzi na pytania dotyczące zgodności udzielane są z poziomu modelu, a nie poprzez ręczną rekonstrukcję. Badanie przyczyn źródłowych rozpoczyna się od śledzenia pól, a nie od wyszukiwania tekstu i komunikacji zespołowej. Utrzymanie tego zawsze aktualnego modelu wymaga narzędzia, które stale indeksuje system w miarę zmian w kodzie, stopniowo aktualizuje model odniesień i utrzymuje dokładność relacji na poziomie pól we wszystkich warstwach. Budowanie takiej funkcji to sensowna inwestycja. Alternatywą jest ponoszenie kosztów ręcznego śledzenia pól za każdym razem, gdy jest to wymagane w całej organizacji działającej na skalę przedsiębiorstwa, co stale generuje wyższe koszty i nadal rośnie wraz z rozwojem systemu.