Naamgevingsconventies Gebruik: Zelfstandig naamwoord. Bijvoorbeeld: GUI, REST API, Webservice.

Transformatie van data naar diverse protocollen, bijvoorbeeld voor de implementatie van webservices, REST maar ook naar een voor rapportages leesbaar formaat

Transformatie van data naar diverse protocollen, bijvoorbeeld voor de implementatie van webservices, REST maar ook naar een voor rapportages leesbaar formaat

Transformation of data to various protocols, for example for the implementation of webservices, REST but also to a format readable for reports

In een modern applicatielandschap staat een architectuur repository niet los van andere registers. Integratie met andere registers zoals bijvoorbeeld een CMDB op basis van moderne berichtgeorienteerde integratie is wenselijk.

Copy from class to interface by script

Statement Services zijn de beschrijving van een combinatie van functionaliteiten en diensten tussen aanbieder(s) en afnemer(s). Omschrijving Services zijn een vorm van inkapseling van de functionaliteit en implementatie van een samenstelling van bouwblokken. Services worden, net als ABB en SBB, gebruikt als communicatiemiddel om tussen aanbieder en afnemer aan te geven welke dienst door de aanbieder aan de afnemer geleverd gaat worden. Services kunnen ook intern binnen de organisatie gedefinieerd zijn (ook in aanbieder en afnemer verband), bijvoorbeeld infrastructurele services voor een applicatieve service of afnemer. Een service kan een samenstelling zijn van een bouwblok dat functionaliteit implementeert binnen het ICT landschap. Daarnaast kan een service bestaan uit het leveren van een meer ingerichte (ICT) werkprocessen in relatie met de bovengenoemde ICT landschappen, bijvoorbeeld een servicedesk. In dit document hebben we de scope beperkt gehouden tot die van de ICT architectuur, ICT werkprocessen worden hier niet uitgewerkt maar zijn binnen andere delen van de organisatie zeker relevant (service management). Dit bouwblokken model kan desgewenst op meerdere manieren toegepast worden en niet alleen in het ICT werkveld. Hier beperken we ons tot ICT architectuur. Services kunnen samengesteld zijn uit onderliggende services. Daarnaast kunnen zij opgebouwd zijn uit een of meerdere architectuur bouwblokken. Door deze samenstellingen kunnen constellaties ontstaan van bouwblokken die zorgdragen voor standaardisatie van herbruikbare toegepaste services. Denk hierbij aan een standaard ingerichte applicatieserver met services (zoals back-up en restore) en ABB (bijvoorbeeld relationele opslag) Services zijn gerelateerd aan requirements, constraints en principes. Dit is bij voorkeur uitgewerkt om aan te geven aan welke behoeften vanuit afnemersperspectief een invulling wordt gegeven en aan welke niet. Rond de term service bestaat veel verwarring. Om te voorkomen dat bij iedere samenstelling van personen een discussie over de definitie ontstaat wordt gekozen voor de term service welke gebaseerd is op onderstaande kenmerken. Daarnaast is er een lijst van synoniemen geformuleerd die verwijzen naar dezelfde onderstaande kenmerken. Kenmerken

• Een herhaalbare activiteit of gedrag die wordt gevraagd te worden uitgevoerd.
• Een service biedt een of meerdere voor de afnemer begrijpelijke invulling van ICT behoeften.
• Combinatie van een implementatie van een functionaliteit in een of meerdere ABBs.
• Eventueel in combinatie met een of meer ICT werkprocessen als service.
• Services worden aangeboden aan afnemers vanuit aanbieders.
• Services hebben een commercieel en een financieel (kosten) aspect.
• Services kennen voorwaarden voor gebruik cq implementatie.

Dienstverlening aan de rest van de organisatie vanuit een specifiek deel van de organisatie. Hier wordt het mogelijk om vragen te stellen en problemen te melden bij het doen van de dagelijkse werkzaamheden en de ondersteuning vanuit ICT.

SOAP/XML webservices inclusief REST

SOAP/XML webservices inclusief JSON/REST

SOAP/XML webservices including eventually REST services

SOAP/XML webservices inclusief JSON/REST

Naamgevingsconventies Gebruik: zelfstandig naamwoord. Bijvoorbeeld Backup en Restore, Printing, Scanning, Searching (ing-vorm).

XXX data en informatie is van waarde voor de bedrijfsvoering - Rationale Data en informatie wordt gebruikt om de prestaties van XXX en de dienstverlening aan de reizigers te verbeteren. Het is daarmee een asset en wordt daarom ook bestuurd, beveiligd en beheerd als andere bedrijfsmiddelen: op basis van risico-inventarisatie en kostenafweging. - Implicatie Data en informatie wordt adequaat beheerd, waarbij de maatregelen passen bij de waarde die is toegekend en het risico dat daarmee samenhangt.

Voor meta data management kan een raamwerk uitgewerkt worden. Met dit raamwerk wordt een registratie gedefinieerd voor de verschillende data management kennisgebieden. Dit raamwerk bestaat veelal uit een groeimodel en is specifiek voor iedere organisatie. Enerzijds vanwege de structuur van de organisatie en anderzijds door de volwassenheid van de organisatie op het vlak van data management. In onderstaande afbeelding zie je een drie bij drie matrix waarin een beperkt aantal kennisgebieden zijn gedefinieerd. Deze matrix zal als indeling gelden voor de rest van dit whitepaper. In de afbeelding worden drie categorieën voor kennisdomeinen genoemd namelijk beschrijvend, kaderstellend en omgeving. De onderwerpen binnen deze domeinen kunnen beschouwd worden als een startpunt voor het uitwerken van meta data management vanuit het perspectief van data management. Dit gaan we doen door voor ieder onderwerp een aantal modelleerwijzen te introduceren waarmee de stakeholders zich op eenvoudige wijze een adequaat beeld kunnen vormen van de situatie van dit meta data onderwerp. In de afbeelding zijn naast de negen kennisdomeinen een viertal pijlen opgenomen. Deze pijlen geven aan dat de kennisdomeinen met elkaar verbonden dienen te zijn. Hierbij neemt het beschrijvende model een centrale plaats in, meer specifiek het conceptueel model. De entiteiten in dit model fungeren feitelijk als centraal koppelpunt voor alle andere aspectgebieden. In de volgende hoofdstukken zullen we van ieder onderwerp een beschrijving geven van een registratie. Echter deze registratie doen we op basis van een aantal gestandaardiseerde modelleertechnieken zoals ArchiMate, UML Klasse diagrammen en ER Diagrammen. Ook hierbij is het uitgangspunt van een startpunt gebruikt. Bij een verdere uitwerking van het meta data model is het desgewenst eenvoudig mogelijk om extra modelleertechnieken toe te voegen.

Het bouwblokken model bestaat uit de generieke entiteiten bouwblok en catalogus. Deze vormen de basis van een referentie architectuur. Catalogi zijn groeperingen van bouwblokken binnen een bepaald domein. Er zullen meerdere catalogi ontstaan die aan elkaar gerelateerd zijn en elkaar overlappen binnen de visualisaties. Het voordeel van de opzet van het werken met catalogi en bouwblokken is:

• Er ontstaan registers van herbruikbare architectuur onderdelen gericht op een bepaald werkveld.
• Inzet van bouwblokken brengt standaardisatie met zich met en stimuleert hergebruik van architecturele configuraties.
• Bouwblokken maakt het architectuur- en het ontwikkelproces eenvoudiger.
• Er ontwikkelen zicht architecturele product catalogi gericht op specifieke werkvelden. Dit heeft een positieve invloed op de dienstverlening naar de rest van de organisatie.

De bouwblokken kennen drie specialisaties waarvan de definities in detail zijn uitgewerkt. Deze beschrijvingen zijn hieronder in de paragrafen uitgewerkt. Indien relevant is aan deze uitwerking extra informatie toegevoegd zoals links naar Togaf en voorbeelden van de implementatie van deze architecturele concepten In het model wordt gewerkt met een pragmatisch model voor wat betreft de associaties tussen Service en SBB. Vanuit ArchiMate perspectief is de route van service via ABB naar SBB. Dit heeft als kenmerk dat het functionele aspect goed ingebed is in het bouwblokken model. Bij het publiceren van deze modellen wordt gezocht naar een mogelijkheid om rapporten en webpagina's te genereren die voor niet architectuur stakeholders geen gegevens bevatten niet relevant voor het model, dat kan betekenen dat in een aantal situaties de ABBs niet uitgewerkt hoeven te worden. Het in de modellering toepassen van de directe associatie tussen service en SBB voldoet niet aan de viewpoints.

In this scenario the master data register collaborates with the various data producing application functions. This means that when data is modified in one of the systems these modifications are shared between all collaborating functions. Therefore the integration between these data producers is essential in this scenario An interesting scenario in this is where the Data Register is only used as a key store or key cabinet and the detailed data is kept in the other source systems Advantages - Data is gathered directly from source systems and thus it is always accurate and real time. - Data can be stored within the source systems in a specific format supporting the business processes within these systems - Differences in availability between consumers and sources can be handled by the Data Register - Reuse of screens, workflows and validations in the source systems - Data standardization within the Data Register - Introduction of a key store or key cabinet. Disadvantages - Managing the synchronization between systems is an extra piece of work and complexity. - Replication of data - Complex data transformations from sources to register and back

In dit scenario is er slechts één toepassing voor het produceren van stamgegevens. Dat is het dataregister. Het kan ook een van de bestaande bronsystemen zijn. Alle andere applicaties verbruiken deze gegevens uit het dataregister en gebruiken deze in hun aanvraagprocessen. Dit omvat de applicatiefuncties voor ERP en geo enz. Voordelen:

• Het servicedesign wordt direct in kaart gebracht in het dataregister.
• Mogelijkheid om het informatiemodel en service-interfaces te standaardiseren
• Verificatie en bedrijfsregels worden alleen geïmplementeerd in het dataregister.
• Realtime uitlijning van de gegevens alleen op lezen/verzoek
• Hoge beschikbaarheid alleen nodig voor het dataregister.
• Uiteindelijk geen replicatie van data (afhankelijk van de volwassenheid van de verbruikende systemen)

Nadelen:

• Elke verandering in datamodel bij consumenten leidt tot verandering in service, dit zou op elkaar moeten worden afgestemd of een groot gestandaardiseerd datamodel in de service-interface vereisen.
• Informatievoorziening aan applicaties moet opnieuw worden ontworpen, wat veel werk is
• Herontwerp van het volledige applicatielandschap
• Hoge vraag naar prestaties en beschikbaarheid voor het dataregister
• Invoering van een single point of failure dus extra niet-functionele eisen in AIC

In dit scenario is er geen dataregister maar worden alle masterdata opgeslagen binnen de dataproducenten zoals ERP en geofuncties. Voor de dataconsumenten zijn de data echter op gestandaardiseerde wijze beschikbaar via de asset data services. Dit betekent dat wanneer een consument assetdata nodig heeft, dit via de dataservices wordt opgevraagd en uit de verschillende dataproducerende applicaties wordt verzameld. De implementatie van de dataservices zorgt voor de standaardisatie van het masterdatamodel en het data-uitwisselingsprotocol Voordelen:

• Realtime afstemming van de gegevens.
• Eén punt van waarheid en onderhoud
• Geen replicatie van data (en de bijbehorende complexiteit)
• Hergebruik van bestaande gebruikersinterfaces, validaties en (verborgen) integraties

Nadelen

• Het serviceontwerp mag de gegevens niet verbeteren, dus de toepassing moet mogelijk opnieuw worden ontworpen.
• Elke verandering in datamodel in bronnen leidt tot verandering in service, dit moet op elkaar worden afgestemd.
• Verificatie en bedrijfsregels worden geïmplementeerd in bronsystemen.
• Hoge beschikbaarheid en prestatie-eisen voor alle producerende systemen
• Complexe modeltransformaties binnen de servicelaag om voor een specifiek producentensysteemmodel te transformeren naar het vereiste model door de consumenten
• Releases van de bronsystemen worden complexer door de nieuwe afhankelijkheden in de dataservices

SWOT analyse op basis van ArchiMate assessments. Deze zijn vervolgens gerelateerd aan de rest van het ArchiMate model in deze repository.