Portföljhierarki

För att förstå hur en portfölj av 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 team för att uppfylla förväntningarna för varje nivå. I den här artikeln kallas varje nivå i hierarkin även för ett område.

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 företagsintressent och en 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 hanteringsteam för delad drift eller ett molndriftsteam. När antalet arbetsbelastningar ökar blir rollerna (angivna eller underförstådda) mer komplexa och matriserade.

Arbetsbelastningar och deras stödtillgå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.

Även om villkoren kan variera omfattar alla IT-lösningar tillgångar och arbetsbelastningar:

• Resurs: Den minsta möjliga tekniska enheten som stöder en arbetsbörda eller lösning.
• Arbetsbelastning: Den minsta IT-enheten 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.

Första gången du distribuerar din arbetsbörda kan arbetsbördan och dess tillgångar möjligen vara det enda definierade området. De andra lagren kan uttryckligen definieras 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 tillhandahåller arbetsbelastningar med nödvändiga grundläggande verktyg eller delade VVS 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.
• Platform Foundation: Den här organisationskonstruktionen centraliserar grundläggande lösningar och säkerställer 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.
• Portfolio: Genom en tekniklins är portföljen en samling arbetsbelastningar, tillgångar och stödresurser som sträcker sig över 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 täcker dessa två linser in 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.

Obs

De team som nämns i följande lista kan vara virtuella team eller individer. För vissa varianter av den här hierarkin kan några av de ansvariga teamen sammanslås, enligt beskrivningen senare i ansvarighetsvarianterna.

• Portfolio: Molnstrategiteamet och CCoE (Cloud Center of Excellence) använder Strategy och Plan-metoder 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 skyddsmekanismer som säkerställer konsekvens i varje miljö i enlighet med metoden Govern. 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 ändring av regler. Molnstyrningsteamet bör också informeras om förloppet med arbetsbelastning och tillgångsimplementering.
• Landningszoner och molnfundament: Molnplattformsteamet ansvarar för att utveckla landningszoner och plattformsverktyg som stöder implementering. 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 Ready för att vägleda implementeringen. Båda teamen bör informeras om förloppet med arbetsbelastningsimplementering och eventuella ändringar i företaget eller miljön.
• arbetsbelastningar: implementering sker på nivå av arbetsbelastning. Moln-adoptionsteam använder Migrate och Innovate metodik för att upprätta skalbara processer för att påskynda adoptionen. När implementeringen är klar överförs ägarskapet för arbetsbelastningar sannolikt till ett molndriftsteam som använder metoden Hantera som vägledning för driftshantering. 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 funktioner i landningszonen.
• Tillgångar: Tillgångar är vanligtvis molndriftsteamets ansvar. Det teamet använder hanteringsbaslinjen i Hantera metod för att vägleda beslut om drifthantering. 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 ansvarsskyldighet

• 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 sannolikt kombineras till ett team.
• Enskild arbetsbelastning: Vissa företag behöver bara en arbetsbelastning, eller några arbetsbelastningar, i en enda landningszon och en enda miljö. I dessa fall finns det lite behov av en uppdelning av uppgifter mellan styrnings-, plattforms- och driftteam.

Vanliga arbetsbelastnings- och ansvarsexempel

Följande exempel illustrerar portföljhierarki.

COTS-arbetsbelastningar

Traditionellt har företag föredragit kommersiella standardprogramvarulösningar (COTS, commercial-off-the-shelf) för att stödja affärsprocesser. Dessa lösningar installeras, konfigureras och drivs sedan. Det finns få ändringar i lösningsarkitekturen efter konfigurationen.

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

Dessa arbetsbelastningar omfattar redovisningspaket, logistikprogramvara eller branschspecifika lösningar. I Microsofts terminologi kallas leverantörerna för 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 sin egen molnbaserade miljö, vilket ger ett paaS-alternativ (plattform som en tjänst) som alternativ till arbetsbelastningen.

Förutom PaaS-erbjudanden ansvarar molndriftsteamen för att säkerställa grundläggande krav på driftefterlevnad 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 anpassade arbetsbelastningar. Vanligtvis använder bara en liten andel 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 tenderar att mappas väl till nya innovationsförslag.

Med tanke på olika rörelser som är rotade i agila metoder och DevOps-metoder gynnar dessa arbetsbelastningar en affärs-/DevOps-anpassning jämfört med 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.

Reparation/åtgärd eller avslutad utveckling

När en skräddarsydd arbetsbelastning når sin högsta mognad kan utvecklingsteamet omfördelas till andra projekt. I dessa fall övergår tekniskt ägande vanligtvis till ett molndriftsteam. När det finns ett behov av små korrigeringar kommer driftteamet att anlita utvecklare för att lösa felet.

I vissa fall flyttas utvecklingsteamet till ett projekt som så småningom ersätter 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 arkitektoniska ändringar.

Verksamhetskritiska arbetsbelastningar

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

Dessa scenarier kräver ett starkt fokus på ansvarsfördelning. Driftteamet kommer vanligtvis att ansvara 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 på produktionen.

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

Anpassning av strategiportfölj

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 till 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å typiskt.

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 vägledningen för Azure Well-Architected Framework 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ön. Det kan också finnas en tydlig segmentering mellan produkter i företagets programvaruportfölj. Ibland kan det också finnas segmentering mellan utvecklings- 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 arbetsbelastningar vanligtvis till kategorierna COTS eller break/fix, som underhålls av tekniska ägare inom molndriftsteamet.

Portföljjustering: IT-portföljen kommer att justeras efter arbetsbelastning, men dessa arbetsbelastningar justeras sedan i enlighet med operativa enheter eller affärsenheter. Det kan också finnas organisation kring finansieringsmodeller, bransch eller andra krav på affärssegmentering.

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.

Migrationsdriven portfölj

På samma sätt som verksamhetsledda portföljer baseras en portfölj som till stor del bygger på migrering på specifika affärsdrivande faktorer som ledde till migrering 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 tillgångsjusterad. Om övergångar till IT-drift har skett i företagets historia kanske många aktiva tillgångar inte enkelt kopplas till finansierade uppgifter. I dessa fall kan många tillgångar sakna en definierad arbetsbelastning eller tydlig ägare av arbetsbelastningen förrän sent i migreringsprocessen.

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

Portfölj styrd av förvaltning

Anpassningen till styrningsteamen bör ske så tidigt som möjligt. Genom styrningsmetoder och verktyg för molnstyrning kan portföljer och miljögränser bäst balansera behoven av innovation, åtgärder och migreringsarbete.

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

gränsdefinitioner: gränser i en styrningsledd portfölj tenderar att gynna åtgärder framför innovation, samtidigt som en hanteringsgruppdriven hierarki som mappar till kriterier för affärsenheter och utvecklingsmiljöer används. 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 på produktionskvalitet 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.