Vaarwel architectuur document. Welkom achitectuur repository!

Kenmerken

• Enterprise- en Solution Architectuur wordt uitgewerkt in architectuur documenten zoals:
  • Architectuur landschappen en – grondplaten;
  • Lijsten en collecties (bijvoorbeeld principes);
  • Project (Start) Architecturen.
• Gebruik van met name kantoorautomatisering, veelal is dit een combinatie van Word, Excel, PowerPoint en incidenteel Visio.
• Document sjablonen, soms zijn er sjablonen van bepaalde architectuur documenten aanwezig, denk aan een sjabloon voor Project Start Architecturen die op internet te vinden zijn.
• Architectuur Werkprocessen, processen rond ontwikkelen, validatie en onderhoud van de architectuur zijn nauwelijks ontwikkeld, soms is er een architectuur board die documenten bespreekt maar het handhaven van latere veranderingen in de architectuur is niet uitgewerkt.
• Samenwerkingsomgevingen, incidenteel worden omgevingen als SharePoint of Confluence gebruikt, met name om collecties van architectuurdocumenten te ontsluiten voor de verschillende stakeholders.

Wat zijn de voordelen?

Deze vorm van architectuur ontwikkelen en beheren wordt breed toegepast en niet zonder reden. Het heeft een aantal voordelen zoals:

• Documenten zijn op zichzelf staande artefacten;
• Vervaardigen van documenten is een op zichzelf staand proces, zonder dat dit invloed heeft op andere documenten;
• Er zijn beperkte relaties met andere architectuur documenten;
  • Verwijzingen
  • Kopieer acties
• Review en goedkeuring van een document staat los van de andere architecturen en reviewprocessen en vindt alleen plaats op dit document;
• Vervaardigings- en onderhoudsritme documenten is vrij definieerbaar.

En de nadelen?

De voordelen zijn waarschijnlijk herkenbaar, maar zijn ook herkenbaar als nadeel van deze aanpak. Hieronder een opsomming van de nadelen van een document gedreven architectuur:

• Architectuur is verdeeld over meerdere documenten, dat maakt onderhoud bijzonder complex. Daarnaast ontstaan er inconsistentie in de architectuur als de uitwerking in de document niet consequent gelijkgeschakeld wordt;
• Moeilijk om een overzicht van de gehele architectuur te krijgen, dit overzicht is verspreid over meerdere documenten;
• Inconsistenties in model en tijd van de architectuur in verschillende documenten;
  • Duplicaten van deelarchitecturen
  • Verschillende viewpoints
• Onderhouden van bestaande architectuur documenten is onvoldoende ingebed, als een deelarchitectuur wordt opgeleverd dan is er geen activiteit ingebed om de voorgaande architecturen te controleren en desgewenst te corrigeren;
• Agile architectuur is lastig realiseerbaar, het vervaardigen en steeds bijstellen van een document in een agile proces is een probleem;
• Weinig standaardisatie van modellen, templates en viewpoints, met name de modelleerconventies zijn veelal nauwelijks uitgewerkt;
• Specifieke modellen voor specifieke stakeholders nauwelijks mogelijk. Het vervaardigen van een document is al tijdrovend, specifieke documenten voor verschillende stakeholders is praktisch onmogelijk.

Gaan de nadelen van deze aanpak steeds meer knellen in een architectuurteam dan moet gezocht worden naar een alternatieve aanpak. Er zijn meerdere oplossingsrichtingen. Hieronder de meest voorkomende:

• Optimaliseer document gedreven architectuurprocessen;
• Inzet van samenwerkingsplatformen zoals SharePoint en Confluence;
• Inzet van een architectuur repository.

De aanpak met een architectuur repository wordt in de rest van dit artikel uitgewerkt.

Repository gebaseerde architectuur

Een Repository kenmerkt zich in een centrale plek waar alle (architectuur) modellen samengebracht worden zodat daar gezamenlijke ontwikkeling en beheer plaatsvindt. Daarnaast is het een omgeving voor het raadplegen van de complete architectuur. Hieronder een afbeelding welke onderdelen dit kan omvatten.

Kenmerken

• Verschillende architecturen worden samengebracht in één (geautomatiseerde) omgeving. Dit is veelal een relationele database die de modelleurs ondersteund in het consistent houden van de verbanden.
• In de omgeving worden de verbanden tussen de verschillende architecturen aangebracht, er worden daarmee verbanden aangebracht tussen referentie-, domein- en solutionarchitecturen.
• Veelal alle architecturen in één model naar publicatie (of document generatie) van een specifieke (deel)architectuur. Daarnaast de mogelijkheid om naast documenten ook andere publicatievormen en artefacten te produceren vanuit de repository.
• Samenwerken is een essentieel onderdeel in de repository, omdat iedereen in dezelfde modellen werkt is samenwerking een vanzelfsprekendheid.
• Gebruik van specifieke repository tooling (zowel desktop als web-based). Voor architectuur repositories is tooling essentieel maar gelukkig in elke prijscategorie verkrijgbaar.

Wat zijn de voordelen?

• Architectuurmodel is gecentraliseerd daardoor (dus alle modellen samengebracht in een repository):
  • Meer samenhang en standaardisatie van de modellen;
  • Meer hergebruik van deelmodellen, deelmodellen die reeds aanwezig zijn in de repository kunnen worden uitgebreid cq aangepast.
• Ontwikkelen architectuurdocumenten wordt sneller door:
  • Automatisering
  • Publiceren van documenten
  • Gebruik van sjablonen
  • Validatie en reviewproces is eenvoudiger te ondersteunen door ondersteuning binnen de repository.
• Agile architectuur eenvoudiger te ondersteunen, vanwege het hergebruik en het gebruik van de functionaliteiten die een agile werkwijze ondersteunen.
• Specifieke (deel)modellen voor specifieke stakeholders eenvoudig mogelijk, omdat alles op een centrale plek samengebracht is kun je hier per doel of doelgroep separate views op maken die de bestaande modellen weergeven.

En de nadelen?

• Vraagt om standaardisatie van:
  • Architectuurprocessen (modelleren en valideren)
  • Architectuurmodellen
• Alles hangt met alles samen
  • dus modelaanpassingen hebben direct impact op de andere modellen
  • Losstaande uitwerkingen vragen later rework, dus werk bij voorkeur in de centrale repository.
  • Onderscheid baseline en target vraagt discipline en werkafspraken
• Zonder vergaande werkafspraken tussen de architecten grote kans op inconsistenties, duplicaten en onwenselijke modelaanpassingen.
• Veel voorafgaande configuratie/afspraken voor daadwerkelijk begonnen kan worden met architectuur

Uit voorgaande blijkt dat een architectuur repository een goed antwoord is op de tekortkomingen van de document gedreven architectuur. Toch zie je regelmatig dat een architectuurteam de overstap naar een repository probeert te maken maar toch na enige tijd weer terugkeert naar de document gedreven aanpak.

Dat wordt niet veroorzaakt door de architectuur repository en de tooling die daarvoor beschikbaar is. De techniek doet het wel. Echter veelal ontstaan knelpunt om de volgende redenen:

• Er wordt teveel tegelijkertijd veranderd, dus zowel de introductie van een tool, als een nieuwe werkwijze en ook nieuwe modelleertalen.
• Onvoldoende afspraken binnen de architectuur community waardoor iedereen een eigen modelleerwijze kiest.
• Repository wordt gezien als een geavanceerd tekentool en de positieve kenmerken van een repository worden onvoldoende benut.
• Niet iedere stakeholder wordt betrokken bij de introductie van een repository. Soms wordt zelfs toegestaan dat een aantal architecten in kantoorautomatisering mogen blijven werken.
• Er is geen rol gedefinieerd die de kwaliteit van de repository inhoud en de werkwijze bewaakt en stimuleert.

Introductie van een architectuur repository is een verandertraject met een behoorlijk impact op het architectuurteam en de stakeholders rond dit team. In de volgende paragraaf geef ik een beeld van een mogelijk stappenplan en een aantal aanvullende tips.

Tips voor een succesvolle overstap

In de voorgaande paragrafen is de introductie van een architectuur repository toegelicht. Hierbij zijn zowel de kansen als de bedreigingen aan de orde gekomen. Hieronder doe ik een aantal suggesties die je kunnen helpen bij het succesvol introduceren van een architectuur repository.

Stappenplan

Gezien de complexiteit van een veranderingstraject voor een architectuur repository is een gestructureerde aanpak noodzakelijk. Deze gestructureerde aanpak wordt bij voorkeur ingedeeld in een aantal kleine definieerbare stappen, een stappenplan. In onderstaande afbeelding zie je een voorbeeld van een dergelijke stappenplan uitgewerkt in een eenvoudig ArchiMate diagram met bedrijfsprocessen.

In dit stappenplan wordt eerst een tool geselecteerd, zoals reeds aangegeven er zijn meerdere tools beschikbaar. De voorbeelden in dit artikel zijn op basis van Sparx Enterprise Architect. Vervolgens wordt het tool ingericht en in de laatste stap worden de betrokkenen geïnformeerd en getraind over de nieuwe werkwijze en tooling. Naast deze stappen zijn er een aantal detailstappen uitgewerkt die binnen de training in detail toegelicht worden.

Tips

Naast het gebruik van stappenplannen wil ik graag en aantal aanvullende tips geven:

• Beperk het aantal modelleertalen, rond Enterprise architectuur modellering is er een veelheid aan modelleertalen beschikbaar. Denk aan ArchiMate, UML, BPMN, DMN, BizBoK of SysML. Allen hebben kenmerken die bruikbaar zijn. Echter, omdat modellering in een repository een gemeenschappelijke activiteit is dient het aantal talen beperkt te blijven. Dit om gezamenlijkheid en hergebruik te stimuleren. Kies bij voorkeur ArchiMate en alleen indien noodzakelijk een of twee aanvullende modelleertalen.
• Beperk de modelleerconcepten binnen modelleertalen, talen als ArchiMate en UML hebben een veelheid aan modelleerconcepten. Bijvoorbeeld elementen, associaties domeinen, viewpoints etc. Lang niet alle concepten zijn relevant in de context van de eigen organisatie. Maak daarom een selectie en werk dit uit in een metamodel. Ook hierbij er wordt gewerkt in een gezamenlijk model. Bijkomend voordeel is dat je modellen eenvoudiger te begrijpen worden voor de verschillende stakeholders.
• Introduceer een modelleer community, in een architectuur repository is een gezamenlijke taal of modelleerwijze noodzakelijk voor succes. Daarom moeten alle betrokken modelleurs mee kunnen denken en discussiëren over hoe de taal gebruikt wordt binnen de context van de eigen organisatie. Hiermee introduceer je de gemeenschap van het model.
• Benoem een modelmanager, als er in een architectuurdocument inconsistenties staan hoeft dit geen probleem te zijn. Echter in een gezamenlijk model heeft elke onvolkomenheid invloed op het gehele model. Daarom is het bewaken van de kwaliteit in de repository belangrijk. Een rol die deze kwaliteit bewaakt en modelleurs ondersteunt en traint in een kwalitatief model is dan ook aan te bevelen.