Steven's weblogs en columns (nederlands)
Iedereen kan informatie van deze weblog overnemen onder de voorwaarde dat hij/zij blijft verwijzen naar deze weblog.
December 1999: Functioneel Ontwerp
Veranderen is de tegenwoordige manier van leven. Vooral in de informatisering en de automatisering is dit de orde van de dag. In deze column wordt vanuit het zich vormende vakgebied rond informatie-architecturen ingegaan op aangedragen stellingen. De bedoeling is dat op deze stellingen gereageerd wordt zodat discussies ontstaan over en rond informatisering en automatisering.
De stelling van deze maand komt voort uit een reeks discussies die de laatste maanden gevoerd zijn rond informatie-architecturen. Veel informatici hebben het volgende probleem:
Het is niet mogelijk om wat bij een informatie-architectuur hoort te scheiden van de resultaten van een functioneel ontwerp.
Aan het ontwikkelen van geautomatiseerde informatiesystemen is in de tweede helft van de twintigste eeuw veel tijd en aandacht besteed. Ging het in de jaren vijftig en zestig nog vooral om het programmeren van de hardware, aan het einde van de jaren zeventig kwamen de eerste echte methoden en technieken voor systeemontwikkeling op de markt. Mensen als Langefors, Lundeberg, Yourdon, deMarco, Gane en Sarson, Martin, Chen en Nijssen werden bekend met methoden en technieken als ISAC, Structured Analysis and Design (DFD's), ERD's, ER/EAR, NIAM, INFOMOD enzovoort. Getracht werd methodisch om te gaan met wat 'het voortraject van de automatisering' werd genoemd. Er zijn heftige discussies gevoerd tussen mensen die data- en mensen die procesgericht wensten te werken. Deze discussies zijn in het begin van de jaren negentig afgerond.1
Naast de genoemde methoden en technieken bestond ook een totaal andere categorie methoden. Het waren algemene stappenplannen die de activiteiten van het ontwikkelen van informatiesystemen in fasen indeelden. Doel was om van een gegeven probleem tot een geautomatiseerde oplossing te komen. Deze methoden beginnen dan ook met het onderkennen van 'het probleem' in de informatievoorziening. Daarna volgt de uitwerking van dat probleem, het ontwerp en de realisatie van de oplossing en de invoering ervan. Deze methoden hadden namen als SDM, PRODOSTA en PARAET.
SDM is in Nederland de bekendste en meest gebruikte methode. In de eerste versie maakte die methode een onderscheid tussen functioneel en technisch ontwerp. Een logische scheiding, want je probleem uitwerken is wat anders dan een oplossing kiezen, uitwerken en implementeren. Deze logica werd doorbroken in versie 2. Onder de fasenamen 'globaal ontwerp' en 'detailontwerp' werd veel eerder begonnen met het uitwerken van de inzet van informatie- en communicatietechnologie (ICT). Veel essentiëler was echter de aanpassing tussen het functioneel ontwerpen van een oplossing van het probleem en het technisch ontwerpen en realiseren. Met deze versie kon tijdens de fase globaal ontwerp op enig moment gestopt worden met het functioneel ontwerp. Het functioneel ontwerp kon tijdens de fase detailontwerp per deelsysteem afgemaakt worden.
Een probleem hierbij was dat er geen harde criteria gegeven zijn voor het moment dat overgegaan werd van systeembreed werken naar werken per deelsysteem. Iedereen had daar dan ook eigen criteria voor, waarbij het toereikend zijn van het budget voor het globale ontwerp vaak leidend was. En daarmee lag de weg open om een groter budget te claimen voor het detailontwerp, met als risico dat het systeembrede deel niet voldoende uitgewerkt was. Het kwam dan ook bijvoorbeeld regelmatig voor dat per deelsysteem gebouwd werd, en dat achteraf bleek dat er aansluitingsproblemen tussen deze deelsystemen waren. Met alle gevolgen van dien...
In de jaren negentig ging men terug naar kleinere systemen en applicaties. Methoden en technieken als objectoriëntatie, RAD/MAD/JAD/IAD/..., DSDM, en component based development kwamen op. Nu ontstonden problemen met het op elkaar aansluiten van de veelheid van ontwikkelde objecten, applicaties, componenten enzovoort. Dat kwam doordat veelal direct ingespeeld werd op de problemen die gesignaleerd werden, zonder dat vooraf gekeken werd naar waar die oplossing een plaats kreeg in de informatie-infrastructuur. Veel organisatie hebben aan het einde van de jaren negentig dan ook een probleem met de inrichting van hun applicatie-infrastructuur. Vele hebben zelfs geen overzicht van welke applicaties ze hebben. Ze kunnen daardoor heel moeilijk zien en onderkennen waar veranderingen doorgevoerd zouden moeten worden.
Kijken we op de drempel van het jaar 2000 terug, dan zien we de volgende ontwikkeling: De eerste methoden en technieken maakten een stevig onderscheid tussen functioneel en technisch ontwerp. Daarna is dat onderscheid vervaagd, en ontstond een mengvorm. Later werd functioneel en technisch ontwerp nog sterker samengenomen, maar nu per applicatie, object of component.
Iets vergelijkbaars is gebeurd met de activiteiten rond informatie-analyse en rond functioneel ontwerp, met als gevolg dat in de jaren negentig niet of nauwelijks nog structureel en breed geanalyseerd werd. Daardoor ontstond in veel gevallen een zeer ondoorzichtige situatie, waarin niet of nauwelijks meer te herkennen was hoe de elementen samen een gedegen en integraal ondersteunende informatie-infrastructuur realiseerden. En dat is het beeld dat veel organisaties te zien kregen als resultaat van de inventarisaties die nodig waren voor het oplossen van het millenniumprobleem. Veel onduidelijkheid, en soms zelfs chaos.
Als we teruggaan naar de essenties, dan is het verschil tussen (informatie-)analyse en ontwerp werkelijk heel simpel. Tijdens een analyse (uit het woordenboek: analyse is de ontleding in bestanddelen ter nadere beschouwing) wordt immers op een rij gezet wat de problemen zijn en in welke richting gedacht kan worden om die problemen op te lossen. Ontwerpen (uit het woordenboek: beschrijving van iets nieuws in hoofdtrekken) heeft te maken met het inrichten van de oplossing. Functioneel ontwerp is daarbij het met de gebruiker afspreken van de functionaliteit die de oplossing hem/haar moet bieden. Bij technisch ontwerp gaat het over de inrichting van de onderliggende techniek.
er wordt nauwelijks nog structureel en breed geanalyseerd, waardoor amper te herkennen is hoe elementen samen een gedegen en integraal ondersteunende informatie-infrastructuur realiseren
De aangedragen stelling spreekt over het 'niet kunnen scheiden van informatie-architectuur en functioneel ontwerp'. Toch is dit scheiden erg simpel: een informatie-architectuur zet namelijk op een rij wat de uitgangspunten, randvoorwaarden, eisen en wensen zijn rond een informatievoorziening die een gekozen omgeving dient te ondersteunen. Oplossingsonafhankelijk. Op basis van de informatie-architectuur kunnen software- en/of systeemhuizen aan het werk gezet worden om oplossingen te realiseren. Op dat moment komt dus de in te zetten technologie aan de orde. (Informatie-)analyse heeft dus alles te maken met de informatie-architectuur, terwijl functioneel en technisch ontwerp de eerste activiteiten omvatten die aannemers (de software- en systeemhuizen) uitvoeren die vorm geven aan oplossingen die een plaats dienen te krijgen in de informatie-infrastructuur (de bestaande informatievoorziening). De stelling is mijns inziens dus onjuist.