Planowanie dotyczące ujednoliconej platformy danych

Ten artykuł ułatwia osobom podejmującym decyzje ustalenie modelu organizacyjnego potrzebnego do tworzenia i utrzymania cennych produktów danych w całej organizacji.

Organizacje muszą zdecydować, gdzie znajduje się odpowiedzialność za dane i jak będą kierować zasoby do produktów danych, które mają największe znaczenie. Bez jasno określonej odpowiedzialności i priorytetów inwestycyjnych inicjatywy związane z danymi mogą konkurować o zasoby, powielać wysiłki i tworzyć produkty danych, które nie mają trwałej wartości biznesowej. Ten artykuł ułatwia organizacjom ustanawianie domen danych, określanie priorytetów inwestycji w produkty danych, wybieranie modelu operacyjnego i rozwijanie kompetencji potrzebnych do wspierania tych priorytetów.

Drzewo rozwiązań i decyzji

Diagram ogólny przedstawiający Microsoft Fabric w centrum ujednoliconej platformy danych. Dane ze źródeł przedsiębiorstwa, takich jak systemy lokalne, usługi firmy Microsoft i platformy chmury publicznej, przepływają do Fabric, gdzie są organizowane jako współdzielone produkty danych. Te produkty danych są następnie wykorzystywane w całej organizacji do obsługi analityki, systemów sztucznej inteligencji i raportowania, w tym obciążeń związanych z usługą Power BI i analizą danych. Fabric łączy się z platformą Azure w zakresie nadzoru, zabezpieczeń i monitorowania, a obciążenia platformy Azure działają obok niego w razie potrzeby. Cały przepływ pokazuje, jak dane trafiają do Fabric, gdzie są objęte nadzorem i standaryzowane, a następnie wspierają sztuczną inteligencję, analitykę i wnioski biznesowe w całej organizacji.

Koncepcyjna architektura ujednoliconej platformy danych na potrzeby sztucznej inteligencji i analizy.

1. Model operacyjny

Jak należy dystrybuować obowiązki? Organizacje powinny stosować federacyjny model operacyjny, który łączy nadzór w całej organizacji z odpowiedzialnością domeny danych. Organizacja powinna ustanowić zasady, które mają zastosowanie we wszystkich domenach danych. Każda domena danych powinna sprawować kontrolę nad swoimi danymi i produktami danych w ramach tych zasad. Organizacje powinny udokumentować ten podział władzy.

1.1 Domeny danych

Jakie obowiązki powinniśmy zdecentralizować? Domena danych definiuje granicę organizacyjną wyznaczającą zakres odpowiedzialności za powiązane dane i produkty danych.

Diagram platformy danych, na której znajduje się wiele domen danych powyżej udostępnionych źródeł danych. W górnej sekcji przedstawiono kilka domen danych z etykietą Domena danych 1, Domena danych 2, Domena danych 3 i Domena danych n. Etykiety te reprezentują jednostki biznesowe lub linie produktów. Poniżej znajduje się warstwa źródeł danych. Strzałki wskazują, że każda domena danych pobiera dane z tych samych typowych źródeł. Źródła danych obejmują systemy lokalne, Dataverse, Microsoft 365, Azure, Google Cloud i Amazon S3. Diagram podkreśla, że domeny danych organizują i używają danych z wielu różnych platform. Omówienie domen danych.

  • Tworzenie domeny danych: domeny danych powinny być zgodne z granicami organizacyjnymi, w których lider może określać priorytety i kontrolować inwestycje. Jednostki biznesowe lub linie produktów często zapewniają wyraźne ramy, ponieważ mają już ustaloną kadrę kierowniczą i budżety. Domeny danych nie powinny odzwierciedlać miejsca, w którym znajdują się dane, ani technologii, która je przechowuje. Jeśli żaden lider nie ma wystarczającej władzy nad powiązanymi danymi i produktami danych, zdefiniuj inną granicę.

  • Własność danych: przypisz jednego głównego właściciela do każdej domeny danych. Właściciel jest odpowiedzialny za wyniki biznesowe i produkty data domeny oraz potrzebuje wystarczającej ilości uprawnień do ustawiania priorytetów i rozwiązywania sprzecznych potrzeb.

  • Inwestycje w produkty danych: każda domena danych powinna określić, które produkty danych należy proponować i utrzymywać na podstawie priorytetów biznesowych.

  • Budżet domeny: domeny danych powinny określać, jak używać budżetu do obsługi ich danych i produktów danych w ramach wymagań dotyczących całej organizacji.

  • Zmiany domeny danych: granice domeny danych powinny pozostać stabilne, dopóki nie zmieni się odpowiedzialność organizacyjna. Organizacje powinny przeglądać granice po zmianach organizacyjnych lub w przypadku cyklicznych decyzji przekrojowych między domenami danych, które tworzą niejasną odpowiedzialność. Powtarzające się eskalacje mogą wskazywać, że struktura domeny danych nie odzwierciedla już uprawnień decyzyjnych organizacji.

1.2 Odpowiedzialność centralna

Jakie obowiązki należy scentralizować? Centralizuj decyzje, które wymagają spójności między domenami danych. Centralna odpowiedzialność powinna skupić się na polityce obowiązującej w całej organizacji i wspólnych zdolnościach potrzebnych do jej zastosowania.

  • Zasady dla całej organizacji: Organizacja powinna ustanowić wymagania dotyczące ładu i zabezpieczeń, które mają zastosowanie we wszystkich domenach danych. Powinna również ustanowić standardy, które produkty danych muszą spełniać do ponownego wykorzystania w organizacji. Te zasady definiują granice, w których domeny danych podejmują własne decyzje.

  • Ograniczenia platformy: Organizacja powinna przełożyć zasady obowiązujące w całej organizacji na ograniczenia platformy. Microsoft Fabric obsługuje scentralizowane i delegowane administrowanie w dzierżawie i innych zakresach. Organizacja powinna centralnie kontrolować ustawienia, które mogą stwarzać zagrożenie dla całej organizacji, takie jak udostępnianie zewnętrzne lub dostęp gościa. Powinno ono delegować zarządzanie ustawieniami, gdy domeny danych mogą podejmować niezależne decyzje bez zwiększania ryzyka dla całej organizacji. Organizacje powinny regularnie przeglądać ustawienia dzierżawy, ponieważ Microsoft Fabric wprowadza nowe możliwości i ustawienia. Zobacz Omówienie nadzoru i wskazówki.

  • Współdzielone funkcje: Organizacja powinna zapewnić współdzielone funkcje platformy, gdy centralizacja poprawia spójność lub zmniejsza zduplikowaną pracę platformy. Te możliwości mogą obejmować Microsoft Fabric i Microsoft Purview. Organizacja powinna ustalić, w jaki sposób domeny danych uzyskują dostęp do udostępnionych możliwości i je finansują. Domeny danych powinny zachować decyzyjność w zakresie inwestycji wspierających ich własne dane i produkty danych.

  • Wyjątki: Organizacja powinna ustanowić udokumentowany proces wyjątków dla domen danych, które nie mogą spełnić wymagań dotyczących zasad lub wymogu dotyczącego platformy współdzielonej. Każdy zatwierdzony wyjątek powinien identyfikować odpowiedzialnego lidera i warunki dalszego obowiązywania zatwierdzenia.

2. Priorytetyzacja danych

Jak należy określić priorytety inicjatyw dotyczących danych? Osoby podejmujące decyzje powinny utrzymywać mapę drogową produktów danych uporządkowaną według priorytetów, które obsługują zdefiniowane cele biznesowe. Produkt danych to zestaw zasobów danych wielokrotnego użytku zorganizowany wokół zdefiniowanego celu biznesowego. Organizacje powinny zacząć od wyniku biznesowego, a nie dostępnych danych. Takie podejście kieruje inwestycje w produkty danych mające możliwych do zidentyfikowania odbiorców i mierzalną wartość.

  • Cele biznesowe: każdy proponowany produkt danych powinien obsługiwać zdefiniowany cel biznesowy. Cel biznesowy może zależeć od produktów danych z wielu domen danych. Każda domena danych pozostaje odpowiedzialna za produkty danych, które współtworzy. Decydenci powinni sfinansować produkt danych tylko wtedy, gdy jego sponsor może wyjaśnić rezultat, który ten produkt umożliwia, i jak organizacja rozpozna tę wartość. Wynik może wpłynąć na ważną decyzję. Może umożliwić automatyzację lub udostępnić zaufane dane do ponownego użycia.

  • Uzasadnienie inwestycji: każdy proponowany produkt danych powinien mieć uzasadnienie inwestycji, które określa jego oczekiwaną wartość oraz zasoby potrzebne do jego dostarczenia i utrzymania. Uzasadnienie biznesowe inwestycji powinno identyfikować krytyczne znaczenie biznesowe produktu danych. Organizacja powinna używać tej klasyfikacji jako danych wejściowych na potrzeby wymagań dotyczących niezawodności, wdrażania, monitorowania, pojemności i zarządzania zmianą. Decydenci powinni ocenić, czy oczekiwana wartość uzasadnia łączną inwestycję bez podejmowania decyzji o rozwiązaniu technicznym.

  • Priorytet portfela: Organizacje powinny porównywać proponowane produkty oparte na danych przy użyciu spójnych kryteriów dotyczących wartości biznesowej i wykonalności. Zależności powinny określać sekwencjonowanie po tym, jak liderzy ustalą wartość względną. Każdy przegląd powinien skutkować decyzją o finansowaniu, odroczeniu lub odrzuceniu wniosku. Produkty danych o wysokiej wartości z osiągalnymi wymaganiami wstępnymi powinny zwykle być finansowane wcześniej. Organizacje powinny odroczyć wniosek, gdy krytyczne wymaganie wstępne nie jest gotowe. Powinny odrzucić propozycję, gdy jej oczekiwana wartość nie uzasadnia inwestycji.

  • Dalsze inwestycje: Organizacje powinny ponownie ocenić finansowane produkty danych, gdy zmieniają się priorytety biznesowe i uzyskiwana wartość. Domeny danych powinny dostarczyć wystarczających dowodów, aby pokazać, czy każdy produkt danych nadal wspiera realizację zamierzonego rezultatu. Osoby podejmujące decyzje powinny kontynuować inwestycje, gdy produkt data zapewnia wystarczającą wartość i ma jasno określonego właściciela. Powinny one zmniejszyć inwestycje lub wycofać produkt data, gdy jego wartość nie uzasadnia już kosztów.

3. Obsada

Jak powinniśmy obsadzić domeny danych? Roadmapa produktu danych powinna kierować planowaniem zatrudnienia. Organizacje nie powinny ustanawiać stałych zespołów, zanim pojawi się trwałe zapotrzebowanie.

  • Dedykowana kadra: domena danych powinna używać dedykowanego personelu, gdy stałe zapotrzebowanie uzasadnia stałe kompetencje. Ten model pasuje również do domen danych, które obsługują strategicznie ważne produkty danych lub w dużym stopniu zależą od wiedzy biznesowej. Domena danych powinna finansować dedykowaną kadrę za pośrednictwem zatwierdzonego budżetu.

  • Współdzielona obsada kadrowa: Organizacja powinna zapewnić współdzieloną obsadę kadrową, gdy kilka domen danych potrzebuje podobnej wiedzy, ale indywidualne zapotrzebowanie pojawia się sporadycznie. Współdzieleni specjaliści mogą zapewnić możliwości, takie jak inżynieria danych lub administrowanie platformą. Wspólni specjaliści powinni ustalić priorytety pracy zgodnie z planem produktu danych.

  • Personel zewnętrzny: domena danych powinna używać dostawców zewnętrznych, gdy potrzeba jest tymczasowa lub wysoce wyspecjalizowana. Zewnętrzni dostawcy mogą również przyspieszyć dostarczanie, dopóki organizacja nie opracuje możliwości wewnętrznych. Domena danych powinna zidentyfikować, która wiedza musi zostać przeniesiona wewnętrznie przed zakończeniem współpracy.

4. Skilling

Jak powinniśmy uzyskać potrzebne umiejętności? Osoby podejmujące decyzje muszą zidentyfikować luki w możliwościach z zatwierdzonego planu, a następnie wybrać metody programowania, aby zamknąć te luki.

  • ** Zastosowane programowanie**: Szkolenie powinno rozwiązać zidentyfikowaną lukę możliwości i połączyć się z aktywnym produktem danych, gdzie jest to praktyczne. Takie podejście daje ludziom kontekst, w którym mogą zastosować nową wiedzę. Daje również liderom dowody na to, że szkolenia zwiększają możliwości dostarczania.

  • ** Walidacja umiejętności**: Poświadczenia (certyfikaty i zastosowane umiejętności) mogą weryfikować odpowiednie umiejętności platformy. Powinny obsługiwać strategię możliwości, a nie ją definiować. Organizacje powinny wybrać bieżące Microsoft Szkolenie i poświadczenia oparte na rolach po zidentyfikowaniu potrzebnych ról i funkcji. Zobacz Microsoft Credentials.

5. Zarządzanie kosztami i FinOps

Jak organizacja powinna zarządzać wydatkami? Organizacje powinny ustanowić ciągły proces FinOps, który łączy wydatki z wartością produktów data. Każda domena danych powinna mieć odpowiedzialność finansową za wydatki w ramach zatwierdzonego budżetu. Organizacja powinna używać istniejących procesów finansowych platformy Azure dla Microsoft Fabric tam, gdzie jest to praktyczne. Powinno ono definiować dodatkowe procesy specyficzne dla Fabric tylko wtedy, gdy współdzielona Fabric pojemność wymaga bardziej szczegółowej alokacji zużycia.

5.1 Alokacja kosztów

Jak należy przydzielić koszty? Organizacje powinny dostosować alokację kosztów Fabric do istniejącego modelu alokacji kosztów Azure. Organizacje, które już korzystają z showbacku lub chargebacku dla Azure, powinny rozszerzyć ten model na Fabric, tam, gdzie jest to praktyczne. Metoda alokacji powinna przypisywać wydatki do domen danych odpowiedzialnych za korzystanie z nich. Metoda powinna również wyjaśnić, w jaki sposób organizacja dystrybuuje współdzielone koszty i korzyści wynikające z rezerwacji.

  • Raportowanie kosztów platformy Azure: Microsoft Cost Management może organizować i rozpowszechniać koszty między subskrypcjami, grupami zasobów lub tagami za pomocą reguł alokacji kosztów. Patrz Alokacja kosztów.

  • Nowy proces: jeśli nie masz ustalonego modelu, zacznij od showbacku, aby zapewnić domenom danych wgląd w ich koszty przed wprowadzeniem chargebacku.

  • Narzędzia Chargeback: gdy domeny danych współdzielą pojemność Fabric, użyj aplikacji Microsoft Fabric Chargeback, aby przypisać użycie pojemności Fabric do odpowiednich domen danych. Zobacz aplikację Chargeback Microsoft Fabric.

5.2 Prognozowanie kosztów

Jak powinniśmy prognozować koszty Fabric? Domeny danych powinny prognozować oczekiwane wydatki w ramach procesu budżetowania i aktualizować prognozy w miarę poznawania rzeczywistego zużycia. Wydajność usługi Fabric jest ważnym czynnikiem kosztowym, dlatego należy uwzględnić planowane potrzeby w zakresie wydajności i oczekiwany wzrost.

Domeny danych powinny używać narzędzia do szacowania jednostki SKU Microsoft Fabric do początkowego planowania i aplikacji Microsoft Fabric Capacity Metrics w celu uściślenia prognoz przy użyciu obserwowanego zużycia. Microsoft zaleca rozpoczęcie od mniejszej mocy obliczeniowej usługi Fabric i zwiększanie tej mocy, gdy rzeczywiste zapotrzebowanie uzasadnia dodatkowe inwestycje. Zobacz planowanie pojemności w usłudze Fabric.

5.3 Optymalizacja kosztów

Jak powinniśmy zoptymalizować wydatki? Liderzy domeny danych powinni okresowo porównywać rzeczywiste wydatki z zatwierdzonym budżetem i oczekiwaną wartością swoich produktów danych. Przegląd powinien określić, czy wydatki pozostają uzasadnione, czy też organizacja powinna zoptymalizować zużycie lub zmienić inwestycję.

  • Częstotliwość przeglądu: cykl przeglądu powinien odzwierciedlać zmienność kosztów. Miesięczne przeglądy zwykle sprawdzają się w domenach danych ze zmieniającymi się obciążeniami lub cyklicznymi skokami zużycia. Przeglądy kwartalne mogą pasować do domen danych ze stabilnym i przewidywalnym użyciem.

  • Narzędzia FinOps: Liderzy domeny danych powinni korzystać z użycia pojemności usługi Fabric wraz z rachunkiem za Azure w celu zrozumienia głównych czynników kosztotwórczych. Microsoft Cost Management pokazuje opłaty za użycie pojemności Fabric, a aplikacja Microsoft Fabric Capacity Metrics udostępnia odpowiednie informacje o wykorzystaniu pojemności. Zobacz Opis rozliczenia platformy Azure za pojemność rozwiązania Fabric i Ocena i optymalizacja pojemności usługi Microsoft Fabric.

  • Cennik oparty na zobowiązaniu: Organizacje mogą zakupić rezerwacje pojemności Fabric na jeden rok lub trzy lata. Rezerwacja obejmuje użycie pojemności Fabric odpowiadające rezerwacji, ale nie obejmuje opłat za magazyn ani sieć. Organizacje powinny podjąć to zobowiązanie dopiero po tym, jak korzystanie stało się wystarczająco przewidywalne. Obniż koszty dzięki rezerwacjom pojemności Microsoft Fabric.