Application Services Library

Overzicht ASL-model

ASL (Application Services Library) is een procesraamwerk, ondersteund door Best Practices, dat de processen van het beheer, onderhoud en vernieuwing van informatiesystemen en applicaties beschrijft. Het biedt een handvat bij het verbeteren van organisaties, die applicatiebeheer uitvoeren. Door gebruik van best practices en diagnose-instrumenten, zoals zelfevaluaties, kan men pragmatisch aan de slag met het verbeteren van het applicatiebeheer.

ASL beschrijft de processen op uitvoerend (operationeel), sturend (tactisch) en richtinggevend (strategisch) niveau. Het kent zes clusters, met daarin processen.

ITIL is als beheermethodiek sterk gericht op het beheren van IT-infrastructuren, ASL legt de nadruk op applicatiebeheer, op de processen rond het beheren en onderhouden van software en de gegevensbanken. De ITIL-processen zijn voor een groot deel binnen ASL terug te vinden, met name in de hoek van de beheer-processen en de tactische processen. Eigen voor ASL is de nadruk op de ontwikkelcyclus (onderhoud / vernieuwing).

ASL is een Nederlandse standaard in het publieke domein, beschikbaar voor iedere organisatie, en wordt beheerd door een stichting, die wordt ondersteund door een aantal grote ICT-bedrijven.

Positie van ASL

Men onderscheidt in de ICT drie vormen van beheer (beheerdomeinen):

• Technisch Beheer (ITIL)

Richt zich op het beheer van de IT-infrastructuur en heeft ITIL als standaard. De IT-infrastructuur is een basis waarop applicaties kunnen draaien. Deze applicaties worden beheerd door Applicatiebeheer.

• Applicatiebeheer (ASL)

Onder dit beheer wordt verstaan het aanpassen van de applicatie naar aanleiding van geconstateerde fouten in de applicatie of veranderende technische of functionele eisen. Het gaat nadrukkelijk om bestaande applicaties en niet om nieuwbouw van applicaties. ASL is hiervoor de standaard. ASL is nieuwer dan en deels geïnspireerd door ITIL.

• Functioneel beheer (BiSL)

De applicaties worden gebruikt door de gebruikersorganisatie. Deze organisatie zal aan moeten geven aan welke eisen die applicatie moet voldoen en controleren of na een eventuele aanpassing deze applicatie inderdaad voldoet. Dit proces noemt men Functioneel Beheer en heeft als standaard BiSL.

ASL 2

In 2009 is ASL 2 geïntroduceerd, er is een aantal structurele veranderingen doorgevoerd ten opzichte van de voorgaande versie. Met name de sturende processen bevatten grote veranderingen. Zo is de continue dynamiek en het bijstellen van de besturingsstructuren onderdeel geworden van de processen. Daarbij zijn de onderwerpen, de stromen en de beschrijving van de processen bijna volledig veranderd. SLA beheer is contractbeheer geworden, het proces leveranciersmanagement is als nieuw proces erbij gekomen, kwaliteitsmanagement is verbreed en heeft functies van het beheersproces probleembeheer overgenomen. Kostenmanagement is financieel management geworden omdat er meer interactie is tussen de afnemers. De beheerprocessen zijn ook gewijzigd, met name de samenvoeging van beschikbaarheidsbeheer en capaciteitbeheer. Die zijn ondergebracht in het nieuwe proces operationeel beheer. Configuratiebeheer is algemener en eenduidiger geworden. Incidentbeheer is gebruiksondersteuning geworden aangezien er niet alleen na incidenten gereageerd wordt, maar ook proactief gecommuniceerd wordt. Het cluster onderhoud en vernieuwing heeft iets meer aandacht voor het werken in ketens. Organization cycle management bevat nu het proces Account & market definition, een samenvoeging vanuit de vorige versie van ASL. Supplier definition is een nieuw proces, en skills definition is capabilities definition geworden om het meer naar het organisatieniveau te brengen.

ASL-processen

ASL is een procesmodel. Dit houdt in dat de werkzaamheden in een bedrijf beschreven worden aan de hand van processen die niet noodzakelijkerwijs hoeven samen te vallen met afdelingen of personen met een bepaalde functie. Een proces omvat werkzaamheden die volgens het ASL-model bij elkaar horen. In de praktijk kan een afdeling meerdere processen uitvoeren en een proces kan door meerdere afdelingen uitgevoerd worden. ASL kent de volgende processen:

Beheerprocessen

Er zijn vijf beheerprocessen in ASL. Deze processen zijn belangrijk omdat ze het gebruik van de applicaties ondersteunen met zo weinig mogelijk middelen en zo weinig mogelijk applicatie-onderbrekingen. Al deze processen zijn ook gedefinieerd in ITIL maar omdat ze hier vanuit applicatiebeheer gedetailleerd zijn, kunnen de processen enigszins afwijken. De volgende beheerprocessen zijn te onderscheiden:

• incidentbeheer
• configuratiebeheer
• beschikbaarheidsbeheer
• capaciteitsbeheer
• continuïteitsbeheer

Onderhouds- en vernieuwingsprocessen

Men schat dat zo'n 80% van het werk binnen applicatiebeheer te maken heeft met onderhouds- en vernieuwingsprocessen. Omdat de bedrijfsprocessen die door applicaties ondersteund worden continu veranderen, moeten de applicaties meeveranderen. Voor elke verandering zullen de onderhouds- en vernieuwingsprocessen doorlopen moeten worden. In ITIL zijn deze processen niet terug te vinden. Het gaat om de volgende processen:

• Impactanalyse
• ontwerp
• realisatie
• test
• implementatie

Verbindende processen

De verbindende processen verbinden de hierboven genoemde beheersprocessen met de onderhouds- en vernieuwingsprocessen. Er zijn twee verbindende processen. Wijzigingsbeheer bepaalt de inhoud van releases en aan welke releases onderhouds- en vernieuwingsprocessen mogen werken. Programmabeheer en distributie controleert de status van applicatiecomponenten en bepaalt welke applicatiecomponenten door de beheersprocessen gebruikt mogen worden. Het gaat om de volgende processen:

• wijzigingsbeheer
• programmabeheer en distributie

Sturende processen

Sturing is noodzakelijk om de hierboven genoemde processen optimaal te doen verlopen. Hierbij zijn vier aspecten van belang: oplevertijd, kosten, kwaliteit voor de medewerker en kwaliteit voor de klant. Dit leidt tot de volgende processen:

• planning en control
• kostenmanagement
• kwaliteitsmanagement
• service level management

Elk proces kent drie soorten activiteiten. Ten eerste moet er een plan opgesteld worden of afspraken gemaakt worden: een resource planning, budgettering, kwaliteitsplan of SLA. Vervolgens moet dit plan of deze afspraken bewaakt worden. Hierna zal er worden geëvalueerd en bijgeleerd.

ACM- en OCM-processen

De ACM-processen (Applications Cycle Management) zorgen voor een lange termijn strategie met betrekking tot de applicatie. Hierbij zijn drie zaken van belang: de technologische ontwikkelingen, de ontwikkelingen bij de gebruikers- of klantorganisatie en ontwikkelingen in de omgeving van gebruikers- of klantorganisatie (bijvoorbeeld bij bedrijven waarmee de gebruikersorganisatie samenwerkt). Deze zaken leiden tot een strategie met betrekking tot de toekomst van de applicatie, de bijbehorende benodigde onderhoudsacties en een strategie met betrekking tot de applicatieportfolio.

De OCM-processen (Organization Cycle Management) zorgen voor een lange termijn strategie met betrekking tot de ICT-organisatie waarbinnen het applicatiebeheer plaatsvindt. Hierbij zijn de volgende zaken van belang: marktontwikkelingen, de gewenste benadering van de gebruikers- of klantorganisatie, de gewenste kennis en vaardigheden binnen de ICT-organisatie en de gewenste technologische middelen voor de ICT-organisatie. Deze zaken leiden tot een bepaling van de te leveren diensten op lange termijn.

De processen in detail

Beheerprocessen

Incidentbeheer

Tijdens gebruik van applicaties kunnen storingen, vragen of wensen ontstaan. Deze worden als incident gemeld bij een helpdesk of servicedesk die onderdeel is van het proces incidentbeheer. Dit proces streeft een handhaving van de dienstverlening na, opdat voldaan wordt aan de afgesproken service levels. Ingewikkelde incidenten of vaak optredende incidenten worden als probleem doorgezet naar Kwaliteitsmanagement. Naast het reageren op incidenten wordt er ook proactief gehandeld, bijvoorbeeld door het communiceren van ontwikkelingen rond een bepaalde applicatie.

Configuratiebeheer

De applicaties en onderdelen daarvan en de afgesproken diensten en service levels moeten geadministreerd worden. Dit is de taak van configuratiebeheer. Ook wanneer iets op dit vlak wijzigt, moet er geadministreerd worden. De administratie wordt de CMDB (Configuration management database) genoemd.

Beschikbaarheidsbeheer

Het is belangrijk dat een applicatie de afgesproken en gewenste functionaliteit kan bieden op de afgesproken tijden. Beschikbaarheidsbeheer zorgt hiervoor door het meten en rapporteren van beschikbaarheidsniveaus, het analyseren van eventuele tekortkomingen in de applicatie of het beheer, het initiëren van verbeteringen en het betrokken zijn bij nieuwe wijzigingen. Deze activiteiten en maatregelen worden in een beschikbaarheidsplan vastgelegd.

Capaciteitsbeheer

De middelen die een applicatie gebruikt zoals geheugenruimte, diskruimte en CPU-vermogen moeten optimaal worden ingezet. Het moment, de hoeveelheid en de kosten zijn hierbij belangrijke aspecten. Capaciteitsbeheer verricht metingen ten aanzien van de gevraagde en beschikbare capaciteit, analyseert de metingen, rapporteert hierover en neemt zo nodig maatregelen. Mogelijke maatregelen zijn het verschuiven of opdelen van verwerkingen, vergroten van de capaciteit en het optimaliseren van de prestaties. Deze activiteiten en maatregelen worden in een capaciteitsplan vastgelegd.

Continuïteitsbeheer

Alle maatregelen die moeten garanderen dat de applicaties en de dienstverlening ook op langere termijn kunnen blijven functioneren, vallen onder continuïteitsbeheer. Er dient tegen diverse bedreigingen beveiligd te worden. Het gaat om bedreigingen zoals: virussen, hackers, fraude, brand, overstroming. Ook dient men rekening te houden met het wegvallen van leveranciers van wie men afhankelijk is. Aangezien het om dure maatregelen gaat, zal men het risico tegen de kosten moeten afwegen. Deze activiteiten en maatregelen worden in een continuïteitsplan vastgelegd.

Onderhoud en Vernieuwing

Impactanalyse

Onderhoud van een applicatie begint altijd met het analyseren van de uitwerking van de gewenste wijzigingen. Het gaat daarbij om de inspanning die benodigd is om de wijziging te realiseren en de consequenties voor gebruikers(organisatie) en beheerders. Hiervoor is nodig dat duidelijk wordt welke onderdelen van de applicatie gewijzigd moeten worden en door wie de betrokken applicatie(vrijgaven) gebruikt worden. Op basis van deze informatie wordt ook bepaald wat de beste oplossingsrichting is voor de wijziging. Ook wordt nu al in kaart gebracht hoe er getest moet gaan worden. Tijdens deze fase is er veel overleg met Technisch en Functioneel beheer.

Ontwerp

Tijdens deze fase worden de gewenste wijzigingen in overleg met Functioneel Beheer uitgewerkt en eenduidig gespecificeerd. Onderdeel van deze specificatie is onder andere een functionele beschrijving van de te verwerken informatie, de gewenste bewerkingen en de gewenste output in de nieuwe situatie. Ook aan samenhang en volgorde dient aandacht besteed te worden. Voor het specificeren maakt men veelal gebruik van een functioneel ontwerp. Verder wordt er ook uitgewerkt hoe er na realisatie getest dient te worden.

Realisatie

Tijdens de realisatie wordt de functionele specificatie uit de vorige fase technisch uitgewerkt tot een technisch ontwerp. Vervolgens wordt er nader uitgewerkt en gebouwd. Het resultaat is een change package, de gewijzigde programmaonderdelen en databestanden. Ook ondergaan de gewijzigde delen een eerste test: de unit-test waarbij de delen afzonderlijk van elkaar getest worden. Een belangrijk aspect hierbij is het voorkomen van het opnieuw optreden van fouten die reeds bij eerdere releases eruit zijn gehaald.

Test

Om te voorkomen dat de wijzigingen tot fouten in de applicatie leiden en om te borgen dat de gewenste functionaliteit in de nieuwe release verwerkt is, moet er getest worden. Onderdeel van het proces testen zijn de volgende soort testen:

• technische systeemtest (met betrekking tot opgestelde specificaties en onderhoudbaarheid van de software)
• functionele systeemtest (met betrekking tot afgesproken functionaliteit en kwaliteit)
• (ondersteuning van de) productietest door Technisch Beheer (met betrekking tot exploiteerbaarheid)

Zo mogelijk worden deze testen zo opgezet dat ze herbruikbaar zijn bij elke nieuwe release. Op die manier kan er efficiënt gewerkt worden. Om het testen nog meer gestructureerd aan te pakken zijn methoden ontwikkeld zoals TMAP en TestFrame. Deze methoden vallen niet onder ASL.

Implementatie

Anders dan het woord implementatie suggereert gaat het bij het proces implementatie niet om de daadwerkelijk implementatie van de nieuwe release in de productie omgeving. Deze actie wordt namelijk uitgevoerd door technisch beheer in samenwerking met functioneel beheer die de gebruikersondersteuning voor zijn rekening neemt. Wel ondersteunt dit proces Technisch beheer en Functioneel Beheer hierbij. Daarnaast sluit dit proces de release en de opdracht af na ontvangst van een verklaring van acceptatie opdrachtdecharge vanuit Functioneel beheer.

Verbindende processen

Wijzigingenbeheer

Diverse processen dienen wijzigingsverzoeken in bij wijzigingenbeheer. Deze wijzigingen worden vervolgens geregistreerd, geclusterd, geprioriteerd en ingepland in releases. Dit gebeurt in overleg met processen zoals service level management, functioneel beheer, planning en control en impactanalyse. Vervolgens bewaakt dit proces uitvoering van het maken van een nieuwe release in de onderhouds- en vernieuwingsprocessen.

Programmabeheer en distributie

Dit proces moet voorkomen dat er ongeautoriseerde wijzigingen plaatsvinden. Wanneer in het Onderhouds- en vernieuwingsproces bepaalde applicatie onderdelen gewijzigd dienen te worden dan zal dat onderdeel eerst door dit proces ter beschikking gesteld moeten worden. Wanneer de applicatie in productie genomen moet worden dan zal dit proces voor de distributie zorgen zodat de juiste applicatie onderdelen operationeel gemaakt worden. Daarbij let dit proces onder andere op interferenties en overlappingen tussen verschillende parallel lopende vrijgaven.

Literatuur

• Remko van der Pols, ASL: een framework voor applicatiebeheer, 2001, ISBN 904400266X
• Yvette Backer, Remko van der Pols, Application services library: a management guide, 2003, ISBN 90-77212-04-3
• Peter Janssen, Applicatiebeheer volgens ASL, 2005, ISBN 90-430-0883-4
• Remko van der Pols, ASL 2: een framework voor applicatiemanagement, 2009 ISBN 978-90-8753-312-0

Gerelateerde methodieken

• ITIL - Information Technology Infrastructure Library, voor servicebeheer
• BiSL - Business Information Services Library, voor functioneel beheer

Externe link

• ASL BiSL Foundation