Architectuur in Nederland "Zijn de veters al gestrikt?"

Architectuur in Nederland "Zijn de veters al gestrikt?"

vrije Universiteit amsterdam

Divisie Wiskunde en Informatica Faculteit der Exacte Wetenschappen vrije Universiteit De Boelelaan 1081A 1081 HV Amsterdam Nederland

Auteurs: Bas Boom Nazan Ergin Valerie Ivangorodsky Meltem Kassabbashi Navin Kisoensingh Ramon Knol Clyve Lo-A-Njoe Tony Slamet Rashid Sohrabkhan Fons Wielzen Groep: 2 Datum: 27januari 2003

C9823

Voorwoord Voor u ligt het eindverslag voor het vak Software Architectuur, gegeven aan de vrije Universiteit in Amsterdam. Het handelt allereerst over wie we zijn en wat het doel van het project is. Daarna bespreken we de bevindingen van ons onderzoek en afsluitend zullen we enkele conclusies geven. Verder willen we hierbij alle bedrijven en docenten van harte bedanken die aan dit onderzoek hebben meegewerkt. Rest ons nog u veel plezier toe te wensen tijdens het lezen van dit verslag. Amsterdam, 27januari2003 Bas Boom Nazan Ergin Va/erie Ivangorodsky Me/tem Kassabbashi Navin K/soensingh Ramon Knol ayve Lo-A-Njoe Tony Slamet Rashid Sohrabkhan Fons Wielzen

Software Architectuur 2002-2003

BIBLIOTHEEK Bouwdienst Rijkswaterstaat Postbus 20.000 BIBLIOTHEEK BOU WOlENST RIJKSWATERSTAAT 3502 LA Utrecht .. NR. L ..

9.

Inhoudsopgave .

...............................................................................................

3 Inleiding 1.1. Introductie ......................................................................................................3 1.2. Projectopzet .................................................................................................... 3 1.3. Projectgroep .......................... . ................................ ... . ....... . ........ . .................... 3 1.4. Executive summary. ................... . ........ . ................................ . ........................... 4 5 2. Bevindingen 2.1. Algemeen ........................................ . ........ . ...................................................... 5 2.2. Wat verstaat men onder architectuur7 ............................................................... 5 2.2.1. Interpretatie / definitie van architectuur .............................................. . ....... 5 2.2.2. Belang van de architectuur ........ ... . ............................................................ 5 2.2.3. Soorten architectuur.................................................................................. 6 2.3. Architectuurmethoden en —modellen ............................................... . .................. 8 2.3.1. Inleiding ............................................................................................... . ... 8 2.3.2. Bedrijfstakken ......................................................... . .................................9 2.3.3. Methoden & Modellen ................... . ........... . .............................................. 10 2.3.4. Uitvoering .............................................................................................. 12 2.4. Rol van de architect ....................................................................................... 13 2.4.1. Inleiding ............................. . ................................................................... 13 2.4.2. Algemene taken en kenmerken ................................................................ 13 2.4.3. Soorten & Rollen ............... . ............................. . ....................................... 14 2.4.4. Positie ............ . ................................................................................ . ...... 15 2.4.5. Toekomst .... . ..................................... . ... . ....... . ........................................ 16 74 A \Iilkiiilpn 16 2.5. Ervaringen met architectuurmethoden en —modellen......................................... 17 Architectuur als communicatiemiddel ........................................................ 17 2.5.1. Architectuur als kostendrukker................................................................. 17 2.5.2. Architectuur en Volwassenheid ............................................................. . ... 17 2.5.3. 2.5.4. Architectuur en projecten ........................................................................ 18 Architectuur en eigen creativiteit ............................................. . ................ 18 2.5.5. Architectuur en de opdrachtgever............................................................. 18 2.5.6. 19 3 Conclusie

1

.........................................................................................

.

......................................................................................... ...

Tabel 1: Architectuurmethoden en of -modellen uitgesplitst naar bedrijfstak ........................ 9 Tabel 2: Overzicht van gebruikte Architectuurmodellen en -methoden ..............................10


1. Inleiding

1.1. Introductie Het vak Software Architectuur is in het studiejaar 2002 - 2003 praktisch van aard. Het vak heeft als hoofddoelstelling te achterhalen welke architectuurmethoden en -modellen er in de praktijk in Nederland worden gebruikt en wat de ervaringen daarmee zijn. Er is voor het project afgesproken dat wij als elicitatietechniek het afnemen van interviews gaan gebruiken. Aan dit onderzoek hebben een twintigtal toonaangevende bedrijven uit verschillende bedrijfstakken meegedaan. In onze groep hebben wij in totaal 15 interviews afgenomen bij 12 verschillende bedrijven. De betrokken bedrijven komen uit verschillende bedrijfstakken, te weten Banken, ICT-consultancy en Productontwikkelaars. In het eindverslag wordt rekening gehouden met de vier hoofdvragen die gedurende de interviews als leidraad hebben gediend: Wat verstaat men onder architectuur? Welke methoden en modellen gebruikt men? Wat is de rol van de architect? Wat zijn de ervaringen met de methoden en modellen? Dit eerste hoofdstuk is bedoeld als inleiding, het geeft onder andere een overzicht van het vak, het doel van het vak en de eindtermen van het vak. In het tweede hoofdstuk kunt u onze bevindingen lezen. Afsluitend in dit eindverslag vindt u onze conclusies van de bevindingen.

1.2. Projectopzet Het vak is grofweg opgedeeld in twee fasen en er zijn 28 deelnemende studenten. In de eerste fase is de totale groep opgedeeld in groepen van twee personen. Elke groep heeft drie interviews afgelegd bij drie van de betrokken bedrijven. In de tweede fase is de totale groep weer opgedeeld in drieën. Er zijn nu twee groepen van 10 personen en één groep van 8 personen gevormd. Deze groepen hebben een eindverslag gemaakt, gebaseerd op de in groepen van twee gehouden interviews, met daarin de bevindingen en eindconclusies van die interviews.

1.3. Projectgroep Onze eindgroep is samengesteld door onze docent, prof. dr. Hans van Vliet. De groep bestaat uit 10 personen, te weten: Naam Bas Boom Nazan Ergin Valerie Ivangorodsky Meltem Kassabbashi Navin Kisoensi ngh Ramon Knol Clyve Lo-A-Njoe Tony Slamet Rashid Sohrabkhan Fons Wielzen

Studie Informatica Informatiekunde Informatica Informatiekunde Informatiekunde Informatiekunde Informatiekunde Informatiekunde Informatiekunde Informatica

Studentnummer 1366009 1043552 1131559 1101293 1046071 1293397 1143085 1172972 1050591 1295489


1.4. Executive summary Eén van de eerste dingen die je als kind leert, is het strikken van je veters. Schoenen vormen onbewust een belangrijke basis voor de rest van je leven. Je zal er een groot deel van je leven op lopen, dus ze moeten comfortabel en stevig zitten. Je bent er van afhankelijk en ze zorgen voor een vlotte en optimale voortbeweging: "Stevig inje schoenen staan' Net zo kan architectuur gezien worden als een belangrijke basis voor een bedrijf. Het kan onder andere voor flexibiliteit en efficiency zorgen. Het is dus van groot belang dat de "veters van de architectuur" goed en stevig gestrikt zijn. Tijdens dit onderzoek is er vooral gekeken naar de huidige stand van zaken op het gebied van architectuur in Nederland. Daartoe is er een inventarisatie gemaakt van de gebruikte methoden en modellen binnen de architectuur. Verschillende bedrijven hebben verschillende interpretaties van architectuur en gebruiken architectuur dus ook allen op hun eigen manier. Verder komt onder andere naar voren dat, ondanks de verschillende gebruikte definities van architectuur, er gemiddeld genomen wel één centrale gedachte bestaat, namelijk dat architectuur "een set richtlijnen" is. Ook bestaan er verschillende soorten architecturen. Om dit wat inzichtelijk te maken, zijn deze architecturen globaal in twee hoofdgroepen verdeeld, te weten IT-architectuur en Businessarchitectuur. Binnen deze hoofdgroepen is er een onderverdeling van deelarchitecturen gemaakt. Over het algemeen wordt architectuur ervaren als kostenbesparend. Verder is het een communicatiemiddel bij uitstek. Architectuur dient verhelderend te zijn voor de opdrachtgever, het is niet de bedoeling om zaken nog ingewikkelder maken. Er is zeker wel voldoende kennis over architectuur aanwezig, echter de toepassing daarvan verschilt per instantie. De meeste bedrijven hebben positieve ervaringen met architectuur en zijn er dan ook erg tevreden mee. Het management moet het belang van architectuur wel goed inzien. Ook moet de rol van de architect niet onderschat worden. Architectuur zal de komende jaren een steeds grotere rol gaan spelen. Daarom zal de behoefte aan architecten alleen maar toenemen. Deze zullen meer bedrijfsbreed worden ingezet. Met dit in ons achterhoofd, kunnen we ons de volgende vragen stellen: Is de basis voor architectuur in Nederland al gelegd? Is architectuur al in een volwassen stadium?

Met andere woorden: 'Zijn de veters al gestrikt?"


4

2. Bevindingen 2.1. Algemeen In dit hoofdstuk staan onze bevindingen uit de interviews. Ze zijn opgedeeld aan de hand van de vier hoofdvragen die aan het begin van dit document zijn gegeven.

2.2. Wat verstaat men onder architectuur? 2.2.1. Interpretatie / definitie van architectuur In het bedrijfsleven bestaan er verschillende definities van het begrip architectuur. Sommige zijn wat gangbaarder dan andere. Ook komt het voor dat er op de vraag: "Welke definitie van architectuur wordt er binnen de organisatie gebruikt?", men een geïmproviseerd antwoord geeft. Over het algemeen kan dus geconcludeerd worden dat er niet een eenduidige definitie is van "architectuur". Een centrale gedachte bij de meeste instanties is wél, dat men architectuur interpreteert als "een set richtlijnen". Dit kan zijn voor het bouwen van applicaties, systemen, infrastructuur of zelfs voor het inrichten van organisaties. Vandaar dat men vaak architectuur onderverdeelt in: Applicatie architectuur, Software architectuur, Informatie architectuur, Technische architectuur, Enterprise architectuur etc. Naast de standaarddefinities zoals IEEE-1471, ADAM en ABN-AMRO zijn er nog andere veel gebruikte definities:

'Architectuur is een set richtlijnen voor het bouwen van systemen ' 'Architectuur is de samenhang tussen systemen "en 'Architectuur is een veizameling van regels voor de samenhang tussen verschillende modules." Een veelvoorkomende vergelijking is die met de architectuur van het bouwen van een huis;

'Architectuur geeft richtlijnen hoe de deuren en ramen geplaatst moeten worden en hoe een huis ingedeeld wordt." Ook kan het zo zijn, dat er binnen een bedrijf verschillende definities van architectuur bestaan. Verschillende afdelingen kunnen dus verschillende definities hanteren omdat ze een eigen invulling geven aan het begrip architectuur.

2.2.2. Belang van de architectuur Tot voor kort was het zo dat de business zich aanpaste aan de IT. De trend is nu echter dat de IT zich aanpast aan de business, in de trend dat de IT de business ondersteunt. De belangrijkste reden is dat businessarchitectuur zorgt voor een structurering van de bedrijfsprocessen. Hierdoor worden deze processen inzichtelijker en duidelijker. Zo kan de IT zich makkelijker aanpassen aan de processen in de business. Op het gebied van de IT zorgt architectuur voor standaardisatie. Doordat bijvoorbeeld interfaces gestandaardiseerd worden, kunnen losse systemen eenvoudig gekoppeld worden. Het belang van IT-architectuur komt echter volgens velen pas goed naar voren tijdens het onderhoud van systemen. Architectuur kan er voor zorgen het onderhoud te reduceren, door een goed en degelijk ontwerp. Zo kunnen vooraf al veel oneffenheden en problemen worden vermeden. Software Architectuur 2002-2003

Immers onderhoud zorgt bij veel projecten vaak voor de grootste kostenpost. Als je deze factor dus kan reduceren, zullen de algehele kosten afnemen. Kostenbesparing is dus een van de grootste pluspunten. Over het algemeen leidt architectuur tot efficiency en flexibiliteit van zowel de processen in de business, als die van de IT. De communicatie binnen het bedrijf en met de klant kan worden verbeterd, doordat de processen gestructureerder en inzichtelijker zijn. Het belang van architectuur moet echter vooral bij het management duidelijk zijn. Zolang de beleidsvormers het nut van architectuur niet inzien, zullen ze van bovenaf ook niets opleggen. Dat is echter wel belangrijk voor het bewerkstelligen van een consequent doorgevoerde architectuur. Architectuur gaat namelijk uit van een visie op langere termijn en heeft dus vaak pas op langere termijn effect. Taak van het management is ervoor te zorgen dat dit constant doorgevoerd wordt.

2.2.3. Soorten architectuur In deze paragraaf geven wij de lezer een algemene indruk van de verschillende soorten architecturen die binnen Nederlandse organisaties voorkomen. Wij constateren dat naast de verschillende definities die er voor architectuur bestaan, er ook heel veel verschillende soorten architecturen voorkomen. In de bedrijfstakken Banken, ICT-consultancy en Productontwikkelaars komt architectuur in allerlei vormen voor. Desondanks valt in hoofdlijnen architectuur in twee groepen in te delen. Namelijk IT-architectuur en Businessarchitectuur. Binnen deze twee hoofdarchitecturen zijn er verder verschillende deelarchitecturen te onderscheiden: A. IT-architectuur Bij IT-architectuur gaat het voornamelijk om de opzet van IT-systemen. Deze architectuur brengt o.a. IT-systemen, -infrastructuren, -processen van de organisatie in kaart en toont de onderlinge samenhang tussen deze onderdelen. De IT-architectuur is onder te verdelen in de volgende deelarchitecturen: Logische architectuur Deze architectuur heeft te maken met de manier waarop systemen en of applicaties "op papier" met elkaar moeten samenwerken of verbonden (moeten) zijn. Binnen logische architectuur is er ook weer een onderverdeling in Applicatie architectuur en Software- / Systeem architectuur: v'

Applicatie architectuur Beschrijft het geheel aan applicaties en hun onderlinge samenhang die de (relatie tussen) bedrijfsprocessen ondersteunen.

V Software / Systeem architectuur Deze architectuur beschrijft de verschillende software componenten van een systeem of deelsysteem en de wisselwerking en relaties tussen deze componenten. Software architectuur kan gezien worden als een blauwdruk voor software ontwikkeling.


6

Technische- / Infrastructuur architectuur Deze architectuur beschrijft de inrichting van de ICT-infrastructuur die bestaat uit basisvoorzieningen van de organisatie voor wat betreft de hardware en hun onderlinge relaties (verbindingen / koppelingen / netwerk). Hardware architectuur Deze architectuur geeft een beschrijving van hardware componenten / devices die een organisatie wil gebruiken. Service architectuur Deze architectuur beschrijft hoe applicaties logisch opgedeeld worden in zogenoemde services. Met deze architectuur streeft men ernaar om de ICT en de business op elkaar aan te laten sluiten en de organisatie minder afhankelijk te maken van technische keuzes in de ICT. B. Businessarchitectuur Businessarchitectuur is op dit moment binnen heel veel bedrijven een "hot item". Deze architectuur geeft een bedrijfsbrede omschrijving, onder andere gebaseerd op de visie van de organisatie, de business strategie en de (bedrijfs)processen. Business architectuur maakt de organisatie er zich van bewust hoe de business in elkaar zit en functioneert. Het voornaamste doel hiervan is om de alignment tussen ICT en de business te bevorderen. Enterprise architectuur Deze architectuur beschrijft de samenhang tussen ICT-systemen en de rest van het bedrijf. Hierbij formuleert men antwoorden op vragen zoals wat het bedrijf wil zijn en wie de klantengroep is. Ook formuleert men wat er hiervoor qua ICT, organisatie, processen en besturing uitgevoerd moet worden. Andere benamingen voor deze architectuur zijn Bedrijf- of Organisatie architectuur. Informatie architectuur Deze architectuur stelt vast wat informatie is en maakt het verder mogelijk om vast te stellen wat men met die informatie wil, kan en moet. Proces architectuur Deze architectuur is opgezet in het kader van procesmatig werken. Hiermee wil men de zogenaamde "stovepipe systemen" vervangen door systemen met herbruikbare functies die vanuit diverse processtappen aangeroepen kunnen worden. Dit is met name bedoeld om een betere procesondersteuning te verkrijgen om zodoende de alignment tussen ICT en de business te garanderen. Projectarchitectuur Deze architectuur beschrijft de bedrijfsprocessen en hun onderlinge samenhang, die het projectmatig werken moet bewerkstelligen. Deze architectuur geeft richtlijnen voor de sturing binnen een project (projectmanagement).


7

Product architectuur Deze architectuur beschrijft het product en dient er-voor te zorgen dat er een architectuur is, die meerdere (communicatie) kanalen voor één of meerdere producten kan ondersteunen. Na analyse van de interviews kunnen wij vaststellen dat binnen de bedrijfstakken (Banken, ICT-consultancy en Productontwikkelaars) de benamingen voor architectuur vaak door elkaar gehaald worden en de verschillende architecturen elkaar sterk overlappen. Dit blijkt bijvoorbeeld uit Applicatie- en Software architectuur. Binnen Software architectuur worden ook Applicaties beschreven en andersom is dit ook het geval. Een duidelijke grenslijn tussen architecturen valt niet te trekken. Het valt op dat verschillende architecturen binnen één Organisatie en zelfs binnen een afdeling naast elkaar kunnen voorkomen. Dit komt omdat het niet altijd mogelijk is om met één soort architectuur de gestelde doelen te kunnen bereiken. Organisaties zijn zich er nu degelijk van bewust dat de business geruime tijd de ICT heeft gevolgd en dat het nu eens tijd is dat de ICT de business gaat volgen. Dit uit zich in het feit dat business architectuur binnen organisaties steeds belangrijker geworden is. Business architectuur ondergaat hierdoor een positieve ontwikkeling.

2.3. Architectuurmethoden en —modellen 2.3.1. Inleiding In deze paragraaf wordt ingegaan op de vraag welke architectuurmethoden en -modellen er worden gebruikt binnen Nederlandse organisaties. Uit het onderzoek is gebleken dat bedrijven verschillende visies en/of ideeën hebben over architectuurmethoden en -modellen. In de meeste bedrijven worden methoden en modellen als volgt beschreven: "Een methode beschrijft een proces, het zijn de stappen die je moet doen (dynamisch) om je doel te bereiken. Een model is meer een referentie die gebruikt wordt om zaken te beschrijven (statischJ'. Er wordt niet alleen op de vraag ingegaan welke methoden en modellen er allemaal gebruikt worden, maar hopen we ook antwoord te geven op de vraag waarom en waarvoor ze gebruikt worden. We hebben de modellen en methoden gerangschikt naar bedrijfstak. In Tabel 1 zijn de soorten architectuurmethoden en —modellen uitgesplitst naar bedrijfstak. In Tabel 2 is een uitgebreide verzameling van alle methoden en modellen te zien.


8

2.3.2. Bedrijfstakken In Tabel 2 hieronder vindt u een overzicht van de afkomst van methoden en modellen uitgesplitst per bedrijfstak. Bedrijfstak Banken

Afkomst Combinatie van methoden of modellen uit de literatuur zelfgemaakt (onderdelen uit bestaande irchitecturen) zelfgemaakt

ICT-Consultantcy

Product )ntwikkelaars

1

Waarom

Waarvoor Business, Systeem en Proces Architectuur

Eigen Visie; Communicatie naar klant makkelijker; Eoetsing Gericht op eigen producten

)ndersteunen van hun )plossingen (IT-systemen, processen) Productfamilies

Tabel 1: Architectuurmethoden en of -modellen uitgesplitst naar bedrijfstak

Binnen de bankensector bestaan de meeste architecturen uit een combinatie van methoden en modellen uit de literatuur. Omdat methoden en modellen soms één-op-één toepasbaar zijn, worden deze eventueel aangevuld. Bij alle banken is hier een onderscheid gemaakt tussen business, processen en systeem architectuur. Binnen de ICT-consultancy sector maakt men gebruik van zelfgemaakte methoden en modellen. Bij het samenstellen hiervan is er gekeken naar bestaande methoden en modellen en zijn telkens de beste eigenschappen eruit gehaald. Men heeft gekozen voor deze aanpak omdat dit de makkelijkste manier is om de problemen van de klant te analyseren en te communiceren met de klant. De methoden en modellen worden vooral gebruikt ter ondersteuning van het primaire proces van de ICT-consultants, het adviseren van klanten op het gebied van ICT en bedrijfsvoering. Verder biedt het ook een middel om tijdens en na het project te toetsen of er aan de vastgestelde architectuur is voldaan. Bij de productontwikkelaars wordt er veelal gebruik gemaakt van zelfgemaakte methoden en modellen. Deze richten zich vooral op het proces rondom het ontwikkelen van de producten. Doordat software een steeds belangrijker deel inneemt van een product is architectuur essentieel om steeds productiever en efficiënter programmacode te gaan ontwikkelen. Architectuur maakt plannen van het ontwikkelproces mogelijk zodat taken en verantwoordelijkheden verdeeld kunnen worden.


9

2.3.3. Methoden & Modellen In Tabel 2 hieronder vindt u een overzicht van modellen en methoden met hun afkomst en soort architectuur. Model/Methode

Volledige Naam

GEM Model

Generic Enterpise Model

Yourdon UML

AVB

Afkomst

Architectuur

Business; Processen; Systemen Uit literatuur Systemen Unified Modelling Uit literatuur Systemen; Software Language Zelfgemaakt

Zelfgemaakt

Specifiek

Koala

Zelfgemaakt

Productfamilie

Zachman

Uit literatuur

Zelfgemaakt

Business; Systemen; Processen Vooral Proces

Zelfgemaakt Uit literatuur

Consultant Systemen

Externe architectuur *

Business

PAM

1F 3-STD-016

Architectuur voor Verkeersbeheersi ng

Proces Architectuur Model Innovationframe

Alignment methode UIL

Unified Innovation Library

Atlas D-Method Development_______________ Methode Corporate Unified CUBA Business Architecture Corporate IT CITA Architecture

Business; Systemen; Processen Zelfgemaakt Processen; Systemen Zelfgemaakt Productontwikkeling Zelfgemaakt Business

PLC gerichte processen Communicatiemedium tussen Architect en Technici

Software ontwikkeling voor producten Alleen onderdelen gebruikt

Toepasbaarheid van klassiek modellen, documentatie structureren

Best Practices

Zelfgemaakt

Toetsing van architectuur

Positie bepaling ten opzichte van andere bedrijven

Processen

Tabel 2: Overzicht van gebruikte Architectuurmethoden en -modellen

(*Architectuur die ontwikkeld is door een andere organisatie)


10

Uit Tabel 2 is af te lezen dat er een verband bestaat tussen het type architectuur en zijn afkomst. Met name bij architectuur voor software en ICT-systemen wordt er gebruik gemaakt van methoden en modellen uit de literatuur. Een reden hiervoor kan zijn dat het begrip architectuur vanuit de ICT op gang is gekomen. Door de tijd heen is er veel ervaring vanuit de ICT opgebouwd en literatuur over dit onderwerp geschreven. Architectuur om de business en processen te beschrijven, is een ontwikkeling die nu pas op gang komt en waar nog weinig literatuur over is. Hieruit blijkt dat organisaties ver zijn in het denken over architectuur, maar op het gebied van business is het gewenste niveau nog niet bereikt. Opvallend is dat veel organisaties UML noemen als architectuurmodel. Sommige organisaties gebruiken UML om UML-diagrammen in te voegen in hun zelfgemaakte model. Andere organisaties gebruiken UML als architectuurmodel omdat met UML, systeemarchitecturen kunnen worden beschreven. Wat opvalt hierbij is dat vooral de uitvoerders (programmeurs) UML noemen. Architecten vinden het ook een prettige manier om architectuur naar de uitvoerders te communiceren. Steeds meer architecten geven aan dat een model vooral begrijpelijk moet zijn voor de mensen die er mee werken. Modellen worden ook gezien als een communicatiemiddel naar de diverse belanghebbenden. Hiervoor is al gezegd dat er met de uitvoerders graag door middel van UML wordt gecommuniceerd. Bij het management wordt vaak voor een simpelere weergave gekozen, meestal Microsoft Powerpoint. Hierbij moet door de architect worden gezorgd dat niet alle energie wordt gestoken in de werking van het model, maar in het inhoudelijk begrijpen van het model. Dit om geen vragen naar boven te laten komen zoals: "wat moet ik met die spin?". De discussie moet juist gaan over de correctheid en toepasbaarheid van het model. Doordat dit besef bij architecten aanwezig is, blijkt dat er veel ervaring is met modellen. Veel modellen overlappen elkaar. Neem bijvoorbeeld de banken waarbij de lagen Business, Processen, Appi icatie/Systemen en Technisch/Infrastructuur steeds terug komen. Sommige banken hebben voor de verschillende architecturen (business-, proces-, systeemarchitectuur) verschillende modellen terwijl andere banken streven naar één model waarin ze alle onderdelen proberen te dekken. Er wordt veel gebruik gemaakt van onderdelen van bestaande en bekende modellen zoals het 4+1 model en het Zachman raamwerk. Als organisaties hun eigen methode of model maken, gaan ze niet het wiel opnieuw uitvinden, maar maken ze gebruik van modellen die er al zijn, aangevuld met de eigen ervaring van de architect(en). De bruikbare onderdelen van de bekende modellen worden overgenomen en aangepast met specifieke zaken die voor de desbetreffende organisatie van belang zijn, bijvoorbeeld 'error handling'.


11

2.3.4. Uitvoering Soms blijkt dat verschillende afdelingen van organisaties op het gebied van architectuur langs elkaar werken. Afdelingen maken niet altijd gebruik van de kennis van andere afdelingen of binnen bedrijven zijn meerdere architectuurmethoden en -modellen aanwezig voor dezelfde zaken (producten, processen, systemen). Sommige instanties geven aan dat de gebruikte architectuurmethoden en -modellen alleen voor hun situatie geschikt is. Bij kleinere projecten die ze uitvoeren, kan het gebruik van de methoden of modellen te zwaar zijn en voor onnodige overhead zorgen: "schieten met een kanon op een vlieg". Doordat organisaties dit probleem beginnen in te zien kan worden geconcludeerd dat zij een stap verder zijn met het denken over de juiste aanpak voor projecten. Het maken van modellen is niet het enige wat organisaties belangrijk vinden. Het is ook van belang dat architectuur wordt nageleefd. Deze organisaties geven tevens aan dat niet alleen de modellen belangrijk zijn maar ook hoe deze modellen worden gebruikt, bijvoorbeeld bij het maken van programmacode. Bij sommige organisaties kan de architect duidelijke modellen maken, maar de diverse programmeurs kunnen van de code weer een bord spaghetti maken. Hierbij is het handig dat modellen toetsbaar zijn zodat het makkelijker wordt om overtredingen te signaleren. Het proces om van een architectuurmodel naar een succesvol resultaat te gaan, is onderbelicht. Daar is nog weinig onderzoek naar gedaan en er is nog weinig literatuur aanwezig. De organisaties die dit inzien, zijn de organisaties die op het gebied van architectuur verder zijn dan de rest.


12

24. Rol van de architect 2.4.1. Inleiding Er kunnen verschillende typen architecten onderscheiden worden, namelijk: - Software architect; - Procesarchitect; - IT-architect; - Enterprise architect. In de komende paragrafen komen de bovenstaande, meest voorkomende, soorten architecten met hun rollen, taken, verantwoordelijkheden en vaardigheden aan bod. Tevens zal de positie van architecten binnen de bedrijfsvoering, de verankering van architectuurdenken, de valkuilen van architecten en een toekomstgedachte de revue passeren

2.4.2. Algemene taken en kenmerken De belangrijkste algemene taken van een architect zijn het opstellen van een architectuur, het begeleiden van projecten, het toetsen van projecten en de controle van projecten. Goede architecten zijn meestal personen die een goede opleiding hebben afgerond en in de loop der jaren veel ervaring hebben opgedaan in diverse projecten. Maar niet alle architecten blijken een IT achtergrond te hebben; electrotechniek, mechanica en natuurkunde zijn hier enkele voorbeelden van. In ICT-consultancy bedrijven worden architecten intern opgeleid, terwijl architecten in niet-consultancy bedrijven hun kennis vaak opdoen in de praktijk. Belangrijk voor een architect is het bij elkaar kunnen brengen van mensen met verschillende ideeën en visies wat noodzakelijk is om uiteindelijk tot een goede architectuur te komen. Een architect moet hiermee om kunnen gaan, begrip kunnen hebben voor verschillende standpunten waarbij communicatie een sleutelrol speelt. De architect is over het algemeen het communicatiekanaal tussen de verschillende belanghebbenden. De kwaliteit van de communicatie is ook mede afhankelijk van de positie waarin de architecten zich organisatorisch bevinden. Een andere belangrijke taak voor een architect is om het begrip architectuur onder de aandacht te brengen van het management en het belang ervan proberen over te brengen. Belangrijk is om de op lange termijn gerichte kostenbesparingen van architectuur duidelijk te maken. De architect zal dan voldoende commitment krijgen vanuit het management en daardoor zal de communicatie soepeler verlopen. Commitment van het management is daarom, naast communicatie, één van de succesfactoren voor het welslagen van een project vanuit het oogpunt van de architect.


13

2.4.3. Soorten & Rollen Als eerste is er de software architect die op het technische vlak bekijkt en beoordeelt wat de mogelijkheden en afhankelijkheden van softwareoplossingen zijn en wat de haalbaarheid is. Daarbij ontwikkelt hij een softwarearchitectuur wat dient als raamwerk voor softwareoplossingen en mogelijkheden. Software bepaalt voor een steeds groter deel de prijs van een product. Een technisch product wordt tegenwoordig veelal softwarematig gestuurd. Gevolg hiervan is dat men steeds productiever en efficiënter program macode moet gaan ontwikkelen. Een goede architectuur hiervoor zal dit niet in de weg staan en juist de weg wijzen. De software architect komt in een meerderheid van de bedrijven voor omdat deze allemaal hun eigen software ontwikkelen. Ten tweede is er de procesarchitect die verantwoordelijk is voor de coördinatie van architectuur met betrekking tot de (bedrijfs)processen en zich daarnaast bezighoudt met de (bedrijfs)procesverbetering rondom de integratie van systemen. Deze architect komt veel voor bij banken die veel aandacht schenken aan hun processen. De IT-architect maakt voorstellen oftewel business cases voor architecturen die door het management worden beoordeeld. Deze voorstellen hebben betrekking op de aanpak en inrichting van de 1Cr om doelen optimaal te verwezenlijken. ICT speelt tegenwoordig een belangrijke rol, aangezien beslissingen inzake 1Cr nauw samenhangen met de beslissingen in de bedrijfsvoering. Daarom is er tenslotte de enterprise-architect die zorgt voor een bedrijfsbrede architectuur van de bedrijfsvoering. Deze organiseert de veelheid aan architecturen binnen de onderneming. De functiebenaming voor architecten loopt soms uiteen ondanks dat de personen zo goed als dezelfde taken en verantwoordelijkheden hebben. Bijvoorbeeld de architect die verantwoordelijk is voor de bedrijfsbrede architectuur wordt zowel entreprise- als lead-, als centrale architect genoemd. Naast de verschillende soorten architecten zijn er ook verschillende rollen die een architect kan hebben. Hierbij is het ook mogelijk dat één soort architect meerdere rollen kan hebben. De rol verschilt per organisatie en niet per soort, immers een soort architect is niet gebonden aan een rol. Een architect kan dus verschillende rollen hebben in een bedrijf. Voorbeelden hiervan zijn: adviseur, communicator/intermediair en uitvoerder. Elke rol zal kort omschreven worden en er wordt verteld welke rollen in welke bedrijfstak het meest voorkomen. In de bedrijfstak banken heeft een architect een breder takenpakket dan in andere door ons bestudeerde bedrijfstakken. Een overallarchitect is een voorbeeld van een rol die een architect kan hebben bij een bank. Hij moet dan businesscases' opstellen en hij coördineert de aanwezige architecturen binnen het bedrijf. Een reden voor banken zou kunnen zijn dat zij te maken hebben met risicovolle producten en diensten. Zij zullen dus misschien het belang van architectuur meer waarderen en relatief meer investeren in architectuur dan bedrijven in andere bedrijfstakken.

1

Business cases: projectvoorstel, een plan van aanpak van een potentieel project


14

Als je kijkt naar de ICT-consultancy bedrijfstak dan zie je dat een architect daar vaak de rol van adviseur of communicator/intermediair heeft. De architect is dan puur adviserend of communicator tussen de verschillende belanghebbenden. Een ICT-consultancy bedrijf heeft andere doelstellingen en opereert vanuit een ander perspectief. Zij hebben tevens een andere visie over architectuur, wat invloed heeft op het architectuurgebeuren in het betreffende bedrijf. Architecten hebben in zekere mate een soort van vrijheid in hun werk. In sommige organisaties (bottom-up) heeft de architect relatief veel vrijheid in zijn werk. In de ICTconsultancy sector komt het voor dat een architect, afhankelijk van het project, de methoden en modellen kiest die hem het beste uitkomen. Dat dit niet bij alle organisaties zo is, komt omdat methoden en modellen soms van boven worden opgedragen aan de architect (top-down). De architect heeft in dit geval weinig vrijheid. Hij krijgt opgelegd, meestal van het management, welke architectuurmethoden en/of -modellen hij moet gebruiken. Bij banken wordt de gebruikmaking van methoden en modellen veelal top-down opgelegd en de vrijheid van de architect is dus beperkt. Bij de productontwikkelaars komt ook naar voren dat ze zich aan een bepaalde methode of model moeten houden. De branche of bedrijfstak waar het bedrijf zich in bevindt, bepaalt in grote mate de visie op architectuur en het gebruik daarvan. Ook worden er verschillende definities van architectuur gebruikt (zie paragraaf 2.2.1.) Deze aspecten bepalen voor een groot gedeelte de benodigde soorten architecten en hun bijbehorende rollen. De soorten architecten en hun rollen is daarom veranderlijk. De aanwezigheid van meerdere soorten architecten geeft naar onze mening aan dat een organisatie het belang van architectuur inziet. Zij probeert op diverse organisatiegebieden (bv. software, processen) architectuur te ontwikkelen. Op een gegeven moment ontstaat er behoefte aan afstemming en/of coördinatie van architecturen. Deze behoefte impliceert dat men veel en serieus met architectuur bezig is en dat men probeert de groei hiervan te stroomlijnen. Om de afstemming tussen de verschillende architecturen op de diverse gebieden goed te laten verlopen, hebben deze organisaties veelal een enterprise architect in dienst. De aanwezigheid van zo'n 'overall-architect' duidt volgens ons op een vergevorderd (volwassen) inzicht in en omgang met architectuur.

2.4.4. Positie De organisatorische positie blijkt te verschillen als je de verschillende bedrijfstakken vergelijkt. Wat opvalt, is dat in productgeoriënteerde branches, bedrijven met productfamilies of softwareproducten, de architecten verdeeld zijn over verschillende divisies of afdelingen. Binnen banken zijn architecten vaak gepositioneerd als stafafdeling. Voor de ICT-consultancy sector geldt uiteraard dat de positie van de architect afhankelijk is van het project. Niet altijd hebben bedrijven hun eigen architecten in dienst. Het komt veelvuldig voor dat deze extern ingehuurd worden omdat de kennis gewoonweg niet in huis is. Het extern vinden van de juiste architect(en) en het goed plaatsen hiervan in de Organisatie kan moeilijk zijn en daarbij soms een langdurig proces zijn.


15

Het positioneren van architecten binnen diverse afdelingen lijkt ons een goede keuze, aangezien de architecten dan dicht bij de bedrijfsprocessen 'staan' en zich in dat domein kunnen verdiepen (domeinkennis). Architecten positioneren als stafafdeling zou nadelig kunnen zijn omdat architecten dan te ver van de werkvloer verwijderd zijn. Aan de andere kant is het voordeel van een stafafdeling dat deze meer betrokken is bij de strategie en doelen van de Organisatie, hetgeen belangrijk is bij de ontwikkeling van architectuur. De organisatorische plaats van de architecten binnen de Organisatie zal volgens ons een weloverwogen keuze moeten zijn. Bij de ICT-consultancy bedrijven worden architecten intern opgeleid en het zijn veelal senior architecten. Ervaring, kennis en communicatie zijn cruciaal bij het detacheren van architecten om door desbetreffende Organisatie serieus genomen te worden. Seniorarchitecten beheersen deze aspecten. Externe architecten hebben het probleem dat zij (meestal) onbekend zijn met de Organisatie en voor een goede samenwerking zal er dus eerst een vertrouwensband moeten ontstaan. De architect speelt als het ware een onafhankelijke rol, waarbij zij adviserend en ondersteunend optreedt. Van groot belang om de vertrouwensband op te bouwen, is inzicht in alignment tussen de IT en de Business waar het bedrijf in zit. Zodra de architect het business-perspectief voldoende aandacht geeft voor en tijdens het project, zal het vertrouwen in diens corn petenties groeien.

2.4.5. Toekomst De bedrijven in het onderzoek hebben bepaalde toekomstvisies met betrekking tot architectuur. Een voorbeeld van een blik op de toekomst is, kijken hoe het nu werkt in de bouwwereld. Daar zie je dat de architecten eigen bureaus hebben, los van de bouwers zelf. In de 'Software Architectuur' zal dezelfde vorm aangenomen worden, er zullen 'Software Architectuur' bureaus ontstaan. Dit zal naar verwachting beter werken, omdat er een scheiding ontstaat van belangen en verantwoordelijkheden tussen bouwers en architecten. Architectuur is steeds meer in opkomst, alleen wordt het nog te weinig toegepast bij de teams die ontwikkeling en onderhoud plegen. Dit komt omdat de kennis hierover bij de teams nog te gering is. In onze ogen is het nadeel van deze "bureau's" dat ze geen of te weinig kennis hebben over de bedrijfsprocessen.

2.4.6. Valkullen Er zijn helaas nog veel architecten die alleen modellen maken en documenteren, maar het samenspel en het proces naar een eindresultaat daarbij soms uit het oog verliezen. Klassieke architecten, oftewel de architecten uit de begintijd van werken onder architectuur, streven te vaak naar een te ideale situatie hetgeen (teveel) extra kosten met zich meebrengt. Hierdoor en mede door hun eigenwijze houding hebben architecten bij sommige bedrijven een 'slechte' naam. Architectuur kan ook weerstand oproepen. Iemand die al twintig jaar hetzelfde vak beoefent, kan gewend zijn om het werk op z'n eigen manier te verrichten. Architectuur kan daarbij dan als dreigend ervaren worden. Daar moet een architect mee weten om te gaan. Daarnaast wordt er bij veel bedrijven te makkelijk gedacht over de rol van een architect. Bovendien zijn architecten vaak niet voldoende betrokken bij de bedrijfsprocessen en hebben dus te weinig inzicht in het reilen en zeilen van de onderneming.


16

2.5. Ervaringen met architectuurmethoden en —modellen Over het algemeen zijn de ervaringen positief over het werken met methoden en modellen om tot een architectuur te komen. Binnen de meeste bedrijven is het begrip architectuur bekend, maar de interpretaties ervan lopen erg uiteen.

2.5.1. Architectuur als communicatiemiddel De voordelen van architectuur uiten zich met name in standaardisatie. De bedrijven hebben een taal waarin gesproken wordt. Het bevordert de communicatie tussen afdelingen binnen organisaties. In veel bedrijven wordt architectuur dan ook gezien als communicatiemiddel naar bijvoorbeeld het management. Vooral het beschrijven van technische ICT toepassingen wordt zonder architectuur als een raadsel gezien door hoger gelegen afdelingen. Ook naar de rest van de business draagt architectuur bij aan de communicatie tussen afdelingen. De kloof tussen vooral ICT en de business verkleint, waardoor er beter samengewerkt wordt. Veel bedrijven ervaren architectuur dan ook als een communicatiemiddel.

2.5.2. Architectuur als kostendrukker Op lange termijn is architectuur kostenbesparend doordat de bedrijfsprocessen flexibeler worden en dus de doorlooptijd aanzienlijk verkort. Bij bedrijven waarin architectuur al een tijd verankerd is in de Organisatie, heeft architectuur hier veel aan bijgedragen. Dit kostenbesparende effect van architectuur is in deze bedrijven dan ook duidelijk waarneembaar.

2.5.3. Architectuur en volwassenheid Zaken waar veel bedrijven echter tegen aan lopen bij architectuur en het gebruik van methoden en modellen, hebben voornamelijk te maken met de volwassenheid van architectuur in de Organisatie. Dit komt op verschillende manieren tot uiting. Ten eerste wordt geconstateerd dat vooral in organisaties als banken en ICTconsultancybedrijven architectuur voortkomt uit de ICT. Alle bedrijven zijn het er over eens dat dit omgedraaid moet worden en dat een architectuur vanuit de business moet worden bekeken. Het feit dat architectuur voortvloeit uit de ICT heeft in een aantal bedrijven echter nog z'n sporen achtergelaten. Dit is te zien aan de grote voorsprong die ICT architectuur heeft op de businessarchitectuur. Ten tweede beperken veel tools zich tot het documenteren van systemen, doordat de implementatie van architectuur zich nog in een vroeg stadium bevindt. De volgende stap is het neerzetten van een controlefunctie om te kijken of alles wel aan de gedocumenteerde vereisten voldoet. Er is echter weinig openbare documentatie beschikbaar over het uitvoeren van gedocumenteerde architectuur. Dit probleem doet zich niet specifiek voor in een bepaalde bedrijfstak. Wat wel opvalt, is dat bij productgeörienteerde bedrijven en bedrijven die hun architectuur zelf ontwikkelen de stap van het ontwerpen van de architectuur naar het implementeren ervan gemakkelijker gaat dan bij andere bedrijven.


17

Ten derde komt de volwassenheid ook terug bij het gebruik van nieuwe methoden en modellen. Veel medewerkers zijn nog bezig met projecten die niet in het kader van nieuwe architectuur worden uitgevoerd. Dit betekent dat er nog volop gebruik gemaakt wordt van oude methoden. Langzamerhand worden in de meeste bedrijven bij nieuwe projecten gekeken naar architectuur (voor zover die al aanwezig is) en worden de nieuwe methoden en modellen die deze architectuur voorschrijft, gebruikt.

2.5.4. Architectuur en projecten Tijdens projecten is de architectuur een houvast. Projectleden vallen terug op de architectuur als controle middel om te toetsen of alles naar wens verloopt. Zodoende heeft elke medewerker voor ogen wat er te doen staat en hoe het werk uitgevoerd moet worden. Bij bedrijven waarin architectuur al een zeer dagelijks begrip vormt, komt het voor dat de aanwezige architectuur niet altijd van toepassing is. Dit heeft te maken met de overweging of de opdracht of het project niet te kleinschalig is om zware methoden te gebruiken die de architectuur voorschrijft. Een oplossing hiervoor zou kunnen zijn, slechts onderdelen van methoden toe te passen. In een aantal bedrijven bestaat er van methoden een lite-versie om kleine projecten onder handen te nemen.

2.55. Architectuur en eigen creativiteit Een nadeel van architectuur waar medewerkers tegenaan lopen, is dat de eigen inbreng wordt beperkt door architectuur. De aanwezige architectuur die van toepassing is op het gebied waar gewerkt wordt, schrijft in veel gevallen tot in detail voor hoe er gewerkt dient te worden. Dit komt vooral voor bij bankinstellingen. Dit wordt niet door elke medewerker als positief ervaren, omdat er geen plaats is voor eigen creativiteit. Om de inbreng van de medewerker te vergroten kan deze, voor zover mogelijk, nauwer betrokken worden bij overleggen of beslissingen die architectuur aangaan.

2.56. Architectuur en de opdrachtgever Het laatste punt wat in de gaten moet worden gehouden, is dat architectuur de wensen van de klant niet in de weg moet staan. Architectuur is geen doel op zich. Het moet zodanig worden ontworpen dat het flexibel is naar de opdrachtgever toe. De opdrachtgever is vaak niet in staat goed duidelijk te maken wat hij precies wil. De architectuur moet er voor zorgen dat de opgestelde requirements een goed beeld geven van de vereisten van de opdrachtgever, zodat hierover geen discussie kan bestaan. De architectuur moet dus geen ingewikkelde modellen voorschrijven, die een goede communicatie met de opdrachtgever in de weg staat.


18

3. Conclusie Schoenen spelen onbewust een belangrijke rol in je leven. Net zo vormt architectuur een belangrijke basis van een bedrijf. Om lekker te lopen moeten de veters wel gestrikt zijn. Zijn de veters nu goed gestrikt? Architectuur wordt gezien als "een set van richtlijnen". Ook blijkt dat architectuur goede communicatiekanalen creëert en in grotere projecten een flinke tijdsbesparing oplevert. Tevens vergroot het de flexibiliteit en de efficiency. Al deze punten leiden tot een zodanige kostenbesparing op de langere termijn, dat het gebruik van architectuur voor grotere organisaties heel interessant is. Het uiteindelijke effect van architectuur is dus vooral betere communicatie en kostenbesparing. Men beschikt al over veel kennis van architectuur. Het begrip architectuur is bij alle organisaties bekend en het belang van architectuur wordt ingezien. De mate van volwassenheid van architectuur blijkt uit de waarde welke organisaties hechten aan business architectuur. In het verleden is vooral vanuit het oogpunt van de ICT naar architectuur gekeken. Dit is nu aan het veranderen. Doordat er nu steeds meer vanuit het businessperspectief wordt gekeken, krijgen de wensen van zowel de interne als de externe klant steeds meer gewicht bij de ontwikkeling van architectuur. Ook het belang van goede communicatie wordt ingezien en men realiseert zich dat een goede architectuur op zich al een effectief communicatiemiddel is. De architecten beseffen dat de gebruikte methoden en modellen een gemeenschappelijke taal creëren en zo wordt architectuur ook gebruikt. Dit "protocol" helpt om zaken inzichtelijker te maken. Dit is op zich heel positief en draagt zeker bij tot de ontwikkeling naar een volwassen gebruik van architectuur. Het is echter nog voor verbetering vatbaar, want vaak werken verschillende afdelingen langs elkaar heen. Zo komt het voor dat binnen één bedrijf, per afdeling verschillende methoden en modellen gebruikt worden, die onderling niet goed op elkaar aansluiten. Vrijwel alle organisaties hebben moeite met de uitvoering van architectuur. Zo blijkt dat het personeel niet altijd de methoden of modellen volgens afspraken gebruikt. Dit komt omdat het betreffende personeel vaak onvoldoende betrokken wordt bij de ontwikkeling van methoden en modellen en vaak over te weinig kennis beschikt. Dit leidt tot een gebrek aan betrokkenheid en motivatie van het uitvoerende personeel. Daarnaast bestaat er in de praktijk vaak een negatief beeld van architecten. Hierdoor wordt het advies van de architect soms niet gevolgd. Bovendien besteden verschillende organisaties onvoldoende aandacht aan de toetsing van de richtlijnen, die mede bepaald zijn door de architectuur. Bij banken is architectuur vooral uit de ICT hoek ontstaan. Hierdoor lopen zij op dat gebied soms nog wat achter de feiten aan, omdat ze nog beperkt worden door deze oude aanpak. ICT consultants hebben over het algemeen een duidelijke visie over architectuur en beschikken ook over uitgebreide instrumentaria. Zij zetten deze kennis in bij andere organisaties. Productontwikkelaars zijn al heel ver op het gebied van architectuur, dat specifiek gericht is op een bepaald product. Zij hebben minder problemen in de uitvoering. Dit komt ook, omdat ze hun eigen methoden hebben ontwikkeld en deze al heel lang toepassen.


19

De veters zitten dus al in de "schoenen", want organisaties zijn zich zeer bewust van het belang en de noodzaak van architectuur en benutten al veel voordelen van architectuur. Architecten zijn binnen de diverse organisaties aanwezig om te zorgen voor de ontwikkeling en de implementatie van architectuur. De bottleneck blijft echter een juiste implementatie; het strikken. De uitvoerders gaan nog al losjes met architectuur om, waardoor de kracht van de architectuur niet geheel tot zijn recht komt. En dan blijft het sloffen.


20

Architectuur in Nederland "Zijn de veters al gestrikt?"

Recommend Documents