Integrated Architecture Framework (IAF)

1 Introductie

Vanaf 1993 werkt Capgemini aan het Integrated Architecture Framework (IAF). Dit is een uitgebreide methode waarin de architectuurbenaderingen uit bedrijfsonderdelen van Capgemini in het Verenigd Koninkrijk, Frankrijk en Nederland zijn samengenomen en gebundeld. Grote klantorganisaties hadden de behoefte aan een herhaalbare en generieke architectuurbenadering en dit leidde tot de eerste versie van IAF. Sindsdien is IAF verder ontwikkeld en uitgebreid op basis van best practices die de Capgemini-architecten hebben opgedaan bij het toepassen van IAF in opdrachten, waarbij telkens zaken zijn aangepast en toegevoegd, zoals businessarchitectuur.

In 2001 werd versie 3 uitgebracht waarin business en informatie ruimer aandacht kregen en het serviceconcept breder werd toegepast. Deze versie diende als basis voor ‘eigen’ aanpakken en raamwerken van klanten in verschillende landen. In 2006 bracht Capgemini IAF versie 4.0 (intern) uit. Deze is voor het eerst voorzien van een metamodel met notatietaal. Dit metamodel is geïmplementeerd in de tooling van verschillende leveranciers.

In 2009 is besloten tot een beperkte upgrade voor IAF in de vorm van versie 4.5. Inmiddels propageert Capgemini open standaarden en daarmee ook TOGAF. Het beleid is om als lid van The Open Group delen van IAF te integreren in TOGAF.

Redenen voor het in stand houden van IAF als niet-open standaard zijn de vele klanten die het raamwerk hebben geadopteerd, het behouden van een ‘vehikel’ voor het verbeteren en testen van architectuurtools in eigen beheer, het beschermen van de kennis en kunde van de eigen architecten op dit gebied en het onderhouden van een communicatiemiddel voor Capgemini-architecten. In 2010 is de methode voor het eerst voor de buitenwereld beschreven in de vorm van een boek. Dit boek is gebaseerd op versie 4.5.

De definitie van architectuur

Het IAF-boek geeft geen expliciete definitie van architectuur. IAF wordt gekarakteriseerd als een constructiemethode. Uitgangspunt is dat alle constructiemethoden een vergelijkbare benadering hebben. Ze hanteren een vaste serie vragen die gekenmerkt wordt door de woorden waarom, wat, hoe, en waarmee. IAF kan daarmee worden gekarakteriseerd als een ‘design school’. Oorspronkelijk was het een ‘way of architecting’, nu is het vooral een ‘way of working’.

Als constructiearchitectuur worden alle vier hoofdtypen van architecturen ondersteund. IAF beschrijft deze als volgt:
1. Enterprise-architectuur, die met name planningsdoelen ondersteunt. Enterprisearchitecturen overspannen business units.
2. Domeinarchitectuur, die eveneens planningsdoelen dient, maar dan binnen een business unit.
3. Solutionarchitectuur, die ontwerp en realisatie van oplossingen ondersteunt voor veranderende bedrijfsprocessen, ondersteunende applicaties en infrastructuren.
4. Softwarearchitectuur, die richting geeft aan de juiste softwarepatterns, style guides en dergelijke.

2 Raamwerk

Het raamwerk van IAF kent drie dimensies: artefacten, aspectgebieden en iets wat zich het best laat omschrijven als thema’s. De artefacten worden gebruikt om de basisvragen – waarom, wat, hoe en waarmee – te beantwoorden. De aspectgebieden categoriseren de artefacten in lagen. De thema’s maken het mogelijk om specifieke onderwerpen holistisch te benaderen. Hieronder gaan we kort in op deze onderdelen van het raamwerk.

Artefacten

De basiselementen in IAF omvatten enkele artefacten.
• Architectuurprincipes geven de algemene uitgangspunten voor de gewenste architectuur en leggen uit waarom deze is zoals die is.
• Services vormen de bouwstenen voor de architectuur. Een service beschrijft een ‘element van gedrag’ of functie in de architectuur. Hierbij gaat om wat deze doet.
• Componenten zijn een set services die op basis van architectuurprincipes samenhangen. Met de wijze waarop IAF services en componenten hanteert, onderscheidt de methode zich in belangrijke mate van andere methoden.
• Collaboration contracts beschrijven de interactie tussen services en componenten. Deze bevatten de niet-functionele aspecten van de architectuur (hoe vaak, hoe snel, hoe veilig, hoe beheerd). Samen met componenten beschrijven ze hoe de architectuur samenhangt.
• Standaarden, richtlijnen en specificaties, die aangeven waarmee componenten moeten worden gerealiseerd.

Aspectgebieden

Een tweede dimensie binnen IAF vormen de aspectgebieden waarbij IAF onderscheid maakt tussen:
• Business, waarin het bedrijfsproces wordt beschreven in de termen van business services, businesscomponenten, business collaboration contracts en business SRG’s (standards, rules en guidelines)
• Informatie, waarin de informatiestromen die de bedrijfsprocessen ondersteunen worden beschreven in termen van information services, information components, information collaboration contracts en information SRG’s.
• Informatiesysteem, waarin de met IT te ondersteunen informatieservices, componenten, collaboration contracts en SRG’s worden beschreven.
• Technologische infrastructuur, waarin de systemen, netwerktechnologie en overige infrastructurele elementen worden beschreven in termen van infrastructuurservices gegroepeerd in infrastructuurcomponenten, collaboration contracts en SRG’s.

De waarom-vraag die de context beschrijft, geldt als algemene laag over alle aspectgebieden. De architectuurprincipes in deze laag geven de rationale achter de uitwerking van de aspectgebieden. Elk van de genoemde aspectgebieden heeft een fysiek realisatieniveau. Het is niet automatisch zo, dat een business- of informatiearchitectuur leidt tot een fysiek informatiesysteem of een tastbare technische infrastructuur.

Metamodel

De samenhang tussen de wat-, hoe- en waarmee-artefacten en de aspectgebieden wordt zichtbaar in het IAF-metamodel zoals weergegeven in figuur 1.

Figuur 1 IAF-metamodel.

Derde dimensie

Naast de vier hierboven beschreven dimensies van artefacten en aspectgebieden omvat IAF een derde dimensie. In deze dimensie worden beveiliging (security) en besturing (governance) geadresseerd. Door het holistisch, over alle aspectgebieden heen, adresseren van beveiliging wordt geborgd dat alle veiligheidsgerelateerde onderwerpen in samenhang aan bod komen. Met besturing worden de beheeraspecten bedoeld, en daartoe behoren ook aspecten als compliance en corporate governance. Hiermee ontstaat het volledige IAF-raamwerk dat is weergegeven in figuur 2.

3 Gebruik

Domeinen versus componenten

Een IAF enterprise-architectuur kent al snel enkele honderden services en componenten. Deze zijn vanwege hun abstractieniveau lastig tot niet communiceerbaar en

Figuur 2 Het volledige IAF-raamwerk.

visualiseerbaar. Daarom wordt in de communicatie met belanghebbenden gebruikgemaakt van herkenbare ‘business’-domeinen waarin services worden geordend.

IAF wordt typisch ingezet in business- en technologietransformaties. De methode geeft inhoud aan de architectuur doordat deze een strak aantal artefacten en de samenhang daartussen beschrijft. Daarmee wordt het architectuurproces herhaalbaar en leidt IAF – ook wanneer ze wordt uitgevoerd door verschillende architecten
– tot vergelijkbare resultaten.

Gebruik in samenhang met andere methoden

Voor de toepassing kan IAF als raamwerk worden gebruikt in samenhang met verschillende methoden, waarvan ADM  voor het architectuurproces de belangrijkste is. Ook wordt beschreven hoe IAF in combinatie met DYA kan worden gebruikt. DYA wordt dan ingezet om architectuur in te bedden in de organisatie en processen en om het architectuurteam en de architectuurbesturing in te richten, waarna IAF wordt gebruikt voor de constructie van de architectuurartefacten. Op deze wijze kan IAF volgens de auteurs ook worden gebruikt om structuur te geven aan, ofwel artefacten te leveren voor, methoden als Zachman en DEMO.

Daarnaast worden scenario’s beschreven waarin IAF kan worden ingezet in relatie tot iteratieve ontwikkelmethoden als RUP of in relatie tot lineaire (waterval) ontwikkelmethoden. Ook wordt aandacht besteed aan de relatie met standaarden als ITIL, COBIT, CMMI, PRINCE2 en MSP.

4 Positionering

In figuur 3 is de methode afgebeeld op het vergelijkingenmodel. De score op de verschillende wijzen wordt hierna toegelicht.

Figuur 3 IAF gepositioneerd op het vergelijkingsmodel.

Denkwijze

Het Integrated Architecture Framework kent een gelaagdheid waarmee abstractieniveaus worden onderkend op verschillende aspectgebieden van de organisatie. De expliciete aandacht voor beveiliging en besturing en services op de verschillende aspectgebieden zijn opvallend te noemen.

Beheer- en exploitatiewijze eigenaar

Kennis en ervaringen over IAF worden door Capgemini beschikbaar gesteld door middel van cursussen en events. Sinds 2009 is een boek beschikbaar waarin de methode uitgebreid wordt uitgelegd. De gebruikersgroep is primair een intern Capgeminigebeuren, maar er zijn ook externe architecten die kennis hebben van IAF. Gezien de doelstelling van het in stand houden van IAF als niet-open standaard is deze relatieve geslotenheid ook logisch. Er wordt regelmatig gewerkt aan nieuwe of herziene onderdelen, waarbij de continuïteit in het oog wordt gehouden

Beheer- en exploitatiewijze gebruiker

Doordat de methode een geïntegreerd geheel vormt, is de zelfstandige aanpasbaarheid van de methode beperkt. Capgemini waarschuwt voor het gevaar dat gebruikers de basale concepten en constructen niet begrijpen, waardoor aanpassing de toegevoegde waarde vermindert. Er is geen ruimte om wijzigingen in te laten brengen door gebruikers. Ook worden geen praktische tips gegeven voor het implementeren van de methoden in een organisatie.

Werkwijze

Hoewel de methode geen expliciet procesmodel kent, biedt Capgemini in haar opleidingen wel inzicht in hoe IAF in een zekere volgorde kan worden toegepast voor het opstellen van enterprise- en solution-architecturen. De leverancier wijst hier verder op de aanwezigheid van roadmaps die helpen bij het gebruik van de methode.

Capgemini noemt de combinatie met TOGAF als mogelijkheid, waarbij dan de architectuurontwikkelmethode van TOGAF (ADM) als werkwijze dient.

Representatie- en modelleerwijze

IAF kent een metamodel en een notatiewijze. Daarnaast kunnen andere modelleertechnieken worden gebruikt, zoals UML en ArchiMate. Een aantal kruisverbanden kan in matrices worden gepresenteerd.

Ondersteuningswijze

Door de introductie van een metamodel zijn er modelleeromgevingen die IAF ondersteunen, zoals Aris, BiZZdesign Architect en System Architect. Daarnaast beschikt de methode over een begrippenlijst en sjablonen voor op te leveren architectuurproducten.

Bruikbaarheid

IAF is sinds 1993 gebruikt in een zeer groot aantal projecten van Capgemini, aangepast aan verschillende volwassenheidsniveaus van de klantorganisatie. Hoeveel organisaties het zelfstandig inzetten is niet bekend. Er is een duidelijke aanpak: van links naar rechts en van boven naar beneden in het raamwerk, maar IAF is veelomvattend. Dit kan ertoe leiden dat men zich verliest in de methode en niet weet waar te beginnen. Het gesloten karakter van de methode, dat ervoor zorgt dat er weinig praktijkvoorbeelden openbaar beschikbaar zijn, is daarbij niet behulpzaam. De referentiemodellen, die geen formeel onderdeel van de methode vormen, kunnen helpen om een snelle start te maken. De methode is specifiek gericht op het maken van architectuurbeschrijvingen. Strategie en transitie van as-is naar to-be worden niet ondersteund en de communiceerbaarheid wordt niet bevorderd.

5 Conclusie

IAF biedt een raamwerkstructuur die ervoor zorgt dat genomen architectuurbeslissingen traceerbaar zijn. Het samen nemen of juist uit elkaar halen van stukken proces, informatie of applicatie, is altijd gebaseerd op een ‘requirement’ of principe uit een eerder genomen stap of gerelateerd veld. De aandacht voor services, die al vroeg in de methode bestond, is opvallend en maakt IAF potentieel geschikt voor het ontwerpen van informatiesystemen die bedrijfsprocessen optimaal ondersteunen op basis van een servicegeoriënteerde architectuurstijl. IAF kan worden toegepast op enterprise-, domein- of afdelingsniveau, maar ook op projecten of specifieke solutions. Voor IAF is ondersteuning beschikbaar in een aantal tools. Hoewel zaken als visievorming buiten IAF vallen, kan de brede scope van de aanpak overweldigend zijn voor organisaties en hen terughoudend maken om IAF te gebruiken.