Formowanie danych w przedsiębiorstwie

Coraz częściej przedsiębiorstwa muszą borykać się z problemem ujednolicania danych rozproszonych w sieci, wynikającym z konieczności przechodzenia na architektury oparte na usługach

Coraz częściej przedsiębiorstwa muszą borykać się z problemem ujednolicania danych rozproszonych w sieci, wynikającym z konieczności przechodzenia na architektury oparte na usługach

Integracja danych to zajęcie wymagające skrupulatności, trudne do zautomatyzowania, a także trudne do oceny w kategoriach ekonomicznych. Jednak jest ona niezbędna dla zapewniania współpracy różnych systemów, a także jako element migracji do nowych narzędzi lub konsolidacji istniejących zasobów.

Ogromny wolumen cennych danych w przedsiębiorstwie jest trzymany w archiwach pamięci masowych lub w katalogach przypisanych poszczególnym aplikacjom. Takie aplikacje określają semantykę danych - "wiedzą", co te dane znaczą i co oznaczają wyniki ich przetwarzania. Tworzą w ten sposób spójny (zazwyczaj lokalnie) model danych. Kiedy jednak przedsiębiorstwo łączy i dopasowuje funkcje w ramach różnych aplikacji, łączone są również modele danych. Im bardziej rozproszone są dane, tym problem jest większy. Dane istnieją zawsze w jakimś kontekście, nawet jeżeli jakieś pole danych jest puste, to różne aplikacje przyjmują odmienne znaczenie tej osobliwości.

W rezultacie, jeżeli dane są przypisane do aplikacji, czyli swoiście "ostemplowane", to zestaw zintegrowanych aplikacji czy usług staje się mało elastyczny i trudny do modyfikowania. Aby zrozumieć nie tylko oryginalne komponenty danych, ale też to, jak były one transformowane na swojej drodze, koniecznym jest prześledzenie wielu powiązań. Jednym z rozwiązań problemu "ostemplowania" jest zapewnienie danych potrzebnych wielu aplikacjom w formie usług, włączających kontekstowe metadane tam, gdzie jest to potrzebne i godzących rozbieżności interpretacyjne istniejące pomiędzy rozproszonymi źródłami danych.

Wymogi architektury usługowej

Podwójną korzyścią, jaką daje SOA (Services Oriented Architecture), jest po pierwsze fakt, iż tworzenie usług wykonujących często używane funkcje zmniejsza nakłady w obszarze projektowania aplikacji, a po drugie, wykorzystując standaryzowane interfejsy, udostępnia funkcjonalność aplikacyjną dostępną w różnych systemach. Luźno powiązana, abstrakcyjna natura SOA ma daleko idące implikacje w odniesieniu do danych używanych, przetwarzanych i tworzonych przez usługi.

Kiedy usługi wymieniają między sobą dane, pojawiają się potencjalne problemy ze strony danych niepasujących lub niepowiązanych z transformacjami.

Wielu analityków rozwiązania tego problemu upatruje w projektowaniu poziomu "usług danych", który kataloguje dane w formie przydatnej do użycia i przedstawia ich kontekst innym usługom. Takie podejście pozwala na oddzielenie logiki danych od logiki biznesowej i traktuje dostęp do danych oraz operacje na nich jako oddzielny zestaw usług wywoływanych przez procesy biznesowe. Bez takiego podejścia luźno powiązane procesy biznesowe zdają się na ściśle powiązane z nimi dane, eliminując istotne korzyści, jakie przynosi, właściwe dla SOA, właśnie luźne powiązanie procesów.

Takie podejście to zmiana w stosunku do wcześniejszych prób integracji danych. Integracje danych rozwiązywano przez rozbudowane kontrole w krytycznych "punktach zbiorczych", które dławiły przepływ danych. SOA eliminuje takie "wąskie gardła" - integracja danych może mieć miejsce wszędzie, co oznacza, że każdy punkt dostępu do danych jest zdolny do transformowania i zarządzania danymi.

SOA wnosi także problemy współbieżności - dane zmieniające się w czasie procesu mogą wpływać na wyniki, zwłaszcza w aplikacjach kompozytowych, kiedy wiele usług sięga do danych w różnym czasie. W takim wypadku dobrym rozwiązaniem jest monitorowanie usług lub stosowanie usług powiadamiającym inne usługi o pojawiających się zmianach danych, co umożliwia rozstrzygnięcie czy restartować proces, czy dostosować jego przetwarzanie.

Co więcej, im bardziej szczegółowe są usługi danych, tym większy jest wpływ ich aranżacji na proces, co może spowodować wydłużenie czasu odpowiedzi i stwarzać problemy synchronizacji.

Innym problemem z danymi SOA jest efekt "śnieżnej kuli", który pojawia się, gdy usługi przekazują kontekst operacji na danych do kolejnej usługi w aplikacjach kompozytowych.

Publikowanie takich transformacji może pomóc dalszym usługom w zrozumieniu kontekstu danych, z którymi pracują. Może też jednak zadławić system przyrostowo powiększającą się informacją i spowodować spowolnienie usługi. Koniecznym jest więc uważne rozważenie, ile kontekstu trzeba przekazywać w formie zagregowanych parametrów.

Renesans Master Data

Z wprowadzaniem usługowej architektury aplikacji przedsiębiorstwa (SOA) nieuchronnie łączy się stary problem: kiepski stan danych większości organizacji. W latach 90. hurtownie danych i repozytoria danych w przedsiębiorstwach uważano za sposób rozwiązania problemu gromadzących się stale danych, ale systemy te stały się szybko niesprawnymi składowiskami danych.

Dzisiaj stawia się na podejście modularne - określane jako Master Data Management (MDM) - wykorzystujące aranżacje do racjonalizacji danych porozrzucanych w różnych formatach i repozytoriach w całym przedsiębiorstwie. Termin ten dotyczy systemów technologii i metod zarządzania danymi podstawowymi w ramach przedsiębiorstwa.

Rozwój SOA zmusza dostawców do udoskonalania narzędzi pod kątem uproszczenia zarządzania danymi zarówno dla środowisk SOA, jak i niezwiązanych z SOA. Wielu z nich promuje narzędzia MDM, mające zapewniać aplikacjom czy usługom używanie właściwych, aktualnych danych w poprawnym kontekście. Master Data - dane główne lub podstawowe - zawierają nie tylko same dane, ale też atrybuty, semantykę i kontekst (metadane) niezbędne do opisania ich znaczenia w celu zapewnienia właściwego ich użycia przez różne systemy (niektórzy dostawcy nazywają takie rozwiązanie EII - Enterprise Information Integration).

Chociaż koncepcja nie jest nowa, to dotychczas w znacznym stopniu ograniczała się do systemów danych "post factum", takich jak hurtownie danych i BI (Business Intelligence).

Określenie "dane główne" odnosi się do zasobów danych istniejących w ramach przedsiębiorstwa (korporacji) - informacji o klientach, produktach, elementach zaopatrzenia, dostawcach, lokalizacjach i innych związanych z działalnością biznesową. Są to komponenty definiujące przedsiębiorstwo - czym się zajmuje, gdzie jest zlokalizowane, kto z nim współpracuje, co sprzedaje, kupuje i wytwarza. Inaczej mówiąc master data to dane podstawowe, na których opierają się pozostałe dane.

Pozostałe typy informacji, istniejące w ramach przedsiębiorstwa, takie jak informacje o transakcjach, dane analityczne czy zawarte w operacyjnych bazach danych, wywodzą się lub opierają się na tych właśnie "danych podstawowych".

Historycznie rzecz ujmując, w czasach mainframe wszystkie dane zintegrowane były w jednym centralnym komputerze. Zbiór plików, określany jako pliki główne, zawierał informacje o danych głównych. Wszystkie aplikacje i programy korzystały z tego wspólnego zbioru plików. Ponieważ pliki główne były scentralizowane, to można było uzyskać większą kontrolę nad ich zarządzaniem. Pojedyncza kopia zapewniała spójność wszystkich aplikacji.

Z biegiem czasu przedsiębiorstwa zaczęły decentralizować aplikacje i kupować je od różnych dostawców, co spowodowało również decentralizację danych. Pojawienie się systemów marketingowych oznaczało, że informacje o klientach i produktach były definiowane do specyficznego użytku, jednocześnie systemy rozwojowe i projektowe (takie jak systemy zarządzania cyklem życia produktów) także miały ustalone definicje produktów czy materiałów zaopatrzenia.

Problem zaostrzał się, kiedy wiele oddziałów i jednostek biznesowych miało podobne systemy - sytuacja ta mogła być konsekwencją różnych fuzji i przejęć. Często też wiele instancji aplikacji ERP istniało z powodu rozmiarów firmy.

Problemy te mogą być częściowo rozwiązane przez zastosowanie architektury integracyjnej, która wykorzystuje transfer plików lub transfer w czasie rzeczywistym pomiędzy systemami. Jednak złożoność interfejsów i połączeń punk-punkt generuje dodatkowe, niemałe koszty. Ponadto w takim scenariuszu pracownikom jest bardzo trudno uzyskać kompleksową informację. Na przykład uzyskanie kompletnej informacji definiującej klienta - z adresem, lokalizacją, sposobem płatności, kontaktami i metodami dostaw, wymaga od pracownika uzyskania dostępu do wielu systemów, włączając w to ERP, systemy dystrybucyjne, dostaw i CRM.

Przed pojawieniem się SOA przedsiębiorstwa mogły sięgać do historycznych danych bez martwienia się o dane podstawowe, ponieważ większość informacji rezydowała w zestawach aplikacji, których dostawcy stosowali własną, często ukrytą, wewnętrzną architekturę danych podstawowych. Tak więc wystarczyło skupić się na transmisji przetworzonych lub surowych danych pomiędzy zestawami aplikacji - tworząc różne konektory - i pozwolić aplikacjom na obsługiwanie większości spraw związanych z kontekstem.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200