Architektura SOA, która zakłada współdziałanie typu "wielu z wieloma", nie dopuszcza jednak pozostawienia problemu po stronie dostawców aplikacji. Nawet w środowiskach innych niż SOA rezygnacja z podejścia polegającego na tworzeniu konektorów i pójście w kierunku bardziej zracjonalizowanej architektury danych, ułatwiającej integrację, daje bezsporne korzyści.

Podejście niektórych dostawców, jak np. IBM czy Oracle, to stawianie na operacyjną hurtownię danych, zapewniającą jeden lub więcej hubów danych obsługujących zarówno magazyny oczyszczonych danych i dostęp z usług generujących, jako zaufane brokery, sprawdzone dane z innych aplikacji. Pozwala to emulować architekturę hubów w tradycyjnym środowisku przedsiębiorstwa. Inni - BEA Systems, Xcalia, podchodzą do tego na poziomie bardziej federacyjnym w celu lepszego odzwierciedlenia luźno powiązanej, abstrakcyjnej natury SOA.

Analitycy ostrzegają jednak, że dzisiejsze technologie są jeszcze niezbyt dojrzałe i co najwyżej mogą pomóc w specyficznych procesach zarządzania danymi.

Wiele hubów danych oferowanych dzisiaj nastawionych jest na jeden rodzaj danych, takich jak informacje o klientach lub produktach. Jest to dobre na początek, jednak na dalszym etapie koniecznym będzie "zgeneralizowanie" huba lub sfederowanie specyficznych hubów danych.

Decyzja, czy startować z systemem "danych specyficznych" - takich jak informacje o produktach w ramach SCM, czy systemem ogólnym, zależy od tego, na jakie zestawy aplikacyjne ukierunkowana jest integracja. Może więc być bardziej sensowne startowanie z hubami specyficznymi, jeżeli skupiamy się na interakcjach z systemami ERP lub SCM, podczas gdy hub ogólny ma większy sens jeżeli skupiamy się na SOA, w której usługi współdziałają z szerokim zakresem aplikacji.

Otwieranie składnic danych

Rozwiązaniem nie jest zabieranie baz danych spod pieczy aplikacji i udostępnianie im możliwości czytania z centralnego źródła danych. Takie aplikacje są często poza kontrolą przedsiębiorstwa - projektowane przez dostawców niezależnych - i z tego powodu trudne lub niemożliwe do modyfikacji.

Podejście, które w opinii różnych ekspertów okazało się najskuteczniejsze, to oddzielenie procesów biznesowych od danych. Architektura przedsiębiorstwa powinna wyraźnie separować dane od aplikacji.

Poziom zarządzania danymi i raportowania to aplikacje horyzontalne, odpowiedzialne za zasilanie danymi wejścia do aplikacji biznesowych i następnie zbieranie danych wyjściowych od nich w celu zapewniania ich "czytelności" w ramach całego przedsiębiorstwa.

Master Data Management może tu być platformą programową, która umożliwi zarządzanie pojedynczą wersją danych podstawowych i następnie dostarczanie ich do aplikacji biznesowych, które w sprzężeniu zwrotnym wpływają na nie.

Aplikacje można podłączyć do hubów danych zamiast łączyć je między sobą. Upraszcza to integrację, ponieważ poziom MDM operuje na pojedynczym, kanonicznym dla całego przedsiębiorstwa, modelu danych. Użytkownicy wchodzą na ten poziom danych w celu dodawania, modyfikowania i usuwania informacji w zakresie wszystkich jednostek danych podstawowych, dotyczących klientów, produktów i poddostawców.

Cykle życia każdej takiej jednostki (pozycji produktu, dostawcy, klienta) mogą być zarządzane przez ciągi przepływu zadań zapewniające, że poprawne dane są wprowadzane przez odpowiednich ludzi i w prawidłowej kolejności.

Jednak próba kompletnego zarządzania danymi głównymi, podobnie jak kompletne wdrożenie SOA, jest ogromnym przedsięwzięciem, jednym z tych, które trwają latami i konsumują znaczne zasoby z niewielkimi korzyściami w okresie przejściowym.

W coraz większym zakresie powraca się więc do podejścia z lat 90. - składnic danych (data mart), które podupadły, nie dając sobie rady z olbrzymimi wolumenami nieuporządkowanych danych. Tworzenie składnic danych uznaje się teraz za dobry sposób rozpoczęcia "wędrówki" w kierunku systemu MDM obejmującego całe przedsiębiorstwo.

Hurtownie danych i repozytoria przedsiębiorstw w przeszłości odsuwały na margines składnice danych. W większości przypadków składnice danych nie mogły służyć w charakterze zasobników aktualnych danych. Były to raczej fotografie danych już przestarzałych. Jednak dzisiaj składnice danych mogą być repozytoriami danych bliskich czasowi rzeczywistemu, a to dzięki różnym zaawansowanym technologiom ostatniej dekady. Obejmują one standaryzacje wymiany danych w ramach ODBC, JDBC i SQL 99, szersze stosowania interfejsów webowych dla przekazu informacji w czasie rzeczywistym, lepsze narzędzia zarządzania danymi od takich dostawców, jak Business Objects czy Informatica.

W rezultacie składnice danych, budowane z użyciem oprogramowania takich firm, jak: Business Objects, IBM, Informatica, Teradata czy Oracle, zostały znacznie ulepszone. Jest to kolejny krok na drodze uzyskiwania oczyszczonych, standaryzowanych informacji z kluczowych danych, jakimi dysponują przedsiębiorstwa.

Wprowadzanie architektury danych

Narzędzia MDM mogą pomóc w budowaniu architektury danych, ale niewiele z ich pomocą można osiągnąć, jeżeli przedsiębiorstwo nie przeprowadzi rozpoznania znaczenia poszczególnych rodzajów danych. Ponieważ scentralizowane magazyny danych radzą sobie zazwyczaj z wynikami post factum, a nie stanami i transakcjami, większość systemów MDM wygląda jak tradycyjne hurtownie danych i prawdopodobnie w mniejszym zakresie będą spełniać potrzeby systemów transakcyjnych, niezależnie czy jest to środowisko SOA, czy tradycyjne. Nierealistycznym jest oczekiwanie, że istnieje jedna nadrzędna baza danych, która wszystko przyjmuje i udostępnia.

W przypadku SOA narzędzia MDM, które tylko w sposób prosty zastępują narzędzia EAI (Enterprise Application Integration), nie są zbyt pomocne, ponieważ SOA powinna być "napędzana" przez procesy biznesowe, podczas gdy EAI zazwyczaj skupia się na połączeniach między aplikacjami bez martwienia się o kontekst danych każdej z nich.

Poprawne zaprojektowanie takiej architektury i specyficznych usług wymaga, aby projektant rozumiał znaczenie wszystkich danych używanych i generowanych przez aplikacje, z którymi współdziałają, a jest to dość obciążające zajęcie. Jest to też powód, dla którego IT potrzebuje powszechnie dostępnego zestawu usług danych lub co najmniej odwzorowania danych.

Po utworzeniu takiego odwzorowania IT może skupić się na budowaniu konektorów lub usług, które je implementują. Potrzebna jest tu wiedza, które odwzorowania powinny być dostępne dla wielu usług i aplikacji - i dlatego będą implementowane jako oddzielne procesy - a które przypisane są do specyficznej logiki biznesowej i powinny być z nią łączone.

Do rozpoznawania danych można podchodzić iteracyjnie, tworząc reguły i metadane wokół informacji używanej dla potrzeb specyficznych aplikacji czy usług. Po pewnym czasie można zbudować kompletną architekturę danych.

Taka architektura danych zawierać będzie zazwyczaj wiele modeli danych - każdy zorientowany na specyficzny typ procesu. To pozwala projektować architekturę danych w etapach, dodatkowo ograniczając odwzorowania wymagane pomiędzy modelami danych. (Zunifikowany model danych musi odzwierciedlać wszystkie możliwe odwzorowania, niezależnie czy jest to model sfederowany czy nie.)

Trzeba też koncentrować się na wyjątkach, projektując usługi, które sprawdzają dane będące spoza przyjętego przedziału, zamiast próbować projektować działający w obrębie całego przedsiębiorstwa system, który rozpoznaje każdy możliwy stan lub powiązanie.

Ostateczny cel to zbudowanie poziomu usług danych, w którym dane główne są rozproszone, jednak infrastruktura i narzędzia do osiągnięcia tego celu nie są jeszcze w pełni dojrzałe.

Zapewnianie źródeł danych jako usług w ramach całej organizacji jest przedsięwzięciem olbrzymim. Dla tradycyjnych prób integracji oznacza to zrozumienie kontekstu każdej aplikacji i tego jak dane są transformowane przed dostarczeniem ich do innej aplikacji. Dla SOA wymaga to zrozumienia wielu powiązań i zależności, które mogą istnieć pomiędzy danymi i procesami biznesowymi.

Analitycy są zgodni, że ta złożoność wymaga zarówno inwestycji w modelowanie architektury danych i myślenia w kategorii zależności i kontekstu danych. Rozpoznawanie modeli danych i powiązań miedzy systemami w celu stworzenia takich odwzorowań, to ok. 70% całego wysiłku w tworzeniu architektury SOA, a modelowanie i rozpoznawanie to ok. 30% prób integracji danych w konsolidowaniu projektów ERP.