Hierarchia portfela

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

Obciążenia

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

Zazwyczaj uczestnik projektu biznesowego i lider techniczny dzielą się odpowiedzialnością za bieżące 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 zróżnicowane.

Obciążenia i ich zasoby pomocnicze znajdują się w centrum każdego portfela. Zakresy lub warstwy definiują, jak te obciążenia są postrzegane i w jakim stopniu wpływają na macierz potencjalnych zespołów wsparcia.

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

• zasób: Najmniejsza jednostka funkcji technicznej, która obsługuje obciążenie lub rozwiązanie.
• Obciążenie: 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, dana operacja i jej zasoby mogą być jedynym zdefiniowanym zakresem. Inne warstwy mogą być jawnie zdefiniowane w miarę wdrażania większej liczby obciążeń.

IT portfolio

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

• pl-PL: Strefy docelowe: Strefy docelowe zapewniają zadaniom roboczym niezbędne podstawowe narzędzia lub wspólne zasoby, które są wymagane do obsługi jednego lub więcej zadań roboczych. Strefy docelowe są tak krytyczne w chmurze, że cała metodologia Ready przewodnika Cloud Adoption Framework koncentruje się na strefach docelowych. Aby uzyskać bardziej szczegółową definicję, zobacz Co to jest strefa docelowa?
• podstawowych narzędzi: Te udostępnione usługi IT są wymagane do obsługi obciążeń w ramach portfolio technologii i biznesu.
• Podstawy platformy: Ta konstrukcja organizacyjna centralizuje podstawowe rozwiązania i pomaga zapewnić, że te kontrole 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 różnymi wdrożeniami podstaw platformy do zarządzania wieloma regionami, rozwiązaniami hybrydowymi, a nawet rozwiązaniami wielochmurowymi.
• Portfolio: Z perspektywy technologii portfolio to zbiór głównych obciążeń, zasobów i zasobów pomocniczych obejmujących wszystkie platformy chmurowe. Dzięki obiektywowi biznesowemu portfolio jest kolekcją projektów, osób, procesów i inwestycji, które obsługują portfolio technologii i zarządzają nimi, aby zwiększyć wyniki biznesowe. Razem te dwa obiektywy przechwytują portfolio.

Odpowiedzialność hierarchii i wskazówki

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

Notatka

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 mogą zostać zwinięte zgodnie z opisem w dalszej części wariantów odpowiedzialności.

• Portfolio: Zespół ds. strategii chmurowej i centrum doskonałości chmurowej (CCoE) korzystają z metodologii Strategii i Planu, aby kierować decyzjami wpływającymi na ogólny portfel. Zespół strategiczny ds. chmury jest odpowiedzialny za ogólną strukturę hierarchii portfela chmury. Zespół strategiczny ds. chmury powinien być również poinformowany o decyzjach dotyczących środowiska, stref docelowych i obciążeń o wysokim priorytcie.
• Platformy chmurowe: Zespół ds. zarządzania w chmurze odpowiada za zasady i mechanizmy kontroli, które zapewniają zgodność i jednolitość w każdym środowisku zgodnie z metodologią Govern. Zespół ds. ładu w chmurze jest odpowiedzialny za zarządzanie wszystkimi zasobami we wszystkich środowiskach. Zespół ds. utrzymania ładu w chmurze powinien być konsultowany ze zmianami, które mogą wymagać wyjątku lub zmiany zasad zarządzania. Zespół ds. ł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ół ds. 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 gotowej do do kierowania implementacją. Oba zespoły powinny być informowane o postępach związanych z przyjmowaniem obciążenia pracą i wszelkimi zmianami w przedsiębiorstwie lub środowisku pracy.
• Obciążenia: wdrożenie odbywa się na poziomie obciążenia. Zespoły ds. adopcji chmury używają metodologii Migrate i Innovate, aby ustanowić skalowalne procesy przyspieszające wdrażanie. 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 do zarządzania operacjami. Oba zespoły powinny się czuć swobodnie z korzystaniem z platformy Microsoft Azure Well-Architected Framework, aby podejmować szczegółowe decyzje dotyczące architektury, które wpływają na obsługiwane obciążenia. Oba zespoły powinny być informowane o zmianach w strefach lądowania i środowiskach. Obie drużyny mogą czasami przyczyniać się do rozwoju elementów strefy lądowania.
• Zasoby: Za zasoby zazwyczaj odpowiada zespół ds. operacji w chmurze. Ten zespół korzysta z podstawowego modelu zarządzania w metodologii zarządzania, aby kierować decyzjami w zakresie zarządzania operacjami. Należy również użyć usługi Azure Advisor i platformy Azure Well-Architected Framework, aby wprowadzić szczegółowe zmiany zasobów i architektury, które są wymagane 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 lądowania: Jeśli środowisko ma tylko jedną strefę lądowania, funkcje zarządzania i platformy można prawdopodobnie połączyć w jeden zespół.
• Pojedyncze obciążenie: Niektóre firmy potrzebują tylko jednego obciążenia lub kilku obciążeń w jednej strefie lądowania i jednym środowisku. W takich przypadkach nie ma potrzeby rozdzielenia obowiązków między zespołami ds. ładu, platformy i operacji.

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

W poniższych przykładach przedstawiono hierarchię portfela.

Obciążenia COTS

Tradycyjnie przedsiębiorstwa preferowały rozwiązania oprogramowania typu COTS (commercial-off-the-shelf) 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ę umożliwiającą wdrażanie i obsługę wystąpienia pakietu oprogramowania w ramach Twoich subskrypcji. Mogą również oferować wersję pakietu oprogramowania działającego we własnym środowisku hostowanym w chmurze, oferując alternatywę w postaci platformy jako usługi (PaaS) 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 trakcie rozwoju z aktywnymi zmianami

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 niewielka część portfela IT korzysta z tego podejścia do obciążenia. Jednak obciążenia te mają tendencję do nieproporcjonalnie wysokiego odsetka wkładu IT w wyniki biznesowe, zwłaszcza wyników związanych z nowymi strumieniami przychodów. Te zadania mają tendencję dobrze odpowiadać nowym pomysłom na innowacje.

Biorąc pod uwagę różne ruchy zakorzenione w metodologiach agile i praktykach DevOps, te zadania sprzyjają współpracy biznesowej i DevOps nad tradycyjnym podejściem do zarządzania IT. W przypadku tych obciążeń przez kilka lat może nie nastąpić przekazywanie do zespołu ds. operacji w chmurze. W takich przypadkach zespół rozwojowy pełni rolę właściciela technicznego zadań.

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

Usuwanie awarii lub wycofywanie projektu

Gdy obciążenie opracowane na zamówienie osiągnie pełną 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 zaangażować deweloperów, aby rozwiązać błąd.

W niektórych przypadkach zespół programistyczny przejdzie do projektu, który ostatecznie zastąpi bieżące obciążenie. Alternatywnie zespół może przejść dalej, ponieważ możliwości biznesowe wynikające z obciążenia są wycofywane. W takich sytuacjach zespół 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. Zespół ten prawdopodobnie zatrudni deweloperów aplikacji, kiedy zmiany operacyjne będą wymagały znaczących zmian architektury.

Obciążenia o krytycznym znaczeniu

W każdej firmie kilka obciążeń jest zbyt ważnych dla działalności, aby mogły się nie powieść. W przypadku tych obciążeń o znaczeniu krytycznym zwykle istnieją właściciele operacji i rozwoju z różnymi poziomami odpowiedzialności. Te zespoły 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 będzie zazwyczaj odpowiadał za codzienne zmiany operacyjne w środowisku produkcyjnym. Gdy te zmiany operacyjne wymagają zmiany architektury, zostaną one ukończone przez zespół deweloperów lub wdrożeniowych 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 wsparcia 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.

Portfel skoncentrowany 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 portfolio z dużym obciążeniem programistycznym środowisko, strefa docelowa i obciążenia są często kompresowane, więc mogą istnieć konkretne środowiska dla określonych obciążeń. Wynik jest współczynnikiem 1:1 między środowiskiem, strefą docelową i obciążeniem.

Ponieważ środowisko obsługuje rozwiązania niestandardowe, potok DevOps i raportowanie na poziomie aplikacji mogą zastąpić potrzebę funkcji operacyjnych i zarządzania. 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.

dostosowanie portfela: Portfolio IT prawdopodobnie skoncentruje się na obciążeniach oraz ich właścicielach w celu podejmowania krytycznych decyzji dotyczących 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 portfolio oprogramowania firmy. Czasami może istnieć również segmentacja między wystąpieniami deweloperskimi a hostowanymi wystąpieniami klientów.

Portfolio zarządzane przez operacje

Międzynarodowe organizacje przedsiębiorstwa z bardziej ugruntowanymi zespołami ds. operacji IT zwykle koncentrują się na zarządzaniu i operacjach niż na rozwoju. W tych organizacjach, większy procent obciążeń zwykle odpowiada kategoriom COTS lub break/fix, które są utrzymywane przez właścicieli technicznych w zespole operacji chmurowych.

Dostosowanie portfela: Portfel IT będzie dostosowany do obciążeń, a te obciążenia będą następnie dostosowane do jednostek operacyjnych i biznesowych. Mogą istnieć również organizacje związane z modelami finansowania, branżą lub innymi wymaganiami dotyczącymi segmentacji biznesowej.

definicje granic: Strefy lądowania prawdopodobnie będą grupować aplikacje w archetypy aplikacji, w celu utrzymania podobnych operacji w tej samej segmentacji. Środowiska będą prawdopodobnie odnosić się do konstrukcji fizycznych, takich jak centrum danych, kraj, region dostawcy chmury lub inne standardy organizacji operacyjnej.

Portfolio zdominowane przez migrację

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

Dopasowanie portfela: Portfolio IT może być dostosowane do obciążenia, ale jest bardziej prawdopodobne, że jest dopasowane do zasobów. Jeśli w historii firmy doszło do przejść na operacje IT, wiele zasobów używanych aktywnie może nie być łatwo przyporządkowanych do finansowanej pracy. W takich przypadkach wiele zasobów może nie mieć zdefiniowanego obciążenia roboczego lub jasnego właściciela obciążenia roboczego aż do późnego etapu procesu migracji.

Definicje granic: Strefy lądowania prawdopodobnie grupują aplikacje w granice odzwierciedlające segmentację lokalną. Chociaż nie jest to najlepsze rozwiązanie, środowiska często odzwierciedlają nazwę lokalnego centrum danych i strefy docelowe (landing zones), które reprezentują praktyki segmentacji sieci. Lepszym rozwiązaniem jest przestrzeganie segmentacji, która ściślej odpowiada portfelowi prowadzonemu przez operacje.

Portfolio zarządzane przez zasady ładu korporacyjnego

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

Dopasowanie portfela: Portfele nadzorowane przez zarządzanie zwykle zawierają punkty danych, które ujmują szczegóły innowacji i operacji, takie jak obciążenie, właściciel operacji, klasyfikacja danych i krytyczność operacyjna. Te punkty danych tworzą kompleksowy obraz portfela.

definicje granic: Granice w nadzorowanym portfelu mają tendencję do faworyzowania operacji nad innowacjami, jednocześnie używając hierarchii zarządzanych przez grupy, które odnoszą się do kryteriów 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 elastyczność twórczą. Jednocześnie do subskrypcji produkcyjnych można stosować wymagania dotyczące klasy produkcyjnej w celu zapewnienia rozdzielenia obowiązków i spójnych operacji.

Następne kroki

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