Project 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
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.
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
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