Ontwerpprincipes voor de levensduur van informatiesystemen

Bij architectuur houden we ons veel bezig met het ordenen van zaken als bedrijfsprocessen, informatiesystemen en dergelijke. Dat is handig, want als je de wereld indeelt in bakjes dan kun je per bakje bepalen hoe je met bijvoorbeeld applicaties omgaat. Dat is efficiënt, bespaart daardoor kosten en helpt ook nog inconsistenties en daarmee fouten te voorkomen.Een indeling die ik niet zo vaak tegenkom is een indeling van informatiesystemen naar beoogde levensduur. Toch kan juist die indeling organisaties veel geld en narigheid besparen.

Hoe kunnen we informatiesystemen op een zinvolle wijze kunnen onderverdelen naar beoogde levensduur? Laten we eens uitgaan van –we zijn tenslotte architecten– drie lagen: de onderste laag staat voor systemen met een beoogde levensduur van meer dan 10 jaar. De bovenste laag staat voor systemen met een heel korte levensduur, zeg minder dan 3 jaar. De middelste laag staat dan voor alles wat daar tussenin zit, dus van 3 tot 10 jaar.

Hoe bepalen we in welk van de respectievelijke lagen een informatiesysteem thuishoort? Een belangrijk criterium is stabiliteit van de bedrijfsfuncties die het systeem ondersteunt. Neem bijvoorbeeld het administreren van klantgegevens. Die bedrijfsfunctie bestaat al eeuwenlang en zal er over 20 jaar ook nog wel zijn. Sterker nog, er zal ook niet veel aan veranderen. Oké, af en toe een nieuwe eigenschap of relatie maar dat zijn geen structurele wijzigingen. Een informatiesysteem dat deze bedrijfsfunctie ondersteunt, zal daarom ook jarenlang gebruikt kunnen worden zonder ingrijpende wijzigingen. Het ontwerpen en bouwen van zo’n systeem kan prima volgens de traditionele watervalmethode. Immers, de functionaliteit is al helemaal uitgekristalliseerd. Gewenste wijzigingen op zo’n systeem zullen een “zwaar” changemanagementproces door moeten waarin kwaliteitseigenschappen als betrouwbaarheid en onderhoudbaarheid van het systeem streng bewaakt worden. Dat is logisch, want dit soort systemen en de informatie die er in beheerd wordt, is bedrijfskritiek. Dat wijzigingen daarmee relatief duur zijn, is niet erg omdat de investeringen over meerdere jaren afgeschreven kunnen worden. Dit leidt tot een eerste ontwerpprincipe: de inspanningen voor realisatie van en onderhoud aan een informatiesysteem moeten in verhouding staan tot de verwachte (resterende) levensduur van dat systeem.

Een tweede ontwerpprincipe dat hier uitstekend bij past, is dat alle onderdelen (functies) van een informatiesysteem dezelfde levenscyclus moeten hebben. Zo mag in het bovenbeschreven voorbeeld van een systeem voor administratie van klantgegevens alleen stabiele functionaliteit opgenomen worden. Hippe moderniteiten zoals bijvoorbeeld socialenetwerkfuncties horen daar niet thuis. Die horen in een separaat systeem dat gerealiseerd en onderhouden wordt op een “agile” wijze die past bij de korte levenscyclus van zo’n systeem.

Voor de integratie tussen de architectuurlagen geldt het derde ontwerpprincipe dat koppelvlakken zich schikken naar de laag met de langste levenscyclus. In de meeste gevallen betekent dat het definiëren van stabiele, generieke services vanuit het perspectief van de serviceaanbieder. De architect moet daarbij verantwoordelijkheid nemen en een visie ontwikkelen op hoe de services in de toekomst gebruikt moeten kunnen worden, ook door kortlevende systemen die nu nog helemaal niet bestaan.

Erwin Oord (eoord@archixl.nl) is principal consultant en partner bij ArchiXL.