Rozdzielenie platformy od aplikacji w Dynamics 365 (9.x.x.x) – o co chodzi Microsoftowi?

Prawdziwy Dynamics 365 nadchodzi!

Pamiętam kilka naprawdę gorących rozmów z Klientami (i przy okazji Microsoft’em) o tym, dlaczego nie warto migrować się do Microsoft Dynamics 365, który pojawił się na rynku w 2016 roku. Ci klienci, którzy nam uwierzyli w lutym i marcu tego roku i posłuchali, że „tamten” Dynamics 365 z grudnia to jedynie update, a nie nowa wersja (8.2.x.x, a nie 9.x.x.x) dobrze na tym wyszli. Ci, którzy uwierzyli mimo naszych warsztatów Microsoftowi przeżyli koszmar z migracją do nowych licencji i do platformy, która była przejściowa. Teraz muszą zmierzyć się z migracją do tego prawdziwego Dynamics 365 :). Dlatego warto wierzyć ekspertom, a nie sprzedawcom, ale to tak przy okazji.

Tak, czy inaczej, prawdziwy Dynamics 365 (a więc wersja z nowym numerem) nadchodzi wielkimi krokami. Należy więc zacząć przygotowywać się do niej z odpowiednią uwagą.

Rozdzielenie platformy i aplikacji, czyli co?

Jedną ze zmian, o których rzadko mówią sprzedawcy Microsoftu (z mojego doświadczenia nawet o niej nie wiedzą, bo to nie jest coś, co się „łatwo sprzedaje”) jest tzw. application-platform separation, czyli rozdzielenie platformy Microsoft Dynamics CRM (tak, CRM, nie żaden Dynamics 365) od logiki i modułów funkcjonalnych. Z wysokiego poziomu można to rozdzielenie opisać w taki sposób:

Do tej pory mieliśmy moduł Sprzedaży, Marketingu i Obsługi Klienta wbudowany w platformę. Te moduły, niejako, były częścią Microsoft Dynamics CRM. Były tam zawsze; no dobra, Obsługi Klienta nie było w 1.2 😉 ). Generalnie chodzi o to, że kupując Microsoft Dynamics CRM kupowaliśmy te trzy moduły i platformę do budowania aplikacji xRM:

Od wersji 9.0 wszystkie te moduły, które znamy od lat i które dla wielu osób są tożsame z „CRM’em”, zostaną „wyrzucone” z „platformy”, która staje się z powrotem platformą, czyli czymś, na czym można budować dowolne inne aplikacji.

Witajcie w historii MBS CRM i w 2003 roku!!! 🙂 Już wtedy Philip Richardson (teraz w Salesforce) był adwokatem osobnej platformy xRM i budowania na niej „appek” w oparciu o SDK. Nomen omen, teraz ta platforma ma roboczą nazwę… xRM Server.

xRM Server jest więc platformą do budowania aplikacji i obejmuje (nazwy Rozwiązań celowo po angielsku, bo takie będą nazwy Solucji w v9!):

 

Oczywiście istniejące moduły zostają „w CRM’ie”, ale technicznie będą realizowane już przez osobne Rozwiązania i nie będą „częścią systemu”. To, w wersji 9.0, dotyczy również modułu Sprzedaży, Marketingu i Obsługi Klienta – od nowej wersji nie są one już częścią platformy, a stają się Rozwiązaniami (Solutions)!!!

 

Czemu tak?

Od niedawna widać, że Microsoft zaczął dodawać kupowane przez siebie produkty (portale ADX, FieldOne) jako solucje (rozwiązania) do Dynamics CRM. Oczywiście to wynika z faktu, że partnerzy robiący wcześniej te rozwiązania oferowali je swoim Klientom jako solucje, więc naturalnym krokiem było pozostawienie ich w tej formie, zamiast podejmowania próby „wbudowywania” ich w platformę. Dodatkowo takie podejście ma mnóstwo innych zalet…

 

Zalety rozdzielenia platformy od logiki aplikacji

Trzymanie konkretnych funkcjonalności / modułów jako osobne rozwiązania, w separacji od platformy ma szereg zalet w kontekście Microsoft Dynamics 365, m.in.:

• Możliwość aktualizacji konkretnego modułu (np. Sprzedaży) bez konieczności podnoszenia wersji całej platformy
• Brak zależności od konkretnego partnera / zespołu wewnątrz Microsoft podczas aktualizacji ważnych dla nas funkcjonalności
• Rozdzielenie kodu platformy od kodu realizującego konkretne funkcjonalności, przez co developerzy mają znacznie mniej zależności przy rozwoju konkretnego modułu
• Możliwość szybszego nadążania za rynkiem w kontekście konkretnego modułu bez oglądania się na całą platformę
• Ogromna zmiana w podejściu do implementacji rozwiązań przez partnerów, bo nie będziemy zależni od „wszystkich” komponentów encji systemowych, ale w zamian będziemy zależni tylko od poszczególnych modułów

 

Na czym technicznie polega to rozdzielenie?

Platforma Microsoft Dynamics 365 składa się z wielu komponentów/warstw (od bazy danych, przez serwery web’owe aż po aplikacje natywne i kod po stronie klienta). Dlatego rozdzielenie, o którym mowa w tym poście, musiało dotyczyć wszystkich tych warstw.

W warstwie serwerowej oznacza to, że:

• cały kod charakterystyczny dla poszczególnych modułów został przeniesiony do plug-in’ów
• metadane encji (a także jej elementów, takich jak widoki i formularze) zostały przeniesione do konkretnych rozwiązań

W warstwie klienckiej rozdzielenie platformy od aplikacji polegało na:

• przepisaniu wszystkich stron ASPX na własne kontrolki w oparciu o CCF (Custom Control Framework)
• kod JScript został skonwertowany na TypeScript

Jak możecie się domyślać, rozdzielenie oznacza, że przybędzie nam Rozwiązań (Solutions). I tak, w wersji 9.0, mamy następujące Rozwiązania:

• LeadManagement
• ProductManagement
• ClientUtilities
• Sales
• Scheduling
• ServiceManagement
• Marketing

 

Ktoś może zapytać „No dobra, a co stanie się, jak nie zainstaluję tych rozwiązań?” A, to odpowiedź jest prosta – sama platforma (xRM Server) bez doinstalowanych rozwiązań z funkcjonalnością np. Sprzedaży sprowadzi się po stronie UI jedynie do modułu Ustawień J. A to dlatego, że cała funkcjonalność będzie teraz realizowana przez dedykowane solucje.