Applicatierationalisatie: een eufemisme

Applicatierationalisatie: een eufemisme
‘Applicatierationalisatie’ is een kreet waar u in de bestuurskamer mee aan kunt komen. Hij straalt daadkracht en beheersing uit, maar dat is slechts schijn. Applicatierationalisatie is geen quick win. U dient de processen die geleid hebben tot de chaos in de greep te krijgen én te houden.
U hebt applicatierationalisatie nodig? Dan hebt u in het verleden forse steken laten vallen. Applicatierationalisatie verhoudt zich namelijk tot goed beheer als een maagverkleining tot gezond eten. Uw enterprisearchitecten hebben misschien lopen dutten, uw productmanagers waren vast op vakantie en van interfacemanagement hebt u waarschijnlijk nog nooit gehoord. En toen lag er ineens dat glanzende foldertje op uw bureau met de titel ‘Applicatierationalisatie’.
Laat mij u onmiddellijk uit de droom helpen: als u na afloop van uw applicatierationalisatie uw zaakjes nog steeds niet op orde hebt, kunt u over een paar jaar dat beduimelde foldertje opnieuw uit uw la halen, want dan bent u er wel weer aan toe. U dient namelijk de processen die geleid hebben tot de chaos in de greep te krijgen én te houden.
Zo min mogelijk applicaties
Applicatierationalisatie moet je vanuit twee perspectieven benaderen: de applicatiecomponent en de gegevenscomponent. Laten we ons eerst eens concentreren op de applicatiecomponent. Een applicatie is niet zomaar uw organisatie binnengekomen. Zij ondersteunt op de een of andere manier een bedrijfsproces door een bepaalde functionaliteit te bieden. Een tekstverwerker bijvoorbeeld voorkomt dat uw medewerkers hun nota’s en memo’s met pen en papier moeten schrijven en maakt tevens een typekamer overbodig. Dat verhoogt de productiviteit, wat het lonend maakt om een tekstverwerker aan te schaffen.
Die productiviteit wordt echter weer verlaagd als er verschillende tekstverwerkers in uw organisatie rondzwerven. Zeker als die niet onderling compatibel zijn. Wellicht wordt het daardoor noodzakelijk om conversieprogramma’s te introduceren. Vaak zijn die niet perfect, waardoor medewerkers alsnog correcties moeten aanbrengen. Op sommige plekken zal het noodzakelijk zijn om twee tekstverwerkers te installeren. Dat maakt het allemaal behoorlijk complex en dus niet erg efficiënt.
Als u dan nog eens toestaat dat er verschillende versies van die tekstverwerkers zijn, maakt u uw leven helemaal onmogelijk. Die versies hebben namelijk allemaal hun eigen patches, die getest en uitgerold moeten worden, allemaal hun eigen eigenaardigheden en bekende problemen en mogelijk zijn ook de fileformaten niet geheel uitwisselbaar tussen de verschillende versies.
U begrijpt nu waarschijnlijk wel waar ik naartoe wil: het is noodzakelijk om per functionaliteit het aantal applicaties en versies tot het absolute minimum te beperken. Daar hebt u een beheersorganisatie voor nodig. Een van de belangrijkste taken van een beheersorganisatie is dat zij het applicatielandschap volledig in beeld heeft. Welke functionaliteiten zijn er, met welke producten worden die ondersteund en welke versies worden er gebruikt? Als u dat niet in kaart hebt, hebt u een vet probleem.
 
Krachtenveld in beeld
De volgende vraag is: weet u ook waar al die applicatieversies zich bevinden binnen uw organisatie en wie ze gebruikt? Ook al niet? Hoe wilt u ze dan gaan wegsaneren? Hoe wilt u er dan achter komen of ze weg kunnen zonder dat er een cruciaal bedrijfsproces omvalt?
Al deze vragen kunnen zonder probleem beantwoord worden als u het betreffende ASL-beheerproces fatsoenlijk hebt ingericht (figuur 1). Zowel de producten, de versies als de onderliggende installaties zijn dan allemaal voorzien van een status, zodat bijvoorbeeld duidelijk is of u het product nog wel wilt, de versie nog wel wilt en de installatie nog wel nodig hebt. Kijk, nu krijgen we een beetje een beeld van het krachtenveld waar we ons in bevinden.
Figuur 1. Relatie tussen ASL-beheergebied en objecten van beheer

Maar we zijn er nog niet. Veel softwareproducten worden wel gebruikt binnen een applicatie, maar leveren geen directe bijdrage aan een bedrijfsproces. Denk daarbij aan webserver- of databaseprogrammatuur. Hebt u in beeld waar MySQL v5.0.52 allemaal onder zit? Nee? Dan zou ik dat maar eens helder proberen te krijgen. Stel dat u gedwongen bent om naar een hogere versie te migreren omdat de leverancier het product binnenkort niet meer ondersteunt. Weet u dan wat er allemaal geraakt wordt? Of stel dat u helemaal van MySQL af wilt en wilt standaardiseren op DB2. Weet u of dat wel ondersteund wordt door alle applicaties? Dit zijn allemaal vragen die u moet zien te beantwoorden als u zich op het pad van applicatierationalisatie begeeft.
Troost u, als u aan applicatierationalisatie wilt gaan doen hoeft u niet het gehele spectrum in kaart te hebben. U kunt ook een beetje rationaliseren, bijvoorbeeld door het aantal versies per product of het aantal installaties per versie terug te brengen. Dat levert al een aardige besparing op. Een centraal aangeboden applicatie maakt het veel gemakkelijker om onderhoud te plegen, en als er onverhoopt iets fout gaat is het veel eenvoudiger om de oorzaak te achterhalen. Ook het licentiebeheer is veel simpeler. Immers, alle licenties zijn gerelateerd aan een enkele installatie. Tel uit je winst.
Ook uw gegevens rationaliseren?
Een veelgehoorde uitspraak is dat minder applicaties ook uw gegevensbeheer eenvoudiger maakt. Als u dat gelooft, dan raad ik u aan een Maserati te kopen, aangezien alleen rijke mensen een Maserati hebben. Maar net zomin als u automatisch rijk wordt van de aanschaf van een dure bolide, wordt uw gegevensbeheer automatisch eenvoudiger als u zich op applicaties concentreert. Het heeft wel met elkaar te maken, maar oorzaak en gevolg zitten net even iets anders in elkaar. Met andere woorden: als u uw informatielandschap wilt rationaliseren, rationaliseer dan uw informatielandschap. Niet uw applicatielandschap.
Een gemiddeld bedrijf houdt behoorlijk wat gegevens bij: over werknemers, klanten, adressen, kamers, computers, kostensoorten, budgetnummers enzovoort. Elk van die gegevensverzamelingen valt onder de verantwoordelijkheid van één enkele afdeling (figuur 2). Oeps, is dat bij u niet het geval? Dan zou ik dat meteen maar regelen. U zegt dat dat helemaal niet kan? Mogelijk haalt u een paar dingen door elkaar. Om maar een voorbeeld te geven: wat een programmeur beheert is niet hetzelfde als wat een systeembeheerder beheert en ook wat anders dan wat er in uw producten-en-dienstencatalogus staat, al noemt u het honderdduizend keer bij dezelfde naam. Een mooie opdracht voor uw enterprisearchitecten om dat plaatje helder te krijgen.
Figuur 2. Verantwoordelijkheden: praktijk en theorie
 
Single point of truth
Het feit dat verschillende afdelingen dezelfde gegevensverzameling bewerken verandert niets aan dit uitgangspunt. Stel, een klant meldt bij de helpdesk dat de gegevens die u van hem registreert niet correct zijn. Dat maakt een helpdeskmedewerker nog niet verantwoordelijk voor het beheer van de klantgegevens; hij is alleen een toeleverancier. De beste man dient dus de klantgegevens te verzamelen op de wijze die de verantwoordelijke afdeling (laten we zeggen de verkoopafdeling) heeft voorgeschreven en deze gegevens naar haar toe te spelen. Als u er echt op staat mag hij ze ook corrigeren in de betreffende applicatie, maar bedenk wel dat hiermee een functionele verantwoordelijkheid ontstaat van de betreffende helpdeskmedewerker tegenover de verkoopafdeling. Deze afdeling wordt immers aangesproken op de kwaliteit van de klantgegevens.
Wat u in dat geval gecreëerd hebt, is een single point of truth ; er is maar één plek in het bedrijf waar u de ‘echte’ klantgegevens vindt en dat is bij de verkoopafdeling. Alle andere klantgegevens in het bedrijf zijn daarvan afgeleid. Aangezien de verkoopafdeling zich wel twee keer zal bedenken voor zij twee applicaties aanschaft om klantgegevens in vast te leggen, brengt u daarmee het aantal applicaties voor het onderhoud van klantgegevens terug tot één. Oorzaak en gevolg, begrijpt u?
Natuurlijk heeft de helpdesk wel behoefte aan klantgegevens, aangezien hij geen ondersteuning wil leveren aan niet-betalende gebruikers. Waarschijnlijk gebruikt de helpdesk een andere applicatie dan de verkoopafdeling. Ik weet het: de verleiding is groot om te kijken of er een applicatie is die zowel de helpdesk als de verkoopafdeling ondersteunt. Maar dat is een heilloze weg. De verkoopafdeling heeft uiteraard ook een relatie met de financiële afdeling en voordat u het weet bent u op zoek naar de mythische ‘Applicatie van Alles’. De pogingen die daar in het verleden toe ondernomen zijn, hebben geleid tot onbestuurbaar geworden stuurgroepen in grote vergaderzalen en rijke consultants. Dat is dus een weg die u zeker níét wilt bewandelen. De oplossing is om de klantgegevens van de verkoopafdeling te importeren in de helpdeskapplicatie middels een interface. De vraag daarbij is hoe snel de klantgegevens beschikbaar moeten zijn in de helpdeskapplicatie. Is dat onmiddellijk, dan lijkt een service-oriented-architectureinterface de aangewezen weg. Mag het een dagje duren, dan kunt u de gegevens ’s nachts overhalen.
 
Gegevens aanspreken
De crux zit hem in het gebruik van de klantgegevens, en dat wordt gedicteerd door het ondersteunde bedrijfsproces. Daar moet u dus zicht op hebben. Toegegeven, er zijn niet veel methodieken die u daarbij ondersteunen. De enige die ik gevonden heb is de Ensoranalysemethodiek. Deze geeft antwoord op de volgende vragen, op basis waarvan u de functionele vereisten van de interface kunt opstellen:
• Op welk moment moeten de gegevens beschikbaar zijn?
• Hoe belangrijk is het voor een bepaald bedrijfsproces dat de gegevens up-to-date zijn?
• Welk deel van de organisatie moet inzicht hebben in die gegevens?
• Hoe vaak worden die gegevens geraadpleegd?
• Wie mag die gegevens veranderen?
• Hoe vaak worden die gegevens veranderd?
Uiteraard zijn we er dan nog niet. Veel applicaties zijn uit een commercieel oogpunt gemaakt en bieden maar beperkte mogelijkheden om gegevens te im- of exporteren. Sterker nog: veel aanbieders verbíéden u zelfs om de onderliggende gegevensverzamelingen aan te spreken. We noemen dat ‘silo’s’, applicaties die binnen de eigen systeemgrenzen allerlei functionaliteiten bieden maar het vertikken om met de buitenwereld te communiceren. Als u dan toch bezig bent om uw applicatielandschap op te schonen, zorg dan dat u de silo’s als eerste wegrationaliseert.
Een andere tactiek waar applicatieleveranciers zich van bedienen, is het zwaan-kleef-aanprincipe. Een applicatie wil wel communiceren met de buitenwereld, maar alleen als het een applicatie betreft van dezelfde leverancier. Een betere garantie voor een vendor lock-in bestaat er niet.
Metastandaardisatie
Als u een complex applicatielandschap hebt, kunt u een punt bereiken waarop het aantal interfaces u toch boven het hoofd groeit. Op dat moment kan een enterprise service bus een oplossing zijn om de logistieke problemen het hoofd te bieden. Een enterprise service bus is een stuk middleware dat de communicatie tussen diverse applicaties voor u afhandelt op een gecontroleerde en beheersbare wijze.
Maar er hoort nog een verhaal bij. U zult moeten zorgen dat elk attribuutje op de juiste plaats terechtkomt en in elke applicatie ook hetzelfde betekent. Betekent ‘straat’ in de ene applicatie hetzelfde als ‘adres’ in de andere? Zit in ‘adres’ ook ‘huisnummer’ verstopt? Bevat ‘huisnummer’ ook ‘huisnummertoevoeging’? En welke standaard gebruikt u – of gebruikt u geen standaard? Leuk als de ene medewerker ‘’s-Gravenhage’ intikt en de andere ‘DEN HAAG’. Het wordt uiteraard hilarisch als u lijsten probeert te maken van de hoeveelheid klanten per gemeente. U begrijpt me wel: dat betekent weer werk voor uw enterprisearchitecten.
Die metastandaardisatie helpt u zelfs als u te maken hebt met verschillende divisies over verschillende landen, die als gevolg van afwijkende wetgeving wel verschillende applicaties móéten gebruiken. Want zodra de gegevens in een vast XML-formaat over de lijn komen, maakt het eigenlijk niet meer uit wat zich aan de andere kant bevindt.
Conclusie
‘Applicatierationalisatie’ klinkt als een quick win , maar dat is het zeker niet. U moet zichzelf vragen stellen die u eigenlijk allang had moeten beantwoorden en u dient alsnog processen in te richten die reeds lang ingericht hadden moeten zijn. Immers, uw organisatie staat niet stil. Morgen zal er vast weer iemand voorbijkomen die een specifieke functionele behoefte heeft. En als u dan niet over de processen en gegevens beschikt om daar een gefundeerd oordeel over te kunnen vellen, zult u niets anders kunnen doen dan de betreffende wens te honoreren, met alle risico’s van dien.
Goed georganiseerde bedrijven zijn daarom in staat om na bijvoorbeeld een fusie een analyse te maken van het toegevoegde applicatieportfolio, dat te mappen op het reeds beschikbare applicatieportfolio en daarmee een onderbouwd en gestructureerd conversie- en migratieplan op te stellen. Dat doen ze namelijk elke dag, bij elke aanvraag. Dat is hun werk.
 
Hans Bezemer is configuratiemanager bij Ordina (thebeez@xs4all).

Tag

Onderwerp



Niet gevonden? Vraag het de redactie!

Heeft u het antwoord op uw vraag niet gevonden, of bent u op zoek naar specifieke informatie? Laat het ons weten! Dan zorgen we ervoor dat deze content zo snel mogelijk wordt toegevoegd, of persoonlijk aan u wordt geleverd!

Stel uw vraag