Informatietechnologie is tegenwoordig een kernonderdeel van organisaties. Bedrijfsprocessen worden mogelijk gemaakt door applicaties en gegevensverzamelingen die deze ondersteunen. Doordat de wereld continu verandert worden steeds hogere eisen gesteld aan de mate waarin de informatietechnologie kan veranderen. Dit artikel geeft een aantal concrete handvatten voor het verhogen van de veranderbaarheid van applicaties.
In alle sectoren zoeken organisaties naar manieren om meer wendbaar te worden. Dit vraagt een flexibel applicatielandschap dat snel kan worden aangepast aan veranderingen en die de bedrijfsprocessen optimaal ondersteunen. Helaas is het huidige applicatielandschap van veel organisaties niet erg flexibel. Het is gebouwd en uitgebreid over een groot aantal jaren, en gecombineerd met dat van overnames en acquisities. Het grootste deel van het it-budget wordt besteedt aan het in leven houden van deze applicaties.
Dit artikel biedt uitzicht en beschrijft hoe een applicatielandschap omgevormd kan worden tot een flexibel applicatieportfolio. Dit start met een informatie-architectuur waarin het noodzakelijke overzicht ontstaat, waarna meer inzicht in kosten en onderhoudbaarheid moet worden gecreëerd.
Reduceren en componentiseren
Een belangrijke factor om te komen tot een wendbaar applicatieportfolio is ervoor zorgen dat het aantal applicaties zoveel mogelijk wordt gereduceerd. Functionaliteit zou maar door één applicatie aangeboden moeten worden, zodat het ook maar één keer hoeft te worden onderhouden. Daarnaast zijn silo-applicaties een probleem; grote monolithische systemen, die naast specifieke functionaliteit ook allerlei generieke functionaliteit bevatten.
Deze applicaties hebben bijvoorbeeld een eigen administratie van klant- of financiële gegevens. Dit soort applicaties moeten dan ook in componenten worden opgedeeld, zodat de individuele componenten los in tijd kunnen worden vervangen door standaard oplossingen. Het is dan ook belangrijk om inzicht te krijgen in de functionaliteit van applicaties. In eerste instantie kan dit relatief grofmazig, maar uiteindelijk zal ook nauwkeuriger moeten worden gekeken naar de functies van applicaties. Daarna kunnen onnodige applicaties uitgefaseerd gaan worden en silo-applicaties worden gecomponentiseerd.
Eenduidige bronadministraties
In een flexibel applicatielandschap worden gegevens maar op één plaats gedefinieerd en onderhouden. Het is buitengewoon lastig een geïntegreerd beeld te krijgen van gegevens die op allerlei plaatsen en op verschillende manieren worden geadministreerd. Dit leidt tot allerlei complexe integraties, die uiteindelijk veel tijd en energie kosten om te ontwikkelen en te onderhouden. In veel gevallen is de noodzakelijke investering te hoog. Er wordt geaccepteerd dat administraties uit elkaar kunnen lopen en dat integratie handmatig plaats moet vinden. Met name als het gaat om financiële rapportages komt dit relatief vaak voor
Het mag duidelijk zijn dat het kloppend krijgen van dergelijke financiële rapportages buitengewoon lastig kan zijn. Het is dan ook belangrijk om duidelijke bronnen aan te wijzen voor gegevens. De eerste aandacht zou daarbij uit moeten gaan naar mastergegevens. Dit zijn de relatief stabiele gegevens die in veel verschillende processen worden gebruikt zoals gegevens over klanten, leveranciers, producten en locaties.
Integreren
Als functionaliteiten maar één keer aanwezig zijn dan zal dat leiden tot meer integraties tussen applicaties. Ook vanuit gegevensperspectief zal een optimaal applicatielandschap leiden tot meer integraties, omdat gegevens moeten worden opgehaald bij de bronapplicatie. Idealiter zijn al deze functionaliteiten beschikbaar als een service en maken ze gebruik van open integratiestandaarden. Voor veel bestaande applicaties is dat nog niet zo eenvoudig, maar applicatie-integratie middleware kan worden ingezet om daarbij te helpen.
In het ergste geval wordt op databaseniveau geïntegreerd, waarbij de applicatielogica die normaliter de consistentie bewaakt en fysieke gegevensstructuren verbergt wordt gepasseerd. Voor het aanschaffen van nieuwe applicaties is integreerbaarheid wel goed te gebruiken als selectiecriterium. Leveranciers zouden moeten aantonen dat alle functionaliteit en gegevens middels open standaarden te ontsluiten zijn.
Kosten inzichtelijk
Een belangrijke indicator voor de wendbaarheid van het applicatieportfolio zijn de kosten die gemaakt worden bij het aanbrengen van veranderingen. Verassend genoeg geeft traditionele managementinformatie relatief weinig inzicht in de kosten van applicaties. Afdelingen, organisatiedelen, projecten of programma's vormen de gebruikelijke budgetstructuur, maar de software die de uiteindelijke voordelen levert, is ergens diep in die structuur verstopt. In het ergste geval kan de link tussen de kosten en de applicaties niet worden herleid.
Een cio zou eigenlijk willen weten hoe zijn applicatieportfolio het doet ten opzichte van zijn peers. Het antwoord ligt in applicatieportfolio-analyse en -benchmarking. Dat zijn onderzoeken die als doel hebben applicaties weer naar de voorgrond te brengen en het mogelijk te maken te gaan sturen op kosten, risico's en kwaliteit. Door de kosten als uitgangspunt te nemen ontstaat een heldere en uitlegbare driver voor het uitvoeren van optimalisaties.
Onderhoudbaarheid
Een andere belangrijke indicator in de wendbaarheid van het applicatieportfolio is de onderhoudbaarheid van applicaties. Een hogere onderhoudbaarheid geeft een groter vermogen tot verandering tegen lagere kosten. Ook het jaarlijkse onderhoud op de software wordt voor een groot deel bepaald door de onderhoudbaarheid zoals gedefinieerd in de ISO 25010 standaard (opvolger van ISO 9126).
Grote (monolitische) legacy applicaties kennen meestal een zeer lage onderhoudbaarheid door het gebruik van verouderde technologie en vaak jarenlange wildgroei aan functionaliteit. Door de lage onderhoudbaarheid gaat nu veel tijd en inzet verloren aan enkel het in de lucht houden van de applicatie. Voor applicaties waarvan bekend is dat ze hoge kosten met zich meebrengen, of moeizaam veranderd kunnen worden, is het zinvol om hun onderhoudbaarheid expliciet te meten. Dit voorkomt beslissingen die worden genomen op basis van onderbuikgevoelens.
Conclusies
In dit artikel zijn een aantal perspectieven beschreven die kunnen helpen bij het verhogen van de wendbaarheid van het applicatieportfolio. De basis voor een aantal van deze perspectieven is een goede informatie-architectuur die inzicht geeft in de functionaliteiten, gegevens en afhankelijkheden in het applicatieportfolio. Deze informatie-architectuur moet worden verdiept met meer kwantitatieve gegevens over kosten en onderhoudbaarheid zodat een goed onderbouwd verbeterplan kan worden opgezet.
Danny Greefhorst, directeur ArchiXL en Computable-expert, en Magiel Bruntink, senior consultant bij Software Improvement Group
Wat een nuttig artikel.
Applicaties en de zaken hieromtrent zijn flink verweven in de ict-architectuur, businessprocessen en ook de (werk)cultuur. Deze verwevenheid maakt het altijd lastig om op korte termijn iets hieraan te kunnen veranderen. Veranderen van deze zaak vereist een visie, duidelijke aanpak en ervaring, iets wat ik duidelijk terug zie in dit artikel.
Door consolidatie van applicaties kunnen we besparing realiseren op verschillende niveau`s. Consolidatie kan ook gerealiseerd worden door het invoeren van een ERP oplossingen. In deze oplossingen zijn verschillende functionaliteiten verzameld0opgenomen waardoor een aantal van applicaties overbodig kunnen worden. Het uitfaseren van een applicatie is niet altijd eenvoudig. Dit komt ook doordat de gegevens volgens wetgeving voor x aantal jaren beschikbaar en bruikbaar moeten blijven.
Het consolideren en optimaliseren van gegevens en databronnen kan ook gerealiseerd worden wanneer een laag tussen front-end en back-end gecreëerd wordt. Deze laag is een Broker tussen deze twee werelden. Deze laag maakt verschillende applicaties overbodig, hiermee kan door 1 (web)interface verschillende informatie en data aan eindgebruikers gepresenteerd worden. Dit zorgt voor zeer flexibiliteit in beheer en integratie en ook een hulpmiddel voor verdere optimalisatie. Deze laag kan bovendien het probleem van Big Data in de toekomst verhelpen of helemaal voorkomen.
In grote lijnen helemaal mee eens. Twee aanvullingen hierop.
‘Reduceren en componentiseren’ is een goed principe, maar in praktijk minder eenvoudig dan het klinkt omdat minder niet altijd beter is. Voor de liefhebber verwijs ik naar http://simplearchitectures.blogspot.nl/2012/07/misuse-of-reuse.html van Roger Sessions die expert is op het gebied van complexiteit reduceren via componentiseren.
Bij ‘grote (monolitische) legacy applicaties’ wordt in mijn ogen vaak (te) snel geoordeeld dat die maar beter zsm moeten worden vervangen. Mijn ervaring is dat er in praktijk legio van dit type applicaties zijn die het lange tijd nog steeds prima doen (al dan niet met een toegevoegde moderne serviceschil). Ook hier geldt dus dat het heel situatieafhankelijk is wat wijsheid is.
Een prima artikel dat aandacht schenkt aan de historie in een applicatieportfolio. Dat gezegd hebbende zal echter ook gekeken moeten worden naar de oorzaak van de historie. Dit omdat functionaliteiten erg gebonden zijn aan het gedrag van de gebruikers, de mogelijkheden van platformen en afhankelijkheden in de keten. Hoewel je het niet noemt lijkt een deel van je verhaal te gaan over zoiets als een Enterprise Service Bus (ESB) welke tot doel heeft om informatie van verschillende bronnen op een gestructureerde en gestandaardiseerde manier te ontsluiten. Zeg maar het verbinden van de verschillende middleware oplossingen die je in een gemiddelde omgeving tegenkomt.
Hoe meer oplossingen in middleware je tegenkomt hoe groter de kans dat er ook enige politieke aspecten zijn waar je rekening mee moet houden bij het rationaliseren van het applicatieportfolio. Historie is namelijk ook cultuurgebonden en dus worden keuzen soms gemaakt op subjectieve in plaats van objectieve argumenten. Betreffende de standaard ISO25010 (voorheen 9126) is de wens de vader van de gedachte maar de aanname de moeder van mislukkelingen. Zo wijken de mogelijkheden voor foutopsporing in de verschillende middleware en applicaties namelijk nogal van elkaar af doordat sommige weinig tot geen zinvolle meldingen in een systeem- of applicatielog schrijven. Wendbaarheid zonder beheerbaarheid zorgt zoals we regelmatig kunnen lezen voor dure fouten.
Opnieuw een pleidooi voor servicegeoriënteerde architecturen (SOA); dit artikel had ook in 2008 geschreven kunnen worden. Vandaar dat ik de volgende opmerkingen, aanvullingen en bedenkingen wil toevoegen.
De stelling dat silo-applicaties gecomponentiseerd moeten worden gaat voorbij aan het feit dat deze systemen een sterke verwevenheid van data, logica en flow kennen; ontvlechten (ofwel ontkoppelen) en verservicen is dan – zo al mogelijk – de route naar meer flexibiliteit. In de tweede plaats is verouderde bedrijfssoftware vaak nog batchgeorienteerd, hetgeen haaks staat op het realtime willen afhandelen van klantwensen door middel van selfservice. De ontwikkelde services dienen niet meer binnen een batchvenster, maar direct op afroep en op welk platform dan ook beschikbaar te zijn.
Een tweede opmerking wil ik maken over het gebruik van het begrip ‘wendbaarheid’. In dit artikel worden ‘flexibiliteit’ en ‘wendbaarheid’ door elkaar gebruikt, waarmee deze begrippen dezelfde betekenis lijken te hebben. Mijns inziens verschillen deze begrippen echter fundamenteel van elkaar, en wel zodanig dat het niet zinvol is om te spreken van ‘wendbaarheid’ ten aanzien van organisaties of applicaties.
Zoek je een begrip als ‘wendbaarheid’ op in een willekeurig woordenboek, dan wordt vaak als voorbeeld ‘een wendbaar vliegtuig’ gegeven. Inderdaad is een vliegtuig, afhankelijk van gewicht en motorvermogen, meer of minder wendbaar. Van flexibele vliegtuigen heb ik daarentegen nog nooit gehoord.
‘Wendbaarheid’ wordt mijns inziens gebruikt voor dingen met het oog op de mate van bestuurbaarheid, beheersbaarheid, etc. door een mens.
Anderzijds is het heel gebruikelijk om mensen of organisaties (als samenwerkings-verbanden van mensen) meer of minder flexibel te noemen en is ‘wendbaarheid’ hier niet van toepassing.
De reden dat in dit artikel ook ten aanzien van applicaties nog steeds van wendbaarheid wordt gesproken is het feit dat nog niet de sprong is gemaakt van informatie-architectuur naar kennisarchitectuur. De omslag van procesgericht naar doelgericht, servicegericht, klantgericht denken heeft zich hier nog niet voltrokken, en daardoor lost SOA haar belofte van flexibiliteitsverhoging en complexiteitsreductie nog steeds niet in.