Naar een nieuw Applicatietijdperk

 
11 oktober 2013

Tekst Sven van de Riet

Vroeger hielden softwareprogramma’s het lang uit. Dat was ook noodzakelijk, want de distributie was – zonder online netwerken – een belangrijke bottleneck. Tegenwoordig kunnen we een applicatie op onze iPad direct updaten als we zien dat er een nieuwe versie beschikbaar is. Door de opkomst van mobiele internettechnologie heeft een ware ‘interface explosie’ plaatsgevonden: iedereen verwacht dat functionaliteit via een groot aantal kanalen te ontsluiten is. Dit alles vraagt om nieuw applicatiebeheer.

Applicaties zijn voor bedrijven van groot belang, steeds vaker zijn ze onderdeel van de omzetstroom. Uitval raakt dan direct de financiële resultaten. Digitale services die zeer gericht inspelen op behoeften, trekken nieuwe klanten én zorgen voor behoud van bestaande klanten. Gebruikers raken gewend aan een goedwerkende app en bouwen een digitale historie op die niet altijd eenvoudig is over te brengen naar een concurrent. In de financiële wereld bestrijden banken en verzekeraars elkaar doorlopend met digitale innovaties om klanten aan zich gebonden te houden. Daarmee wordt de stabiliteit van applicaties nog belangrijker. Klanten klagen sneller en ook de pers zit er tegenwoordig bovenop als de elektronische omgeving ‘plat’ ligt.

Snel, wendbaar en stabiel

Om de voortbrenging van IT te professionaliseren is het IT-werk opgeknipt in een groot aantal verschillende processen. Applicatieontwikkeling staat los van applicatiebeheer en ook de werelden van applicaties en infrastructuur zijn vaak van elkaar gescheiden. De gedachte hierachter is logisch: specialisatie verhoogt de kwaliteit van de individuele componenten en het scheiden van verantwoordelijkheden beperkt de risico’s. Deze specialisatie heeft ook tot verkokering geleid: de verschillende disciplines hebben niet altijd even goed onderling contact over het gewenste eindresultaat. Het uiteindelijke resultaat wordt echter bepaald door de kwaliteit van de gehele keten, niet door de kwaliteit van de individuele componenten.

Deze opzet komt nu onder druk te staan door twee tegengestelde ontwikkelingen. Bedrijven willen enerzijds steeds sneller inspringen en reageren op veranderende behoeften. Als gevolg hiervan veranderen applicaties steeds sneller en dit resulteert in een behoefte aan functionele wendbaarheid. Functionaliteit kan niet meer beschouwd worden als iets dat in beton gegoten is. Aan de andere kant verwacht iedereen dat applicaties altijd beschikbaar zijn: dit vraagt om continuïteit en stabiliteit in de onderliggende infrastructuur. Het tempo van veranderingen en de hoge eisen op het vlak van beschikbaarheid vergen meer samenwerking tussen de verschillende disciplines dan nu gebruikelijk is.

Applicatiebeheer nieuwe stijl

Met de traditionele beheermethode is de snelheid van applicatieontwikkeling niet meer bij te benen. Bij steeds meer oplossingen is bovendien niet de medewerker, maar de klant de eindgebruiker. Ook op dat vlak is een betere samenwerking tussen de IT-organisatie en de business nodig. Omdat beheerprocessen nu nog zijn ingericht op efficiënte IT-processen in plaats effectieve bedrijfsprocessen ervaart de business echter vaak lange doorlooptijden.

Om dit probleem op te lossen kiezen IT-organisaties steeds vaker voor het werken met zogenaamde DevOps-teams. De naam zegt het al: bij deze teams komen Development en Operations bij elkaar, samen met kwaliteitsbewaking (QA). DevOps wordt gevoed door ontwikkelingen op zowel applicatie- als infrastructuurgebied. Aan de applicatiekant is de agile werkwijze, waarbij wordt gewerkt in kleine iteraties, sterk in opkomst. Met agile probeert men in te spelen op de behoefte aan doorlopende verandering en een kortere timeto- market. Samenwerking en interactie staan boven het werken met strakke processen en allesomvattende documentatie. Aan de infrastructuurkant is de opkomst van (bijna) volledig geautomatiseerde datacenterprocessen een belangrijke ontwikkeling.

De DevOps-benadering heeft vaart gekregen door de ervaringen van bedrijven die drijven op hun websites. E-commerce-ondernemingen hebben de behoefte om elke dag nieuwe functionaliteit voor websites in de lucht te brengen. Zij ervoeren dat het onmogelijk is om de gewenste veranderingen snel door te voeren op de traditionele wijze: er ging te vaak iets mis. Om wijzigingen zo snel, veilig en stabiel mogelijk in productie te nemen, gingen applicatiespecialisten de samenwerking aan met infrastructuurspecialisten.

Applicatie- en infrastructuurbeheer schuiven in elkaar

De DevOps-benadering houdt een andere manier van werken in. DevOps-teams bestaan uit professionals die wel een eigen werkveld hebben, maar geen superspecialist zijn. Ieder teamlid heeft kennis van de verschillende aspecten die bij ontwikkeling én beheer komen kijken. Samenwerken staat voorop: de professionals van development en operations zitten bij elkaar in één ruimte en zo dicht mogelijk bij de mensen in de business waarmee het team moet samenwerken. In het geval van uitbesteding moet de locatie van betrokken medewerkers binnen de service providers zorgvuldig overwogen worden. Als je volgens DevOps wilt werken, staat een team dat volledig offshore werkt, te ver af van de business.

Met het invoeren van DevOps-teams kunnen silo’s binnen IT worden geëlimineerd. Omdat teams rondom business processen of producten zijn georganiseerd, zijn ze bevorderlijk voor intensieve samenwerking met de business. Een DevOps-team is beter zichtbaar voor de business, waardoor het eenvoudig is om de juiste personen aan te spreken. Kortere lijnen helpen om snel duidelijk te krijgen waar de prioriteiten liggen en om vast te stellen welke activiteiten de meeste businesswaarde genereren.

De opkomst van DevOps betekent niet het einde van een methodiek als ITIL. ITIL-processen blijven belangrijk om de kwaliteit op peil te houden. Met DevOps veranderen vooral de werkwijze en de verantwoordelijkheden voor processen. Omdat het moeilijk is om een complete IT-organisatie snel om te laten schakelen, zullen grotere organisaties in eerste instantie uitkomen op een mix van nieuwe en traditionele manieren van beheer.

De valkuilen bij applicatiebeheer

Succesvolle organisaties breken oude silo’s af: ontwikkel- en beheerorganisaties bewegen naar elkaar toe

DevOps wordt momenteel vooral ingezet bij nieuwe applicatievormen, zoals mobile apps en web applicaties. Het bestaande applicatielandschap van organisaties is vaak al een complexe mengelmoes van software: generiek en gespecialiseerd, groot en klein, legacy en modern. De verwachting is dat dit applicatielandschap de komende jaren in hoog tempo op de schop gaat. Maatwerkoplossingen maken hierbij steeds vaker plaats voor modernere oplossingen met nieuwe applicatievormen zoals SaaS, waarbij software en infrastructuur integraal als dienst worden afgenomen.

Bij het in gebruik nemen van moderne oplossingen en het uitfaseren van de oude systemen staat de beheerorganisatie voor de uitdaging om de vernieuwing adequaat te ondersteunen, terwijl de traditionele doelen op het gebied van stabiliteit, continuïteit en kostenbeheersing niet uit het oog verloren mogen worden. Bij het aangaan van deze uitdagingen komen organisaties waarschijnlijk een aantal valkuilen tegen, die hieronder worden besproken. Bij iedere valkuil geven we ook een oplossingsrichting.

Valkuil 1 – Integratie wordt onderschat

Oplossingsrichting: mobiliseren van aanwezige kennis

Nieuwe elementen als applicatieplatformen, SaaS, apps en web applicaties doen hun intrede in het applicatielandschap en vergroten de uitdaging op het gebied van integratie. Het is niet eenvoudig om de juiste en samenhangende technische maatregelen te treffen om stabiliteit en continuïteit te waarborgen. Nieuwe functionaliteiten brengen bovendien vaak nieuwe leveranciers mee en deze hebben de natuurlijke neiging vooral naar hun eigen domein te kijken.

Organisaties die het integratievraagstuk zelf willen managen, ervaren steeds meer moeite om de juiste mensen aan te trekken. Sommige organisaties overwegen daarom de verantwoordelijkheid voor integratie uit te besteden. Eén van de grotere providers krijgt dan de opdracht om de leveringsprocessen end-to-end aan te sturen, inclusief de betrokken (kleinere) leveranciers. Dit blijkt in de praktijk vaak lastig; het belang van de hoofdleverancier is bovendien tegengesteld aan dat van de klantorganisatie. De klantorganisatie streeft naar minder complexiteit en lagere kosten, terwijl de leverancier juist baat heeft bij gelijkblijvende of toenemende complexiteit, aangezien dit uiteindelijk meer omzet oplevert. Daar komt bij dat de klantorganisatie precies die operationele kennis uitbesteedt, die nodig is om leveranciers aan te sturen. Ook met de beste KPI’s en stuurmechanismen in het contract zal de klant steeds minder goed in staat zijn om inhoudelijk te beoordelen in hoeverre de maandelijkse facturen in verhouding staan tot geleverde diensten.

Uiteindelijk blijft de eindverantwoordelijkheid voor integratie bij de klantorganisatie zelf liggen. Er zijn mogelijkheden om de integratie intern goed te organiseren. Als steeds meer beheertaken worden uitbesteed of anders worden ingevuld (bijvoorbeeld door de keuze voor SaaS), dan komt capaciteit vrij bij applicatiebeheerders. Deze medewerkers komen nu vaak terecht in herplaatsingstrajecten of afvloeiingsregelingen. Zij hebben echter veel kennis van de business, van dagelijkse processen en van gebruikte systemen: kennis die noodzakelijk is voor operationele integratie. Effectieve regievoering speelt zich niet alleen af op het tactische niveau met aandacht voor maandelijkse voortgangsrapportages en overleggen. Integratie is gebaat bij IT-medewerkers die met de voeten in de klei staan; die aandacht hebben voor documentatie en voor het controleren van de configuratiedatabase; en die de beheerders bij de leveranciers scherp kunnen houden. Het loont daarom om goed in kaart te brengen welke medewerkers over essentiële kennis beschikken die ook na de uitbesteding nodig blijft om de integratie van de grond te krijgen. Deze rollen bestaan nog nauwelijks, in veel situaties zal waarschijnlijk omscholing of bijscholing nodig zijn.

Valkuil 2 – Dubbele beheerlasten

Oplossingsrichting: inzet van flexibele beheercontracten

Effectief licentiebeheer wordt steeds interessanter

Licentiebeheer

Als bestaande functionaliteit steeds sneller wordt vervangen door nieuwe oplossingen, dan dreigt een klassieke valkuil: een dubbele beheerlast. De nieuwe wereld wordt uitgerold, maar de oude wereld kan niet zomaar worden ‘uitgezet’. De bestaande infrastructuur is nog steeds nodig en wordt daarmee relatief gezien steeds duurder; een situatie die jaren kan blijven bestaan. Voor de beheerorganisatie is het van belang om bij het uitrollen van nieuwe oplossingen de bestaande leveranciers zo snel mogelijk in te lichten. Bestaande leveranciers beschikken vaak over kennis die nodig is om de uitrol van denieuwe oplossing tot een succes te maken, maar zien op termijn wel een deel van hun omzet verdampen als zij niet de nieuwe oplossing leveren. Flexibele beheercontracten houden rekening met kennisoverdracht en uitloop van de transformatie. Hoe eerder hier aandacht aan wordt besteed en afspraken over worden gemaakt, hoe minder de pijn zal zijn.

Valkuil 3 – Minder effectieve incidentafhandeling

Oplossingsrichting: beter gebruiken van beschikbare data

Met meer applicaties en meer leveranciers neemt ook het aantal oplosgroepen toe. Het beheersen van de ticketstromen wordt dus complexer, maar de doelstelling blijft hetzelfde: de tickets moeten zo snel mogelijk bij de juiste oplosgroep terecht komen. Een complexer applicatielandschap brengt met zich mee dat niet altijd direct  duidelijk is waar in de keten het probleem ligt. Oplostijden kunnen oplopen en de kwaliteit van dienstverlening kan verslechteren als de diagnose niet goed kan worden gesteld.

Het continu monitoren van de ticketstromen en het identificeren van verbetermogelijkheden is daarom belangrijk. De meeste organisaties beschikken over een schat aan data, afkomstig uit servicemanagementsystemen, die lang niet altijd volledig wordt benut. Het doorvoeren van relatief eenvoudige acties kan leiden tot aanzienlijke kwaliteitsverbeteringen of kostenbesparingen. Voorbeelden zijn het implementeren van standaard templates voor eindgebruikers, waarmee de routing van tickets wordt geautomatiseerd; het verwijderen van onnodige overdrachtsmomenten in de ticketstroom; het wegnemen van blokkades in het proces (denk aan procedures waardoor tickets vastlopen); het versterken van de eerste lijn of het aanpassen van afspraken met leveranciers.

 Valkuil 4 – Beheercontracten worden minder transparant

Oplossingsrichting: versterken licentiebeheer en benefit tracking

Een gevolg van de opkomst van moderne oplossingen is dat de kosten van de geboden diensten  minder transparant worden. Traditioneel wordt IT afgerekend op basis van een hardwarecomponent en een beheercomponent: bijvoorbeeld het aantal servers dat nodig is om een applicatie te laten werken en de beheercapaciteit die daarbij nodig is. Wanneer bij nieuwe oplossingen de aangeboden diensten virtueel worden gedeeld met andere klanten, wordt vaak op basis van licenties afgerekend. De interne opbouw van de kosten voor de dienst is dan onzichtbaar voor de afnemer. Dit betekent dat de focus van kostenopbouw verschuift naar waardeoptimalisatie: hoe stel je vast dat de licentie meer oplevert dan hij kost?

Een steeds groter deel van het IT-budget zal in de komende jaren bestaan uit licentiekosten. Zaken als de prijs/kwaliteitsverhouding en de waarde die wordt gegenereerd door een contract worden belangrijker. Effectief licentiebeheer wordt dus nog interessanter. Daarbij valt te denken aan het afsluiten van gunstige licentiecontracten (dit vergt andere kennis dan bij ‘traditionele’ IT contracten), het optimaliseren van zowel het aantal gebruikers als het proces voor het aanvragen van licenties. Bij het delen van licenties tussen organisatieonderdelen – ook een onderdeel van effectief licentiebeheer – is het van belang tijdig in actie te komen: licentiecontracten hebben vaak een lange looptijd en een eenmaal aangeschafte licentie kan niet meer worden (door)verkocht.

Verder kan het helpen om meer aandacht te besteden aan benefit tracking. Na het opstellen van de business case en het afronden van het project worden de daadwerkelijk gerealiseerde baten van het project zelden gemonitord. De aandacht van het projectteam verschuift vaak snel naar het volgende project. Wanneer de beheerorganisatie benefit tracking naar zich toetrekt, ontstaat er beter inzicht in stijgende beheerlasten (inclusief licentiekosten) en kunnen beslissingen over nieuwe projecten beter worden onderbouwd. Bij het effectief inrichten van benefit tracking is een lange adem van belang. Doorgaans wordt het effect van een bepaalde keuze pas goed zichtbaar na verloop van jaren, zeker wanneer het gaat om geheel nieuwe ontwikkelingen. Omdat medewerkers nogal eens van plek wisselen, is het noodzakelijk om benefit tracking structureel in de organisatie te verankeren. De beheerorganisatie is hiervoor een geschikte plek vanwege de focus op continuïteitsvraagstukken.

Valkuil 5 – De business galoppeert IT voorbij

Oplossingsrichting: businessbehoeften gebruiken als katalysator voor het opruimen van legacy

De nieuwe generatie online applicaties maken het eenvoudiger voor de business om zelf oplossingen te selecteren en implementeren. Soms wordt daarbij de beheerorganisatie geheel omzeild. Dit brengt risico’s met zich mee, omdat de business vaak vanuit het eigen perspectief redeneert zonder voldoende rekening te houden met security-aspecten, interfaces, standaarden en licentiebeheer.

Voor de beheerorganisatie is het zaak om ook op dit punt met de business in gesprek te blijven. Als de business een bepaalde oplossing in gedachten heeft, dan voorziet deze meestal in een directe behoefte en kan de oplossing vaak prima geïmplementeerd worden. Randvoorwaarde is dat de beheerorganisatie en de business daarbij samen optrekken. Een proactievebusiness is niet alleen een ‘bedreiging’ voor de beheerorganisatie, maar biedt ook kansen. Door een verbeterde samenwerking bij de implementatie van nieuwe oplossingen kunnen ook gelijk afspraken worden gemaakt over hetopruimen en uitzetten van legacy-oplossingen.

Hoe nu verder?

De hoge eisen die consumenten en businessstellen aan vernieuwing binnen IT, zijn op de traditionele wijze niet meer  bij te houden. Succesvolle organisaties breken oude silo’s af, zodat de ontwikkel- en beheerorganisaties meer naar elkaar toe bewegen. Het inrichten van multidisciplinaire teams stelt IT-organisaties in staat om sneller resultaat te leveren, zonder daarbij veiligheid en stabiliteit uit het oog te verliezen.

Bij de beweging naar een nieuwe applicatieorganisatie verdient een aantal valkuilen de aandacht. Vooral de integratie van verschillende soorten oplossingen en de integratie van de ‘oude wereld’ met de ‘nieuwe wereld’ blijven een uitdaging. Operationele kennis is daarbij cruciaal. Succesvolle organisaties waken ervoor de juiste mensen te behouden en waar nodig bij te scholen. Dubbele beheerlasten kunnen worden voorkomen, bij het vormgeven van het nieuwe applicatie landschap is de samenwerking met de business een succesfactor. Ook hernieuwde aandacht voor licentiebeheer, het opvolgen van benefit tracking en het beter benutten van beschikbare informatie kunnen bijdragen aan het nieuwe applicatiebeheer.

Naast het aangeven van een duidelijke richting heeft de top ook de taak om initiatieven te laten ontstaan vanuit de bestaande groepen. De grootste kans op succesvolle vernieuwing van het applicatiebeheer ontstaat als de beheerprofessionals zelf de handschoen oppakken en hun vakgebied naar het volgende niveau tillen.

Dit artikel is tot stand gekomen in samenwerking met Erik Cazemier.