Goede architectuur

Robert Deckers, 3 maart 2012


Succesvolle systeemrealisatie en beheer kunnen niet zonder een goede architectuur. Maar, waar moet een goede architectuur aan voldoen of op welke vlakken is een architectuur te verbeteren? Dit artikel reikt handvatten aan om die vragen te beantwoorden.Het is de taak van de architect om een zo goed mogelijke architectuur op te stellen en uit te dragen. Veel boeken over architectuur (bijvoorbeeld 1, 2, 3 en 4) reiken daarvoor technieken aan. Maar, welke technieken zijn op welk moment het meest geschikt en wanneer moet hij die wel of niet toepassen? Om dat te bepalen moet je als architect als eerste weten wat een goede architectuur is. Dat laatste is het onderwerp van dit artikel.

Situatiespecifiek

Een architectuur vormt de balans tussen de belangen van verschillende stakeholders en biedt voor de belangrijkste eisen een oplossing. Zowel functionele eisen als kwaliteitseisen moeten binnen de architectuur passen en het systeem moet realiseerbaar zijn binnen het budget en binnen de bestaande plannen. Met systeem wordt datgene bedoeld waarvan de architectuur opgesteld wordt. Dat kan bijvoorbeeld een organisatie, een bedrijfsproces, de gehele informatievoorziening, een applicatielandschap, een enkele applicatie of de gehele it-infrastructuur zijn.

Een standaard architectuurraamwerk, een vaste architectuurtaal en voorgedefinieerde architectuurproducten zijn geen garantie voor een goede architectuur. Zij vormen in feite alleen kaders voor een gemiddeld systeem en gemiddelde organisatie. Maar, net zoals er geen gemiddelde Nederlander bestaat, bestaat er ook geen gemiddeld systeem. Het ene systeem maakt gebruik van nieuwe technologie, een ander systeem komt langs een afwijkend proces tot stand. Weer een ander systeem moet afwijkende kwaliteitseisen ondersteunen. Een goede architectuur is toegespitst op de unieke aspecten van het systeem en haar omgeving.

De eigenschappen

Een goede architectuur heeft verschillende eigenschappen. Deze kenmerken zijn afzonderlijk van elkaar te beschouwen. Aldus is het mogelijk de kwaliteit van een architectuur en de mogelijke verbeterpunten te bepalen.

De eigenschappen van een goede architectuur zijn:

  • Correct: de architectuur is gebaseerd op gevalideerde uitspraken over de systeemomgeving en de stakeholderbelangen in het bijzonder. De belangen zijn geprioriteerd. De architectuur vormt de juiste balans tussen de belangen.
  • Consistent: de architectuur vormt een samenhangend geheel. De architectuuruitspraken zijn onderling niet strijdig. Dit geldt niet alleen voor de uitspraken binnen de architectuur zelf, maar ook in relatie tot de omgeving. De architectuur moet te realiseren zijn in het systeem. Voor alle relevante eisen moet de architectuur een oplossing bieden.
  • 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. De stakeholders moeten begrijpen hoe hun eisen geborgd zijn. Een gecommuniceerde architectuur begint bij een communiceerbare architectuurbeschrijving.

Hoewel uitspraken als een architectuur moet flexibel zijn, modulair zijn, toekomstvast zijní vaak van toepassing zijn, zijn zij niet universeel geldig. Er zijn altijd voorbeelden van systemen waarvoor die uitspraken niet gelden (of niet het belangrijkste criterium voor succes zijn). Correctheid, consistentie en communiceerbaarheid zijn architectuurattributen die van toepassing zijn op alle systemen. Verderop worden deze begrippen verder toegelicht. Er is ook een vragenlijst die pragmatische handvatten biedt om te komen tot een goede architectuur en/of te bepalen hoe goed een architectuur is.

Afstemmen

De architectuur moet rekening houden met vele verschillende stakeholders en informatiebronnen. Zijn hebben elk hun eigen vaktaal en hanteren hun eigen notaties. De architectuur moet in overeenstemming zijn met bijvoorbeeld de projectroadmap van de programmamanager, de netwerktopologie van de netwerkarchitect, de componentenbibliotheek van de componentenbouwer, de financiÎle planning van de business manager, de wet- en regelgeving, de functionele structuur van functioneel beheer, de user interface van de eindgebruiker en het opleidings- en aannamebeleid van de HRM afdeling.

Natuurlijk zijn er in de praktijk nog veel meer stakeholders en specificaties waarop de architectuur moet passen. Daarnaast zullen de verschillende architectuurmodellen en -richtlijnen ook onderling in overeenstemming moeten zijn. Om deze te communiceren is het vaak nodig een vertaling te maken naar de taal van de stakeholders.

Figuur 1: De architectuur moet afgestemd worden met verschillende partijen op doelen, beperkingen en samenhang.

Correct

Correctheid van de architectuur wordt bereikt door het volgende:

  • Voldoende omgevingsanalyse: er zijn voldoende stakeholders, stakeholderbelangen en andere informatie over de omgeving van het systeem in beschouwing genomen en afgewogen. Deze informatie moet specifiek genoeg zijn om de architectuur op te baseren.
  • Bewuste afweging tussen belangen: een richtinggevende architectuur is het resultaat van een bewuste en traceerbare afweging tussen verschillende en mogelijk tegenstrijdige belangen en andere omgevingsuitspraken. De belangen zijn geprioriteerd. De prioritering is nuttig om afwegingen te maken tussen systeemeigenschappen die de belangen dienen.
  • Validatie van omgevingsuitspraken: de stakeholders herkennen en erkennen hun beweegredenen en doelen. De geldigheid van omgevingsinformatie is getoetst. Stakeholders begrijpen dat er een afweging is gemaakt en het soms op organisatieniveau beter is bepaalde wensen niet in te willigen. De afwegingen zijn ook gevalideerd.

Samengevat gaat het bij correctheid om de vraag "past het systeem in zijn omgeving?". Dit begint bij de vraag "is de architectuur gebaseerd op de juiste informatie over de omgeving?"

Consistent

Consistentie wordt bereikt door het volgende:

  • Verificatie op tegenstrijdigheid: alle architectuuruitspraken en relevante omgevingsuitspraken vormen een geheel. Dit geheel moet worden geanalyseerd op tegenstrijdigheden.
  • Aantoonbaar realiseerbaar: Het moet helder zijn dat het systeem met de architectuur en de gestelde middelen is te realiseren. Het realisatieteam moet de architectuur in de praktijk kunnen brengen.
  • Bewust beheerd: het moet duidelijk zijn wat wel en niet tot de architectuurbeschrijving hoort en hoe de architectuur wordt gewijzigd.

Samengevat gaat het bij consistentie om de vraag "Zit het systeem goed in elkaar?" Dit begint bij de vraag "zit de architectuur goed in elkaar?"

Consistentie geldt niet alleen als eis binnen de architectuurbeschrijving, maar ook in relatie tot uitspraken over de omgeving. Zo moet de broncode consistent zijn met de architectuurprincipes die erop van toepassing zijn. Maar bijvoorbeeld ook de structuur en terminologie van de requirements moeten passen op de architectuur. Daarnaast moeten ook het projectplan en werkpakketten passen op de systeemonderdelen die in de architectuur beschreven staan.

Communicatie

Een gecommuniceerde architectuur wordt bereikt door:

  • Vertaalbaar naar acties door stakeholders: De betrokkenen rond de architectuur ondernemen de juiste acties op basis van de architectuur.
  • Voldoende verankering: Er zijn genoeg stakeholders betrokken in de communicatie en zij moeten informatie van voldoende diepgang krijgen om de erkenning en toepassing van de architectuur te borgen.
  • Bewust uitgevoerd. De communicatie tussen de betrokkenen en de architectuur is gecoördineerd. De communicatievorm en inhoud zijn gepland en de architect weet wie waarvan op de hoogte is en hoe de informatie is overgebracht is.

Samengevat gaat het bij communicatie om de vraag "Weet iedereen wat hij moet weten van de architectuur?"

Tien vragen van de manager aan de architect

In een ontwikkelproces komt vaak de mijlpaal "architectuur gereed" voor. Echter, hoe bepalen de business manager, de projectleider, QA manager of de architectuur ook daadwerkelijk gereed is? Omdat architectuur de meer kwalitatieve aspecten van het systeem adresseert en per situatie een andere verschijningsvorm kan hebben, zal het niet eenvoudig zijn om een simpele test te doen. De uitgebreide vragenlijst in het bij dit artikel geplaatste kader kan hierbij helpen.

Een relatief eenvoudige toetsing is om de aan de architect te vragen hoe het staat met de architectuur. Managers die kennis van en ervaring met architectuur hebben kunnen dat gericht doen. Voor managers die dat in mindere mate hebben, is een aantal basisvragen voor handen. Het doel van deze vragen is een beeld te krijgen van de kwaliteit van de architectuur. De basisvragen aan de architect zijn:

  1. Wie zijn de stakeholders en wat is de grootste zorg van elke stakeholder?
  2. Wat zijn de vijf (een behapbaar aantal) belangrijkste doelen waar de architectuur invulling aan moet geven?
  3. Wat zijn de vijf moeilijkste kwesties waar de architectuur een oplossing voor biedt? Welke stakeholderbelangen 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 Toepassingsgebied, Technologie, Ontwikkel- en beheerproces, en 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. Hoe 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?

De architect moet op alle vragen antwoord kunnen geven of hij moet kunnen zeggen waarom hij geen antwoord heeft. Eventueel worden de antwoorden besproken met verschillende stakeholders, zodat de business manager de geldigheid kan toetsen.

Vragen van de architect aan zichzelf

Om met het begrip goede architectuur aan de slag te gaan zijn de onderstaande vragen een pragmatisch hulpmiddel. Ze zijn allesomvattend, maar leveren in praktijk genoeg stof tot nadenken en vormen een bruikbaar kader voor het handelen van de architect. Een effectieve architect zal bijna altijd bezig zijn om invulling te geven aan een of meerdere vragen.

Voor het onderdeel "Correctheid" zijn de volgende vragen nuttig:

  • Wat is de afbakening van het systeem? Denk aan afbakening in toepassingsgebied, technologie, realisatie en levensduur.
  • Welke omgeving wordt beschouwd (ook in de tijd)? Hoever ga je? Denk aan concurrenten, marktontwikkelingen, technologische ontwikkelingen, samenwerking met partners, aangrenzende systemen, gerelateerde projecten.
  • Wie zijn de stakeholders?
  • Wat zijn de belangen van elke stakeholder?
  • Wat is belangrijke omgevingsinformatie? Denk hierbij aan inputdocumenten, marktinformatie, wet- en regelgeving.
  • Hoe wordt de omgevingsinformatie gebruikt als input voor de architectuur?
  • Wat is de prioritering van de verschillende belangen?
  • Is de prioritering bruikbaar om afwegingen te maken?
  • Welke afwegingen zijn gemaakt in de architectuur?
  • Hoe zijn deze terug te herleiden naar de stakeholderbelangen en hun prioritering?
  • Op welke andere omgevingsinformatie zijn de afwegingen gebaseerd?
  • Waaruit blijkt of de stakeholders de afweging begrijpen?
  • Hoe (h)erkennen de stakeholders de beschreven belangen?
  • Hoe zijn de andere uitgangspunten over de omgeving gecontroleerd op geldigheid?
  • Hoe komt de prioritering van belangen tot stand? De rol van de systeemeigenaar is daarbij het belangrijkst.

Voor het onderdeel "Consistentie" zijn de volgende vragen nuttig:

  • Welke terminologie wordt gebruikt in de architectuurbeschrijving? Is er bijvoorbeeld een expliciete woordenlijst van te gebruiken termen?
  • Hoe wordt ervoor gezorgd dat de terminologie begrepen wordt?
  • Hoe wordt de architectuur geanalyseerd op tegenstrijdigheden? Zijn er consistentieregels en hoe worden ze getoetst?
  • Hoe is duidelijk dat alle architectuuruitspraken aansluiten op een omgevingsuitspraak? Passen ze op een stakeholderbelang of uitgangspunt over de omgeving?
  • Waaruit blijkt dat de belangrijkste architectuuruitspraken dezelfde belangen dienen?
  • Hoe wordt ervoor gezorgd dat de architectuur toegepast wordt tijdens realisatie?
  • Hoe wordt aangetoond of het systeem volgens de architectuur is te realiseren?
  • Hoe wordt aangetoond of het systeem volgens de architectuur is gerealiseerd?
  • Wat hoort wel en niet tot de architectuurbeschrijving?
  • Hoe wordt de architectuur beheerd?
  • Hoe is de architectuur vastgelegd?

Voor het onderdeel "Gecommuniceerd" zijn de volgende vragen nuttig:

  • Welke rol speelt de architectuur in de activiteiten van de stakeholders? Wat moet elke stakeholder met de architectuur doen?
  • Hoe is duidelijk of de stakeholders informatie van voldoende diepgang hebben (om de juiste acties te kunnen ondernemen)?
  • Hoe wordt bepaald of de architectuur goed is vertaald? Wat gebeurt er als dat niet zo is?
  • Hoe is duidelijk of de belangrijkste/invloedrijkste stakeholders betrokken zijn in de communicatie?
  • Wie erkent de architectuur en wie niet?
  • Wat wordt gecommuniceerd over architectuurvisie, voorspelde gevolgen en behaalde successen?
  • Hoe wordt de architectuur ingebed in ontwikkelproces/-straat?
  • Hoe wordt de communicatie gecoördineerd?
  • Hoe worden de communicatievorm en inhoud gepland en vastgelegd?
  • Hoe is bekend wie waarvan op de hoogte is of op de hoogte zou moeten zijn?

Referenties

  1. Len Bass, et al. Software Architecture in Practice, 2nd Edition, ISBN 0-321-15495-9
  2. Nick Rozanski, Eoin Woods. Software Systems Architecture, Working with views and perspectives, ISBN 0-321-11229-6
  3. Jan Bosch. Design and Use of Software Architectures: Adopting and Evolving a Product-Line Approach, ISBN 0-201-67494-7
  4. DYA, snelheid en samenhang in business- en ICT-architectuur, ISBN10 9072194624; www.dya.info
  5. R. Deckers, R. Steeghs, DYA|Software, Architectuuraanpak voor bedrijfskritische applicaties, ISBN 978-90-75414-31-8

Opmerking

Je moet lid zijn van Via Nova Architectura om reacties te kunnen toevoegen!

Wordt lid van Via Nova Architectura

Reactie van Mark Paauwe (Founder of Dragon1) op 23 Augustus 2012 op 12.24

Robert,

Heel interessant om te lezen. Wat ik niet lees, of waar ik overheen lees, is wat jij ziet wat de onderdelen of bouwstenen zijn van architectuur. Voor mij zijn de bouwstenen van een business architectuur de bedrijfskundige concepten die de literatuur ons aanreikt. Waarbij je als architect de zinvolheid van het inzetten op een bepaalde wijze van een bedrijfskundig concept af laat hangen van de gestelde eisen door stakeholders en je eigen ervaring en creativiteit.

Stel een organisatie heeft als ambitie "Verhogen van omzet en verlagen van kosten voor het verkoopproces". Het bedrijfskundig concept "Self Service" zou dan mogelijk een correct concept zijn om onderdeel te maken van de business architectuur. Het self-service-principe "Klanten zelf producten laten kiezen en laten afrekenen wanneer het hun uitkomt, verlaagt de kosten van het verkoopproces en verhoogt het aantal transacties en de omzet." is dan voor deze organisatie een mogelijk business architectuurprincipe als het concept self-service voldoende correct en volledig wordt geimplementeerd in de organisatie.

Stel de organisatie slaagt er niet in om 1 en slechts 1 up-to-date productencatalogus er op na te houden, dan gaat self-service geen voordelen opleveren, immers klanten kunnen verkeerde producten bestellen. En stel dat de webshop waar klanten spullen op zouden kunnen bestellen veel duurder wordt dan de kosten besparingen vanwege integratiegedoe met systemen die men niet wil uitfaseren, ook dan gaat self service geen voordeel opleveren.

De architect kan op de tekentafel al heel ver komen om te zien of self-service als bedrijfskundig concept meer voordelen dan nadelen als onderdeel van de business architectuur voor deze opdrachtgever.

Zo ben ik vaak bezig bij organisaties om architecten te ondersteunen en trainen in het visueel en beslisbaar maken van business architectuur.

Wat zijn voor jou de bouwstenen of onderdelen van architectuur? Welke definitie voor architectuur gebruik je om dat te onderbouwen.

Ik pleit in mijn reactie op deze blog voor voorbeelden: http://vianovaarchitectura.nl/page/naf-rondetafelsessie-businessarc...

Heb jij wellicht een voorbeeld van wat jij ziet als goede architectuur? En dan het liefst natuurlijk in visuele vorm, waarin ik zie welke onderdelen of bouwstenen voor architectuur je hebt gekozen en welke eisen van belanghebbenden maken dat dat goede bouwstenen voor architectuur voor de opdrachtgever/belanghebbenden zijn.

Ik hoor graag van je.

Sponsoren

Sessies

15/16-11: Landelijk Architectuur Congres meer...

Advertenties

Je kunt hier adverteren

© 2018   Gemaakt door Stichting Digital Architecture.   Verzorgd door

Banners  |  Een probleem rapporteren?  |  Algemene voorwaarden