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

Podziel się!

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

Proces zarządzania 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 abstrakcyjnego (produkt finansowy).

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.

Obiekty biznesowe w Architekturze Danych

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, aktorów, usług. Do wykonania tego kroku najlepiej użyć narzędzia, wspierającego modelowanie w języku Archimate 2.0 i 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ż obiekt 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 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 odbywa się w czasie procesu definiowania strategii biznesowej, oraz na 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ą rolę w ładzie IT. To właśnie na ich poziomie odbywa się przydzielanie stewardów, custodiana oraz często właściciela danych.

Konceptualny, logiczny i kanoniczny model danych

Modele konceptualne nie zawierają definicji atrybutów. W modelu konceptualnym mogą wystąpić relację wiele-do-wielu – pomiędzy obiektami biznesowymi i 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. Oznacza to, że 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, natomiast o modelach rozwijanych na potrzeby projektów, 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 dla procesu Zarządzania Jakością Danych.

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.

Podziel się!