Model Informacji Chmurowej

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

Kluczowe wnioski

• CIM to otwarty, niezależny od aplikacji model danych — wspólny słownik koncepcji biznesowych (klienci, zamówienia, produkty itd.), który umożliwia różnym systemom chmurowym i lokalnym wymianę danych bez konieczności tworzenia dedykowanego mapowania punkt-punkt.
• Istnieje, aby rozwiązać konkretny, kosztowny problem: każda aplikacja dostarcza własny model danych, przez co zespoły integracyjne kończą pisząc i utrzymując niestandardowy kod tłumaczenia, który jest kruchy i spowalnia innowacje.
• Jest zarządzany jako otwarty standard, opracowany przez konsorcjum i udostępniony na zasadach open source w ramach Joint Development Foundation, będącej częścią Linux Foundation — dzięki czemu każdy może go współtworzyć, przeglądać i adoptować.
• Treść jest zorganizowana w Obszary Tematyczne (domeny), z których każdy reprezentuje główną koncepcję biznesową, a projekty są publikowane w wielu formatach, w tym w formie przykładowych diagramów.
• CIM to model, a nie produkt. Definiuje znaczenie i strukturę; to Ty nadal wybierasz sposób mapowania, przechowywania i przesyłania danych we własnych systemach.

Nowy standard interoperacyjności danych

CIM jest opracowywany przez otwarte konsorcjum utworzone w celu dostarczenia opartego na standardach rozwiązania do łączenia produktów dla przedsiębiorstw. Dzięki CIM możesz tworzyć płynne i dostosowane 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. 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, aby ułatwić komunikację pomiędzy różnymi formatami danych. Jako projekt open source w ramach Joint Development Foundation (pod egidą Linux Foundation), zapraszamy wszystkich współtwórców.

Dlaczego modele danych specyficzne dla aplikacji zawodzą

Podstawowym problemem, który rozwiązuje CIM, nie jest to, że jakakolwiek pojedyncza aplikacja ma zły model danych. Większość z nich jest całkowicie rozsądna w obrębie własnych granic. Problemem jest eksplozja kombinatoryczna, która następuje przy łączeniu wielu z nich.

Rozważmy typowy stos korporacyjny: CRM, ERP, platformę do automatyzacji marketingu, system obsługi zgłoszeń (support desk), hurtownię danych i kilka biznesowych narzędzi SaaS. Jeśli każdy system ma własne pojęcie „klienta”, „konta”, „zamówienia” i „produktu”, to każda para systemów, która musi wymieniać dane, wymaga własnego mapowania. Liczba integracji rośnie w przybliżeniu wraz z kwadratem liczby systemów, a każde mapowanie to mały, nieudokumentowany i nieprzypisany do nikogo fragment logiki, który ktoś musi utrzymywać w nieskończoność.

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

Objawy są znane każdemu, kto zarządzał procesami integracji:

• Dryf semantyczny. „Klient” w CRM oznacza podmiot rozliczeniowy; w systemie wsparcia oznacza osobę zgłaszającą tickety. To samo słowo, dwa znaczenia, po cichu pogodzone przez mapowanie, którego nikt nie pamięta z pisania.
• Kruche potoki (pipelines). Dostawca zmienia nazwę pola lub wartość wyliczenia (enum), a zadanie ETL kończy się niepowodzeniem o 2 w nocy, ponieważ mapowanie zostało zakodowane na sztywno według starego schematu.
• Duplikacja wysiłku. Dwa zespoły niezależnie tworzą niemal identyczne tłumaczenia między tymi samymi dwoma systemami, ponieważ nie ma wspólnego punktu odniesienia.
• Uzależnienie od dostawcy poprzez dane (vendor lock-in). Migracja z platformy jest kosztowna nie ze względu na oprogramowanie, ale przez skumulowaną logikę tłumaczeń powiązaną z jej schematem.

Wspólny, niezależny od aplikacji model uderza w przyczynę źródłową: zamiast mapowań N-do-N, każdy system mapuje dane raz do wspólnego modelu, a wspólny model niesie znaczenie.

Co właściwie oznacza „niezależny od aplikacji”

Warto być precyzyjnym w kwestii filozofii projektowania, ponieważ słowo „agnostyczny” jest często używane w sposób potoczny.

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

Model niezależny od aplikacji nie jest własnością żadnego pojedynczego dostawcy ani nie jest pod niego zoptymalizowany. Opisuje koncepcje biznesowe w kategoriach, które byłyby rozpoznawalne dla eksperta dziedzinowego — klient, zamówienie, produkt, lokalizacja — a nie w kategoriach odzwierciedlających wewnętrzne tabele jednej aplikacji. Ta neutralność sprawia, że jest on użytecznym centrum (hub): żaden uczestnik nie musi przyjmować światopoglądu konkurenta, aby zapewnić interoperacyjność.

To ten sam instynkt architektoniczny, który stoi za innymi neutralnymi standardami wymiany. Tak jak Resource Description Framework (RDF) i schema.org dają sieci wspólny słownik do opisywania rzeczy, a EDI i później UBL (Universal Business Language, standard OASIS) dały łańcuchom dostaw wspólny format transakcji, tak CIM ma na celu zapewnienie aplikacjom korporacyjnym wspólnego słownictwa dla ich kluczowych encji biznesowych. Różnica polega na zakresie i nowoczesności: CIM celuje w połączony, oparty na API świat chmurowy i lokalny, a nie w wymianę plików wsadowych.

Przydatnym modelem mentalnym jest wzorzec kanonicznego modelu danych z integracji przedsiębiorstw, spopularyzowany w książce Enterprise Integration Patterns autorstwa Gregora Hohpe i Bobby’ego Woolfa. CIM jest w efekcie wspólnie utrzymywanym modelem kanonicznym — „centrum” w topologii integracji typu hub-and-spoke — ale takim, który jest otwarty, wersjonowany i współdzielony między organizacjami, a nie wymyślonym prywatnie wewnątrz jednej firmy.

Jak zorganizowany jest CIM: Obszary Tematyczne i domeny

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.

W praktyce oznacza to, że należy myśleć o CIM jak o bibliotece powiązanych modeli, a nie o pojedynczym, monolitycznym schemacie. Typowe obszary tematyczne (Subject Areas) skupiają się wokół rozpoznawalnych kwestii biznesowych — na przykład stron i kont, produktów i katalogów, zamówień i transakcji oraz relacji, które je łączą. Ponieważ każdy obszar jest publikowany wraz z diagramami i definicjami czytelnymi maszynowo, różne zespoły mogą wdrażać różne obszary w różnym czasie, nie czekając na ukończenie całego modelu.

Z tej struktury wynika kilka praktycznych implikacji:

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

• Wdrażaj stopniowo. Nie musisz od razu mapować całego przedsiębiorstwa do CIM. Zacznij od obszaru tematycznego, który sprawia najwięcej problemów – zazwyczaj jest to domena klienta lub zamówienia – i rozszerzaj go.
• Rozszerzaj, zamiast tworzyć forki. Gdy w CIM brakuje koncepcji, której potrzebujesz, model otwarty jest zaprojektowany tak, aby można go było rozbudować. Przekazanie rozszerzenia z powrotem do projektu jest lepsze niż utrzymywanie prywatnego forka, ponieważ fork z czasem dryfuje i traci korzyści z interoperacyjności.
• Traktuj diagramy jako dokumentację, a nie źródło prawdy. Przykładowe diagramy są przeznaczone dla ludzi; to definicje czytelne maszynowo powinny być konsumowane przez Twoje narzędzia.

CIM w krajobrazie integracji: jak podjąć decyzję

CIM to jedna z kilku opcji pozwalających okiełznać złożoność integracji. Dobry wybór wymaga dopasowania narzędzia do problemu. Poniższa tabela zestawia główne podejścia, które zazwyczaj rozważa architekt danych w przedsiębiorstwie.

Podejście	Co to jest	Najlepsze, gdy	Główny kompromis
Mapowanie punkt-punkt	Niestandardowy kod tłumaczący bezpośrednio między dwoma systemami	Tylko dwa systemy, stabilne schematy, krótki horyzont czasowy	Nie skaluje się; eksplozja N-do-N; kruchość
Model kanoniczny (np. CIM)	Wspólny, neutralny model, do którego każdy system jest mapowany raz	Wiele systemów, różni dostawcy, długotrwała integracja	Początkowy wysiłek modelowania; wymagane zarządzanie (governance)
Konektory iPaaS dostawcy	Gotowe konektory z platformy integracyjnej	Typowe pary SaaS, szybkość ponad kontrolą	Semantyka specyficzna dla konektora; potencjalny lock-in
Branżowe standardy wymiany (EDI, UBL, HL7 itp.)	Formaty wiadomości specyficzne dla domeny	Sektory regulowane lub dobrze ugruntowane	Wąski zakres; często zorientowane na przetwarzanie wsadowe
Wirtualizacja danych / federacja	Zapytania między źródłami bez centralizacji	Analityka, dostęp głównie do odczytu	Nie rozwiązuje samodzielnie konfliktów semantycznych

Heurystyka decyzyjna jest prosta: jeśli masz więcej niż kilka systemów, które muszą być zgodne co do znaczenia wspólnych encji, a systemy te pochodzą od różnych dostawców, model kanoniczny zwraca się z nawiązką. Jeśli masz dwa systemy i nie planujesz dodawać kolejnych, mapowanie punkt-punkt jest w porządku. Jeśli Twoja potrzeba ma charakter czysto analityczny i dotyczy tylko odczytu, federacja może wystarczyć — ale pamiętaj, że federacja przesuwa problem semantyczny, zamiast go rozwiązywać.

CIM stanowi uzupełnienie, a nie zamiennik dla otaczających go narzędzi. Potok ETL lub ELT (zbudowany przy użyciu np. Apache Airflow, dbt lub platformy komercyjnej) nadal odpowiada za przesyłanie danych; CIM definiuje, co te dane oznaczają po dotarciu do celu. Broker komunikatów, taki jak Apache Kafka, nadal zajmuje się transportem; CIM określa kształt zdarzeń. Model jest kontraktem; narzędzia są instalacją (plumbing).

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

Zarządzanie, licencjonowanie i dlaczego Fundacja ma znaczenie

CIM jest udostępniony jako open source w ramach Joint Development Foundation, która działa pod egidą Linux Foundation. To nie jest trywialny szczegół — jest to klucz do tego, dlaczego przedsiębiorstwo może bezpiecznie budować rozwiązania w oparciu o CIM.

Linux Foundation jest uznanym, neutralnym domem dla wspólnych projektów open source, a Joint Development Foundation zapewnia lekką strukturę prawną do wspólnego opracowywania standardów i specyfikacji. Hostowanie CIM w tym miejscu oznacza:

• Neutralne zarządzanie. Żaden pojedynczy dostawca nie kontroluje modelu, więc jego przyjęcie nie oznacza przyjęcia mapy drogowej konkurenta.
• Otwarty wkład. Każdy — dostawcy, przedsiębiorstwa, indywidualni kontrybutorzy — może proponować zmiany, a proces jest przejrzysty.
• Przewidywalne licencjonowanie. Specyfikacje hostowane przez Fundację zazwyczaj zawierają warunki zaprojektowane z myślą o szerokiej adopcji bez opłat licencyjnych (royalty-friendly), co ma ogromne znaczenie dla zespołów prawnych i zakupowych oceniających standard.

Dla architekta argumentującego wybór wewnątrz organizacji, ta kwestia zarządzania jest często równie ważna jak treść techniczna. „To otwarty standard pod egidą Linux Foundation” odpowiada na pytania, które często blokują adopcję standardów: Kto go kontroluje? Co się stanie, jeśli dostawca zniknie z rynku? Czy możemy przekazać nasze rozszerzenia?

Pierwsze kroki: praktyczna ścieżka adopcji

Przyjęcie wspólnego modelu jest w równym stopniu ćwiczeniem organizacyjnym, co technicznym. Pragmatyczna sekwencja wygląda następująco:

1. Zrób inwentaryzację wspólnych encji. Zidentyfikuj koncepcje biznesowe, które pojawiają się w więcej niż jednym systemie — zazwyczaj są to klient, produkt, zamówienie i lokalizacja. To Twoi kandydaci.
2. Wybierz jeden obszar tematyczny i jedną integrację. Wybierz integrację, która sprawia największy problem, ale ma najmniejszy „promień rażenia” (blast radius), aby przetestować model. Idealny będzie pojedynczy potok raportowy lub wdrożenie jednej nowej aplikacji.
3. Zmapuj każdy system do CIM tylko raz. Zbuduj translację z każdego systemu źródłowego do reprezentacji CIM oraz z CIM do każdego celu. Powstrzymaj pokusę mapowania systemów bezpośrednio między sobą.
4. Udokumentuj swoje rozszerzenia. Tam, gdzie CIM nie obejmuje danej koncepcji, wyraźnie odnotuj rozszerzenie i rozważ przekazanie go z powrotem do projektu.
5. Ustanów odpowiedzialność. Model kanoniczny bez opiekuna (steward) ulega degradacji. Przypisz zespół lub rolę odpowiedzialną za mapowania i śledzenie zmian u dostawców (upstream).
6. Wersjonuj i testuj. Traktuj model i jego mapowania jako wersjonowane artefakty z testami, dokładnie tak samo, jak kod aplikacji.

Najczęstszym powodem niepowodzenia jest traktowanie CIM jako jednorazowego ćwiczenia z modelowania, a nie żywego kontraktu. Organizacje, które odnoszą sukces, traktują model tak, jak traktują interfejs API: wersjonują go, testują, przypisują mu właściciela i rozwijają w sposób przemyślany.

Partnerzy współpracujący z CIM

CIM jest przedsięwzięciem konsorcjum, a jego wartość rośnie wraz z liczbą uczestników. Partnerzy wnoszą wkład do treści obszarów tematycznych (Subject Areas), przeglądają propozycje i pomagają kształtować kierunek rozwoju modelu. Ponieważ prace są otwarte, wkład nie ogranicza się do dużych dostawców — przedsiębiorstwa borykające się z realnymi problemami z integracją oraz indywidualni praktycy posiadający wiedzę domenową są równie mile widziani.

Skontaktuj się

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

Często zadawane pytania

Co to jest Cloud Information Model (CIM)?

CIM to niezależny od aplikacji, otwartoźródłowy model danych, który zapewnia wspólne, oparte na standardach słownictwo dla koncepcji biznesowych, którymi przedsiębiorstwa muszą wymieniać się pomiędzy aplikacjami chmurowymi a lokalnymi (on-premises). Jest on tworzony przez otwarte konsorcjum i hostowany w ramach Joint Development Foundation, będącej częścią Linux Foundation. Jego celem jest ograniczenie ilości niestandardowego kodu mapowania, którego wymagają kruche integracje punkt-punkt.

Czy CIM to produkt czy specyfikacja?

CIM to specyfikacja — model i zestaw definicji — a nie produkt, który można uruchomić. Definiuje on znaczenie i strukturę wspólnych encji; nadal wybierasz własne narzędzia ETL/ELT, brokerów komunikatów i pamięć masową. Pomyśl o tym jak o kontrakcie, który implementuje Twoja infrastruktura integracyjna, a nie o samej infrastrukturze.

Czym CIM różni się od platformy integracyjnej dostawcy?

Platforma integracyjna (iPaaS lub biblioteka konektorów) przenosi dane i często dostarcza gotowe konektory, ale konektory te kodują semantykę specyficzną dla dostawcy. CIM jest neutralny i niezależny od dostawcy, więc nie zamyka Cię w światopoglądzie jednej platformy. Te dwa podejścia się uzupełniają: możesz używać CIM jako modelu kanonicznego wewnątrz dowolnej platformy integracyjnej.

Czym są obszary tematyczne (Subject Areas) w CIM?

Obszary tematyczne (zwane również domenami) to jednostki organizacyjne modelu, z których każda reprezentuje główną koncepcję biznesową, taką jak klienci, produkty lub zamówienia. Projekty są publikowane w wielu formatach, w tym w formie przykładowych diagramów, a zestaw obszarów tematycznych będzie rósł w miarę dostarczania nowych treści przez konsorcjum i społeczność.

Czy możemy rozszerzyć CIM, jeśli nie obejmuje on naszych koncepcji?

Tak. CIM został zaprojektowany tak, aby można go było rozszerzać, a ponieważ jest on open source pod egidą neutralnej fundacji, możesz proponować dodatki poprzez proces wnoszenia wkładu. Rozszerzanie wspólnego modelu i dzielenie się zmianami jest zdecydowanie lepsze niż utrzymywanie prywatnego forka, który z czasem oddala się od oryginału i pozbawia korzyści z interoperacyjności, które w pierwszej kolejności motywowały do przyjęcia CIM.

Kto powinien przyjąć CIM?

Jest on najbardziej wartościowy dla organizacji korzystających z wielu aplikacji od różnych dostawców, które muszą uzgodnić znaczenie wspólnych encji — to klasyczna sytuacja dla korporacyjnych architektów danych i inżynierów integracji. Dostawcy aplikacji i platform również odnoszą korzyści, dopasowując swoje schematy do neutralnego modelu, co ułatwia klientom integrację ich produktów. Jeśli posiadasz tylko dwa stabilne systemy, wystarczające może okazać się prostsze mapowanie punkt-punkt.

Dalsza lektura

• Linux Foundation — Wikipedia
• Joint Development Foundation — Wikipedia
• Enterprise Integration Patterns — Wikipedia
• Resource Description Framework (RDF) — Wikipedia