Diagrams

Primaire concepten In de applicatielaag zijn de drie specialisaties van de bouwblokken relatief eenvoudig te relateren aan een ArchiMate element, namelijk:

• Service <-> Application_Service
• ABB <-> Application_Function, zoals reeds genoemd kan hier ook een ander behavioural element gebruikt worden
• SBB <-> Application_Component

Tussen de elementen kunnen ArchiMate relaties gedefinieerd worden:

• Service <-> ABB: Realisation
• SBB <-> ABB: Assignment
• xBB <-> xBB: Aggregation

Met name de laatste associatie de aggregatie is van belang omdat hiermee samengestelde bouwblokken samengesteld kunnen worden. Naast de genoemde associaties zijn meerdere typen associaties te kiezen zoals de dynamische associaties. Bij het uitwerken van de views binnen dit viewpoint staat het je vrij deze extra associaties toe te passen, mits uitgewerkt in de reeds aanwezige algemene {Organisatie} viewpoints. Secundaire concepten Naast de primaire elementen en associaties zijn er een tweetal elementen en associaties relevant, echter niet in alle architectuurdomeinen. Dit zijn:

• Data_Object, binnen bijvoorbeeld de integratie architectuur zijn data objecten noodzakelijk voor het beschrijven van bijvoorbeeld herbruikbare berichtdefinities binnen een bouwblok
• Application_Interface, eveneens binnen de integratie architectuur is voor de implementatie van bijvoorbeeld een webservice dit concept noodzakelijk als extra ArchiMate element binnen de xBB modellering.

Primaire concepten In de technische laag zijn de drie specialisaties van de bouwblokken relatief eenvoudig te relateren aan een ArchiMate element, namelijk:

• Service <-> Technology_Service
• ABB <-> Technology_Function, zoals reeds genoemd kan hier ook een ander behavioural element gebruikt worden
• SBB <-> System_Software, Node, Network, Device, Path en andere technische actieve structuur elementen.

Tussen de elementen kunnen ArchiMate relaties gedefinieerd worden:

• Service <-> ABB: Realisation
• SBB <-> ABB: Assignment
• xBB <-> xBB: Aggregation

Met name de laatste associatie de aggregatie is van belang omdat hiermee samengestelde bouwblokken samengesteld kunnen worden. Naast de genoemde associaties zijn meerdere typen associaties te kiezen zoals de dynamische associaties. Bij het uitwerken van de views binnen dit viewpoint staat het je vrij deze extra associaties toe te passen, mits uitgewerkt in de reeds aanwezige algemene {Organisatie} viewpoints. Secundaire concepten Naast de primaire elementen en associaties is er element en associatie relevant, echter niet in alle architectuurdomeinen. Dit zijn:

• Technology_Interface, eveneens binnen de integratie architectuur is voor de implementatie van bijvoorbeeld een webservice dit concept noodzakelijk als extra ArchiMate element binnen de xBB modellering.
• Een introductie van een artifact is in deze alleen in bepaalde deelgebieden relevant (geo). In andere gevallen zal worden uitgeweken naar een taal met meer detail zoals UML klassediagram of XSD modellen. In dat laatste geval wordt er via een trace associatie gelegd tussen de modelleertaal concepten.

Dit is een discussie plaat voor de situatie waarbij een service op de applicatielaag is uitgewerkt in een aantal ABB en SBB op de applicatielaag. Vervolgens wordt het applicatie ABB ingevuld door de functionaliteit en implementatie en ABB en SBB binnen een infrastructurele service. In deze afbeelding is op basis van de ArchiMate notatiewijze een voorbeeld uitgewerkt waarbij de infrastructurele bouwblokken via een service de applicatie ABB ondersteund. Hiermee wordt het model relatief omvangrijk maar wel gebaseerd op de ArchiMate viewpoint

Dit model is relatief eenvoudig van opzet, er is een applicatie service die wordt ingevuld door één logische applicatie functie. Echter dit kan in andere situaties een meer complexe samenstelling zijn. Wordt er voor de architectuur bouwblokken een register of portfolio opgesteld dan is dit een extra vorm van aggregatie. Alternatief is om via het service portfolio te aggregeren en groeperen. Is een discussiepunt.

Een ABB kan zijn opgebouwd uit een of meerdere SBB. Daarnaast is het mogelijk dat een ABB ingevuld kan worden door een van meerdere SBB, er ontstaat dus een keuzemogelijkheid. Dat wordt in dit voorbeeld getoond. Hierbij wordt het van belang dat inzichtelijk gemaakt wordt wat de verschillen zijn tussen de verschillende SBB. Zie hiervoor het uitgebreide voorbeeld diagram.

In dit samengestelde SBB model komen een aantal zaken samen:

• Het email ABB wordt enerzijds ingevuld door een Email component in de applicatielaag
• Ten tweede worden de email ABB ingevuld door een technische functie en - service binnen de infrastructurele ABB en SBB
• Het voorbeeld toont hoe een service de verbinding legt tussen de lagen.
• In het model is een secundair element opgenomen als voorbeeld een interface obv een mail protocol.

Dit eerste voorbeeld een uitwerking van de services. Kenmerkend hierin is dat de service een communicatiemiddel is tussen aanbieder en afnemer. Het is daarbij van belang dat er een begrijpelijk portfolio van services gemaakt wordt. De portfolio aanpak is nog een onderwerp van discussie, wel opgenomen in het voorbeeld diagram. Discussiepunt is daarbij wat is de indeling van de portfolio en de services.

In het samengestelde servicemodel is te zien hoe een service op een hoger abstractieniveau is opgebouwd uit kleinere services met een meer specifiek karakter. In dit model kantoorautomatisering wordt een tussenlaag van services opgenomen, dat hoeft niet perse, je zou ook direct de koppeling kunnen leggen naar Microsoft Office dat is afhankelijk van de context. In deze uitwerking worden alleen applicatie services gemodelleerd en in de samenstelling opgenomen. Echter naast applicatie services kun je hier ook bedrijfsservices definieren. Denk hierbij aan de combinatie van de implementatie van Office en een servicedesk voor vragen bij problemen. Dat ligt nu buiten scope maar wordt op zeker moment relevant. Relevant hierin is dat er dan een knelpunt in de ArchiMate modellering ontstaat. ICT business services inbedden in de lagere architectuurlagen.

Dit voorbeeld laat op eenvoudige wijze zien hoe de kenmerken/eisen op basis van requirements, constraints, kwaliteiten en principes inzichtelijk gemaakt kunnen worden. In dit voorbeeld is te zien hoe de kenmerken van de verschillende xBB op basis van ArchiMate concepten in kaart gebracht kunnen worden. Dit wordt straks een belangrijk mechanisme in de verschillende xBB catalogi. Naast deze aanpak kunnen de kenmerken ook uitgewerkt worden via de interne kenmerken van de entiteiten in EA. Zoals requirements, constraint en scenario. Als laatste is er de mogelijkheid om tagged values te gebruiken. In de werkgroep is bepaald dat hierbij het leggen van associaties tussen ArchiMate concepten de voorkeur verdiend. Is een uitwerking met ArchiMate concepten onvoldoende en wil men uitwijken naar interne eigenschappen of tagged values dan dient dit kortgesloten te worden