module and plugin to add google adsense to joomla based websites
Applicatieportfoliomanagement volgens Arjan Juurlink
Gepubliceerd in Informatiemanagement Afdrukken

applicatieportfoliomanagement

Arjan Juurlink beschrijft in zijn boek Applicatieportfoliomanagement voor IT-complexiteitsreductie het belang van hebben van een helder inzicht in het applicatielandschap en het vastleggen van de relevante gegevens in een zgn. Applicatie Inventory. In het onderstaande wordt aangegeven wat volgens Juurlink de belangrijke aspecten zijn van het applicatie en geeft inzicht in de de belangrijkste begrippen en processen die een rol spelen bij het reduceren van complexiteit in het applicatie- en infrastructuurlandschap.

IT (Service)-portfoliomanagement: paraplubegrip voor alle activiteiten die zich bezighouden met het in lijn brengen van de IT-voorzieningen en de strategische doelstellingen van de organisatie. Het gaat om het besturen van de samenhang van de portfolio van IT-diensten met de strategie van de organisatie. Doel is door te sturen op samenhang in de portefeuille van IT-services de effectiviteit van de inzet van IT toe te laten nemen.

In het ideale geval is een organisatie in staat om naar IT-voorzieningen te kijken als onderdeel van business-services. Applicaties zijn het meest zichtbare deel van een business-service en worden door de gebruiker vaak als een geheel gezien met gegevens en infrastructuur. Omdat een SLA de dienstverlening vaak beschrijft in relatie tot het (complexe) applicatielandschap, gebruikt Arjan Juurlink het begrip applicatieportfoliomanagement als hulpmiddel voor het reduceren van complexiteit in het applicatie- en infrastructuurlandschap.

Voor het kunnen reduceren van de complexiteit in het applicatie- en infrastructuurlandschap is het volgens Juurlink noodzakelijk een Applicatie Inventory ('single-source-of-truth') aan te leggen, waarin minimaal voor elke applicatie de kosten, het belang en het risico (incl. de verwachte ontwikkeling van alledrie de aspecten tot het eind van de levenscyclus). Juurlink waarschuwt voor het gevaar om té veel zaken vast te leggen en pleit voor het vastleggen van een beperkt aantal gegevens voor het gehele landschap. Op basis van need-to-know is het mogelijk later alsnog meer informatie te inventariseren. Hij onderscheidt drie categorieën informatie:

  1. Analysegegevens: gegevens die nodig zijn om het applicatielandschap in te delen in categorieëen. Het is van belang deze groep gegevens zo beperkt mogelijk te houden, omdat deze informatie voor het gehele landschap moet worden vastgesteld.

  2. Rapportagegegevens: wanneer de eigenaar van een groep applicaties wil kunnen sturen op de afhankelijkheden en op de voortgang van de migratie naar de doelarchitectuur, zijn overzichten nodig op basis van doorsneden en invalshoeken (zoals proces, informatie- of productdomein, ontwikkelomgeving en soort technologie), om de voortgang (in 'standgegevens') te kunnen volgen.

  3. Executiegegevens: (tijdelijke) gegevens die nodig zijn om te weten wanneer een applicatie daadwerkelijk wordt gemigreerd, zoals bijvoorbeeld aantallen logische of fysieke database-instanties. Het verzamelen van deze gegevens vindt plaats op basis van need-to-know en alleen voor applicaties die deel uitmaken van een migratie.

Juurlink clustert de eigenschappen van een applicatie in zeven categorieën:

  1. Applicatiegegevens: [ identificatie, naam, versie | service level | status | maatwerk/standaard | fase levenscyclus | client/server/beide | jaar in productie | datum laatste release | jaar end-of-life ]

  2. Functionele gegevens: [ relatie procesketen | relatie bedrijfsproces | belang voor bedrijfsproces | mate waarin proces wordt ondersteund | mate van gebruik (business events) | doelomgeving ja/nee | functionele kwaliteit ]

  3. Gebruiksgegevens: [ aantal gebruikers | gem. frequentie van gebruik | aantal installaties | aantal incidenten | performance | gebruikerstevredenheid | datakwaliteit | inleertijd ]

  4. Organisatiegegevens: [ businesseigenaar (eigenaar functionaliteit) | eigenaar applicatie | functioneel beheerteam | applicatiebeheerteam | aantal beheerders in organisatie | aantal beheerders buiten de organisatie ]

  5. Leveranciersgegevens: [ leveranciersnaam | productnaam | productversie | omvang leverancier | binnen/buitenlands ]

  6. Technische gegevens: [ hardwareplatform | operatingsystem | DBMS | aantal interfaces intern/extern | ontwikkelplatform | aantal regels code | middleware | doelomgeving ja/nee | technische kwaliteit ]

  7. Business-strategie: op welke wijze draagt applicatie bij aan de strategie?

Arjan Juurlink hanteert de volgende definities:

  1. Applicatie: eenheid van functionaliteit die van buitenaf autoriseerbaar is ten behoeve van een eindgebruiker. Een applicatie ondersteunt één of meer stappen uit een bedrijfsproces. Alles wat verdwijnt op het moment dat een applicatie wordt uitgezet, behoort tot deze applicatie.

  2. Component: een applicatie bestaat uit componenten, een component is ondeelbaar en draait op dezelfde technische stack (optelsom van functionaliteit, ontwikkelplatform, databaseplatform, middleware, operating system en hardware).

  3. Informatiesysteem: aantal applicaties die een bepaalde samenhang hebben (in termen van onderlinge verbindingen tussen applicaties, componenten en/of eindgebruikers).

Volgens Arjan Juurlink kunnen vijf soorten applicaties worden onderscheiden:

  1. End User-applicatie: applicaties die door eindgebruikers zélf zijn ontwikkeld (vaak op eigen werkplek, denk aan allerlei Excel-trucendozen)

  2. Image-applicaties: in verre mate gestandaardiseerde besturingssoftware en/of gebruikerssoftware (MS Office, internetbrowsers).

  3. Standaardkantoorapplicaties: standaarddiensten (meestal standaardpakketten) die een gebruiker kan bestellen via de IT-catalogus.

  4. SLA-applicaties: applicaties die niet standaard in de bestelcatalogus voorkomen, en meestal worden gebruikt ter ondersteuning van de (primaire) bedrijfsprocessen. Voor deze applicaties worden Service Level Agreements (SLA's) afgesloten met de (interne) leverancier, bijv. ten aanzien van beschikbaarheid, maximale tijd voor afhandeling van storingen. Het gaat meestal om uitgebreidere standaardpakketten, ERP-pakketten en specifieke maatwerkontwikkelingen.

  5. IT-for-IT applicaties: ontwikkel- en beheertools, 'tooling' om IT-diensten te maken en/of beheren.

Nadat de basisgegevens van het applicatielandschap zijn geïnventariseerd en geregistreerd, is het mogelijk applicaties te classificeren. Classificatie helpt bij het bepalen van migratiescenario's naar de doelarchitectuur of uitfasering. Arjan Juurlink noemt de volgende veelvoorkomende scenario's:

Arjan Juurlink beschrijft zijn boek beknopt ASL en BiSL, maar in relatie tot complexiteitreductie zijn vooral drie processen van belang:

  1. Applicatielifecyclemanagement : ASL-proces dat beslissingen faciliteert over investeringen in vernieuwing en onderhoud van een applicatie (gebaseerd op de levenscyclus van de applicatie).

  2. Applicatieportfoliomanagement: ASL-proces dat het applicatie- en infrastructuurlandschap optimaliseert voor de bedrijfsdoelstellingen.

  3. Planning en control: BiSL-proces wordt door Juurlink vertaalt naar projectportfoliomanagement dat zich bezig houdt met de coördinatie van projecten en programma's van een organisatie om de realisatie te optimaliseren, het risicoprofiel van de portfolio evenwichtig te houden en ervoor te zorgen dat projecten in lijn zijn met de strategie van de organisatie en binnen budgettaire grenzen wordt opgeleverd.

Volgens Juurlink bij het nemen van 'portfoliobeslissingen' gekeken worden naar de verdere - liefst gehele - levensduur van applicaties en de onderliggende infrastructuur. De lifecycle van functionaliteit wordt opgedeeld in drie categorieën:

  1. Doelapplicaties: applicaties die (al) deel uitmaken van de doelomgeving.

  2. Te migreren kernapplicaties: applicaties waarvan de functionaliteit nog niet in de doelomgeving is gemigreerd (maar dit moet nog wel gebeuren omdat deze applicaties nog zeker zo'n drie tot vijf jaar gebruikt moeten worden).

  3. Legacy applicaties: applicaties die nog binnen de planperiode (meestal 1 tot 3 jaar) gesaneerd zullen worden.

Zie ook:

Bron: Applicatieportfoliomanagement voor IT-complexiteitsreductie, Arjan Juurlink

Tags:
Laatst aangepast op maandag, 01 januari 2018 12:56