Bij Server Based Computing (SBC) worden werkplekapplicaties

Transcriptie

1 Methodieken Het OTAP-proces in een SBC-infrastructuur: praktijkervaringen 5.8 Het OTAP-proces in een SBC-infrastructuur: praktijkervaringen Bij Server Based Computing (SBC) worden werkplekapplicaties aangeboden vanaf een serverplatform. Bedrijven migreren naar een SBC-omgeving omdat dit onder andere voordelen biedt voor het beheer van werkplekapplicaties. Deze SBComgeving vraagt een andere manier van beheer dan de conventionele client/server (C/S) omgeving. Voor het beheer van de omgeving en de applicatiedistributie kan gebruik worden gemaakt van het Ontwikkel, Test, Acceptatie, Productie (OTAP) proces. De relatie tussen OTAP, ITIL en MOF wordt kort weergegeven. Dit artikel beschrijft of de verwachtingen, die voor de SBC-migratie zijn gewekt, in de praktijk zijn waargemaakt. Het artikel sluit af met een beschrijving van de best practice van het OTAP-proces in een SBC-infrastructuur. 359 Auteur: Jeroen A. Kruithof, BT DE AANLEIDING VOOR HET ONDERZOEK Het OTAP-proces is een formeel proces, dat bijdraagt aan de beschikbaarheid en beheerbaarheid van applicaties. Het midden- en kleinbedrijf heeft een kleine ICT-staf, die is belast met zeer diverse taken. Voor het werken volgens formele procedures is die omgeving te hectisch, een formeel proces staat dan op gespannen voet met de praktijk. Doel van het onderzoek is, om vast te stellen hoe in de praktijk wordt omgegaan met het OTAP-proces, en welke aanbevelingen kunnen worden gedaan om ook bij het middenen kleinbedrijf het OTAP-proces voor een SBC-omgeving te implementeren. Aanpak en indeling In het onderzoek worden bedrijven een jaar nadat de migratie is uitgevoerd benaderd, en wordt de huidige werkwijze geëvalueerd. Een SBC-omgeving vereist een formele manier van werken. Onderzocht is hoe de beheerders zich deze nieuwe manier van werken eigen hebben gemaakt. Tien bedrijven werden benaderd. Er werd ingegaan op de manier waarop het OTAP-concept is geïmplementeerd en op de vraag welke elementen hiervan in de praktijk worden gebruikt. Is het überhaupt mogelijk om slechts een deel te doen en hoe wordt bijvoorbeeld een functiescheiding gerealiseerd als er maar één beheerder verantwoordelijk is voor de applicaties? Hoe worden kleine en grote veranderingen op de omgeving doorgevoerd als de druk tot implementeren vanuit de organisatie toeneemt? In dit artikel worden eerst het conventionele C/S en SBC tegenover elkaar gezet en hierna wordt specifiek ingegaan op het OTAPproces. Vervolgens worden de resultaten van het onderzoek gepresenteerd. In het laatste deel worden de gegevens geanalyseerd en voorzien van de best practice voor het toepassen van OTAP in een kleine tot middelgrote SBC-omgeving. SERVER BASED COMPUTING TEGENOVER CONVENTIONEEL CLIENT/SERVER Na een introductie van het SBC-concept volgt een toelichting op de verschillen in de wijze waarop applicaties op een SBC- en 5 IT Service Management, best practices

2 360 C/S-omgeving worden aangeboden. Dit hoofdstuk eindigt met het aanduiden van het belang van het zogenaamde OTAP-proces voor het beheer van applicaties. Introductie van het SBC-concept SBC is een architectuur waarbij een applicatie voor 100% op een applicatieserver draait, en waarbij de user interface van de applicatie wordt weergegeven en bediend met behulp van een werkplek. Tussen de applicatieserver en de werkplek worden alleen de veranderingen van het scherm en de toetsenbord- en muisactiviteiten uitgewisseld. De minimaal vereiste bandbreedte per gebruiker is ongeveer 20 kilobit per seconde, waardoor deze architectuur bijzonder geschikt is in omgevingen met een beperkte bandbreedte tussen de centrale servers en de werkplek. Alle backoffice- en applicatieservers worden centraal opgesteld waardoor het beheer wordt vereenvoudigd en de kosten worden gereduceerd. Ook applicaties met een zware netwerkbelasting presteren goed omdat er tussen de applicatieserver en de backofficeserver gebruik wordt gemaakt van snelle netwerkkoppelingen. De architectuur is vrijwel werkplekonafhankelijk waardoor de werkplek kan bestaan uit een grote verscheidenheid aan apparaten, variërend van een standaard-pc of een thin client tot een PDA of een smart phone. In tegenstelling tot de C/S-architectuur worden er bij SBC op de werkplek van de gebruiker geen applicaties geïnstalleerd en bevinden zich geen persoonlijke- of bedrijfsgegevens op de werkplek. Alle bedrijfsgegevens bevinden zich op de centrale serverlocatie en worden niet uitgewisseld met de werkplek. Figuur 1 SBC-concept De architectuur wordt gebruikt voor het doorvoeren van servercentralisatie en -standaardisatie en voor het vereenvoudigen van de werkplekken. Deze architectuur maakt het mogelijk om gangbare C/S-applicaties zoals DOS, 16 biten 32 bit Windows applicaties, aan te bieden over een beperkte netwerkcapaciteit en kan worden gebruikt als een overgangsfase naar een toekomstige 100% web-enabled omgeving. De applicatieserver is gebaseed op een multi-user Windows operating system, waarop 60 tot 100 werkplekken per applicatieser- Figuur 2 Voorbeeld van eenvoudige SBC-omgeving

3 Methodieken Het OTAP-proces in een SBC-infrastructuur: praktijkervaringen ver worden aangesloten. Het aantal systemen waarop de applicaties fysiek worden geïnstalleerd, uitgevoerd en beheerd is hiermee met een factor 60 tot 100 gereduceerd t.o.v. de C/S-architectuur. Omdat de impact van het wegvallen van één applicatieserver gelijk is aan het wegvallen van het aantal aangesloten werkplekken worden er voor de beschikbaarheid van de applicaties meer applicatieservers in productie genomen dan rekenkundig vereist. Verschillen tussen SBC- en C/Somgeving De specifieke verschillen tussen een SBC- en C/S-omgeving komen tot uiting in applicatieperformance en applicatieconflicten. Om in de SBC-omgeving de applicatieservers maximaal te kunnen benutten en het beheer te vereenvoudigen worden alle applicatie op alle applicatieservers geïnstalleerd. De applicatieservers zijn en blijven hierdoor identiek. De toegang tot de individuele applicatie wordt per gebruiker centraal beheerd. De kans op versieconflicten en technische conflicten groeit asymptotisch met het aantal geïnstalleerde applicaties. Omdat bij het SBC-concept alle applicaties op alle systemen worden geïnstalleerd bestaat de uitdaging uit het onder controle houden van deze conflicten en afhankelijkheden. Voor het onder controle houden van deze conflicten en afhankelijkheden wordt gebruik gemaakt van het OTAP-concept. 361 Applicatieperformance Performance van de SBC-omgeving is afhankelijk van de som van het gedrag van alle actieve gebruikers en actieve applicaties op één systeem. C/S-applicaties worden in de meeste gevallen voor een pc ontwikkeld en verwachten de volledige systeemresource ter beschikking te hebben. De resources van de applicatieserver worden met de overige gebruikers gedeeld. Moderne applicaties houden hier in veel gevallen rekening mee. Oudere applicaties eisen in een aantal gevallen alle resources van het systeem op, waardoor de applicatieperformance voor andere gebruikers nadelig wordt beïnvloed. Het gedrag van de applicaties wordt geanalyseerd door de beheerder en indien nodig worden er instellingen en aanpassingen doorgevoerd of wordt additionele managementsoftware ingezet. Applicatieconflicten Bij de kleine en middelgrote bedrijven zijn tussen de 100 en 200 applicaties in gebruik. In de standaard C/S-omgeving zijn de applicaties verspreid over de werkplekken. Het effect is dat een grote verscheidenheid aan werkplekconfiguraties ontstaat. In de praktijk zijn conflicten lastig te herkennen in een omgeving met zo veel variaties. Applicatiedistributie in een SBCen C/S-omgeving In een C/S-omgeving is elke werkplek voorzien van een set met basisapplicaties. Per gebruiker wordt een aantal specifieke applicaties geïnstalleerd. Het gevolg is dat er een grote verscheidenheid aan configuraties ontstaat. De kleine en middelgrote bedrijven maken voor het beheer van de applicaties op de werkplekken op beperkte schaal gebruik van geautomatiseerde desktop-managementsystemen (DMS). Met een DMS kunnen voorwaarden worden gesteld aan de werkplek, aan de instellingen of aan de gebruiker van de werkplek, voordat de applicatie wordt geïnstalleerd, aangepast of verwijderd. Bij het doorvoeren van iedere wijziging in de applicatieset moeten alle mogelijke combinaties en afhankelijkheden worden geanalyseerd en getest, voordat de wijziging wordt doorgevoerd. Door de grote verscheidenheid aan hard- en softwareconfiguraties is dit een hele uitdaging en het gevolg is dat een groot aantal individuele en specifieke problemen ontstaan. Voor de bedrijven die geen gebruik maken van een DMS is de kans op verstoring groter en het oplossende vermogen kleiner, doordat het opzetten van een representatieve testomgeving niet mogelijk is. Fouten worden hand- 5 IT Service Management, best practices

4 362 Stappen Testen Groep/persoon Ontwikkel Technische haalbaarheid Applicatie packagers Test Testen op technische conflicten Technisch beheerders Acceptatie Testen op correcte functionaliteit Functioneel beheerders Productie Pilot Eindgebruikers Tabel 1 matig hersteld en uiteindelijk wordt de werkplek voorzien van een nieuw basisinstallatie. In de SBC-omgeving wordt juist gestreefd naar het beperken van het aantal verschillende serverconfiguraties, door alle applicaties op identieke servers aan te bieden. Een aanpassing op één server heeft direct impact op een groep van minimaal 60 gebruikers en de functionaliteit van de applicatie kan per server gaan verschillen. In tegenstelling tot het C/S-model, waarbij applicaties op individuele werkplekken kunnen worden aangepast, worden applicatiewijzigingen in het SBCmodel gelijktijdig op alle applicatieservers doorgevoerd. Deze aanpak vraagt een gedegen voorbereiding en een gestructureerde aanpak. Een gestructureerde aanpak is het toepassen van het OTAP-proces waarbij er een logische en fysieke scheiding wordt aangebracht tussen de productieomgeving en de omgevingen waar de voorbereidingen worden ontwikkeld en getest. HET OTAP-PROCES Het OTAP-proces is een cyclisch proces dat bestaat uit de stappen: ontwikkelen, testen, accepteren en in-productie-name. Het is van toepassing bij de implementatie van zowel nieuwe applicaties als bij het doorvoeren van aanpassingen op bestaande applicaties. Het doel van het OTAP-proces is het optimaal houden van de kwaliteit van de dienstverlening, door stappen in het wijzigingsproces zo lang mogelijk buiten de productieomgevingen te houden. Pas op het moment dat alle testen succesvol zijn afgerond en iedere vertegenwoordiger akkoord is, wordt overgegaan tot het implementeren van de wijziging in de productieomgeving. Ter ondersteuning van deze processtappen wordt gebruik gemaakt van vier logisch en fysiek gescheiden omgevingen. Het aantal systemen per omgeving is afhankelijk van de grootte van de organisatie en het aantal applicaties dat wordt geïmplementeerd. Per omgeving is een vaste groep personen verantwoordelijk; deze groep hanteert eigen procedures, methodieken en technieken om de kwaliteit te borgen. Op deze manier wordt een duidelijke functiescheiding aangebracht (tabel 1). Toepassen van OTAP in een SBC-omgeving In de ontwikkelfase wordt alle relevante informatie van de applicatie verzameld. De gegevens worden vastgelegd in een applicatieaanvraagformulier (AAF). Bij wijzigingen wordt het formulier gebruikt om de aanpassingen te administreren. Het AAF-formulier bevat naast de technische gegevens ook informatie over de leverancier, over de functioneel- en technisch beheerder en over de gebruikersgroep. Op basis van dit formulier en de verzamelde media wordt de applicatie geïnstalleerd op een standaard applicatieserver. In deze fase wordt de technische haalbaarheid van de applicatie op het platform geanalyseerd en op basis van een nulmeting wordt het gedrag vastgelegd. In de testfase wordt gezocht naar conflicten die kunnen ontstaan bij de installatie van een nieuw pakket in een omgeving met reeds geïnstalleerde applicaties. Dit proces wordt ondersteund met software die een deel van de conflictanalyse kan uitvoeren. De uiteindelijke situatie is een opeenstapeling van applicaties met onderlinge afhankelijkheden. In deze fase wordt getest wat de gevolgen van de mutaties in deze omgeving zijn.

5 Methodieken Het OTAP-proces in een SBC-infrastructuur: praktijkervaringen In de acceptatiefase wordt de applicatie aangeboden aan de functioneel beheerder. De inhoudelijke werking wordt getest en er wordt gecontroleerd of alle functionaliteiten beschikbaar zijn. Het aanbieden van een applicatie via het SBC-concept heeft invloed op de prestatie en presentatie van de applicatie. In deze fase worden deze aspecten geanalyseerd en vergeleken en wordt de gebruikershandleiding aangepast. De applicatie wordt gefaseerd in productie genomen door deze eerst aan een pilotgroep aan te bieden. Voor het uitvoeren van de pilot wordt één van de productieservers voorzien van de nieuwe applicatie en wordt er tijdens de pilot gebruik gemaakt van productiedata. In de configuratie van de SBC-software wordt aangegeven welke groep gebruikers toegang heeft tot dit pilotsysteem. Bij gebleken geschiktheid wordt de applicatie aan de overige gebruikers aangeboden. Het voordeel van het SBC-concept is dat het distribueren van de applicatie bijzonder snel kan worden gerealiseerd omdat het aantal systemen beperkt is en deze altijd beschikbaar zijn. Door bij de uiteindelijke installatie gebruik te maken van een DMS blijven de productieservers identiek. de facto wereldstandaard voor beheer en levering van IT-diensten. Het OTAP-proces zorgt ervoor dat applicaties geschikt gemaakt worden voor de productieomgeving. Is het nu (volgens ITIL) change management of/en release management? Het doel van change management 1 is het planmatig doorvoeren van alle wijzigingen in de ICT-infrastructuur. Daarbij worden de risico s op verstoring van de diensten en daarmee het verlagen van de kwaliteit van de geleverde diensten zo beperkt mogelijk gehouden. Change management vormt de schakel tussen de operationele productieomgeving en de ondersteunende ontwikkel-, test- en acceptatieomgeving. Wijzigingen of nieuw applicaties worden planmatig ingevoerd. Daarbij worden risico s afgewogen en geminimaliseerd. Op verzoek van change management worden versies (release, upgrade, fix, patch) samengesteld die ook afzonderlijk worden getest. Als deze testen goed zijn verlopen, zal change management de beslissing tot vrijgave nemen. De goedgekeurde en vrijgegeven versie wordt dan gedistribueerd, waarna change management de implementatie op de productieomgeving verzorgt. 363 OTAP IN RELATIE TOT ITIL EN MOF Hoe past het OTAP-proces nu in het welbekende ITIL-bouwwerk? ITIL (Information Technology Infrastructure Library) is zoals bekend een verzameling best practices, de Release management beheert alle applicaties binnen de productieomgeving. Er worden uitsluitend gecontroleerde applicaties gedistribueerd, waarbij men ervoor zorgt dat men kan terugvallen op originele versies. De 5 Applicatie 103 Applicatie 102 Applicatie 101 Applicatie 101 Applicatie 100 Applicatie 100 Applicatie 99 Applicatie 2 Applicatie 2 Applicatie 1 Applicatie 1 Applicatie 1 Applicatie 100 Applicatie 99 Applicatie 1 Testomgeving Ontwikkelomgeving Acceptatieomgeving Productie-omgeving Figuur 3 OTAP-omgeving 1 Infravision. IT Service Management, best practices

6 364 release manager bewaart en beheert de originele versies van software. Daarnaast bewaakt hij het proces van de beschikbaarstelling van software. De conclusie uit bovenstaande is dat OTAP een combinatie is van release management én change management. De release manager bewaakt het proces van beschikbaarstelling (Ontwikkelen, Testen), de change manager geeft de beslissing tot vrijgave (Accepteren en in Productie nemen). Het Microsoft Operations Framework (MOF) 2 is gebaseerd op 3 bouwstenen: Team model - dat zich richt op alle aspecten van het organiseren van IT-personeel. Proces model - dat zich richt op IT-processen. Risicomanagement - dat zich richt op het managen van de risico s voor IT-diensten. Het procesmodel is gebaseerd op ITIL, zie figuur 4. Veel van de in de figuur vermelde Service Management Functions (SMF s) komen uit ITIL. Uitzonderingen zijn Workforce Management (in het Optimizing kwadrant) en alle SMF s in het Operating kwadrant. Op het niveau van het procesmodel is MOF (net als ITIL) platformonafhankelijk. Pas op het niveau waarin de vertaling naar de Microsoftproducten wordt gemaakt wordt de MOFdocumentatie platformafhankelijk. Voor wat betreft de relatie met OTAP verandert er op het niveau van het procesmodel dan ook niets: OTAP is eveneens platformonafhankelijk en MOF kent eveneens change management en release management. SBC IN DE PRAKTIJK Het onderzoek is gericht op bedrijven die zijn gemigreerd van het conventionele C/Smodel naar het SBC-model en in deze omgeving applicaties aanbieden aan 300 tot 500 medewerkers. De medewerkers zijn verspreid over gemiddeld vier locaties. Het team van beheerders bestaat uit twee tot tien personen en het takenpakket varieert van breed tot zeer specifiek. Een jaar nadat de migratie is uitgevoerd werden circa tien bedrijven benaderd en hun werkwijze geëvalueerd. Het opzetten en in gebruik nemen van het OTAP-concept is binnen SBC een vereiste, de vorm is een keuze. Onderzocht is hoe de beheerders zich deze nieuwe manier van werken eigen hebben gemaakt. Service Level Management Financial Management Capacity Management Availability Management IT Service Continuity Mgmt. Workforce Management Security Management Infrastructure Engineering SLA Review Service Desk Incident Management Problem Management Figuur 4 Proces model van MOF Optimizing Supporting Change Initiation Review MOF Operations Review Changing Operating 2 Microsoft. Change Management Configuration Management Release Management Release Readiness Review System Administration Security Administration Service Monitoring & Control Directory Services Administration Network Administration Storage Management Job Scheduling

7 Methodieken Het OTAP-proces in een SBC-infrastructuur: praktijkervaringen Verwachtingen Het SBC-concept wordt om verschillende redenen geïmplementeerd. De redenen zijn als volgt te categoriseren: centralisatie, consolidatie van decentrale systemen; ontsluiten van functionaliteit voor decentrale locaties, telewerken op een veilige manier; reductie van beheerkosten, door vereenvoudiging en hergebruik van bestaande apparatuur. De eerste twee punten zijn in alle situaties gerealiseerd. De doelstelling om kostenreductie en vereenvoudiging van de omgeving te realiseren is in vijf van de tien gevallen niet overeenkomstig de verwachting gerealiseerd. Als verklaring wordt gegeven dat het beheer, de complexiteit en de afhankelijk van de werkplekken voor ruim 80% is afgenomen. De centrale omgeving is daarentegen complexer geworden en de afhankelijkheid van een kleiner aantal systemen is toegenomen. Het beheer is kritischer geworden doordat de impact van een verstoring groter is dan bij het werken met individuele werkplekken. Bijzondere aandacht gaat uit naar de applicaties die niet op de SBC-omgeving aangeboden kunnen worden. Van de SBC-architectuur is bekend dat gemiddeld 20% van de applicaties niet geschikt zijn om op de SBComgeving te worden aangeboden. Uit het onderzoek bleek dat gemiddeld 15% van de applicaties om technische of organisatorische redenen niet op de SBC-omgeving aangeboden konden worden. Voor bepaalde oude DOS-applicaties, applicaties met een specifieke hardwareafhankelijkheid of applicaties met onderlinge conflicten valt men terug op de oorspronkelijke werkplekken. Als argument wordt ook gebruikt dat een applicatie slechts door enkele personen wordt gebruikt en de kosten voor het realiseren van een applicatiepackage niet opwegen tegen de voordelen van een beheerbare omgeving. OTAP-gebruik De implementatie van het OTAP-concept op basis van een gescheiden omgeving is bij 50% van de onderzochte groep gerealiseerd. 30% maakt gebruik van een gecombineerde ontwikkel- en testomgeving en 20% implementeert de wijzigingen in de productieomgeving. Voor het implementeren in de productieomgeving wordt één server uit de SBC-omgeving gehaald en worden de aanpassingen op deze server doorgevoerd. Bij slechts 20% van de deelnemers zijn de rollen van ontwikkelaar, tester en functioneel beheerder (acceptant) werkelijk gescheiden. In de meeste gevallen is de technisch beheerder verantwoordelijk voor de implementatie en de uitvoering van de technische testen. Alleen voor specifieke applicaties wordt gebruik gemaakt van een functioneel beheerder met voldoende kennis van de applicatie. Het OTAP-concept heeft tot doel de productie minimaal te verstoren. Het testen van de applicaties door de ontwikkelaar levert in de praktijk niet de gewenste kwaliteit op. Zo blijkt dat 15% van de applicaties die op de productieomgeving zijn geïmplementeerd alsnog aangepast of hersteld moeten worden. Beheer Het gebruik van het OTAP-proces heeft een grote invloed op de beheerbaarheid van de omgeving. Bij de bedrijven waar het OTAPproces zo goed mogelijk wordt gebruikt is de ervaring dat de omgeving steeds beter onder controle komt bij de beheerders. Het systeem maakt het mogelijk om niet alleen maar brandjes te blussen maar ook te investeren in onderzoek en ontwikkeling. De beheerinspanning is in kwantiteit niet afgenomen maar de werkzaamheden zijn verschoven van reactief naar proactief IT Service Management, best practices

8 -- tijd -----> 366 C/S-model SBC-model SBCmodel ná 1 jaar OTAP Geen OTAP C/S Beheer(s)baarheid Figuur 5 Beheerbaarheid in de praktijk Bij de bedrijven die het OTAP-concept niet of niet volledig praktiseren, bestaat twijfel over het SBC-concept. De combinatie van het beheer van werkplekken naast het beheer van de SBC-omgeving wordt als zeer verstorend aangeduid. De beheerbaarheid van de gehele omgeving is afgenomen. Deze afname wordt geweten aan de toegenomen complexiteit, de kwaliteit van de beheerders en de kwaliteit van de applicaties. 20% van de deelnemers maakt geen gebruik van OTAP en implementeert wijzigingen direct in de SBC-omgeving. Dit zijn de deelnemers die eveneens overwegen het beheer van de omgeving uit te besteden. Applicatiewijzigingen Applicaties hebben onderling bepaalde afhankelijkheden die niet altijd herkenbaar zijn. 80% van de onderzochte bedrijven gebruikt een vaste volgorde waarmee de applicaties worden geïmplementeerd. 60% Overige applicaties Basis applicaties Systeem image { { { Applicatie 200 Applicatie 199 Applicatie 21 Applicatie 20 Applicatie 1 van de bedrijven gebruikt voor de installatie de software-distributieonderdelen van de SBC-software. Slechts 20% van de bedrijven gebruikt voor het beheren van de SBC-servers en de resterende werkplekken een desktop management systeem (DMS). De overige 20% voert alle werkzaamheden handmatig uit. Eén van de ongewenste effecten van het handmatig installeren is dat servers niet identiek blijven. De functionaliteit van de gehele omgeving is dan niet consistent en dat kan verwarrend zijn voor de eindgebruikers. Als voordeel is aangegeven dat eventuele aanpassingen snel zijn door te voeren. Kleine aanpassingen worden zonder test op een enkele server doorgevoerd en bij wijzigingen met een grote tijdsdruk wordt er van de gehele applicatieserver een kopie gemaakt en wordt de wijziging geïmplementeerd. Applicatie 200 Applicatie 199 Applicatie 21 Applicatie 20 Applicatie.. Applicatie 1 applicatie aanpassing applicatie verwijderen applicatie aanpassing Figuur 6 Applicatiemutaties

9 Methodieken Het OTAP-proces in een SBC-infrastructuur: praktijkervaringen In figuur 6 is de opeenstapeling en onderlinge afhankelijkheid van applicaties aangegeven. Wijzigingen van een enkele applicatie heeft effect op de overige applicaties. 10% van de bedrijven maakt gebruik van een applicatie package omgeving met een ingebouwde conflictanalyse. Gedurende het doorlopen van het OTAP-proces worden de afhankelijkheden en conflicten bekend, en worden ze verholpen of vermeden. In de 130 applicaties die in de productieomgeving zijn geïmplementeerd zijn twee fouten geconstateerd. Het doorlopen van het OTAP-proces kan met de juiste afstemming binnen één dag worden gerealiseerd. Bij een hoge tijdsdruk bestaat de uitdaging uit het vasthouden aan de procedures. 60% van de beheerders geeft aan erg gevoelig te zijn voor deze druk en heeft met overhaaste beslissingen en onzorgvuldigheid het OTAP-proces verstoord. OTAP EN SBC BEST PRACTICE OTAP leeft wel bij de bedrijven, maar het praktiseren blijft om organisatorische en praktische redenen wat achter. Het aantal beheerders is te klein om de verschillende rollen volledig te kunnen scheiden en op een aantal van 2 tot 12 productieservers is het opzetten van een gescheiden OTAP-straat een grote investering. Virtualisatie van de OTA-omgeving In de kleine omgeving is het aantal wijzigingen beperkt en wordt de OTAP-omgeving beperkt gebruikt. Het gebruik kan efficiënter door het toepassen van servervirtualisatie. Met servervirtualisatie is het mogelijk om op één fysieke server meerdere logische servers aan te bieden. De logische servers kunnen worden ingezet als volwaardige applicatieservers. Alle gegevens van de logische server worden opgeslagen in enkele bestanden, waardoor het tijdelijk opslaan of terughalen van een specifieke serverconfiguratie zeer eenvoudig en snel is uit te voeren. Deze techniek is ontwikkeld in de mainframeomgeving en wordt al jaren toegepast als systeempartitionering. De drie OTA-functies worden gecombineerd op één fysieke server. Het is bijvoorbeeld mogelijk om parallel meerdere test- of acceptatieservers in te zetten. Tijdens het ontwikkelen en testen van applicaties worden de applicatieservers regelmatig terug gebracht naar een stabiele situatie. In plaats van het gebruik van images of herinstallaties wordt de situatie hersteld door het kopiëren van een aantal bestanden. Op deze manier kan efficiënter en sneller worden gewerkt en drukt het gebruik van servervirtualisatie de operationele kosten. 367 Aan de verdeling van de beheertaak is in de praktijk weinig te veranderen. Het onderscheid tussen de rollen van de ontwikkelaar en de tester moet wel duidelijk worden aangebracht. In de praktijk worden wijzigingen overhaast in productie genomen en veroorzaken daarmee veel verstoring. Het is voor de kleinere organisatie lastig om voldoende gekwalificeerd personeel aan zich te binden en het uitbesteden van de beheertaak is voor deze groep een reële optie. Specifieke applicatieservers Er zijn applicaties ( bad-apps ) die niet geschikt zijn om op een standaard applicatieserver te worden aangeboden. Als deze bad-apps worden gecombineerd met de overige applicaties, ontstaat verstoring van de functionaliteit als gevolg van applicatieconflicten, specifieke afhankelijkheden of systeemeisen. 5 Een specifiek punt dat de kleine organisaties kan helpen is het gebruik van servervirtualisatie en een punt voor de grotere omgevingen is juist het opsplitsen van de productieserver in generieke en specifieke applicatieservers. IT Service Management, best practices

10 Applicatie 100 Applicatie 99 Applicatie 100 Applicatie Applicatie 2 Applicatie 1 Bad-appl. 3 Applicatie 2 Bad-appl. 2 Applicatie 1 Bad-appl. 1 Bad-appl. 6 Bad-appl. 5 Bad-appl. 4 Productie-omgeving Productie-omgeving (Bad-Apps) Figuur 7 Omgeving inclusief bad-apps-servers Door de bad-apps op specifieke servers te implementeren, zoals in figuur 7 is aangeven, blijft de standaard-productieomgeving stabiel. Op de bad-apps server wordt gebruik gemaakt van specifieke management software om het gedrag van de applicaties te beteugelen. Het gebruik van applicaties op de bad-apps -servers is voor de medewerkers vrijwel transparant. Algemene Do s and Don ts In het onderstaande overzicht zijn de meest relevante leermomenten opgenomen die van toepassing zijn bij het beheren van een SBComgeving: OTAP: - Streef naar één omgeving: óf SBC óf C/S, en pas OTAP integraal toe. - Zorg voor een duidelijke scheiding in de functie applicatiepackager/-ontwikkelaar en functioneel tester. - Zorg voor een duidelijke scheiding in de applicatieservers voor Productie en voor OTA. - Herinstalleer de productieapplicatieservers eens per half jaar om de servers identiek te houden en de omgeving op te schonen. Opleiding: - Zorg voor voldoende kennis door passende opleidingen en certificering vóórdat de omgeving wordt opgeleverd. - Maak gebruik van specialisten bij het opzetten van de applicatie package omgeving. Applicaties: - Minimaliseer het aantal applicaties en vervang oude applicaties door webapplicaties. Voorkom het gebruik van niet-32-bit applicaties. - Installeer probleemapplicaties op een specifieke bad-apps server. Installatie: - Handmatige installatie. Zet een generieke softwaredistributietool in. Hanteer een vaste volgorde voor applicatieinstallaties. - Maak gebruik van goede conflictanalyse bij het ontwikkelproces. Jeroen A. Kruithof is senior technisch consultant bij BT, op de afdeling Consulting and Systems Integration. Hij ontwerpt en begeleidt infrastructuurmigraties en is gespecialiseerd in het implementeren van server based computing omgevingen.