WHITE PAPER DYA : IMPLEMENTATIEAANPAK VOOR TOGAF

WHITE PAPER

DYA®: IMPLEMENTATIEAANPAK VOOR TOGAF™

Martin van den Berg Jan Willem Dijkstra Gé Schellen Renzo Wouters

WHITE PAPER DYA®: IMPLEMENTATIEAANPAK VOOR TOGAF™

Martin van den Berg Jan Willem Dijkstra Gé Schellen Renzo Wouters

Versie: 2.0 juli 2009

Copyright Sogeti Nederland B.V. © te Vianen Niets uit deze uitgave mag worden verveelvoudigd (voor willekeurig welke doeleinden) door middel van druk, fotokopie, microfilm, geluidsband, elektronisch of op welke andere wijze dan ook zonder voorafgaande schriftelijke toestemming van Sogeti Nederland B.V.

Sogeti Nederland B.V. juli 2009

2.0

I

White paper: DYA®: implementatieaanpak voor TOGAF™

Inhoudsopgave 1

INTRODUCTIE .......................................................................... 1

2

VERGELIJKINGSMODEL ............................................................... 2

3

ARCHITECTUUR MET TOGAF™ EN DYA® ............................................ 7

4

3.1

TOGAF™........................................................................................... 7

3.2

DYA® .............................................................................................12

VERGELIJKINGSRESULTATEN ....................................................... 22 4.1

TOGAF ...........................................................................................22

4.2

DYA ...............................................................................................25

4.3

Mapping op vergelijkingsmodel ..............................................................28

5

CONCLUSIE............................................................................ 30

6

OVER DE AUTEURS ................................................................... 31

7

REFERENTIES ......................................................................... 32


2.0

III

White paper: DYA®: implementatieaanpak voor TOGAF™ Introductie

1

INTRODUCTIE

Hoe gaat Sogeti nu verder met DYA®? Dat is een vraag die wij als architecten van Sogeti vaak te horen krijgen, mede naar aanleiding van de opkomst van TOGAF™ maar ook het ontstaan van aanvullingen op DYA zoals DYA|Infrastructuur. In een eerdere versie van dit White Paper[4.] hebben we daarom DYA en TOGAF 8 naast elkaar gelegd en vergeleken. De conclusie toen was dat DYA en TOGAF prima naast elkaar gebruikt kunnen worden. Inmiddels is TOGAF 9 verschenen en hebben de losse onderdelen van DYA een plek gekregen in DYA|Suite. Daarnaast zijn de inzichten aangescherpt over wat belangrijk is voor het ontwikkelen van een enterprise-architectuurfunctie in een organisatie [5.][9.]. TOGAF 9 is zo groot dat het niet lukt om alles in één keer in te voeren. Tijd dus om de balans opnieuw op te maken en DYA en TOGAF te vergelijken, maar nu in het perspectief van een enterprise-architectuurfunctie in een organisatie. Organisaties die overwegen TOGAF als architectuuraanpak te implementeren, lopen vaak tegen de vraag aan hoe dit voor elkaar te krijgen. TOGAF zelf biedt daar namelijk slechts in beperkte mate hulp. De kunst is om TOGAF gefaseerd in te voeren. DYA biedt hierbij soelaas. Voor organisaties die aan de slag willen met architectuur of die hun architectuur verder willen professionaliseren, is DYA een prima implementatieaanpak. TOGAF is als open standaard dan een prima aanpak voor het ontwikkelen van de inhoud van architectuur. In dit paper wordt allereerst in hoofdstuk 2 een model gepresenteerd dat de elementen bevat die nodig zijn bij het inrichten van een enterprise-architectuurfunctie in een organisatie. Vervolgens wordt in hoofdstuk 3 ingegaan op de essentie van TOGAF uitgaande van TOGAF 9 en DYA op basis van DYA|Suite. In hoofdstuk 4 worden TOGAF 9 en DYA|Suite op het in hoofdstuk 2 besproken model geplot. Tot slot worden in hoofdstuk 5 conclusies getrokken. In dit paper verstaan we onder enterprise-architectuur de architectuur voor de volle breedte van een organisatie, dus zowel business, informatie als ICT.


2.0

1

White paper: DYA®: implementatieaanpak voor TOGAF™ Vergelijkingsmodel

2

VERGELIJKINGSMODEL

TOGAF en DYA zijn beide aanpakken voor enterprise-architectuur. De vraag die we ons gesteld hebben is: “In hoeverre ondersteunen beide aanpakken bij het inrichten en professionaliseren van een enterprise-architectuurfunctie?”. Voor het vergelijken van beide is een metamodel nodig. Zo’n metamodel, dat alle elementen in zich heeft van een enterprise-architectuurfunctie is echter niet beschikbaar. Forrester constateert bijvoorbeeld dat er geen universele standaard is voor enterprise-architectuur [7.] en [8.]. IEEE 1471 heeft wel een metamodel voor architectuur [11.], maar dat betreft alleen de inhoudelijke dimensie. Omdat er geen model bestaat dat alle dimensies van een enterprise-architectuurfunctie beschrijft, hebben we zelf zo’n model ontwikkeld. De elementen van een enterprise-architectuurfunctie zijn te vatten in twee dimensies. Dimensie 1: Reikwijdte van de architectuurfunctie Hierbij gaat over het de 3 P’s: Proces, Product en Persoon en daarnaast over Visie en Plan om tot een goed werkende architectuurfunctie te komen. In welke mate besteedt de architectuuraanpak aandacht aan al deze elementen van werken onder architectuur? Hiernaast zijn deze 5 elementen schematisch weergegeven. Dimensie 2: Uit te voeren activiteiten als onderdeel van de architectuurfunctie Dit betreft de activiteiten: Inrichten, Ontwikkelen, Gebruiken en Besturen van Proces, Product en Persoon. Met andere woorden: in welke mate gaat de architectuuraanpak in op de activiteiten die nodig zijn om de elementen van een architectuurfunctie in te richten, te ontwikkelen, te gebruiken en te besturen? Deze twee dimensies zijn uitgezet in figuur 1. Op deze manier ontstaan veertien aandachtsgebieden waarop TOGAF 9 en DYA|Suite met elkaar vergeleken worden.

Figuur 1 Vergelijkingsmodel architectuurmethoden


2.0

2


In het vervolg van deze White Paper worden TOGAF en DYA beoordeeld aan de hand van de veertien aandachtsgebieden. Deze gebieden worden verderop beschreven. Telkens wordt de vraag gesteld in hoeverre de methode dat gebied afdekt. Daarbij is een onderverdeling gemaakt naar: • Compleet; • Goed; • Redelijk; • Beperkt; • Niet. Daarnaast wordt voor ieder aandachtsgebied aangegeven in hoeverre de methode hulpmiddelen ((meta)modellen, procedures, templates, best practices en voorbeelden) biedt. Voor de vergelijking is uitgegaan van TOGAF versie 9, beschreven in [19.].

Figuur 2 DYA|Suite

Voor wat betreft DYA is uitgegaan van DYA|Suite. DYA|Suite bevat de kern van DYA (DYA|Werken onder Architectuur) en aanvullingen die passen bij DYA, maar ook afzonderlijk gebruikt kunnen worden. Omdat DYA|Suite geen formele versienummers is uitgegaan is van de volgende boekpublicaties: • DYA|Werken Onder Architectuur [20.], [1.], [2.]. • DYA|Governance [16.] • DYA|Principes [6.] • DYA|Software (verschijnt in 2010) • DYA|Infrastructuur [12.]


2.0

3


De 14 aandachtsgebieden uit het vergelijkingsmodel gedefinieerd: Hieronder worden alle aandachtsgebieden nader toegelicht.

Figuur 3 Vergelijkingsmodel

Visie Definiëren van een visie op (gebruik van) architectuur. Dit aandachtsgebied geeft aan wat de organisatie met architectuur wil bereiken en vormt een belangrijke leidraad voor de vele beslissingen en keuzes die gemaakt moeten worden bij het inrichten van de architectuurfunctie. De aanleiding waarom we met architectuur gaan werken, het doel wat we ermee willen bereiken, wat we onder architectuur verstaan, wat architectuur de organisatie oplevert en hoe we de architectuurfunctie organiseren. Procesinrichting Inrichting van het architectuurproces in een organisatie. Dit aandachtsgebied geeft aan welke processen in een organisatie ingericht moeten zijn om ‘werken onder architectuur’ succesvol te laten functioneren. Onder dit aandachtsgebied wordt ook de manier verstaan waarop architectuur binnen een organisatie het beste geïmplementeerd kan worden, rekening houdend met de volwassenheid van de organisatie. Ontwikkeling en onderhoud Het proces van ontwikkelen en onderhouden van architectuurproducten. Dit aandachtsgebied gaat over de processen die onderkend worden voor de ontwikkeling en onderhoud van architectuur. Het gaat om de manier waarop de methode voorschrijft hoe een architectuur(product) opgesteld en onderhouden moet worden.


2.0

4


Gebruik Het proces van het gebruik van architectuur bij het faciliteren van veranderingen en het ontwikkelen en beheren van oplossingen. Als een architectuur eenmaal opgesteld is, dan moet er ook mee gewerkt kunnen worden. Dit aandachtsgebied draait om de vraag op welke manier architectuur gebruikt wordt in het faciliteren en het ontwikkelen en beheren van nieuwe mogelijkheden en oplossingen voor de organisatie. Architectuurgovernance De besturing en bewaking van de inrichting van de architectuurprocessen in de organisatie. Tijdens de inrichting van de architectuurprocessen is verondersteld dat architectuur bijdraagt aan het succes van de organisatie. Dit aandachtsgebied draait om de vraag of dit ook daadwerkelijk het geval is. Het aandachtsgebied gaat dus na in hoeverre de methode aandacht schenkt aan het controleren of ‘werken onder architectuur’ daadwerkelijk zijn vruchten afwerpt (rendement levert). Raamwerk De indeling en ordening van de architectuur in deelgebieden / domeinen. Architectuurproducten worden veelal ingedeeld in een ordeningsstructuur/raamwerk. Dit aandachtsgebied gaat over de manier waarop de methode aangeeft hoe de architectuurproducten geordend kunnen worden in deelgebieden of domeinen. Artefact De individuele architectuurproducten / architectuurbeschrijvingen waarmee het raamwerk gevuld wordt, binnen één deelgebied / domein van het raamwerk. Dit aandachtsgebied gaat over de architectuurproducten zelf. Het zijn de producten die een architect maakt en kan positioneren in het raamwerk. Een artefact past binnen een domein en is daarmee eendimensionaal. View De representatie / visualisatie van de architectuur vanuit het gezichtspunt van een belanghebbende. Om architectuur toe te kunnen passen, moeten de artefacten zodanig worden gepresenteerd, dat het voor een belanghebbende duidelijk wordt wat de opgestelde architectuur betekent voor de nieuwe ontwikkeling of verandering die geïmplementeerd moet worden. Een view is daarom veelal meerdimensionaal. Architectuurmanagement Instrumenten om de kwaliteit van de architectuurproducten in de organisatie te bewaken en te sturen. Dit aandachtsgebied betreft de instrumenten die ingezet worden om sturing te kunnen geven aan een samenhangende inrichting van de organisatie. Denk aan KPI’s waarmee kan worden aangetoond dat de opgestelde architectuurproducten een bijdrage leveren aan de doelstellingen van de organisatie. Dat wil zeggen: hoe wordt gemeten wat het rendement van architectuurproducten is? Ook versiebeheer speelt hierbij een rol om de architectuur actueel te houden.


2.0

5


Organisatie en rollen De plaats van de architectuurfunctie binnen de organisatie. Dit aandachtsgebied gaat over de plaats van de architectuurfunctie binnen de organisatie die werkt onder architectuur. Het gaat dan over de organisatorische ophanging van de architectuurfunctie en de rollen, taken en bevoegdheden. Dit aandachtsgebied besteedt ook aandacht aan het meten van de volwassenheid van de architectuurfunctie. Opleiding en coaching De ontwikkeling van de architectuurfunctie door middel van opleiding, coaching en certificering. Dit aandachtsgebied gaat over het ontwikkelen van de architect zelf, door het aanbieden van opleidingen, coaching en certificering. De vraag is in hoeverre de methode hiervoor uitgerust is. Competentie De benodigde vaardigheden van een architect. Dit aandachtsgebied gaat over de vaardigheden waarover een architect moet beschikken om blijvend een goede architect te kunnen zijn. HR-management Het management van de ontwikkeling van de architectuurfunctie op het gebied van Human Resources. Dit aandachtsgebied gaat over het managen van de verbetering van de persoon, de architect zelf: het HR-management. Ook wel de Plan/Do/Check/Act-cyclus van de persoonlijke ontwikkeling van de architect/de architectuurfunctie binnen een organisatie. Plan Het planmatig verbeteren van het werken onder architectuur binnen een organisatie. Dit aandachtsgebied geeft aan welke architecturen er nodig zijn, waar de sterke en zwakke kanten liggen bij werken onder architectuur en hoe de rol van architectuur moet worden ingevuld in een veranderstrategie en daarop gebaseerde actieplannen.


2.0

6

White paper: DYA®: implementatieaanpak voor TOGAF™ Architectuur met TOGAF™ en DYA®

3

ARCHITECTUUR MET TOGAF™ EN DYA®

3.1

TOGAF™

The Open Group Architectural Framework (TOGAF) is in 1995 ontwikkeld door The Open Group. The Open Group is een consortium van samenwerkende bedrijven (leveranciers en gebruikers) en wetenschappelijke instellingen. De groep is leveranciersonafhankelijk en heeft als visie het bevorderen van de ‘Boundaryless Information Flow’. TOGAF is geïnitieerd om bij te dragen aan het realiseren van deze visie. Oorspronkelijk beperkte TOGAF zich tot het ontwikkelen van de technische architectuur (tot en met versie 7). Vanaf versie 8 richt TOGAF zich op het ontwikkelen van een Enterprise-architectuur, gericht op het realiseren van ICT-oplossingen: de Business, Data, Applications en Technical Architectures [19.]. De Business Architectuur wordt slechts opgesteld om daarmee de requirements te kunnen vaststellen voor de ICToplossing. In februari 2009 is een nieuwe versie van TOGAF uitgebracht: TOGAF 9. Ook TOGAF 9 is bedoeld voor het ontwikkelen van enterprise-brede IT-architecturen. De Business Architectuur wordt opgesteld om de requirements vast te kunnen stellen voor het ontwikkelen van de IT-architectuur.

Figuur 4 TOGAF 9 Overview


2.0

7


TOGAF 9 bestaat – naast een algemene inleiding - uit de volgende onderdelen (Parts): 1. Architecture Development Method (Part II) Centraal in TOGAF staat de Architecture Development Method (ADM), een iteratieve ontwikkelcyclus voor het ontwikkelen van een Enterprise-architectuur. 2. ADM Guidelines and Techniques (Part III) Een set van richtlijnen en technieken die het gebruik van de ADM ondersteunen. 3. Architecture Content Framework (Part IV) In de ADM wordt inhoud geproduceerd. Het Architecture Content Framework biedt een model voor welke architectuurproducten geproduceerd kunnen worden. 4. Enterprise Continuum (Part V) Het Enterprise Continuum is een virtuele bibliotheek waarin de architectuurproducten kunnen worden geplaatst. Het bestaat uit een classificatie van de verschillende architecturen en oplossingen. 5. TOGAF Reference Models (Part VI) TOGAF biedt twee referentie modellen als startpunt voor de vulling van het Enterprise Continuum van een organisatie. 6. Architecture Capability Framework (Part VII) De ADM wordt uitgevoerd door de ‘Architecture Capability’. Het Architecture Framework biedt hulpmiddelen voor het inrichten van de architectuurfunctie (de ‘Architecture Capability’) binnen een organisatie.

Part II - Architecture Development Method Centraal in TOGAF staat de ontwikkelcyclus van architectuur (ADM). Deze ontwikkelcyclus bestaat uit acht fasen, die iteratief achter elkaar worden afgehandeld. Iteratief betekent hier dat er voorafgaand aan het doorlopen van elke nieuwe cyclus bepaald moet worden wat de vereiste diepgang en scope is, passend bij de situatie waarin de organisatie zich op dat moment bevindt. Voorafgaand aan de eerste iteratie, doorloopt men een voorbereidende fase: de Preliminary Phase. Deze fase definieert hoe de organisatie aan architectuur wil doen. Het draait dan om het bepalen welk raamwerk gehanteerd gaat worden en welke architectuurprincipes gelden.

Als deze fase is afgesloten, kan de eigenlijke cyclus van start gaan. De cyclus bestaat grofweg uit vier delen. Als eerste wordt de Figuur 5 Ontwikkelcyclus van architectuur scope van de te ontwikkelen architectuur bepaald en wordt een globale (baseline) architectuur ontwikkeld (fase A). Het tweede deel betreft de daadwerkelijke ontwikkeling van architectuur (fasen B, C en D). Hierbij Sogeti Nederland B.V. juli 2009

2.0

8


wordt voor elk van de afzonderlijke domeinen, zowel de huidige als de toekomstige architectuur beschreven. Na het opstellen van de architectuur worden als derde onderdeel de mogelijkheden om de ‘gap’ tussen de huidige en de toekomstige situatie te overbruggen vastgesteld en worden projecten gepland en opgestart om die ‘gap’ te dichten (fase E, F en G). In de laatste fase (fase H) wordt een proces ingericht om alle nieuwe ontwikkelingen vanuit de business en de technologie die invloed hebben op de architectuur in de gaten te houden. Op grond hiervan kunnen beslissingen genomen worden om een nieuwe cyclus voor onderhoud of herontwerp van de architectuur te starten. Centraal in de ontwikkelcyclus staat het Requirements Management proces. Dit proces moet ervoor zorgen dat alle vereisten voor de enterprise-architectuur geïdentificeerd, vastgelegd en ter beschikking gesteld worden aan elke fase van de ontwikkelcyclus. Part III – ADM Guidelines and Techniques TOGAF biedt in een apart deel (ADM Guidelines and Techniques) een aantal hulpmiddelen ter ondersteuning van de ADM. Deze bestaan enerzijds uit verschillende scenario’s voor het gebruiken van de ADM, zoals aanwijzingen voor iteratie binnen de ADM-cyclus, het gebruik van de ADM voor security architecturen en SOA. Anderzijds wordt in dit deel een groot aantal technieken besproken die gebruikt kunnen worden in verschillende fasen van de ADM, zoals het definiëren van architectuurprincipes, business scenario’s en het uitvoeren van een gap analyse, migratieplanning en risicomanagement. Part IV – Architecture Content Framework In TOGAF 9 is een volledig nieuw onderdeel toegevoegd: het Architecture Content Framework.


2.0

9


Figuur 6 Architecture Content Framework

Het Architecture Content Framework (content metamodel) biedt een definitie van alle soorten bouwblokken die kunnen bestaan binnen een architectuur. Het maakt duidelijk hoe deze bouwblokken beschreven kunnen worden en hoe ze in relatie staan tot elkaar. Bijvoorbeeld, een architect onderscheidt bij het opstellen van een architectuur verschillende applicaties, dataobjecten die binnen deze applicaties bewerkt worden en technologieën die deze applicaties implementeren. Deze applicaties zullen op hun beurt bepaalde groepen van gebruikers of actoren ondersteunen en zullen gebruikt worden om bepaalde ‘business services’ te leveren. Het content metamodel identificeert al deze concerns (bijv. applicaties, dataobjecten, technologieën, actoren en business services) en toont de mogelijke relaties ertussen (bijv. actoren consumeren business services). Als laatste geeft het metamodel aan welke artefacten gebruikt kunnen worden om de concerns weer te geven. Het metamodel kent een indeling die overeenkomt met de fasering binnen de ADM: 1. Architecture Principles, Visions and Requirements (Preliminary Phase, Phase A en Requirements Management) 2. Business Architecture (Phase B) 3. Information Systems Architecture (Phase C) 4. Technology Architecture (Phase D) 5. Architecture Realization (Phase E, F, G)


2.0

10


Part V – Enterprise Continuum Het Enterprise Continuum is een ‘virtuele repository’ van alle architectuurassets binnen en buiten de organisatie waarvan de organisatie vindt dat die van belang zijn voor het ontwikkelen van architectuur. Het gaat dan om modellen, patronen, architectuurbeschrijvingen en andere assets die ontwikkeld zijn in een eerdere fase van een architectuurontwikkeling, maar ook om meer generieke architectuurassets die in de branche waarin de organisatie zich bevindt, gebruikelijk zijn. Het Enterprise Continuum kent twee onderdelen: het Architecture Continuum en het Solutions Continuum, ieder weer onderverdeeld in vier deelgebieden. Elk deelgebied kent een eigen scope, die steeds specifieker wordt voor de organisatie.

Figuur 7 Enterprise Continuum

Het Architecture Continuum biedt een consistente manier om de algemene regels, de representaties en relaties van een (informatie) systeem te definiëren en begrijpelijk te maken. Het Architecture Continuum beslaat een continuum van meer generieke architecturen (Foundation Architectures), via Common Systems Architectures en Industry Architectures naar specifieke architecturen voor de organisatie (Enterprise Architectures). Het Solutions Continuum biedt een consistente manier om de implementatie van hetgeen in het Architecture Continuum vastligt te definiëren en begrijpelijk te maken. Het Architecture Continuum geeft richting aan het Solutions Continuum, het Solutions Continuum ondersteunt het Architecture Continuum. Het Solutions Continuum loopt ook hier van generieke oplossingen (Foundation Solutions), via Common Systems Solutions en Industry Solutions naar de specifieke (maatwerk) oplossingen voor de organisatie (Organization Solutions). Part VI – TOGAF Reference Models TOGAF biedt zelf een tweetal referentiemodellen: Een Foundation Architecture (het Technical Reference Model) en een Common Systems Architecture (het Integrated Information Infrastructure Reference Model). Deze zijn te vinden in een apart deel: TOGAF Reference Models.


2.0

11


Part VII – Architecture Capability Framework Het Architecture Capability Framework is een verzameling van hulpmiddelen, richtlijnen, templates en andere aanwijzingen voor het inrichten van de architectuurfunctie binnen een organisatie.

Figuur 8 Architecture Capability Framework

In dit deel wordt besproken hoe de ‘Architecture Capability’ ingericht kan worden. Het inrichten van een ‘capability’ binnen een organisatie vereist het inrichten van de vier domeinarchitecturen: Business, Data, Applications en Technology Architecture. Dit geldt dus ook voor het inrichten van de Architecture Capability. De ADM kan ook voor het inrichten van de architectuurfunctie binnen een organisatie worden gebruikt. Daarnaast worden aanwijzingen gegeven voor het opzetten van Architecture Governance, een Architecture Board en een proces voor Architecture Compliance. Ten slotte maakt het Architecture Skills Framework onderdeel uit van dit deel van TOGAF.

3.2

DYA®

DYA®, Dynamische Architectuur, is een praktisch toepasbare benadering voor werken onder architectuur, ontwikkeld door Sogeti. Het geeft de visie van Sogeti weer, gebaseerd op jarenlange ervaring in het begeleiden van organisaties bij het werken met architectuur. DYA is geïntroduceerd in 2001 [20.] en wordt regelmatig uitgediept en uitgebreid op basis van praktijkervaringen [1.], [2.], [6.], [12.], [13.] en [16.]. In 2009 zijn alle onderdelen van DYA samengevoegd tot de DYA|Suite.


2.0

12


Figuur 9 DYA|Suite

Deze DYA|Suite bestaat uit de volgende onderdelen: • DYA|Werken Onder Architectuur [20.], [1.], [2.] • DYA|Infrastructuur [12.] • DYA|Principes [6.] • DYA|Governance [16.] • DYA|Software (verschijnt in 2010) Hieronder worden alle onderdelen van de DYA|Suite kort toegelicht. DYA|Werken onder architectuur De basis van DYA, die in de boeken [20.], [1.] en [2.] is beschreven, is nu samengebracht onder de noemer DYA|Werken onder Architectuur (WoA). DYA|WoA bestaat uit een aantal onderdelen : • Het DYA denk- en werkmodel met onder andere het procesmodel, een set aan principes en instrumenten voor het werken onder architectuur. • Een visie op en definitie van architectuur, geordend in het Architectuur raamwerk. • Een aanpak voor het implementeren en / of professionaliseren van werken onder architectuur. Ondersteund met concrete handvatten, zoals de architectuurvolwassenheidsmatrix en het architectuureffectiviteitsmodel [18.]. DYA in de basis is dus met name gericht op het werken onder architectuur, niet het ontwikkelen van architectuur. Architectuur pragmatisch aanpakken DYA gaat uit van een pragmatische visie op architectuur. Architectuur is hierin niet alleen gericht op samenhang, maar ook op het verkrijgen van snelheid door dynamisch in te spelen op de ontwikkelingen vanuit de realiteit van de organisatie. DYA gaat niet uit van een in detail uitgewerkte blauwdruk voor de toekomst, met een meerjarenplan om deze te realiseren. Deze manier van werken voldoet niet meer. Tegen de tijd dat de blauwdruk gereed is, is de wereld al drastisch veranderd. Organisaties moeten snel kunnen meebewegen en anticiperen. De rol van architectuur verandert daarmee van een toekomstbeeld dat gebouwd moet gaan worden in een stuurinstrument dat richting geeft aan de ontwikkelingen van vandaag de dag. Architectuur komt niet tot stand vanuit een ivoren toren, maar vanuit de realiteit van de organisatie. Belangrijkste uitgangspunt hierbij is dat architectuur geen doel op zich is, maar ondersteunend aan de doelen die de organisatie wil bereiken. Sogeti Nederland B.V. juli 2009

2.0

13


Architectuurontwikkeling is een faciliterend proces dat, vergelijkbaar met strategievorming of personeelsbeleid, nooit stopt. Dit leidt tot het tweede uitgangspunt: architectuur kan heel goed stukje bij beetje worden aangepakt. Het is niet nodig om in één keer een volledig architectuurdocument neer te leggen. Architectuur bestaat uit verschillende niveaus, variërend van algemene principes, via concrete beleidslijnen en standaarden, tot modellen. Daarnaast kan architectuur gericht zijn op verschillende domeinen, zoals processen, organisatie, gegevens, applicaties en technische infrastructuur. Door deze differentiatie te onderkennen, wordt het mogelijk om dat stuk architectuur te ontwikkelen waar behoefte aan is en de rest op een later tijdstip of slechts globaal uit te werken. Architectuur ontwikkelt zo mee met de organisatie. Dit is architectuur volgens het just enough, just in time principe, oftewel behoeftegestuurde architectuurontwikkeling. Dit is vormgegeven in het DYA architectuurraamwerk:

Figuur 10 Architectuurraamwerk

Dit DYA raamwerk kan naar behoefte van de organisatie worden aangepast. Het laat duidelijk zien dat de scope niet beperkt is tot ICT architectuur, maar ook business architectuur omvat: de enterprise-architectuur. Architectuur werkend krijgen binnen organisaties Binnen DYA staat het ‘werken onder architectuur’ centraal. Doel daarbij is dat architectuur daadwerkelijk ‘werkt’ binnen de organisatie en bijdraagt aan de doelen. DYA onderkent een aantal processen dat hierbij een rol speelt. Ten eerste is een goede dialoog tussen business en ICT van belang, waarbij ontwikkelingen en kansen van business en ICT worden besproken, deze worden getoetst aan de businessdoelen, business cases worden opgesteld en projectvoorstellen met prioriteiten gedefinieerd. Deze zgn. strategische dialoog wordt ondersteund door Sogeti Nederland B.V. juli 2009

2.0

14


architectuurdienstverlening, waarbij architectuur (verder) wordt ontwikkeld om een specifieke business case uit te werken. Deze architectuur services bieden ondersteuning in de vorm van principes en modellen die inzicht geven in samenhang en richting geven aan de ontwikkeling. De concrete projectvoorstellen worden gerealiseerd in ontwikkelen onder architectuur, binnen gestelde kaders van tijd, geld en kwaliteit. Vanuit architectuur services wordt een project-start-architectuur (PSA) opgesteld. Deze PSA is een vertaling van de algemene architectuurprincipes en modellen naar een op het project toegesneden kader. Overigens geldt voor alle veranderingen waar de organisatie voor staat dat ze onder architectuur kunnen worden uitgevoerd. DYA spreekt in dit verband over businessoplossingen die worden gerealiseerd onder architectuur. Onder speciale omstandigheden (als tijdsdruk een overheersende rol speelt) kan bewust niet onder architectuur worden ontwikkeld: ontwikkelen zonder architectuur. Voorwaarde is wel dat er afspraken worden gemaakt om te zorgen dat het projectresultaat uiteindelijk wel onder architectuur komt. Deze afspraken worden vastgelegd in een zogenaamde management letter.

Figuur 11 DYA Procesmodel

DYA is ontstaan uit de praktijk en bevat sjablonen en instrumenten voor de architect. DYA geeft organisaties hiermee concrete handvatten bij het inrichten en professionaliseren van hun architectuurprocessen zoals visiedocument, communicatiematrix, plan van aanpak, impactanalyse, business case, project-startarchitectuur, bouwvergunning en management letter. Om werken onder architectuur volgens DYA te implementeren of verder te professionaliseren biedt DYA een aanpak waarbij drie sporen worden gevolgd: proces, Sogeti Nederland B.V. juli 2009

2.0

15


product, persoon. De aanpak wordt ondersteund door een assessment instrument, de architectuurvolwassenheidmatrix. Hiermee is te bepalen waar de organisatie staat op het gebied van werken onder architectuur en op welke aandachtsgebieden maatregelen genomen kunnen worden om verbeteringen te realiseren. Schaal 0

1

2

3

4

5

6

7

8

9

10 11 12 13

Aandachtsgebied Opstellen van architectuur

A

Gebruik van architectuur

B A

Afstemming met business

A

Afstemming met ontwikkelproces

C B

C

B A

Afstemming met beheer

A

Relatie met bestaande situatie

A

Verantwoordelijkheden en bevoegdheden

C B

A

B

C B

B

Coördinatie van ontwikkelingen

C A

Bewaking

A

B

B C

Kwaliteitsmanagement

D

A

Beheer architectuurproces

A

Beheer architectuurproducten Commitment en motivatie

A B A

Toepassingsgraad van architectuurmethode

A A

B

C C D B

C

C A

Begroting en planning

C C

C

B

Architectuurtools

B B

B

A

Architectuurfuncties en -opleidingen Overleg

C

A

B B

C C

Figuur 12 Architectuurvolwassenheidsmatrix

Deze aanpak onderkent 18 aandachtsgebieden voor werken onder architectuur zoals te zien is in figuur 12. De aanpak maakt het mogelijk om op het juiste moment het juiste aandachtsgebied de juiste aandacht te schenken. DYA biedt bovendien inzicht in hoe aanpalende vakgebieden als projectmanagement en requirements management samenhangen en samenwerken met architectuur [2.]. DYA|Infrastructuur DYA|Infrastructuur is een methodiek die specifiek gewijd is aan het richting geven aan de vormgeving, implementatie en exploitatie van infrastructuur. De methodiek doet dit met behulp van drie verschillende, elkaar aanvullende onderdelen. 1. Het architectuurproces. Aandacht voor de integratie van infrastructuurarchitectuur in het architectuurproces. Infrastructuur is een nutsvoorziening. Het wordt als gemeenschappelijke voorziening benut door meerdere processen en applicaties én genereert op zichzelf geen opbrengsten voor een organisatie (nutsfunctie). In het architectuurproces moet daarom rekening worden gehouden met het gehele infrastructuurlandschap en de gebruikers, processen en applicaties die hiervan gebruik maken. Gebruikers verwachten infrastructuur af te kunnen nemen als overige nutsvoorzieningen als gas, water en elektriciteit. Dat betekent dat infrastructuur moet voldoen aan duidelijke kwaliteitseisen. Belangrijke kwaliteitsattributen zijn Aanpasbaarheid, Schaalbaarheid, Beschikbaarheid, Veiligheid, Beheerbaarheid en Verrekenbaarheid. In het architectuurproces moeten uitspraken gedaan worden over deze kwaliteitsattributen, zodat duidelijk wordt wat de wensen en eisen ten aanzien van de Sogeti Nederland B.V. juli 2009

2.0

16


infrastructuurvoorzieningen zijn. 2. Werkwijzen en producten. De definitie en beschrijving van werkwijzen en producten die een rol spelen binnen het (infrastructuur)architectuurproces. Het architectuurproces wordt vanuit DYA|Infrastructuur gefaciliteerd door een aantal werkwijzen en producten. Basisarchitectuurproducten: • Organisatie Context Analyse / Globale Taxonomie • Referentie Architectuur • Producten Catalogus • Toekomstvisie en –planning Architectuurbegeleiding van projecten en exploitatie: • Architectuurschets en Impact Analyse • Project Start Architectuur • Ontwerpbegeleiding • Bouw-, test en uitrolbegeleiding • Ondersteuning probleemoplossing 3. Het bouwblokkenmodel. Het aanbieden van een metamodel voor een gestructureerde indeling van het infrastructuurlandschap. Het dient als gereedschap bij het modelleren van het infrastructuurlandschap.

Figuur 13 Het Bouwblokkenmodel

Het Bouwblokkenmodel bestaat uit de volgende dimensies: • Werkgebied Expertise t.a.v. een verzameling infrastructuurvoorzieningen die aan elkaar verwant zijn. Sogeti Nederland B.V. juli 2009

2.0

17


• • • •

Omgeving Gebied binnen de bedrijfsvoering, met bijbehorende bedrijfsprocessen. Bouwblok Enkelvoudige infrastructuurvoorziening die eenduidige en afgebakende infrastructuurfunctionaliteit biedt. Element Technische component waarmee Bouwblokken worden geconstrueerd. Kwaliteitsattribuut Kwaliteitseis die aan de infrastructuurvoorziening wordt gesteld.

DYA|Principes DYA|WoA zegt veel over het (inrichten van) werken onder architectuur maar weinig over hoe architecturen opgesteld moeten worden. Eén van de vormen waarin architecturen opgesteld kunnen worden, zijn architectuurprincipes. Dit zijn beleidsuitspraken die richting geven aan de inrichting van de informatievoorziening. Architectuurprincipes zijn effectief in: • Het ondersteunen van de strategische dialoog • Het stellen van kaders bij het ontwikkelen onder architectuur In DYA|Principes wordt aangegeven wat goede principes zijn door aan te geven waaraan vorm en inhoud moeten voldoen. Ieder principe wordt uitgewerkt in de vorm van statement, rationale, consequenties en eigenaar. Daarnaast worden nog enkele optionele kenmerken beschreven. Qua inhoud worden eisen gesteld aan de semantiek, de syntax en de verzameling van principes.

DYA|Governance Eén van de onderdelen van het DYA-procesmodel is Governance. DYA|Governance geeft concrete invulling aan de inrichting van IT Governance in een organisatie.

Figuur 14 Governance in het DYA-procesmodel

Het uitgangspunt van DYA|Governance is ‘eenvoud’: met een eenvoudige inrichting van governance zijn complexe processen te besturen. In DYA|Governance wordt IT governance beschouwd als de inrichting van de besturing van de IT-functie binnen een Sogeti Nederland B.V. juli 2009

2.0

18


organisatie. IT governance maakt zelf weer onderdeel uit van de totale besturing van de organisatie. Een belangrijk mechanisme bij IT Governance is het IT portfolio. Dit portfolio bestaat uit een projectenportfolio (gericht op veranderingen) en een beheerportfolio (gericht op status-quo). Het IT-portfolio moet passen binnen het businessportfolio.

Figuur 15 Governance portfolio’s

Om de besturing van het IT-portfolio in een organisatie in te richten, zijn 6 factoren van belang: • Besluitvorming: Wie beslist waarover?; • Informatie: Welke informatie is nodig voor een beslissing?; • Alignment: Hoe wordt gewaarborgd dat de beslissing in lijn is met de strategie?; • Planning: Welke invloed heeft de beslissing op korte en lange termijn planning?; • Samenhang: Wat is de invloed van de beslissing op andere zaken uit het portfolio?; • Compliance: In hoeverre past deze beslissing binnen weten regelgeving? Rekening houdend met deze factoren, moeten de volgende processen ingericht worden: • Onderhouden IT plan; • Beheren IT-portfolio; • Bepalen impact vraag; • Besturen verandering; • Verrekenen IT producten en diensten.


2.0

19


Figuur 16 Governance processen en instrumenten

Ter ondersteuning van de Governance-processen is een aantal instrumenten beschreven (zie Figuur 16). DYA|Software DYA|WoA zorgt voor een duidelijke positie van de architectuurrol in de veranderprocessen van de organisatie. DYA|Software vult deze rol verder in voor software architectuur. Aan de ene kant geeft het invulling aan software architectuur voor informatiesystemen binnen de context van enterprise-architectuur voor organisaties. Aan de andere kant geeft het invulling aan hoe software architectuur toegespitst kan worden op een bepaalde situatie, reikend van een enkele applicatie tot aan een verzameling van gerelateerde applicaties. DYA|Software levert een aantal technieken en denkwijzen om te komen tot een goede software architectuur. Het biedt ondersteuning bij het opstellen van architectuurprincipes die goed richting geven aan het ontwerp en realisatie van software. Het dicht daarmee het gat tussen het algemene niveau van enterprisearchitectuur en het concrete niveau dat nodig is voor software ontwerpers en ontwikkelaars in ontwikkelprojecten. In DYA|Software staat het opleveren van een ‘goede’ architectuur centraal. Een architectuur is goed als deze: • correct is: de architectuur vormt de juiste balans tussen de stakeholders belangen. Belangen zijn er in de vorm van doelen en beperkingen. • consistent is: de architectuuruitspraken zijn onderling niet strijdig. Dit geldt niet alleen voor de uitspraken van de architectuur zelf, maar ook in relatie tot de omgeving. Sogeti Nederland B.V. juli 2009

2.0

20


•

gecommuniceerd is: de stakeholders zijn op de hoogte van hun relatie met en hun rol in de architectuur. Zij moeten weten wat er van hen verwacht wordt en wat zij moeten verwachten. Natuurlijk moeten ze ook valideren hoe hun doelen en beperkingen geborgd zijn. Als puur de architectuurbeschrijving beschouwd wordt, dan moet deze dus communiceerbaar zijn.

Om de architect te helpen een ‘goede’ architectuur op te leveren, is het architectuur redeneermodel ontwikkeld. Het doel van het model is om te helpen bij het nemen en het begrijpen van beslissingen die nodig zijn om een systeem te realiseren binnen haar context. Het model bestaat uit drie dimensies: 1. Toepassingsdimensie Wat lever je aan de gebruikers/klanten van het systeem en wat betekent dat voor hen? Het gaat hier over klantdoelen, klantbehoefte, systeem use cases, systeem functionaliteit en kwaliteit. 2. Ontwerpdimensie Hoe moet het systeem in elkaar zitten en hoe maak je gebruik van reeds bestaande ontwerpkeuzes/systemen? Het gaat hier over de opdeling van het systeem in (evt. reeds bestaande) onderdelen en hoe deze samenhangen. 3. Realisatiedimensie Op welke manier en met welk plan komt het systeem tot stand en welke mensen/organisatie heb je daarvoor nodig? Dit gaat over planning, het ontwikkelen beheerproces en de daarvoor benodigde vaardigheden en kennis. DYA|Software geeft praktische richtlijnen voor het omgaan met stakeholderbelangen en het op maat maken van een architectuur en architectuurraamwerk. Dit uit zich in het aanpassen van viewpoints en het omgaan met situatiespecfieke aspecten en kwaliteitsattributen.


2.0

21

White paper: DYA®: implementatieaanpak voor TOGAF™ Vergelijkingsresultaten

4

VERGELIJKINGSRESULTATEN

In het vorige hoofdstuk zijn TOGAF en DYA besproken. In dit hoofdstuk worden ze geplot op het vergelijkingsmodel dat in hoofdstuk 2 is gepresenteerd.

4.1

TOGAF

TOGAF omschrijft zichzelf als een raamwerk, maar het belangrijkste deel van TOGAF is het procesmodel ADM (Architecture Development Method). De ADM is een recept om een enterprise-architectuur te ontwikkelen. TOGAF 8 was daarom niet zozeer een raamwerk, maar meer een architectuurproces. Een raamwerk categoriseert de architectuurassets, een architectuurproces beschrijft hoe de architectuurassets ontwikkeld moeten worden [15.]. In TOGAF 9 is een content framework toegevoegd waarmee TOGAF pas sinds kort zowel een ontwikkelproces als een raamwerk biedt. Het vergelijkingsmodel van hoofdstuk 2 kent verschillende onderdelen. Voor elk van die onderdelen is onderzocht in hoeverre TOGAF invulling geeft aan die onderdelen. Visie Het aandachtsgebied visie is binnen TOGAF beperkt ingevuld. TOGAF levert nauwelijks ondersteuning voor het bepalen en opstellen van een architectuurvisie binnen een organisatie. TOGAF stelt in de preliminary phase alleen de vraag how we do architecture. Aan de vraag naar het waarom van architectuur wordt echter geen aandacht besteed. Procesinrichting De procesinrichting van TOGAF is goed ingevuld. De ADM geeft duidelijk aan hoe een architectuurproces binnen een organisatie ingericht kan verlopen. Binnen TOGAF 9 wordt volop aandacht gegeven aan de inbedding van dit proces binnen de organisatie, onder meer door relaties aan te geven met andere frameworks. Ook het Capability Framework biedt ondersteuning bij de juiste inbedding van het architectuurproces binnen een organisatie door sjablonen voor Architecture Contracts en Architecture Compliance Reviews en hulpmiddelen om de volwassenheid te meten met behulp van een Architecture Maturity Model. TOGAF bevat zelf geen Architecture Maturity Model, maar verwijst naar andere modellen (CMMI, ACMM). Ontwikkeling en onderhoud Het aandachtsgebied ontwikkeling en onderhoud is goed ingevuld. De ADM van TOGAF is hiervoor bedoeld. Stap voor stap (met name de fasen B, C en D) wordt beschreven hoe de architectuur ontwikkeld moet worden. In de eerste stap van de cyclus wordt bepaald wat de scope van de architectuurontwikkeling is. De cyclus is op die manier bruikbaar voor zowel de initiële opzet van een enterprise-architectuur als voor het onderhoud van een deel van de architectuur. De stappen bieden handvatten voor het architectureren van ICT-oplossingen binnen een business context. Binnen TOGAF zijn enkele referentiemodellen opgenomen, die gebruikt kunnen worden bij het ontwikkelen van architectuurproducten: • TRM – Technical Reference Model, een voorgestelde beschrijving van (de componenten van) een generieke ICT architectuur; • IIIRM – Integrated Information Infrastructure Reference Model, een applicatie architectuur referentiemodel met de applicatiecomponenten en -services gericht op gegevensuitwisseling. Het is een verbijzondering van de 'applicatielagen' van het


2.0

22


TRM, en biedt een indeling naar business applicaties, infrastructurele applicaties en applicatieplatform services. In het hoofdstuk Architecture Deliverables wordt een overzicht gegeven van wat de architectuurfunctie binnen een organisatie moet produceren. Gebruik Het aandachtsgebied gebruik is goed afgedekt. Het resultaat van de eerste stap in de ADM-cyclus (Architecture Vision) is dat de beslissers in de organisatie duidelijkheid krijgen over de voordelen van de beoogde ontwikkeling. Uit de architectuurvisie moet duidelijk blijken dat de iteratie van architectuurontwikkeling bijdraagt aan de doelen van de organisatie, past binnen de geldende principes en de belangen van de stakeholders behartigt. Dit is de adviserende kant van het gebruiken van architectuur. De kaderstellende kant van het gebruiken van architectuur is te vinden in de stap Implementation Governance. Nadat de architectuur in de voorgaande stappen is ontwikkeld, wordt de architectuur verder ingevuld en ontwikkeld binnen projecten. De architect geeft (in de stap Implementation Governance) kaders en richtlijnen mee aan de projecten en reviewt de resultaten tijdens de projecten. Na afronding van de projecten worden (in de stap Architecture Change Management) continu nieuwe ontwikkelingen in de gaten gehouden en wordt beoordeeld of een nieuwe ADM-cyclus nodig is. Ook hierin komt de adviserende kant van architectuur tot uiting. Het Enterprise Continuum is een concept dat helpt om bij ontwikkeling en gebruik van architectuur altijd zicht te houden op andere architecturen dan alleen de architectuur die aan verandering onderhevig is. In TOGAF 9 is dit concept verder uitgebreid met een aanpak voor het partitioneren van architecturen en een voorstel voor de structuur van een Architecture Repository. In deel III van TOGAF 9 worden Guidelines en Techniques beschreven, die hulp bieden bij het gebruik van de ADM, zoals business scenarios en gap analyses. Architectuurgovernance Het aandachtsgebied architectuurgovernance is beperkt ingevuld. TOGAF kent binnen de ADM de fase Implementation Governance, maar dat is de governance van de implementatie van de ontwikkelde architectuur, niet de governance van het architectuurproces. In deel VIII wordt een hoofdstuk gewijd aan Architecture Governance. In dit hoofdstuk wordt op globaal niveau beschreven hoe de governance van het ontwikkelen van architectuur enterprisebreed ingericht kan worden. Het biedt echter geen handvatten voor het bepalen van het succes van architectuur en het verbeteren daarvan. Raamwerk Dit aandachtsgebied is compleet ingevuld. In TOGAF 9 is het Content Framework één van de belangrijkste toevoegingen aan TOGAF. Het raamwerk omvat alle drie de domeinen die in een architectuurraamwerk te verwachten zijn: business, informatie en technologie. Deze domeinen zijn verder onderverdeeld in entiteiten per domein. Artefact Dit aandachtsgebied is goed ingevuld. Onderdeel van het Content Framework zijn de entiteiten per domein. Van ieder van deze entiteiten wordt aangegeven wat de attributen zijn. Sogeti Nederland B.V. juli 2009

2.0

23


View Dit onderwerp is compleet ingevuld. Binnen het Content Framework wordt ingegaan op – zoals TOGAF het noemt – Architectural Artifacts. Dit zijn views, waarin de entiteiten worden gerepresenteerd. TOGAF maakt onderscheid in catalogs, matrices en diagrams. Voor elk van de domeinen in het Content Framework worden suggesties gedaan voor de op te stellen views. Daarnaast wordt aandacht besteed aan het proces van het opstellen van views. Architectuurmanagement Dit aandachtsgebied is niet ingevuld. TOGAF onderkent geen meetinstrumenten waarmee het rendement van architectuurproducten in de organisatie kan worden aangetoond. Organisatie en rollen Het aandachtsgebied Organisatie is binnen TOGAF goed ingevuld. Het Architecture Capability Framework is hiervoor bedoeld. Dit framework levert referentiemateriaal aan de hand waarvan de architectuurfunctie ingericht kan worden. Voor het inrichten van de architectuurfunctie stelt TOGAF voor ook de ADM te hanteren. Daarnaast wordt verwezen naar volwassenheidsmodellen (CMMI, ACMM) en is er een hulpmiddel beschikbaar om de veranderbereidheid te meten (Business Transformation Readiness Review). Onderdeel van het Capability Framework is het Skills Framework, waarin de verschillende rollen van architecten en van stakeholders zijn uitgewerkt. Binnen TOGAF 9 worden geen uitspraken gedaan waar in het organisatieschema de architectuurfunctie het beste ingepast moet worden. Opleiding en coaching Dit aandachtsgebied is redelijk uitgewerkt. TOGAF geeft zelf weliswaar geen aanwijzingen voor opleidingen en coaching, maar The Open Group kent wel een certificeringstraject voor TOGAF. Daarnaast biedt The Open Group ook een meer generieke certificering in de vorm van ITAC. Competentie TOGAF werkt het aandachtsgebied competentie goed uit. Van iedere rol in het Architecture Skills Framework wordt benoemd welke vaardigheden en kennis nodig zijn op welk niveau (background, awareness, knowledge, expert). De rol ‘Enterprise Architect’ wordt verder uitgediept in taken en bevoegdheden. HR-Management Binnen TOGAF wordt geen aandacht geschonken aan HR-management. Plan Binnen TOGAF wordt beperkt aandacht geschonken aan het planmatig verbeteren van de architectuurfunctie binnen een organisatie. Er zijn weliswaar instrumenten voor risicomanagement en Capability Based Planning, maar deze zijn vooral gericht op het implementeren van de ontwikkelde architectuur in de organisatie. Er wordt verder geen aandacht geschonken aan het blijvend verbeteren van de architectuurfunctie.


2.0

24


4.2

DYA

DYA omschrijft zichzelf als een denk- en werkmodel, en is vooral gericht op het werken onder architectuur, met een pragmatische aanpak voor het maken en het daadwerkelijk gebruiken van architectuur. Het vergelijkingsmodel kent verschillende onderdelen. Voor elk van die onderdelen is onderzocht in hoeverre DYA invulling geeft aan die onderdelen en welke hulpmiddelen hiertoe worden aangedragen door de methode. Visie Het aandachtsgebied visie is binnen DYA goed ingevuld. Binnen DYA wordt duidelijk gemaakt dat de architectuurfunctie binnen een organisatie moet opereren vanuit een duidelijke architectuurvisie. DYA biedt ondersteuning in het opstellen van een dergelijke architectuurvisie door het bieden van een sjabloon en een stappenplan. Verder zijn er werkvormen beschikbaar om te komen tot een gedragen, afgestemde visie (awareness workshop, communicatieworkshop, veranderstrategie). Procesinrichting De procesinrichting is compleet afgedekt. DYA is in feite ontwikkeld om tot een optimale inrichting van de architectuurfunctie en –processen in een organisatie te komen. Daar wordt veel aandacht aan besteed met onder andere het DYA-procesmodel, de architectuurscan, de volwassenheidsmatrix, de aanpak voor invoering van architectuur, en producten als het architectuurvisiedocument, de veranderstrategie, het etappeplan en de communicatiematrix. Met name deel twee [1.] – de praktische gids voor professionaliseren – bevat veel concrete tips en succesfactoren voor architecten, hun rol en de plaats van het architectuurteam in de organisatie. Ontwikkeling en onderhoud Ontwikkeling en onderhoud is goed ingevuld. DYA besteedt met name in het proces Architectuurservices, ondersteund met het architectuurraamwerk, aandacht aan het opstellen van architectuurproducten. DYA hanteert het principe van just enough, just in time bij het opstellen van architectuur. Het raamwerk geeft de verscheidenheid van en samenhang tussen architectuurproducten weer. DYA benoemt verschillende architectuurinvalshoeken, te weten strategisch, tactisch en operationeel, met als resultaat respectievelijk enterprise-architectuur (bestemmingsplan), domeinarchitectuur (blauwdruk) en project-start-architectuur (PSA). De architectuur die moet worden opgesteld wordt gestuurd door de businessontwikkelingen, bepaald in het proces Strategisch dialoog. Hierbij worden concrete handvatten geboden in bijvoorbeeld het (sjabloon) plan van aanpak dat voor elk architectuurproduct wordt gemaakt. DYA beschrijft wel welke producten wanneer en hoe moeten worden opgesteld, en waar ze voor dienen, maar geeft niet aan hoe ze eruit moeten zien. Daarnaast biedt DYA|Infrastructuur een meer uitgewerkte aanpak voor het ontwikkelen van technische architectuur (infrastructuur) en DYA|Software voor het ontwikkelen van software architectuur (applicaties). Met DYA|Principes biedt DYA een aanpak voor het ontwikkelen van architectuurprincipes. Gebruik Het gebruik is goed afgedekt. Het procesmodel van DYA is met name gericht op het gebruiken van architectuur. De Strategische dialoog betreft vooral de adviserende kant van het gebruiken van architectuur en het proces Ontwikkelen onder architectuur vooral de kaderstellende kant van het gebruiken van architectuur. Sogeti Nederland B.V. juli 2009

2.0

25


In beide gevallen biedt DYA concrete instrumenten en tips. De Strategische dialoog wordt ondersteund met de business case en de impactanalyse, het Ontwikkelen onder architectuur met de project-start-architectuur en een bouwvergunning. In voorkomende gevallen wordt Ontwikkelen zonder architectuur ondersteund met de management letter. Ook wordt nadrukkelijk gesteld dat een visiedocument met betrekking tot architectuur wordt opgesteld, als vertrekpunt voor alle architectuurinitiatieven. Tevens dient voor elk architectuurproduct een plan van aanpak te worden opgesteld met een opdrachtgever. Architectuurgovernance Sturing en bewaking zijn goed ingevuld. DYA onderkent in het procesmodel een proces voor besturing van het werken onder architectuur (“governance”). Met DYA|Governance wordt bovendien een aanpak gegeven voor IT Governance. De implementatieaanpak, onderbouwd met de architectuurvolwassenheidsmatrix geeft een aantal aandachtsgebieden waarmee de besturing stap voor stap verder ingericht wordt en het werken onder architectuur verder geprofessionaliseerd. Raamwerk Het raamwerk is goed ingevuld. Het DYA architectuurraamwerk geeft een indeling en ordening van de domeinen of architectuurgebieden die DYA onderkent, en de verschillende niveaus van architectuurproducten. De matrix die ontstaat biedt de mogelijkheid om concrete architectuurproducten te positioneren en aan elkaar te relateren. Het helpt om volledigheid en prioriteit te bepalen. Voor het niveau van de architectuurprincipes biedt de DYA|Suite een specifieke invulling met DYA|Principes. DYA biedt expliciet de vrijheid om het raamwerk aan te passen of te vervangen voor een ander ordeningshulpmiddel. Artefact Artefacten zijn beperkt ingevuld. DYA biedt met het architectuurraamwerk een overzicht van mogelijke architectuurproducten – op verschillende niveaus en domeinen. Aan het niveau van architectuurprincipes wordt invulling gegeven door DYA|Principes. Dit onderdeel van de DYA|Suite geeft aan op welke manier architectuurprincipes opgesteld moeten worden, qua proces en qua samenstelling. Ook met DYA|Infrastructuur wordt in de vorm van het bouwblokkenmodel een metamodel gegeven voor het ontwikkelen van artefacten voor infrastructuurarchitectuur. Views Views zijn beperkt ingevuld. DYA geeft aan dat de verschillende architectuurproducten moeten worden afgestemd op de doelgroep. Er worden enkele voorbeelden getoond, echter zonder waardeoordeel. DYA beperkt zich in haar basis (DYA|WoA) voor wat betreft voorschriften tot het niveau van principes en beleidslijnen en besteedt nagenoeg geen aandacht aan de manier waarop architectuurmodellen gevisualiseerd kunnen worden afhankelijk van stakeholders. Met de komst van aanvulling op DYA (DYA|Infrastructuur en DYA|Software) wordt er wel verder invulling gegeven aan het richting geven aan het opstellen van architectuurviews. Dit is echter niet over de volle breedte uitgewerkt. Architectuurmanagement Dit aandachtsgebied is niet ingevuld. DYA kent binnen de scope van de methode een breed scala aan modellen, voorbeelden, templates en checklists maar bevat geen handvatten waarmee zeker kan worden gesteld dat de juiste architectuur is opgeleverd. Organisatie en rollen Het aandachtsgebied Organisatie is binnen DYA goed ingericht. Met het DYAgnoseinstrument (architectuurvolwassenheidsmatrix) worden concrete handvatten gegeven Sogeti Nederland B.V. juli 2009

2.0

26


voor de inrichting van de architectuurfunctie, gegeven de volwassenheid van de organisatie. Ook wordt uitgebreid aandacht besteed aan de ophanging van de architectuurfunctie in de organisatie. Daarbij worden verschillende varianten besproken en voorzien van voor- en nadelen. Binnen DYA wordt beperkt aandacht geschonken aan verschillende rollen. DYA definieert geen verschillende rollen voor architecten en stakeholders. Wel wordt in een voorbeeld een uitwerking gegeven van een mogelijke rolverdeling. Opleiding en coaching Dit aandachtsgebied is redelijk afgedekt. In het hoofdstuk ‘De architect als succesfactor’ in [1.] worden tips gegeven voor persoonlijke coaching, collegiale review, intervisie en training. Er wordt via een voorbeeld aangegeven hoe dit concreet kan worden gemaakt in een coachingsplan voor een architect. DYA kent geen vormen van certificering. Het gedachtegoed van DYA wordt wel aangeboden in de vorm van cursussen bij onafhankelijke opleidingsinstituten. Competentie De Competentie van een architect is binnen DYA redelijk uitgewerkt. Er worden tips gegeven hoe ‘de architect’ zijn rol moet spelen binnen een organisatie en er wordt aandacht gevraagd voor het helder definiëren van verantwoordelijkheden, bevoegdheden en opdrachtgeverschap. DYA definieert zelf echter geen taken, verantwoordelijkheden en bevoegdheden van verschillende rollen van architecten en stakeholders. HR-management DYA schenkt geen aandacht aan HR-management. Plan Binnen DYA wordt het planmatig verbeteren van de architectuurfunctie helemaal uitgewerkt. Een instrument als het etappeplan is hiervoor bedoeld. Aan de hand van de volwassenheidsmatrix wordt bepaald waar de organisatie staat in volwassenheid van de architectuurfunctie. In het etappeplan worden de acties voor de komende periode vastgelegd om een stap hoger in de volwassenheid te komen rekening houdend met de cultuur van de organisatie. Deze cyclus wordt steeds herhaald.


2.0

27


4.3

Mapping op vergelijkingsmodel

De analyse van TOGAF en DYA, zoals in de vorige paragrafen beschreven, is als volgt samen te vatten in het vergelijkingsmodel:

Figuur 17 Vergelijking TOGAF - DYA

Uit de vergelijking van TOGAF en DYA kan een aantal conclusies worden getrokken: •

TOGAF 9 is vooral sterk in het ondersteunen bij het ontwikkelen van architectuur binnen een organisatie, zowel bij het proces als bij het product en de persoon, gezien de hoge scores op Ontwikkeling en Onderhoud, Raamwerk, Artefact, View, Organisatie, Rollen en Competentie;

•

DYA|Suite is vooral gericht op het werkend krijgen en houden van de architectuurfunctie binnen een organisatie, gezien de hoge scores in Visie, Plan, Procesinrichting, Governance en Organisatie;

•

TOGAF 9 biedt meer dan DYA|Suite ondersteuning op de productdimensie;

•

Op sommige gebieden vertonen TOGAF 9 en DYA|Suite overlap met elkaar (Procesinrichting, Raamwerk en Organisatie);

•

TOGAF 9 en DYA dekken beide maar een beperkt deel af van het totale spectrum dat een organisatie nodig heeft om op een effectieve en efficiënte manier architectuur te kunnen bedrijven (TOGAF 31, DYA 32 van de 56 mogelijke “bollen”). TOGAF 9 is sterker op de productkant, DYA|Suite biedt meer op het gebied van Visie en Plan. Op de andere gebieden (Proces en Persoon) ontlopen ze elkaar niet veel;


2.0

28


•

Een aantal onderdelen van de DYA|Suite vult blinde vlekken in van TOGAF. Het duidelijkst gebeurt dit door DYA|Governance en DYA|Infrastructuur. Op het gebied van respectievelijk IT Governance en infrastructuurarchitectuur geven zij concrete handvatten om op een laagdrempelige manier aan de slag te gaan.


2.0

29

White paper: DYA®: implementatieaanpak voor TOGAF™ Conclusie

5

CONCLUSIE

Uit het vergelijkingsmodel blijkt dat TOGAF inhoudelijk sterke papieren heeft. Op de aandachtsgebieden Proces, Product en Persoon voegt DYA alleen op onderdelen wat toe. De aandacht van TOGAF voor de overige twee elementen van architectuur, Visie en Plan, is echter beperkt. Deze twee elementen gaan over de inbedding van de architectuurfunctie binnen een organisatie. En daar ligt juist de kracht van DYA. Op dit gebied voegt DYA dus waarde toe aan TOGAF. Uiteindelijk gaat het niet over TOGAF of over DYA, maar over het leveren van toegevoegde waarde vanuit een effectieve architectuurfunctie. Niet een methode is bepalend voor het succes daarvan, maar de mate waarin de architectuurfunctie is ingebed in strategische besluitvormingsprocessen van een organisatie. [5.]

Figuur 18 DYA als implementatieaanpak voor TOGAF

Organisaties die overwegen TOGAF als architectuuraanpak te implementeren, lopen vaak tegen de vraag aan hoe dit voor elkaar te krijgen. TOGAF zelf biedt daar beperkt hulp. Forrester [9.] geeft bovendien aan dat TOGAF moeilijk is voor starters op het terrein van enterprise-architectuur en dat het zeker niet raadzaam is om in zo’n situatie alle onderdelen van TOGAF 9 in de volle omvang te gaan gebruiken. De kunst is om TOGAF gefaseerd in te voeren. DYA biedt hierbij soelaas. Het bevat hulpmiddelen om een effectieve architectuurfunctie in een organisatie te implementeren. Instrumenten als de volwassenheidsmatrix, de architectuurscan, het architectuureffectiviteitsmodel en de aandacht voor de Strategische Dialoog helpen een organisatie om architectuur werkend te krijgen. Voor organisaties die aan de slag willen met architectuur of verder willen professionaliseren, is DYA dus een prima implementatieaanpak. TOGAF is als open standaard dan een prima aanpak voor het ontwikkelen van de inhoud van architectuur. Daar waar TOGAF aan de productkant hiaten kent (bijvoorbeeld op het gebied van infrastructuur) biedt de DYA|Suite welkome aanvullingen die heel goed samen met TOGAF kunnen worden gebruikt.


2.0

30

White paper: DYA®: implementatieaanpak voor TOGAF™ Over de auteurs

6

OVER DE AUTEURS

Martin van den Berg is als Serviceline manager binnen Sogeti verantwoordelijk voor de diensten vakontwikkeling op architectuurgebied. Daarnaast begeleidt hij organisaties bij het professionaliseren van het werken onder architectuur. Martin is (mede-)auteur van een reeks van DYA-boeken en van het boek “SOA for Profit, a Manager's Guide to Success with Service Oriented Architecture”. Ook staan er tal van publicaties en artikelen op zijn naam en is hij een veelgevraagd spreker. Martin van den Berg is tevens voorzitter van de Afdeling Architectuur van het NGI, is docent bij Pro-Education, is namens Sogeti afgevaardigde in het Architecture Forum van The Open Group, zit in de redactieraad van Sogeti’s IT Journal en maakt deel uit van de programmacommissie van het LAC2009. [email protected] Jan Willem Dijkstra is informatie architect bij Sogeti. Hij helpt organisaties bij het opstellen van architecturen en het implementeren van werken onder architectuur. Daarnaast treedt hij op als docent binnen Sogeti. Jan Willem is TOGAF gecertificeerd. [email protected] Gé Schellen is informatie architect bij Sogeti. Hij helpt organisaties bij het opstellen van architecturen (Business, Informatie en Technisch) en het implementeren van werken onder architectuur. Zijn belangstelling gaat daarbij vooral uit naar de informatie en technische architectuur. Gé is TOGAF gecertificeerd. [email protected] Renzo Wouters is informatie architect bij Sogeti. Hij helpt organisaties bij het opstellen van architecturen en het implementeren van werken onder architectuur. Zijn belangstelling gaat daarbij vooral uit naar de business architectuur. Renzo is TOGAF gecertificeerd. [email protected]


2.0

31

White paper: DYA®: implementatieaanpak voor TOGAF™ Referenties

7

REFERENTIES

[1.] Berg, Martin van den en Marlies van Steenbergen, DYA : Stap voor stap naar professionele enterprise-architectuur, 2004, Academic Service [2.] Berg, Martin van den en Marlies van Steenbergen, DYA Topics, Rendement uit enterprise-architectuur, 2006, Academic Service [3.] Berg, Martin van den en Marlies van Steenbergen, Dynamische architectuur, naar een nieuwe architectuurstijl, 2002, Computable [4.] Berg, Martin van den, Jan Willem Dijkstra en Renzo Wouters, Maakt TOGAF DYA overbodig? Februari 2009, www.dya.info [5.] Booz&co, Building Value through Enterprise Architecture, A Global Study, 2009 [6.] Bouwens, Serge, DYA|Architectuurprincipes, White Paper, 2008, www.dya.info [7.] Forrester Research, Enterprise Architecture Frameworks are mainstream, but the landscape remains diverse, 2006, www.forrester.com [8.] Forrester Research, Standards for Enterprise Architecture, mix and match to suit your enterprise needs, 2005, www.forrester.com [9.] Forrester Research, Use TOGAF 9 As Your Next EA Framework, 2009, www.forrester.com [10.] Harmsen van der Beek, Wijke ten en Herman Hartman, De opmars van TOGAF, Informatie, november 2007, www.informatie.nl [11.] IEEE, Recommended Practice for Architectural Description of Software-Intensive Systems, IEEE 1471, 2001, http://www.iso-architecture.org/ieee-1471/index.html [12.] Jumelet, Daniël, DYA Infrastructuur, Architectuur voor de fundering van de IT, 2007, Academic Service [13.] Luijpers, Joost, Project-start-architectuur, White Paper, 2007, www.dya.info [14.] Molenaar, Teus, TOGAF gaat het maken, Computable, februari 2008 [15.] Sessions, Roger, Comparison of the top four Enterprise Architecture Methodologies, 2007, http://www.objectwatch.com/WhitePapers/4EAComparison.pdf [16.] Smits, Daniel, Succes met IT-Governance, 2006, www.dya.info [17.] Steenbergen, Marlies van, Sjaak Brinkkemper and Martin van den Berg, An instrument for the development of the enterprise architecture practice. In Proceedings of the 9th International Conference on Enterprise Information Systems, 2007, pp.14-22. www.dya.info [18.] Steenbergen, Marlies van and Sjaak Brinkkemper, Modeling the contribution of enterprise architecture practice to the achievement of business goals, www.dya.info [19.] The Open Group, The Open Group Architectural Framework (TOGAF), Version 9, Enterprise Edition, February 2009, www.opengroup.org/architecture/togaf9doc/arch/ [20.] Wagter, Roel, Martin van den Berg, Joost Luijpers en Marlies van Steenbergen, DYA: Snelheid en samenhang in business- en ICT architectuur, 2001, Tutein Nolthenius


2.0

32

WHITE PAPER DYA : IMPLEMENTATIEAANPAK VOOR TOGAF

Recommend Documents