Componenten zijn concepten

Bij architectuur gaat het om concepten!

Ik beschouw de volledige architectuur van een systeem als een groot concept. En omdat zo'n architectuur is opgebouwd uit (logische)componenten beschouw ik deze als deelconcepten.


Mijn ervaring leert dat de voordelen om een (logisch)component te introduceren als een op zichzelf staand concept zeer groot zijn, namelijk:

• Mensen (klanten, sponsors, collega's etc.) worden makkelijk enthousiast van een concept. Denk maar eens aan het alternatief: een lange droge lijst met features;


• Concepten zijn precies voldoende abstract om als uitgangspunt te dienen voor de functionele en technische uitwerking.

Maar waar zou zo'n concept nu aan moeten voldoen? Wat zou een formele definitie van zo'n architectuur-deelconcept kunnen zijn, vroeg ik me vandaag af?


Opeens moet ik aan de standaard (ANSI1471) 'architectuurdefinitie' denken: "The fundamental organization of a system, embodied in its components, their relationships to each other and the environment and the principles governing its design and evolution".


Volgens mij zijn dat precies de eisen die je aan zo'n concept moet stellen:

• Verduidelijking van de logische plaats in het geheel door het benoemen van de relaties met andere componenten en zijn omgeving;
• Verduidelijking van ten minste een principes betreffende het ontwerp en evolutie.

Ook moet ik denken aan de IEEE1471 definitie van een 'architectuurbeschrijving': "... The architectural description can be divided into one or several views. Each view covers one or more stakeholder concerns. View is defined as “a representation of a whole system from the perspective of a related set of concerns”...."Op basis hiervan kunnen we een derde formele eis benoemen, namelijk geschreven op een manier die aansluit op de belevenis van de klant voor wie we dit doen.


Een voorbeeld: het logische component "Logging"


Je zou kunnen zeggen voor logging gebruiken we de Microsoft Enterprise Library. Maar van Logging kun je ook een concept maken namelijk.



=====

Ontmoet Marcel's Logging!


Marcel's logging is gebaseerd op de ervaring van jarenlange softwareontwikkelervaring die wij inmiddels hebben opgedaan. Zo leert de ervaring ons dat het verstandig is om onderscheid te maken in rollen en soort. Bijvoorbeeld technische informatie voor de systeembeheerder en technische informatie voor de ontwikkelaar. Maar ook bedrijfskundige informatie waar alleen de "business analyst" iets aan heeft. Gegevensinhoudelijke waarschuwingen bijvoorbeeld.


De staat van de betreffende applicaties worden steeds op een dashboard middels stoplichten getoond. Bij oranje of rode stoplichten kan direct op het probleem worden ingezoomd.
Normaal gesproken staat de gehele applicatie in een diagnosestand (met alle gevolgen voor snelheid en gebruiksvriendelijkheid) of niet. Maar bij onze loggingstrategie is het mogelijk om per zogenaamde sessie deze diagnosestand aan te zetten.

Ook voor onze logging geldt het principe: technologie moet uitwisselbaar zijn en we beginnen met de Enterprise Library.Technologie is nu eenmaal een van de meest veranderlijke zaken (anticipation of change).

Verder dient het afhandelingsproces vrij inregelbaar te zijn. Bij een bepaalde freqentie van bepaalde fouten moet geëscaleerd worden totdat ze bevestigd zijn. In andere gevallen is een email naar bijvoorbeeld de supportdesk voldoende. Welke gevallen welke route bewandelen is iets wat in de loop van de tijd steeds duidelijker wordt (lerende organisatie)In de flexibele afhandeling dient een extern systeem te kunnen worden aangeroepen zodat er automatisch een issue kan worden aangemaakt in het issuetrackingsysteem.

===

Nabeschouwing

• Blijkbaar was het belangrijk voor de klant om de ervaring te borgen;
• Het is duidelijk hoe het component gebruikt gaat worden in zijn omgeving;
• Het is duidelijk hoe het component samenwerkt met andere componenten;
• Het is duidelijk hoe het component zich gedraagt;
• Het is duidelijk welke principes van toepassing zijn;
• De conceptuele beschrijving kan uistekend dienen als uitgangspunt voor de verdere uitwerking.