Hierarchia portfolio

Aby zrozumieć, w jaki sposób portfolio obciążeń, zasobów i usług pomocniczych współdziała ze sobą, należy ustanowić hierarchię portfela. Ten artykuł zawiera jasne definicje poziomów hierarchii portfolio wraz ze wskazówkami dotyczącymi zespołów w zakresie realizacji oczekiwań dla każdego poziomu. W tym artykule każdy poziom hierarchii jest również nazywany zakresem.

Pakiety robocze

Kolekcja technologii, która dostarcza zdefiniowaną wartość biznesową, jest nazywana obciążeniem. Kolekcja może obejmować aplikacje, serwery lub maszyny wirtualne, dane, urządzenia i inne podobnie zgrupowane zasoby. Większość firm korzysta z wielu obciążeń, aby dostarczać istotne funkcje biznesowe.

Zazwyczaj uczestnik projektu biznesowego i lider techniczny mają wspólną odpowiedzialność za ciągłe wsparcie każdego obciążenia. W niektórych fazach cyklu życia obciążenia te role są wyraźnie określone. W bardziej operacyjnych fazach cyklu życia obciążenia te role mogą być przenoszone do udostępnionego zespołu zarządzania operacjami lub zespołu ds. operacji w chmurze. Wraz ze wzrostem liczby obciążeń role (określone lub implikowane) stają się bardziej złożone i bardziej macierzowe.

Obciążenia i ich zasoby pomocnicze są podstawą każdego portfela. Zakresy lub warstwy definiują sposób wyświetlania tych obciążeń i w jakim stopniu mają one wpływ na macierz potencjalnych zespołów pomocniczych.

Mimo że terminy mogą się różnić, wszystkie rozwiązania IT obejmują zasoby i obciążenia:

• Aktywów: Najmniejsza jednostka funkcji technicznej, która obsługuje obciążenie lub rozwiązanie.
• Obciążenia: Najmniejsza jednostka pomocy technicznej IT dla firmy. Obciążenie to kolekcja zasobów infrastruktury, aplikacji i danych, które obsługują wspólny cel biznesowy lub wykonywanie typowego procesu biznesowego.

Podczas wdrażania pierwszego obciążenia obciążenie i jego zasoby mogą być jedynym zdefiniowanym zakresem. Pozostałe warstwy mogą być jawnie zdefiniowane w miarę wdrażania większej liczby obciążeń.

Portfolio IT

Gdy firmy obsługują obciążenia za pomocą metod macierzowych lub scentralizowanych podejść, istnieje szersza hierarchia, która prawdopodobnie obsługuje te obciążenia:

• Strefy docelowe: Strefy docelowe zapewniają obciążenia z niezbędnymi podstawowymi narzędziami lub współużytkowaniem kanalizacyjnymi, które są wymagane do obsługi co najmniej jednego obciążenia. Strefy docelowe są tak krytyczne w chmurze, że cała metodologia Gotowości Cloud Adoption Framework koncentruje się na strefach docelowych. Aby uzyskać bardziej szczegółową definicję, zobacz Co to jest strefa docelowa?
• Podstawowe narzędzia: Te współużytkowane usługi IT są wymagane, aby obciążenia działały w ramach portfolio technologii i biznesu.
• Podstawy platformy: Ta konstrukcja organizacyjna centralizuje podstawowe rozwiązania i zapewnia, że te kontrolki są wymuszane dla wszystkich stref docelowych.
• Platformy w chmurze: W zależności od ogólnej strategii obsługi pełnego portfolio klienci mogą potrzebować wielu platform w chmurze z odrębnymi wdrożeniami podstaw platformy, aby zarządzać wieloma regionami, rozwiązaniami hybrydowymi, a nawet rozwiązaniami wielochmurowymi.
• Portfolio: Dzięki technologii portfolio jest kolekcją obciążeń, zasobów i zasobów pomocniczych obejmujących wszystkie platformy w chmurze. Dzięki obiektywowi biznesowemu portfolio jest kolekcją projektów, osób, procesów i inwestycji, które wspierają portfolio technologii i zarządzają nim, aby napędzać wyniki biznesowe. Razem te dwa obiektywy przechwytują portfolio.

Odpowiedzialność i wskazówki dotyczące hierarchii

Zespół odpowiedzialny zarządza każdą warstwą hierarchii portfela. Na poniższym diagramie przedstawiono mapowanie między odpowiedzialnym zespołem a wskazówkami dotyczącymi wspierania decyzji biznesowych, decyzji technicznych i implementacji technicznej.

Uwaga

Zespoły wymienione na poniższej liście mogą być zespołami wirtualnymi lub osobami. W przypadku niektórych wariantów tej hierarchii niektóre zespoły odpowiedzialne można zwinąć zgodnie z opisem w dalszej części wariantów odpowiedzialności.

• Portfolio: Zespół strategiczny ds. chmury i centrum doskonałości w chmurze (CCoE) używają metodologii strategii i planowania , aby kierować decyzjami wpływającymi na ogólne portfolio. Zespół strategiczny ds. chmury jest odpowiedzialny za poziom przedsiębiorstwa hierarchii portfolio chmury. Zespół strategiczny ds. chmury powinien być również poinformowany o decyzjach dotyczących środowiska, stref docelowych i obciążeń o wysokim priorytcie.
• Platformy w chmurze: Zespół ds. utrzymania ładu w chmurze jest odpowiedzialny za dyscypliny, które zapewniają spójność w każdym środowisku zgodnie z metodologią ładu . Zespół ds. utrzymania ładu w chmurze jest odpowiedzialny za zarządzanie wszystkimi zasobami we wszystkich środowiskach. Zespół ds. utrzymania ładu w chmurze powinien być konsultowany w sprawie zmian, które mogą wymagać wyjątku lub zmiany zasad zarządzania. Zespół ds. utrzymania ładu w chmurze powinien być również poinformowany o postępach związanych z wdrażaniem obciążeń i zasobów.
• Strefy docelowe i podstawy chmury: Zespół ds. platformy w chmurze jest odpowiedzialny za opracowywanie stref docelowych i narzędzi platformy, które obsługują wdrażanie. Zespół automatyzacji chmury jest odpowiedzialny za automatyzację rozwoju i ciągłego wsparcia dla tych stref docelowych i narzędzi platformy. Oba zespoły używają metodologii Gotowe do kierowania implementacją. Oba zespoły powinny być poinformowane o postępach związanych z wdrażaniem obciążeń i wszelkimi zmianami w przedsiębiorstwie lub środowisku.
• Obciążeń: Wdrożenie odbywa się na poziomie obciążenia. Zespoły ds. wdrażania chmury używają metodologii migracji i innowacji w celu ustanowienia skalowalnych procesów w celu przyspieszenia wdrażania. Po zakończeniu wdrażania własność obciążeń prawdopodobnie zostanie przeniesiona do zespołu ds. operacji w chmurze, który korzysta z metodologii Zarządzania w celu zarządzania operacjami. Oba zespoły powinny być wygodne przy użyciu platformy Microsoft Azure Well-Architected Framework w celu podejmowania szczegółowych decyzji dotyczących architektury, które mają wpływ na obsługiwane obciążenia. Oba zespoły powinny być poinformowane o zmianach w strefach docelowych i środowiskach. Obie drużyny mogą od czasu do czasu współtworzyć funkcje strefy docelowej.
• Aktywów: Zasoby są zwykle odpowiedzialne za zespół ds. operacji w chmurze. Ten zespół używa planu bazowego zarządzania w metodologii zarządzania , aby kierować decyzjami zarządzania operacjami. Powinna również używać usług Azure Advisor i Azure Well-Architected Framework do wprowadzania szczegółowych zmian zasobów i architektury wymaganych do spełnienia wymagań dotyczących operacji.

Warianty odpowiedzialności

• Jedno środowisko: Gdy przedsiębiorstwo potrzebuje tylko jednego środowiska, CCoE zwykle nie jest wymagane.
• Pojedyncza strefa docelowa: Jeśli środowisko ma tylko jedną strefę docelową, funkcje ładu i platformy mogą być prawdopodobnie łączone w jeden zespół.
• Pojedyncze obciążenie: Niektóre firmy potrzebują tylko jednego obciążenia lub kilku obciążeń w jednej strefie docelowej i jednym środowisku. W takich przypadkach nie ma potrzeby rozdzielenia obowiązków między zespołami ds. utrzymania ładu, platformy i operacji.

Typowe przykłady obciążeń i odpowiedzialności

Poniższe przykłady ilustrują hierarchię portfela.

Obciążenia COTS

Tradycyjnie przedsiębiorstwa faworyzowały komercyjne rozwiązania programowe (COTS) do obsługi procesów biznesowych. Te rozwiązania są instalowane, konfigurowane, a następnie obsługiwane. Po skonfigurowaniu architektury rozwiązań niewiele się zmienia.

W tych scenariuszach każde wdrożenie chmury rozwiązań COTS kończy się przejściem do zespołu ds. operacji w chmurze. Następnie zespół ds. operacji w chmurze staje się właścicielem technicznym tego oprogramowania i zakłada odpowiedzialność za zarządzanie konfiguracją, kosztami, cyklami stosowania poprawek i innymi potrzebami operacyjnymi.

Te obciążenia obejmują pakiety księgowe, oprogramowanie logistyczne lub rozwiązania specyficzne dla branży. W terminologii firmy Microsoft dostawcy tych pakietów są nazywani niezależnymi dostawcami oprogramowania (ISV). Wiele niezależnych dostawców oprogramowania oferuje usługę do wdrażania i obsługi wystąpienia pakietu oprogramowania w Twoich subskrypcjach. Mogą również oferować wersję pakietu oprogramowania działającego we własnym środowisku hostowanym w chmurze, zapewniając platformę jako usługę (PaaS) alternatywę dla obciążenia.

Z wyjątkiem ofert PaaS zespoły ds. operacji w chmurze są odpowiedzialne za zapewnienie podstawowych wymagań dotyczących zgodności operacyjnej dla tych obciążeń. Zespół ds. operacji w chmurze powinien współpracować z zespołem ds. utrzymania ładu w chmurze, aby dostosować koszty, wydajność i inne filary architektury.

W programowania z aktywnymi poprawkami

Gdy rozwiązanie COTS lub oferta PaaS nie są dostosowane do potrzeb biznesowych lub nie istnieje żadne rozwiązanie, przedsiębiorstwa tworzą niestandardowe obciążenia. Zazwyczaj tylko niewielki procent portfela IT korzysta z tego podejścia do obciążenia. Jednak te obciążenia mają tendencję do nieproporcjonalnie wysokiego odsetka wkładu IT w wyniki biznesowe, zwłaszcza wyników związanych z nowymi strumieniami przychodów. Te obciążenia mają tendencję do mapowania na nowe pomysły na innowacje.

Biorąc pod uwagę różne ruchy zakorzenione w metodologiach agile i praktykach Metodyki DevOps, te obciążenia faworyzują dopasowanie biznesowe/DevOps do tradycyjnego zarządzania IT. W przypadku tych obciążeń może nie być od kilku lat przekazanie zespołowi ds. operacji w chmurze. W takich przypadkach zespół programistyczny pełni rolę właściciela technicznego obciążenia.

Ze względu na obszerne ograniczenia czasowe i kapitałowe niestandardowe opcje programowania są często ograniczone do możliwości o wysokiej wartości. Typowe przykłady obejmują innowacje aplikacji, głęboką analizę danych lub funkcje biznesowe o krytycznym znaczeniu.

Przerwanie/naprawa lub rozwój zachodu słońca

Gdy obciążenie niestandardowe osiągnie szczytową dojrzałość, zespół deweloperów może zostać ponownie przydzielony do innych projektów. W takich przypadkach własność techniczna zwykle przechodzi do zespołu ds. operacji w chmurze. Jeśli istnieje potrzeba małych poprawek, zespół operacyjny będzie zarejestrować deweloperów, aby rozwiązać ten problem.

W niektórych przypadkach zespół deweloperów przechodzi do projektu, który ostatecznie zastąpi bieżące obciążenie. Alternatywnie zespół może przejść dalej, ponieważ możliwości biznesowe obsługiwane przez obciążenie są wycofywane. W tych scenariuszach zachodu słońca zespół ds. operacji w chmurze pełni rolę właściciela technicznego, dopóki obciążenie nie będzie już potrzebne.

W obu scenariuszach zespół operacyjny ds. chmury zazwyczaj pełni rolę długoterminowego właściciela technicznego i twórcy decyzji. Ten zespół prawdopodobnie będzie zarejestrować deweloperów aplikacji, gdy zmiany operacyjne wymagają znaczących zmian architektury.

Obciążenia o znaczeniu krytycznym

W każdej firmie kilka obciążeń jest zbyt ważne dla firmy, aby ich awaria nie powiodła się. W przypadku tych obciążeń o znaczeniu krytycznym zwykle istnieją operacje i właściciele programowania z różnymi poziomami odpowiedzialności. Zespoły te powinny dostosować zmiany operacyjne i zmiany architektury, aby zminimalizować zakłócenia w rozwiązaniu produkcyjnym.

Te scenariusze wymagają silnego skupienia się na rozdzieleniu obowiązków. Zespół operacyjny zazwyczaj będzie odpowiedzialność za codzienne zmiany operacyjne w środowisku produkcyjnym. Gdy te zmiany operacyjne wymagają zmiany architektury, zostaną one ukończone przez zespół deweloperów lub wdrażania w środowisku nieprodukcyjnym, zanim zespół operacyjny zastosuje zmiany do środowiska produkcyjnego.

Przykłady obciążeń o znaczeniu krytycznym z wymaganym rozdzieleniem obowiązków obejmują obciążenia, takie jak SAP, Oracle lub inne rozwiązania do planowania zasobów przedsiębiorstwa (ERP), które obejmują wiele jednostek biznesowych w firmie.

Dopasowanie portfela strategii

Ważne jest, aby zrozumieć strategiczne cele nakładu pracy nad wdrożeniem chmury i dostosować portfolio do obsługi tej transformacji. Kilka typowych typów dopasowania portfela strategicznego pomaga kształtować strukturę hierarchii portfela. W poniższych sekcjach przedstawiono przykłady wyrównania portfela i wpływu na hierarchię portfela.

Portfolio oparte na innowacjach lub rozwoju

Niektóre firmy, zwłaszcza szybko rozwijające się startupy, mają wyższy niż średni procent niestandardowych projektów programistycznych. W przypadku portfolio z dużym obciążeniem programistycznym środowisko, strefa docelowa i obciążenia są często kompresowane, więc mogą istnieć określone środowiska dla określonych obciążeń. Wynikiem jest stosunek 1:1 między środowiskiem, strefą docelową i obciążeniem.

Ponieważ środowisko hostuje rozwiązania niestandardowe, potok DevOps i raportowanie na poziomie aplikacji mogą zastąpić potrzebę działania i funkcji ładu. Ci klienci prawdopodobnie zredukują skupienie się na operacjach, zarządzaniu lub innych rolach pomocniczych. Większy nacisk na obowiązki zespołów ds. wdrażania chmury i automatyzacji chmury jest również typowy.

Wyrównanie portfela: Portfolio IT będzie prawdopodobnie koncentrować się na obciążeniach i właścicielach obciążeń, aby podejmować krytyczne decyzje dotyczące architektury. Te zespoły prawdopodobnie znajdą więcej wartości w wytycznych dotyczących platformy Azure Well-Architected Framework podczas działań związanych z wdrażaniem i operacjami.

Definicje granic: Granice logiczne, nawet na poziomie przedsiębiorstwa, prawdopodobnie skupią się na segmentacji środowiska produkcyjnego i nieprodukcyjnego. Może również istnieć wyraźna segmentacja między produktami w portfelu oprogramowania firmy. Czasami może istnieć również segmentacja między wystąpieniami deweloperów i hostowanych klientów.

Portfolio prowadzone przez operacje

Międzynarodowe organizacje przedsiębiorstwa z bardziej ustalonymi zespołami ds. operacji IT zwykle koncentrują się na zarządzaniu i operacjach niż na rozwoju. W tych organizacjach wyższa wartość procentowa obciążeń zwykle jest zgodna z kategoriami COTS lub break/fix, utrzymywaną przez właścicieli technicznych w zespole ds. operacji w chmurze.

Wyrównanie portfela: Portfolio IT będzie dostosowane do obciążenia, ale obciążenia te są następnie dostosowane do jednostek operacyjnych lub jednostek biznesowych. Mogą istnieć również organizacje związane z modelami finansowania, branżą lub innymi wymaganiami dotyczącymi segmentacji biznesowej.

Definicje granic: Strefy docelowe prawdopodobnie grupują aplikacje w archetypy aplikacji, aby zachować podobne operacje w podobnej segmentacji. Środowiska będą prawdopodobnie odnosić się do konstrukcji fizycznych, takich jak centrum danych, naród, region dostawcy chmury lub inne standardy organizacji operacyjnej.

Portfolio prowadzone przez migrację

Podobnie jak portfele prowadzone przez operacje, portfel, który jest w dużej mierze zbudowany przez migrację, będzie oparty na konkretnych czynników biznesowych, które doprowadziły do migracji istniejących zasobów. Zazwyczaj centrum danych jest największym czynnikiem w tych czynnikach.

Wyrównanie portfela: Portfolio IT może być dostosowane do obciążenia, ale jest bardziej prawdopodobne, że są wyrównane zasób. W przypadku przejścia do operacji IT w historii firmy wiele zasobów aktywnego użycia może nie być łatwo mapowanych na finansowane obciążenie. W takich przypadkach wiele zasobów może nie mieć zdefiniowanego obciążenia lub wyczyścić właściciela obciążenia do końca procesu migracji.

Definicje granic: Strefy docelowe prawdopodobnie grupują aplikacje w granice, które odzwierciedlają segmentację lokalną. Chociaż nie jest to najlepsze rozwiązanie, środowiska często są zgodne z lokalną nazwą centrum danych i strefami docelowymi, które reprezentują praktyki segmentacji sieci. Lepszym rozwiązaniem jest przestrzeganie segmentacji, która ściślej odpowiada portfelowi prowadzonemu przez operacje.

Portfolio oparte na zarządzaniu

Dostosowanie do zespołów ds. ładu powinno nastąpić tak szybko, jak to możliwe. Dzięki praktykom ładu i narzędziom ładu w chmurze portfolio i granice środowiskowe mogą najlepiej równoważyć potrzeby innowacji, operacji i działań związanych z migracją.

Wyrównanie portfela: Portfele oparte na zarządzaniu zwykle obejmują punkty danych, które przechwytują szczegóły innowacji i operacji, takie jak obciążenie, właściciel operacji, klasyfikacja danych i krytyczność operacyjna. Te punkty danych tworzą dobrze zaokrąglony widok portfela.

Definicje granic: Granice portfela opartego na zarządzaniu mają tendencję do faworyzowania operacji w zakresie innowacji przy użyciu hierarchii opartej na grupach zarządzania, która mapuje na kryteria jednostek biznesowych i środowisk deweloperskich. Na każdym poziomie hierarchii granica ładu w chmurze może mieć różne stopnie wymuszania zasad, aby umożliwić tworzenie i twórczą elastyczność. Jednocześnie wymagania dotyczące klasy produkcyjnej można zastosować do subskrypcji produkcyjnych, aby zapewnić rozdzielenie obowiązków i spójnych operacji.

Następne kroki

Dowiedz się, jak produkty platformy Azure obsługują hierarchię portfolio.