Model Informacji Chmurowej

Witamy w CIM – niezależnym od aplikacji modelu danych, który upraszcza integrację i przyspiesza innowacje.

Kluczowe wnioski

• CIM to współdzielony, otwarty model danych, a nie produkt. Definiuje on wspólne koncepcje biznesowe i ich relacje, dzięki czemu różne aplikacje mogą wymieniać dane bez konieczności tworzenia dedykowanych, jednorazowych mapowań.
• Jest on zarządzany jako otwarty standard. CIM jest udostępniany na zasadach open source w ramach Joint Development Foundation (części Linux Foundation) i zaprasza do współpracy dostawców, przedsiębiorstwa oraz szerszą społeczność.
• Treści są zorganizowane w Obszary Tematyczne (domeny). Każda domena reprezentuje główną koncepcję biznesową i jest publikowana w wielu formatach, w tym w formie diagramów, aby architekci i inżynierowie mogli wdrażać ją stopniowo.
• Kluczową wartością jest zmniejszenie kruchości integracji. Model kanoniczny zastępuje kod translacji punkt-punkt stabilnym celem, do którego i z którego wiele systemów może mapować dane.
• Adopcja to decyzja projektowa, a nie przełączenie funkcji. To Ty wybierasz, które domeny przyjąć, jak mapować systemy źródłowe i jak zarządzać rozszerzeniami w czasie.

Nowy standard interoperacyjności danych

CIM jest tworzony przez otwarte konsorcjum powołane w celu dostarczenia opartego na standardach rozwiązania do łączenia produktów korporacyjnych. Dzięki CIM możesz tworzyć płynne i dopasowane do indywidualnych potrzeb doświadczenia w aplikacjach natywnych dla chmury.

Aby przyspieszyć transformację cyfrową i zapewnić spersonalizowaną komunikację z klientami w każdym kanale, wiele firm wdraża wiele aplikacji chmurowych i lokalnych (on-premise). Każda z nich posiada własny model danych, co zmusza programistów do tworzenia, testowania i zarządzania niestandardowym kodem niezbędnym do mapowania i translacji danych między różnymi systemami. Zamiast przyspieszać transformację cyfrową, proces ten spowalnia innowacje i prowadzi do kruchych integracji.

CIM to nowoczesna, otwarta specyfikacja, która ma pomóc złagodzić trudności związane z integracją danych. CIM zapewnia zdefiniowany standard, który umożliwia łatwą komunikację między różnymi formatami danych. Jako projekt open source w ramach Joint Development Foundation (pod egidą Linux Foundation), zapraszamy wszystkich chętnych współpracowników.

Problem, który rozwiązuje CIM, ma charakter strukturalny, a nie incydentalny. Gdy każdy system mówi własnym dialektem — jeden nazywa klienta „Kontaktem”, inny „Stroną”, a trzeci „Kontem” — zespoły integracyjne kończą z utrzymywaniem rosnącej sieci mapowań parami.

Każda nowa aplikacja zwielokrotnia liczbę wymaganych translacji, a każda zmiana schematu w dowolnym systemie może wywołać efekt domina i przerwać potoki danych (pipelines) w dalszych etapach. Model kanoniczny zmienia naturę tego problemu: zamiast N systemów mapujących się nawzajem, każdy system mapuje się raz do wspólnego słownika.

Powiązane: Fivetran — W pełni zarządzany potok ELT, który po prostu działa.

Dlaczego integracja punkt-punkt zawodzi

Warto konkretnie wskazać tryby awarii, które motywują do stworzenia wspólnego modelu.

• Wzrost kombinatoryczny. W przypadku mapowań punkt-punkt liczba ścieżek translacji rośnie w przybliżeniu wraz z kwadratem liczby systemów. Dodanie dziesiątej aplikacji jest znacznie kosztowniejsze niż dodanie drugiej.
• Dryf semantyczny. Dwa zespoły mogą „mapować klienta” i nadal nie zgadzać się co do tego, czy klientem jest osoba, organizacja czy relacja rozliczeniowa. Dane przepływają, ale znaczenie staje się rozbieżne.
• Kruche zarządzanie zmianami. Zmiana nazwy pola lub nowy wymagany atrybut w jednym systemie źródłowym wymusza poprawki u każdego konsumenta, który z niego korzysta.
• Zduplikowana logika. Reguły walidacji, deduplikacji i rozpoznawania tożsamości są implementowane ponownie w każdej integracji, zamiast zostać zdefiniowane raz.
• Presja na uzależnienie od dostawcy (vendor lock-in). Gdy logika integracji jest nierozerwalnie związana ze schematem konkretnego dostawcy, zmiana lub dodanie nowych dostawców staje się projektem wymiany całej platformy.

Model kanoniczny, taki jak CIM, nie eliminuje pracy związanej z mapowaniem — każdy system źródłowy nadal wymaga mapowania na model. Eliminuje on jednak mnożenie tej pracy. Tworzysz jedno mapowanie z systemu do wspólnego modelu, a sam model stanowi stabilną umowę (contract) między nimi.

Jak zorganizowany jest CIM: Obszary Tematyczne

Treści definiowane wspólnie są zorganizowane w domeny, czyli Obszary Tematyczne. Każdy Obszar Tematyczny reprezentuje główną koncepcję biznesową. Projekty CIM są dostępne w wielu formatach dla każdej domeny, w tym w formie przykładowych diagramów. Liczba i zakres Obszarów Tematycznych będą rosły wraz z rozwojem konsorcjum i nowymi wkładami.

Jeśli robisz zakupy: Boomi AtomSphere — Enterprise iPaaS do integracji hybrydowej chmury z lokalną firmą.

Taka struktura zorientowana na domeny jest kluczowa dla adopcji. Rzadko kiedy potrzebny jest cały model naraz. Typowe przedsiębiorstwo zaczyna od domen, które dotyczą jego najbardziej problematycznych integracji, sprawdza to podejście, a następnie je rozszerza. Wspólnymi punktami wyjścia są zazwyczaj koncepcje pojawiające się w prawie każdym systemie:

• Strona / Klient (Party / Customer) — osoby i organizacje, z którymi prowadzisz interesy, oraz role, jakie pełnią.
• Produkt (Product) — to, co sprzedajesz, oferujesz lub czym zarządzasz, w tym katalogi i klasyfikacje.
• Konto i relacja (Account and relationship) — sposób, w jaki strony wiążą się z produktami, kontraktami i sobą nawzajem.
• Interakcja i aktywność (Interaction and activity) — zdarzenia, transakcje i zaangażowania, które łączą powyższe elementy.

Ponieważ każdy Obszar Tematyczny jest publikowany wraz z diagramami i w wielu formatach reprezentacji, architekci mogą przeglądać model koncepcyjny, inżynierowie mogą korzystać z formy czytelnej maszynowo, a interesariusze biznesowi mogą potwierdzić, że koncepcje odpowiadają rzeczywistości. To wieloformatowe podejście jest świadomym wyborem projektowym: model, który mogą przeczytać tylko inżynierowie, ma tendencję do odrywania się od znaczenia biznesowego.

Jak CIM wypada na tle innych podejść

CIM jest jedną z kilku opcji osiągnięcia interoperacyjności. Odpowiedni wybór wymaga zrozumienia związanych z tym kompromisów.

Podejście	Co to jest	Mocne strony	Kompromisy
Mapowanie punkt-punkt	Bezpośrednie tłumaczenia pomiędzy każdą parą systemów	Proste dla dwóch systemów; nie wymaga wspólnego zarządzania	Rośnie kombinatorycznie; kruche; zduplikowana logika
Model kanoniczny (w stylu CIM)	Wspólne, niezależne od aplikacji słownictwo, do którego każdy system mapuje dane	Liniowy nakład pracy przy mapowaniu; stabilny kontrakt; wielokrotnego użytku w projektach	Wymaga zarządzania i porozumienia; mapowanie nadal potrzebne dla każdego systemu
Standardy danych branżowych	Standardy pionowe dla konkretnego sektora (np. opieka zdrowotna, finanse)	Głębokie pokrycie domeny; zgodność z regulacjami	Wąski zakres; może nie obejmować międzybranżowych koncepcji przedsiębiorstwa
Modele danych dostawców	Natywny schemat platformy udostępniony jako centrum integracji	Ścisła integracja z narzędziami; szybkie wdrożenie w ekosystemie jednego dostawcy	Ryzyko uzależnienia (lock-in); inni dostawcy muszą dostosować się do modelu jednej strony
Najpierw API / schemat przy odczycie	Kontrakty zdefiniowane dla każdego API; znaczenie rozstrzygane w momencie konsumpcji	Elastyczne; szybki start	Spójność semantyczna zależy od dyscypliny; trudniejsze do zarządzania na dużą skalę

Praktyczne wskazówki: używaj modelu kanonicznego, gdy masz wiele systemów, koncepcje międzydomenowe i długotrwały krajobraz integracji. Używaj mapowania punkt-punkt, gdy zakres obejmuje rzeczywiście dwa systemy i jest krótkotrwały. Standardy branżowe i CIM uzupełniają się — standard pionowy może informować domenę, podczas gdy CIM zapewnia przekrojowe słownictwo korporacyjne.

Jak zastosować CIM w praktyce

Adopcja to raczej sekwencja przemyślanych decyzji niż pojedyncza migracja. Działający wzorzec wygląda następująco:

1. Wybierz problematyczną, ale dobrze ograniczoną integrację. Wybierz domenę, w której trudności z mapowaniem są realne, a zakres jest na tyle mały, by szybko wykazać wartość.
2. Spisz systemy źródłowe i ich schematy. Udokumentuj, jak każdy system nazywa koncepcje w wybranym Obszarze Tematycznym i w których miejscach występują rozbieżności.
3. Zmapuj każdy system na domenę CIM. Utwórz jedno mapowanie na system do wspólnego modelu. Traktuj te mapowania jako wersjonowane artefakty, a nie jednorazowe skrypty.
4. Od razu zdefiniuj politykę rozszerzeń. Zdecyduj, jak będziesz obsługiwać koncepcje, których CIM jeszcze nie obejmuje — rozszerzenia powinny być udokumentowane, spójnie nazwane i zaproponowane konsorcjum, jeśli są szeroko przydatne.
5. Ustal zasady zarządzania. Przypisz odpowiedzialność za mapowania, proces przeglądu zmian oraz częstotliwość synchronizacji z nadrzędnymi aktualizacjami CIM.
6. Rozszerzaj domenę po domenie. Wykorzystaj wzorce mapowania i zarządzania z pierwszej domeny, aby obniżyć koszt kolejnych.

Warto jasno sformułować dwa zastrzeżenia. Po pierwsze, model kanoniczny dodaje warstwę — nie jest darmowy, a korzyści wynikają z ponownego wykorzystania w wielu integracjach, a nie z jednej. Po drugie, to w mapowaniu kryje się prawdziwa praca; model zapewnia stabilny cel, ale ktoś wciąż musi zdecydować, w jaki sposób każde pole źródłowe mu odpowiada, a decyzja ta wymaga wkładu biznesowego, a nie tylko inżynierskiego.

Powiązane: Matillion — ELT typu push-down zbudowany dla hurtowni danych w chmurze.

Zarządzanie, licencjonowanie i wkład

CIM jest udostępniany jako open source w ramach Joint Development Foundation, która działa pod egidą Linux Foundation. Ta struktura ma znaczenie dla przedsiębiorstw go oceniających: Linux Foundation jest ugruntowanym domem dla wspólnych, niezależnych od dostawców projektów open source, a Joint Development Foundation zapewnia ramy prawne zaprojektowane specjalnie do opracowywania i obsługi projektów standardów i specyfikacji.

Dla architekta danych korporacyjnych praktyczne implikacje tego modelu zarządzania są następujące:

• Neutralność dostawcy. Żaden pojedynczy dostawca nie kontroluje specyfikacji, co zmniejsza ryzyko, że model zostanie ukształtowany tak, by faworyzować jedną platformę.
• Otwarty wkład. Każdy może zaproponować zmiany, co oznacza, że model może ewoluować, aby odzwierciedlać rzeczywiste potrzeby integracyjne, a nie pojedynczy plan rozwoju (roadmap).
• Proces zorientowany na specyfikację. Model Joint Development Foundation opiera się na tworzeniu i utrzymywaniu specyfikacji, co jest zgodne ze sposobem przyjmowania standardów i odwoływania się do nich w przeglądach zamówień i architektury.

Zachęcamy do wnoszenia wkładu, który jest otwarty dla wszystkich. Wkład zazwyczaj przyjmuje formę nowych lub udoskonalonych Obszarów Tematycznych, poprawek i wyjaśnień, przykładowych diagramów oraz informacji zwrotnych z rzeczywistych projektów integracyjnych. Najcenniejszy wkład często pochodzi od praktyków, którzy napotkali konkretny problem z mapowaniem i potrafią opisać koncepcję, która go rozwiązuje.

Nasz wybór: Workato — Oparte na automatyzacji iPaaS, na którym zespoły biznesowe mogą faktycznie bazować.

Zaangażuj się

Jesteś zainteresowany dołączeniem do inicjatywy CIM? Świetnie! Zapraszamy do kontaktu e-mailowego w celu uzyskania dalszych informacji.

Poza e-mailami, naturalnymi sposobami zaangażowania są: przejrzenie opublikowanych Obszarów Tematycznych dla interesującej Cię domeny, próba zmapowania jednego ze swoich systemów na domenę oraz zgłaszanie znalezionych luk społeczności. Ponieważ liczba i zakres Obszarów Tematycznych rosną wraz z konsorcjum i wkładem użytkowników, model ulepsza się proporcjonalnie do liczby rzeczywistych problemów integracyjnych, jakie wnoszą do niego jego użytkownicy.

Często zadawane pytania

Czym dokładnie jest Cloud Information Model?

CIM to niezależny od aplikacji, otwarty model danych, który definiuje wspólne koncepcje biznesowe i ich relacje, dzięki czemu różne aplikacje mogą wymieniać dane za pomocą wspólnego słownictwa. Jest tworzony przez otwarte konsorcjum i publikowany jako otwarta specyfikacja. Nie jest to produkt, który instalujesz, lecz model, do którego mapujesz swoje systemy.

Dla kogo jest CIM?

Jest skierowany do architektów danych korporacyjnych, inżynierów integracji i ETL, dostawców aplikacji i platform oraz kontrybutorów open source. Potencjalnym użytkownikiem jest każdy, kto musi połączyć wiele systemów chmurowych i lokalnych o różnych schematach. Dostawcy odnoszą korzyści, ponieważ wspólny model zmniejsza nakład pracy niestandardowej wymaganej do integracji z ich produktami.

W jaki sposób CIM jest zarządzany i licencjonowany?

CIM jest udostępniany jako open source w ramach Joint Development Foundation, która działa pod egidą Linux Foundation. Zapewnia to neutralny dla dostawców, zorientowany na specyfikację model zarządzania. Struktura ta ma na celu utrzymanie modelu otwartego na wkład i niezależnego od kontroli któregokolwiek z dostawców.

Czym CIM różni się od natywnego modelu danych dostawcy?

Natywny model dostawcy jest zoptymalizowany pod kątem produktu i ekosystemu tego dostawcy; przyjęcie go jako centrum integracji ma tendencję do tworzenia uzależnienia od dostawcy (lock-in). CIM został zaprojektowany tak, aby był niezależny od aplikacji, więc żadna pojedyncza platforma nie definiuje słownictwa. Kompromisem jest to, że CIM wymaga zarządzania i porozumienia między zespołami, podczas gdy model dostawcy jest gotowy do użycia w ramach narzędzi tego dostawcy.

Czy nadal muszę tworzyć mapowania, jeśli korzystam z CIM?

Tak. Każdy system źródłowy nadal wymaga mapowania na wspólny model. Korzyścią jest to, że tworzysz jedno mapowanie z systemu do CIM, zamiast osobnego tłumaczenia dla każdej pary systemów. Zmienia to kombinatoryczny wysiłek mapowania w wysiłek w przybliżeniu liniowy i zapewnia stabilny kontrakt, który przetrwa zmiany w poszczególnych systemach.

Jak rozpocząć wdrażanie CIM?

Zacznij od pojedynczej, problematycznej i dobrze ograniczonej integracji w jednym obszarze tematycznym (Subject Area). Przeprowadź inwentaryzację schematów źródłowych, zmapuj każdy system na domenę CIM, zdefiniuj politykę rozszerzeń i zarządzania oraz traktuj mapowania jako wersjonowane artefakty. Gdy pierwsza domena udowodni swoją wartość, rozszerzaj ją domena po domenie, ponownie wykorzystując ustanowione wzorce i zasady zarządzania.

Dalsza lektura

• Linux Foundation — Wikipedia
• Linux Foundation — Wikipedia