Blog

Architectuur & ICT ontwikkeling: de stand van 2010

Een korte opsomming van actuele thema's en aandachtspunten die van belang zijn bij het maken van een architectuur en het ontwikkelen van informatiesystemen. Zonder daarbij overigens de pretentie te hebben uitputtend te zijn. 

Allereerst: de key issues. Die punten, waar je als architect rustig bij kunt slapen of juist hele nachten wakker van ligt - ze zijn aan het veranderen. Tot voor kort waren aspecten als stabiliteit en performance van een informatiesysteem vaak kritisch.

Kort door de bocht, tenzij je high definition video aanbiedt aan een miljoenenpubliek of je voor een apparaat ter grootte van een luciferdoosje moet bouwen is performance geen issue meer. Heb je toch performance problemen dan ben je waarschijnlijk aan het blunderen geweest. Stabiliteit? Een snelle check van een van mijn servers leert dat deze meer dan duizend dagen 'up' is. In die tijd is er geen crash voorgekomen van een applicatie als geheel. Treedt er ergens een fout op dan corrigeert de applicatieserver zichzelf. Ik kan rustig slapen.

Organiseerbaarheid

Software gaat in toenemende mate vooral over organiseerbaarheid. Dat is het centrale thema het komende decennium. Organiseren van het ontwikkelproces en van de onderdelen van de informatiesystemen die we bouwen. Overzicht kunnen houden. Logische onderverdelingen maken die begrijpelijk zijn. Daarvoor zelfs consessies doen.

Organiseerbaarheid is ook de  bijdrage van de informatiesystemen voor de inrichting en aanpasbaarheid van de processen en de organisaties waarin de systemen worden toegepast. Om daarin iets te kunnen bereiken is ook aandacht voor cultuur en strategie nodig. Op een vreemde manier zijn architectuurdisciplines gefragmenteerd geraakt. Volgens mij kun je zonder integratie niet tot resultaat komen.

Niet nieuw maar wel steeds prominenter in beeld: beveiliging. Bevonden we ons in de jaren negentig met onze verhouding naar internet nog in een soort van blije hippie-cultuur, inmiddels is die naïviteit (helaas) voorbij. Definitief ook, vrees ik. Dagelijks worden er pogingen gedaan om op mijn servers in te breken. En dat bepaald niet alleen door lieden die 'Killroy was here' op mijn homepage willen plaatsen.

Beveiliging

Beveiliging is een rode draad in ieder project. Dat begint met tamelijk triviale zaken als aandacht voor sql-injectie. Aandacht voor de evaluatie van je url-parameters en form-data. Het gaat verder met het vastleggen van alle ongebruikelijke gebeurtenissen waar je systeem mee te maken heeft. Mislukte inlog-pogingen bijvoorbeeld. Over hoe je om zult gaan met automatische updates in de toekomst. Over de beheersbaarheid van je systeem, wanneer dit in handen komt van beheerders voor wie het vooral een black box is.

Niet alleen is beveiliging een issue voor de continuïteit van de bedrijfsvoering. Er komt steeds meer regelgeving op het gebied van privacy waardoor je aanspreekbaar wordt op de verspreiding van gegevens van anderen die je beheert.

Eet smakelijk in New Delhi, Beijing, of bij de aardappelen thuis?

De huur van een middenklasse appartement van 2 -3 kamers in Beijing is zo ongeveer € 300 per maand. Dat is natuurlijk niet duur, maar anderzijds ook niet bijzonder goedkoop. Ik ben een hartstochtelijk wereldreiziger en ik ga graag voor u naar verre oorden om een project in goede banen te leiden. Toch is mijn vertrouwen in een sterke business case voor de off shoring van software-ontwikkeling beperkt.

Waarom? Ten eerste, bij een goed ontwikkelproces is de tijd die nodig is voor het daadwerkelijk coderen van een programma maar een beperkt onderdeel van het geheel. Off shoring brengt onvermijdelijk met zich mee dat je het ontwerp veel gedetailleerder moet maken. Een Indiër heeft weinig feeling met onze sociale wetgeving en zal ieder detail voorgekauwd moeten krijgen. Als ik zo gedetailleerd moet ontwerpen dan kan ik het bijna net zo goed meteen in Java opschrijven. Ontwerpers zijn nogal wat duurder dan programmeurs. Vervelende bijkomstigheid is dat de taalvaardigheid van menig ICT-er in C of Java beter is dan in het Nederlands of Engels.

Mocht het product of de prestatie niet aan de verwachtingen voldoen dan is het verre van eenvoudig om juridisch verhaal te halen. Er zijn veel verhalen over projecten in verre oorden. De successen zijn te vinden in Computable en Automatiseringsgids. Wie zijn oor te luisteren legt bij collegae hoort andere geluiden. Dat is trouwens in het algemeen een probleem voor het leren in de ICT: juist van fouten kun je leren, maar die houden we vaak onder de pet

Life cycle en horizon

Al die met het Internet vervlochten systemen zijn veelomvattend en kostbaar, in een veel hogere mate dan wat we ooit eerder hebben gemaakt. Dat vind je terug in de ontwikkelkosten van de systemen en in de tijd die gebruikers investeren om de systemen te kunnen benutten. Tegelijk volgen technologieën elkaar snel op en ontstaan nieuwe toepassingen.

Over het tempo waarin innovatie plaatsvindt woedt een groot debat onder filosofen. Sommige stellen dat het groeitempo exponentieel toeneemt, anderen houden het op lineair, en voor de volledigheid, er zijn er ook die stellen dat het aan het afnemen is.

Voor dit betoog: de ICT wereld ontwikkelt in hoog tempo door en dat heeft economische consequenties voor ons werk. Stel er moeten aanpassingen worden gedaan aan een systeem, wat is uw beslissing: aanpassen of opnieuw beginnen? Als het een systeem is dat is gemaakt met Perl scripts uit 1997? Als het in Active Server Pages (ASP) is gemaakt in 2001? In PHP 3 in 2003? In Java Enterprise beans in 2005? Of met het Struts 1.0 framework in 2007?

Ik zal het u gemakkelijk maken: ontwikkelaars die die oude omgevingen nog beheersen zijn met een kaarsje te vinden en als u ze vindt hebben ze geen enkele belangstelling om zich te specialiseren op uw doodlopende weg. Meer dan ooit zijn zij zich bewust van hun actuele marktwaarde.

De vraag naar de horizon van een systeem is er een die bij de opzet van een ontwerp nadrukkelijk aandacht verdient. Te vaak bouwen we nog simpelweg voor de eeuwigheid. De praktijk van websystemen tot nu toe is dat ze de vijf jaar amper halen zonder grootschalig rework.

.NET of Java?

Op beide technologie-platforms kun je om het even welk enterprise informatiesysteem bouwen. De keuze wordt daarom vaak bepaald door andere factoren dan die van de technologie an sich. Hoe close wil je je relatie met Microsoft, als enige leverancier van .NET hebben? Is integratie met andere producten van Microsoft een groot issue? Is het van belang om de keuze te hebben tussen meerdere componenten en meerdere leveranciers? Wat is je gevoel bij open source componenten - die in de Java-wereld veel prominenter aanwezig zijn?

Bepaalde groepen ICT-ers voelen zich aangetrokken tot een bepaald platform. Java trekt typisch mensen die diep willen nadenken over objectstructuren en architecturen. ICT-ers die hun vak bloedserieus beoefenen. Naar .NET kun je doorgroeien vanuit simpele kantoorapplicaties. Waar ik meteen achteraan moet zeggen dat er in de .NET-wereld net zo serieuze ICT-ers bestaan.

 

Helaas heeft deze keuze vaak religieus fanatieke trekjes. Soms lijkt het erop dat organisaties met Microsoft zekerheid willen kopen. Er wordt dan een 'Microsoft only' of een 'Microsoft tenzij'- beleid aangehangen. Dit beleid heeft vaak haar origine in de kantoorautomatisering van de organisatie en wordt vervolgens zonder nadere overweging doorgevoerd op een heel andere categorie van systemen.

Ook Microsoft voert mislukte en verouderde technologieën af. En ook bij Microsoft sta je dan soms in de kou. Zijn uw websites geoptimaliseerd op Internet Explorer 6 en is daarbij gebruik gemaakt van alle trucs die in IE 6 mogelijk waren - ik wens u sterkte.

To framework or not to framework

Om te beginnen: je kunt prachtige systemen bouwen zonder je te baseren op een framework. Java objecten, door Martin Fowler en anderen Plain Old Java Objects of POJO's gedoopt, zijn prima bouwstenen en bieden alle mogelijkheden om structuur in je systeem te brengen en te houden.

Een framework kan je veel werk uit handen nemen. Je kunt er componenten in hangen die zich aangepast hebben voor gebruik in een framework. Een framework helpt enorm bij het organiseren van je project en het systeem. Ze bieden out of the box de mogelijkheid van aspect-oriëntatie om bepaalde aspecten systeembreed aan te pakken.

Framework-eritis

'Ik hou zoveel van Duitsland, ik wil er twee', zei Francois Mitterand ooit. Ik hou van frameworks en er zijn inmiddels enkele tientallen om uit te kiezen. Welke modieus zijn wisselt in hoog tempo. Je zou  er een maandelijkse 'what's in- and  what's out- column aan kunnen wijden. Pluspunt is dat we kunnen kiezen, dat er verschillende richtingen worden geprobeerd en dat er veel ontwikkeling plaatsvindt.

Haal je een framework binnen in je project dan zijn dat de nodige megabytes aan code en abstracte overwegingen die eraan ten rondslag liggen. Voor normale stervelingen kost het even om daarin thuis te geraken. Pas je een framework niet toe zoals bedoeld dan kan het zich behoorlijk tegen je keren en wordt je project alsnog een puinhoop. Uit het voorgaande volgt dat het vinden van een ontwikkelaar met vijf jaar ervaring op een bepaald framework kansloos is.

Kies je voor een framework dan zit je er ook aan vast. Zelfs migratie naar een volgende versie van hetzelfde framework is meestal niet triviaal. Migratie naar een ander framework zal in de praktijk niet snel geschieden. Dit is iets om bij stil te staan, als je je realiseert dat het onwaarschijnlijk is dat al die frameworks van vandaag over drie jaar nog zullen floreren.

Relationele opslag versus object-georienteerd programmeren

Object oriented ontwikkelen kwam op rond 1995. Maar voor de gegevensopslag maken we vijftien jaar later nog grootschalig gebruik van relationele databases. Terwijl die twee modellen niet op elkaar aansluiten, wat betekent dat iedere keer dat je informatie uitwisselt met de database een omzetting moet plaatsvinden. De reden? De kwaliteit van relationele database-engines, de uitwisselbaarheid van data tussen systemen en heel veel koudwatervrees.

Als gevolg van het gebrek aan aansluiting zit ieder project vol met 'CRUD code'. CRUD: 'create, read, update, delete'. Dit zijn de handelingen nodig om het objectmodel te mappen op de relationele database. Met een object relational mapper tool - zoals Hibernate - kun je deze handelingen alsnog naar de achtergrond drukken, het tool doet ze nu voor je, maar uiteindelijk is dat slechts de automatisering van het probleem, niet de oplossing.

Overname alleen na voorafgaande toestemming.