PProject Start Architectuur (PSA)

Archimate Risico Extensie (Are)

versie 0.2

Bert Dingemans

2

Administratieve pagina

Wijzigingshistorie

Versie Datum Auteur Reden wijziging

0.1 Juni 2011 Bert Dingemans Geen voorafgaand document

0.2 Juni 2011 Bert Dingemans Uitwerking technische architectuur

Review historie

Naam Afdeling Functie Datum

Inhoud afgestemd met

Naam Afdeling Functie Datum

Distributie

Naam Afdeling Functie

3

1 Managementsamenvatting

1.1 Verkorte inleiding

Overzicht van de oplossing

Oplossing bestaat uit een aantal modulen rond een architectuur repository (relationele

database). Onder andere het volgende:

Repository

Modelleeromgeving voor architecten

Beheer en registratieomgeving

Enquete verwerkings module (email en webinterface)

Koppelvlak voor ontsluiting door middel van webservices

Naast de technische oplossing wordt in deze PSA een beschrijving gegeven van de

bijbehorende werkprocessen op basis van Togaf ADM.

2 Inleiding

2.1 Aanleiding PSA

Het opstellen van een enterprise architect is een creatief proces dat wordt uitgevoerd door

architecten en een aantal stakeholders binnen de beheerorganisatie. Hierbij wordt veelal

een baseline en een target architectuur opgesteld. Voor deze architecturen wil men graag

een beeld geven van de concerns en requirements van de stakeholders. De architectuur

geeft vervolgens een beschrijving van de implementatie waarmee concerns en requirements

optimaal worden afgedekt.

De concerns van stakeholders in de beheerorganisatie zijn veelal gebaseerd op het in kaart

brengen van risico’s en de maatregelen om deze risico’s in te perken tot een aanvaardbaar

niveau. Hierbij kan men denken aan de werkvelden:

Volwassenheid van de organisaties rond de oplossing

Informatiebeveiliging

Non functionals zoals ontwikkel- en beheerbaarheid

Kosten en eventueel opbrengsten van de oplossing Inrichting werkprocessen rond beheer en ontwikkeling (ITIL/ASL en BISL)

Om deze risico’s in kaart te brengen zijn er twee acties nodig. Stel enerzijds een model op

van de gewenste oplossing en eventuele transities van de huidige situatie naar de gewenste

oplossing. Inventariseer anderzijds door middel van enquetes, vragenlijsten en checklists de

risico’s behorend bij de oplossing. Dit wordt gedaan door materiedeskundige stakeholders

kennis te laten leveren omtrent de voorgestelde architecturele oplossing.

Naast deze twee kernactiviteiten zijn een aantal ondersteunende modulen te onderkennen

voor het beheer van het registratieve gedeelte . Daarnaast is een koppelvlak nodig

waarmee op geautomatiseerde wijze gegevens uitgewisseld kunnen worden op basis van

webservices.

4

Aanleiding van deze PSA is dat in de dagelijkse praktijk van een enterprise architect men

regelmatig geconfronteerd wordt met het feit dat er geen sluitend antwoord gegeven kan

worden op vragen omtrent (beheer)risico’s en kosten van een bepaalde architecturele

oplossing.

Onderzoek naar bestaande architectuur methoden zoals Togaf, Dya en Archimate laat zien

dat op het vlak risicobeheersing er enerzijds geen modellering is binnen de talen, anderzijds

dat er geen procesmatige aanpak is om concerns op het vlak van beheerrisico’s in kaart te

brengen. In deze PSA wordt een beeld gegeven van een architectuur waarbij risico’s bij het

opstellen van een architectuur in kaart worden gebracht en kwantitatief worden

geëvalueerd. Dit wordt gedaan op basis van Togaf 9 en Archimate 1.1.

Het doen van een risico inventarisatie binnen een enterprise architectuur zal al snel een grote

administratieve inspanning vergen. Reden om deze activiteiten te ondersteunen met een

geautomatiseerd informatiesysteem.

2.2 Doelstelling en gebruik PSA

Doelstelling van het PSA is om op hoofdlijnen een beeld te geven van de bedrijfsarchitectuur

voor beheerrisico inventarisaties op basis van Togaf en Archimate. Het wordt gebruikt als

leidraad binnen een iteratief ontwikkelproces van zowel de bedrijfsarchitectuur als de

technische implementatie. Het dient daarnaast als communicatiemiddel naar betrokken

stakeholders.

2.3 Opbouw PSA

Het MARIJ-sjabloon voor een PSA (versie 0.1) wordt gebruikt voor de PSA voor ARE, vanwege

het integrale karakter van de voorgestelde oplossing. MARIJ is als referentiearchitectuur

eigenlijk alleen bedoeld voor de kerndepartementen, terwijl het Are project niet alleen op

overheden gericht is Het MARIJ-sjabloon en de MARIJ principes zijn echter algemeen

toepasbaar.

Hoofdstuk 1 en 2 van dit document betreffen algemene informatie over de PSA en het

programma/project waar de PSA over gaat (zoals aanleiding, opzet, doel, scope en kaders).

Deze 2 hoofdstukken hebben voor de deelprojecten vrij veel overlap, en zijn gezamenlijk

beschreven in de programma PSA.

Hoofdstuk 3 en verder beschrijft het specifieke probleemgebied en globale

oplossingsrichtingen op verschillende aspecten (bedrijfs-, informatie- en infrastructuurniveau).

Deze hoofdstukken zijn specifiek gericht op de Are implementatie.

Werkwijze totstandkoming PSA

De totstandkoming van deze PSA kenmerkt zich door gezamenlijkheid. Deze producten zijn

gezamenlijk ontwikkeld met een aantal architecten vanuit een ICT maatschap. Dit is

gebaseerd op de uitkomsten van een aantal interactieve sessies waaraan architecten en

experts een bijdrage hebben geleverd.

Documenten

Ref. Document

1 Reference Guide Archimate 1.0

2 Togaf 9.0

3

5

4

6

3 Projectinformatie

3.1 Doel van het project

Het doel van het project bestaat uit een onderzoek naar een model, inclusief

geautomatiseerd informatiesysteem om het beheer van een ICT (architectuur) oplossing op

basis van risico’s te kunnen inventariseren.

Op basis van het model en de geautomatiseerde hulpmiddelen ontstaat de mogelijkheid om

verschillende basis- en doelarchitecturen op basis van beheerrisico’s met elkaar te

vergelijken op basis van kwantitatieve criteria.

Problemen opgelost met dit project zijn:

Reductie van risico’s op het vlak van beheer en implementatie door analyse van een

aantal risicogebieden.

Vergroten van de betrokkenheid van een aantal ICT beheer stakeholders bij een

architecturele oplossing

Betere inzage van kosten-, beheer- en implementatieaspecten van architecturele ICT

oplossingen

Het project sluit aan bij het idee van DLA Ontwerp & Software om door interactie met

stakeholders te komen tot een beter architectuurproduct.

3.2 Project context

Context van het project is de implementatie van architectuur tooling gebaseerd op een

architectuur repository. Hierbij wordt de context bepaald door:

Ontwikkelingen binnen de architectuur methoden TOGAF, ArchiMate

Ontwikkelingen op het vlak van ITIL, ASL en BISL

Visievorming rond architectuur, beheer en risico inventarisaties.

3.3 Scope, afbakening

Het project omvat:

de ontwikkeling van een architectuurmodel

een extensie op archimate voor risico inventarisatie,

uitwerking van interactiemodellen rond het opstellen van basis en doelarchitecturen

Ontwikkelen van tooling ter ondersteuning van architectuur werkzaamheden

Checklist en vragenlijsten voor beheerrisico’s

Eindproducten van het project zijn:

Beschrijving van het architectuurmodel

Prototype voor softwaremodulen

Voorbeeld checklists voor:

o Informatiebeveiliging

o ITIL/ASL/BISL werkprocessen

o Software maturity

o Non functional requirements (Quint2)

o Kostenmodel voor ontwikkeling, migratie en beheer.

Website met achtergrondinformatie

7

Publicaties en presentatie voor architectuur community

3.5 Kaders en standaarden

Binnen de PSA gelden de volgende standaards en richtlijnen:

Togaf 9

ArchiMate

ITIL V3

ASL

BISL

Quint2

Navisoft maturity model

ISO 1471

Daarnaast wordt waar nodig gebruik gemaakt van inzichten vanuit DyA,NORA, MARIJ, AIA

en de SOA pattern guide.

3.6 Bedrijfsdrijfveren

Voor DLA Ontwerp & Software zijn de volgende bedrijfsdrijfveren relevant:

Visievorming. Ontwikkelen van een visie omtrent beheer, architectuur en risico’s

en van de combinaties van deze aspecten. Door deze visievorming wordt een

niche in de architectuurmarkt gezocht waarin weinig andere partijen actief zijn.

Hierdoor wordt enerzijds de kans op architectuuropdrachten groter, anderzijds

heeft deze visievorming een positief effect op de tarieven binnen opdrachten.

Productontwikkeling. Door het ontwikkelen van enerzijds een model en een

uitwerking in een product kan het dienstverleningsaanbod uitgebreid worden in

de richting van Application Service Provider of het aanbieden van trainingen op

dit onderwerp.

Concurrentievoordeel. Door kennis- en productontwikkeling ontstaat een

dienstaanbod dat niet door andere architectuur dienstverleners aangeboden kan

worden

3.7 Architectuurdrijfveren

Belangrijkste architectuurdrijfveren zijn:

Modelontwikkeling, ontwikkeling van een architectuurmodel dat een relatie legt

tussen bestaande architectuurmethoden en ICT beheer en risicoanalyse.

Extensie Togaf en Archimate, modelextensies voor Togaf en Archimate, waarmee

invulling wordt gegeven aan concerns, views en viewpoints van een aantal

betrokken partijen, met name de beheerorganisatie.

Software architectuur modelleeromgeving, werkwijzen voor software ontwikkeling

veranderen sterk door nieuwe frameworks, methoden en tools. Kennis hieromtrent

dienen vergaard te worden op basis een actueel portfolio.

3.8 Afbakening en relaties met andere projecten

Het project ARE sluit aan bij de volgende projecten:

DLArchitect, ontwikkelen van een drie lagen architectuur voor source code

generatie

8

PSAssistent, Beheertool voor architecturen en architectuurdocumenten op basis

van Archimate en DyA.

InterActory, interactieve architectuurmodelleer en inventarisatie werkwijze.

9

4 Overzicht van de oplossing

In onderstaande afbeelding een overzichtsschema van de oplossing.

Afbeelding 1: Overzicht oplossing

In de afbeelding ziet men dat de architectuur repository een centrale plaats inneemt. Dit is

een relationele database die op basis van een viertal modulen ontsloten.

5 Bedrijfsarchitectuur

5.1 Beleidslijnen, principes en standaarden

De volgende strategische uitgangspunten gelden voor het Are project:

Werkprocesinrichting en uitwerking aansluiten bij internationale standaarden op

het vlak van enterprise architectuur modellering zoals Togaf en Archimate

Uitwerken van een architectuurmodel op het vlak van informatie- en technische

architectuur.

Interactieve ondersteuning van enterprise architecten bij het opstellen van

architectuurmodellen zodat werkzaamheden efficiënt en effectief uitgevoerd

kunnen worden.

Kwantitatieve analyse van concerns van een specifieke groep stakeholders (ICT

beheer)

10

5.2 Globale architectuur

5.2.1 Producten en diensten:Globale product- en dienst architectuur

Product bestaat uit de ondersteuning van architectuurmodellering op basis van Archimate.

Hierbij wordt de focus gelegd op de structurele elementen van de Archimate modelleertaal

binnen het vlak informatie en technische architectuur. In onderstaande afbeelding ziet u een

overzicht van de archimate entiteiten. De kleuren hebben de volgende indeling: rood:

essentieel, oranje: belangrijk, geel: aandacht; wit: niet relevant.

11

Afbeelding 2: Archimate elementen in Are

5.2.2 Processen: Globale procesarchitectuur

12

Het proces dat ondersteunt wordt binnen het Are project omvat enerzijds de analyse van de

concerns van stakeholders binnen ICT beheer. Stakeholders betrokken bij ICT beheer hebben

concerns op het vlak van ICT kosten en opbrengsten, risico’s op het vlak van non functionele

requirements zoals performance en beschikbaarheid en dergelijke. Anderzijds wordt

aandacht besteedt aan de modelleerwerkzaamheden van enterprise architecten. Dit wordt

samengevoegd tot een uitbreiding van de Archimate taal waarbij in de diagrammen een

extra dimensie wordt toegevoegd. Deze dimensie omvat een weergave van de

risicodimensie voor de structurele elementen. Indien mogelijk wordt op basis van

infrastructuur- en applicatieservices een extra ontsluiting toegevoegd aan de archimate taal.

Processen zijn uitgewerkt op basis van Togaf ADM. In onderstaande afbeeldingen wordt

getoond binnen welke fasen van het ADM de risico inventarisatie wordt toegepast.

Daarnaast worden ook de activiteiten benoemd relevant voor deze extensie in

onderstaande afbeeldingen

Afbeelding 3 Togaf ADM

13

Afbeelding 4 Togaf modelling steps

14

Afbeelding 5 Togaf change steps

15

5.2.3 Organisatie/actoren: Globale functie- en organisatiearchitectuur

Het Are project heeft betrekking op de volgende stakeholder rollen binnen een ICT

organisatie (er wordt een gangbare benaming voor functies gebruikt):

DBA

Functioneel applicatiebeheerder

ICT architect

Infrastructuur specialist

Systeembeheerder

Teamleider ICT

Technisch applicatiebeheerder

Daarnaast is vanzelfsprekend de rol van enterprise architect de belangrijkste actor in dit

project.

16

6 Informatie architectuur

De Informatie Architectuur van de oplossing structureert en beschrijft de informatiesystemen

van het bedrijf(sonderdeel). De functionaliteiten die beïnvloed worden door het project

worden geïdentificeerd en aangegeven. Hetzelfde gaat op voor de applicaties en

interfaces die betrokken zijn in het project.

6.1 Beleidslijnen, principes en standaarden

De strategische uitgangspunten voor de informatie architectuur zijn:

De architectuur repository neemt een centrale plaats in binnen architectuur

tooling en bestaat uit een relationele database inclusief essentiële database

constraints zoals primaire sleutels en referentiele integriteit.

Afzonderlijke applicatie functies worden opgenomen in applicatie componenten

Er dient een component beschikbaar te zijn voor integratie met andere

toepassingen buiten het projectdomein.

Applicatie oplossingen zijn bij voorkeur webbased.

6.2 Globale architectuur

6.2.1 Applicatie diensten: Globale applicatiearchitectuur: medewerkers en

applicaties

De Applicatie Architectuur wordt getoond in onderstaande afbeelding. Te zien is dat er een

architectuur repository is die een centrale plaats inneemt binnen de oplossing. Deze

repository zorgt voor opslag van de architectuurmodellen en dient als communicatiemiddel

tussen de vier applicaties.

17

Afbeelding 6 Applicatiestructuur

Projectoplossing bestaat uit de volgende onderdelen:

Architectuur repository, relationele database voor opslag van alle project

entiteiten

Registratiemodule, onderdeel voor het registeren van de elementen op basis van

Archimate, inclusief registratie van stakeholders en concerns.

Modelleeromgeving bestaat uit een component waarmee diagrammen op basis

van de archimate notatie

Enquete module, component voor het beheren , verzenden en verwerken van

checklists en enquetes omtrent architectuur elementen.

Uitwisselportaal, webservice ontsluiting van de gegevens opgeslagen in de

architectuur repository.

6.2.2 Applicatie functies /-structuur: Globale applicatiestructuur (blauwdruk)

De applicatie bestaat uit een vijftal componenten. De repository is een relationele database.

Binnen de repository worden de metagegevens van de verschillende onderdelen

beschreven.

Naast de opslag van gegevens in de relationele database wordt het filesysteem gebruikt

voor de opslag van documenten zoals ontwerpen, afbeeldingen, modellen en diagrammen.

Binnen de repository wordt een verwijzing en een beschrijving opgenomen naar deze

documenten op het filesysteem.

18

Voor het ontsluiten van de gegevens opgeslagen in de repository worden een viertal

componenten ingezet. Deze componenten voorzien allen in een eigen viewpoint op het

architectuur model binnen de repository. Hierbij is het noodzakelijk dat de verschillende

viewpoints met elkaar gecombineerd kunnen worden. Binnen de modelleeromgeving is het

mogelijk dat de beschrijving van de componenten gecombineerd kan worden met de

checklists en de enquêtegegevens. In onderstaande afbeeldingen een voorbeeld hoe deze

gecombineerde viewpoints uitgewerkt zullen worden:

Afbeelding 7 Viewpoints voor beheerconcerns, modelleerperspectief

19

Afbeelding 8 Viewpoints voor beheerconcerns, matrixperspectief

In de afbeeldingen worden een aantal applicatiecomponenten getoond waarbij op basis

van kleuren de resultaten van de checklists wordt getoond. Hiermee is eenvoudig te zien

waar de risico’s binnen een bepaalde opstelling liggen.

6.2.3 Objecten, gegevens en berichten: globale gegevensarchitectuur

Onderstaande afbeeldingen tonen de bedrijfsobjecten op basis van een Merode ER

diagram. In de afbeeldingen zijn de entiteiten te zien en hoe deze zich tot elkaar verhouden.

20

Afbeelding 9 ER model architectuurmodel

Het architectuurmodel omvat de volgende clusters:

Archimate entiteiten voor de beschrijving van de architectuur in modellen

Stakeholders en concerns

Architectuur documenten en diagrammen

Navigatie en sorteer entiteiten voor registratie en modelleeromgeving

21

Afbeelding 10 ER model checklistmodel

Checklistsmodule bestaat uit de entiteiten voor het verwerken van enquetes, rekenmodellen

en checklist. Opzet hierbij is dat per architectuur element en stakeholder checklists opgesteld

kunnen worden, via element, concern en stakeholder wordt vervolgens de relatie gelegd

met het modelleer model. Deze module wordt apart onderscheiden omdat het ook mogelijk

moet zijn om te kunnen registreren en modelleren zonder checklistsmodule.

Het uitwisselportaal voorziet in het uitwisselen van gegevens met andere informatiesystemen.

Vooral bij grote organisaties zal vaak al een CMDB of ITIL omgeving aanwezig zijn waarin op

geautomatiseerde wijze gegevens ontsloten worden van delen van de hierboven

beschreven entiteiten. Het is hiermee een aanvullende component ter ondersteuning van

automatisch synchroon houden van meerdere informatiebronnen

Het uitwisselportaal biedt een voorziening op basis van webservices waarbij de gegevens

omtrent de architectuur elementen (configuratie_items) uitgewisseld kunnen worden. Hiertoe

zal een berichtdefinitie opgesteld worden dat elementen en de onderlinge relaties van deze

elementen met beschrijft. Voor de andere onderdelen zoals stakeholders, documenten en

concerns wordt binnen dit project nog geen uitwisselportaal ingericht. Eventueel kan voor

eenmalige inlees- en conversieroutines gewerkt worden met database links en stored

procedures binnen de database.

22

7 Technische architectuur

7.1 Beleidslijnen, principes en standaarden

Strategische uitgangspunten op het vlak van technische architectuur zijn:

Er wordt gebruik gemaakt van een relationele database die ingezet wordt binnen

een grote community

Waar mogelijk wordt gebruik gemaakt van bestaande COTS en Open Source

libraries, componenten en toepassingen

Bij gelijke geschiktheid wordt gekozen voor een open source component

Componenten zijn loosely coupled en kunnen onafhankelijk van elkaar werken en

zijn als modulen te configureren

7.2 Globale technische architectuur

Oplossing bestaat uit een relationele database en webbased componenten. Hierbij is

voorzien in de volgende configuratie:

Component Inrichting

Architectuur repository Microsoft SQL Server 2008 Express Editie

Registratiecomponent Lightswitch Beta 2

Modelleermodule Silverlight 4 inclusief OSS diagram library

Enquetemodule Asp.Net 3.5 webapplicatie

Uitwisselportaal ASMX of WCF

Webserver IIS

Besturingssysteem Windows 7

23