Portföljhierarki

För att förstå hur en portfölj med arbetsbelastningar, tillgångar och stödtjänster fungerar tillsammans måste du upprätta en portföljhierarki. Den här artikeln innehåller tydliga definitioner för nivåerna i din portföljhierarki, tillsammans med vägledning för teamen att uppfylla förväntningarna för varje nivå. I den här artikeln kallas varje nivå i hierarkin även för ett omfång.

Arbetsbelastningar

En samling tekniker som levererar ett definierat affärsvärde kallas för en arbetsbelastning. Samlingen kan innehålla program, servrar eller virtuella datorer, data, enheter och andra liknande grupperade tillgångar. De flesta företag förlitar sig på flera arbetsbelastningar för att leverera viktiga affärsfunktioner.

Vanligtvis delar en affärsintressent och teknisk ledare ansvar för det löpande stödet för varje arbetsbelastning. I vissa faser av arbetsbelastningens livscykel anges dessa roller tydligt. I mer operativa faser i en arbetsbelastnings livscykel kan dessa roller övergå till en delad drifthanteringsteam eller molndriftsteam. När antalet arbetsbelastningar ökar blir rollerna (angivna eller underförstådda) mer komplexa och mer matriserade.

Arbetsbelastningar och deras stödjande tillgångar är kärnan i alla portföljer. Omfången eller lagren definierar hur dessa arbetsbelastningar visas och i vilken utsträckning de påverkas av matrisen för potentiella stödteam.

Villkoren kan variera, men alla IT-lösningar innehåller tillgångar och arbetsbelastningar:

• Tillgång: Den minsta tekniska funktionen som stöder en arbetsbelastning eller lösning.
• Arbetsbelastning: Den minsta it-supportenheten för verksamheten. En arbetsbelastning är en samling infrastruktur-, program- och datatillgångar som stöder ett gemensamt affärsmål eller körning av en gemensam affärsprocess.

När du distribuerar din första arbetsbelastning kan arbetsbelastningen och dess tillgångar vara det enda definierade omfånget. De andra lagren kan definieras explicit när fler arbetsbelastningar distribueras.

IT-portfölj

När företag stöder arbetsbelastningar via matrisbaserade metoder eller centraliserade metoder finns det sannolikt en bredare hierarki som stöder dessa arbetsbelastningar:

• Landningszoner: Landningszoner ger arbetsbelastningar de nödvändiga grundläggande verktygen, eller delade rörmokare, som krävs för att stödja en eller flera arbetsbelastningar. Landningszoner är så viktiga i molnet att hela ready-metoden i Cloud Adoption Framework fokuserar på landningszoner. En mer detaljerad definition finns i Vad är en landningszon?
• Grundläggande verktyg: Dessa delade IT-tjänster krävs för att arbetsbelastningar ska fungera inom teknik- och affärsportföljen.
• Plattformsgrund: Den här organisationskonstruktionen centraliserar grundläggande lösningar och hjälper till att säkerställa att dessa kontroller tillämpas för alla landningszoner.
• Molnplattformar: Beroende på den övergripande strategin för att stödja hela portföljen kan kunder behöva flera molnplattformar med distinkta distributioner av plattformsgrunden för att styra flera regioner, hybridlösningar eller till och med lösningar med flera moln.
• Portfölj: Genom en tekniklins är portföljen en samling arbetsbelastningar, tillgångar och stödresurser som omfattar alla molnplattformar. Genom en affärslins är portföljen en samling projekt, personer, processer och investeringar som stöder och hanterar teknikportföljen för att driva affärsresultat. Tillsammans fångar dessa två linser portföljen.

Hierarkiansvar och vägledning

Ett ansvarigt team hanterar varje lager i portföljhierarkin. Följande diagram visar mappningen mellan det ansvariga teamet och vägledningen för att stödja affärsbeslut, tekniska beslut och teknisk implementering.

Anteckning

Teamen som nämns i följande lista kan vara virtuella team eller individer. För vissa varianter av den här hierarkin kan vissa ansvariga team döljas enligt beskrivningen senare i varianterna av ansvar.

• Portfölj: Molnstrategiteamet och CCoE (Cloud Center of Excellence) använder strategi - ochplanmetoderna för att vägleda beslut som påverkar den övergripande portföljen. Molnstrategiteamet ansvarar för företagsnivån i molnportföljhierarkin. Molnstrategiteamet bör också informeras om beslut om miljö, landningszoner och arbetsbelastningar med hög prioritet.
• Molnplattformar: Molnstyrningsteamet ansvarar för de discipliner som säkerställer konsekvens i varje miljö i enlighet med styrningsmetodiken . Molnstyrningsteamet ansvarar för styrningen av alla resurser i alla miljöer. Molnstyrningsteamet bör rådfrågas om ändringar som kan kräva ett undantag eller ändringar av gällande principer. Molnstyrningsteamet bör också informeras om förloppet för arbetsbelastning och tillgångsimplementering.
• Landningszoner och molngrund: Molnplattformsteamet ansvarar för att utveckla de landningszoner och plattformsverktyg som stöder implementeringen. Teamet för molnautomatisering ansvarar för att automatisera utvecklingen av och kontinuerligt stöd för dessa landningszoner och plattformsverktyg. Båda teamen använder metoden Klar för att vägleda implementeringen. Båda teamen bör informeras om framstegen med implementering av arbetsbelastningar och eventuella ändringar i företaget eller miljön.
• Arbetsbelastningar: Implementeringen sker på arbetsbelastningsnivå. Molnimplementeringsteam använder metoderna Migrate och Innovate för att upprätta skalbara processer för att påskynda implementeringen. När implementeringen är klar överförs troligen ägarskapet för arbetsbelastningar till ett molndriftsteam som använder metoden Hantera för att vägleda driftshanteringen. Båda teamen bör känna sig bekväma med att använda Microsoft Azure Well-Architected Framework för att fatta detaljerade arkitektoniska beslut som påverkar de arbetsbelastningar som de stöder. Båda teamen bör informeras om ändringar i landningszoner och miljöer. Båda teamen kan ibland bidra till landningszonfunktioner.
• Tillgångar: Tillgångar är vanligtvis molndriftsteamets ansvar. Teamet använder baslinjen för hantering i metoden Hantera för att vägleda beslut om driftshantering. Den bör också använda Azure Advisor och Azure Well-Architected Framework för att göra detaljerade resurs- och arkitekturändringar som krävs för att uppfylla driftskraven.

Varianter av ansvarstagande

• Enskild miljö: När ett företag bara behöver en miljö krävs vanligtvis inte en CCoE.
• Enskild landningszon: Om en miljö bara har en enda landningszon kan styrnings- och plattformsfunktionerna förmodligen kombineras till ett team.
• Enskild arbetsbelastning: Vissa företag behöver bara en arbetsbelastning, eller ett fåtal arbetsbelastningar, i en enda landningszon och en enda miljö. I dessa fall behövs det inte mycket ansvarsfördelning mellan styrnings-, plattforms- och driftteam.

Vanliga arbetsbelastnings- och ansvarsexempel

Följande exempel illustrerar portföljhierarkin.

COTS-arbetsbelastningar

Traditionellt har företag prioriterat cots-programvarulösningar (commercial-off-the-shelf) för att driva affärsprocesser. Dessa lösningar installeras, konfigureras och drivs sedan. Det sker små ändringar i lösningsarkitekturen efter konfigurationen.

I dessa scenarier avslutas alla molnimplementeringar av COTS-lösningar med en övergång till ett molndriftsteam. Molndriftsteamet blir sedan teknisk ägare för programvaran och förutsätter ansvar för att hantera konfiguration, kostnad, korrigeringscykler och andra operativa behov.

Dessa arbetsbelastningar omfattar redovisningspaket, logistikprogramvara eller branschspecifika lösningar. I Microsofts terminologi kallas leverantörerna av dessa paket oberoende programvaruleverantörer (ISV:er). Många ISV:er erbjuder en tjänst för att distribuera och underhålla en instans av deras programvarupaket i dina prenumerationer. De kan också erbjuda en version av programvarupaketet som körs i en egen molnbaserad miljö, vilket ger en plattform som en tjänst (PaaS) alternativ till arbetsbelastningen.

Förutom PaaS-erbjudanden ansvarar molndriftsteamen för att säkerställa grundläggande krav på driftsefterlevnad för dessa arbetsbelastningar. Ett molndriftsteam bör samarbeta med molnstyrningsteamet för att anpassa kostnader, prestanda och andra arkitekturpelare.

Under utveckling med aktiva revisioner

När en COTS-lösning eller Ett PaaS-erbjudande inte är anpassat till affärsbehovet, eller om det inte finns någon lösning, skapar företag egenutvecklade arbetsbelastningar. Normalt använder bara en liten del av IT-portföljen den här arbetsbelastningsmetoden. Men dessa arbetsbelastningar tenderar att driva en oproportionerligt hög andel av IT:s bidrag till affärsresultat, särskilt resultat relaterade till nya intäktsströmmar. Dessa arbetsbelastningar brukar mappas väl till nya innovationsidéer.

Med tanke på olika rörelser som är rotade i agila metoder och DevOps-metoder gynnar dessa arbetsbelastningar en affärs-/DevOps-anpassning framför traditionell IT-hantering. För dessa arbetsbelastningar kanske det inte finns någon överlämning till molndriftsteamet på flera år. I dessa fall fungerar utvecklingsteamet som teknisk ägare av arbetsbelastningen.

På grund av omfattande tids- och kapitalbegränsningar är anpassade utvecklingsalternativ ofta begränsade till värdefulla affärsmöjligheter. Vanliga exempel är programinnovationer, djupdataanalys eller verksamhetskritiska affärsfunktioner.

Avbrott/korrigering eller solnedgångsutveckling

När en egenutvecklad arbetsbelastning når toppmognad kan utvecklingsteamet omtilldelas till andra projekt. I dessa fall övergår tekniskt ägande vanligtvis till ett molndriftsteam. När det finns ett behov av små korrigeringar ber driftsteamet utvecklarna att lösa felet.

I vissa fall flyttas utvecklingsteamet till ett projekt som så småningom kommer att ersätta den aktuella arbetsbelastningen. Alternativt kan teamet gå vidare eftersom affärsmöjligheten som stöds av arbetsbelastningen håller på att fasas ut. I dessa solnedgångsscenarier fungerar molndriftsteamet som teknisk ägare tills arbetsbelastningen inte längre behövs.

I båda scenarierna fungerar molndriftsteamet vanligtvis som långsiktig teknisk ägare och beslutsfattare. Det teamet kommer sannolikt att värva programutvecklare när driftsändringar kräver betydande arkitekturändringar.

Verksamhetskritiska arbetsbelastningar

I varje företag är några arbetsbelastningar för viktiga för företaget för att de ska kunna misslyckas. Med dessa verksamhetskritiska arbetsbelastningar finns det vanligtvis drift- och utvecklingsägare med olika ansvarsnivåer. Dessa team bör anpassa driftsändringar och arkitekturändringar för att minimera störningar i produktionslösningen.

Dessa scenarier kräver starkt fokus på ansvarsfördelning. Driftteamet har vanligtvis ansvar för dagliga driftsändringar i produktionsmiljön. När dessa driftändringar kräver en arkitekturändring slutförs de av utvecklings- eller implementeringsteamet i en icke-produktionsmiljö innan driftteamet tillämpar ändringarna i produktionen.

Exempel på verksamhetskritiska arbetsbelastningar med en obligatorisk uppdelning av uppgifter är arbetsbelastningar som SAP, Oracle eller andra ERP-lösningar (Enterprise Resource Planning), som omfattar flera affärsenheter i företaget.

Anpassning av strategiportföljen

Det är viktigt att förstå de strategiska målen för molnimplementeringsarbetet och anpassa portföljen för att stödja den omvandlingen. Några vanliga typer av strategisk portföljjustering hjälper dig att forma strukturen i portföljhierarkin. Följande avsnitt innehåller exempel på portföljjusteringen och effekten på portföljhierarkin.

Innovations- eller utvecklingsledd portfölj

Vissa företag, särskilt snabbväxande nystartade företag, har en högre procentandel anpassade utvecklingsprojekt än genomsnittet. I utvecklingsintensiva portföljer komprimeras ofta miljön, landningszonen och arbetsbelastningarna, så det kan finnas specifika miljöer för specifika arbetsbelastningar. Resultatet är ett 1:1-förhållande mellan miljö, landningszon och arbetsbelastning.

Eftersom miljön är värd för anpassade lösningar kan DevOps-pipelinen och rapportering på programnivå ersätta behovet av drifts- och styrningsfunktioner. Dessa kunder kommer sannolikt att minska fokus på åtgärder, styrning eller andra stödjande roller. En starkare betoning på ansvarsområdena för molnimplementerings- och molnautomatiseringsteamen är också typisk.

Portföljjustering: IT-portföljen kommer sannolikt att fokusera på arbetsbelastningar och arbetsbelastningsägare för att driva kritiska arkitekturbeslut. Dessa team kommer sannolikt att hitta mer värde i Azure Well-Architected Framework-vägledningen under implementerings- och driftsaktiviteter.

Gränsdefinitioner: De logiska gränserna, även på företagsnivå, kommer sannolikt att fokusera på segmentering av produktions- och icke-produktionsmiljöer. Det kan också finnas en tydlig segmentering mellan produkter i företagets programvaruportfölj. Ibland kan det också finnas segmentering mellan utveckling och värdbaserade kundinstanser.

Verksamhetsledd portfölj

Multinationella företagsorganisationer med mer etablerade IT-driftsteam har vanligtvis ett starkare fokus på styrning och drift än utveckling. I dessa organisationer anpassas en högre procentandel av arbetsbelastningarna vanligtvis till COTS- eller break/fix-kategorierna, som underhålls av tekniska ägare inom molndriftsteamet.

Portföljjustering: IT-portföljen kommer att vara arbetsbelastningsjusterad, men dessa arbetsbelastningar justeras sedan efter driftenheter eller affärsenheter. Det kan också finnas organisation kring finansieringsmodeller, bransch eller andra affärssegmenteringskrav.

Gränsdefinitioner: Landningszoner grupperar sannolikt program i programarketyper för att behålla liknande åtgärder i en liknande segmentering. Miljöer kommer sannolikt att referera till fysiska konstruktioner som datacenter, nation, molnleverantörsregion eller andra operativa organisationsstandarder.

Migreringsledd portfölj

På samma sätt som med verksamhetsledda portföljer baseras en portfölj som till stor del bygger på migrering på specifika affärsdrivande faktorer som ledde till migreringen av befintliga tillgångar. Vanligtvis är datacentret den största faktorn i dessa drivrutiner.

Portföljjustering: IT-portföljen kan vara arbetsbelastningsjusterad, men det är mer sannolikt att tillgången är justerad. Om övergången till IT-drift har skett i företagets historik kanske många aktiva tillgångar inte enkelt mappas till en finansierad arbetsbelastning. I dessa fall kanske många tillgångar inte har en definierad arbetsbelastning eller rensar arbetsbelastningsägaren förrän sent i migreringsprocessen.

Gränsdefinitioner: Landningszoner kommer sannolikt att gruppera program i gränser som återspeglar lokal segmentering. Även om det inte är bästa praxis matchar miljöer ofta det lokala datacentrets namn och landningszoner som representerar nätverkssegmenteringsmetoder. Det är en bättre praxis att följa segmentering som ligger närmare en verksamhetsledd portfölj.

Styrningsledd portfölj

Anpassningen till styrningsteamen bör ske så tidigt som möjligt. Med styrningsmetoder och verktyg för molnstyrning kan portföljer och miljögränser bäst balansera behovet av innovation, drift och migrering.

Portföljjustering: Styrningsledda portföljer brukar innehålla datapunkter som samlar in information om innovation och drift, till exempel arbetsbelastning, driftägare, dataklassificering och driftskritiskhet. Dessa datapunkter skapar en väl avrundad vy över portföljen.

Gränsdefinitioner: Gränser i en styrningsledd portfölj tenderar att gynna verksamheten framför innovation, samtidigt som man använder en hanteringsgruppdriven hierarki som mappar till kriterier för affärsenheter och utvecklingsmiljöer. På varje nivå i hierarkin kan en molnstyrningsgräns ha olika grader av principtillämpning för att möjliggöra utveckling och kreativ flexibilitet. Samtidigt kan krav i produktionsklass tillämpas på produktionsprenumerationer för att säkerställa uppdelning av uppgifter och konsekventa åtgärder.

Nästa steg

Lär dig hur Azure-produkter stöder portföljhierarkin.