piątek, 5 kwietnia 2013

Dojrzałość organizacji w zarządzaniu danymi

W ramach opracowywania architektury korporacyjnej w organizacji jednym z nurtów jest architektura danych. W TOGAF zagadnienie to jest jedną z czterech domen architektonicznych:

  • Business,
  • Data,
  • Application,
  • Technology.

Słownik TOGAF® (dokument TOGAF® 9 Translation Glossary: English - Polish) definiuje, że architektura danych to:
Struktura logicznych i fizycznych danych organizacji, a także zasobów używanych do zarządzania tymi danymi.
W książce pod tytułem The Art of Enterprise Information Architecture: A Systems-Based Approach for Unlocking Business Insight znalazłem interesujący model dojrzałości organizacji w zarządzaniu informacjami. Model ten pokazuje w jaki sposób organizacja może rozwijać się w tym zakresie i do czego dążyć.


W tym artykule nie chciałbym dyskutować o możliwych zaletach takiego podejścia, choć mogłoby być to interesujące, zwłaszcza gdy się postawi na szali koszty utrzymania takiej architektury danych na najwyższym poziomie. Z pewnością jednak, organizacji na wyższych poziomach łatwiej jest konkurować na zmiennym rynku poprzez możliwość szybkiego dostosowania systemów informatycznych, aby biznes mógł oferować produkty dostosowane do wymagań klientów.

Model ten został przedstawiony na poniższym diagramie zaczerpniętym z w/w książki.
Poziomy dojrzałości w zarządzaniu metadanymi
Poziomy dojrzałości w zarządzaniu metadanymi.
Źródło: M. Godinez, E. Hechler, K. Koenig, S. Lockwood, M. Oberhofer, M. Schroeck, The Art of Enterprise Information Architecture: A Systems-Based Approach for Unlocking Business Insight, IBM Press 2010.

Został tu użyty termin metadata. Jako, że metadane służą do opisu danych, sądzę, że można je również odnieść do klas, w rozumieniu UML.

Poziomy dojrzałości to:

  • Poziom 1 - Najniższy poziom dojrzałości organizacji w zarządzaniu danymi. Przykładem może być dokumentacja baz danych, na przykład DB2 lub Oracle. W tej dokumentacji znaleźć można listę tabel wraz z kolumnami i ich opisem. Może to być również model ERD. Dokumentacja ta może zawierać również inne informacje, takie jak widoki, indeksy czy procedury składowe.
  • Poziom 2 - Istnieją w organizacji zdefiniowane dane na poziomie biznesowym. Mogą to być słowniki terminów, modele domeny, encji biznesowych itp.
  • Poziom 3 - Organizacja jest na trzecim poziomie dojrzałości, gdy istnieją modele zawierające odpowiednie mapowania danych biznesowych (model domeny, encji biznesowych) na dane techniczne (model ERD).
  • Poziom 4 - Następny poziom dojrzałości, gdy organizacja posiada zdefiniowane scenariusze przypadków użycia, dzięki którym można łatwiej zarządzać i optymalizować procesy biznesowe. Umożliwia to na przykład kierownictwu sprzedaży zgłoszenie wymagania zmiany zakresu generowanych w aplikacji raportów sprzedaży przy użyciu słownictwa, którym posługuje się biznes. Dzięki powiązaniu procesu biznesowego z danymi biznesowymi oraz powiązaniu danych biznesowych z danymi technicznymi - wymaganie takie może zostać "przetłumaczone" na język techniczny.
  • Poziom 5 - Najwyższy poziom dojrzałości organizacji, który został opisany w książce jako udoskonalony wgląd w prowadzone procesy biznesowe, pozwalający na wprowadzanie nowych innowacji i wykorzystywanie szans. Możliwe byłoby to poprzez analitykę i modelowanie procesów biznesowych w taki sposób, aby optymalizacja procesów biznesowych była odpowiednio zsynchronizowana z danymi biznesowymi i technicznymi.

Model ten jest ogólny i abstrahuje od zastosowania języków modelowania (UML, Archimate, ERD), jak również od narzędzi. W dodatku należy mieć na względzie, że nie pojedynczego systemu, a wszystkich procesów biznesowych, które mogą być realizowane w wielu systemach.

Aby móc lepiej rozróżnić, czym się różnią od siebie poszczególne poziomy, można chyba zaryzykować podsumowanie.
Na poziomie pierwszym mamy do czynienia tylko z modelem ERD. 
Na poziomie drugim dodatkowo istnieje analityczny model domeny. 
Na poziomie trzecim klasy odpowiednie klasy modelu ERD są połączone relacjami z klasami modelu domeny. 
Poziom czwarty zakłada istnienie modelu użycia, w którym przypadki użycia powiązane są z klasami modelu domeny. 
I ostatni poziom piąty, w którym istnieje dodatkowo model procesów biznesowych (na przykład w postaci diagramów BPMN) powiązany z określonymi funkcjonalnościami systemów informatycznych (przypadkami użycia). Dzięki temu organizacja będąca na najwyższym poziomie mogłaby zmieniać i optymalizować swoje procesy biznesowe w sposób bardziej świadomy - mogąc odpowiednio wcześnie zidentyfikować ograniczenia lub niewykorzystane możliwości w sferze funkcjonalne i technicznej.

Brak komentarzy:

Prześlij komentarz