Microsoft Dataverse: Ewolucja

Microsoft Dataverse jest podstawowym komponentem służącym do budowy aplikacji Power Apps opartych na modelu danych. Nazwa „Dataverse” pojawiła się po raz pierwszy pod koniec 2020 roku. Osoby rozpoczynające przygodę z systemami low/no-code mogą natomiast nie zdawać sobie sprawy, że omawiana usługa nie jest czymś zupełnie nowym. Jest ona bowiem wynikiem ewolucji technologii, dostępnej na rynku od kilkunastu lat i będącej w czasach „przedchmurowych” po prostu systemem instalowanym we własnej serwerowni. Zapraszam do lektury poniższego tekstu, będącego w założeniach krótką historią ewolucji Microsoftowego „uniwersum danych”.

Dawno, dawno temu w niezbyt odległej galaktyce istniał sobie system o nazwie Microsoft CRM. Dla niewtajemniczonych – skrót CRM rozwijamy jako: „customer relationship management” (zarządzanie relacjami z klientami). Natomiast systemy CRM to po prostu informatyczne produkty wspierające ww. procesy. Nieco później w wyniku rebrandingu aplikacji biznesowych firmy Microsoft omawiany system został przemianowany na Dynamics CRM. Było to w czasach, kiedy w samym Microsofcie (a przynajmniej w jego polskim oddziale, w którym miałem wówczas przyjemność pracować) mało kto wiedział o jego istnieniu. Topowym produktem oferowanym klientom był wówczas SharePoint, w przekonaniu sprzedawców system „do wszystkiego”, w tym również do budowy wszelakich aplikacji LOB. Dynamics CRM wymagał całego zestawu wcale nie tanich licencji (własnych oraz licencji produktów wymaganych do jego prawidłowego działania, takich jak np. Windows Server, SQL Server lub Microsoft Exchange) i był wówczas w moim przekonaniu produktem mocno niszowym, na dodatek posiadającym bardzo niewielką część rynku w porównaniu do konkurencyjnych rozwiązań firm Oracle, Siebel lub SAP.

Warto wspomnieć w tym miejscu, że Dynamics CRM posiadał bardzo rozbudowane możliwości rozbudowy oraz tworzenia nowych funkcjonalności za pomocą narzędzi low/no-code, a także za pomocą ogólnie znanych języków programowania (C#, JavaScript). Umożliwiało to klientom firmy Microsoft oraz jej partnerom budowę w oparciu o omawiany system aplikacji LOB, które z „klasycznym” zarządzeniem relacjami z klientami nie miały totalnie nic wspólnego. To wówczas po raz pierwszy pojawiła się idea „Xrm”, czyli platformy przeznaczonej do budowy dowolnych (symbolizowanych przez „X” w nazwie) aplikacji opartych o relacyjny („RM”) model danych.

Czas płynął, a system (cały czas w wersji on-premise) ewoluował. Wersja 2011 była bardzo podobna do aplikacji MS Office i posiadała nawigację oparta o słynną „wstążkę”. Na początku drugiego dziesięciolecia dwudziestego pierwszego wieku zaczęły się pierwsze, nieśmiałe próby przenoszenia aplikacji do Internetu i oferowania jej jako usługi w modelu subskrypcji. Bądźmy szczerzy – działało to wówczas nie za dobrze i standardem było odbieranie telefonów od niezadowolonych klientów narzekających na niedostępność systemu oraz kiepskie wsparcie usługi (kto próbował się w tamtych czasach dodzwonić do Indii i wyjaśnić konsultantowi, że odpowiedź w rodzaju „U mnie działa” w żaden sposób nie rozwiązuje problemu, wie o czym piszę).

W międzyczasie Microsoft budował zestaw aplikacji oraz systemów low/no-code pod wspólną nazwą Power Platform. Jednocześnie kolejne aplikacje biznesowe (głównie rozmaite systemy ERP) udostępniane były jako usługi w Internecie. Narodził się brand Dynamics 365 skupiający wszystkie aplikacje biznesowe Microsoftu. Powstała również idea usługi określanej wówczas jako Common Data Model, która w założeniu miała oferować współdzielony model oraz repozytorium danych dla wszystkich ww. systemów. Jest to pomysł, która do tej pory nie została w pełni zrealizowany.

Ważną kwestią było to, że w miarę upływu czasu aplikacje biznesowe dostępne w chmurze SaaS działały coraz lepiej. Powoli kończyły się problemy z ich dostępnością lub nieprawidłowym działaniem poszczególnych komponentów. Zapoczątkowało to jednak proces powolnego wymierania partnerów firmy, opierających swój model biznesowy na usługach hostingu omawianych systemów. Cóż, nie pierwszy i nieostatni raz wielki brat z Redmond zaorał biznes współpracujących z nim organizacji.  

Ważną kwestią, o której należy wspomnieć, była transformacja usługi Common Data Model w Common Data Service. Na pozór była to drobna zmiana nazewnictwa. Jednak w rzeczywistości był to pierwszy moment, w którym Microsoft przyznał (oczywiście, z korporacyjny, pokrętny sposób 😉), że pomysł budowy „od zera” współdzielonego modelu danych nie wypalił. Na szczęście firma zorientowała się, że posiada już technologię oferującą podobne możliwości. Mam oczywiście na myśli stary, dobry silnik, klasycznego CRM-a. W taki oto sposób platforma określana niegdyś jako „Xrm” przekształciła się w Common Data Service.

W omawianym okresie kupując dostęp do usługi klienci otrzymywali dostęp do wszystkich modułów systemu, które dostępne były wcześniej w modelu on-premise (Sales, Customer Service, Marketing). Microsoft zdecydował się na udostępnienie klientom możliwości zakupu poszczególnych modułów funkcjonalnych w postaci osobnych aplikacji (Dynamics 365 Sales, Dynamics 365 Customer Service, itd.). Natomiast niestandardowe rozwiązania oparte o platformę Common Data Service i tworzone przez klientów lub partnerów zaczęły być określane jako aplikacje Power Apps oparte na modelu danych (model-driven Power Apps). Zmiana ta spowodowana była głównie ekspansją marki „Power Apps” oraz próbami sprzedaży jak największej ilości technologii pod tą flagą, a nie faktycznymi kwestiami technicznymi. W kronikarskiego obowiązku wspomnę, że aplikacje Dynamics 365 posiadały (i do dzisiaj posiadają) zupełnie innych model licencjonowania, niż te wykorzystujące brand „Power Apps”.

W końcu, po latach niejasności, bałaganu nazewniczego oraz niepewności co do przyszłości wszystko stało się w miarę jasne. Klienci oraz partnerzy otrzymali możliwość budowy własnych aplikacji Power Apps opartych o usługę Common Data Service. Natomiast Microsoft zaoferował własne aplikacje biznesowe (pod szyldem Dynamics 365), które również wykorzystywały wewnętrznie CDS (czyli dla przypomnienia – dawny silnik CRM/XRM). Minusem tej sytuacji był i niestety do dzisiaj jest bałagan oraz poziom skomplikowania poszczególnych modeli licencyjnych. Nastały czasy, w których kwestia dopasowania odpowiednich licencji do wykorzystywanych aplikacji biznesowych stała się bardziej skomplikowana niż ich faktyczna budowa i proces udostępnienie ich funkcjonalności użytkownikom.

Ostatnim krokiem ewolucji była zmiana nazwy usługi Common Data Service na Microsoft Dataverse. Incydent z próbą jej przechrzczenia na Microsoft Dataflex (okazało się, że nazwa ta jest już zarezerwowanym znakiem towarowym) litościwie przemilczę. Aktualnie Microsoft Dataverse cały czas ewoluuje, dochodzą do niej nowe funkcjonalności oraz powstają jej różne odnogi, np. Microsoft Dataverse for Teams.

Ja natomiast mam cichą satysfakcję, że technologia, z którą pracuje już od kilkunastu lat, istnieje do dzisiaj i jest podstawą platformy wykorzystywanej przez dziesiątki tysięcy klientów na całym świecie. Oczywiście przeszła ona wiele zmian, począwszy od prostego systemu do zarządzania relacjami z klientami, poprzez aplikację biznesową udostępnianą jako usługę, a skończywszy jako platforma umożliwiająca budowę własnych modułów funkcjonalnych, oparta i zintegrowania z chmurą Azure oraz (za pomocą adapterów) z setkami innych usług dostępnych w Internecie.

Na zakończenie pozwolę sobie, przytoczyć z pamięci kilka cytatów związanych z najlepszym na świecie systemem 😉. Z góry przepraszam ich autorów (których niestety nie jestem już w stanie sobie przypomnieć) za ewentualne nieścisłości 😉. Pochodzą one bowiem sprzed wielu lat i zostały  wykopane z najdalszych zakamarków mojej pamięci.

„CRM? Czy to jakiś dodatek do SharePointa?”

„CRM w Microsofcie nie ma przyszłości. To jest firma od Windowsa i Office’a…”

„Microsoft nie umie chmury. Biznesowych aplikacji też nie umie.”

„Ten cały no-code to chwilowa moda. Nie ma możliwości, żeby to się przyjęło!”

Total Views: 372 ,
Be the first to comment

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Wymagane pola są oznaczone *