Generieke klasse voor het beschrijven van een adres

Generieke klasse voor het beschrijven van een adres

Andere gestructureerde gegevensopslag zoals JSON, REST, RSS

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

Backup en restore procedures zijn cruciale processen voor het beveiligen en herstellen van data. Hier is een overzicht: Back-up procedure:  

• Regelmatige back-ups maken van alle belangrijke data.
• Gebruik maken van verschillende soorten back-ups: vol, incrementeel, en differentieel.
• Back-ups opslaan op veilige, redundante locaties, zoals externe harde schijven, cloud-opslag of off-site locaties.

Restore procedure:  

• Herstelproces documenteren: stap-voor-stap instructies voor het terugzetten van back-ups.
• Regelmatig testen van het herstelproces om er zeker van te zijn dat het werkt.
• Herstellen van data uit de back-up, indien nodig, naar de juiste locatie en ervoor zorgen dat alle systemen correct functioneren na het herstel.

Beperking van het aantal verschillende softwarestacks en zorgdragen dat deze aanwezige softwarestacks in de infrastructuur gestandaardiseerd worden ingericht. Bijvoorbeeld het dotnet framework als basis binnen de windows server infrastructuur.

Beperking van het aantal verschillende softwarestacks en zorgdragen dat deze aanwezige softwarestacks in de infrastructuur gestandaardiseerd worden ingericht. Bijvoorbeeld het dotnet framework als basis binnen de windows server infrastructuur.

Datakwaliteiten dragen zorg voor dat datakwaliteit de activiteiten van de organisatie voldoende ondersteunen en bijdragen aan het krijgen van inzicht over de prestaties binnen de organisatie.

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

Human Resource Management diensten die aangeboden worden aan de rest van de organisatie zoals de vestigingen.

Met name op het vlad van de technische infrastructuur zullen architectuur elementen de requirements rond data operation realiseren. Denk hierbij aan zaken zoals systeem software voor backup en restore, uitwijk, performance en andere kwaliteitsdimensies voor data binnen de organisatie.

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.

Aangezien de meeste dataveranderingsprojecten de ontwikkeling of aanschaf van softwaretoepassingen vereisen, is een algemeen begrip van technologie, technologische ontwikkelingen en benaderingen van softwareontwikkeling noodzakelijk, zodat data-architecten zinvol kunnen communiceren met hun technologiegerichte collega's en hun rol en bijdrage aan de oplossingsarchitectuur en het ontwikkelingsproces kunnen waarderen. De mate waarin data-architecten technische kennis nodig hebben, hangt af van de aard van het analysewerk dat wordt uitgevoerd. De belangrijkste vereiste is dat de data-architect het potentieel van technologie en de benaderingen en termen die door technische specialisten worden gebruikt, begrijpt. Enkele van de belangrijkste gebieden die data-architecten moeten begrijpen, worden hieronder opgesomd: Trends en ontwikkelingen zoals AI, robotic process automation (RPA), big data, software as a service (SaaS), visualisatie, mobiele technologieën, en hoe deze impact hebben op organisaties en de potentie die ze bieden voor nieuwe of verbeterde producten of diensten. Technische infrastructuurcomponenten zoals besturingssystemen, applicatiesoftware, hardware, netwerken, cloud computing. Levenscycli van systeemontwikkeling (SDLC's) en benaderingen zoals het 'V'-model en het uniforme proces. Benaderingen voor systeemmodellering zoals de UML. Agile ontwikkelingsbenaderingen zoals DSDM en Scrum. De relatieve voor- en nadelen van het ontwikkelen van software in plaats van het kopen van kant-en-klare softwareproducten. Organisatiestructuren Veel bedrijfsveranderingsprojecten omvatten het tot op zekere hoogte herstructureren van divisies of teams om overdrachten te verwijderen, taken te centraliseren of de klantenservice te verbeteren. Om deze redenen is het belangrijk dat een data-architect een goed begrip heeft van de verschillende organisatiestructuren die zich kunnen voordoen – functioneel, project, matrix, plat, virtueel – en van hun relatieve sterke en zwakke punten. Beheer van leveranciers Veel organisaties maken gebruik van externe leveranciers om hun IT-systemen te leveren, hetzij op ad-hocbasis, hetzij via een uitgebreidere outsourcingregeling, die hele bedrijfsprocessen of zelfs een hele bedrijfsfunctie kan omvatten. Veel organisaties hebben bijvoorbeeld hun salarisadministratieprocessen meerdere jaren uitbesteed, maar sommige hebben dit nu uitgebreid tot een groot deel van het personeelswerk (HR), van werving tot het bijhouden van gegevens. Selecteren en contracteren van leveranciers valt meestal binnen het domein van de inkoopfunctie. Voor sommige outsourcingcontracten kan de data-architect echter betrokken zijn om ervoor te zorgen dat de bedrijfsprocessen en -systemen efficiënt blijven werken. Dit vereist dat data-architecten een breed begrip hebben van inkoop- en leveranciersbeheerprocessen. Data-architecten moeten op zijn minst op de hoogte zijn van de verschillende contractuele regelingen die beschikbaar zijn, met name: Tijd en materiaal: Wanneer de gecontracteerde partij wordt betaald op basis van de gewerkte tijd en de te leveren prestaties die zijn geleverd; het tijdselement heeft geen betrekking op de verstreken tijd van het project, maar op de hoeveelheid inspanning die is geleverd. Levering tegen een vaste prijs: waarbij de gecontracteerde partij de prijs ontvangt die is overeengekomen voor de levering van het werk in overeenstemming met de oorspronkelijke specificatie. Risico en beloning: Wanneer de gecontracteerde partij ermee heeft ingestemd om een deel of het volledige risico van het project te dragen. Bijvoorbeeld door middelen te investeren zoals personeelstijd, materialen of kantoorruimte, maar waarbij de potentiële beloningen groter zijn dan bij andere contractuele regelingen. Data-architecten moeten in staat zijn om met leveranciers in contact te komen om ervoor te zorgen dat ze hun diensten effectief leveren. Dit vereist persoonlijke kwaliteiten zoals communicatie en het opbouwen van relaties, die eerder zijn besproken

Verwijst naar het vermogen of de architectuur van een systeem om steeds grotere hoeveelheden gegevens te beheren of de werklast uit te breiden zonder concessies te doen aan de prestaties, betrouwbaarheid of onderhoudbaarheid.

Verwijst naar het vermogen of de architectuur van een systeem om steeds grotere hoeveelheden gegevens te beheren of de werklast uit te breiden zonder concessies te doen aan de prestaties, betrouwbaarheid of onderhoudbaarheid.

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

Whitepaper with the list of permissions in Sparx Enterprise Architect for administrators and modellers

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