Vandaag is van mij een artikel gepubliceerd in het online magazine: XR-Magazine. In dit artikel beschrijf ik de rol van softwarearchitect als waakhond bij de ontwikkeling en tijdens de rest van de applicatie life cycle.

De belangrijkste conclusie, die ik getrokken heb, is hoe belangrijk het is om controle op de structuur van de applicatie te blijven uitvoeren. De structuur is het fundament van iedere applicatie.

Het complete artikel is te vinden op de website van XR Magazine.

Ik krijg altijd een behoorlijke kick als klanten enthousiast zijn over de dingen die ik achterlaat. DIt overkwam mij ook weer gisteren. Ik had toen een afsluitend gesprek met een klant waar ik behoorlijk wat onderzoekswerk voor verricht het.

De situatie bij deze klant is als volgt:

Ruim 10 jaar ontwikkelwerk aan een grote applicatie, opgebouwd uit Cobol, Uniface, Java, C, Fortran, Oracle PL/SQL en Streamserve.

Gisteren heb ik voor een potentiële klant een presentatie gegeven over het gebruik van Dependency Structure Matrices bij het analyseren van software applicaties. De presentatie geeft een korte introductie in de mogelijke toepassingen.

Gisteren heb ik bij een groot Internet bedrijf in Rotterdam een presentatie gegeven over software complexiteit. De belangrijkste conclusies zijn:

• wacht met coderen totdat je de complexiteit van het te realiseren systeem voldoende begrepen hebt;
• monitor de toename van de software complexiteit gedurende de applicatie life cycle d.m.v. geschikte metrieken, dependency graphs en/of dependency structure matrices.

Aan het einde van de workshop waren de deelnemers overtuigd van het nut van het verkrijgen van meer inzicht in de complexiteit van hun eigen applicatie. Een onderzoek wordt op gezet om te kijken welke metrieken in Visual Studio geschikt zijn voor deze doeleinden.

Op InfoQ is zojuist een zeer interessante video verschenen van Amit Uttam en Derek Longmuir waarin verschillende strategieen worden besproken die van toepassing zijn op bestaande systemen. 

Naast dat de beide heren een definitie geven voor een legacy systeem geven ze ook een aantal interessante migratie mogelijkheden. Sommige doe je waarschijnlijk al onbewust, sommigen liggen minder voor de hand.

Veel succesvolle softwarebedrijven hebben een ding gemeen, Het geheim achter hun succes heet visie. Visie drijft de ontwikkeling van een softwareapplicatie of een software productlijn. Het omzetten van visie in een product is geen rocket-sience je hoeft ook niet de beste programmeurs van de wereld te hebben om het te realiseren.

In verschillende projecten en omgevingen heb ik zowel de waarde als het gemis van een visie mogen ervaren. Als er een visie is dan is het maken van een model en een softwarearchitectuur veel eenvoudiger. Hoewel misschien niet alles aan het begin klip-en-klaar is vallen puzzelstukjes vanzelf op de juiste plek omdat alles logisch lijkt en ook is. Gebeurt dit niet dan is dit een teken aan de wand. Het product wil niet af komen, enthousiasme is tanende, kosten lopen op. Onderhoud wordt een blok aan het been.

In het artikel Scoping and Requirements Woes van Frank Buschmann (Gang of Four) in IEEE Software November/December 2009  worden weer een aantal punten naar voren gebracht waardoor softwareapplicaties de mist in gaan. De belangrijkste redenen zijn:

1. scope van de applicatie, veel applicatieontwikkelingen worden gestart zonder voldoende de scope van de te ontwikkelen applicatie te bepalen;
2. onvoldoende rekening te houden of niet definieren van vage niet-functionele eisen.

Na wat geharrewar over zaken die meer te maken hebben met de Belastingdienst met name inzake de afgifte van de juiste VAR verklaring is het dan eindelijk zo ver. Ik ga starten met een grote opdracht. Voor een bedrijf (ik noem bewust geen namen) ga ik een redelijk omvangrijke analyse uitvoeren.

Deze klant wil meer inzicht krijgen in de huidige applicatie die bestaat uit verschillende technologien en programmeertalen: