Równoważenie konkurencyjnych priorytetów

Sukces każdej transformacji cyfrowej zależy od zdolności zainteresowanych stron biznesowych i technologicznych do zrównoważenia konkurencyjnych priorytetów.

Podobnie jak w przypadku innych transformacji cyfrowych wdrożenie chmury uwidacznia konkurencyjne priorytety w całym cyklu życia wdrażania. Podobnie jak w przypadku innych form transformacji, zdolność do równoważenia tych priorytetów ma znaczący wpływ na realizację wartości biznesowej. Równoważenie tych konkurencyjnych priorytetów wymaga otwartych i czasami trudnych rozmów między uczestnikami projektu, a czasami z poszczególnymi współautorami.

W tym artykule opisano niektóre z konkurencyjnych priorytetów, które są często omawiane podczas wdrażania każdej metodologii. Może to pomóc w przygotowaniu się do tych dyskusji podczas opracowywania strategii wdrażania chmury.

Poniższe sekcje są dostosowane do przepływu w poprzednim diagramie cyklu życia wdrażania chmury. Należy jednak pamiętać, że wdrożenie chmury jest procesem iteracyjnym, a nie sekwencyjnym, i że te konkurencyjne priorytety mogą zostać ponownie uruchomione w różnych punktach podczas wdrażania chmury.

Ogólny temat podejścia Cloud Adoption Framework

Rozwiązania monolityczne i zaawansowane planowanie są oparte na serii założeń, które mogą okazać się niedokładne w czasie. Wdrażanie chmury to często nowe środowisko dla firm i zespołów technicznych. Podobnie jak w przypadku większości nowych doświadczeń, istnieje pewne prawdopodobieństwo, że początkowe założenia zostaną udowodnione niepoprawne.

Przestrzeganie sprawdzonych zwinnych zasad opóźnionych decyzji technicznych jest preferowane podejście do większości wskazówek w ramach tej struktury. Takie podejście jest zgodne ze spójnym wzorcem: ustanowienie ogólnego stanu końcowego, szybkie przejście do początkowej implementacji, testowania i weryfikowania założeń oraz wczesne refaktoryzację w celu rozwiązania wadliwych założeń. Ten typ myślenia o wzroście maksymalizuje uczenie się i minimalizuje ryzyko związane z wartością biznesową, ale wymaga pewnego komfortu z niejednoznacznością.

Niejednoznaczność może czasami być przerażająca lub bardziej niebezpieczna niż fałszywe założenia. Mimo że ta struktura określa priorytety uczenia się i rozwiązywania niejednoznaczności podczas wdrażania, wiele sytuacji wymaga od zespołu nadania priorytetów metodom opartym na analizie lub podejściu opartym na założeniach. W poniższych sekcjach przedstawiono co najmniej jeden "przykład rozszerzonego zakresu", aby zilustrować, kiedy druga głębsza iteracja może być cenna.

Równowaga w fazie strategii

Głównym celem metodologii strategii jest opracowanie dopasowania między uczestnikami projektu. Po zdefiniowaniu dopasowanej pozycji strategicznej zachowanie wszystkich metodologii zapewnia, że decyzje techniczne są zgodne z pożądanymi wynikami biznesowymi. Wspieranie dopasowania między uczestnikami projektu tworzy wspólny zestaw konkurencyjnych priorytetów: głębokość uzasadnienia i czas na wpływ na działalność biznesową.

Konkurencyjne priorytety:

• Głębokość uzasadnienia: Uczestnicy projektu często chcą głębokiej analizy finansowej i pełnego uzasadnienia biznesowego, zanim będą wygodne z dopasowaniem do strategicznego kierunku. Niestety, ten poziom analizy może wymagać dłuższego okresu, aby umożliwić zbieranie i analizę danych.

• Czas na wpływ na działalność biznesową: Z drugiej strony uczestnicy projektu są często pociągnięci do odpowiedzialności za dostarczanie wyników biznesowych w zdefiniowanych przedziałach czasu. Czasochłonna analiza i ocena mogą narażać te wyniki na ryzyko, zanim rozpocznie się nawet praca techniczna.

Minimalny zakres: znalezienie właściwej równowagi wymaga dyskusji uczestników projektu na wczesnym etapie procesu. Metodologia strategii sugeruje ograniczenie zakresu dostosowania podczas tego wczesnego wysiłku. W sugerowanym podejściu uczestnicy projektu koncentrują się na dostosowaniu zestawu podstawowych motywacji, mierzalnych wyników i uzasadnienia biznesowego wysokiego poziomu. Uczestnicy projektu powinni następnie szybko zobowiązać się do kilku początkowych projektów lub pilotów w celu kierowania wymaganymi możliwościami uczenia się.

Przykład rozszerzonego zakresu: jeśli początkowa analiza biznesowa wskazuje wysokie ryzyko negatywnego wpływu na firmę, uczestnicy projektu mogą potrzebować spowolnić i ostrożniej ocenić dokładniejszą analizę podczas uzasadnienia biznesowego.

Saldo w fazie planowania

Podobnie jak w fazie strategii, w fazie planowania istnieje potrzeba zrównoważenia głębokości początkowego planowania w porównaniu z opóźnionymi decyzjami technicznymi.

Konkurencyjne priorytety:

• Głębokość początkowego planowania implementacji technicznej w chmurze jest często oparta na wielu założeniach. Szczególnie w przypadku braku umiejętności w zespole środowisko cierpi na luki w odnajdywania lub obciążenia nie mają jasno zdefiniowanych stanów końcowych architektury. Wszystkie te założenia są wspólne w szczegółowych planach wdrażania chmury. Eksperymentowanie, pilotaż i analiza jakościowa są wymagane do zweryfikowania lub ulepszenia tych założeń.

• Opóźnione decyzje techniczne opierają się na założeniu, że późniejsze podjęcie decyzji technicznej, tym bardziej dokładne jest. Przestrzeganie zasad elastycznego planowania produktu pomaga opóźnić decyzje techniczne, dzięki czemu mogą one nastąpić w odpowiednim czasie na podstawie wystarczających informacji. Jednak takie podejście skutkuje bardziej niejednoznacznością w początkowym planie.

Minimalny zakres: sugerujemy elastyczne podejścia do tworzenia produktów w celu podejmowania monitów w ramach planów, którymi można zarządzać. Metodologia planowania zaleca następujące kroki, aby osiągnąć tę równowagę:

1. Utwórz spis pełnego majątku cyfrowego przy użyciu narzędzi automatycznego odnajdywania, ale użyj racjonalizacji przyrostowej, aby zaplanować pracę od następnych 1 do 3 miesięcy.
2. Zapewnij odpowiednie dopasowanie organizacji, aby szybko przejść.
3. Utwórz plan gotowości umiejętności dla przypisanego zespołu. Użyj szablonu strategii i planu, aby szybko wdrożyć początkową listę prac.

Przykład rozszerzonego zakresu: Dostarczanie planu wdrożenia chmury może czasami być odpowiedzią na zdarzenie biznesowe z uwzględnieniem czasu lub dużego wpływu. Gdy powodzenie wymaga przenoszenia dużej liczby zasobów w określonym czasie, powyższe kroki są często wykonywane przez dokładniejsze planowanie. Kluczem do sukcesu w tych scenariuszach jest zaplanowanie wystarczającej ilości czasu, aby przejść, a następnie później zaplanować pełne zaangażowanie. Takie podejście zmniejsza prawdopodobieństwo, że planowanie zablokuje wyniki biznesowe.

Równowaga w fazie gotowości

Gdy zespoły przygotowują się do pierwszych kroków wdrażania chmury, często istnieją konkurencyjne priorytety między czasem wdrażania i długoterminowych operacji. Zespół może zmagać się z równowagą między dobrym rozwiązaniem w celu realizacji zadania pod ręką i dobrego zarządzania. Ta walka jest niezbędna w tradycyjnych środowiskach IT, w których działanie tworzenia platformy wymaga zasobów fizycznych i cykli pozyskiwania. Jednak gdy cała platforma IT jest zdefiniowana w kodzie, tradycyjna taktyka programowania, taka jak refaktoryzacja, zmniejsza potrzebę dobrego zarządzania od początku.

Konkurencyjne priorytety:

• Długotrwałe operacje: Organizacje są często blokowane przez chęć posiadania środowiska w chmurze spełniającego równoważność funkcji z bieżącymi systemami zarządzania operacjami, ładu i zabezpieczeń. W jednym z badań ponad 90 procent organizacji potrzebowało wsparcia, aby przejść przez ten sposób myślenia. Ten bloker może tworzyć miesiące opóźnienia, spowalniać lub uniemożliwiać wpływ na działalność biznesową.

• Czas na wdrożenie: narzędzia oparte na chmurze, takie jak Azure Policy, metody ciągłej integracji i ciągłego dostarczania (CI/CD), takie jak infrastruktura, jako kod (IaC) i grupy zarządzania mogą uprościć proces refaktoryzacji na całej platformie IT. Ponadto wstępnie zdefiniowane strefy docelowe zawierają zalecenia dotyczące przyspieszania wdrażania w środowisku, które spełnia już wiele wymagań dotyczących parzystości funkcji. Te narzędzia zapewniają możliwości przyspieszenia czasu obrotu przy minimalnym wpływie na długoterminowe operacje.

Minimalny zakres: Metodologia Gotowości przedstawia bezpośrednią ścieżkę od szybkiego wdrożenia do długoterminowych operacji. To podejście rozpoczyna się od podstawowego wprowadzenia do narzędzi, których można użyć do refaktoryzacji środowiska. Narzędzia uwzględniają wymagania i prowadzą cię do wyboru wstępnie zdefiniowanych stref docelowych dostarczanych z modelami IaC. Następnie można refaktoryzować kod w trakcie wdrażania chmury w celu poprawy operacji, zabezpieczeń i zarządzania.

Przykład rozszerzonego zakresu: w przypadku zespołów, których plan wdrożenia wymaga celu średnioterminowego (w ciągu 24 miesięcy) do hostowania ponad 1000 zasobów (aplikacji, infrastruktury lub zasobów danych) w chmurze, zalecamy bardziej niezawodny widok stref docelowych. W takich sytuacjach należy wziąć pod uwagę metodologie rządzenia i zarządzania podczas początkowych konwersacji strefy docelowej. Jednak ta głębsza kwestia często dodaje tygodnie lub miesiące do planu wdrożenia chmury. Aby zminimalizować wpływ na wyniki biznesowe, zespół wdrożeniowy powinien pilotować rzeczywiste obciążenia w chmurze, jednocześnie tworząc bardziej dojrzałą strefę docelową i centralne rozwiązanie architektury.

Saldo w fazie migracji

Podczas migracji zespoły wdrożeniowe często zakładają, że obciążenia będą ponownie hostowane w chmurze w bieżącej konfiguracji. To założenie konkuruje z planem przyszłościowym, aby zmienić architekturę każdego obciążenia, aby lepiej wykorzystać możliwości chmury. Te dwa widoki nie wykluczają się wzajemnie i mogą być bezpłatne podczas zarządzania nimi przy użyciu wspólnego procesu.

Konkurencyjne priorytety:

• Ponowne hostowanie: Organizacje często utożsamiają migrację metodą "lift-and-shift ", która replikuje wszystkie zasoby do chmury w bieżącej konfiguracji. Takie podejście skutkuje niewielkim dryfem w portfolio IT. Jest to również najszybszy sposób wycofywania zasobów w istniejącym centrum danych.

• Zmiana architektury: Modernizacja architektury każdego obciążenia maksymalizuje wartość wdrożenia chmury między kosztami, wydajnością i operacjami. Jednak takie podejście jest wolniejsze i często wymaga dostępu do kodu źródłowego każdej aplikacji.

Minimalny zakres: Podczas planowania na wczesnym etapie użyj opcji ponownego hostu do planowania, z wyraźnym zrozumieniem, że wybór jest oparty na początkowym założeniu biznesowym i nie jest decyzją techniczną. W metodologii migracji zespół wdrożeniowy ds. chmury następnie kwestionuje to założenie dla każdego zmigrowanego obciążenia. Ta metodologia jest zgodna z podejściem oceny/migracji/podwyższania poziomu dla każdego obciążenia lub grupy obciążeń w celu utworzenia fabryki migracji. W fazie oceny zespół wdrożeniowy ocenia dopasowanie techniczne i architekturę każdego obciążenia. Nakład pracy w tej ocenie rzadko skutkuje czystym podejściem metodą "lift-and-shift", ponieważ wiele składników architektury jest zwykle wybieranych do refaktoryzacji i modernizacji.

Przykład rozszerzonego zakresu: w przypadku obciążeń o krytycznym znaczeniu lub wysokiej poufności, takich jak aplikacje mikrousług mainframe lub wielowarstwowych, może być wymagana bardziej szczegółowa ocena obciążenia w fazie oceny. W tych sytuacjach architektury należy użyć przeglądu dobrze zaprojektowanego architektury platformy Azure i platformy Azure Well-Architected Framework , aby uściślić wymagania dotyczące obciążeń podczas oceny.

Równowaga w fazie innowacji

Prawdziwe innowacje związane z klientami często tworzą sprzeczne priorytety między koniecznością dostarczenia planowanego zestawu funkcji i wdrożeniem procesu opracowywania empatii klienta.

Konkurencyjne priorytety:

• Koncentracja na funkcjach: Wstępne plany innowacji opierają się na istniejących możliwościach majątku cyfrowego i chmury w celu dostarczania zestawu funkcji, które spełniają potrzeby klientów. Łatwo jest zezwolić planowi na realizację techniczną, co prowadzi do wysiłku programistycznego skoncentrowanego na funkcjach. Takie podejście często prowadzi do tymczasowego zadowolenia uczestników projektu, ale zmniejsza prawdopodobieństwo wprowadzenia innowacji, które wpływają na zachowanie klientów.

• Empatia klienta: Początkowe plany są ważną częścią rozwoju biznesowego i powinny być uwzględniane w regularnych raportach. Jednak uczenie się, mierzenie i budowanie z empatią klientów jako celem jest dokładniejszą miarą sukcesu w wysiłkach związanych z innowacjami. Skupienie się na klientach na funkcjach jest bardziej prawdopodobne, aby spowodować krótkoterminowe i długoterminowe zadowolenie klientów i wpływ na działalność biznesową.

Minimalny zakres: Metodologia innowacji ilustruje sposób integrowania strategii i planów za pośrednictwem konsensusu w zakresie wartości biznesowej. Następnie w przewodniku przedstawiono narzędzia natywne dla chmury, które mogą przyspieszyć każdą dyscyplinę innowacji i najlepszych rozwiązań dotyczących implementacji. Na koniec sekcja ulepszeń procesów przedstawia podejścia do budowania empatii klientów przy jednoczesnym poszanowaniu planów i strategii w ramach podróży wdrażania chmury. Takie podejście koncentruje się na dostarczaniu innowacji przy użyciu jak najmniejszej technologii.

Przykład rozszerzonego zakresu: Innowacja jest czasami zależna od obciążeń o znaczeniu krytycznym lub o wysokiej poufności. Gdy klient jest użytkownikiem wewnętrznym, nakład pracy programistycznej może być zarówno krytyczny, jak i wysoki poziom poufności podczas najwcześniejszych iteracji. W tych scenariuszach zespoły ds. wdrażania powinny korzystać z przeglądu dobrze zaprojektowanego architektury platformy Azure i platformy Azure Well-Architected Framework w celu oceny zaawansowanego projektu architektury na wczesnym etapie procesu.

Równoważenie równowagi w fazie utrzymania ładu

Praktyka zapewniania ładu w chmurze jest równowagą między dwoma konkurencyjnymi priorytetami: szybkością i elastycznością a dobrze zarządzanym środowiskiem. Zespół ds. ładu w chmurze koncentruje się na ocenie i zminimalizowaniu ryzyka dla firmy poprzez jednolite mechanizmy kontroli i minimalizację zmian. Zespół wdrożeniowy koncentruje się na prowadzeniu wyników biznesowych, które wymagają nowych zagrożeń i z natury tworzą zmiany.

Konkurencyjne priorytety:

• Dobrze zarządzane: każda kontrolka zaprojektowana w celu zminimalizowania ryzyka blokuje pewien aspekt zmian lub limitów opcji projektowania. Kontrola jest niezbędna dla dobrze zarządzanego środowiska. Jednak gdy kontrolki są projektowane i wdrażane w izolacji, mogą być tak szkodliwe, jak zagrożenia, które mają zapobiec.
• Szybkość i elastyczność: Szybkość i elastyczność są podstawowymi wymaganiami biznesowymi w gospodarce cyfrowej. Oba wymagają możliwości kierowania zmianami przy minimalnych blokadach innowacji lub wdrażania. Jednak gdy zmiana jest napędzana bez ładu, generuje nowe ryzyko, które może zaszkodzić firmie w nieoczekiwany sposób.

Minimalny zakres: Metodologia ładów sugeruje, że ani ład, ani wdrożenie nigdy nie powinny występować w izolacji. Ta metodologia rozpoczyna się od zrozumienia dyscyplin ładu i rozmowy na temat ryzyka biznesowego, zasad i procesu. Jako aktywny uczestnik wdrożenia chmury zespół ds. utrzymania ładu może wdrożyć minimalny zestaw zabezpieczeń w celu rozwiązania rzeczywistych zagrożeń w ramach planu wdrożenia chmury. Z biegiem czasu zespół ds. ładu może refaktoryzować i rozszerzać te zabezpieczenia, aby sprostać nowym zagrożeniom. Takie podejście maksymalizuje uczenie się i innowacje przy jednoczesnym zminimalizowaniu ryzyka.

Przykład rozszerzonego zakresu: jeśli ryzyko biznesowe jest wysokie, szczególnie na wczesnym etapie wdrażania, zespół ds. ładu w chmurze może wymagać przyspieszenia rozszerzania implementacji ładu. Możesz użyć tych samych wskazówek i ćwiczeń, aby dodać ten wyższy poziom ładu, ale może być konieczne szybsze. W niektórych scenariuszach zaawansowany stan ładu może być nawet wymagany podczas opracowywania pierwszych stref docelowych.

Równoważenie równowagi w fazie zarządzania

Model biznesowy IT do zarządzania operacjami stale ewoluował w ciągu ostatniej dekady. W miarę jak konserwacja sprzętu przechodzi dalej od podstawowej propozycji wartości IT, widok zarządzania operacjami uległ zmianie. W miarę zwiększania się nakładów na dostarczanie wartości biznesowej zespoły zarządzania operacjami są w konflikcie z koniecznością zrównoważenia operacji bez operacji i małych operacji w porównaniu z szerokimi inwestycjami.

Konkurencyjne priorytety:

• Szerokie inwestycje: Inwestowanie w równie unikanie awarii, szybkie odzyskiwanie i monitorowanie w całym środowisku jest tradycyjnym podejściem do zarządzania operacjami. Takie podejście może być kosztowne, a czasami duplikuje produkty pomocnicze dostarczane przez dostawcę usług w chmurze.

• No-ops i low-ops: użyj natywnych dla chmury narzędzi operacyjnych, aby zminimalizować powtarzające się i cykliczne zadania, które były wcześniej dostarczane przez pracowników. Zmniejszenie tych zależności operacyjnych zwalnia pracowników, aby zwiększyć wartość w inny sposób. Jednak w izolacji takie podejście może prowadzić do obsługi operacji podrzędnych.

Minimalny zakres: Metodologia zarządzania sugeruje ustanowienie natywnego dla chmury planu bazowego bez operacji. Uznając, że plan bazowy no-ops nie spełnia wszystkich potrzeb biznesowych, współpracuj z firmą, aby zdefiniować zobowiązania i lepiej dostosować inwestycje. Rozwiń plan bazowy, aby zaspokoić typowe potrzeby wszystkich obciążeń. Następnie włącz zespoły platformy lub określone zespoły obciążeń, aby zachować dobrze zarządzane rozwiązania w dobrze zarządzanym środowisku.

Przykład rozszerzonego zakresu: W większości środowisk wartość biznesowa niewielkiej części obciążeń uzasadnia głębokie inwestycje w operacje z it. W przypadku tych obciążeń zespół IT może chcieć użyć recenzji dobrze zaprojektowanej architektury platformy Azure i platformy Azure Well-Architected Framework, aby przeprowadzić bardziej szczegółowe operacje.

Saldo w fazie organizacji

Konkurencyjne priorytety opisane w tym artykule odzwierciedlają dążenie IT do realizacji wymagań biznesowych w celu zapewnienia szybkości i elastyczności. Ta sama zmiana pojawia się w zmianach schematów organizacyjnych lub struktur wirtualnych zespołów w celu zapewnienia lepszej obsługi wyników biznesowych. W miarę jak liderzy IT zastanawiają się nad strukturami zespołów, często są rozwiązywane dwa konkurencyjne priorytety: scentralizowana kontrola a kontrola delegowana.

Konkurencyjne priorytety:

• Scentralizowana kontrola: ten model operacyjny koncentruje się na centralizacji wszystkich kontrolek wymaganych do wymuszania sztywnych zasad. W tym modelu it służy jako element blokujący innowacje, szybkość i elastyczność. Jednak it może zapewnić wyższy stopień stabilności, zgodności i zabezpieczeń.

• Kontrola delegowana: w tym rozproszonym modelu operacyjnym zakłada się, że każdy zespół DevOps lub zespół aplikacji biznesowych zapewni własny zestaw kontrolek na podstawie rozwiązań wymaganych do realizacji celów biznesowych. W tym modelu dział IT udostępnia wytyczne ułatwiające zespołom unikanie zagrożeń, ale minimalizuje liczbę wymuszonych ograniczeń technicznych, jeśli to możliwe.

Minimalny zakres: większość organizacji przechodzi naturalny zestaw ewolucji w czasie. Metodologia Organizuj przedstawia najbardziej typową serię ewolucji. Zalecamy, aby zespoły starały się przejść do struktury centrum doskonałości w chmurze (CCoE), aby zapewnić delegowane podejścia kontroli.

Przykład rozszerzonego zakresu: wiele sytuacji wyzwala potrzebę scentralizowanej kontroli. Wymagania dotyczące zgodności innych firm i tymczasowe ujawnienie zabezpieczeń to dwa przykłady wyzwalaczy scentralizowanej kontroli. W takich sytuacjach często konieczne jest ustanowienie ograniczeń zasad i sztywnych, stałych mechanizmów kontroli. Jednak aby umożliwić kontynuowanie innowacji i wdrażania, zachęcamy centralne zespoły IT do dostarczania tych mechanizmów kontroli w oparciu o krytyczność i wrażliwość każdego obciążenia. Zapewnienie środowisk o mniejszej kontroli, ale ograniczony zakres lub profil ryzyka umożliwia elastyczność nawet wtedy, gdy jest wymagana kontrola.

Następne kroki

Dowiedz się, jak zrównoważyć migrację, innowacje i eksperymenty, aby zmaksymalizować wartość wysiłków związanych z migracją do chmury.