1. 48
informatie/september2012
i
applicatie
rationalisatie
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 per-
spectieven 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 tekst-
verwerker bijvoorbeeld voorkomt dat uw mede-
werkers 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 com-
patibel zijn. Wellicht wordt het daardoor noodza-
kelijk om conversieprogramma’s te introduceren.
Vaak zijn die niet perfect, waardoor medewerkers
alsnog correcties moeten aanbrengen. Op som-
mige 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 uit-
wisselbaar 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 beheers-
organisatie 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.
Applicatierationalisatie:
een eufemisme
Organisaties
moeten alsnog
vragen stellen en
processen inrichten
‘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.
Hans Bezemer
2. informatie/september2012
49
Krachtenveld in beeld
De volgende vraag is: weet u ook waar al die
applicatieversies zich bevinden binnen uw orga-
nisatie 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 beant-
woord worden als u het betreffende ASL-beheer-
proces fatsoenlijk hebt ingericht (figuur 1).
Zowel de producten, de versies als de onderlig-
gende 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.
Maar we zijn er nog niet. Veel softwareproducten
worden wel gebruikt binnen een applicatie, maar
leveren geen directe bijdrage aan een bedrijfs-
proces. Denk daarbij aan webserver- of database-
programmatuur. 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 bin-
nenkort 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 rationa-
liseren, 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 installa-
tie. Tel uit je winst.
Ook uw gegevens rationaliseren?
Een veelgehoorde uitspraak is dat minder applica-
ties 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 auto-
matisch rijk wordt van de aanschaf van een dure
bolide, wordt uw gegevensbeheer automatisch
eenvoudiger als u zich op applicaties concen-
treert. Het heeft wel met elkaar te maken, maar
oorzaak en gevolg zitten net even iets anders in
Samenvatting
Bij applicatierationalisatie draait het erom per functionaliteit het aantal applicaties
en versies tot een minimum te beperken. Ook moet bekend zijn waar software zich
bevindt en wie deze gebruikt. De benodigde gegevens worden tussen afdelingen
uitgewisseld met interfaces. Een enterprise service bus kan hierbij handig zijn.
Functionaliteit
Product
Versie
Installatie
tekstverwerking
LyX
geïnstalleerd op
server nr. 1
applicatieportfolio-
management
applicatielifecycle-
management
configuratie-
managementgeïnstalleerd op
server nr. 2
geïnstalleerd op
server nr. 3
LyX 1.5
(end of life)
LyX 1.6
(voorkeur)
LyX 2.0
(in test)
Figuur 1. Relatie tussen ASL-beheergebied en objecten van beheer
3. informatie/september2012
50
i
applicatie
rationalisatie
elkaar. Met andere woorden: als u uw informatie
landschap wilt rationaliseren, rationaliseer dan
uw informatielandschap. Niet uw applicatieland-
schap.
Een gemiddeld bedrijf houdt behoorlijk wat
gegevens bij: over werknemers, klanten, adressen,
kamers, computers, kostensoorten, budgetnum-
mers enzovoort. Elk van die gegevensverzamelin-
gen 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.
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 helpdeskmede-
werker nog niet verantwoordelijk voor het beheer
van de klantgegevens; hij is alleen een toeleveran-
cier. 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 verant-
woordelijkheid ontstaat van de betreffende help-
deskmedewerker 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 ver-
koopafdeling zich wel twee keer zal bedenken voor
zij twee applicaties aanschaft om klantgegevens in
vast te leggen, brengt u daarmee het aantal appli-
caties 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. Waarschijn-
lijk 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, heb-
ben geleid tot onbestuurbaar geworden stuurgroe-
pen 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 helpdesk
applicatie middels een interface. De vraag daarbij
is hoe snel de klantgegevens beschikbaar moeten
zijn in de helpdeskapplicatie. Is dat onmiddel-
lijk, dan lijkt een service-oriented-architecture-
interface de aangewezen weg. Mag het een dagje
duren, dan kunt u de gegevens ’s nachts overhalen.
Verantwoordelijkheden:
waar ze vaak liggen … … en waar ze eigenlijk horen te liggen!
hrm financial
services
hrm financial
services
technical
support
sales order desk order desktechnical
support
sales
mede-
werkers
mede-
werkers
mede-
werkers
claims
cliënten
cliënten
cliënten
cliënten cliënten
orders
orders
orders
cliënten
facturen facturen
betalingen betalingen
incidenten incidenten
incidenten
mede-
werkers
claims
Figuur 2. Verantwoordelijkheden: praktijk en theorie
4. informatie/september2012
51
Gegevens aanspreken
De crux zit hem in het gebruik van de klantge-
gevens, en dat wordt gedicteerd door het onder-
steunde bedrijfsproces. Daar moet u dus zicht op
hebben. Toegegeven, er zijn niet veel methodieken
die u daarbij ondersteunen. De enige die ik gevon-
den 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 beschik-
baar zijn?
• Hoe belangrijk is het voor een bepaald bedrijfs-
proces dat de gegevens up-to-date zijn?
• Welk deel van de organisatie moet inzicht heb-
ben 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 gegevens-
verzamelingen aan te spreken. We noemen dat
‘silo’s’, applicaties die binnen de eigen systeem-
grenzen allerlei functionaliteiten bieden maar het
vertikken om met de buitenwereld te communice-
ren. Als u dan toch bezig bent om uw applicatie-
landschap 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 garan-
tie 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 moe-
ten 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 enterprisear-
chitecten.
Die metastandaardisatie helpt u zelfs als u te
maken hebt met verschillende divisies over ver-
schillende 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 beant-
woorden 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 applicatie-
portfolio en daarmee een onderbouwd en gestruc-
tureerd conversie- en migratieplan op te stellen.
Dat doen ze namelijk elke dag, bij elke aanvraag.
Dat is hun werk.
Hans Bezemer
Bezemer is configuratiemanager bij Ordina (thebeez@xs4all).
»Veel softwareproducten
leveren geen directe bijdrage
aan een bedrijfsproces«
