# data[].attributes.body
Deze methode biedt een stappenplan waarin is aangegeven welke activiteiten moeten worden uitgevoerd en wat hun invoer en uitvoer is. De methode geeft niet in detail aan welke inhoudelijke architectuurmodellen moeten worden gemaakt .

·         A: Architecture Vision;

·         B: Business Architecture;

·         C: Information Systems Architecture;

·         D: Technology Architectures;

·         E: Opportunities and Solutions;

·         F: Migration Planning;

·         G: Implementation Governance;

·         H: Architecture Change Management.
https://archixl.nl/files/srm_togaf.pdf

# data[].attributes.body
De NORA is bedoeld als richting gevend en sturend instrument. Het bevat kaders en bestaande afspraken voor het inrichten van de informatiehuishouding van de Nederlandse overheid. Het realiseren van voorzieningen binnen die kaders en afspraken, zorgt er voor dat ze goed samenwerken met andere voorzieningen en dat optimaal hergebruik gemaakt wordt van bestaande oplossingen. Naast de beleidskaders omvat de NORA principes, standaarden, bouwstenen en een begrippenkader. Dit zijn de basiselementen waarmee architectuur werkt. Een bouwsteen is gedefinieerd in NORA als: "Voorziening die deel uitmaakt van de infrastructuur van de e-overheid." Wat een voorziening is, is nog niet nader bepaald. In de praktijk wordt bij bouwstenen gedacht aan een systeem, product, standaard of een stelsel van afspraken.

# data[].attributes.body
RUP staat voor Rational Unified Process.  RUP is gebaseerd op een aantal principes en best practices:
- Ontwikkel software incrementeel/iteratief
- Management van software requirements
- Maak gebruik van op componenten gebaseerde architectuur
- Maak prototypes
- Test het systeem
- Maak gebruik van versiebeheer tijdens de softwareontwikkeling
https://nl.wikipedia.org/wiki/Rational_Unified_Process

# data[].attributes.body
De Rational  Unified  Process  (RUP)  is  een  systeemontwikkelingsmethode.  Het verschaft een gestructureerde methode voor het toewijzen van verantwoordelijkheden in een ontwikkelingsorganisatie.  Het doel van RUP  is het zekerstellen van het maken van software van hoge kwaliteit die tegemoetkomt aan de eisen van de gebruikers binnen de begrootte tijdsspanne en het budget.

Onderstaande figuur is een overzicht van RUP
------------------------------------------------------
RUP heeft twee dimensies:

Op de horizontale as staan de tijd, fasering en iteraties;

Op de verticale as staan de verschillende disciplines welke logisch zijn gegroepeerd.

De eerste dimensie heeft betrekking op het dynamische aspect van het proces dat tot uitdrukking

Komt in fases, iteraties en mijlpalen.

De tweede dimensie heeft betrekking op het statische aspecten van het proces dat tot uitdrukking

Komt in componenten, disciplines, activiteiten, workflow, tussenproducten en rollen.

In het figuur staat de inspanning in de tijd per discipline.  In het begin wordt bijvoorbeeld meer tijd

# data[].attributes.body
PRINCE2 is een methode voor projectmanagement. Deze methode is gericht op het management, de besturing en de organisatie van een project. PRINCE2 is toepasbaar op alle projecten en kent een grote flexibiliteit qua inzet.

# data[].attributes.body
1.       Sturen van een project

2.       Opstarten van een project

3.       Initiëren van een project

4.       Faseovergangen managen

5.       Beheersen van een fase

6.       Managen productoplevering

7.       Afsluiten van een project

# data[].attributes.body
PRINCE2 is een methode op procesbasis voor effectief projectmanagement waarmee u de fundamentele vaardigheden leert die nodig zijn om een ​​succesvolle projectmanager te worden. Het staat voor PRojects IN Controlled Environments en wordt over de hele wereld gebruikt en erkend.
https://www.prince2.com/nl/what-is-prince2

# data[].attributes.headline
PRINCE2 is een benadering voor projectmanagement op procesbasis die een eenvoudig aan te passen en schaalbare methode voor het management van alle types projecten biedt. Elk proces wordt gedefinieerd met de belangrijkste input en output samen met de specifieke doelen die behaald moeten worden en de activiteiten die uitgevoerd moeten worden.

# data[].attributes.subject
PRINCE2 is een benadering voor projectmanagement op procesbasis die een eenvoudig aan te passen en schaalbare methode voor het management van alle types projecten biedt. Elk proces wordt gedefinieerd met de belangrijkste input en output samen met de specifieke doelen die behaald moeten worden en de activiteiten die uitgevoerd moeten worden.

# data[].attributes.body
Rational Unified Process
Eén van de zgn. agile ontwikkelingsmethodologieën.

# data[].attributes.headline
RUP focussed primair op speciale activiteiten zoals Business modeling, design en architectuur.

# data[].attributes.subject
RUP focussed primair op speciale activiteiten zoals Business modeling, design en architectuur.

# data[].attributes.body
Prince2 is een methode voor algemeen projectmanagement.
RUP is een methode voor systeemontwikkeling.

# data[].attributes.body
het zijn processen die zichzelf constant herhalen

# data[].attributes.body
Beide methoden hebben een eigen Engelstalige terminologie.

# data[].attributes.body
Beide methoden kennen fasen (stages in Prince2 respectievelijk phases in RUP).

# data[].attributes.body
prince 2 gaat over vaardigheden hebben terwijl RUP over hoe een proces vorm te doen geven

# data[].attributes.headline
De foundatie van RUP is gebaseerd op een set van Software best practices (itteratief ontwikkelen, requirements beheren, componente architectuur, visuele modellen, herhaaldelijke verificatie van kwaliteit, en het beheren van veranderingen

# data[].attributes.subject
De foundatie van RUP is gebaseerd op een set van Software best practices (itteratief ontwikkelen, requirements beheren, componente architectuur, visuele modellen, herhaaldelijke verificatie van kwaliteit, en het beheren van veranderingen

# data[].attributes.body
Bij de methode hebben een business case inzich.

# data[].attributes.attachment_link.readable_text
Door de toenemende complexiteit van ICT-projecten op zowel organisatorisch als technisch vlak, wordt het steeds belangrijker om bewezen methoden en technieken in te zetten. Hierdoor is een verbetering van kwaliteit, voorspelbaarheid, beheersbaarheid en productiviteit te realiseren. Een veel voorkomende projectmanagementmethode is Prince2, terwijl voor softwareontwikkeling RUP een hoge vlucht neemt. Zowel Prince2 als RUP zijn gebaseerd op best practices en hebben elk afzonderlijk in de praktijk bewezen dat zij, mits goed toegepast, een grote kans van slagen hebben.

Waarom zou men Prince2 en RUP willen combineren?
Prince2 is een uitstekende methode voor algemeen projectmanagement, waarmee allerlei projectsoorten (dus niet alleen ICT-projecten) kunnen worden aangestuurd. De methode biedt echter geen expliciete ondersteuning voor systeemontwikkeling. Voor een ICT-project is dan ook naast Prince2 een methode voor systeemontwikkeling nodig. RUP is een prima methode voor systeemontwikkeling, die steeds vaker wordt toegepast.
Indien Prince2 en RUP aanvullend op elkaar kunnen worden gebruikt, kan dit leiden tot een versterking van de voordelen van beide methoden (best of both worlds). Het nadeel van het gebruik van twee methoden is dat er overlap is. Dit betekent dat er keuzes moeten worden gemaakt over waar Prince2 leidend is en waar RUP. Het niet maken van keuzes of het maken van de verkeerde keuzes bepaalt of er sprake zal zijn van een symbiose of van een conflict.
Op welke gebieden conflicteren
beide methoden?
Op een aantal gebieden dreigen er conflicten. Dit heeft te maken met onder meer de terminologie, fasering en processen.
1. Terminologie
Beide methoden hebben een eigen Engelstalige terminologie. Naast het feit dat van twee methoden het 'dialect' moet worden geleerd, kan er ook verwarring ontstaan over de betekenis van de begrippen. De neiging bestaat dan ook om eigen Nederlandse woorden te gaan gebruiken.
Aangeraden wordt om de terminologie van beide methoden te handhaven want:
* beide terminologieën zijn blijvend in ontwikkeling, waardoor discrepantie met de bronmethode kan ontstaan;
* beide terminologieën zijn ook bij buitenstaanders in gebruik. Door de terminologie te handhaven is communicatie met de buitenwereld en nieuwe medewerkers eenvoudiger;
* de meeste projectmedewerkers krijgen te maken met maar één van beide terminologieën, waardoor de impact van de overlap minimaal is.
2. Fasering
Beide methoden kennen fasen (stages in Prince2 respectievelijk phases in RUP). De projectaanpak van Prince2 is op een aantal punten anders dan die van RUP. Zowel Prince2 als RUP gaan uit van een deelproductplanning (lever subsysteem X op), hoewel RUP wel werkt met zogenaamde 'work breakdown structures'. De RUP-phases en Prince2-stages lopen echter niet helemaal synchroon. RUP kent buiten de Prince2-stages ook een aantal andere processen. Hier zal in het projectplan expliciet aandacht aan moeten worden geschonken. In de praktijk blijkt dat het prettig is om Prince2 te gebruiken als raamwerk en RUP voor de invulling hiervan.
3. Processen
Elke projectmethode kent een aantal gelijke processen (in RUP 'activities'), zoals het starten van een project (vergelijk Prince2 'starting up' met RUP 'conceive new project'). In het projectplan zal een keuze moeten worden gemaakt tussen de processen. In de praktijk werkt het goed om de Prince2-processen als uitgangspunt te nemen en voor zaken die specifiek zijn voor systeemonwikkeling RUP te gebruiken. Omdat elk project uniek is, wordt elke keer voorafgaand aan het project een afweging gemaakt wat wel en wat niet moet gebeuren.

Zijn er nog valkuilen?
Het begrip kwaliteit speelt een cruciale rol bij het goed toepassen van de 'best practices'. Een grote valkuil is om de generieke 'best practices' van RUP en Prince2 één op één toe te passen binnen de eigen procescontext. Deze valkuil heeft de bijnaam 'Rücksichtslos RUP/Prince2' gekregen. Een voorbeeld uit de praktijk.
Binnen een project dat de herbouw van een bestaande applicatie als doel heeft, worden use cases gemaakt volgens de sjabloon en beschrijvingen van RUP. De tijd die het kost om een use case te analyseren en uit te werken is ongeveer vijf mandagen. Binnen het ontwerp- en testteam leeft er ongenoegen over het gebruik van use cases. Bij analyse blijkt dat zowel het functionele team (verantwoordelijk voor use cases), het ontwerpteam (verantwoordelijk voor technisch ontwerp en bouw), als het testteam (verantwoordelijk voor de testcases en -gevallen) de oude applicatie alsnog moeten onderzoeken. In een workshop met het projectteam wordt gekeken hoe dit verbeterd kan worden. De uitkomst is dat de opdeling van de use cases goed is, maar dat de inhoud veel meer venstergedreven moet zijn (90 procent van de formulieren moet ongewijzigd blijven). En dat de business rules gedocumenteerd moeten worden, met daarbij de gebruikte concepten uit het domeinmodel. De nieuwe werkwijze leidt tot een spectaculaire verlaging van de benodigde tijd om een use case te maken en zorgt ervoor dat de ontwerp- en testteams de specificaties zonder de oude applicatie kunnen gebruiken. Dus tevreden gebruikers bij een verhoogde efficiency.

Waar ligt de symbiose tussen beide methoden?
Op een aantal gebieden is er een grote symbiose mogelijk. Dit ligt onder andere op het vlak van de business case (feasibilty study), een proof of concept en de iteratieve aanpak.
1. Business case
RUP is zoals gezegd een methode voor softwareontwikkeling. Dit betekent dat RUP pas ingezet kan worden zodra duidelijk is dat bij de oplossing software nodig is. Voor de voorfase heeft Prince2 een methode (de business case/feasibility study). Vanuit deze business case wordt uitgaande van de bedrijfsbehoefte onder meer inzichtelijk gemaakt:
* wat het bedrijfsdoel is;
* welke grenzen het bedrijf stelt aan risico's en kosten van het project;
* of er software gemaakt en/of aangeschaft dient te worden. RUP is geoptimaliseerd voor softwareontwikkeling, echter voor de aanschaf van standaardpakketten is RUP minder geschikt;
* wie de stakeholders zijn en wat hun belangen zijn.
Met name bij grotere projecten of indien er sprake is van grote bedrijfsonzekerheden biedt een feasibility study een brede en gedegen basis voor het vervolgtraject.
2. Proof of concept (POC)
De insteek van RUP om alle risicovolle zaken, vooral op het technische en functionele vlak, zo snel mogelijk te realiseren is zeer vruchtbaar gebleken. RUP gaat ervan uit dat 80 procent van de risico's in een vroeg stadium aangepakt worden. Eén van de handvatten is om een POC uit te voeren. Dit heeft tot doel de haalbaarheid van het project aan te tonen voordat er veel geld is uitgegeven. POC's kunnen veel geld besparen als zij worden uitgevoerd bij bijvoorbeeld:
* het opleveren van een werkend prototype om de functionele risico's te verlagen;
* het uitvoeren van een code review bij de producent van een standaardpakket om technische risico's te verlagen;
* het maken van afspraken over hoe de oplossing gereviewd wordt op basis van een architecturaal prototype om politieke risico's te verlagen.
3. Iteratieve aanpak
Iteratief werken is een RUP-werkwijze die haar wortels vindt in zowel de watervalaanpak als de RAD-aanpak. Binnen Prince2 kan deze werkwijze prima worden aangestuurd met zogenaamde workpackages (werkpakketten). Hieronder volgt een aantal voorbeelden waar de iteratieve aanpak een positieve bijdrage levert.
Omdat een iteratie als een miniwatervalproject wordt uitgevoerd kunnen de lessen uit de vorige iteratie weer mee worden genomen in de volgende. Vooral bij het inwerken van nieuwe krachten heeft dit als groot voordeel dat de geleerde lessen onmiddellijk kunnen worden toegepast, in plaats van in het volgende project.
Aan het begin van het project wordt reeds werkende software opgeleverd. Het management en zijn adviseurs kunnen vroeg zien of het beeld dat leeft binnen het projectteam overeenkomt met hun beeld van de oplossing. Dit maakt een vroege bijsturing mogelijk. Voordeel is dat in de praktijk door deze aanpak vaker een project vroegtijdig wordt gestaakt. Voor de projectmanager voelt dit als een nederlaag, maar voor de organisatie betekent het vaak een enorme besparing omdat er anders veel geld in een niet gewenste of haalbare oplossing wordt gestoken.
Door vroeg in het project het moeilijkste deel op te leveren en daarmee de planning te controleren, kan de business case (onderdeel kostenanalyse) worden bijgesteld. Verrassingen achteraf komen, indien goed toegepast, veel minder voor.
Doordat de use case een kleine functionele eenheid is, die past op de taak van een gebruiker, kan deze goed als planningseenheid worden gebruikt. In het begin zal de nadruk liggen op het uitwerken van de use cases, terwijl later de nadruk ligt op het ontwerpen en coderen van de use cases. Aan het einde volgen de acceptatietesten. De use case is ook een primair planningshulpmiddel.

Twee methoden
Prince2 (PRojects IN a Controlled Environments) is een gestructureerde en schaalbare methode voor projectmanagement, gebaseerd op best practices. Deze bestaan uit een gestandaardiseerde projectorganisatie, processen, producten, technieken. De bedrijfsmatige aanpak blijkt vooral uit de aansturing van het project (management by exception) en de nadruk op bedrijfseconomische overwegingen (kosten/baten).
RUP (Rational Unified Process) is een gestructureerde en schaalbare methode voor softwareontwikkeling, gebaseerd op best practices. Deze bestaan uit standaarden en richtlijnen voor: fasering, activiteiten, producten, disciplines en rollen, gedocumenteerd in een geïntegreerde, toegankelijke website. Voor projectmanagement is de sturing voornamelijk geënt op duidelijk gestelde prioriteiten en geïdentificeerde risico's.

Praktijk
Een mogelijke werkwijze gaat als volgt. Het project wordt opgedeeld in een aantal fasen, waarbinnen iteraties van ongeveer vier weken zitten. Dit zijn miniwatervalprojecten, waarbij gebruik wordt gemaakt van timeboxing. Lessons learned worden al in de volgende iteratie toegepast. Hieronder wordt nader ingegaan op de fasering.
1. 'Starting up a project' is de eerste stap die eigenlijk voor aanvang van het project wordt gedaan. Het project start op het moment dat de stuurgroep haar goedkeuring heeft gegeven.
2. In 'Initiate a project' wordt de scope bepaald. Plan van aanpak, business case, visie, scope en geïdentificeerde use cases spelen hier een belangrijke rol. Aan het einde van deze fase geeft de stuurgroep haar goedkeuring.
3. In de 'Elaboration' worden alle belangrijke risico's verkleind. Dit wordt gedaan door de meest risicovolle use cases helemaal uit te specificeren en op basis hiervan een basisarchitectuur te ontwerpen. Hierbij wordt gebruik gemaakt van proofs of concept. De architectuur wordt bewezen door één van de moeilijkste use cases helemaal uitgewerkt en getest op te leveren. Hiermee ligt er een sterke basis voor een betrouwbare schatting/planning.
4. In de 'Construction' ligt de nadruk op de bouw van het systeem. Elke iteratie bevat een aantal bij elkaar horende use cases. Eerst worden de use cases verder afgemaakt met een prototype. Dan worden zij gebouwd, waarna een integratietest en eventueel een gebruikersdeelacceptatietest wordt uitgevoerd.
5. De 'Transition' bestaat uit twee iteraties. De nadruk ligt vooral op de acceptatietest en oplevering, maar er wordt ook rework gedaan en de oplevering wordt voorbereid.
6. 'Closing a project' is de laatste stap. Het product wordt volgens de eisen opgeleverd en is geaccepteerd. Het project wordt nu ontbonden en de geleerde lessen worden beschikbaar gesteld voor volgende projecten.
Bij deze fasering is Prince2 als basis genomen. De inhoud van de fases 'Elaboration', 'Construction' en 'Transition' komen uit RUP.
Gerard van der Helm (Prince2 Foundation en Practitioner gecertificeerd) is als project director bij LogicaCMG verantwoordelijk voor het managen van complexe, grootschalige en innovatieve projecten. Dik Harbrecht (RUP Principal gecertificeerd) is senior-consultant bij LogicaCMG.
Op 12 oktober organiseren IBM en LogicaCMG een middagseminar over de toepassing van Prince2 en RUP in Living Tomorrow in Amsterdam (www.logicacmg.nl/ibm)
n aantal gebieden dreigen conflicten

# data[].attributes.attachment_link.title
Waarom zou men Prince2 en RUP willen gebruiken?

# data[].attributes.attachment_link.description
Door de toenemende complexiteit van ICT-projecten op zowel organisatorisch als technisch vlak, wordt het steeds belangrijker om bewezen methoden en technieken in te zetten. Hierdoor is een verbetering van kwaliteit, voorspelbaarheid, beheersbaarheid en productiviteit te realiseren. Een veel voorkomende projectmanagementmethode is Prince2, terwijl voor softwareontwikkeling RUP een hoge vlucht neemt.

# data[].attributes.body
Het opzetten van een interactieplan tussen verschillende systemen, servers en applicaties.

# data[].attributes.headline
Relaties tussen systemen en de invloed die ze op elkaar uitoefenen.

# data[].attributes.subject
Relaties tussen systemen en de invloed die ze op elkaar uitoefenen.

# data[].attributes.body
Raamwerk om geordend iets te creëren

# data[].attributes.headline
architectuur is een samenloop van alle processen en onderdelen binnen een bedrijf die via een schets met elkaar in verbinding staan.

# data[].attributes.subject
architectuur is een samenloop van alle processen en onderdelen binnen een bedrijf die via een schets met elkaar in verbinding staan.

# data[].attributes.body
De landkaart van een bedrijf waar alle fysieke applicaties worden weergeven. Met alle verbindingen tussen al deze applicaties en medewerkers.

# data[].attributes.body
Enterprise Architectuur is een coherente, consistente verzameling principes, verbijzonderd naar uitgangspunten, regels, richtlijnen en standaarden.

# data[].attributes.body
Raamwerk
Infrastructuur architectuur
Business architectuur
Technology architectuur

# data[].attributes.headline
Gestructureerde/georaniseerde opbouw van een bepaald gegeven 

# data[].attributes.subject
Gestructureerde/georaniseerde opbouw van een bepaald gegeven 

# data[].attributes.body
Architectuur is de beschrijving van alle interacties en activiteiten die in een organisatie / systeem plaatsvinden.

# data[].attributes.body
beschrijving interacties

# data[].attributes.body
DYA|Infrastructure is a method that aims to support the infrastructure architect. It brings business agility, architectural effectiveness and manageable and expandable infrastructure landscapes within the grasp of any organization. DYA infrastructure provides three mutually supportive elements:

1. A definitive description of infrastructure architecture as an integral part of the architectural process, and how it helps enforce architectural principles—with two focal points: defining a functional approach to infrastructure facilities and how to select and work with the appropriate quality attributes

2. The building blocks model (an architectural meta-model for infrastructure) that...

1. Creates and describes logical, modular infrastructure facilities

2. Maintains a categorical and functional inventory of existing infrastructure "landscapes"

3. Structures and constructs architectural products, like reference architecture, impact analyses, and project start architecture

3. Best practices to help begin infrastructure architecture smoothly, and guidelines for producing essential architectural artifacts that make infrastructure architecture work

Various implementation strategies are outlined, how to extend the Project Start Architecture is explained and the importance of a number of products such as Reference Architectures, Product Catalogs and Service Catalogs are also illustrated.

Apart from these three main ingredients, DYA|Infrastructure also provides guidance on how infrastructure architecture can improve security, project management, test management and production

# data[].attributes.body
Architecture is defined as:

1.   In reference to computers, software or networks, the overall design of a computing system and the logical and physical interrelationships between its components. The architecture specifies the hardware, software, access methods and protocols used throughout the system.

2.    A framework and set of guidelines to build new systems. IT architecture is a series of principles, guidelines or rules used by an enterprise to direct the process of acquiring, building, modifying and interfacing IT resources throughout the enterprise. These resources can include equipment, software, communications, development methodologies, modeling tools and organizational structures.
Definition of Architecture - IT Glossary | Gartner