Udostępnij za pośrednictwem


Równoważenie portfela

Wdrażanie chmury to nakład pracy w zakresie zarządzania portfolio, sprytnie przebrany za implementację techniczną. Podobnie jak w przypadku każdego ćwiczenia zarządzania portfelem równoważenie portfela ma kluczowe znaczenie. Na poziomie strategicznym oznacza to zrównoważenie migracji, innowacji i eksperymentów w celu maksymalnego wykorzystania chmury. Gdy nakład pracy nad wdrożeniem chmury pochyli się zbyt daleko w jednym kierunku, złożoność znajduje swoją drogę do wysiłków związanych z wdrażaniem. W tym artykule przedstawimy Czytelnikowi podejścia do osiągnięcia równowagi portfela.

Ogólne rozszerzenie zakresu

Równoważenie portfela ma charakter strategiczny. W związku z tym zaprezentowane w nim podejście jest równie strategiczne. Aby uziemić strategię w decyzjach opartych na danych, w tym artykule przyjęto założenie, że czytelnik oceni istniejący majątek cyfrowy lub rozpoczął ten proces. Celem tego podejścia jest pomoc w ocenie obciążeń, aby zapewnić odpowiednią równowagę portfela przez pytania jakościowe i udoskonalanie portfela.

Dokumentacja wyników biznesowych

Przed zrównoważeniem portfela ważne jest, aby udokumentować i udostępnić wyniki biznesowe, które napędzają nakład pracy nad migracją do chmury. Poniższa tabela ułatwia dokumentowanie i udostępnianie żądanych wyników biznesowych. Należy pamiętać, że większość firm dąży do osiągnięcia wielu wyników jednocześnie. Celem tego ćwiczenia jest wyjaśnienie rezultatów, które są najbardziej bezpośrednio związane z nakładem pracy w zakresie migracji do chmury:

Wynik Mierzony przez Cel Horyzont czasowy Priorytet tego nakładu pracy
Obniżanie kosztów IT Budżet centrum danych Zmniejsz o 2 mln USD 12 miesięcy 1.
Wyjście centrum danych Wyjście z centrów danych 2 centra danych 6 miesięcy 2.
Zwiększenie sprawności biznesowej Szybsze wejście na rynek Skrócenie czasu wdrożenia o sześć miesięcy 2 lata 3.
Ulepszanie środowiska klienta Zadowolenie klientów (CSAT) Poprawa o 10% 12 miesięcy 4.

Ważne

Powyższa tabela jest przykładem fikcyjnym i nie powinna być używana do określania priorytetów. W wielu przypadkach ta tabela może być uważana za antywzorcę, umieszczając oszczędności kosztów powyżej środowisk klientów.

Poniższa tabela może dokładnie reprezentować priorytety zespołu strategicznego ds. chmury i zespołu wdrożeniowego ds. chmury. Ze względu na znaczne ograniczenia czasowe ten zespół kładzie większy nacisk na redukcję kosztów IT i traktuje priorytetowo wyjście z centrum danych jako środek do osiągnięcia żądanego obniżenia kosztów IT. Jednak dzięki udokumentowaniu konkurencyjnych priorytetów w tej tabeli zespół wdrożeniowy ds. chmury może ułatwiać zespołowi strategicznemu ds. chmury identyfikowanie możliwości lepszego dopasowania implementacji nadrzędnej strategii portfela.

Szybkość zmian przy zachowaniu równowagi

Wskazówki dotyczące przyrostowej racjonalizacji majątku cyfrowego sugerują podejście, w którym racjonalizacja rozpoczyna się od pozycji niezrównoważonej. Zespół strategiczny ds. chmury powinien oszacować każde obciążenie pod kątem zgodności z podejściem do ponownego hostowania. Takie podejście jest sugerowane, ponieważ pozwala na szybką ocenę złożonego majątku cyfrowego na podstawie danych ilościowych. Takie wstępne założenie umożliwia zespołowi wdrożeniowemu ds. chmury szybkie zaangażowanie i skrócenie czasu oczekiwania na wyniki biznesowe. Jednak, zgodnie z opisem w tym artykule, to pytania jakościowe będą zapewniały niezbędną równowagę portfela. W tym artykule opisano proces tworzenia uzgodnionego salda.

Znaczenie decyzji o wycofaniu

W tabeli z powyższej sekcji Dokumentowanie wyników biznesowych pominięto kluczowy wynik, który mógłby ułatwić osiągnięcie pierwszorzędnego celu redukcji kosztów IT. W przypadku klasyfikacji obniżenia kosztów w dowolnym miejscu listy wyników biznesowych ważne jest, aby wziąć pod uwagę potencjalną liczbę wycofywanych obciążeń. W niektórych scenariuszach oszczędności kosztów mogą wynikać z braku migrowania obciążeń, które nie uzasadniają krótkoterminowych inwestycji. Niektórzy klienci zgłosili oszczędności kosztów przekraczające 20% łącznego obniżenia kosztów przez wycofanie niewykorzystywanych obciążeń.

Aby zrównoważyć portfolio, lepiej odzwierciedlać decyzje dotyczące zachodu słońca i wycofywania, zespół strategiczny ds. chmury i zespół wdrożeniowy ds. chmury są zachęcani do zadawania następujących pytań dotyczących poszczególnych obciążeń podczas fazy oceny i migracji:

  • Czy obciążenie było używane przez użytkowników końcowych w ciągu ostatnich sześciu miesięcy?
  • Czy ruch użytkowników końcowych jest stały lub wzrastający?
  • Czy to obciążenie będzie potrzebne firmie w ciągu 12 miesięcy od teraz?

Jeśli odpowiedź na dowolne z tych pytań to "nie", obciążenie może być kandydatem na emeryturę. Jeśli potencjalna emerytura zostanie potwierdzona przez właściciela aplikacji, może nie mieć sensu migrowania obciążenia. To prowadzi do kilku pytań jakościowych:

  • Czy można ustanowić plan wycofania tego obciążenia?
  • Czy to obciążenie może zostać wycofane przed wyjściem z centrum danych?

Jeśli odpowiedź na oba te pytania brzmi "tak", warto rozważyć , aby nie migrować obciążenia. Takie podejście może pomóc osiągnąć cele zmniejszenia kosztów i wyjścia z centrum danych.

Jeśli odpowiedź na pytanie brzmi "nie", warto ustanowić plan hostowania obciążenia, dopóki nie będzie można go wycofać. Ten plan może obejmować przeniesienie zasobów do tańszego lub alternatywnego centrum danych, co również umożliwia osiągnięcie celów zmniejszenia kosztów i wyjścia z jednego centrum danych.

Wdrażanie zmian procesu

Równoważenie portfela wymaga dodatkowej analizy jakościowej w fazie wdrażania, co pomoże zwiększyć prostą racjonalizację portfela.

Na podstawie danych z tabeli w powyższej sekcji Dokumentowanie wyników biznesowych prawdopodobne jest ryzyko, że portfel dąży zbyt daleko do modelu wykonywania skoncentrowanego na migracji. Jeśli obsługa klienta miałaby najwyższy priorytet, bardziej prawdopodobny byłby portfel bardziej nastawiony na innowacje. Żadne z tych podejść nie jest prawidłowe lub złe, ale zbytnie dążenie w jednym kierunku zwykle skutkuje mniejszymi zyskami, niepotrzebnie zwiększa złożoność i wydłuża czas wykonywania nakładów pracy zakresie wdrażania w chmurze.

Aby zmniejszyć złożoność, należy postępować zgodnie z tradycyjnym podejściem do racjonalizacji portfela, ale w modelu iteracyjnym. Poniższe kroki przedstawiają model jakościowy takiego podejścia:

  • Zespół strategiczny ds. chmury utrzymuje priorytetową listę prac dotyczącą obciążeń, które mają zostać poddane migracji.
  • Zespół strategiczny ds. chmury i zespół wdrożeniowy ds. chmury prowadzą spotkanie dotyczące planowania wydania przed ukończeniem każdego wydania.
  • W trakcie spotkania dotyczącego planowania wydania zespoły uzgadniają od 5 do 10 najważniejszych obciążeń na priorytetyzowanej liście prac.
  • Poza spotkaniem planowania wydania zespół wdrożeniowy ds. chmury zadaje właścicielom aplikacji i ekspertom dziedzinowym następujące pytania:
    • Czy ta aplikacja może zostać zastąpiona odpowiednikiem platformy jako usługi (PaaS)?
    • Czy ta aplikacja jest aplikacją innej firmy?
    • Czy zatwierdzono budżet inwestycji w ciągłe tworzenie aplikacji w ciągu najbliższych 12 miesięcy?
    • Czy dodatkowy rozwój tej aplikacji poprawi środowisko klienta? Utworzy przewagę konkurencyjną? Wygeneruje dodatkowy przychód firmy?
    • Czy dane w tym obciążeniu przyczynią się do innowacji w zakresie analizy biznesowej, uczenia maszynowego, IoT lub powiązanych technologii?
    • Czy obciążenie jest zgodne z nowoczesnymi platformami aplikacji, takimi jak Azure App Service?
  • Odpowiedzi na powyższe pytania i wszelka inna wymagana analiza jakościowa wpływają następnie na korekty priorytetyzowanej listy prac. Te korekty mogą obejmować:
    • Jeśli obciążenie nadawałoby się do zastąpienia przy użyciu rozwiązania PaaS, mogłoby zostać całkowicie usunięte z listy prac migracji. Co najmniej dodatkowa staranność w celu podjęcia decyzji o ponownym hostowaniu i zastąpieniu zostanie dodana jako zadanie, tymczasowo zmniejszając priorytet tego obciążenia z listy prac migracji.
    • Jeśli obciążenie jest (lub powinno) przechodzić postęp programowania, może on najlepiej dopasować się do modelu refaktoryzacji ponownego kompilowania. Ponieważ innowacje i migracja wymagają różnych umiejętności technicznych, aplikacje zgodne z podejściem refaktoryzacji i przebudowy powinny być zarządzane za pomocą listy prac innowacji, a nie listy prac migracji.
    • Jeśli obciążenie jest częścią dalszej innowacji, wtedy może mieć sens refaktoryzacja platformy danych, ale z pozostawieniem warstw aplikacji jako kandydata do ponownego hostowania. Niewielka refaktoryzacja platformy danych obciążenia może często być wprowadzona do listy prac migracji lub innowacji. Ten wynik racjonalizacji może skutkować bardziej szczegółowymi elementami roboczymi na liście prac, ale w przeciwnym razie priorytety nie zostałyby zmienione.
    • Jeśli obciążenie nie jest strategiczne, ale jest zgodne z nowoczesnymi platformami hostingu aplikacji opartych na chmurze, warto wykonać drobne refaktoryzację aplikacji w celu wdrożenia jej jako nowoczesnej aplikacji. Może to przyczynić się do ogólnego oszczędności przez zredukowanie ogólnych wymagań licencyjnych IaaS i systemów operacyjnych migracji do chmury.
    • Jeśli obciążenie jest aplikacją innej firmy, a dane obciążenia nie są planowane do użycia w dalszych innowacjach, najlepszym rozwiązaniem może być pozostawienie opcji ponownego hostowania na liście prac.

Te pytania nie powinny być zakresem analizy jakościowej ukończonej dla każdego obciążenia, ale pomagają one kierować rozmową na temat złożoności niezrównoważonych portfeli.

Zmiany procesu migracji

Podczas migracji działania równoważenia portfela mogą mieć negatywny wpływ na szybkość migracji (szybkość migracji zasobów). Poniższe wskazówki posłużą do rozwinięcia kwestii, dlaczego i jak należy dostosować pracę, aby uniknąć przerw w wysiłkach związanych z migracją.

Racjonalizacja portfela wymaga różnorodności technicznych nakładów pracy. Zespoły wdrożeniowe ds. chmury mają pokusę dopasowania tej różnorodności portfela w ramach wysiłków związanych z migracją. Biznesowi uczestnicy projektu chcą współpracować z pojedynczym zespołem wdrożeniowym ds. chmury w celu prowadzenia całej listy prac migracji. Rzadko jest to zalecanym podejściem, a w wielu przypadkach może zmniejszać produktywność.

Te zróżnicowane wysiłki powinny być podzielone na segmenty w co najmniej dwóch zespołach wdrażania chmury. Użycie modelu dwuskładowego jako przykładowego trybu wykonywania, zespół 1 jest zespołem ds. migracji, a zespół 2 jest zespołem innowacji. W przypadku większych wysiłków te zespoły mogą być dalej podzielone na segmenty, aby rozwiązać inne podejścia, takie jak zastępowanie/refaktoryzacja paaS lub drobne refaktoryzacja. Poniżej przedstawiono umiejętności i role potrzebne do ponownego hostowania, refaktoryzacji lub drobnej refaktoryzacji:

Rehost: Ponowne hostowanie wymaga od członków zespołu wdrożenia zmian skoncentrowanych na infrastrukturze. Zasadniczo odbywa się to przy użyciu narzędzia, takiego jak Azure Site Recovery, do migrowania maszyn wirtualnych lub innych zasobów na platformę Azure. Ta praca dobrze pasuje do administratorów centrum danych lub realizatorów IT. Zespół ds. migracji do chmury ma odpowiednią strukturę, aby wykonać tę pracę na dużą skalę. Jest to najszybszy sposób migrowania istniejących zasobów w większości scenariuszy.

Refactor: Refaktoryzacja wymaga od członków zespołu modyfikowania kodu źródłowego, zmiany architektury aplikacji lub wdrażania nowych usług w chmurze. Zasadniczo ten w tych nakładach pracy wykorzystuje się narzędzia programistyczne, takie jak program Visual Studio i narzędzia potoku wdrażania, takie jak Azure DevOps, do ponownego wdrożenia zmodernizowanych nowoczesnych aplikacji na platformie Azure. Ta praca jest dopasowana do ról wytwarzania aplikacji lub ról wytwarzania potoku DevOps. Zespół ds. innowacji w chmurze najlepiej ustrukturyzuje tę pracę. Zastąpienie istniejących zasobów za pomocą zasobów w chmurze w tym podejściu może potrwać dłużej, ale aplikacje mogą korzystać z funkcji natywnych dla chmury.

Refaktoryzacja pomocnicza: Niektóre aplikacje można zmodernizować przy użyciu drobnych refaktoryzacji na poziomie danych lub aplikacji. Ta praca wymaga, aby członkowie zespołu wdrażali dane na platformach danych opartych na chmurze lub wprowadzali niewielkie zmiany konfiguracji w aplikacjach. Może to wymagać ograniczonego wsparcia ekspertów zajmujących się danymi lub rozwojem aplikacji. Jednak ta praca jest podobna do pracy wykonywanej przez implementatory IT podczas wdrażania aplikacji innych firm. Pracę tę można łatwo dopasować do zespołu ds. migracji do chmury lub zespołu strategicznego ds. chmury. Chociaż ten nakład pracy nie zbliża się do szybkości migracji polegającej na ponownym hostowaniu, jego wykonanie zajmuje mniej czasu niż nakład pracy na refaktoryzację.

Podczas migracji wysiłki powinny być podzielone na trzy sposoby wymienione powyżej i wykonywane przez odpowiedni zespół w odpowiedniej iteracji. Chociaż należy zdywersyfikować portfel, upewnij się również, że wysiłki pozostają bardzo skoncentrowane i segregowane.

Następne kroki

Dowiedz się, jak globalne decyzje rynkowe mogą wpływać na podróż transformacji.