Beheer

IT beheer

Grote schoonmaak

16 september 2011

Het is een beproefd middel om CIO’s in de ziel te raken: vraag ze hoe het ervoor staat met hun bestaande applicaties. Grote kans dat er een onderlip gaat trillen of heimelijk een zakdoek tevoorschijn wordt gehaald. De grootste kopzorgen van de IT-afdeling zitten niet in het verzinnen van nieuwe, innovatieve toepassingen. Ook de samenwerking tussen bedrijfsvoering en IT – van oudsher een heikel onderwerp – prijkt niet meer boven aan de prioriteitenlijst. Alles staat in de schaduw van de last van de bestaande IT-huishouding. En waar het infrastructurele deel daarvan vaak met succes door de IT-directie wordt opgepakt om te vereenvoudigen en te ontdubbelen, blijkt het applicatielandschap een nauwelijks te kraken noot.

Toch valt er een hoop te winnen met het rationaliseren van applicaties. Het overgrote deel van het IT-budget gaat op aan het onderhouden en ‘in de lucht houden’ van bestaande applicaties. Veel van die toepassingen zijn gebaseerd op verouderde technologie, zijn zo complex geworden dat ze slechts door enkelen worden doorgrond of bieden functionaliteit die deels ook door andere applicaties in het bedrijf wordt afgedekt. Het potentieel van kostenbesparing is daarmee groot. Maar er valt nog meer te bereiken dan dat: een afgeslankt applicatielandschap biedt een veel beter fundament voor nieuwe en innovatieve toepassingen, niet alleen door de toegenomen flexibiliteit maar eveneens door de ruimte die vrijkomt in de projectenportfolio en het budget. Versimpeling en standaardisatie helpen de CIO bovendien de risico’s te beheersen van ondoorgrondelijke, ontoegankelijke toepassingen en de afhankelijkheid van een slinkend groepje ingewijde experts.

Alles in overweging nemend, is het begrijpelijk waarom applicatierationalisatie zoveel in de belangstelling staat. Het ironische is dat opruimen een tot nu toe weinig bekend ambacht is in het vakgebied. De curricula van IT-opleidingen richten zich vooral op de nieuwbouw van toepassingen – op het maken van rommel, zeg maar – en met een beetje geluk op het onderhouden en beheren ervan. Het idee dat een applicatielandschap eigenlijk voortdurend versimpeld en bijgesteld moet worden, is nieuw en kent nog weinig weerklank in methoden en technieken. CIO’s onderkennen dit. Het openbreken en radicaal vernieuwen van applicaties lijkt een onoverzichtelijke, risicovolle activiteit die misschien maar beter kan worden uitgesteld; bijvoorbeeld tot een opvolger aantreedt.

Stapsgewijs
Toch wordt er in de praktijk vooruitgang geboekt, vooral met aanpakken die meer stapsgewijs de grote schoonmaak uitvoeren. Door het bestaande applicatielandschap als een organisch geheel – met een eigen levenscyclus – te zien dat steeds weer vernieuwd en verbeterd kan worden, wordt het pad geëffend voor een palet van rationalisatiescenario’s. Bij elke stap wordt gekozen voor een of meerdere scenario’s, waarbij de businesscase en architectonische richting helpen om prioriteiten te stellen. De inspanning van zo’n rationalisatieslag moet overzienbaar zijn en het resultaat moet steeds helder en meetbaar zijn. Applicatierationalisatie wordt zo een continue activiteit van de IT-afdeling die steeds opnieuw energie en inspiratie geeft.

Hoewel elke rationalisatieslag op zich een uniek pad volgt, is het methodisch gezien handig om verschillende categorieën van scenario’s te onderscheiden. Dat helpt bij het nemen van beslissingen en geeft meer garantie dat veelbelovende aanpakken niet over het hoofd worden gezien. Er zijn acht rationalisatiescenario’s te onderscheiden.

  1. Pappen en nathouden
    Het stabiliseren en in leven houden van bepaalde applicaties lijkt niet het meest gewaagde pad. Toch is het al moeilijk genoeg om simpelweg controle te hebben over het applicatielandschap. De drijfveer is hier kostenbesparing, maar vooral ook risicobeheersing. Niet zelden begint dit scenario eenvoudigweg met het documenteren van cruciale applicaties. Verder kan besloten worden om voortaan slechts een miniem aantal aanpassingsvoorstellen te honoreren, bijvoorbeeld alleen maar als ze betrekking hebben op kennelijke fouten of op onontkoombare wijzigingen in wet- en regelgeving. Elke andere wijziging dient buiten de geselecteerde applicaties te worden doorgevoerd, bijvoorbeeld met behulp van portals of businessprocesmanagement (BPM)-oplossingen. Deze strategie vereist wel uitzicht op beëindiging van de betreffende applicaties, bijvoorbeeld in de vorm van vervanging door een standaardpakket over een paar jaar.
  2. Verbouwen
    Het verbeteren van de structuur van applicaties kan de levensduur verlengen en de onderhoudbaarheid verbeteren. Verbouwingsacties kunnen preventief zijn, bijvoorbeeld door het inzetten van codeanalysetools om stukken ‘dode’ software te vinden die niet worden gebruikt of gevaarlijk complex zijn. In het geval van ERP kan verbouwing nog weleens helpen om buitenissige aanpassingen en uitbreidingen terug te draaien (ook wel aangeduid met het fraaie ‘decustomization’), mogelijk om een upgrade naar een verbeterde, meer standaardversie van het pakket makkelijker te maken. Verbouwen kan ook tot doel hebben de flexibiliteit van de applicaties te verhogen: door het toevoegen van webservices en aansluiting op een Enterprise Service Bus (ESB) wordt het veel makkelijker om aansluitingen te maken vanuit andere toepassingen.
  3. Veranderen van platform
    Het overbrengen van applicaties naar een andere, modernere infrastructuur kan alleen al grote kostenbesparingen opleveren. COBOL-toepassingen die op een setje ‘blades’ met Linux draaien in plaats van op een mainframe, vereisen vaak slechts een fractie van de oorspronkelijke infrastructuurkosten. Het is doorgaans ook makkelijker om personeel te vinden dat gespecialiseerd is in modernere platformen. Verandering van spijs doet bovendien eten: de applicaties zullen op zijn minst in kaart moeten worden gebracht en doorgelicht voordat ze naar het nieuwe platform kunnen worden overgezet. Een ideaal moment om vast te stellen of de applicatie werkelijk nog wel nodig is. Dit is niet alleen het geval aan de ‘serverkant’: de migratie naar Windows 7 biedt bijvoorbeeld ook uitstekende gelegenheden om iets te doen aan een uit de hand gelopen verzameling van desktoptoepassingen. Evenzeer biedt de huidige golf van migraties naar de cloud zulke perspectieven.
  4. Veranderen van taal
    Dit scenario heeft iets weg van het voorgaande. Bestaande toepassingen die zijn geschreven in archaïsche, slecht te onderhouden programmeertalen worden gemigreerd naar meer moderne varianten, vaak Java of een .NET-programmeertaal. De voordelen lijken evident: het is makkelijker om gespecialiseerd IT-personeel te vinden en gemotiveerd te houden, de continuïteit van de software is voorlopig weer geborgd, het onderliggende infrastructuurplatform is vaak goedkoper en vanuit de nieuwe talen is het makkelijker om toegang te krijgen tot webservices en mobiele kanalen. Veel hangt echter af van de kwaliteit van de gebruikte migratietools: in veel gevallen is een migratie alleen haalbaar met een hoge graad van automatisering en de bronapplicaties moeten geschikt zijn om verwerkt te kunnen worden. Het is dan bovendien de vraag of de aldus gegenereerde software wel zoveel beter onderhoudbaar is, zelfs als het om de nieuwste programmeertaal gaat.
  5. Consolideren
    Als je als organisatie maar genoeg hebt overgenomen en gefuseerd, krijg je vanzelf een portfolio van applicaties op verschillende infrastructuren die deels hetzelfde doen, overlappen of – erger nog – tegenstrijdige functionaliteit bevatten. Het in elkaar schuiven van applicaties is dan de voor de hand liggende oplossing. Voor elk functioneel gebied wordt één applicatie geselecteerd; de data van andere applicaties die dezelfde functionaliteit invullen, worden gemigreerd naar de nieuwe ‘master’-toepassing. Afhankelijk van de organisatorische structuur kan ook worden gekozen voor een centraal, consoliderend systeem en diverse decentrale ‘satelliet’-toepassingen die daarmee periodiek worden gesynchroniseerd. Consolideren lijkt een nuchtere, op feiten gebaseerde exercitie, maar weinig scenario’s leiden tot meer emoties en politieke afwegingen, vooral als de gemaakte keuzes dwars door de oorspronkelijke bloedgroepen van de organisatie snijden.
  6. Vervangen
    Veel oudere toepassingen werden in een tijd gebouwd dat hun functionaliteit nog als uniek en onderscheidend werd gezien; het was daarom zaak de software met grote zorgvuldigheid zelf te maken en als een kleinood te koesteren. De raderen van de tijd draaien echter onverbiddelijk door en standaardoplossingen doen hetzelfde – of meer en beter – tegen een fractie van de kosten van de zelfgebouwde toepassing. Vervangen is echter niet eenvoudig: de data moeten worden gemigreerd en de bedrijfsvoering zal hoe dan ook moeten worden aangepast aan de standaardoplossing. Toch is de businesscase vaak zo aantrekkelijk en overtuigend dat veel creativiteit is vereist om vast te houden aan bestaande processen ‘omdat we nu eenmaal altijd zo gewerkt hebben’. Een nieuwe lichting CIO’s onderscheidt zich momenteel met een ‘standard or explain’-strategie: verklaar vooral waarom jouw situatie zó bijzonder is dat een standaardoplossing niet volstaat.
  7. Uitbreiden
    Het mag dan chic zijn om serviceoriëntatie af te doen als ‘mislukt’, feit is dat de nieuwe generatie open interfaces tot bijna alle applicaties is doorgedrongen, of ze nu zelfgebouwd zijn of van een pakkettenleverancier komen. En dat biedt de gelegenheid om nieuwe functionaliteiten toe te voegen, zonder dat grootscheepse veranderingen in het applicatielandschap hoeven te worden doorgevoerd. Met behulp van bijvoorbeeld portals, mashups, mobiele platforms en businessproces/rulesmanagementtools kan razendsnel worden gereageerd op wijzigingsvoorstellen zonder dat basisapplicaties hoeven te worden aangepast. Zo blijven die silo’s wat ze horen te zijn: simpel, standaard en gericht op de langere termijn.
  8. Pensioneren
    Een opmerkelijk taboe in IT-kringen ten slotte, blijkt het feitelijk stopzetten van applicaties. Zelfs grote, professionele IT-afdelingen blijken vaak geen draaiboeken te hebben voor zulke gelegenheden. Toch hebben steeds meer CIO’s letterlijk het terugdringen van het aantal applicaties op hun KPI-contract staan en daarmee is de jacht op mogelijk te pensioneren toepassingen geopend. Om applicaties te kunnen stoppen is allereerst hard, feitelijk inzicht nodig in welke toepassingen beschikbaar zijn, hoe vaak ze gebruikt worden en met welke andere applicaties ze verbonden zijn. Samen met overwegingen rond wet- en regelgeving kan zo een lijst met de meest geschikte kandidaten worden opgesteld. De data van te pensioneren applicaties zullen mogelijk nog moeten worden gearchiveerd voordat uiteindelijk de sleutel uit het contact kan worden getrokken: weer een slachtoffer van de ’application-number-hunt’.

Ron Tolido is chief technology officer van Capgemini’s Application Services voor Europa.

 
Lees het hele artikel
Je kunt dit artikel lezen nadat je bent ingelogd. Ben je nieuw bij AG Connect, registreer je dan gratis!

Registreren

  • Direct toegang tot AGConnect.nl
  • Dagelijks een AGConnect nieuwsbrief
  • 30 dagen onbeperkte toegang tot AGConnect.nl

Ben je abonnee, maar heb je nog geen account? Neem contact met ons op!