Review en Audit van een ICT Architectuur

Review van ICT Architectuur

Op dit moment ben ik voor een klant een applicatie aan het reviewen, maar ook aan het beschrijven. Ik gebruik daarvoor een deel van de zaken die beschreven worden in Reviewen en auditen van architectuur.
Dit artikel is geschreven door Harm Verschuren.

Hoewel de focus van mijn review meer in het beschrijven van de functionaliteiten van één van de applicaties van mijn klant betreft, blijkt ook hier dat in deze organisatie documentatie een achterstand heeft, maar wat belangrijker is er ook niet een echt goed mechanisme is om documentatie vast te leggen.


Releasing met de juiste documenten en het terug vinden van de juiste documenten die bij een release horen is veelal handwerk.

Dependency Structure Matrix als start voor review van ICT Architectuur

Bij aanvang van de opdracht heb ik Lattix gebruikt om inzicht te krijgen in de structuur van de applicatie, waardoor ik een gevoel kreeg van de complexiteit van de architectuur. Daarna volgde veel interviews met gebruikers van het systeem, om vanuit die optiek de functies van het systeem vast te leggen. In een grote organisatie is het van belang zo veel mogelijk mensen te spreken, omdat iedereen maar een deel van de functionaliteit kent en/of gebruikt. Er blijken maar zeer weinig mensen te zijn die een totaal overzicht hebben over de functies van een applicatie in de context van de werkprocessen.

 Gedurende het uitwerken van de functionaliteiten heb ik regelmatig in de Dependency Structure Matrix gekeken om te zien of de functies inderdaad binnen de aangegeven subsystemen valt. Ook zijn door de Matrix nog onbeschreven functies aan het licht gekomen en als nog beschreven. 

Het resultaat heeft geleidt tot een eerste versie van een redelijk complete beschrijving die gereed was om middels een review (Fagan Inspectie) een hogere kwaliteit te krijgen. 

 Mijn opdrachtgever heeft hierdoor een uitgangspunt gekregen om nieuwe versies van de applicatie te kunnen beschrijven.

 

Fagan inspecties, waar zijn zij gebleven?

Resultaat van een Fagan Inspectie

Recentelijk las ik het arikel van oud-collega's Hans Sassenburg en Peter Wijnhoven m.b.t. dit onderwerp in Informatie. 

Terwijl ik dit aan het lezen was realiseerde ik mij dat het al weer lang geleden is dat ik een Fagan inspectie heb uitgevoerd. Heeft dit te maken met de projecten waar ik de laatste tijd mee bezig ben? Ik denk het wel, het is mij opgevallen dat softwareproductie steeds belangrijker wordt, maar dat er meestal niet expliciet om een hogere kwaliteit (in termen van stabiliteit, onderhoudbaarheid en aanpasbaarheid) gevraagd wordt. Met andere woorden de softwaregebruiker vindt het al snel goed, blijkbaar.

Functionele eisen zijn makkelijk te onderkennen, denken we, maar niet-functionele eigenschappen worden veelal niet benoemd. Ik durf te beweren dat de niet-functionele eigenschappen de werkelijke kwaliteit van een systeem bepalen en daarmee een belangrijke bijdrage hebben voor een goede ICT architectuur.

Door het uitvoeren van stringente reviews van requirements en designs conform de werkwijze van Fagan inspecties worden conceptuele fouten, ommissies en fouten vroeger in het realisatietraject gevonden. Hoe eerder deze fouten gevonden worden deze te geringer de herstelkosten.

Kortom Fagan inspecties zijn belangrijk om nauwgezet te worden uitgevoerd. Het niet uitvoeren van Fagan inspecties is een gemiste kans om fouten uit ICT archtitecturen te halen.

Six Sigma en ICT Architectuur

Na het lezen van het artikel: 3 argumenten voor Six Sigma in de ICT ben ik er van overtuigd geraakt dat het mogelijk moet zijn om met minder afspraken toch ook een betere ICT architectuur te realiseren. Het continu verbeteren van probleempunten door toepassing van metingen en het optimaliseren van Six Sigma resultaten is niet echt heel moeilijk en vooral inzichtelijk.

Net genoeg software architectuur

Ik heb net het interview met George Fairbanks gelezen: George Fairbanks’ Just Enough Software Architecture

Fairbanks is geen voorstander van big design upfront maar makt zich ook zorgen over de aanpak van veel ontwikkelaars met wat zij Agile noemen. Net als Fairbanks ben ik overtuigd van het feit dat geen inspanning doen om software architecturen te ontwikkelen en te onderhouden er onnodig complexe systemen gebouwd worden.

Pleidooi voor ICT architectuurreview

Mark Paauwe heeft recent een oproep geplaatst waar ik mij persoonlijk aan verbinden. Mark heeft geconstateerd dat niet alleen de aanpak voor het moderniseren van de ICT t.a.v. de Gemeentelijke Basis Administratie als ook Burgerzaken Kennissysteem. De overheid wil de lokale administraties gaan centraliseren.  Hier wordt al jaren over gesproken. In die tijd zijn belangrijke architectuurdocumenten slechter geworden doordat eisen, wensen, ontwerpconcepten en -principes, en implementatie details in verschillende documenten terecht gekomen. Een herziening van deze documenten is dan ook van essentieel belang om het technische deel van de realisatie van voldoende kwaliteit te krijgen. Meer informatie:
http://www.xr-magazine.nl/blogs/683/overheid/pleidooi-voor-grondige-architectuurreview-mgba-en-bzs-k

Gemeentes en ICT blijven worstelen

 

Op Webwereld stond 28 oktober 2010 een nogal onthutsend artikel over de automatiseringsproblemen bij de lokale overheden. Ik vind het nogal schokkend om te lezen dat er zo veel geld ingezet wordt en dat dit zo weinig oplevert. Ligt het aan de kwaliteit van de automatiseerders, de mensen die er dagelijks mee werken of aan andere zaken. Waar de oorzaak ook ligt is mij niet duidelijk. 

Wat ik wel weet is dat de complexiteit van de ICT Architectuur oplossingen te groot worden. Hoogstwaarschijnlijk worden te veel bestaande systemen aan elkaar geknoopt en heeft niemand echt inzicht in de werkelijke problemen en oplossingen.