Podróż do usługi SaaS: Dynamics 365

Wielu niezależnych dostawców oprogramowania (ISV) myśli o przejściu z lokalnego dostarczania oprogramowania do modelu dostarczania opartego na chmurze i oprogramowania jako usługi (SaaS). W firmie Microsoft przeszliśmy tę podróż z wieloma naszymi produktami i poprosiliśmy o podzielenie się naszymi rzeczywistymi doświadczeniami i kluczowymi lekcjami, które poznaliśmy po drodze.

Naszym celem w tym artykule jest przedstawienie sposobu, w jaki ta podróż rozgrywa się podczas tworzenia usługi Microsoft Dynamics 365. Opisujemy proces myślowy, przez który przeszliśmy, oraz kluczowe czynniki dla każdego z głównych decyzji, które podjęliśmy. Mamy nadzieję, że ten dokument zapewnia poczucie ewolucji naszego produktu, ponieważ przenieśliśmy się z dostarczania oprogramowania lokalnego do produktu SaaS w hiperskala używanego przez miliony użytkowników w tysiącach organizacji. Mamy nadzieję, że czytając ten dokument, możesz poznać nasze doświadczenia i zaplanować własną podróż do usługi SaaS. Chociaż podróż firmy Microsoft z usługą Dynamics 365 może być unikatowa, uważamy, że wnioski i zasady, które dowiedzieliśmy się, mogą nadal zapewniać cenne informacje dla organizacji o dowolnym rozmiarze, które planują własne przejście do modelu SaaS.

Krótka historia naszej podróży

Usługa Microsoft Dynamics ma głęboką historię jako zestaw produktów lokalnych. Zastosowaliśmy chmurę dla wszystkich oferowanych przez nią wielu korzyści i wiedzieliśmy, że nasz model technologiczny i biznesowy będzie musiał dostosować się w miarę rozwoju modelu SaaS.

Pierwszą decyzją, którą skonfrontowaliśmy, była wybór między tworzeniem czegoś nowego, czy rozwijaniem aplikacji lokalnych w usługach w chmurze. W przypadku usługi Dynamics 365 wierzyliśmy w dwie rzeczy. Po pierwsze, istniała wystarczająca wartość w modelach danych i logice biznesowej, którą utworzyliśmy i zweryfikowaliśmy z tysiącami klientów, że warto było rozwijać nasze istniejące rozwiązania. Po drugie, architektura warstwowa i struktura platformy naszych produktów lokalnych zapewniała odpowiednie dźwignie, aby umożliwić nam szybsze wdrażanie doskonałej architektury chmury niż od podstaw. Kombinacja wartości i szybkości, wraz z zrozumieniem, że możemy wdrożyć zasady natywne dla chmury, sprawiła, że przejście do chmurowego modelu SaaS i ciągłego ulepszania było właściwym wyborem dla usługi Dynamics 365. Inne organizacje mogą mieć różne priorytety i przyjść do innej strategii.

Na początku postanowiliśmy skupić się na tworzeniu najlepszego produktu, który moglibyśmy wykorzystać na platformie Microsoft Azure. Platformy w chmurze szybko się poprawiają i chcieliśmy skorzystać z bogactwa jednej platformy, zamiast rozpowszechniać nasze zasoby w wielu chmurach. Inni dostawcy SaaS mogą podejmować różne decyzje w oparciu o własne sytuacje. Na przykład dostawca platformy poziomej może tworzyć oprogramowanie dla klientów do użycia w wielu chmurach, dlatego warto mieć obecność na każdej z tych platform w chmurze. Jednak deweloper aplikacji SaaS może wybrać, aby skupić się na jednej chmurze i uzyskać korzyści wynikające z skupienia się na tym jednym dostawcy chmury i ich ewolucji. W przypadku usługi Dynamics 365 wiedzieliśmy, że przejście do platformy Microsoft Azure zapewni nam bardziej zintegrowane i bezproblemowe środowisko przy zachowaniu niezawodnych zabezpieczeń i wysokiej wydajności.

Gdy zaczęliśmy głęboko eksplorować platformę Azure i planować naszą podróż w modelu SaaS, dowiedzieliśmy się, jak obsługiwać i skalować ogromną platformę planowania zasobów przedsiębiorstwa (ERP) w chmurze. Jednocześnie platforma Azure stała się bogatsza i bardziej zdolna i wprowadziła nowe możliwości, których nie mogliśmy sobie wyobrazić. Wiedzieliśmy, że stała ewolucja chmury oznacza, że nasza migracja nie będzie jednorazową rzeczą. Zamiast tego myśleliśmy o ciągłym ulepszaniu na każdym etapie naszej podróży. Ciągłe ulepszanie wpływa na wszystko, co robimy, a na wczesnym etapie naszej podróży musieliśmy wprowadzić znaczące zmiany — od naszej ogólnej architektury do sposobu obsługi zapytań bazy danych. Stale rozwijamy nasze rozwiązanie, aby jak najlepiej wykorzystać funkcje chmury. Wprowadziliśmy architekturę mikrousług i używamy generowania sztucznej inteligencji w ramach naszej ciągłej ewolucji. Te podejścia i technologie są łatwiejsze do tworzenia, wdrażania i działania w przypadku korzystania z zaawansowanej platformy w chmurze, takiej jak Microsoft Azure.

Podstawowym składnikiem ciągłego ulepszania chmury jest telemetria. Dzięki efektywnej telemetrii możesz zrozumieć, jak aplikacja jest używana i jak działa — nawet w dół do poziomu poszczególnych funkcji. Telemetria dostarcza wglądu, który pozwala rozwiązywać problemy, znając to, co się stało, zamiast stosować tradycyjne podejścia lokalne, takie jak odtworzenie problemu i debugowanie. Telemetria umożliwia również podejmowanie decyzji inżynieryjnych na podstawie rzeczywistych danych oraz potwierdzanie hipotez dotyczących produktów za pośrednictwem eksperymentów i danych. Tworzenie infrastruktury telemetrii wraz z odpowiednimi zasadami dotyczącymi tego, jakie dane są przechowywane i jak długo są zarządzane, jest czymś, co należy zrobić tak szybko, jak to możliwe.

Zrozumienie zasad klasyfikacji i przechowywania danych zarządzanych przez aplikację wymaga również dodatkowej uwagi w ramach podróży do usługi SaaS. Jako dostawca SaaS Twoje obowiązki wynikające z bieżących i pojawiających się przepisów dotyczących prywatności danych różnią się od sytuacji, w której dostarczano oprogramowanie, które klienci wdrażali i uruchamiali. Ważne jest, aby zrozumieć przepisy dotyczące prywatności danych, które mają zastosowanie do Ciebie jako dostawcy SaaS. Musisz również ustanowić procesy klasyfikacji i przechowywania danych na początku twojej podróży do chmury.

Jak przygotowywaliśmy się do podróży

Określanie zakresu MVP

Nasza strategia koncentruje się na tworzeniu minimalnej opłacalności produktu (MVP), abyśmy mogli jak najszybciej uzyskać rozwiązanie dla klientów i rozpocząć poznawanie unikatowych wyzwań i możliwości saaS. Ten cel był strategicznym wyborem. Uważamy, że szybkie uczenie się i iteracja są niezbędne w chmurze, a definiowanie MVP jest miejscem do rozpoczęcia.

Termin minimalny opłacalny produkt jest często niezrozumiały. Należy wziąć pod uwagę, że oba atrybuty MVP są równie ważne:

• Minimum: dowiedz się, jak najszybciej rozpocząć generowanie wartości dla klientów. Im szybciej klienci korzystają z rozwiązania, tym szybciej zaczniesz uczyć się, jak z niego korzystają i jak można go nadal ulepszać.
• Funkcjonalny: Ważne jest, aby określić zakres swojego produktu tak, aby ktoś mógł uzyskać z niego prawdziwą wartość. Początkowo wybierasz podzbiór całkowitych możliwości, które mają być kompilowane. Wybór odpowiedniego podzestawu jest ważny — jeśli jesteś zbyt minimalny, aby być opłacalnym, klienci nie korzystają z produktu i nie otrzymujesz opinii, które musisz uzyskać, aby się rozwijać.

W przypadku usługi Dynamics 365 skupiliśmy się na tworzeniu produktu, który był gotowy do użycia bezpośrednio od momentu jego uruchomienia. Następnie dowiedzieliśmy się, jak klienci czerpali z niego korzyści, i otrzymaliśmy znaczną ilość opinii oraz danych telemetrycznych. Wykorzystaliśmy te dane, aby kształtować nasz proces rozwoju produktu, wprowadzając drobne ulepszenia i stale go udoskonalając.

Nasza strategia polegała na tworzeniu produktu, który chcieliby nowi klienci. Chociaż chcieliśmy osiągnąć, aby migracje od istniejących klientów korzystających z rozwiązań lokalnych były łatwiejsze, migracja była drugorzędnym celem w porównaniu z tworzeniem wspaniałego nowoczesnego produktu. Ta strategia oznacza, że nasi nowi klienci będą mieli pełne doświadczenie w usłudze Dynamics 365 od samego początku. Przekazali nam również nieocenione opinie i zrobili to z korzyścią dla świeżych oczu. Nie były jeszcze mocno zaangażowane w lokalne produkty Dynamics, więc pomogły nam stworzyć produkt, który naprawdę był oparty wyłącznie na chmurze i pełnoprawną ofertą SaaS. W miarę ulepszania i rozszerzania naszych możliwości w końcu dotarliśmy do punktu, w którym zestaw funkcji obejmował produkty znajdujące się na miejscu. W tym momencie możemy zacząć obsługiwać przejście istniejących klientów z wersji lokalnej na bardziej zaawansowaną usługę Dynamics 365.

Świadomie wybraliśmy tę strategię, ponieważ wiedzieliśmy, że będzie dobrze działać dla systemu ERP. W innych produktach może być możliwe wybranie podzestawu funkcji produktu, aby najpierw to zrobić, a następnie dodać więcej funkcji z czasem. Ale w ERP składniki są ściśle połączone. Produkt nie jest przydatny, dopóki nie zostanie wdrożony kawałek funkcjonalności we wszystkich tych komponentach, zapewniając klientom użyteczne doświadczenie od początku do końca. Zakres MVP to poziomy fragment funkcji w każdym składniku. Postanowiliśmy wybrać krzyżowy zestaw funkcji, które będą obsługiwać przypadki użycia nowych klientów:

W przypadku innych rozwiązań warto zamiast tego określać zakres MVP jako cały składnik. Ważne jest, aby podjąć świadomą decyzję o strategii, którą należy wykonać podczas rozpoczynania własnej podróży do usługi SaaS. Kluczem jest to, że początkowy element dostarczany na rynek powinien być możliwie najmniejszy, a jednocześnie jest wystarczająco kompletny, aby uzyskać rzeczywiste użycie.

Podczas planowania i ulepszania pamiętaliśmy, że oczekiwania klientów również stale się zmieniają. Zamiast migrować nasz produkt w jego obecnym stanie, zaplanowaliśmy, czego będą potrzebować klienci w momencie, gdy będziemy mieli produkt gotowy do użycia. Podróż do modelu SaaS w połączeniu z migracją do chmury jest często długoterminowym przedsięwzięciem, trwa miesiące, a nawet lata. Ważne jest, aby nie tracić wzroku na zmiany zapotrzebowania klientów w tym czasie. W przeciwnym razie można wydać dużo wysiłku, tworząc coś, co nie w pełni zaspokaja potrzeby klientów, gdy w końcu dotrze.

Użycie, zadowolenie klientów i koszty

Przychody z oprogramowania lokalnego są zazwyczaj uznawane w momencie dokonania transakcji sprzedaży, a odpowiedzialność za pomyślne wdrożenie i przyjęcie spoczywa na kliencie. W przypadku modelu subskrypcji SaaS w chmurze klienci często zaczynają od licencjonowania kilku miejsc i rozszerzają swoją subskrypcję tylko po udowodnieniu rozwiązania. Wszelkie zakupione miejsca, które nie są używane, stanowią ryzyko, ponieważ mogą zostać anulowane w kolejnej rocznicy subskrypcji. W związku z przejściem do modelu SaaS zmieniliśmy najważniejsze metryki, które użyliśmy do prowadzenia naszej firmy.

W lokalnym świecie licencjonowanego oprogramowania głównym celem było przychód. W chmurze skupiono się na użyciu i zadowoleniu klientów. Te wskaźniki stały się wiodącymi wskaźnikami przychodów i wzrostu przychodów. Spędziliśmy wysiłek, aby zminimalizować czas pomyślnego wdrożenia, zapewniając widoczność zakupionych, ale nieużywanych licencji oraz utrzymanie wysokiej satysfakcji w rolach użytkowników i firm. Od początku koncentrujemy się na tworzeniu produktów, które klienci kochają używać. Wiemy z doświadczenia, że gdy klienci uzyskują wartość z korzystania z produktu, następuje przychód. Ustalając priorytety doświadczeń klientów i ich użycia, kładziemy fundamenty dla udanej strategii biznesowej.

Podczas tworzenia SaaS koszt sprzedanych towarów (COGS) ma duże znaczenie, zwłaszcza w miarę skalowania i wzrostu kosztów. Jednak lepiej jest najpierw ustalić priorytet zadowolenia i użycia. Jeśli zapewnisz dobre środowisko klienta, możesz zoptymalizować koszty dostarczania usługi, zapewniając bardziej wydajne wykorzystanie zasobów i korzystając z nowych możliwości platformy. Jeśli doświadczenie nie jest wystarczająco dobre, użycie będzie mniejsze i będziesz mieć mniej klientów do zadowolenia. Dlatego podczas przeglądania postępów skupiamy się na trzech kluczowych wskaźnikach wydajności w kolejności ważności:

• Zadowolenie klientów: Czy nasi klienci lubią doświadczenie korzystania z produktu? Jaka jest ich opinia?
• Użycie: Ilu użytkowników mamy? Ile subskrypcji mamy? Czy nasze korzystanie przyspiesza? Jaki jest czas między zakupem a użyciem? Jak zachęcić klientów do korzystania ze wszystkich zakupionych subskrypcji?
• COGS: Ile kosztuje obsługa naszych klientów?

Ważne jest również, aby zastanowić się, jak każdy produkt SaaS generuje przychody. Klienci muszą zrozumieć, jak płacą za usługę, a model cen musi mieć sens. W wielu rozwiązaniach SaaS biznesowych liczba użytkowników, których klient ma, jest doskonałym wskaźnikiem wykorzystania zasobów, gdy użytkownicy korzystają z systemu. Im więcej użytkowników, którzy aktywnie korzystają z systemu, tym więcej zasobów systemowych jest potrzebnych, aby zapewnić im dobre środowisko. Koszt klienta odzwierciedla ten fakt. Klienci mają intuicyjną wiedzę na temat struktury cen opartej na użytkowniku.

Istnieją jednak sytuacje, w których liczba użytkowników nie wskazuje na zasoby używane przez klienta. Na przykład gdy zespół ds. marketingu klienta wysyła dużą liczbę wiadomości na kampanię e-mail, może być tylko jeden użytkownik wysyłający miliony wiadomości e-mail. Podobnie proces w tle, a nie użytkownik, importuje szczegóły zamówienia. Ważne jest, aby klienci rozumieli wskaźniki, którymi są obciążani, i mogli przewidzieć swój rachunek. Możesz użyć mierników, takich jak liczba kontaktów, do których wysyłają wiadomości e-mail, lub liczbę wierszy zamówień, które przetwarzają każdego miesiąca.

Architektura usługi Dynamics 365

Tożsamość, uwierzytelnianie i autoryzacja

Aplikacje biznesowe, takie jak Dynamics 365, zarządzają danymi biznesowymi o wysokiej wartości i automatyzują działania biznesowe o krytycznym znaczeniu. Należy upewnić się, że tylko autoryzowani użytkownicy mają dostęp do danych i akcji systemu. Korzystając z identyfikatora Entra firmy Microsoft, przedsiębiorstwa mogą zarządzać dostępem do usługi Dynamics 365 przy użyciu tych samych narzędzi i platform, których już używają w swoim majątku IT. Klienci mogą korzystać z zaawansowanych funkcji zabezpieczeń, takich jak dostęp warunkowy, bez większej liczby prac nad naszą częścią. Możliwości zabezpieczania systemu Dynamics nadal ewoluują wraz z trwającymi inwestycjami firmy Microsoft na platformie Entra.

Usługa Dynamics 365 przypisuje użytkowników do ról i przypisuje uprawnienia do określonych danych i akcji do tych ról. Ta metoda jest zgodna z typowym wzorcem zarządzania autoryzacją poza uwierzytelnianiem użytkowników udostępnianym przez firmę Entra. Takie podejście zapewnia również możliwość wymuszania wymagań biznesowych dotyczących najlepszych rozwiązań w usłudze Dynamics 365, takich jak rozdzielenie obowiązków.

Model dzierżawy

Każda organizacja korzystająca z usługi Dynamics 365 oczekuje, że ich dane będą bezpieczne i odizolowane od dostępu przez inne organizacje. Modelujemy każdą organizację jako najemcę, a każdy najemca ma wielu użytkowników, którzy mogą korzystać z produktów i współpracować z danymi organizacji. Udostępnianie zasobów zmniejsza koszty komponentów prowadzenia usług, ale udostępnianie musi być zrównoważone względem wymagań w celu zapewnienia oczekiwanych poziomów izolacji najemców. Na szczęście platforma Azure oferuje zaawansowane funkcje umożliwiające dostawcom aplikacji równoważenie kosztów w miarę dostarczania wymaganej izolacji.

Na przykład czuliśmy, że ważne jest przechowywanie danych biznesowych każdego najemcy w oddzielnej bazie danych SQL. Ta separacja pozwala nam między innymi zaimplementować funkcję Transparent Data Encryption (TDE) usługi Azure SQL z kluczami zarządzanymi przez klienta — ważnym składnikiem obietnic zaufania przedsiębiorstwa dotyczących danych. Usługa Azure SQL, w szczególności pule elastyczne, zapewnia wydajność kosztową, jednocześnie zezwalając na oddzielną bazę danych na klienta. Oprócz wzrostu kosztów infrastruktury decyzja o utrzymaniu oddzielnej bazy danych na najemcę zwiększa złożoność zarządzania. Nie ma wystarczającej liczby administratorów baz danych (DBA), aby ręcznie zarządzać bazami danych w skali usługi Dynamics i które doprowadziły do znacznych inwestycji w automatyzację zadań zarządzania. Aby uzyskać więcej informacji na temat sposobu działania usługi Dynamics 365 z bazami danych na dużą skalę, zobacz Running 1M databases on Azure SQL for a large SaaS provider: Microsoft Dynamics 365 and Power Platform (Uruchamianie baz danych 1M w usłudze Azure SQL dla dużego dostawcy SaaS: Microsoft Dynamics 365 i Power Platform).

Dla każdej warstwy naszego rozwiązania nasza strategia polegała na użyciu natywnych funkcji platformy Azure w celu zapewnienia izolacji najemców oraz dostarczenia skalowalności i odporności, jednocześnie uzyskując efektywności kosztowe tam, gdzie to możliwe. Zawsze szukamy możliwości optymalizacji naszego systemu, priorytetowo traktując bezpieczeństwo najemców i zapewniając wyjątkową obsługę klienta.

Sygnatury wdrożenia

Usługa Dynamics 365 działa w hiperskali. Istnieje setki tysięcy klientów, z milionami użytkowników, z których każdy zależy od naszych produktów. Te liczby nadal rosną wraz z upływem czasu. Rozwiązania SaaS zwykle muszą być zaprojektowane do skalowania i muszą obsługiwać klientów na całym świecie.

W chmurze kluczowe jest przejście od skalowania w górę do skalowania poziomego wszędzie tam, gdzie jest to możliwe. Jeśli dodatkowe zapotrzebowanie można spełnić, dodając więcej węzłów (skalowanie w poziomie) zamiast zwiększać możliwości istniejących węzłów (skalowanie w górę), a ta relacja jest zbliżona do liniowej, wówczas podejście oparte na skalowaniu w poziomie zapewnia możliwość zwiększenia skali. Usługa Dynamics 365 używa skalowania poziomego w warstwie aplikacji. Zintegrowane monitorowanie wykrywa wzrost obciążenia określonych dzierżaw i dodaje więcej węzłów, aby zaspokoić zapotrzebowanie.

W połączeniu z modelem dzierżawy i architekturą horyzontalnie skalowaną można postępować zgodnie ze wzorcem znaczników wdrażania, z każdym znacznikiem obsługującym zestaw klientów. Gdy sygnatura zbliża się do maksymalnej pojemności, możesz aprowizować nową sygnaturę i rozpocząć wdrażanie nowych klientów. Korzystając z znaczków, możesz wspierać dalszy rozwój klientów i rozwijać swoją obecność regionalną w nowych regionach.

Korzystając z sygnatur wdrażania, zyskujesz również korzyści związane z niezawodnością. Nasze aktualizacje można wdrażać stopniowo, a bezpieczne procesy wdrażania ułatwiają stopniowe wprowadzanie zmian w globalnej floty. Każda pieczęć jest niezależna od innych, więc jeśli wystąpi problem z pieczęcią, wpłynie to tylko na podzbiór klientów przydzielonych do tej pieczęci. Sygnatury pomagają zmniejszyć promień wybuchu problemu lub błędu i przyczynić się do ogólnej strategii odzyskiwania po awarii.

Podobnie jak w przypadku każdej decyzji dotyczącej architektury, należy używać stempli wdrożeniowych w zależności od potrzeb biznesowych. Wdrożenie sygnatury wymaga wdrożenia zestawu infrastruktury do jej obsługi. Jeśli minimalny rozmiar sygnatury jest zbyt duży, trudno jest uzasadnić wdrożenie nowej sygnatury na nowym rynku, ponieważ musisz najpierw osiągnąć krytyczną masę klientów. Ważne jest również, aby zrozumieć, w jaki sposób wzrost klientów wpływa na ich wykorzystanie produktu, ponieważ wraz z ich rozwojem korzystają z większej ilości zasobów produktu. Te zagadnienia są równie ważne dla małego niezależnego dostawcy oprogramowania, jak dla platformy hiperskalowej, takiej jak Dynamics 365.

Warstwy zarządzania i konfiguracja

Gdy niezależny dostawca oprogramowania przechodzi do modelu dostarczania usług SaaS w chmurze, jedną z najbardziej znaczących zmian jest przejęcie odpowiedzialności za działanie usługi. W większości lokalnych oprogramowania działy IT klientów są odpowiedzialne za wdrażanie, konfigurowanie i zarządzanie systemami. Klienci sami zajmują się systemami monitorowania i podejmują decyzje dotyczące tego, kiedy wdrażać aktualizacje. Są one również odpowiedzialne za wykonywanie wszystkich kroków. Często wyspecjalizowani partnerzy integracji usług pomagają klientom obsługiwać złożone produkty w ich środowisku. Dostawca oprogramowania staje się odpowiedzialny za wszystkie te działania we wszystkich swoich klientach , przechodząc do modelu chmury i SaaS. W przypadku przejścia do modelu SaaS, należy utworzyć usługę ISV oraz płaszczyznę sterowania w celu zautomatyzowania procesu onboardingu i zarządzania tenantami. Sterowanie i automatyzacja są ważne, nawet w przypadku stosunkowo małej liczby klientów.

Dobrym rozwiązaniem jest zaprojektowanie płaszczyzny sterowania, która jest odporna, niezawodna i wysoce dostępna. Zbyt często warstwy kontrolne są traktowane jako sprawy drugorzędne w procesie tworzenia produktu SaaS. Ale jeśli płaszczyzna sterowania nie jest zaprojektowana z taką samą starannością jak reszta produktu, istnieje ryzyko, że jest to pojedynczy punkt awarii. Bez odpowiedniej uwagi na odporność płaszczyzny sterowania awaria płaszczyzny sterowania może mieć wpływ na wszystkich klientów.

W Dynamics 365 mamy płaszczyznę kontroli usług, która obsługuje operacje, takie jak dołączanie nowych klientów. Mamy również płaszczyznę sterowania na poziomie dzierżawy, która umożliwia zespołowi administracyjnemu klienta inicjowanie działań konserwacyjnych i zmianę konfiguracji, ponieważ mogą wykonywać te operacje za pośrednictwem usługi.

Dostosowywanie i rozszerzalność

Podstawową wartością modelu SaaS jest to, że wszyscy klienci uruchamiają jedną wersję kodu usługi. Gdy klienci uruchamiają jedną wersję kodu usługi, problemy są identyfikowane i rozwiązywane raz, a wszyscy klienci szybko korzystają z tych rozwiązań. Celem jest ciągłe rozwijanie jednej wersji usługi bez konieczności planowania testowania i wdrażania aktualizacji przez klientów.

Aby osiągnąć tę korzyść, istnieje wiele zmian wymaganych w porównaniu z uruchomionym oprogramowaniem w środowisku lokalnym. Na przykład należy zaplanować procesy i procedury, aby zmniejszyć prawdopodobieństwo regresji.

W transformacji usługi Dynamics 365 jednym z obszarów, w które zainwestowaliśmy, był rozwój rozbudowanej rozszerzalności opartej na modelu. Aplikacje ERP wymagają rozszerzalności, aby obsługiwać integrację z innymi krytycznymi systemami biznesowymi i zaspokoić unikatowe potrzeby funkcjonalne określonych klientów. Zamiast dostosowywania na poziomie kodu źródłowego, który był typowy dla aplikacji lokalnych, wprowadziliśmy możliwości rozszerzania modeli danych za pomocą metadanych specyficznych dla dzierżawy i wyzwalania rozszerzonej logiki na podstawie zdarzeń występujących w systemie.

Dodaliśmy funkcje izolacji i ładu, aby chronić usługę i inne dzierżawy przed problemami w rozszerzonej logice innej dzierżawy. Nasze podejście dało klientom wymagany poziom rozszerzalności, ale umożliwiło im uruchamianie wszystkich z tą samą wersją produktu. Ponadto aktualizacje mogą być dostarczane do produktu bez konieczności scalania naszych zmian i ponownego kompilowania kodu w celu zapewnienia współpracy rozszerzeń z nowszymi wersjami produktu.

Dostosowanie może nie być wymagane dla każdego produktu, ale jeśli produkt będzie go wymagał, dostosowanie stanie się krytycznym czynnikiem projektowym. Musisz spełnić wymagania bez naruszania podstawowych korzyści modelu SaaS. To wymaganie było istotnym celem usługi Dynamics 365. Rozszerzalność oparta na modelu zachowała zarówno propozycję wartości SaaS, jak i poprawiła zdolność klientów do tworzenia i utrzymywania rozszerzeń.

Jak zaprojektowaliśmy usługę Dynamics 365 pod kątem odporności

Jeśli rozważasz model wdrażania na platformie Azure, kluczowym składnikiem, który należy wziąć pod uwagę, jest odporność, jeśli występują problemy z usługą zależną — na przykład problem z siecią, problem z zasilaniem lub konserwacja maszyny wirtualnej. W środowisku lokalnym, w którym infrastruktura obsługuje jedną dzierżawę klienta, wielu klientów korzysta ze strategii wysokiej dostępności dla każdego składnika infrastruktury. Jednak kiedy uwzględniasz odporność w skali chmury, wysoka dostępność jest często konieczna, ale niewystarczająca. Przy wystarczającej skali występują błędy.

Głównym obszarem koncentracji dla Dynamics 365 jest obecnie eliminacja nadmiarowości w strefach dostępności platformy Azure, aby umożliwić płynne działanie usług Dynamics o krytycznym znaczeniu, nawet jeśli awaria wpływa na centrum danych lub całą strefę dostępności.

Aby zastosować ten sposób myślenia do własnego rozwiązania, należy postępować zgodnie z pewnymi ważnymi praktykami.

• Upewnij się, że inwestujesz w narzędzia do monitorowania, aby szybko identyfikować problemy. Dzięki rozwiązaniu SaaS klienci oczekują, że będziesz wiedzieć o awariach i szybko zaangażować się w przywracanie usługi.
• Użyj możliwości platformy, takich jak strefy dostępności i nadmiarowość stref, jeśli są one odpowiednie dla Twojej usługi.
• Projektowanie aplikacji pod kątem odporności w każdej warstwie. Na przykład ważne jest również, aby rozważyć inne najlepsze rozwiązania w chmurze, takie jak używanie ponownych prób, wyłączników i grodzi oraz wdrażanie praktyk związanych z komunikacją asynchroniczną. Te rozwiązania mogą zachować kondycję usługi nawet wtedy, gdy inne usługi, od których zależysz, są obciążone.
• Należy wziąć pod uwagę dostępność płaszczyzny sterowania, szczególnie dlatego, że ma ona rolę w odzyskiwaniu rozwiązania, gdy mają one wpływ na zasoby infrastruktury.
• Po zaimplementowaniu możliwości odporności uruchom testy. Nigdy nie wiesz, czy plany i funkcje zostaną ukończone, dopóki nie spróbujesz ich użyć. Przydatne może być ćwiczenie procesów trybu failover w ramach normalnych działań konserwacyjnych, co może zapewnić zarówno podejście do konserwacji bez przestojów, jak i weryfikację mechanizmów trybu failover.

Filar niezawodności platformy Azure Well-Architected Framework zawiera doskonałe wskazówki dotyczące tych tematów.

Jak dostosowaliśmy się do środowiska chmury

Usługa Dynamics 365 przekształciła się w zaawansowaną architekturę natywną dla chmury, ale dostawcy oprogramowania często tworzą bardziej ograniczone przejścia metodą "lift-and-shift " ze środowisk lokalnych do chmury. Omówiliśmy model definiowania MVP , który umożliwia szybkie przejście usługi SaaS do rąk klientów, co rozpoczyna cykl uczenia się i ciągłego ulepszania. Ale jest równowaga. Lift and shift powinien być naprawdę lift, shift i dostosować.

Wcześniej w tym artykule omówiliśmy projektowanie pod kątem odporności ze strefami dostępności i innymi najlepszymi rozwiązaniami w chmurze. Istnieją inne obszary, w których typowe wzorce projektowe lokalne również prowadzą do wyzwań lub wyższych kosztów w chmurze. Na przykład w aplikacjach lokalnych często przechowuje się duże obiekty binarne w relacyjnej bazie danych. Możesz na przykład przechowywać dokument PDF związany z zamówieniem sprzedaży w ramach zamówienia sprzedaży w bazie danych SQL. W środowisku lokalnym takie podejście upraszcza spójność między kopiami zapasowymi i funkcjami przywracania do punktu w czasie. Jednak w chmurze duże obiekty przechowywane w bazie danych mogą być kosztowne. Ponadto obiekty blob usługi Azure Storage upraszczają przechowywanie dużych obiektów binarnych z prostą logiką wymaganą do zachowania spójnych kopii zapasowych.

Ważne jest, aby zastanowić się nad tym, co należy zrobić w ramach transformacji chmury. Należy wykonać te czynności, które tworzą silniejszą usługę chmurową. Ale należy również wykorzystać to jako okazję do szybkiego wejścia na rynek i rozpoczęcia pozytywnego cyklu uczenia się oraz ciągłego ulepszania.

Chmura może również sprawić, że całkowicie nowe rozwiązania będą praktyczne, które nie były opcją w środowisku lokalnym. Jednym z najbardziej wymagających wydajności procesów w systemie ERP jest planowanie zasobów produkcyjnych lub MRP II. MRP II analizuje zapasy pod ręką, oczekiwane zamówienia przychodzące i wychodzące oraz wymagania produkcyjne. Następnie określa, co firma musi kupić lub dokonać w celu spełnienia oczekiwanych zamówień. W lokalnej wersji Dynamics ta funkcja została zaimplementowana w kodzie aplikacji, który działał bezpośrednio w magazynie relacyjnym. Funkcja planowania zużywała dużo pojemności systemu i działała przez dłuższy czas. W pierwszych wersjach chmury funkcje lokalne zostały przeniesione bez zmian — działały, ale z tymi samymi wyzwaniami dotyczącymi skalowania i wydajności. Następnie kilka lat temu wprowadziliśmy nową mikrousługę w pamięci, która może ukończyć ten sam przebieg planowania w ułamku czasu i bez wpływu na wydajność. Co ważne, ponieważ mikrousługa jest krytycznym rdzeniem systemu produkcyjnego, wprowadziliśmy ją jako opcję, na którą klienci mogą się zdecydować po sprawdzeniu w swoich środowiskach testowych, że przynosi właściwe wyniki. W miarę jak coraz więcej klientów zaczęło korzystać z nowej mikrousługi, podjęliśmy działania, aby każdy klient przeszedł na nową mikrousługę, co pozwoli nam zrezygnować z dotychczasowych funkcji. Z MRP II staje się czymś, co może być uruchamiane w ciągu kilku minut w dowolnym momencie, organizacje mogą być nimbler. Chmura sprawiła, że tworzenie i łączenie mikrousługi w pamięci było praktyczne, a dobre zasady inżynierii SaaS pozwoliły nawet tej najbardziej krytycznej części usługi rozwijać się bez zakłócania działania klientów.

Jak zmigrowaliśmy istniejących klientów do chmury

Migracja istniejącej bazy klientów może być najszybszym sposobem na zwiększenie skali usługi w chmurze. Jednak kiedy wprowadziliśmy usługę Dynamics 365 do chmury, początkowo skupiliśmy się na nowych klientach. Istnieją dwa kluczowe powody:

• Takie podejście dało nam możliwość oceny, czy dostarczaliśmy rozwiązanie SaaS, które zdobyło własne zalety, a nie tylko takie, które odwoływały się do klientów lokalnych poszukujących prostej migracji do chmury.
• Możemy skupić się na MVP i odroczyć zadania, takie jak tworzenie narzędzi do migrowania istniejących klientów.

Po tym, jak widzieliśmy trakcję z nowymi klientami, mogliśmy skupić się na migracji istniejących klientów lokalnych.

Odkryliśmy, że klienci często boją się kosztów i złożoności przenoszenia. Ważne było, abyśmy dostarczali narzędzia, które zmniejszają koszty i usuwają nieznane czynniki. Opracowaliśmy narzędzia ułatwiające analizowanie nakładu pracy związanego z migracją danych do nowych schematów, które ewoluowały w naszym produkcie w chmurze, oraz zrozumienie wpływu migracji na rozszerzenia i integracje klienta. Odkryliśmy również, że pomocne jest utworzenie innych narzędzi i programów, które wyniosą granice w czasie i kosztach migracji.

Przejście do samej chmury przynosi korzyści klientom, usuwając większość obciążeń związanych z zarządzaniem systemami, z którymi borykają się z produktami lokalnymi, ale podkreślanie korzyści związanych z wersją w chmurze jest również ważnym motywatorem.

Jak nauczyliśmy się obsługiwać usługę Dynamics 365 jako SaaS

Po zdefiniowaniu MVP i zakończeniu procesu inżynieryjnego w celu przenoszenia i dostosowywania, powinieneś skupić się na obsłudze usługi SaaS dla swoich klientów. Ta transformacja jest ogromna. W środowisku lokalnym dostawcy oprogramowania tworzą i wysyłają oprogramowanie, integratorzy systemów wdrażają je, a organizacja IT klienta lub dostawca zlecił jego uruchomienie. W modelu SaaS dostawca SaaS jest zasadniczo odpowiedzialny za obsługę usługi, ale jest również odpowiedzialny za obsługę jej przez setki tysięcy klientów w tym samym czasie.

Dowiedzieliśmy się wiele dzięki obsłudze usługi Dynamics 365 w chmurze dla dużej i rosnącej liczby klientów.

Monitorowanie: jako dostawca usług, klienci oczekują, że wykryjesz problemy z kondycją usługi zanim sami je zauważą, i oczekują natychmiastowego podjęcia działań w celu ich rozwiązania. Problem z kondycją nie jest tylko wtedy, gdy usługa nie działa. Postrzeganie usługi jako niesprawnej przez klienta obejmuje sytuacje, w których usługa działa wolno lub nieprawidłowo. Niezbędne jest, aby rozwijać odpowiednie narzędzia do monitorowania — ten rozwój jest częścią twojej usługi, a nie opcjonalnym dodatkiem.

Komunikacja: w środowisku lokalnym klient może zobaczyć, jak zespół IT pracuje nad problemem. W chmurze nie mogą. Ważne jest, aby komunikować się podczas wykrywania problemu z kondycją usługi, informować o postępach w rozwiązywaniu problemu i potwierdzić problem został rozwiązany , gdy problem zostanie rozwiązany. Charakter komunikacji różni się w zależności od ważności problemu. Potok komunikacji jest również główną częścią usługi SaaS i musisz upewnić się, że komunikacja może zakończyć się powodzeniem nawet wtedy, gdy naruszono bezpieczeństwo podstawowych części infrastruktury usługi SaaS.

Widok całego stosu: w środowisku lokalnym dostawca aplikacji jest ogólnie odpowiedzialny za składnik aplikacji, a klient jest właścicielem podstawowej infrastruktury. W chmurze odpowiadasz za cały stos. Jeśli usługa ma problem zdrowotny, klient oczekuje od ciebie wykrycia, zgłoszenia i naprawy, niezależnie od tego, czy problem znajduje się w aplikacji, czy na platformie chmurowej, na której działa.

Automatyzuj: jeśli ludzie muszą ręcznie wykonywać kroki w ramach działania usługi, błędy będą nieuchronnie popełniane. Każda możliwa akcja powinna być zautomatyzowana i zarejestrowana. Jeśli wymagana jest akcja na wystarczającej liczbie węzłów usługi, automatyzacja jest jedyną opcją. Doskonałym przykładem jest administrowanie bazą danych dla usługi Dynamics 365. Dzięki naszej decyzji o zachowaniu danych każdej dzierżawy w oddzielnej bazie danych Azure SQL Database musieliśmy opracować automatyzację w celu obsługi wszystkich zadań wykonywanych zwykle przez administratorów baz danych, na przykład konserwację indeksów i optymalizację zapytań. Aby uzyskać więcej informacji na temat zarządzania bazami danych na dużą skalę, zobacz Running 1M databases on Azure SQL for a large SaaS provider (Uruchamianie baz danych 1M w usłudze Azure SQL dla dużego dostawcy SaaS).

Bezpieczne wdrażanie: wszędzie tam, gdzie to możliwe, zmiany powinny być zgodne z bezpiecznym procesem wdrażania. Po pierwsze, zmiany są wprowadzane do środowisk o niskim ryzyku — na przykład do regionu chmury obliczeniowej z mniejszymi klientami lub mniej krytycznymi obciążeniami. Następnie przechodzą do grupy nieco większych, bardziej złożonych klientów itd., dopóki wszyscy klienci nie zostaną zaktualizowani. Na każdym etapie należy monitorować, czy zmiana zakończyła się pomyślnie. Jeśli wystąpi problem, proces powinien zatrzymać wprowadzanie zmian i minimalizować problemy lub wycofać je tam, gdzie zostały już wdrożone. Bezpieczne praktyki wdrażania mają zastosowanie zarówno do zmian kodu, jak i konfiguracji. Aby uzyskać więcej informacji, zobacz Zaawansowane rozwiązania dotyczące bezpiecznego wdrażania.

Zarządzanie incydentami na żywo: dla nas incydent na żywo oznacza, że klient ma problem z naszą usługą w środowisku produkcyjnym, który wymaga interwencji zespołu inżynieryjnego. Może to być problem zdrowotny, który wykrywamy, lub problem zgłaszany przez klienta, którego nasze zespoły pomocy technicznej nie mogą rozwiązać samodzielnie. Doskonałość działania na żywo ma kluczowe znaczenie dla sukcesu SaaS. Oto kilka kluczowych kwestii z naszego doświadczenia:

• Zespół inżynierów powinien obsługiwać zdarzenia na żywo. W przeszłości wiele firm miało oddzielne zespoły operacyjne lub zespoły inżynierów pomocy technicznej. Dokonaliśmy wyraźnego wyboru, aby nasze podstawowe zespoły inżynieryjne obejmowały zdarzenia na żywo. Mają najlepszą wiedzę, a doświadczając problemów bezpośrednio, inspirują właściwą kreatywność i energię, aby stymulować rzeczywiste, szybkie ulepszenia i lepsze projekty w przyszłości. Jest to coś, co należy wziąć pod uwagę podczas planowania harmonogramów programowania, ale zapewnia doskonałe wyniki.
• Przywództwo incydentów na żywo jest umiejętnością i jest to ciężka praca — rozpoznawanie go, trenowanie dla niego, naucz się go zatrudnić i nagradzać.
• Priorytetem powinno być wykrywanie, izolacja i środki zaradcze. Przywróć zdrowie klientowi, a potem martw się o długoterminowe ulepszenia.

Naucz się i ulepszaj: Ktoś kiedyś powiedział: "Nigdy nie marnuj dobrego kryzysu". Każde zdarzenie na żywo jest okazją do poprawy. Po zakończeniu ograniczania ryzyka upewnij się, że zapytasz, jak szybciej wykrywać podobne problemy, jak rozwiązać podstawowy problem, aby go w pełni wyleczyć, jak zminimalizować wpływ podobnych problemów, czy inne podobne problemy mogą istnieć w innej części usługi oraz jak zapobiec całej klasie problemów. Ustalanie priorytetów tych akcji naprawczych zwiększa jakość usług i zmniejsza zapotrzebowanie na przyszłe zdarzenia na żywo. Jakość usług musi się poprawiać z czasem, w przeciwnym razie, gdy się rozwijasz, wpływ każdego problemu także będzie się zwiększał.

Przesunięcie w lewo: Problemy, które wymagają zaangażowania zespołu odpowiedzialnego za działanie witryny, są kosztowne. Zajmuje trochę czasu, zanim problemy dotrą do nich, a zespół ds. wsparcia na miejscu to ograniczony zasób, który musi być dostępny w przypadku najpoważniejszych problemów dotyczących kondycji usług i zadań zarządczych.

Jeśli to możliwe, najlepszym rozwiązaniem jest całkowite wyeliminowanie problemu, a następnie szybkie wykrywanie automatyczne i zautomatyzowane środki zaradcze. Gdy nie jest to możliwe, przesunięcie w lewo pomaga umożliwić zespołowi pomocy technicznej linii frontu wykrywanie i naprawianie problemu lub wykonywanie zadania, a nawet lepsze, umożliwienie klientowi samodzielnej obsługi i samodzielne wykonywanie zadania. Na poniższym diagramie pokazano, jak sprawy pomocy technicznej zaczynają się od klienta, przechodzą do zespołu pomocy technicznej linii frontu, a następnie do zespołu inżynierów. Strzałka wskazuje, że przesuwamy akcję rozwiązywania po lewej stronie, aby zmniejszyć wpływ zdarzeń.

Zachowaj normy: Może to być kuszące, aby rozwiązać problem, wprowadzając specjalne ustalenia dla jednego klienta. Na dużą skalę wszystko, co specjalne, staje się narożnym przypadkiem, który powoduje niepowodzenie czegoś innego. Staraj się zachować wszystkie dzierżawy przy użyciu standardowego kodu, ustawień i konfiguracji.

Ciągłe innowacje

W tym artykule omówiliśmy potrzebę uzyskania produktu do chmury i rozpoczęcia cnotliwego cyklu ciągłego uczenia się i ciągłego ulepszania. Ciągłe innowacje to oczekiwanie dla większości produktów SaaS. Ale gdy produkt SaaS jest następcą długotrwałego produktu lokalnego, prawdopodobnie wymaga to znaczącego zarządzania zmianami, aby przygotować klientów do ciągłej innowacji.

Poniżej przedstawiono trzy kluczowe obszary fokusu z naszej transformacji usługi Dynamics 365:

Konserwacja z niemal zerowymi przestojami: w miarę wzrostu liczby klientów w różnych firmach i lokalizacjach nie można znaleźć powszechnie akceptowalnych okien konserwacji. Musisz zbudować dojrzałość inżynieryjną, aby działania konserwacyjne mogły wystąpić, gdy system jest w trybie online. W szczególności wdrożenie aktualizacji usługi musi odbywać się z przestojem, który jest jak najbardziej zbliżony do zera.

Eliminowanie regresji: zaufanie klientów zależy od usługi o znaczeniu krytycznym z ciągłymi zasadami innowacji. To zaufanie jest zdobywane stopniowo, z każdego dnia udanej działalności i każdej bezproblemowej aktualizacji serwisu. Niestety, jest tracona w dużych ilościach — szybko — bez względu na to, jak niewielka jest regresja. Warto wykonać wszystko, co można zrobić, co eliminuje regresje w procesie inżynieryjnym, zwłaszcza przy użyciu bezpiecznych procesów wdrażania.

Flagi funkcji: zespół usługi Dynamics 365 zainwestował szeroko w platformę flag funkcji . Przełącznik funkcji można włączyć lub wyłączyć dla całej usługi, dla podzbiorów dzierżawców, a nawet dla pojedynczego dzierżawcy. Korzystając z flag funkcji, umożliwiamy wprowadzenie nowych funkcji bez zakłócania działania procesów biznesowych o krytycznym znaczeniu dla misji, które obsługuje usługa Dynamics 365.

Oto jak flagi funkcji mogą pomóc:

• Prostą poprawkę wydajności lub zabezpieczeń można wprowadzić z flagą włączoną domyślnie. Każdy powinien natychmiast uzyskać korzyści ze zmiany.
• Coś, co zmienia środowisko użytkownika, proces biznesowy lub zachowanie widocznego zewnętrznie interfejsu API, jest wprowadzane z flagą wyłączoną domyślnie.
• Zmiana flagi funkcji skutecznie zmienia kod, który jest uruchamiany, więc zmiany flag funkcji powinny być również zarządzane za pośrednictwem bezpiecznego wdrożenia. Załóżmy na przykład, że wprowadzisz poprawkę problemu i domyślnie włączysz flagę funkcji poprawki. Możesz włączyć flagę dla klientów, którzy zgłosili oryginalną usterkę. Następnie możesz stopniowo włączać znacznik dla coraz szerszych grup klientów, aż zostanie on włączony dla wszystkich.
• Jeśli poprawka zostanie wprowadzona, gdy flaga jest domyślnie włączona, a poprawka ma problem, można ją logicznie wycofać, przełączając flagę wyłączoną.
• Flagi funkcji mogą również służyć do selektywnego ujawniania funkcji w wersji zapoznawczej lub selektywnego ukrywania funkcji od nowych klientów w ramach procesu wycofywania.
• Możesz zapewnić widoczność nowych flag funkcji i ustawień flag funkcji specyficznych dla dzierżawy do obsługi linii frontu i zespołów witryn na żywo. Te informacje pomagają zespołom szybko rozstrzygać lub wykluczać zmiany funkcji, gdy badają problem. W razie potrzeby zespoły mogą również dostosować ustawienia flag funkcji, aby rozwiązać ten problem.
• Na koniec musisz zarządzać cyklem życia flag funkcji, aby zapobiec nieobsługiwaniu bazy kodu. Ustanów proces usuwania flag funkcji z kodu po ich pełnym wdrożeniu i udowodnieniu.

Podsumowanie

Przejście z produktu lokalnego do modelu SaaS wymaga znaczących zmian w każdej części sposobu dostarczania oprogramowania klientom i w każdej części firmy. Zmiany kulturowe są tak istotne, jak zmiany techniczne: przejście z okazjonalnego lokalnego tempa wydawania do regularnego tempa wydania jest ważną zmianą, a przyjęcie kultury i procesów na żywo wymaga wysiłku. Musisz upewnić się, że twój zespół jest dobrze przygotowany do podróży i że rozwijasz pulę talentów poza inżynierami, aby mieć pewność, że masz ludzi, którzy wiedzą, jak obsługiwać rozwiązania SaaS na dużą skalę.

Wiele organizacji nie przetrwa tak dużej zmiany, zwłaszcza jeśli pojawi się konkurent, który już działa natywnie w chmurze. Aby skonfigurować się na sukces, należy dokładnie określić zakres MVP, jak najszybciej przejść do środowiska produkcyjnego, a następnie iterować i ulepszać go szybko. Proces przejścia jest często najtrudniejszym czasem, dlatego warto jak najszybciej przenieść się do chmury.

Poniżej przedstawiono kluczowe zagadnienia, które mamy nadzieję, że odejdziesz od naszych doświadczeń i niektóre decyzje, które musisz podjąć na własną podróż.

• Zdecyduj się na własną ścieżkę. Jeśli masz istniejącą aplikację z rozbudowanymi funkcjami i ustanowioną lokalną bazą klienta, warto przejść do modelu SaaS opartego na chmurze. Każda podróż produktu jest inna i musisz wziąć pod uwagę decyzje i pytania oddzielnie, na podstawie własnych potrzeb. Weź inspirację z innych podróży, ale wykuć własną ścieżkę.
• Określanie strategii. Posiadanie produktu z ustalonymi klientami oznacza, że musisz zdecydować, jak tworzyć priorytety. Możesz skupić się na tworzeniu produktu, który działa dobrze dla nowych klientów natychmiast. Możesz skupić się na jak najszybszym przeprowadzeniu migracji istniejącej bazy klientów do nowej usługi. Powód, dla którego przenosisz się, oraz zdolność do wprowadzania znaczących zmian, ma wpływ na kierunek, który podejmujesz.
• Zdecyduj, czy zamierzasz używać jednej chmury, czy wielu chmur. Zastanów się, czy warto korzystać z jednej chmury, czy też rozpowszechniać wysiłki inżynieryjne w wielu chmurach. Jeśli tworzysz składnik platformy, strategia wielochmurowa może mieć sens. Jeśli tworzysz aplikację, strategia z jedną chmurą może zapewnić korzyści wynikające z używania spójnej i zintegrowanej platformy.
• Zaplanuj specjalnie dla chmury. Podejście metodą "lift-and-shift" do migracji do chmury nie jest wystarczające. Musisz zaplanować sposób korzystania z elastyczności chmury oraz sposobu obsługi usługi w środowisku chmury. Automatyzacja, odporność, skalowanie, zabezpieczenia, wydajność i możliwość obserwacji są ważnymi zagadnieniami. Nie musisz robić wszystkiego z góry, ale musisz znać miejsce docelowe, aby można było zaplanować plan działania.
• Zaplanuj specjalnie dla SaaS. Model biznesowy SaaS wygląda inaczej w porównaniu z lokalnym podejściem do dostarczania oprogramowania. Klienci oczekują kont próbnych, zrozumiałych modeli rozliczeń, w pełni zarządzanej usługi i dynamicznej skali na podstawie ich potrzeb.
• Ląduj, ucz się i iteruj. Zaplanuj zakres MVP, zidentyfikuj podstawowe osiągnięcia, które można osiągnąć, a następnie szybko to osiągnij. Gdy już tam jesteś, zatwierdź ciągłe ulepszanie.
• Gdy jesteś w chmurze, skorzystaj z niej. Chmura zapewnia wiele możliwości, których nie mają rozwiązania lokalne. Możliwości obejmują ogromną skalę, elastyczność i możliwość używania składników platformy w chmurze do szybkiego tworzenia i iterowania pomysłów. Zastanów się, jak można używać technologii, takich jak generowanie sztucznej inteligencji, mikrousługi i inne podejścia, które są trudne do użycia poza środowiskiem chmury.
• Zostań działem IT klienta. Oczekiwania klientów zmieniają się, gdy udostępniasz kompleksową usługę. Zaplanuj, jak można przesunąć w lewo. Upewnij się, że masz kompleksową możliwość monitorowania i samonaprawiania.
• Dowiedz się na podstawie użycia przez klienta. Po uruchomieniu usługi zbierasz dużą ilość przydatnych danych dotyczących sposobu korzystania z produktu przez klientów. Wdrażanie kultury danych. Dowiedz się więcej o swoich klientach, o tym, co robią i jak to robią. Eksperymentuj i bądź wystarczająco zwinny, aby zmienić podejście, gdy dane wskazują, że coś nie jest zgodnie z oczekiwaniami.
• Zapewniaj ciągłą wartość poprzez aktualizacje. Zastanów się, kiedy i jak wdrażać aktualizacje. Zaplanuj szybkie rozwiązywanie problemów lub powrót do poprzednich wersji. Zdecyduj, jak poradzić sobie ze zmianami disruptującymi. Unikaj jednorazowych zmian dla konkretnych klientów, ponieważ każdy punkt różnicy jest okazją, aby coś poszło nie tak.

Największą nauczoną lekcją jest to, że podróż do SaaS nigdy się nie kończy. Plan produktu to żywy dokument, który stale się rozwija. Zawsze masz wiele elementów na liście prac, aby ulepszyć produkt, zarówno w celu dodawania nowych funkcji, jak i ulepszania sposobu działania i dostarczania produktu. Dostarczanie modelu SaaS wymaga ciągłego ulepszania procesów, inwestycji w jakość i czujność, aby zapewnić niezawodną, bezpieczną, wydajną i godną zaufania usługę dla klientów. Postępy w technologiach, takich jak generowanie sztucznej inteligencji, dają ogromną szansę na zapewnienie możliwości, które wcześniej były niewyobrażalne.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

• Michał Ehrenberg | Dyrektor techniczny, Microsoft Dynamics
• John Downs | Główny inżynier oprogramowania
• Arsen Władimirsky | Główny inżynier klienta