Inleiding
Analyseren, specificeren, structureren en plannen zijn belangrijke onderwerpen in een informaticaopleiding. Goed nadenken voordat je begint te bouwen, daar gaat het om. Maar daar wordt in de praktijk vaak niet de tijd voor genomen. In de meeste ontwikkeltrajecten wordt vooral snel begonnen met bouwen en worden daarna continu problemen opgelost.
Het is de taak van de architect om, voor het realiseren van een softwaresysteem, na te denken over hoe de belangrijkste systeemeigenschappen gerealiseerd worden en hoe problemen voorkomen kunnen worden. Die taak kan hij nooit alleen vervullen. Hij werkt samen met anderen om erachter komen wat de belangrijkste eigenschappen van een systeem zijn, om een uiteindelijke oplossing te bepalen en om die oplossing te realiseren. De architect bemoeit zich met alles, maar bereikt niets alleen.
DYA|Software vult een aantal gaten in de bestaande literatuur over softwarearchitectuur. De volgende elementen maken DYA|Software uniek:
· Een definitie van “goede softwarearchitectuur” die gebruikt kan worden als richtlijn bij het opzetten, in stand houden en analyseren van een architectuur.
· Een generiek architectuurredeneermodel dat architecten helpt bij het nemen van onderbouwde beslissingen en bij het slaan van de brug tussen bedrijfsvoering, (requirements) analyse, software engineering en realisatieproces.
· Technieken die het mogelijk maken een architectuur af te stemmen op een bepaalde situatie. Denk aan het afstemmen van een systeem met zijn omgeving, het communiceren met verschillende stakeholders over hun specifieke eisen en het focussen op de bedrijfskritische eigenschappen van een systeem.
· Technieken om softwarearchitectuur organisatiebreed in te zetten.
DYA|Software hanteert voor al deze elementen geen vast raamwerk, geen star architectuurproces en geen lange studie vooraf. Met DYA|Software kan men meteen aan de slag. De belangrijkste doelgroep is (aspirant) softwarearchitecten op zowel enterprise- als projectniveau en de niveaus daartussen. DYA|Software helpt hen bij het maken van een betere softwarearchitectuur binnen de context waarin zij werken.
softwarearchitectuur en softwarearchitect
Softwarearchitectuur is geen begrip dat iedereen in zijn opvoeding mee krijgt. Kinderen leren het niet op school, ouders praten er thuis niet over en het is geen populair onderwerp op TV. De meeste mensen kennen het niet en zullen er nooit direct mee te maken krijgen.
Mensen die betrokken zijn bij softwareontwikkeling hebben vaak te maken met softwarearchitectuur. Zij moeten input leveren voor een architectuur of gaan de architectuur toepassen in hun eigen activiteiten. Voor hen is het belangrijk om te weten wat softwarearchitectuur is. De DYA|Software definitie van softwarearchitectuur is: De softwarearchitectuur van een systeem is een geheel van uitspraken dat richting geeft aan ontwerp, realisatie en evolutie van de software in zijn omgeving.
Waarbij de architectuuruitspraken een model vormen van:
· De structuur van de systeemelementen, hun onderlinge relaties en/of van de relaties tussen de elementen en de omgeving.
· De richtlijnen voor het vormen van de structuur, de elementen en de relaties daartussen.
DYA|Software is vooral gericht op software in de informatievoorziening van een organisatie. Dit uit zich niet alleen in de constructie en functionaliteit van die software, maar ook in de systeemomgeving. De omgeving van een bedrijfsinformatiesysteem omhelst minimaal:
· De bedrijfsprocessen die door het systeem ondersteund worden.
· De gebruikersomgeving waarvoor het systeem bedoeld is.
· De andere (software)systemen waarmee het systeem interactie heeft.
· De technische infrastructuur waar het systeem op past.
· De strategie en plannen voor de informatievoorziening waar het systeem onderdeel van uitmaakt.
· De ontwikkel-/beheerprocessen waarmee het systeem gerealiseerd wordt.
De architect houdt rekening met de kennis en expertise van de mensen waarmee hij communiceert. De gedetailleerdheid en vorm van de architectuur hangt niet alleen af van wat nodig is om de belangrijkste systeemeigenschappen te garanderen, maar ook van degenen die de architectuur moeten begrijpen. Zij moeten de architectuur interpreteren en vertalen naar hun eigen werkzaamheden. De architect moet daarom goed nadenken over hoe hij de architectuur overbrengt aan anderen.
Goede softwarearchitectuur
Tijdens een discussie rond een opleiding voor architecten rees de vraag wat een goede architect is. Er kwamen vooral antwoorden die stelden welke vaardigheden een architect moet hebben. Een goede architect moet kunnen analyseren, abstraheren, structuren, communiceren, bemiddelen, overzicht houden en veel weten van zijn architectuurdomein. Maar hoe weet je of een architect dat allemaal in huis heeft? “Dat kun je zien aan de architectuur” was het antwoord. “Een goede architect realiseert een goede architectuur”. Dat klinkt logisch. Maar, wat is een goede architectuur?
Om een goede architectuur op te stellen, te beheren en uit te dragen kiest de architect bewust hoeveel aandacht hij besteedt aan bepaalde stakeholders, concerns, modellen en andere architectuuraspecten. Om zinvolle keuzes te maken moet hij eerst bepalen wat een goede architectuur is. Een goede architectuur heeft de volgende eigenschappen:
· Correct: de architectuur is gebaseerd op voldoende gevalideerde informatie over de omgeving en de belangen van stakeholders in het bijzonder. Belangen zijn er in de vorm van doelen en beperkingen. Belangen zijn geprioriteerd. De architectuur vormt de juiste afweging tussen de belangen. Bij correctheid gaat het om de vraag “Past het systeem in zijn omgeving?”.
· Consistent: de architectuur vormt een samenhangend geheel dat bewust beheerd wordt. De architectuuruitspraken zijn onderling niet strijdig. Dit geldt niet alleen voor de uitspraken binnen de architectuur zelf, maar ook in relatie tot de omgeving. Het systeem moet binnen de gestelde beperkingen te realiseren zijn met de architectuur. Voor alle relevante eisen moet de architectuur een acceptabele oplossing bieden. Bij consistentie gaat het om de vraag “Zit het systeem goed in elkaar?”.
· geCommuniceerd: de stakeholders zijn op de hoogte van hun relatie met de architectuur. Zij moeten de juiste verwachtingen hebben van de architectuur en weten wat hun eigen bijdrage is. Zij moeten de architectuur kunnen vertalen naar hun eigen activiteiten. De stakeholders moeten begrijpen hoe hun eisen geborgd zijn. Een gecommuniceerde architectuur begint bij een communiceerbare architectuurbeschrijving en een bewuste planning van de communicatie. Bij communicatie gaat het om de vraag “Weet iedereen wat hij moet weten?".
Om te toetsen of een architectuur goed is en om richting te geven aan de architectuuractiviteiten, vevat DYA|Software een aantal checklists voor de architect. Voor de businessmanager is een korte vragenlijst beschikbaar waarmee hij snel kan toetsen of de architectuur goed is (zie kader). De architect moet op alle vragen antwoord kunnen geven of hij moet kunnen zeggen waarom hij geen antwoord heeft. De vragen helpen om aandachtspunten voor de architectuur te identificeren.
|
10 vragen van de manager aan de architect:
1. Wie zijn de stakeholders en wat is het belangrijkste concern van elke stakeholder?
2. Wat zijn de vijf[1] belangrijkste concerns waar de architectuur invulling aan moet geven?
3. Wat zijn de vijf moeilijkste kwesties waar de architectuur een oplossing voor biedt? Welke stakeholderconcerns zijn daarmee gediend?
4. Wat is de belangrijkste rol die elke stakeholder speelt bij de totstandkoming van de architectuur?
5. Wat is de afbakening van de architectuur? In het bijzonder met betrekking tot:
a. Toepassingsgebied
b. Technologie
c. Ontwikkel- en beheerproces
d. Levensduur
6. Wat zijn de vijf belangrijkste afwegingen in de architectuur en hoe zijn deze vastgelegd, uitgedragen en bewaakt?
7. Op welke manier is de consistentie van de vijf belangrijkste eisen en hun oplossing aangetoond?
8. Welke architectuurviews zijn er om te redeneren, uit te leggen, uit te rollen, te beschrijven, etc.? Aan welke stakeholders zijn deze gericht?
9. Op welke manier zijn de stakeholders op de hoogte gebracht van de manier waarop de architectuur hun eisen (niet) inwilligt en wat er van hen verwacht wordt / welke acties zij moeten ondernemen?
10. Wat is er zo geweldig aan de architectuur wat ik niet mag vergeten? Wat moet ik echt weten van de architectuur dat ik niet gehoord heb in de antwoorden op de vorige vragen?
|
Het architectuurredeneermodel
De architect heeft te maken met een grote diversiteit en hoeveelheid aan informatie en stakeholders. Het is een complexe taak om overzicht te houden en de juiste architectuurbeslissingen nemen. Het architectuurredeneermodel helpt de architect bij het nemen van afgewogen beslissingen en het analyseren van genomen beslissingen. Dat is elke keer wanneer technologiekeuzes, bedrijfsdoelen en ontwikkelplannen met verschillende stakeholders afgestemd moeten worden.
|
Voorbeeld:
Eindgebruikers willen dat applicaties gebruiksvriendelijk zijn en dat hun taken optimaal ondersteund worden. Beheerders willen dat software eenvoudig te installeren en te onderhouden is. De opdrachtgever vindt het belangrijk dat het systeem op tijd beschikbaar is en niet te duur wordt. Het redeneermodel helpt de architect om een afgewogen keuze te maken en die aan de stakeholders uit te leggen.
|
Figuur 1 Het architectuurredeneermodel toegepast op een softwaresysteem
Figuur 1 toont het architectuurredeneermodel voor een softwaresysteem.
Het model beslaat drie dimensies waarbinnen de architect redeneert over de relatie tussen het systeem en zijn omgeving:
· Langs de toepassingsdimensie wordt geredeneerd over wat het systeem betekent voor klanten en gebruikers. Deze dimensie bevat de doelen, klantbehoeften, ondersteuning van bedrijfsprocessen, use cases, functionaliteit en functionele kwaliteit van het systeem.
· Langs de constructiedimensie wordt geredeneerd over de elementen waaruit het systeem is opgebouwd. Deze dimensie bevat componenten, interfaces, ontwerppatronen, benodigde infrastructuur en andere toe te passen technologie.
· Langs de realisatiedimensie wordt geredeneerd over wat de processen en organisatie voor ontwikkeling en beheer zijn waarmee het systeem gerealiseerd wordt. Deze dimensie bevat de ontwikkelplannen, projectplannen, benodigde kennis, beschikbaar personeel, externe leveranciers en ontwikkelstraten.
Langs alle drie dimensies kunnen uitspraken betrekking hebben op de systeemomgeving, op het systeem zelf of op het grensvlak tussen systeem en omgeving. Elke uitspraak in een bepaalde dimensie is gerelateerd aan uitspraken in de andere dimensies. Daarnaast moet elke systeemuitspraak aansluiten op omgevingsuitspraken en andersom. Dit gebeurt via uitspraken op de grens van het systeem. De grensuitspraken maken duidelijk hoe het systeem in zijn omgeving past. Het redeneermodel is een simpel en krachtig instrument dat bijna bij alle architectuurvraagstukken in te zetten is.
Organisatiebrede Softwarearchitectuur
De applicaties van een organisatie moeten zo gemaakt zijn dat zij samen de gehele bedrijfsvoering ondersteunen. Dit is een logische gedachtegang, maar in de praktijk gaat het vaak anders. Applicaties worden ontworpen om één bepaalde bedrijfsfunctie te ondersteunen. Er worden daarbij steeds nieuwe oplossingen bedacht voor aspecten die in veel applicaties een rol spelen. Dit geldt voor zowel veel voorkomende functies als voor veel voorkomende non-functionele eigenschappen. Het gevolg is dat organisaties een grote diversiteit aan applicaties ontwikkelen en beheren. De samenhang binnen het applicatielandschap is dan ondoorzichtig. Schaalvoordelen door applicaties te baseren op gemeenschappelijke functies en ontwerpen, worden op deze manier niet bereikt. Een applicatielandschap, dat op die manier tot stand is gekomen, vormt geen optimale ondersteuning van de bedrijfsvoering.
Om een geheel applicatielandschap af te stemmen op de bedrijfsdoelstellingen moeten meer aspecten beschouwd worden dan alleen de softwarefunctionaliteit die nodig is om een bedrijfsfunctie te ondersteunen. Bij het opstellen van een architectuur voor een applicatielandschap spelen de volgende aspecten (zie Figuur 2):
1) De eisen en de doelen voor het gehele applicatielandschap van een organisatie (en hoe zich dat uit in bijbehorende specificaties zoals requirements, ontwerpen en realisatieplannen). Een goede architectuur begint met een goed beeld van de eisen en doelen die nagestreefd worden.
2) De gemeenschappelijke eigenschappen van applicaties. Hiervoor moeten oplossingen gecreëerd worden die dan in alle beoogde applicaties moeten worden toegepast. Dit uit zich op 2 manieren:
a) Ontwerp-/realisatiepatronen die in alle componenten en realisatieprojecten moeten worden toegepast.
b) Centrale softwarecomponenten die door alle (of vele) applicaties gebruikt worden. Denk aan een enterprise service bus, autorisatieservice, logging-component, een gemeenschappelijk informatiemodel voor interfacespecificaties, een operating systeem en al datgene dat onder infrastructuur valt.
3) De aspecten die van belang zijn voor de constructie en realisatie van het gehele applicatielandschap. Om de eisen en doelen uit punt 1 waar te maken, is het van belang om de landschapbrede aspecten, de opdeling in componenten en de interfaces tussen die componenten te beschouwen.
Figuur 2 Aspecten van een applicatiearchitectuur
Softwarearchitectuur voor families
De softwaresystemen die een organisatie gebruikt, hebben vaak een aantal eigenschappen gemeen. Er zijn overeenkomsten in functionaliteit, kwaliteit of de technologie waarmee ze gemaakt zijn. Systemen die op dezelfde manier gerealiseerd worden, vormen een systeemfamilie. In de praktijk komen families voor op het niveau van applicaties, softwarecomponenten en softwareservices.
|
Een bepaalde organisatie heeft applicaties die klanten bedienen via internet. Dergelijke applicaties bieden functionaliteit om vanuit thuis producten af te nemen, de status van de bestellingen in te zien of de persoonlijke gegevens te onderhouden. Voor al deze applicaties gelden ongeveer dezelfde eisen op het gebied van beveiliging van klantgegevens, beschikbaarheid, responstijden en schaalbaarheid. Een andere overeenkomst is dat de applicaties allemaal gebruik maken van webtechnologie om via internet toegankelijk te zijn. De architect doet er goed om om deze gevallen een familiearchitectuur op te zetten.
|
Het ontwikkel- en beheerproces voor een systeemfamilie streeft de volgende doelen na:
· Ontwikkelproblemen die in meerdere systemen voorkomen worden slechts één keer opgelost. Dit verlaagt zowel de ontwikkelkosten als de gemiddelde ontwikkeltijd per product.
· Door hergebruik van oplossingen wordt de totale verzameling systemen homogener. Dit resulteert in lagere beheerkosten.
· Een gekozen oplossing voor een gemeenschappelijk probleem wordt in meerdere systemen gevalideerd. Daardoor wordt sneller duidelijk of een bepaalde oplossing werkt.
Een goed opgezette familiearchitectuur leidt tot een toename in systeemkwaliteit en afname in totale realisatiekosten en realisatieduur.
In een familiearchitectuur gaat het om de belangrijke gemeenschappelijke eigenschappen van de systemen die tot de familie behoren. De familiearchitectuur bevat uitspraken over de manier waarop die eigenschappen gerealiseerd worden. Er zijn ruwweg drie manieren om de gemeenschappelijke eigenschappen in afzonderlijke systemen te borgen:
· Door vaste eisen te hanteren voor de familieleden.
· Door elementen voor te schrijven die in elk systeem toegepast worden, zoals ontwerppatronen en standaard softwarecomponenten.
· Door te standaardiseren op het ontwikkelproces en/of –organisatie.
Binnen een systeemfamilie vervult ieder systeem een eigen rol. Om die rol in te kunnen vullen is het van belang om de variabiliteit tussen de familieleden te onderkennen. De familiearchitectuur moet het mogelijk maken om, binnen datgene wat gemeenschappelijk is, variatie aan te brengen. Hiervoor zijn in software ruwweg de volgende mechanismen: samenstelling, overerving, extensie, configuratie, type-instantiëring en generatie. Een familiearchitectuur hanteert vaak combinaties van deze mechanismen.
Een familieaanpak beperkt zich meestal niet tot een familiearchitectuur. Ook de daadwerkelijke realisatie van de systemen kan via een familieaanpak opgezet worden. Een organisatie richt hiervoor een ontwikkelstraat in. De ontwikkelstraat en de familiearchitectuur moeten goed op elkaar afgestemd worden. De elementen uit de ontwikkelstraat richten zich dan op de juiste systeemeigenschappen, de ontwerpen die daarbij horen en de manier waarop de systemen gerealiseerd worden. Hierdoor ontstaat een versnelling van de realisatietrajecten. Het proces binnen de ontwikkelstraat moet het mogelijk maken om bewezen oplossingen tot standaard te verheffen.
Architectuur Beheren en beheersen
Bij het opstellen en onderhouden van een architectuur is het belangrijk om te weten wat de essentie van het systeem is, wat de grenzen van het systeem zijn en hoe het systeem in zijn omgeving past. De architect moet hier een goed beeld van hebben. Dit begint met het in kaart brengen van de belangrijkste concepten van het systeem en zijn omgeving in een domeinmodel.
Figuur 3 Basisconcepten van de architect
Figuur 3 toont een domeinmodel van de concepten die doorgaans in elke architectuur voorkomen. De architect kan met deze basisconcepten niet alle zaken afdekken die belangrijk zijn voor een specifieke architectuur. Naast de concepten die in elke architectuur van belang zijn, zijn ook domeinspecifieke concepten nodig. De architect kan het model uitbreiden met de concepten die nodig zijn in een specifieke situatie. Het domeinmodel is de basis om, de grote hoeveelheid informatie die de architect moet beschouwen, te beheren en beheersen.
Een bestaande architectuurtaal kan uitgebreid worden met concepten die belangrijk zijn in het betreffende systeem of omgeving. Talen zoals UML en Archimate bieden goede mogelijkheden om de systeemelementen te specificeren. Echter, dergelijke talen bieden geen standaard mogelijkheden om uitspraken te specificeren die over kwaliteit of ontwerpaspecten gaan. Er zijn geen concepten in UML en Archimate om bijvoorbeeld uitspraken over beveiliging te doen. Hiervoor kan de taal uitgebreid[2] worden. Een domeinmodel van het beveiligingsdomein kan als basis dienen. Figuur 4 toont een aantal van de meest voorkomende concepten om over beveiliging te communiceren en redeneren.
Figuur 4 Concepten voor beveiliging
|
Niet alle ervaring, gevoel en intuïtie van de architect zijn eenvoudig in woorden te vatten en dus ook niet via tekst of plaatjes over te dragen. Ondanks dat DYA|Software meer systematiek in het opstellen van een architectuur brengt, blijft architectuur een creatief en niet volledig voorspelbaar proces.
Taken van de architect
De essentie van architectuur bedrijven is oplossingen bedenken voor de belangrijkste eigenschappen van een systeem en voor de eigenschappen die het moeilijkste te realiseren zijn. De primaire verantwoordelijkheid van de architect is het bewerkstelligen van een goede architectuur. Om dat te bereiken moet hij niet alleen denken, hij moet ook handelen.
DYA|Software helpt de architect bij de activiteiten om het systeem en zijn omgeving te analyseren, de architectuur op te stellen en de architectuur uit te dragen. Figuur 5 toont de hoofdactiviteiten van de architect.
Figuur 5 Hoofdactiviteiten van de architect
Om een architectuur op te stellen moet de architect eerste een goed beeld hebben van het systeem en zijn omgeving. Hij moet weten welke andere systemen en ontwikkelingen een relatie hebben met het systeem. Hij moet begrijpen wat de belangrijkste aspecten en hun onderlinge samenhang zijn. Hij moet weten wie de stakeholders zijn, weten wat hun concerns zijn en zorgen dat die concerns op een bruikbare manier beschreven zijn.
Het opstellen van een architectuur is de primaire taak van de architect. De architectuur ontstaat door het maken van afgewogen beslissingen. Een goede architectuurbeslissing is het resultaat van een afweging tussen verschillende stakeholderbelangen. Sommige belangen zijn expliciet gemaakt in beschreven concerns. Andere belangen zijn vertegenwoordigd via domeinkennis van de architect en betrokken stakeholders. Als een architectuur eenmaal opgesteld is, dan is de architect vooral bezig met het anticiperen en reageren op wijzigingen in de systeemomgeving.
De architect voert meerdere activiteiten uit om de architectuur uit te dragen: hij selecteert de viewpoints, plant de communicatie, zorgt dat de architectuur in de realisatie geborgd wordt en ondersteunt het management bij nemen van beslissingen. Bij al deze activiteiten handelt de architect als een gids en denkt als een bewaker.
De architectuur moet toegepast worden bij het realiseren van het systeem. Hiervoor moet de architectuur uitgelegd worden aan het realisatieteam. De architect controleert altijd of het realisatieteam de architectuur begrepen heeft. Een architectuur kan nooit goedgekeurd zijn als het realisatieteam niet weet hoe de architectuur toegepast moet worden.
[1] Vijf is een behapbaar aantal. Het kunnen er ook drie of zeven zijn. In de praktijk is minder dan drie te summier en meer dan zeven moeilijk te hanteren.
[2] UML kan uitgebreid worden door middel van profiles.