Inteca

11 02 Rekomendacja D 8,Wytyczna IT 8 – Zarządzanie Architekturą Danych

2015.10.04

Architektura Danych jest częścią Architektury Korporacyjnej. Integruje się z Architekturą Biznesową, Aplikacji i Technologiczną. Architektura Danych wspiera organizację w realizacji zmian biznesowych, poprawia efektywność, zwinność oraz zwiększa przejrzystość ładu organizacyjnego.

Proces zarządzanie Architekturą Danych rozpoczyna się w momencie pojawienia się w organizacji nowego konceptu, który jest ważny z perspektywy działania organizacji. Konceptem tym może być coś fizycznego, jak klient lub bardziej abstrakcyjnego, jak produkt finansowy czy faktura. Pierwszym i najważniejszym krokiem procesu Zarządzania Architekturą Korporacyjną jest ustalenie w organizacji wspólnego nazewnictwa i definicji dla nowego konceptu oraz zamknięcie go w oznaczonych granicach. Granice powinny zapewniać rozdzielność od wszystkich innych konceptów zidentyfikowanych w organizacji. Tak opisany byt nazywamy obiektem biznesowym. Mając uzgodnioną definicję nowego bytu przechodzimy do osadzenia go w Architekturze Biznesowej. W tym celu definiujemy relację do innych obiektów biznesowych, procesów biznesowych, aktorów biznesowych oraz usług biznesowych. Do wykonania tego kroku najlepiej użyć narzędzia wspierającego modelowanie w języku Archimate 2.0 oraz pozwalającego złożyć wyniki prac w repozytorium. Stworzona struktura definiuje Architekturę Biznesową. W kolejnym kroku należy wyznaczyć obiekty biznesowe, które będą przetwarzane w aplikacjach IT. Każdemu takiemu obiektowi biznesowemu należy przyporządkować stworzony lub istniejący już Obiektu Danych i umiejscowić go w Architekturze Aplikacji. Obiekty danych należy połączyć odpowiednimi relacjami z aplikacjami. W szczególnych wypadkach, jeżeli zamierzamy zarządzać jakością danych i architekturą danych w jednym miejscu, relacje należy wyprowadzić bezpośrednio do usług aplikacji. Na usługach aplikacji będziemy rozmieszczać zabezpieczenia zapewniające jakość danych. Relacje między aplikacjami IT, usługami aplikacji oraz obiektami danych stanowią definicję architektury aplikacji w najprostszej postaci. W kontekście standardów przetwarzania danych, wymaganych przez KNF, należy również stworzyć Architekturę Technologiczną. W tym celu każdej aplikacji IT, zdefiniowanej w Architekturze Aplikacji, przypisujemy komponent technologiczny w Architekturze Technologicznej. Każdy komponent technologiczny definiuje odrębną kategorię narzędzi. Możemy do niego przypisać preferowane implementacja narzędzia, standardy czy protokoły do integracji. Wszystkie trzy domeny: biznesowa, aplikacyjna i technologiczna wraz ze zdefiniowanymi architektonicznymi blokami stanowią Architekturę Korporacyjną. Podsumowując, definicja Architektury Danych na poziomie Architektury Korporacyjnej, ogranicza się do definicji obiektów biznesowych, obiektów danych i ich relacji z pozostałymi blokami architektonicznymi. Poziom ten często nazywany jest poziomem konceptualnym. Jest on wystarczający, aby uchwycić wszystkie potrzeby biznesu związane z informacją oraz danymi na poziomie planowania strategicznego. Całość omówionych czynności dzieje się w czasie procesu definiowania strategii biznesowej oraz w etapie wizji architektury procesu definicji Architektury Korporacyjnej. Otrzymany produkt jest krytyczny z perspektywy dalszych działań projektowych oraz stanowi odniesienie dla analiz i przyszłych zmian strategii. Liczba obiektów biznesowych oraz obiektów danych w dużych organizacjach jest znaczna. W związku z tym należy przygotować odpowiednią taksonomię dla zdefiniowanych obiektów. Taksonomia powinna definiować obszary zrozumiałe przez biznes i być zorientowana informacyjnie. Orientacja na informację pozwoli jednoznacznie przypisać obiekt biznesowy oraz obiekt danych do jednego obszaru oraz automatycznie wyznaczyć granicę aplikacji IT, która w późniejszym okresie będzie implementować dany obszar. W naszych projektach często do definicji obszarów danych wykorzystujemy standard BIAN – Bank Industry Architecture Network. Obszary danych, poza klasyfikacją obiektów danych i informacyjnych, pełnią istotną role w ładzie IT. To właśnie na ich poziomie odbywa się przydzielanie stewardów, custodiana oraz często właściciela danych.
Omówmy kilka kluczowych cech konceptualnego modelu danych. Modele konceptualne nie zawierają definicji atrybutów. W modelu konceptualny mogą wystąpić relację wiele-do-wielu pomiędzy obiektami biznesowymi oraz pomiędzy obiektami danych. Ponieważ model konceptualny nie zawiera atrybutów, nie wykonujemy na nim normalizacji. W skład modelu konceptualnego wchodzi glosariusz biznesowy, zawierający definicję oraz meta-dane relacji, obiektów biznesowych oraz obiektów danych. Finalnie, model danych powinien być zrozumiały przez biznes oraz służyć w implementacji aplikacji IT, zarówno transakcyjnych jak i analitycznych.
Kolejnym poziomem w Architekturze Danych jest poziom logicznego modelu danych, który tworzy się dla wybranych grup danych. KNF wymaga, aby taki model został opracowany dla istotnych grup danych. Tworzy się go zazwyczaj przy wykorzystaniu narzędzi wspierających modelowanie w języku UML. Każdemu obiektowi danych, w wybranej grupy danych na poziomie konceptualnym, przyporządkowuje się odpowiednie klasy danych na poziomie logicznym. Na diagramach klas ujawnia się kluczowe atrybuty. Reprezentują one uzgodnione wymagania i ustandaryzowane definicje. Logiczny model danych, tak jak i konceptualny model danych, ma charakter organizacyjny. Czyli jest rozwijany z perspektywy całej organizacji – neutralnie i niezależnie wobec kontekstu aplikacji IT. Należy również pamiętać, że logiczny model danych ma swoje odpowiedniki, które są z niego wyprowadzane i rozwijane w ramach projektów. W tym kontekście, o logicznym modelu danych rozwijanym na potrzeby organizacji mówimy jako o kanonicznym modelu danych, a o modelach rozwijanym na potrzeby projektu, jako o aplikacyjnych/projektowych logicznych modelach danych. Model kanoniczny zasila model projektowy przed uruchomieniem projektu. Następnie, w czasie trwania projektu, jest z nim uzgadniany. Finalnie, na zakończenie projektu, aktualizuje się model kanoniczny o nowe i zmienione obiekty danych powstałe w projekcie.
W procesie Zarządzania Architekturą Danych, oprócz definiowania bloków architektonicznych, należy opracować elementy ładu korporacyjnego, powiązanego z zarządzaniem danymi. Wspomnieliśmy już o kilku rolach, takich jak właściciel danych, steward czy custodian. Oprócz tych ról, w minimalnym zakresie wdrożenia, należy zdefiniować dane referencyjne, elementy związane z jakością danych oraz cykl życia obiektów danych. Elementy te są równie istotne dla Architektury Danych jak i dla procesu Zarządzania Jakością Danych. O czym opowiemy w dalszej części.
W wyniku procesu Zarządzania Architekturą Danych, powinniśmy otrzymać repozytorium architektoniczne, które jest:

  • Zintegrowane – oznacza, że obiekty i reguły są opisane raz, a powiązania między nimi są jednoznaczne.
  • Zorientowane biznesowo – oznacza, że model składa się z elementów rozpoznawanych przez biznes.
  • Istotne – oznacza, że repozytorium zawiera tylko informacje istotne do podejmowania decyzji związanych z rozwojem informacji i danych w organizacji.
wytyczne_it_knf

Wytyczne IT KNF

Wsparcie w implementacji rozwiązań dostosowujących organizację do wymogów Komisji Nadzoru Finansowego dot. IT i bezpieczeństwa IT dla podmiotów rynków bankowego, ubezpieczeniowego i finansowych.

Używamy cookies w celach świadczenia usług i statystyk. Brak zmiany ustawień przeglądarki oznacza, że będą one umieszczane na Twoim urządzeniu. Możesz zmienić te ustawienia. zamknij