Project Start Architectuur (PSA)

Transcriptie

1 Project Start Architectuur (PSA) InterActory Architectuur Service Orientatie versie 0.2 Bert Dingemans

2 Administratieve pagina Wijzigingshistorie Versie Datum Auteur Reden wijziging 0.1 Maart 2012 Bert Dingemans Geen voorafgaand document Review historie Naam Afdeling Functie Datum Inhoud afgestemd met Naam Afdeling Functie Datum Distributie Naam Afdeling Functie 2

3 1 Managementsamenvatting 1.1 Verkorte inleiding Overzicht van de oplossing Oplossing bestaat uit een aantal modulen rond een service repository (relationele database). Onder andere het volgende: 3 Register voor services, applicaties, processen en data objects Canoniek Data Modelleeromgeving voor architecten Beheer en registratieomgeving voor architectuurdocumenten rond bovengenoemde entiteiten Zoek en ontsluitingsmodule 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 service georienteerde enterprise architect is een creatief proces dat wordt uitgevoerd door architecten en een aantal stakeholders. Hierbij wordt veelal een baseline en een target architectuur opgesteld. Voor deze architecturen wil men graag een gezamenlijk beeld opstellen van de data objecten die gebruikt worden. Daarnaast wil men dat er een gemeenschappelijke basis ontstaat over deze data objecten. Om dit te realiseren is het noodzakelijk dat de data objecten binnen services voldoen aan de volgende eisen: Vindbaar Herbruikbaar Gedocumenteeerd Generiek Om dit te realiseren is een oplossing gewenst waarbij op basis van de Archimate modelleertaal gezocht wordt naar een uitbreiding van deze taal met de mogelijkheid om de inhoud vasn services en data objecten te beschrijven. 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 notatie is rond service modellering. Daarnaast wordt gezocht naar register functionaliteit voor de betrokken entiteiten en hun bijbehorende documenten. 2.2 Doelstelling en gebruik PSA Doelstelling van het PSA is om op hoofdlijnen een beeld te geven van de bedrijfsarchitectuur voor service orientatie en data architecturen. Het wordt gebruikt als leidraad binnen een iteratief ontwikkelproces van zowel de dataarchitectuur 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. 2.4 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 Togaf Service oriented architecture principles and design 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 voor service georienteerde architectuur en de bijbehorende (data) objecten. Op basis van het model en de geautomatiseerde hulpmiddelen ontstaat de mogelijkheid om verschillende basis- en doelarchitecturen te ontwikkelen waarbij de services en bijbehorende data objecten op adequate wijze worden beschreven en geregistreerd. Daarnaast wordt gezocht voor hulpmiddelen voor hergebruik. Problemen opgelost met dit project zijn: 5 Uitbreiding notatiewijze archimate voor services en data objecten Architectuurproces beschrijving en implementatie van service en object register Werkwijze voor opslag en ontsluiten van Architectuur documenten rond SOA. 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 service architectuur repository. Hierbij wordt de context bepaald door: Ontwikkelingen binnen de architectuur methoden TOGAF, ArchiMate Ontwikkelingen op het vlak van SOA en Canonieke Data Modellen (CDM). Visievorming rond architectuur, SOA governance en architectuur documentatie. 3.3 Scope, afbakening Het project omvat: de ontwikkeling van een architectuurmodel een extensie op archimate voor services en data objecten uitwerking van interactiemodellen rond het opstellen van basis- en doelarchitecturen Ontwikkelen van tooling ter ondersteuning van architectuur werkzaamheden Eindproducten van het project zijn: o Beschrijving van het architectuurmodel o Prototype voor softwaremodulen o Extensie met notatiewijze voor SOA encdm Website met achtergrondinformatie Publicaties en presentaties voor architectuur community 3.5 Kaders en standaarden

6 Binnen de PSA gelden de volgende standaards en richtlijnen: Togaf 9 ArchiMate ISO 1471 SOA manifesto SOA (Thomas Erl) Daarnaast wordt waar nodig gebruik gemaakt van inzichten vanuit DyA,NORA, MARIJ, AIA en de SOA en EAI pattern guide. 3.6 Bedrijfsdrijfveren Voor DLA Ontwerp & Software zijn de volgende bedrijfsdrijfveren relevant: Visievorming. Ontwikkelen van een visie omtrent service, architectuur en data objectet 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, CDM en SOA. Extensie Togaf en Archimate, modelextensies voor Togaf en Archimate, waarmee invulling wordt gegeven aan concerns, views en viewpoints van een aantal betrokken partijen. 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 ASO sluit aan bij de volgende projecten: 6 DLArchitect, ontwikkelen van een drie lagen architectuur voor source code generatie PSAssistent, Beheertool voor architecturen en architectuurdocumenten op basis van Archimate en DyA.

7 Archimate Risico Extensie (ARE), repository voor architectuur risico inventarisaties InterActory, interactieve architectuurmodelleer en inventarisatie werkwijze. 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. Deze modulen sluiten aan bij het procesmodel zoals beschreven in het volgende hoofdstuk. 5 Bedrijfsarchitectuur 5.1 Beleidslijnen, principes en standaarden De volgende strategische uitgangspunten gelden voor het ASO project: 7

8 Werkprocesinrichting en uitwerking aansluiten bij internationale standaarden op het vlak van enterprise architectuur modellering zoalssoa, Togaf en Archimate Uitwerken van een architectuurmodel op het vlak van proces-, data- en service architectuur. Interactieve ondersteuning van SOA architecten bij het opstellen van service en integratiemodellen zodat werkzaamheden efficiënt en effectief uitgevoerd kunnen worden. Werkwijze voor inzet van canonieke datamodellen voor SOA projecten.) 5.2 Globale architectuur 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. Dit in combinatie met een uitbreiding voor services, entiteiten en eigenschappen binnen het concept van data objecten in Archimate Processen: Globale procesarchitectuur Het proces dat ondersteunt wordt binnen het ASO omvat een generiek procesmodel voor ontwerp- en architectuur activiteiten zoals opgesteld binnen de InterActory methode. In onderstaande afbeelding ziet u de basis van het iteratieve proces 8

9 Afbeelding 2: Generiek ontwerpproces Dit proces kenmerkt zich door een intensieve interactie met de diverse stakeholders en bestaat in de basis uit vier fasen: 9 Interacteren, communicatie met de stakeholders voor inventariseren van de behoefen Modelleren, opstellen van modellen van de gewenste oplossing Registeren, beschrijven van de gemaakte keuze en registratie van de verschillende componenten binnen de oplossing Evalueren, toetsen van de gemaakte keuze bij de stakeholders en vervolgens opnieuw de eerdere fasen doorlopen voor een verdere verfijning Dit ontwerpproces sluit aan bij iteratieve werkwijzen zoals scrum en dergelijke. Binnen sommige organisaties wordt een waterval werkwijze toegepast. Hierbij wordt het werkproces anders van opzet: De fasen analyse en ontwerp zijn nog steeds sterk iteratief van aard en doorlopen in een aantal cycli bovenstaande ontwerpstappen. Vervolgens wordt een architectuurdocument opgesteld dat wordt gepubliceerd. Na publicatie moet bewaakt worden dat projecten

10 gerelateerd blijven aan de opgestelde architectuur of dat de architectuur documenten belangrijke mutaties beschrijven. Onderstaande afbeelding toont de opzet. Afbeelding 3: Waterval ontwerpproces Organisatie/actoren: Globale functie- en organisatiearchitectuur Het ASO project heeft betrekking op de volgende stakeholder rollen binnen een ICT organisatie (er wordt een gangbare benaming voor functies gebruikt): DBA Data architect ICT architect Project manager Teamleider ICT Technisch of functioneel applicatiebeheerder Daarnaast is vanzelfsprekend de rol van SOA architect de belangrijkste actor in dit project. 10

11 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 of gebaseerd op cloud computing. 6.2 Globale architectuur 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. 11

12 Afbeelding 6 Applicatiestructuur in relatie tot werkproces 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 Zoekmodule, component voor het zoeken naar services, data objecten en de bijbehorende onderdelen. Uitwisselportaal, rapportage en webservice ontsluiting van de gegevens opgeslagen in de architectuur repository 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. 12

13 Naast de opslag van gegevens in de relationele database wordt het filesysteem gebruikt voor de opslag van architectuurdocumenten zoals ontwerpen, afbeeldingen, modellen en diagrammen. Binnen de repository wordt een verwijzing en een beschrijving opgenomen naar deze documenten op het filesysteem. Naast de ontsluiting van fysieke documenten wordt gezocht naar een oplossing waarbij documenten interactief samengesteld worden voor stakeholders. Deze opzet brengt met zich mee dat het beheer van documenten beter aansluit bij het basis werkproces zonder publicatie. Deze module wordt uitgewerkt in de registratiemodule en het uitwisselportaal. 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. Waar mogelijk zijn deze vier componenten via een servicelaag ontsloten 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. Afbeelding 9 Entiteitenmodel architectuurmodel 13

14 Het architectuurmodel omvat de volgende clusters: Procesentiteiten voor de beschrijving van de proces entiteiten Service entiteiten en de bijbehorende onderdelen Data entiteiten, gemeenschappelijke beschrijving van entiteiten. Architectuur documenten en diagrammen Applicatie entiteiten, voor het in kaart brengen van het gebruik van de verschillende entiteiten 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 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 of cloud componenten. Het eerste prototype wordt ontwikkeld op basis van een Visual Objects toepassing en een MS- Access relationele database. Daarnaast is voorzien in de volgende configuratie scenario s: 14

15 Afbeelding 7: Lightswitch configuratie Afbeelding 8: ASP.Net/Dynamic data configuratie 15

16 Afbeelding 9: Access 2010 en Office