Vaarwel architectuur document welkom architectuur repository

Volg nu de nieuwe Masterclass Architectuur Repository met Sparx Enterprise Architect!

Inleiding

Binnen veel organisaties in Nederland speelt een architectuurteam een rol bij het sturen van verandering, het stellen van kaders en het beschrijven van de organisatie inrichting. Dit doet een architectuurteam door het opstellen van verschillende soorten architectuurproducten. Hierbij wordt vanuit één van bovenstaande perspectieven bepaalt hoe een dergelijk architectuurproduct is ingericht en vormgegeven.

Dit wordt veelal gedaan door het opstellen van architectuurdocumenten. Documenten als referentie architectuur, domein architectuur of solution architectuur hebben vaak een (Word) document als verschijningsvorm.

Een architectuur op basis van een collectie van documenten is bij een architectuur die te overzien nog realiseerbaar en beheersbaar. Wordt de architectuur echter omvangrijker en complexer dan zal gezocht moeten worden naar andere implementaties voor de architectuur producten. Hiervoor zijn meerdere scenario’s mogelijk, bijvoorbeeld een wiki maar ook de inzet van een architectuur repository.

In dit artikel gaan we in op de inzet van een architectuur repository als volgende stap in de volwassenheid van de architectuurfunctie en – producten die vervaardigd worden. Een architectuur repository heeft een aantal belangrijke voordelen ten opzichte van een werkwijze met architectuurdocumenten. Echter er kleven ook een aantal bezwaren aan een repository gebaseerde aanpak. Maak je echter een weloverwogen overstap van document naar repository dan krijgt het architectuurteam een krachtig in handen om architecturele meerwaarde te creëren voor de organisatie.
Hieronder geven we een beeld van de voor- en nadelen van zowel de document gedreven als de repository gedreven aanpak. Op basis hiervan beschrijven we een aantal tips en tricks voor een succesvolle overstap naar een architectuur repository.

Wat is een architectuur repository

Een zoekopdracht naar de definitie van een architectuur repository op internet levert een summier resultaat op. Interessant daarbij is dat met name een aantal cloud leveranciers een definitie opgesteld hebben. Hieronder de definitie van AWS die wij in dit artikel als uitgangspunt nemen.
Een enterprise-architectuurrepository is een verzameling artefacten die het huidige en beoogde IT-landschap van een organisatie beschrijft. Het doel van de enterprise-architectuurrepository is om de inventaris van technologie, gegevens, applicaties en zakelijke artefacten van de organisatie weer te geven en om de relaties tussen deze componenten te tonen. Bron:AWS.

Document gedreven architectuur

Een document gedreven architectuur kenmerkt zich in een verschijningsvorm van een aantal documenten. Documenten worden veelal opgesteld met behulp van kantoorautomatisering zoals met Powerpoint, Excel of Word. Hieronder een voorbeeld van een dergelijk architectuur document

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.

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
   o Verwijzingen
   o 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

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
   o Duplicaten van deelarchitecturen
   o 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 het 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 webbased). Voor architectuur repositories is tooling essentieel maar gelukkig in elke prijscategorie verkrijgbaar.

Voordelen
• Architectuurmodel is gecentraliseerd daardoor (dus alle modellen samengebracht in een repository):
   o Meer samenhang en standaardisatie van de modellen
   o Meer hergebruik van deelmodellen, deelmodellen die reeds aanwezig zijn in de repository kunnen worden uitgebreid cq aangepast
• Ontwikkelen architectuurdocumenten wordt sneller door:
   o Automatisering
   o Publiceren van documenten
   o Gebruik van sjablonen
   o 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.

Nadelen
• Vraagt om standaardisatie van:
   o Architectuurprocessen (modelleren en valideren)
   o Architectuurmodellen
• Alles hangt met alles samen
   o dus modelaanpassingen hebben direct impact op de andere modellen
   o Losstaande uitwerkingen vragen later rework, dus werk bij voorkeur in de centrale repository.
   o 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 hier een aantal aanvullende tips:
• 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.

Vervolgstappen
Bent u geïnteresseerd in het werken met een architectuur repository? Wilt u meer weten over de stappen en activiteiten die kunnen helpen bij een succesvolle introductie? Of wilt u zien hoe Sparx Enterprise Architect ingericht kan worden als architectuur repository. Dan is de training Masterclass Architectuur Repository met Sparx Enterprise Architect een interessante volgende stap!