PProject Start Architectuur (PSA) Archimate Risico Extensie (Are)
versie 0.2
Bert Dingemans
Administratieve pagina
Wijzigingshistorie Versie Datum 0.1 Juni 2011 0.2 Juni 2011
Auteur Bert Dingemans Bert Dingemans
Reden wijziging Geen voorafgaand document Uitwerking technische architectuur
Review historie Naam
Afdeling
Functie
Datum
Afdeling
Functie
Datum
Afdeling
Functie
Inhoud afgestemd met Naam
Distributie Naam
2
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.
3
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. 1 2 3
Document Reference Guide Archimate 1.0 Togaf 9.0
4
4
5
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 o o o o
Informatiebeveiliging ITIL/ASL/BISL werkprocessen Software maturity Non functional requirements (Quint2) Kostenmodel voor ontwikkeling, migratie en beheer.
Website met achtergrondinformatie
6
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
7
PSAssistent, Beheertool voor architecturen en architectuurdocumenten op basis van Archimate en DyA. InterActory, interactieve architectuurmodelleer en inventarisatie werkwijze.
8
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)
9
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.
10
Afbeelding 2: Archimate elementen in Are
5.2.2 Processen: Globale procesarchitectuur
11
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
12
Afbeelding 4 Togaf modelling steps
13
Afbeelding 5 Togaf change steps
14
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.
15
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.
16
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.
17
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
18
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.
19
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
20
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.
21
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 Architectuur repository Registratiecomponent Modelleermodule Enquetemodule Uitwisselportaal Webserver Besturingssysteem
Inrichting Microsoft SQL Server 2008 Express Editie Lightswitch Beta 2 Silverlight 4 inclusief OSS diagram library Asp.Net 3.5 webapplicatie ASMX of WCF IIS Windows 7
22
23
