Follow Us on Twitter

Realiseren van SOA onder architectuurgovernance

Mei 2014 – Met behulp van SOA kunnen IT-oplossingen sneller, beter en goedkoper worden gerealiseerd. Om deze voordelen ook echt te realiseren, is het belangrijk dat SOA op de juiste manier wordt toegepast, hetgeen kan worden bereikt met behulp van SOA-governance.

SOA-governance is een specialisatie van governance die zich richt op services en gerelateerde SOA-artefacten, zoals aangegeven in onderstaande figuur uit de SOA Governance Definitie van The Open Group.

Governance in relatie tot SOA volgens The Open Group

In dit Whitebook beschrijf ik hoe SOA-governance in de praktijk kan worden toegepast als uitbreiding van architectuurgovernance (EA-governance). Dit is hard nodig om ervoor te zorgen dat services ook daadwerkelijk conform de bedachte architectuur worden gerealiseerd in projecten.

SOA-governance

In mijn eerdere Whitebooks heb ik beschreven wat SOA-governance inhoudt en wat een pragmatische, lichtgewichte aanpak voor het invoeren hiervan is (zie Invoering van SOA onder governance en Stuurbekrachtiging voor SOA – een lichtgewicht aanpak voor SOA-governance).

Deze aanpak houdt onder meer in dat in de eerste fase van een SOA-invoeringstraject de volgende SOA-governanceproducten worden gemaakt.

SOA-governanceproducten in het SOA-invoeringstraject

Verder wordt in deze aanpak aanbevolen om SOA-governance zoveel mogelijk in bestaande governance en processen te verwerken, waaronder in architectuurgovernance en -processen. Hierbij moet duidelijk worden gemaakt hoe bovengenoemde producten daarin passen. Dit licht ik hieronder verder toe, waarbij ik vooral zal ingaan op het architectuurproces “Werken onder architectuur”, inclusief het omgaan met architectuurafwijkingen.

Architectuurprocessen

Het ontwikkelen en toepassen van architectuur binnen een organisatie wordt in principe beschreven in architectuurprocessen. Vaak worden hierbij de volgende twee hoofdprocessen onderscheiden:

  • maken architectuur;
  • werken onder architectuur.

Proces "Maken Architectuur"

In dit proces wordt geregeld hoe architectuurproducten tot stand komen. Wie geeft opdracht voor een architectuurproduct, wie maakt het en op welke manier, wie keurt het goed, wie onderhoudt/beheert het en op welke manier, etc.?

Bij architectuurproducten wordt onderscheid gemaakt tussen:

  • Concrete architecturen. Deze beschrijven de concrete architectuur van functionele domeinen binnen een organisatie op het niveau van business, informatie, applicaties en infrastructuur. Hierbinnen wordt weer onderscheid gemaakt tussen:
    • as-is architecturen: deze beschrijven de huidige situatie.
    • to-be architecturen: deze beschrijven de toekomstige, gewenste situatie.
  • Architectuurkaders. Dit zijn principes, modellen, ontwerppatronen, standaarden, richtlijnen, technologiekeuzes, methoden, technieken, architectuurrepository, en dergelijke. Deze kaders vormen in feite de spelregels die gelden voor het realiseren van to-be architecturen.

De eerder genoemde SOA-governanceproducten "SOA-referentiearchitectuur", "SOA-ontwikkelstandaarden" en "SOA-repository" zijn architectuurkaders en komen dus tot stand in het proces "Maken architectuur".

Proces "Werken onder Architectuur"

In dit proces wordt geregeld hoe architectuur moet worden toegepast bij veranderingen binnen de organisatie. In principe zullen de veranderingen moeten bijdragen tot het realiseren van de to-be architecturen, waarbij moet worden voldaan aan de architectuurkaders.

Veranderingen binnen een organisatie vinden doorgaans plaats in projecten, die eventueel gebundeld zijn in een (verander)programma. Werken onder architectuur kan daarom ook worden gezien als het toepassen van architectuur binnen projecten. Overigens vindt het maken van architectuurproducten vaak ook binnen projecten plaats, met name in de beginfase.

Een belangrijk hulpmiddel bij het op de juiste wijze toepassen van architectuur binnen projecten is de PSA – Project Start Architectuur. In een PSA wordt typisch het volgende beschreven:

  • De veranderingen in architectuur die het project maakt, oftewel welk deel van de to-be architectuur door het project wordt gerealiseerd. Dit beschrijft in feite ook de architectuur-scope/afbakening van het project.
  • De architectuurkaders die voor het project van toepassing zijn, bijvoorbeeld de SOA-referentiearchitectuur.
  • De architectuurbeslissingen, inclusief hun rationale, die binnen het project zijn genomen.
  • Architectuurafwijkingen die door het project worden gemaakt en waarvoor toestemming is verleend.
  • Architectuuractiepunten die binnen het project moeten worden geadresseerd.

Een PSA is dus geen ontwerpdocument. Hooguit wordt in de PSA de interne architectuur/structuur van de oplossing beschreven die door het project zal worden gerealiseerd. Op basis hiervan maakt een analist/ontwerper het ontwerp van de oplossing.

Een PSA vormt de inhoudelijke basis voor een PID (Project Initiatie Document). Beide documenten moeten daarom in samenhang zijn opgesteld voordat (de implementatiefase van) een project van start gaat.

Een PSA is, net als een PID, een projectdocument dat in principe ophoudt te bestaan als het project is afgelopen. Dat betekent dat de architectuurveranderingen van het project moeten worden verwerkt in de lijnarchitectuur.

Het werken onder architectuur binnen projecten is de verantwoordelijkheid van de projectarchitect. Deze heeft onder meer de volgende taken:

  • Maken van PSA aan begin van project (eventueel als architectuurintake uitwijst dat dit nodig is).
  • Inhoudelijk bijstaan van projectleider, onder meer bij opstellen van PID in samenhang met PSA.
  • Toetsen of project conform PSA werkt; eventuele architectuurafwijkingen verwerken volgens architectuurproces.
  • Ondersteunen van projectleden (bijv. architectuur uitleggen, oplossingen voorstellen of valideren, ontwerpen reviewen, helpen bij problemen, e.d.).
  • Bijwerken van PSA gedurende project indien nodig, bijvoorbeeld bij nieuwe architectuurafwijkingen.
  • Bijwerken lijnarchitectuur, zoals as-is architecturen, register met architectuurafwijkingen en architectuurkaders.
  • Bespreken projectarchitectuur met Architectuurteam, met name review en bespreking van PSA’s.

Binnen een project worden producten ontwikkeld conform een ontwikkelproces. In dit ontwikkelproces worden onder meer ook de rol van de (project)architect en zijn activiteiten beschreven. Voor het beschrijven van een proces wordt vaak gebruik gemaakt van processtroomdiagrammen en RASCI-matrices. In een stroomdiagram wordt aangegeven welke deliverables in welke fase door welke rol moeten worden opgeleverd. In een RASCI-matrix wordt aangegeven wat de verantwoordelijkheden van de rollen hierbij zijn: R(esponsible), A(ccountable), S(upport), C(onsulted), of I(nformed). In de volgende figuur wordt een voorbeeld hiervan geschetst.

Voorbeeld van RASCI-matrix voor werken onder architectuur

In het processtroomdiagram en de bijbehorende RASCI-matrix in bovenstaande figuur zijn de rol van (project)architect en zijn activiteiten (bijv. “Maken PSA”) te zien.

Verder zijn in bovenstaande figuur deliverables met betrekking tot services en canonieke datadefinities opgenomen. Op deze wijze is het eerder genoemde SOA-governanceproduct “SOA-ontwikkelproces” verwerkt in het overall ontwikkelproces, waarin bovendien de relatie met het architectuurproces “Werken onder architectuur” wordt gelegd.

Architectuurgovernance

Binnen de architectuurprocessen wordt ook aangegeven wie waarvoor verantwoordelijk is, vaak met behulp van een RASCI-matrix. Dit wordt wel architectuurgovernance genoemd. Belangrijk hierbij is wie waarover besluiten neemt en wat de escalatieprocedures hierbij zijn.

Architectuurboard

Voor architectuurgovernance in het algemeen is de Architectuurboard het belangrijkste beslissingsorgaan. Hiervoor geldt typisch het volgende:

  • Bestaat uit senior business- en IT-management.
  • Heeft de volgende taken:
    • Opdracht geven voor architectuurproducten.
    • Goedkeuren van architectuurproducten (to-be architecturen en architectuurkaders).
    • Goedkeuren van PSA’s, inclusief eventuele architectuurafwijkingen hierin.
    • Monitoren van voortgang PSA’s en register van architectuurafwijkingen.
    • Communiceren van architectuurbeslissingen naar onderliggend management.
  • Wordt geadviseerd door het Architectuurteam. Het Architectuurteam neemt zelf geen formele beslissingen; het maakt architectuurbeslissingen en hun consequenties inzichtelijk voor de Architectuurboard.
  • Bij onenigheid wordt geëscaleerd naar de Managementboard.
  • Eventueel kan een Programmaboard tevens als Architectuurboard acteren voor dat programma.

Architectuurgovernance binnen projecten

Binnen projecten heeft architectuurgovernance vooral betrekking op de besluitvorming rond PSA’s, inclusief de hierin beschreven architectuurafwijkingen. Hiervoor geldt typisch het volgende:

  • De PSA is een projectdeliverable waarvoor de projectleider accountable is.
  • De PSA wordt gemaakt en onderhouden door de projectarchitect; deze is dus responsible voor de PSA.
  • De PSA moet worden geaccepteerd door het Architectuurteam en de Projectboard. Dit is echter geen formele goedkeuring. Bij onenigheid wordt geëscaleerd naar de Architectuurboard.
  • De PSA wordt formeel goedgekeurd door de Architectuurboard. Bij onenigheid wordt geëscaleerd naar de Managementboard.
  • De implementatiefase van het project (ontwerp, bouw, etc.) mag pas starten nadat de PSA formeel is goedgekeurd.

De architectuurgovernance binnen projecten wordt schematisch weergegeven in de volgende figuur.

Schematische weergegave van architectuurgovernance binnen projecten

De grootste uitdaging van de projectarchitect is vaak hoe het beste kan worden omgegaan met architectuurafwijkingen, gebruikmakend van de architectuurgovernance. Dit wordt hieronder in een aparte sectie besproken.

Omgaan met architectuurafwijkingen in projecten

Wanneer ergens een goede architectuur voor is bedacht en deze is goedgekeurd door de Architectuurboard is het natuurlijk zaak om deze architectuur ook daadwerkelijk te implementeren.

Toch kunnen er goede redenen zijn om af te wijken van de gewenste architectuur. Bijvoorbeeld omdat een bepaalde architectuurcomponent nog niet beschikbaar is of omdat er snel een werkende deeloplossing beschikbaar moet komen. Op zich hoeft dat niet erg te zijn, mits de beslissing om af te wijken bewust en formeel wordt genomen door de Architectuurboard. Hiervoor is het nodig dat de redenen en consequenties van de architectuurafwijking inzichtelijk worden gemaakt voor de Architectuurboard, zodat deze een weloverwogen besluit kan nemen.

Vastleggen en goedkeuren van architectuurafwijkingen

Een projectarchitect dient een architectuurafwijking volgens een vaste structuur te beschrijven, bijvoorbeeld volgens onderstaand template.

AA-code
       <Code van de architectuurafwijking, om er elders gemakkelijker aan te kunnen refereren.>
Beschrijving
  <Beschrijving van de architectuurafwijking.>
Type
  <Type architectuurafwijking: Tijdelijk of Permanent.>
Redenen
  <Redenen van de architectuurafwijking; waarom moet worden afgeweken?>
Consequenties
  <Consequenties van de architectuurafwijking.>
Maatregelen
  <Maatregelen die worden genomen om de consequenties van deze architectuurafwijking zoveel mogelijk te compenseren. Ook aangeven wie accountable en responsible hiervoor is. Bij een tijdelijke architectuurafwijking kan hier bijvoorbeeld worden aangegeven door welk ander project deze zal worden opgelost.>

Bovengenoemde beschrijvingen van architectuurafwijkingen worden opgenomen in de PSA en ter goedkeuring voorgelegd aan de Architectuurboard. Architectuurafwijkingen die tijdens het project ontstaan worden vaak in een apart beslismemo ter goedkeuring voorgelegd aan de Architectuurboard en vervolgens opgenomen in de PSA. Goedkeuring van een architectuurafwijking houdt overigens ook in dat de Architectuurboard de beschreven consequenties en maatregelen accepteert en goedkeurt.

Omdat een PSA een tijdelijk projectdocument is, dienen nog openstaande architectuurafwijkingen van het project te worden opgenomen in een (permanent) register van architectuurafwijkingen (AA-register). In een dergelijk AA-register kan naast bovengenoemde informatie bijvoorbeeld ook het volgende worden vastgelegd:

  • Door welke board en wanneer is de architectuurafwijking goedgekeurd?
  • Wie is accountable voor de te nemen maatregelen van de architectuurafwijking?
  • Wanneer wordt de tijdelijke architectuurafwijking opgelost?

Het AA-register kan periodiek worden besproken in het Architectuurteam en de Architectuurboard om de voortgang van het oplossen van architectuurafwijkingen te monitoren.

Tips

De praktijk is vaak weerbarstig. Daarom geef ik hieronder een aantal tips om ook daadwerkelijk volgens bovengenoemd proces voor architectuurafwijkingen te kunnen werken.

  • Zorg ervoor dat er een Architectuurboard is, waarin zowel business- als IT-management is vertegenwoordigd. Dit hoeft niet per se een nieuwe board te zijn, maar kan ook een bestaand managementgremium zijn dat ook expliciet de rol van Architectuurboard invult. De architectuurbeslissingen van de Architectuurboard dienen expliciet te worden vastgelegd en toegankelijk te zijn voor alle betrokkenen.
  • Zorg ervoor dat architectuurprocessen, inclusief het omgaan met architectuurafwijkingen, zijn goedgekeurd door de Architectuurboard. Zorg er bovendien voor dat ze goed bekend zijn bij en worden geaccepteerd door business-, programma- en projectmanagement (dit is ook een taak van de Architectuurboard).
  • Reserveer bovenstaande werkwijze voor architectuurafwijkingen alleen voor “echte” architectuurafwijkingen, waarbij het project bepaalde functionaliteit echt anders wil realiseren dan volgens de beoogde architectuur. Deze architectuurafwijkingen zullen namelijk niet door het project worden opgelost. Gebruik deze werkwijze dus niet voor architectuurafwijkingen die er zijn omdat het project bepaalde functionaliteit nog niet geheel (conform architectuur) heeft gerealiseerd. Deze “architectuurafwijkingen” verdwijnen namelijk zodra de functionaliteit conform plan en architectuur is gerealiseerd door het project.
  • Voor echte architectuurafwijkingen moeten goede redenen zijn. Bespreek de redenen met degene die uiteindelijk van de architectuur wil afwijken, vaak iemand uit de business. Bespreek vervolgens ook de consequenties en eventuele maatregelen en ga na of men de architectuurafwijking dan nog steeds wil. Het is van groot belang om deze redenen, consequenties en maatregelen goed te beschrijven zodat de Architectuurboard een weloverwogen besluit kan nemen. Bij grote architectuurafwijkingen is het raadzaam om deze vooraf met Architectuurboard-leden te bespreken.
  • Grote projecten worden soms opgedeeld in fasen. Behandel dan in principe elke fase als een apart project met betrekking tot het architectuurproces “Werken onder architectuur”. Dus bijvoorbeeld architectuurafwijkingen die het project in een fase wil maken, worden opgenomen in de PSA van die projectfase. Een maatregel kan dan zijn dat de architectuurafwijkingen in een volgende projectfase worden opgelost.
  • Soms wil een project al functionaliteit in productie nemen die nog niet geheel conform architectuur is gerealiseerd. In dat geval is het wel goed om inzichtelijk te maken wat er dan nog niet conform architectuur is en wat de risico’s daarvan zijn voor het in productie nemen. Een dergelijk overzicht kan, naast andere acceptatiecriteria, worden gebruikt voor het acceptatieproces voor de productierelease. Verder kan de projectboard erop sturen dat het verder realiseren van de functionaliteit conform architectuur expliciet in de projectplanning wordt opgenomen. De projectarchitect kan hierbij adviseren en dit monitoren.

Conclusie

We hebben in dit Whitebook gezien dat SOA-governance goed in bestaande governance en processen kan worden verwerkt, met name in architectuurgovernance en -processen.

De twee belangrijkste architectuurprocessen zijn "Maken architectuur" en "Werken onder architectuur". Het maken van de "SOA-referentiearchitectuur", "SOA-ontwikkelstandaarden" en "SOA-repository" valt onder het proces "Maken architectuur". In het "SOA-ontwikkelproces" zijn ook activiteiten en rollen van het proces "Werken onder architectuur" opgenomen, bijvoorbeeld het maken van een PSA door een projectarchitect.

Voor architectuurgovernance is de Architectuurboard het belangrijkste beslissingsorgaan. Binnen projecten heeft architectuurgovernance vooral betrekking op de besluitvorming rond PSA’s, inclusief de hierin beschreven architectuurafwijkingen. Er kunnen in de praktijk goede redenen zijn om af te wijken van de gewenste architectuur. Het is dan wel noodzakelijk dat de beslissing om af te wijken bewust en formeel wordt genomen door de Architectuurboard.

Het daadwerkelijk werken volgens de architectuurprocessen valt in de praktijk niet altijd mee. De volgende tips kunnen hierbij helpen:

  • Zorg ervoor dat architectuurgovernance en architectuurprocessen duidelijk zijn ingebed in de organisatie. Zorg dat ze goed bekend zijn bij en geaccepteerd door business-, programma- en projectmanagement.
  • Reserveer de werkwijze voor architectuurafwijkingen alleen voor "echte" architectuurafwijkingen.
  • Bespreek redenen, consequenties en maatregelen van een architectuurafwijking met degene die wil afwijken. Beschrijf deze duidelijk zodat de Architectuurboard een weloverwogen besluit kan nemen.
  • Behandel elke fase van een groot project als een apart project met betrekking tot het architectuurproces “Werken onder architectuur”; hanteer met name aparte PSA en architectuurafwijkingen per projectfase.
  • Neem "architectuurafwijkingen" bij het in productie nemen van nog niet geheel conform architectuur gerealiseerde functionaliteit mee in het acceptatieproces van de productierelease.

Referenties

Waardering:
 

Reacties

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.

Meer informatie over formaatmogelijkheden

CAPTCHA
Deze vraag is om te testen of u een persoon bent en om spam te voorkomen
Image CAPTCHA
Enter the characters shown in the image.