Artikel

Het COmmon Reference Architecture model

Architectuur heeft zich ontwikkeld tot een belangrijk instrument om inzicht te verkrijgen in hoe geïntegreerde IT-landschappen met elkaar interacteren. Door het veelvoud aan architectuurmethoden is het echter lastig te bepalen welke aanpak je het beste kan volgen. Daarnaast ontstaat er een toenemende behoefte om met behulp van een lichtgewicht aanpak snel en eenvoudig IT-oplossingen te ontwerpen. Dit lijkt misschien een niet te overbruggen tegenstrijdigheid, maar misschien is er toch een manier om dit op eenvoudige wijze mogelijk te maken. In dit artikel wordt daarom een praktische handleiding gepresenteerd voor het gebruik van een gemeenschappelijke referentiearchitectuur om geïntegreerde IT-oplossingen met succes te ontwerpen en te ontwikkelen.

Veranderende behoeften vanuit de business hebben meer en meer invloed op de manier waarop organisaties hun IT-landschap moeten beheersen. Door de jaren heen heeft het IT-landschap binnen organisaties (“On Premise”) zich ontwikkeld tot een groot aantal Legacy, maatwerk en ERP systemen van verschillende softwareleveranciers. Al deze verschillende toepassingen zijn in de eerste plaats ontstaan om aan de “lokale” business behoeftes te voldoen en zijn bijna altijd uitgevoerd met behulp van leveranciersspecifieke referentiearchitecturen.

Gelijktijdig neemt de complexiteit van het IT-landschap toe door het opnemen van ‘loose coupled” services van externe partijen in de enterprise architectuur van ‘thight coupled’ applicaties en diensten. Last but not least krijgen organisaties met de komst van Cloud Computing niet alleen de mogelijkheid om (delen van) hun “On Premise” IT te outsourcen, maar ook om deze “On Demand” uit te besteden. Dit alles heeft een groot effect op de architectuur en governance van het interne IT-landschap omdat moet worden omgegaan met zowel interne als grensoverschrijdende datastromen.

Er zijn uitstekende architectuur en implementatie modellen/methoden beschikbaar om deze complexiteit inzichtelijk te maken en te beheersen. Vaak is echter het resultaat dat bij toepassing ervan een onterecht gevoel van veiligheid en controle wordt gecreëerd die verdampt bij de volgende overschrijding van project- en IT-budgetten.

Dit is voornamelijk te wijten aan het feit dat:

  • er een kloof bestaat tussen architectuur en implementatie (= Solution Design);
  • de huidige architectuurmodellen gericht zijn op de referentiearchitecturen van één leverancier en/of één architectuurstijl;
  • de noodzakelijke nieuwe en verschillende manieren van het verzamelen van requirements vaak over het hoofd worden gezien of genegeerd.

Om deze problemen het hoofd te bieden is het Common Reference Architecture (CORA)-model ontwikkeld.

Wat is het CORA-model?

Het CORA-model (zie figuur 1) is een bibliotheek van alle mogelijke (vendor agnostische) elementen die onderdeel uit kunnen maken van een IT-landschap. Hoe elementen zich tot elkaar verhouden en welke elementen er daadwerkelijk zijn of zullen worden gebruikt hangt af van het huidige (en toekomstige) IT-landschap, de voorgestelde oplossing en de toepassing van architectuurstijl(en) (N-tier, Service Oriented en/of Resource Oriented).

Op deze manier kan zowel een bestaand IT-landschap, alsmede nieuwe IT-oplossingen gemapped worden op het model en vervolgens worden beoordeeld (zijn er bijvoorbeeld elementen ‘vergeten’ of zijn er overlappende leveranciersoplossingen).

Figuur 1: CORA-model

Basis voor het CORA-model

Het CORA-model is gebaseerd op bestaande theoretische modellen (Ross, Crown), normen (TOGAF III-RM, IAF), methodieken (RUP/Agile) en referentiearchitecturen van leveranciers. Vijf van deze referentiearchitecturen zijn toe nu toe gerelateerd aan CORA (SAP, Oracle, Microsoft, Intel, IBM/Open Group).

De eisen ten aanzien van het CORA-model zijn gebaseerd op zes basisprincipes.

Principe 1: CORA is ‘vendor-agnostic’. Veel leveranciers leveren referentiearchitecturen die zijn gebaseerd op hun eigen oplossingen en/of platforms. Dit impliceert dat CORA moet worden beschreven in logische termen. Met het mappen van een leveranciers-architectuur op het CORA-model wordt inzichtelijk hoe een leveranciers-architectuur zich verhoudt tot het IT-landschap van een organisatie.

Principe 2: CORA is een gelaagde architectuur. Een gelaagde architectuur is één van de meest voorkomende technieken om complexiteit inzichtelijk te maken met betrekking tot de scheiding van verantwoordelijkheden, ontkoppeling, herbruikbaarheid en vervangbaarheid van elementen. Wanneer een IT-landschap bestaat uit multi-leverancier en multi-technologie elementen, maakt een gelaagde architectuur vergelijkingen tussen deze elementen veel eenvoudiger.

Principe 3: CORA beschrijft elementen die onderdeel uit kunnen maken van een IT-landschap. CORA moet de mogelijkheid bieden om te worden gebruikt als een component model om de keuze van een element afhankelijk van de situatie en architectuurstijl mogelijk te maken. De nadruk moet liggen op het bepalen van de gevolgen bij het toevoegen of verwijderen van elementen en lagen.

Principe 4: CORA maakt gebruik van een ‘relaxte’ gelaagdheid. Ongeacht de architectuurstijl moeten alle logische elementen kunnen worden geclusterd op basis van hun rol. In een zuiver gelaagde hiërarchie, waarbij elke laag alleen communiceert met aangrenzende bovenste en onderste lagen, is dit niet mogelijk.

Principe 5: CORA kan worden toegepast op zowel Enterprise niveau (Enterprise Architecture) als project of programma-niveau (Solution Architecture). In de praktijk zien we dat er een kloof bestaat tussen deze twee niveaus.

Principe 6: CORA is makkelijk te begrijpen. Elke laag en de elementen binnen een laag moeten gemakkelijk zijn te begrijpen.

Gebruik van het CORA-model

Het CORA-model kan bijvoorbeeld voor de volgende doeleinden gebruikt worden:

  • Afleiding van de impact van nieuwe IT-ontwikkelingen, zoals cloud computing;
  • Optimale IT-oplossingen vormgeven, omdat CORA zich richt op hybride en cross-technologie omgevingen;
  • Platform decompositie: in kaart brengen van ERP op CORA om de gekochte functionaliteit te kunnen beoordelen;
  • Landschap harmonisatie: mapping-functionaliteit op logische elementen afbeelden en eventuele overlap te beoordelen.

Om het gebruik van het CORA-model te ondersteunen is de ‘CORA Methodology’ ontwikkeld, waarin de belangrijkste stappen om te komen tot herhaalbare, voorspelbare en ‘risk-aware’ IT-oplossingen zijn beschreven.

Figuur 2: CORA methodology

Voor het vaststellen van IT-oplossingen dienen architectuur (principes en stijlen), requirements (zowel functionele als niet-functionele) en een AS-IS beschrijving van het IT-landschap als input. Met deze input als basis kunnen de activiteiten binnen de methodologie worden uitgevoerd. Deze reeks activiteiten start met het maken van een logische beschrijving van de IT-oplossing(en) met daarop volgend een vertaling naar concrete technologie componenten (incl. onderlinge relaties). Op basis van de CORA interactie-patronen (bijvoorbeeld patronen voor BPM, Beveiliging, Opslag, etc.) kan de geschetste oplossing worden beoordeeld en kunnen ontwerprichtlijnen worden afgeleid. De output van deze activiteiten bestaat uit een grondig geëvalueerde IT-oplossing en een set ontwerprichtlijnen. Daarnaast kunnen de (voor de oplossing relevante) CORA interactie-patronen dienen als basis voor de planning en QA.

In de praktijk blijkt deze combinatie van output-producten als zeer waardevol te worden ervaren, omdat hiermee in een vroeg stadium veel inzicht wordt verkregen in de inhoud van de IT-oplossing(en) waardoor planningen veel beter kunnen worden onderbouwd.

Op www.coramodel.com is uitgebreide informatie te vinden over het model, de methodologie en de relatie met diverse architectuurraamwerken.

Categorie:   
Auteur(s)
afbeelding van theoelzinga
Theo Elzinga
Capgemini - IT Architect

Theo Elzinga is als IT Architect werkzaam bij Capgemini en mede-auteur van het CORA-model.

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.