Administrasjon av applikasjonsportefølje - Application portfolio management

IT Application Portfolio Management ( APM ) er en praksis som har oppstått i midten til store organisasjoner for informasjonsteknologi (IT) siden midten av 1990-tallet. Applikasjonsporteføljestyring prøver å bruke leksjonene fra økonomisk porteføljestyring for å rettferdiggjøre og måle de økonomiske fordelene ved hver applikasjon i forhold til kostnadene ved applikasjonens vedlikehold og drift.

Utvikling av praksis

Sannsynligvis var den tidligste omtalen av Applications Portfolio i Cyrus Gibson og Richard Nolans HBR-artikkel "Managing the Four Stages of EDP Growth" i 1974.

Gibson og Nolan antydet at bedriftens forståelse og vellykkede bruk av IT "vokser" i forutsigbare stadier, og en gitt virksomhets fremgang gjennom trinnene kan måles ved å observere applikasjonsporteføljen, brukerbevissthet, IT-styringspraksis og IT-ressurser innenfor konteksten av en analyse av de samlede IT-utgiftene.

Nolan, Norton & Co. var banebrytende for bruken av disse konseptene i praksis med studier ved blant annet DuPont, Deere, Union Carbide, IBM og Merrill Lynch. I disse "Stage Assessments" målte de i hvilken grad hver applikasjon støttet eller "dekket" hver forretningsfunksjon eller prosess, og brukte på applikasjonen, funksjonelle kvaliteter og tekniske kvaliteter. Disse tiltakene ga en helhetlig oversikt over anvendelsen av IT i virksomheten, styrker og svakheter og et veikart for forbedring.

APM ble bredt adoptert på slutten av 1980-tallet og gjennom 1990-tallet da organisasjoner begynte å løse trusselen om søknadsfeil da datoen endret seg til år 2000 (en trussel som ble kjent som år 2000 eller Y2K). I løpet av denne tiden utviklet titusenvis av IT-organisasjoner over hele verden en omfattende liste over applikasjonene sine, med informasjon om hver applikasjon.

I mange organisasjoner ble verdien av å utvikle denne listen utfordret av bedriftsledere som er bekymret for kostnadene ved å håndtere Y2K- risikoen. I noen organisasjoner ble forestillingen om å administrere porteføljen presentert for forretningsfolk med ansvar for informasjonsteknologibudsjettet som en fordel ved å utføre arbeidet, utover å håndtere risikoen for applikasjonsfeil .

Det er to hovedkategorier av applikasjonsporteføljestyringsløsninger, vanligvis referert til som 'Top Down' og 'Bottom Up' tilnærminger. Det første behovet i enhver organisasjon er å forstå hvilke applikasjoner som finnes og deres hovedegenskaper (for eksempel fleksibilitet, vedlikehold, eier osv.), Vanligvis referert til som "Inventory". En annen tilnærming til APM er å få en detaljert forståelse av applikasjonene i porteføljen ved å analysere applikasjonens kildekode og tilhørende komponenter i en depotdatabase (dvs. "Bottom Up"). Application mining verktøy, nå markedsført som APM verktøy, støtter denne tilnærmingen.

Hundrevis av verktøy er tilgjengelige for å støtte 'Top Down' -tilnærmingen. Dette er ikke overraskende, fordi hoveddelen av oppgaven er å samle inn riktig informasjon; selve vedlikeholdet og lagringen av informasjonen kan implementeres relativt enkelt. Av den grunn omgår mange organisasjoner kommersielle verktøy og bruker Microsoft Excel til å lagre lagerdata. Imidlertid, hvis beholdningen blir kompleks, kan Excel bli tungvint å vedlikeholde. Automatisk oppdatering av dataene støttes ikke godt av en Excel-basert løsning. Endelig er en slik lagerløsning helt atskilt fra forståelsesbehovet 'Bottom Up'.

Business case for APM

I følge Forrester Research , "For IT-driftsbudsjetter bruker bedrifter to tredjedeler eller mer på løpende drift og vedlikehold.".

Det er vanlig å finne organisasjoner som har flere systemer som utfører samme funksjon. Det kan være mange grunner til denne dupliseringen, inkludert den tidligere fremtredende delen av databehandling, applikasjonssiloer fra 1970- og 1980-tallet, spredning av fusjoner og oppkjøp av selskaper og abortforsøk på å ta i bruk nye verktøy. Uansett duplisering vedlikeholdes hver applikasjon separat og oppgraderes med jevne mellomrom, og redundansen øker kompleksiteten og kostnadene.

Med et stort flertall av utgiftene til å administrere eksisterende IT-applikasjoner, er gjennomsiktigheten i den nåværende beholdningen av applikasjoner og ressursforbruk et hovedmål for Application Portfolio Management. Dette gjør det mulig for bedrifter å: 1) identifisere og eliminere delvis og fullstendig overflødige applikasjoner, 2) kvantifisere tilstanden til applikasjoner når det gjelder stabilitet, kvalitet og vedlikeholdsevne, 3) kvantifisere forretningsverdien / effekten av applikasjoner og den relative betydningen av hver applikasjon til virksomheten, 4) tildele ressurser i henhold til applikasjonenes tilstand og betydning i sammenheng med forretningsprioriteringer.

Åpenhet hjelper også til strategisk planleggingsarbeid og sprer virksomhet / IT-konflikt, for når bedriftsledere forstår hvordan applikasjoner støtter deres viktigste forretningsfunksjoner, og virkningen av utfall og dårlig kvalitet, blir samtaler vekk fra å skylde på IT for store kostnader og mot hvordan du best kan bruke dyrebare ressurser for å støtte bedriftens prioriteringer.

Portefølje

Med ideer fra forvaltning av investeringsporteføljer samler APM-utøvere informasjon om hver applikasjon som brukes i en bedrift eller organisasjon, inkludert kostnadene for å bygge og vedlikeholde applikasjonen, den produserte forretningsverdien, kvaliteten på applikasjonen og forventet levetid. Ved hjelp av denne informasjonen er porteføljeforvalteren i stand til å gi detaljerte rapporter om ytelsen til IT-infrastrukturen i forhold til kostnadene som eies og den leverte forretningsverdien.

Definisjon av en applikasjon

I applikasjonsporteføljestyring er definisjonen av en applikasjon en kritisk komponent. Mange tjenesteleverandører hjelper organisasjoner med å lage sin egen definisjon på grunn av de ofte omstridte resultatene som kommer fra disse definisjonene.

  • Applikasjonsprogramvare - En kjørbar programvarekomponent eller tett sammenkoblet sett med kjørbare programvarekomponenter (en eller flere), distribuert sammen, som leverer noen eller en rekke trinn som trengs for å opprette, oppdatere, administrere, beregne eller vise informasjon for en bestemt virksomhet hensikt. For å kunne telles må hver komponent ikke være medlem av en annen applikasjon.
  • Programvarekomponent - Et kjørbart sett med datamaskininstruksjoner som finnes i en enkelt distribusjonsbeholder på en slik måte at den ikke kan brytes fra hverandre. Eksempler inkluderer et Dynamic Link Library , en ASP- webside og et kommandolinjeprogram " EXE ". En zip-fil kan inneholde null eller flere programvarekomponenter fordi det er lett å bryte dem ned (ved å pakke ut ZIP-arkivet).

Programvareapplikasjon og programvarekomponent er tekniske begreper som brukes til å beskrive en spesifikk forekomst av klassen av programvare for IT-porteføljestyring . Se applikasjonsprogramvare for en definisjon for ikke-utøvere av IT Management eller Enterprise Architecture.

Kunsten og praksisen med porteføljestyring av programvare krever en ganske detaljert og spesifikk definisjon av et program for å lage en katalog med applikasjoner installert i en organisasjon.

Kravene til en definisjon for en applikasjon

Definisjonen av en applikasjon har følgende behov i forbindelse med applikasjonsporteføljestyring:

  • Det må være enkelt for forretningsmedlemmer å forklare, forstå og anvende.
  • Det må være fornuftig med utvikling, drift og prosjektledelse i IT-gruppene.
  • Det må være nyttig som input til en kompleks funksjon hvis produksjon er den totale kostnaden for porteføljen. Det er med andre ord mange faktorer som fører til den totale kostnaden for en IT-portefølje. Det store antallet søknader er en av disse faktorene. Derfor må definisjonen av en applikasjon være nyttig i den beregningen.
  • Det må være nyttig for medlemmene av Enterprise Architecture-teamet som prøver å bedømme et prosjekt med hensyn til deres mål for porteføljeoptimalisering og forenkling.
  • Det må klart definere grensene for en applikasjon, slik at en person som arbeider med en målbar 'porteføljeforenklingsaktivitet' ikke bare kan omdefinere grensene for to eksisterende applikasjoner på en slik måte at de kaller dem en enkelt applikasjon.

Mange organisasjoner vil redressere definisjonen av en applikasjon i sammenheng med deres IT-porteføljestyring og styringspraksis. Av den grunn bør denne definisjonen betraktes som en arbeidsstart.

Eksempler

Definisjonen av en applikasjon kan være vanskelig å formidle tydelig. I en IT-organisasjon kan det være subtile forskjeller i definisjonen blant team og til og med innen ett IT-team. Det hjelper med å illustrere definisjonen ved å gi eksempler. Avsnittet nedenfor gir noen eksempler på ting som er applikasjoner, ting som ikke er applikasjoner, og ting som inneholder to eller flere applikasjoner.

Inkluderinger

Etter denne definisjonen er følgende applikasjoner:

  • Et endepunkt for nettjeneste som presenterer tre webtjenester: InvoiceCreate, InvoiceSearch og InvoiceDetailGet
  • En tjenesteorientert forretningsapplikasjon ( SOBA ) som presenterer et brukergrensesnitt for å lage fakturaer, og som snur og kaller InvoiceCreate- tjenesten. (merk at selve tjenesten er en annen applikasjon).
  • En mobil som er publisert i en bedrift søknad butikken og dermed distribuert til ansatte eies eller drives bærbare enheter muliggjør godkjent tilgang til data og tjenester.
  • Et eldre system som består av en rik klient, et serverbasert mellomnivå og en database, som alle er tett koblet. (f.eks. vil endringer i en meget sannsynlig utløse endringer i en annen).
  • Et nettsidepubliseringssystem som henter data fra en database og publiserer det til et HTML- format som et underside på en offentlig URL.
  • En database som presenterer data til en Microsoft Excel- arbeidsbok som spør informasjonen om layout og beregninger. Dette er interessant fordi selve databasen er et program, med mindre databasen allerede er inkludert i et annet program (som et eldre system).
  • Et Excel-regneark som inneholder et sammenhengende sett med gjenbrukbare makroer som gir forretningsverdi. Regnearket i seg selv utgjør en distribusjonsbeholder for applikasjonen (som en TAR- eller CAB- fil).
  • Et sett med ASP- eller PHP- nettsider som fungerer sammen med hverandre for å levere opplevelsen og logikken til et webapplikasjon. Det er fullt mulig at et underside vil kvalifisere som en egen applikasjon under denne definisjonen hvis koblingen er løs.
  • Et endepunkt for nettjeneste etablert for maskin-til-maskin-kommunikasjon (ikke for menneskelig interaksjon), men som rasjonelt kan forstås å representere et eller flere nyttige trinn i en forretningsprosess.

Unntak

Følgende er ikke applikasjoner:

  • Et HTML-nettsted.
  • En database som inneholder data, men som ikke er en del av noen serie trinn for å levere forretningsverdi ved hjelp av disse dataene.
  • En webtjeneste som strukturelt er ute av stand til å være en del av et sett med trinn som gir verdi. For eksempel en webtjeneste som krever innkommende data som bryter delt skjema.
  • Et frittstående batch-skript som sammenligner innholdet i to databaser ved å ringe til hver og deretter sender e-post til et overvåkingsalias hvis det blir lagt merke til dataavvik. I dette tilfellet er det sannsynlig at batchskriptet er tett sammenkoblet med minst en av de to databasene, og derfor bør det inkluderes i applikasjonsgrensen som inneholder databasen som den er tettest koblet til.

Kompositter

Følgende er mange applikasjoner:

  • En sammensatt SOA- applikasjon sammensatt av et sett med gjenbrukbare tjenester og et brukergrensesnitt som utnytter disse tjenestene. Det er minst to applikasjoner her (brukergrensesnittet og en eller flere tjenestekomponenter). Hver tjeneste regnes ikke som en applikasjon.
  • En eldre klient-server-app som skriver til en database for å lagre data og et Excel-regneark som bruker makroer til å lese data fra databasen for å presentere en rapport. Det er TO apper i dette eksemplet. Databasen tilhører helt klart den eldre appen fordi den ble utviklet med den, levert med den og er tett koblet til den. Dette gjelder selv om det eldre systemet bruker de samme lagrede prosedyrene som Excel-regnearket.

Metoder og tiltak for vurdering av søknader

Det er mange populære økonomiske tiltak, og enda flere beregninger av forskjellige (ikke-økonomiske eller komplekse) typer som brukes til å evaluere applikasjoner eller informasjonssystemer.

Avkastning på investeringen (ROI)

Return on Investment er en av de mest populære målingene og resultatmålingene som brukes i forretningsanalyser. ROI-analyse (når den brukes riktig) er et kraftig verktøy for å evaluere eksisterende informasjonssystemer og ta informerte beslutninger om programvareanskaffelser og andre prosjekter. ROI er imidlertid en beregning designet for et bestemt formål - for å evaluere lønnsomhet eller økonomisk effektivitet. Det kan ikke pålitelig erstatte mange andre økonomiske beregninger når det gjelder å gi et samlet økonomisk bilde av informasjonsløsningen. Forsøkene på å bruke avkastning som eneste eller viktigste beregning for beslutningstaking angående informasjonssystemer kan ikke være produktive. Det kan være aktuelt i et svært begrenset antall saker / prosjekter. ROI er et økonomisk tiltak og gir ikke informasjon om effektiviteten eller effektiviteten til informasjonssystemene.

Økonomisk merverdi (EVA)

Et mål på selskapets økonomiske resultater basert på gjenværende formue beregnet ved å trekke kapitalkostnader fra driftsresultatet (justert for skatt på kontantbasis). (Også referert til som "økonomisk fortjeneste".)

Formel = Netto driftsresultat etter skatt (NOPAT) - (Kapital * Kapitalkostnad)

Totale eierkostnader (TCO)

Total eierkostnad er en måte å beregne hva applikasjonen vil koste over en definert tidsperiode. I en TCO-modell blir kostnadene for maskinvare, programvare og arbeid fanget opp og organisert i de forskjellige programmets livssyklusstadier. En grundig TCO-modell hjelper ledelsen med å forstå den virkelige kostnaden for applikasjonen når den prøver å måle bygge-, kjøre- / støtte- og indirekte kostnader. Mange store konsulentselskaper har definert strategier for å bygge en komplett TCO-modell.

Total økonomisk innvirkning (TEI)

TEI ble utviklet av Forrester Research Inc. Forrester hevder TEI ser systematisk på potensielle effekter av teknologiinvesteringer i fire dimensjoner: kostnad - innvirkning på IT; fordeler - innvirkning på virksomheten; fleksibilitet - fremtidige alternativer skapt av investeringen; risiko - usikkerhet.

Forretningsverdi av IT (ITBV)

ITBV-programmet ble utviklet av Intel Corporation i 2002. Programmet bruker et sett med økonomiske målinger av forretningsverdien som kalles Business Value Dials (Indicators). Det er et flerdimensjonalt program, inkludert en virksomhetskomponent, og er relativt enkelt å implementere.

Anvendt informasjonsøkonomi (AIE)

AIE er en beslutningsanalysemetode utviklet av Hubbard Decision Research. AIE hevder å være "den første virkelig vitenskapelige og teoretisk sunne metoden" som bygger på flere metoder fra beslutningsteori og risikoanalyse, inkludert bruk av Monte Carlo-metoder. AIE brukes ikke ofte på grunn av kompleksiteten.

Referanser