Inleiding

Over het algemeen wordt de norm IEEE 1471 - 2000 algemeen aanvaardt als uitgangspunt voor architectuurbeschrijvingen. Deze norm is ontwikkeld door IEEE (Institute of Electrical and Electronics Engineers, Inc., www.ieee.com). Door deze organisatie werd geconstateerd dat in het verleden hardware gerelateerde architectuur aspecten vaak dominant waren en dat software gerelateerde architectuur integriteit, als het al bestond, vaak werd geofferd gedurende de software ontwikkeling. Door de toenemende kosten en complexiteit van software ontwikkeling was dit echter aan het veranderen. Software ontwikkeling kon veel baat hebben bij het toepassen van architectuur voorschriften, maar deze waren niet consistent gedefinieerd en toegepast binnen de levenscyclus van software intensieve systemen. Er was geen universeel geaccepteerd raamwerk voor architectuur denken.

De IEEE planning group (APG) was opgericht in augustus 1995 om deze behoefte te addresseren. De APG was opgezet door het IEEE Software Engineering Standards Committee (SESC) om richting te geven aan het inbedden van architectuur denken in de IEEE standaarden. De APG's discussies moesten leiden tot een aanbeveling voor een IEEE activiteit met de volgende doelen:

• Het definieren van bruikbare termen, principes en richtlijnen voor de consistente toepassing van architectuur voorschriften voor systemen gedurende hun levenscyclus;
• Het uitwerken van architectuur voorschriften en hun voorziene opbrengsten voor software producten, systemen en geaggregeerde systemen (systemen van systemen);
• Het verschaffen van een raamwerk voor de verzameling en overweging van architecturele attributen en gerelateerde informatie voor gebruik in de IEEE standaarden;
• Het verschaffen van een bruikbare road map voor de inbedding van architectuur voorschriften in de ontwikkeling, revisie, en toepassing van IEEE standaarden.

Denkwijze

De basisprincipes van views zijn vastgelegd in IEEE-standaard 1471-2000 (IEEE, 2000). Deze standaard beschrijft de begrippen belanghebbende (stakeholder), belang (concern), gezichtspunt (viewpoint) en beeld (view). De architectuur bestaat uit een aantal views: representaties van het systeem vanuit het perspectief van een gerelateerde set belangen. Gezichtspunten bepalen hoe een bepaald type beeld er uit moet zien. IEEE Std. 1471 is een beknopte standaard, hij vertelt niet welke views gemaakt moeten worden en hoe. Voor mensen die gebruik willen maken van een min of meer geaccepteerde aanpak is de verleiding daarom groot om een raamwerk te adopteren. Het uitgangspunt achter IEEE 1471 is echter dat architectuurdocumentatie wordt opgesteld vanuit de gedachtewereld van de belanghebbenden. Het is de vraag of een raamwerk dat opdelingen op allerlei logische gronden scheidt (statisch van dynamisch, functioneel van implementatie) overeenkomt met de informatiebehoefte van de doelgroep. Bovendien lijken de raamwerken, met hun focus op de beschrijving van het systeem zelf, zich nauwelijks te bekommeren over allerlei andere belangrijke vragen: Op basis van welke principes werken we? Hoe duur wordt dit? Welk risico introduceren we?

IEEE 1471 - 2000 is sterk ge�nspireerd door de systeemtheorie. Een overzicht van de begrippen en hun samenhang wordt weergegeven in dit schema:

Belangrijk is dat hier onderscheid gemaakt wordt in systeem en architectuur aan aan kant en de subjectieve invalshoeken en architectuurbeschrijvingen aan de andere kant.
De volgende definities worden gehanteerd:

• A system is a collection of components organized to accomplish a specific function or set of functions.
• The architecture of a system is the system's fundamental organization, embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution.
• An architect is the person, team or organization responsible for systems architecture.
• An architecture description is a collection of artifacts that document an architecture.
• Stakeholders are people who have key roles in, or concerns about, the system: for example, as users, developers, or managers. Different stakeholders with different roles in the system will have different concerns. Stakeholders can be individuals, teams, or organizations (or classes thereof).
• Concerns are the key interests that are crucially important to the stakeholders in the system, and determine the acceptability of the system. Concerns may pertain to any aspect of the system' s functioning, development, or operation, including considerations such as performance, reliability, security, distribution, and evolvability.
• A view is a representation of a whole system from the perspective of a related set of concerns.
• A viewpoint is a specification of the conventions for constructing and using a view. A pattern or template from which to develop individual views by establishing the purposes and audience for a view and the techniques for its creation and analysis.

Werkwijze

De werkwijze wordt slechts summier beschreven. Er wordt wel een overzicht gegeven van de architectuur beschrijving practices:

• Architectuur documentatie
• Identificatie van belanghebbenden en belangen
  Minimale belanghebbenden: gebruikers, verkrijgers, ontwikkelaars, beheerders
  Minimale belangen: doel, geschiktheid, haalbaarheid, risico's, onderhoudbaarheid
• Keuze van architectuur gezichtspunten
• Architectuur beelden
• Consistentie tussen beelden
• Architectuur redenen (rationale)

Producten

De viewpoints, views en architectural desciptions moeten zelf ingevuld worden. Het raamwerk bevat dus niet echt kant en klare producten.

Er worden wel enkele (willekeurige) voorbeelden gegeven:

• Structural viewpoint in software architecture
• Behavioral viewpoint
• Physical interconnect viewpoint
• Link bit error rate viewpoint

Hulpmiddelen

Geen

Inleiding

De basis van TOGAF is gelegd door het Ministerie van Defensie in de Verenigde Staten. Zij gaven The Open Group toestemming om een TOGAF te ontwikkelen op basis van TAFIM, de reeds bestaande methodiek die het ministerie gebruikte en waar al veel moeite in was gestoken.

TOGAF, The Open Group Architecture Framework, is een industrie standaard architectuur raamwerk dat vrij gebruikt mag worden door elke organisatie die een informatie systeem architectuur wil ontwikkelen voor gebruik binnen die organisatie. The Open Group is een leverancier neutraal en techniek neutraal consortium die met de visie van Boundaryless Information Flow toegang tot geintegreerde informatie wil bevorderen, binnen en tussen organisaties, gebaseerd op open standaarden en globale interoperabiliteit. TOGAF is ontwikkeld en continue geevolueerd sinds het midden van de jaren 90 door vertegenwoordigers van 's werelds leidende IT klanten en leverancier organisaties in The Open Group's Architecture Forum.

TOGAF Version 8 Enterprise Edition ("TOGAF 8") is een gedetailleerde methode en verzameling van ondersteunende bronnen voor het ontwikkelen van een Enterprise Architecture. Als een samenhagende open methode voor Enterprise Architecture, TOGAF 8 vult aan, en kan gebruikt worden in combinatie met, andere raamwerken die meer gefocust zijn op specifieke producten voor bepaalde verticale sectoren zoals overhead, defensie en financieel.

De aanpak van TOGAF om tot een IT architectuur te komen wordt in de volgende delen gesplitst:

• Architecture Development Method (ADM)
• Enterprise Continuum
• Resource Base

Denkwijze

TOGAF omarmt maar hangt niet strikt aan de ANSI/IEEE Std 1471-2000 terminologie. In TOGAF, heeft architectuur twee betekenissen, afhankelijk van het contextueel gebruik:

• Een formele beschrijving van een systeem, of een gedetailleerd plan van een systeem op component niveau om haar implementatie te begeleiden.
• De structuur van componenten, hun relaties, en principes en richtlijnen die het ontwerp en evolutie van een systeem door de tijd regeren.

Een architectuur beschrijving volgens TOGAF is een formele beschrijving van een informatiesysteem, georganiseerd op een manier die het redeneren over de structurele eigenschappen van het systeem ondersteunt. Het definieert de componenten of bouwstenen waaruit het totale systeem bestaat, en verstrekken een plan op basis waarvan de producten kunnen worden verkregen en de systemen kunnen worden ontwikkeld, die samenwerken om het totale systeem te implementeren. Het stelt je dus in staat de totale IT investering te managen op een manier die aansluit bij de behoefte van jouw business.

Een Architecture Framework volgens TOGAF is een hulpmiddel dat gebruikt kan worden voor het ontwikkelen van een breed bereik van verschillende architecturen. Het moet een methode beschrijven voor het ontwerpen van een informatiesysteem in termen van een verzameling bouwstenen, en voor het tonen van de samenwerking tussen deze bouwstenen. Het moet een verzameling hulpmiddelen bevatten en een vocabulaire leveren. Het moet ook een lijst leveren van aanbevolen standaarden en ondersteunde producten die gebruikt kunnen worden om de bouwstenen te implementeren.

The minimale verzameling systeem belanghebbenden die overwogen moeten worden in de ontwikkeling van de architectuur gezichtspunten en beelden is volgens TOGAF

• Users
• System and Software Engineers
• Operators, Administrators, and Managers
• Acquirers

Werkwijze

De werkwijze ligt vastgelegd in de Architecture Development Method (ADM).

De sleutel van TOGAF is een praktische methode - the TOGAF Architecture Development Method (ADM) voor het definieren van business behoeften en het ontwikkelen van een architectuur die aansluiten bij deze behoeften, waarbij gebruik gemaakt worden van de elementen van TOGAF en andere architectuur producten die beschikbaar zijn in een organisatie.

De TOGAF Architecture Development Method schrijft niet een specifieke verzameling van architectuur producten voor. Het beschrijft wel een verzameling architectuur producten, maar bij wijze van voorbeeld. TOGAF is ontworpen om te gebruiken bij willekeurig welke verzameling door de gebruiker gepaste geachte architectuur producten. Dit kan de verzameling producten zijn die in TOGAF wordt beschreven, maar het kan ook een verzameling gebaseerd op een ander raamwerk zoals Zachman Framework, FEAF, etc. zijn.

Enkele uitgangspunten van de ADM:

• De ADM is iteratief, over het totale proces, tussen fasen, en binnen fasen. Voor elke iteratie van de ADM moet een beslissing moet worden genomen over:
  de breedte van de dekking van de te definieren enterprise;
  het te definieren niveau van detail;
  de lengte van de tijd horizon waar op gericht wordt, inclusief het aantal en de lengte van de tussenliggende tijd horizonnen;
  de architectuur goeden die opgenomen moeten worden in het Enterprise Continuum van de organisatie, inclusief:
  goeden gecreeerd in voorgaande iteraties van de ADM cyclus binnen de organisatie
  goeden beschikbaar elders in de industrie (andere raamwerken, systeem modellen, verticale industrie modellen, etc.)
   
• De beslissingen moeten gemaakt worden op basis van een praktische beoordeling van beschikbaarheid van bronnen en competenties, en de waarde voor de organisatie die realistisch verwacht kan worden van de gekozen scope van architectuur werk.
   
• Als een generieke methode, de ADM is bedoeld om te gebruiken door organisaties in een grote variatie van gebieden, sectoren en industrie types. De methode kan, maar hoeft niet, op maat gemaakt worden voor specifieke behoeften. Bijvoorbeeld:
  het kan gebruikt worden in combinatie met een verzameling producten van een ander framework, waar deze gepast geacht worden voor een specifieke organisatie
  het kan gebruikt worden in it may be used in combinatie met het bekende Zachman Framework, welke een excellent classificatie schema is, maar waarin een open beschikbare goed gedefinieerd methodologie ontbreekt.

De ADM bestaat uit de volgende fasen:

Alle fasen worden gedetailleerd uitgewerkt. Per fase wordt steeds het volgende aangegeven:

• Doelen
• Aanpak
• Rol van het raamwerk
• Input
• Output

Producten

TOGAF verzamelt producten onder de term Enterprise Continuum. Het Enterprise Continuum kan het beste gezien worden als een virtuele repository van alle architectuur goederen (assets, activa) modellen, patronen, architectuur beschrijvingen en andere artifacten - die zowel binnen de organisatie als binnen de IT industrie als geheel bestaan, welke de organisatie beschouwt beschikbaar te hebben voor de ontwikkeling van architecturen voor een organisatie.

Het Enterprise Continuum is een term die een combinatie van twee complementaire concepten aanduidt:

• Architecture Continuum  
  Het Architecture Continuum representeert een structurering van herbruikbare architectuur goeden. 
   
• Solutions Continuum.
  Het Solutions Continuum definieert wat beschikbaar is in de organisatie omgeving aan herbruikbare bouwstenen. De oplossingen zijn het resultaat van afspraken tussen klanten en business partners, die de regels en relaties in de architectuur ruimte implementeren. Het Solutions Continuum addressert de gemeenschappelijkheden en verschillen van de producten, systemen en services van geimplementeerde systemen.

Resource base

Verder kent TOGAF een zogenaamde Resource Base, een verzameling hulpmiddelen en technieken voor gebruik bij het toepassen van TOGAF en TOGAF ADM. De Resource base bevat onder andere:

• Architecture Board: Guidelines for establishing and operating an enterprise Architecture Board
• Architecture Compliance: Guidelines for ensuring project compliance to architecture
• Architecture Contracts: Guidelines for defining and using architecture contracts
• Architecture Governance: Framework and guidelines for Architecture Governance
• Architecture Maturity Models: Techniques for Evaluating and Quanifying an Organization's Maturity in Enterprise Architecture
• Architecture Patterns: Guidelines for using architectural patterns
• Architecture Principles: Principles for the use and deployment of IT resources across the enterprise
• Architecture Skills Framework: A set of role, skill and experience norms for staff undertaking Enterprise Architecture work
• Architecture Views: Guidelines for viewpoints and views in architecture models
• Building Blocks Example: A fictional example illustrating building blocks in architecture
• Business Process Domain Views: A set of function views aligned with the business process structure of the enterprise
• Business Scenarios: A method for deriving business requirements for architecture and the implied technical requirements
• Case Studies: Real-life examples of TOGAF in use
• Glossary: Definitions of key terms

TOGAF onderscheidt tenslotte de volgende standaard views:

• The Architecture Views en bijbehorende viewpoints;
• Business Architecture Views;
• Data Architecture Views;
• Applications Architecture Views;
• Technology Architecture Views.

Hulpmiddelen

TOGAF 8 Tool Support Product Standard

Inleiding

DYA staat voor dynamische architectuur. Het is een architectuur methode ontwikkeld door Iquip, dat later is overgenomen door Sogeti.
Er zijn een aantal boeken over DYA verschenen. Zie de boekenlijst.

Denkwijze

Definitie architectuur: (Wagter) Een consistent geheel van principes en modellen dat richting geeft aan ontwerp en realisatie van de processen, organisatorische inrichting, informatievoorziening en technische infrastructuur van een organisatie.

Uitgangspunten:

• Het architectuur proces is belangrijker dan de architectuur producten.
• Architectuur is een continu proces.
• Architectuur ondersteunt verandering.
• Afwijken van de architectuur mag, maar op een gecontroleerde wijze.

De 10 principes van DYA zijn:

1. Architectuur is strategisch als ICT dit is
2. Architectuur moet snelheid dienen
3. Communicatie tussen business- en ICT management staat centraal
4. Het ontwikkelen van architectuur wordt gestuurd door business doelen
5. Het architectuurniveau wordt verhoogd door mee te liften op de energiegolven van belangrijke verandertrajecten
6. Architectuur wordt ontwikkeld volgens het just enough, just in time principe
7. Een denk-/werkmodel ondersteunt het werken onder architectuur
8. Verbanden moeten inzichtelijk zijn
9. Er worden meerdere ontwikkelscenario�s onderscheiden
10. De architectuurprincipes en -processen moeten ingebed zijn in de organisatie

Bron: DYA: Snelheid en samenhang in business architectuur (Wagter e.a.).

Deze 10 principes zijn vertaald naar een denkmodel en een werkmodel. Binnen het denkmodel worden drie scenario's onderscheiden: anticiperend (onder architectuur), defensief en offensief (beide zonder architectuur).

Werkwijze

De kern van het DYA model wordt gevormd door vier processen die het hele traject van strategievorming tot realisatie van verandering beslaan:

• Strategische Dialoog
• Architectuur services
• Ontwikkelen onder architectuur
• Ontwikkelen zonder architect

Een traject start met een architectuur visie en plan van aanpak. Op basis van het architectuur raamwerk en DYA model kan vervolgens verdere invulling worden gegeven.

De 18 aandachtspunten van werken onder architectuur volgens DYA zijn:

• Opstellen van architectuur
• Gebruik van architectuur
• Afstemming met business
• Afstemming met ontwikkelproces
• Afstemming met beheer
• Relatie met bestaande situatie
• Verantwoordelijkheden en bevoegdheden
• Coordinatie van ontwikkelingen
• Bewaking
• Kwaliteitsmanagement
• Beheer architectuurproces
• Beheer architectuurproducten
• Commitment en motivatie
• Architectuurfuncties en -opleidingen
• Toepassingsgraad van architectuurmethode
• Overleg
• Architectuurtools
• Begroting en planning

Producten

Daar wordt in de boeken het volgende over gezegd:

Het DYA-model is ontstaan uit de praktijk. Het is gebaseerd op jarenlange ervaring met de praktijk van architectuurontwikkeling. In deze jaren is ons duidelijk geworden dat de bottleneck bij het succesvol van ICT niet zozeer gelegen is in dat we niet goed weten hoe we een goede architectuur moeten ontwerpen, maar in het feit dat architectuur onvoldoende verankerd is in de organisatie. Daarom worden in dit boek geen concrete architecturen besproken, noch wordt er ingegaan op de inhoudelijke stappen waarmee we tot een concrete architectuur zijn gekomen.

Inleiding

The Zachman Institute for Framework Advancement (ZIFA) is opgericht door John Zachman en Samuel Holcman eind jaren tachtig. Dit instituut is opgericht om het ZIFA enterprise framework en de ondersteuning aan de implementatie hiervan te verbeteren. Zelf omschrijven zij hun doelen als:
Establish the Zachman Framework as a universal "language" to facilitate communication, research, and implementation of Enterprise Architecture concepts. Achieve universal understanding and competence in every "community" to implement architectural concepts. These communities include the: Public Sector and Private Sector Technology Community, General Management, User Community Consumers (Enterprises) and Suppliers (Hardware/Software/Consulting Vendors) Academicians and Practitioners Maintain method and tool neutrality, focusing on integration and positioning, as opposed to competition and displacement.

Denkwijze

De Archimate website leert ons het volgende:

Inleiding

"Op dit moment is er geen goede beschrijvingswijze beschikbaar voor het weergeven van geintegreerde architecturen. Het ArchiMate-project wil zo'n architectuurtaal ontwikkelen voor het beschrijven van de verschillende architecturen in hun onderlinge samenhang. Maar een architect wil naast modellen ook andere zaken met elkaar in verband kunnen brengen, zoals bedrijfsdoelen, systeemeisen, principes en ontwerpbeslissingen. Ook die relaties moeten in een architectuurbeschrijving meegenomen kunnen worden. En verder is de koppeling met meer gedetailleerde ontwerpniveaus, bijvoorbeeld met softwaremodellen in UML of met bedrijfsprocesmodellen, een belangrijk aandachtspunt. Door tussen die beschrijvingen in de architectuur de relaties aan te geven (bijvoorbeeld hoe applicaties de bedrijfsprocessen ondersteunen), worden de deelarchitecturen aan elkaar gerelateerd en wordt indirect ook de koppeling tussen de onderliggende, meer gedetailleerde modellen gemaakt. De concepten voor het uitdrukken van zulke architectuurbeschrijvingen nemen een middenpositie in tussen enerzijds de meer gedetailleerde, op een specifiek gebiedgerichte technieken als UML, en anderzijds zeer algemene concepten als object en relatie.

Denkwijze

ArchiMate maakt gebruikt van de IEEE 1471-2000 definities. Daarnaast worden de termen Enterprise en Enterprise Architecture gebruikt:

• Enterprise: any collection of organisations that has a common set of goals and/or single bottom line.

• Enterprise architecture: a coherent whole of principles, methods, and models that are used in the design and realisation of an enterprise organisational structure, business processes, information systems, and infrastructure.

Architectuur bestaat uit een consistent geheel van principes, methoden en modellen voor het ontwerpen en realiseren van processen, informatievoorziening, technische infrastructuur en organisatorische inrichting. Binnen bedrijven komen verschillende architecturen voor. Elk architectuurgebied heeft zijn eigen concepten voor het modelleren en visualiseren van de samenhang. Echter, in elk architectuurgebied spreekt de architect zijn eigen taal, heeft zijn eigen beelden en gebruikt zijn eigen technieken en tools, waardoor veranderingen in andere gebieden niet zichtbaar worden. Discussies, communicatie en beslissingen over veranderingen die hun uitwerking hebben op meerdere terreinen worden hierdoor bemoeilijkt of zelfs onmogelijk.

Tegelijkertijd is het duidelijk dat er sterke afhankelijkheden bestaan tussen de domeinen. Voor een optimale communicatie tussen architecten en belanghebbenden is het noodzakelijk dat de relaties tussen de diverse domeinen inzichtelijk gemaakt kunnen worden. Vanuit deze optiek richt ArchiMate zich niet op ��n specifiek architectuurdomein maar op een overkoepelende architectuur waarmee organisaties, processen en informatievoorziening in samenhang in beeld gebracht kunnen worden: de enterprise architectuur.

Binnen ArchiMate worden de volgende architecturendomeinen en relaties daartussen onderscheiden:

Een belangrijke basis voor de ontwikkeling van een professionele gereedschapskist is een (modelleer)taal voor architectuur. Een taal voor enterprise-architectuurmodellering moet zich richten op inter-domein-relaties. Met een dergelijke taal moet het mogelijk zijn om:

• De globale structuur binnen een domein te modelleren.
• De relaties tussen de domeinen te modelleren.

Een andere belangrijke eigenschap voor de enterprise-modelleertaal is de mogelijkheid om modellen op verschillende manieren te visualiseren, gericht op verschillende belanghebbenden. Bovendien moet de taal een formele onderbouwing hebben zodat modellen geanalyseerd kunnen worden (bijvoorbeeld op een aspect als performance).

Omdat geen van de huidige modelleertalen voldoen aan de gestelde eisen en om het gesignaleerde vacuum op te vullen is ArchiMate ontwikkeld. Daarbij is het expliciet niet de bedoeling dat ArchiMate de bestaande talen zal vervangen; het vormt hierop een aanvulling, waarbij wel zo veel mogelijk aangesloten wordt op bestaande standaarden en praktijken.

In de ArchiMate-taal heeft het concept service een centrale rol. Een service definieren we als een eenheid van functionaliteit die een bepaalde actor (b.v. een systeem of een organisatie) beschikbaar stelt aan zijn omgeving. Service-orientatie sluit aan op trends als de service-gebaseerde netwerkeconomie en web services.

Service-orientatie is ook op natuurlijke wijze verbonden met een opdeling in lagen waarbij hogere lagen gebruik maken van services die beschikbaar worden gesteld door lagere lagen. ArchiMate onderscheidt de volgende drie lagen:

• Business laag

• Applicatielaag

• Technologielaag

Binnen de verschillende lagen worden de concepten verder uitgewerkt. Per laag zijn specifieke concepten ge�dentificeerd, maar de algemene structuur is per laag identiek.

De centrale structuur per laag ziet er als volgt uit:

Ten eerste wordt het structurele of statische aspect onderscheiden (de rechterkant van de figuur) en het gedragsaspect of dynamisch aspect (linkerkant van de figuur). Gedragsaspecten worden toegekend (assigned) aan structurele concepten om te laten zien wie of wat het gedrag uitvoert.

Ten tweede wordt onderscheid gemaakt tussen een extern gezichtspunt en een intern gezichtspunt op een organisatie of systeem. Het externe gezichtspunt wordt afgedekt door de service die te benaderen is via een interface. Voor het interne gezichtspunt wordt onderscheid gemaakt tussen gedrag dat wordt uitgevoerd door een individueel structureel element (b.v. actor, rol of component) en collectief gedrag (interactie) wat wordt uitgevoerd door een samenwerking (collaboration) van een aantal structurele elementen.

Naast de actieve structurele elementen worden ook de passieve structurele elementen onderkend: de objecten waar het gedrag op is gericht.

Producten

De kern van Archimate is een ontwerptaal waarmee organisaties en ICT in onderlinge samenhang af te beelden zijn. Archimate sluit hierbij aan op internationale standaarden zoals UML en MDA. Meer in het bijzonder omvat dit:

• Een generieke verzameling concepten en de notatie van deze concepten als visuele taal.

• Een precieze definitie van de semantiek (formele betekenis) van deze concepten, zodat helder is wat een model betekent.

• Een afbeelding van deze concepten naar talen als UML, BPMN en Testbed, om aan te sluiten op bestaande werkpraktijken.

• Ondersteuning van het ontwerpproces met algemene principes, richtlijnen en best practices."

Er wordt onderscheid gemaakt in symbolische en semantische modellen:

• Een symbolisch model drukt de eigenschappen van architectuur van systemen uit door middel van symbolen die refereren aan de realiteit.
• Een semantisch model is een interpretatie van een symbolisch model, uitgedrukt door middel van symbolen in dat model.

Verder wordt een raamwerk (framework) voor de definitie en classificatie van gezichtspunten (viewpoints) en beelden (views) gedefinieerd. Het raamwerk is gebaseerd op twee dimensies, doel en inhoud. De volgende drie typen architectuur ondersteuning definieren de doel dimensie van architectuur beelden: ontwerpen, beslissen, informeren. Voor de karaktiseristieken van de inhoud van een beeld worden de volgende abstractie niveaus gedefinieerd: details, samenhang, overzicht. Er worden voor gezichtspunten voorbeelden en richtlijnen voor het gebruik gegeven.

Werkwijze

Het architectuur proces zelf wordt niet echt uitgewerkt binnen ArchiMate. Wel worden richtlijnen gegeven voor het werken met modellen.
De volgende basis modellering activiteiten worden onderscheiden:

• Vaststellen van doel, werkingsgebied en nadruk
• Selecteren van een of meer gezichtspunten
• Maken en structureren van het model
• Visualiseren van het model
• Gebruik van het model
• Onderhouden van het model

Ook worden richtlijnen gegeven voor architectuur analyse.

Hulpmiddelen

Er komen software hulpmiddelen op de markt die ArchiMate ondersteunen. een daarvan is BizzDesign Architect:

BiZZdesign Architect kan uw organisatie helpen om deze architecturen inzichtelijk te maken. Deze tool is gericht op onder meer het vastleggen van architecturen en het visualiseren en analyseren van samenhang tussen architectuurdomeinen, impact of change analyses, etc. Ook is het mogelijk om de verschillende architectuurdomeinen op verschillende detailniveaus vast te leggen. Bron: http://www.bizzdesign.nl/html/bizzdesignarchitect.html  

Een andere software hulpmiddel dat ArchiMate ondersteunt is Metis van Troux Technologies.

Inleiding

xAF is een architectuur framework dat ontwikkeld is door een werkgroep met dezelfde naam. De werkgroep bestaat uit deelnemers van universiteiten, suppliers en appliers. een van de deelnemers is Jan Dietz.

De naam "xAF" is een afkorting van "Extensible Architecture Framework". Het idee voor het ontwikkelen van een extensible framework is ontstaan in de herfst van 2003 als een mogelijke en uitdagende manier om te voldoen aan de doelstellingen van het programma Generic Architecture Framework van het National Architecture Forum (NAF) in the Netherlands. Deze doelstelling is om een generiek architectuur raamwerk te ontwikkelen dat theoretisch solide en praktisch bruikbaar is. De specifieke eisen voor dit raamwerk zijn:

• Het raamwerk moet breed toepasbaar zijn, bijvoorbeeld binnen het gehele gebied van enterprise engineering (business definition, business system development, organisation development, ICT-applications development etc.).
• De concepten die binnen het raamwerk gebruikt worden moeten een een complete verzameling vormen, zo moeten ze een noodzakelijk en voldoend zijn voor het succesvol uitvoeren van enterprise engineering projecten.
• De definities van elk concept moet erg precies zijn, maar moet ook ruimte laten voor aanpassing binnen een bepaald sub gebied. Het raamwerk moet geen rigide standaard zijn.

Het basis idee van xAF is dat er een root uitbreidbaar raamwerk is (xAF0) en dat andere (ook weer uitbreidbare) raamwerken gedefinieerd kunnen worden als uitbreidingen hiervan. Het definieren van raamwerk xAFi als uitbreiding van een of meer bestaande xAFi's volgt strikte uitbreidingsregels. Twee regels zijn voorgesteld, welke voldoende lijken te zijn: De specialisatie regel en de integratie regel. Door het toepassen van deze regels wordt een rooster van xAFi's opgebouwd. Theoretisch is het mogelijk om elk bestaand architectuur raamwerk te herformuleren als een bepaalde xAFi in dit rooster. Dit maakt de xAF een universele basis voor evalueren en vergelijken van raamwerken. Maar het maakt xAF ook een methode voor het ontwikkelen van een eigen raamwerk op een wijze dat het ontwikkelde raamwerk aan hoge kwaliteitsstandaarden voldoet, en deze eenvoudig vergelijkbaar is met bestaande raamwerken.

Denkwijze

Binnen xAF is aan een uitgebreide definitie van het begrip ontwerpen gewerkt. In principe is het ontwerpproces generiek en niet beperkt tot een type systeem. Het kan derhalve worden gebruikt in de context van het ontwerpen van ieder doelsysteem (DS) dat gebruikt wordt door een gebruikend systeem (GS).

Het proces van systeemontwikkeling is uitgewerkt in een model waarin de definities van begrippen als eisen/wensen, specificaties, gebruikend systeem en doelsysteem en algemene principes voor het ontwerp zijn beschreven. De algemene principes zijn essentieel voor de transitie van eisen/wensen naar specificaties (het ontwerpen). Zij beperken de ontwerpvrijheid van de ontwerper door regels te stellen die bindend zijn. Principes worden gezien als een operationele concretisering van algemeen geldende eisen/wensen en specificaties. Voor een klasse van systemen wordt dus verbijzonderd. In de specificaties van het DS zullen deze principes verwerkt zijn. Het begrip architectuur staat binnen xAF voor de normatieve beperking van de ontwerpvrijheid.

De term architectuur kent twee interpretaties:

• De prescriptieve
• De descriptieve IT architectuur wordt binnen xAF in de prescriptieve zin uitgewerkt.

In het proces van systeemontwikkeling zoals in de context van xAF is gedefinieerd wordt architectuur gedefinieerd als:

• Architectuur is een normatieve beperking van de ontwerpvrijheid (conceptuele definitie);
• Architectuur is gespecificeerd in een set van ontwerpprincipes voor het te specificeren DS (operationele definitie)..

Een ontologisch model kan worden uitgelegd als een model van de, implementatie-onafhankelijke, essentie van een systeem (zowel GS als DS). Het is een geabstraheerd model van de essentiele werking en constructie van een systeem, volledig onafhankelijk van de realisatie, implementatie en gebruikte technologieen. Een ontologie wordt als een white box (WB) beschreven. Een ontologie kan in verschillende detailniveaus en vanuit verschillende aspecten zijn uitgewerkt. Een black box (BB) model heeft geen directe relatie met de constructie of werking van het te ontwerpen DS. Een BB model beschrijft de transformatie van invoervariabele naar uitvoervariabele.

Producten

Enkele xAF figuren:

Op basis hiervan is het SMART model ontwikkeld.

Inleiding

IAF staat voor Integrated Architecure Framework en is een methode die door Cap Gemini is ontwikkeld en wordt gebruik. Het raamwerk is oorspronkelijk afgeleid van Zachman, maar IAF omvat nu een uitgebreide bibliotheek van architectuur producten en best practices.

De rol van het IAF raamwerk Het IAF raamwerk is een communicatieraamwerk op basis waarvan met alle betrokkenen gecommuniceerd kan worden over de relaties tussen de aspectgebieden, de beschouwingniveaus en vanuit verschillende gezichtspunten. Op de kruispunten van deze relaties onderkennen we vervolgens de onderwerpen die van belang kunnen zijn tijdens een architectuurtraject. IAF als communicatieraamwerk verschaft zodoende inzicht in en overzicht over de samenhang tussen de verschillende aspectgebieden en de verschillende abstractieniveaus.

Denkwijze

Vanuit de noodzaak tot geintegreerde architecturen heeft Capgemini het Integrated Architecture Framework (IAF) ontwikkeld. IAF beschrijft hoe een architectuur voor verschillende aspectgebieden, vanuit verschillende gezichtspunten en op verschillende beschouwingsniveaus wordt opgebouwd.

Gezichtspunten
Er kan vanuit enkele andere gezichtspunten naar dit architectuurraamwerk worden gekeken. De belangrijkste gezichtspunten van waaruit altijd naar de eerder genoemde aspectgebieden wordt gekeken, is vanuit Beveiliging en Beheer. Beide vormen een vast onderdeel van de architectuurbenadering en beslaan de vier aspectgebieden in samenhang.

Abstractieniveaus
Bij een ge�ntegreerde architectuuraanpak moet men zich bewust zijn van de verschillende beschouwings- of abstractieniveaus waarlangs een architectuurbeschrijving tot stand komt. Binnen het IAF raamwerk worden de volgende niveaus onderscheiden:

Het contextuele niveau waarin de waarom vraag aan bod komt. Hierin worden missie, visie en strategie expliciet gemaakt en worden de strategische principes onderzocht. Het conceptuele niveau die zich bezig houdt met het wat. Welke doelstellingen zijn er en welke eisen gelden er voor elk van de aspectgebieden Het logische niveau waarin de structuur van de gewenste situatie wordt ontworpen. Hierin wordt de samenhang tussen de verschillende onderdelen gemaakt op basis van de eerder beschreven strategische principes Het fysieke niveau waarin wordt uitgewerkt hoe het logische niveau wordt vormgegeven in de werkelijkheid Het transformatie niveau waarin de benodigde verandering naar een toekomstige situatie wordt geschreven

Werkwijze

Cap Gemini Ernst & Young heeft ter ondersteuning van IAF een aantal architectuur ontwerp methoden (de architectural design-methoden) ontwikkeld op basis van enerzijds best practices en anderzijds wetenschappelijk onderzoek. Een van deze methoden (AD-TI) is door de IEEE tot standaard verheven (IEEE 1003.23).

Op het architectuur proces wordt minder de nadruk gelegd, maar IAF kan gecombineerd worden met andere methoden.

Buiten Cap Gemini is weinig informatie over IAF beschikbaar.

Het Extended Enterprise Architecture Framework is ontwikkeld door Jaap Schekkerman van het Institute for Enterprise Architecture Development. Het is productenmatrix die gezien kan worden als uitbreiding op de productenmatrices van Zachman en IAF.