Lectorale rede Lectoraat Business Innovation & Enterprise Engineering Hogeschool NOVI te Utrecht
De synergie door samenhang met bestaande methoden en technieken Uitgesproken Donderdag 2 oktober 2014
Edward van Dipten
NOVI Opleidingen/ Hogeschool NOVI
T: E: W:
030-7115615
[email protected] www.novi.nl
Bezoekadres: Kobaltweg 44 3542 CE Utrecht Postadres: Postbus 2068 3500 GB Utrecht
Geacht College van Bestuur van de hogeschool, collega lectoren, collega’s in het werk, docenten, studenten en oud-studenten, familie en vrienden,
Inleiding Tja, een inauguratie. Het is niet niets. Een mijlpaal in mijn leven. Een mijlpaal die ik samen met u mag beleven. Er zijn er velen die ik zou kunnen noemen, die hebben bijgedragen aan waar ik nu sta. Om niemand te kort te doen noem ik dan ook geen namen. Het uiteindelijke resultaat is dat ik hier nu sta. Hier, voor u. Dank dat u bent gekomen. Maar wat ga ik dan doen als lector? De leeropdracht aan het lectoraat Business Innovation & Enterprise Engineering is: “Het geven van een impuls aan de verdere ontwikkeling van het Bedrijfskundig en ICT-onderwijs op hbo-niveau door onderzoek, nieuwe werkwijzen en methoden te introduceren op een manier die operationeel te maken is voor het beroepenveld” Na de voor mij, als militair, gebruikelijke Oriëntatie- en Analyseopdracht en eerste en tweede commandantenterugkoppeling had ik een idee over wat het onderzoekveld in zou kunnen houden en welke zaken zouden kunnen worden onderzocht. In 2010 heb ik voor mijn Master onderzoek verricht naar de wijze waarop architectuur kan worden uitgevoerd, hoe kan worden omgegaan met principes en het maken van onderscheid tussen functie en constructie. Het resultaat daarvan is de Basic Enterprise Engineering Map: BEEM1. Een resultaat waar ik nog steeds volledig achtersta, maar ook een resultaat dat nog wel moest worden geoperationaliseerd. In de afgelopen vier jaar ben ik daarmee verder gegaan. Binnen Defensie heeft dit geleid tot een nieuw concept om aan Enterprise Architectuur te gaan doen: de Integrale Defensie Architectuur (IDA). Het concept is universeel en dus ook bruikbaar buiten de grenzen van Defensie. Vanavond deel ik graag met u deze ideeën.
1
http://www.demo.nl/publications/doc_download/136-dipten-edward-van-a-mulder-hans-basic-enterpriseengineering-map-van-details-naar-essentie
Het appèl Veel is er al gepubliceerd over Business & IT alignment, architectuurraamwerken en wat dies meer zij. Heel veel publicaties waarvan veel enkel maar zijn gebaseerd op persoonlijke best practices. Over architectuur in de wereld van Business & IT is evenzo veel gepubliceerd met even zo vele persoonlijke best practices. U vroeg airco. U heeft airco, toch.
Maar wat is er aan de hand in de wereld? Waar zijn we met z’n allen mee bezig? Waarom lopen we achter ieder hype en zogenaamde best practice aan? Waarom steken overheden en bedrijven zoveel geld in de IT? Waarom sluit die IT niet aan bij de bedrijfsvoering van de Business? Een paar simpele vragen. En nog eentje: waarom wordt niemand afgerekend op het ontwerp van een organisatie als dat alleen is gebaseerd op een functioneel ontwerp bestaande uit een organisatiehark en diverse orgaanbeschrijvingen? Veronderstellen we dat er geen ontwerp ten grondslag zou moeten liggen aan een goed werkende organisatie? Het technisch ontwerp van de organisatie waarin de constructie van de organisatie staat. Ten slotte wil ik nog appelleren aan het probleem van reductie versus deductie van complexiteit. De mens is niet in staat om complexiteit in één keer in zijn geheel te overzien. Mintzberg wist dit al. Vrij vertaald zei hij: “Als het werk teveel wordt, moet je het verdelen en de uitvoering gaan coördineren”. Oftewel krijg vat op het grotere geheel door het te deduceren tot kleinere delen. Zoek voor de kleinere delen naar een oplossing waarbij rekening wordt gehouden met het grotere geheel en coördineer vervolgens de uit te voeren werkzaamheden voor de realisatie. Seligman, Soll en Wijers hebben in 1989 de vijf Wijzen beschreven en hun samenhang:
The Way of Thinking (WoT) The Way of Working(WoW) The Way of Modelling (WoM) The Way of Controlling (WoC) The Way of Supporting (WoS)
Helaas gaan we heel vaak niet met deze van de vijf Wijzen aan de slag. De bekende raamwerken spreken zich niet of nauwelijks uit in de WoW en de WoM. Ze zijn vooral gericht op control! Misschien zou er moeten worden onderzocht of en in welke mate bestaande raamwerken voldoen aan deze vijf Wijzen. Ook worden problemen vereenvoudigd door deze te reduceren tot een klein, te bevatten probleem. Er wordt van alles en nog wat buiten de scope gezet. Dit zijn vaak de zaken die we als complex ervaren of waarvan we geen verstand hebben. Niet vreemd dat de oplossing dan niet past bij het grotere probleem waarvoor een oplossing werd gezocht. Dit is misschien ook één van de oorzaken van het niet slagen van projecten.
Als ik dit vertaal naar mijn domein, als militair, dan zou het erop neerkomen dat ik de tegenstander in de planning van de volgende missie maar even weg-reduceer, want de vorige keer werkte die ook al niet mee.
De propositie Zijn we in staat met slechts één methode of technologie de huidige problemen op te lossen? Misschien moeten we meer denken in de aard van de vakman. Hij heeft gereedschap nodig. Als de vakman aan de slag gaat, beoordeelt hij de klus en bepaalt hij welke gereedschap hij daarvoor nodig heeft. Een echte vakman kiest dan zijn gereedschap en dat is niet per definitie hetzelfde gereedschap als bij de vorige klus. In tegenstelling wat consultancyorganisaties ons jarenlang hebben doen geloven. Eén van de vele voorbeelden waarbij het one-size-fits-all-principe wel erg hoog in het vaandel stond. Geef de vakman dus zijn gereedschap dat hij nodig heeft voor zijn klus. Er is echter een maar. In grote organisaties waar veel projecten worden uitgevoerd, zullen de vaklui afspraken moeten maken over de gereedschapset, die zij nodig hebben. Gereedschap is echter alleen de invulling van de WoS. Er zullen dus ook afspraken moeten worden gemaakt over de andere Wijzen.
Weet wat je moet doen, op welke verschillende manieren je het aan kunt pakken. Stel de mens in zijn/haar rol centraal. Kijk naar het proces dat wordt uitgevoerd, maar kijk ook gelijktijdig naar de informatie die daarvoor nodig is en de regels die daarbij gelden. Het is absolute onzin om te stellen dat je alleen Business Process Management of Business Rules Management of Information Management op orde moet hebben. Het is een drie-eenheid in relatie tot de actor die communiceert over de dienstverlening die aan een andere actor wordt aangeboden.
Binnen Defensie zijn we aan de slag gegaan met de nieuwe opzet voor de Enterprise Architectuur. De eerste ervaringen zijn positief. Feitelijk hanteren we het Think big – Act small principe. Om het concept succesvol te laten zijn, wordt gelijktijdig gewerkt aan de kennisopbouw bij het personeel dat hierbij betrokken is. Om aan te tonen dat het concept universeel is, is het noodzakelijk om het ook toe te passen binnen andersoortige organisaties. Dat is wat binnen de op te zetten kenniskring moet gaan gebeuren. Naast deze kenniskring kunnen de uitkomsten ook worden gespiegeld aan de wetenschap. Als voorzitter van het Enterprise Engineering Institute en lid van het CIAO-network heb ik diverse contacten met universiteiten over de hele wereld. Universiteiten die ook onderzoek doen naar Enterprise Engineering. Zoals Marcel Nieuwenhuis, schrijver van The Art of Management en helaas veel te vroeg overleden, zei: “Kennis is er om te delen, niet om te bezitten.” Binnen het CIAO-network wordt volop kennis gedeeld. Het CIAO-network2 bestaat uit hoogleraren en promovendi van over de hele wereld. Deze kennis kan dus worden toegevoegd aan het uit te voeren onderzoek.
2
http://ciaonetwork.org/organization
Wat moet worden onderzocht, is in lijn met de gedachten van het Tactisch Besluitvormings Model. Hierover zal in deze rede nadere uit uitleg worden gegeven. Maar zie het alsof u op vakantie gaat. Niet raar dat u een plan maakt. U denkt na over wat u wilt, hoe dat moet en hoe één en ander moet worden geregeld. Als u uw plan heeft gemaakt, ziet u dat dingen misschien niet helemaal passen in het budget voor de vakantie. U gaat uw eisen bijstellen op basis van de mogelijkheden en middelen, die u heeft om op een zo optimaal mogelijke wijze van uw vakantie te kunnen gaan genieten en zoveel mogelijk dingen te gaan doen die u leuk lijken. U weegt voor- en nadelen met elkaar af en u maakt uiteindelijk een keuze! We zullen dus iets moeten gaan doen aan de planning van onze reis. Een reis waarbij niet altijd het einddoel zeker is, maar waar we wel tijd hebben gestoken in de planning ervan. We moeten op zoek naar de oplossingsrichting: het bestemmingsplan. Is dat engineering? Is dat Governance? Misschien wel.
Confrontatie Waar zijn de leiders, die als krullenraper in de fabriek zijn begonnen? Mensen die hun organisatie tot in de haarvaten kenden en konden doorgronden. Ja, ik spreek in de verleden tijd. Ze zijn er niet meer. We zijn overgelaten aan de moderne managers. Managers, die niet weten wat het is op de werkvloer te zijn. Managers die niet achter hun scherm vandaan komen en denken dat wat daarop wordt gepresenteerd, overeenkomt met de werkelijkheid van hun organisatie. Leiders lopen rond. Durven zich te begeven op de werkvloer, weten daardoor wat er leeft. Gaan de discussie met de werkvloer niet uit de weg en weten hun wil vanuit overtuiging over te brengen. Ze durven ook de slechte boodschap naar boven over te brengen en draaien er niet omheen. Maar ja, is dat het probleem? Deels. Als het om IT gaat, gedragen we ons als kinderen in een speelgoedwinkel. We willen alles hebben. Als het buurjongentje of buurmeisje een nieuw speeltje heeft, willen we dat ook. Oké, we zijn allemaal wat ouder. Dus gebeurt het op de golfbaan, verjaardag, of omdat je wordt overmeesterd door een gewiekste accountmanager. “Klant is koning” is in deze tijd verworden naar “Klant is kind”. Net als de jeugd vertellen we dat we al die nieuwe snufjes absoluut nodig hebben. Dat er zonder die snufjes geen bestaan meer is. En we betalen er met z’n allen grof geld voor. Als we alles wat er op internet staat mogen geloven, is zelfs de piramide van Maslow al aangepast op het nieuwe overleven.
De trends en hypes zijn veelal gebaseerd op best practices. Is daar iets mis mee? Ja!!! Veelal zijn het ideeën die niet door onderzoek zijn gevalideerd en ook niet zijn gebaseerd op een theorie waardoor het herhaalbaar en opleidbaar wordt. Misschien is dat wel de reden waarom ze na een tijdje weer verdwijnen. Gelukkig maar. Ondertussen is er veel geld geïnvesteerd door organisaties. De handige accountmanagers hebben weer iets aan de man gebracht, geld binnengehaald en hun bonus gescoord. Eind jaren ‘90 en begin jaren 2000 kenden we dit als “Seagull Consultancy”, ook wel meeuwengedrag: “Krijsend binnenvliegen, de boel onderschijten en stilletjes weer vertrekken”. Een hype is als een accuboormachine van € 25. Na gebruik gooi je ‘m weg. Feit is dat hypes in de ICT meer kosten dan € 25! Daar heb je geen onderzoek voor nodig. Gelukkig begint er een vorm van besef te ontstaan dat we niet alleen over duurzaamheid moeten spreken in de zin van het milieu en dergelijke. Ook in de zin van bijvoorbeeld software dient sprake te zijn van duurzaamheid. Software slijt niet door het gebruik, maar door het onderhoud dat eraan wordt gedaan. Verelst en Mannaert hebben op basis van de wetten van Lehman op een fundamenteel andere wijze software ontwikkeld. Ook voor organisatie geldt duurzaamheid. Niet in de zin dat zij aan milieu doen, maar omdat de essentie van een organisatie helemaal niet zo snel verandert als wordt verondersteld. De echte essentie van een organisatie verandert pas als een organisatie een nieuwe markt aanboort of een bedrijfstak outsourcet. Dan is er nog het probleem van de velen op best practices gebaseerde raamwerken. Ook de Referentie Architecturen van Rijk en Overheid zijn in principe raamwerken, zoals de NORA, de EAR (oude MARIJ), PETRA, GEMMA, WILMA, enzovoort. Maar ook raamwerken als het IAF, TOGAF en dergelijke. Maar wat is het probleem van de raamwerken? Je kunt stellen dat alle raamwerken wel een redelijke WoT hebben en een compleet uitgewerkte WoC. Ze spreken zich veelal niet of onvoldoende uit over de WoM, WoW en de WoS. Als je geen opzet hebt voor de WoM, WoW en de WoS: wat is dan de waarde van de WoC? Simpel gezegd: als je niet weet hoe je werkt en waarmee, wat kun je dan controleren?
Confirmatie Maar wat kunnen we leren vanuit andere vakgebieden? Is er echt een verschil tussen het bouwen van een organisatie en het bouwen van een vliegtuig, gebouw of een auto? In de wereld van de techniek wordt duidelijk onderscheid gemaakt tussen functie, de specificaties, en constructie, het te realiseren ontwerp. We hebben in de afgelopen decennia onze wereld steeds complexer zien worden. De vraag is wat kunnen we eraan doen. Helaas is dat antwoord niet simpel. Frederick Brooks heeft daar heel duidelijk over geschreven in zijn artikel “No silver bullit”3. In dit artikel zet hij uiteen dat er twee soorten van complexiteit bestaan: 1. Essential complexity: de complexiteit die organisatorisch moet worden opgelost; 2. Accidental complexity: de complexiteit die is ontstaan door de informatiesystemen waarmee we werken en de fouten die daar in zitten. Feitelijk geeft hij al het antwoord over hoe we het probleem kunnen oplossen. Namelijk, reduceer eerst de essentiële complexiteit in een organisatie voordat je een systeem gaat specificeren, ontwerpen, bouwen en testen.
3
http://faculty.salisbury.edu/~xswang/Research/Papers/SERelated/no-silver-bullet.pdf
Rob Poels heeft met zijn onderzoek4 naar de wijze waarop ICT de toegevoegde waarde van mensen en middelen kan vergroten, aangetoond dat de gebruikelijke interventies die we toepassen niet leiden tot het gewenste resultaat in de verandering van de organisatie en de toenadering tussen Business en IT. Voor een deel dragen de interventies, die Poels beschrijft als zijnde dialoog bevorderende interventies, ook bij aan het perspectief relatie. Communicatie en relatie zijn immers sterk met elkaar verbonden (dialoog): - ICT expliciet opnemen in het strategieproces; - Organiseren van een multidisciplinair ICT-beleidsvormingsproces; - Iemand aanstellen of ontwikkelen tot hybride CIO; - ICT-projecten linken aan de business-strategie; - Trainen van ICT’ers: denken en praten in businesstaal; - Optimaliseren serviceproces. Er is echter wel een aanzienlijk verschil in waardeoordeel tussen Business en IT. Dit waardeoordeel uit zich vooral op het gebied van gedeelde doelen, risico’s en beloningen maar ook op de onderlinge relatie en het daarvoor benodigde vertrouwen. De te selecteren maatregelen zullen zich vooral op deze aspecten moeten richten. Het pijnlijke is dat de zes punten op het gebied van de te nemen maatregelen om de dialoog tussen business en IT te bevorderen door Poels al in 2007 zijn beschreven. Nu zijn het de resultaten van het onderzoek van o.a. Forrester en Deloitte dat begin van 2014 is uitgevoerd binnen Defensie. Dit is meer dan oude wijn in nieuwe zakken. Dit is onkunde. Niet op de hoogte zijn van onderzoeksresultaten die je in de eigen organisatie kunt gebruiken. Ik kende deze feiten pas in 2009 en wat heb ik ermee gedaan. Niets? Nee, zeker niet! Het is gebruikt in mijn onderzoek binnen het onderdeel waar ik in die tijd diende. Maar ik kende toen niet het belang, dat het kon hebben voor mijn organisatie. Onkunde of de boodschap niet op de juiste plaats kunnen laten landen? Op het gebied van softwareontwikkeling zijn ook ingrijpende veranderingen gaande. Zoals gezegd, slijt software niet door het gebruik, maar door het onderhoud dat eraan wordt gedaan. Verelst en Mannaert hebben op basis van de wetten van Lehman op een fundamenteel ander wijze software ontwikkeld. In 2011 is een proof of concept5 met deze fundamenteel ander wijze van software ontwikkelen van Verelst en Mannaert uitgevoerd in een samenwerking tussen de Universiteit van Antwerpen, Capgemini en het Command & Control Centre waar ik toen werkzaam was. Het resultaat was softwareontwikkeling die 2 tot 2,5 maal sneller was en evolueerbaar. De factor 2-2,5 is vastgesteld van een dubbelblind uitgevoerde functiepuntanalyse. Ook bleek het mogelijk te zijn om in één dag tijd is er van Javastack te wisselen. Zeer recent, zomer 2014, is een soortgelijk onderzoek door Klaas Meijer, een afstudeerder van mij, uitgevoerd bij de Belastingdienst. De resultaten laten een nog grotere voortgang zien in doorlooptijd dan drie jaar geleden het geval was. Maar ja, theorie is niet het ding van de pragmaticus. De pragmaticus is een menstype dat gaat voor de actie: geen plan vooraf en recht op het doel af. Wat raar dat we in het militair operationele wereld beginnen met een plan na de ontvangst van de opdracht.
4 5
Haal meer uit uw ICT, Interventies die ertoe doen, Poels, 2007 http://www.nl.capgemini.com/resource-file-access/resource/pdf/Exploring_Normalized_Systems_Potential_for_Dutch_MoDs_Agility_0.pdf
Militair denken in de lijn van het Tactisch Besluitvormings Model (TBM). In het kort komt het neer op de volgende stappen: Oriëntatie en analyse opdracht; 1e en 2e Commandantenterugkoppeling; Denken in de intent van de commandanten 1 en 2 hoger; Kiezen voor de uit te werken haalbare en realistische scenario’s; Validatie: Het testen van de scenario’s; Besluitvorming o.b.v. voor- en nadelen van de scenario’s; Besluiten; Bevelsuitgifte en wilsoverdracht van de commandant. Uit deze zeer korte analyse, niet gebaseerd op empirisch materiaal, kunnen we dus de conclusie trekken dat de militair geen pragmaticus is, want die is opgeleid vanuit het TBM of een daarop gebaseerde verkorte variant. Een conclusie in relatie tot het onderzoeksveld is dat we echt op zoek moeten naar een andere Wijze van Werken. Theo Mulder en Hans Mulder geven aan de hand van onderzoeksresultaten6 van The Standish Group aan dat de oorzaak van mislukkingen niet alleen afhankelijk is van de grootte van een project of de grootte van het systeem. The Standish benoemt drie factoren: 1. Projectomvang; 2. Systeemomvang; 3. Organisatieomvang. Als we dat weten, waarom duren projecten dan zo lang? Zo zijn de systemen die moeten worden gebouwd te groot en zitten er in de projectorganisatie honderden mensen. Kunnen we het klein krijgen? Dat kan als we het paradigma van functie en constructie volgen zoals gebruikelijk is in de mechanica. Als we het wat en waarom duidelijk kunnen scheiden van het hoe en waarmee. Het is nogal een verschil of je over het zagen, vijlen of schuren spreekt. In alle gevallen spreken we over verspanen, maar het is niet allemaal hetzelfde. En als er dan verspaand is, is het eindresultaat nog niet bereikt, want er is gezaagd of geschuurd voor een heel ander doel. Om dat doel te bereiken, zijn er ander gereedschappen nodig. En als je kiest voor gereedschappen, kies dan ook voor gereedschappen die stabiel zijn. Stabiel in de zin van: het kan bij herhaling worden gebruikt, er kan op worden opgeleid, opleidingen zijn gecertificeerd waardoor er garantie is op kwaliteit. Die aanbieding voor de goedkope accuboormachine is natuurlijk een perfecte keuze voor de hobbyist. Als de accu minder wordt of het niet meer doet, gooi je hem weg. Sorry, dan lever je het in bij het afvalverwerkingstation. Waarom koopt de vakman die machine dan niet? Omdat hij niet zeker is van het resultaat dat hij ermee kan bereiken.
6
Mulder en Mulder, Waarom grote ICT-projecten vaak mislukken, mei 2013, Informatie
Om de constructie van een organisatie te kunnen bepalen, is een heel ander denkwijze noodzakelijk dan het functioneel-denken. Die denkwijze biedt DEMO7 (Design & Engineering Methodology for Organisations). Deze methodologie is ontwikkeld door Jan Dietz en is in de afgelopen jaren meer en meer geoperationaliseerd, waardoor het steeds breder wordt toegepast binnen bedrijven en projecten. Bij de genoemde proofs of concept binnen Defensie en de Belastingdienst is DEMO gebruikt om de basis te leggen voor het gehele systeemontwerp. Dit zijn slechts twee voorbeelden. Het Enterprise Engineering Institute8 beschikt over tientallen voorbeelden. Een ander punt is skills. Vakvolwassenheid. Dat kun je alleen bereiken door te trainen, trainen en nog eens te trainen. Trainen op basis van een goede en gedegen basis. Voetbal leer je niet uit een theorieboek. Ook al zijn de grootste voetballers ooit gewoon op straat begonnen, ze zijn uiteindelijk groot geworden door de kennis die aanwezig was bij hun club. Kennis die ze hebben overgenomen en in de praktijk brengen in hun spel. Maar dat is geen vanzelfsprekendheid. Van Gaal heeft hierover op z’n Van Gaal’s uitleg gegeven aan managers9. We zien als we naar het Nederlands elftal kijken een trainer, zijn assistenten en 23 uitverkoren spelers. Wist u dat de organisatie van het Nederlands elftal een organisatie betreft van 60 mensen? Van Gaal liet niets aan het toeval over en prepareerde het elftal voor iedere wedstrijd met bijna militaire precisie. Een operatie die ook vrijwel gelijk is aan een militaire operatie. Rehearsal, vooroefening, is een heel belangrijk aspect om te komen een goed resultaat. Kent u bedrijven waar wordt getraind in de bedrijfsvoering of in projectmanagement? Training waardoor aanvallers, backs, verdedigers en de doelman onderling weten wat ze moeten doen en wat hun rol is in het spel. Ik ken ze niet. Alles bestaat uit pure vanzelfsprekendheden. Onder het motto: “dat begrijp je toch wel”. In het militair operationele domein wordt wel getraind voor een succesvolle bedrijfsvoering: de commandovoering. In het traditionele grootschalig conflict traden we op met twee-voor-één-achter. In het voetbal hebben we 3-3-4, 2-5-3. Wat hebben we voor systemen in de bedrijfsvoering? In het projectmanagement? Niets! Een grote hoeveelheid “best practices” en mensen. Best practices die smelten als sneeuw voor de zon en mensen die niet meer van elkaar weten wat ze doen omdat ze met te veel zijn.
Conclusie In de afgelopen jaren, na de afronding van mijn master, bleef het probleem “Hoe kunnen we op een praktische manier een goede Enterprise Architectuur voor Defensie opzetten?” bestaan. Twee jaar geleden ben ik, bij toeval, tijdelijk te werk gesteld, bij het organisatiedeel dat binnen Defensie verantwoordelijk is voor de Enterprise Architectuur van Defensie. De DIVA, Defensie IV Architectuur, was zo goed als mislukt. Vreemd? Nee, het Amsterdams Informatie Model (Maes, Truijens en Abcouwer) was dusdanig verbouwd dat het uit balans was geraakt. Het AIM is gebaseerd op het Strategic Alignment Model van Henderson en Venkatraman. Maar de toenmalige Hoofddirectie Informatie en Organisatie was niet van het verrichten. Dus werd Verrichten als onderdeel van het IAM verwijderd. Dat betekende dat het oorspronkelijke, onderliggende model van Henderson en Venkatraman werd gehalveerd. Een onbewuste en onkundige actie waardoor de logische samenhang verloren is gegaan.
7
http://www.demo.nl/ http://www.ee-institute.com/ 9 https://www.youtube.com/watch?v=Ac7Bk7fhbb4 8
Omdenken, dus??!! En vooral volwassen worden in het vakgebied, zodat we met de business in gesprek kunnen gaan. Maar ook zoals Hans Mulder heeft betoogd voor de Commissie ICT van de Tweede Kamer: maak projectomvang, systeemomvang en de projectorganisatieomvang kleiner. Hij onderbouwt zijn voorbeelden op basis van jarenlang onderzoek van de The Standish Group. Jan Hoogervorst heeft de Commissie geadviseerd om de governance competentie in de top te vergroten. Adosh Van der Heide pleit voor het verhogen van het kennisniveau van opdrachtgevers in ICT‐projecten, niet over ICT zelf, maar over de impact van ICT op de bedrijfsinteractie, en de bedrijfsinformatie. Jan Dietz pleit voor het toepassen van Enterprise Engineering. Alle vier begeven zich al jaren op het nieuwe terrein van Enterprise Engineering. Ze redeneren vanuit de constructie van een organisatie om wat de organisatie functioneel moet doen, te kunnen realiseren. Om functioneel iets te laten gebeuren, zijn altijd verschillende oplossingen mogelijk. Dat is het terrein van het organisatieontwerp: engineering. Dit is iets heel anders dan harken en orgaanbeschrijvingen, die functioneel georiënteerd zijn op het wat en waarom. Je weet dan nog steeds niets over de werking: het hoe. En wat er moet worden gebouwd: het waarmee. Door het inzicht dat ik heb gekregen met het onderzoek voor mijn Master is bij mij het idee ontstaan voor de opzet van een nieuwe vorm van Enterprise Architectuur. Feitelijk is het niets nieuws, maar heb ik bestaande methoden, technieken en methodologieën gebruikt en die, als gereedschappen, in samenhang toegepast. Binnen Defensie is dit verworden tot de Integrale Defensie Architectuur. De keuze voor bestaande methoden, technieken en methodologiën is zeer bewust genomen. Dit maakt het mogelijk om civiele, gecertificeerde opleidingen van de markt te gebruiken. De engineering competentie moet dus ook verder worden ontwikkeld naast de governance competentie die Hoogervorst beschrijft. We zullen moeten gaan onderzoeken op welke wijze al het werk dat in de afgelopen jaren is gedaan met elkaar in relatie kan worden gebracht. Op welke wijze kunnen we bestaande methoden en technieken in samenhang bij elkaar brengen, waardoor ze elkaar versterken om Enterprise Engineering als vakgebied volwassen te laten worden. In het begin heb ik aangegeven dat ik geen namen zou noemen. Toch noem ik er één, mijn vriend Hans Mulder, waar ik al jaren mee optrek in het veld van onderzoek, onderwijs en ondernemen. Hans, dank dat ik een stukje met je mee mocht lopen. Met veel plezier draag ik deze rede aan jou op. Ik heb gezegd.
Governance vanuit het functie- en constructieperspectief De BASIC ENTERPRISE ENGINEERING MAP Edward van Dipten Hans Mulder
“Complexity is one of the great problems in environmental design” (Christopher Alexander). Dat geldt ook voor de ontwikkeling van organisaties en informatiesystemen. Om de complexiteit van de ‘eigen’ organisatie en ‘eigen’ systemen te reduceren en te beheersen, is een totaalbeeld van de omgeving en de eigen positie nodig. Architectuur is daarvoor een belangrijk middel. Maar wat als de architectuur niet inzichtelijk is, zelfs als complex wordt ervaren en weinig toegevoegde waarde lijkt te hebben? Veel organisaties kampen met dit probleem. De paradox van enerzijds een als complex ervaren architectuur (raamwerk) en anderzijds de noodzaak van complexiteitsreductie was de inzet van een nader onderzoek. Het onderzoek heeft geleid tot een theoretisch model voor Enterprise Architectuur (BEEM10) dat het ICT-werkterrein bestrijkt en praktisch toepasbaar blijkt. BEEM is het resultaat van een onderzoek in het kader van een Master Thesis voor de opleiding Master of Informatics aan de Hogeschool Utrecht. Het onderzoek is in 2010 uitgevoerd binnen de defensieorganisatie met deskundigen op het gebied van de Defensie Informatie Voorziening Architectuur (DIVA). Daarnaast hebben diverse externe experts bijgedragen aan het onderzoek. Het onderzoek is uitgevoerd op basis van onder meer twee Group Support Sessies (Mulder, 2006). BEEM blijkt in de praktijk een uitstekend model te zijn om inzicht te krijgen in de samenhang van activiteiten en resultaten binnen het werkterrein van business en IT. Binnen Defensie, maar ook daarbuiten, heeft het de betrokken architecten en ontwerpers bewust gemaakt van het verschil tussen functie en constructie. Hierdoor is het mogelijk om duidelijk afgebakend de verschillende onderdelen waaruit een organisatie/systeem is opgebouwd te benaderen en vast te stellen welke principes moeten worden opgenomen in de architectuur. Ook is er een bewustwording opgetreden dat principes niet ontstaan vanachter een tekentafel. Het merendeel van de principes ontstaat namelijk tijdens de ontwikkeling. Beleidsmakers en architecten kunnen met deze kennis voorkomen dat er nutteloze principes worden geformuleerd, die vanuit de theorie misschien kloppen, maar in de praktijk nooit worden toegepast. De schrijvers van dit artikel menen dat de uitkomsten van dit onderzoek bruikbaar zijn voor elke organisatie. Inleiding In de jaren 90 is het zogeheten L_PASO-model [Dietz, 2001] ontwikkeld voor de Vereniging van Register Informatici (VRI). Het model had tot doel inzicht te verschaffen in de activiteiten en de daarvoor benodigde competenties van alle spelers in het ICT-werkterrein. Het L_PASO-model is mede gebaseerd op de systeemsoorten en de systeemoriëntaties zoals die ook in DEMO (Design and 10
Basic Enterprise Engineering Map
Engineering Methodology for Organizations) worden onderkend [Dietz, 2006]. Enkele jaren later is het L_PASO model in een generieke vorm en met een verdere uitwerking van het competentiedeel uitgebracht onder de titel “Matchen op competenties” [Dietz, 2004]. DEMO is een methodologie voor Enterprise Engineering die voldoet aan alle criteria van het Enterprise Engineering Paradigm11. Organisatie-, Informatie- en ICTproblemen worden op een holistische wijze aangepakt vanuit de premisse dat die problemen onderling gerelateerd zijn. Deze alomvattende aanpak wordt praktisch mogelijk gemaakt doordat DEMO is gebaseerd op een degelijk theoretisch fundament, met daarop krachtige instrumenten om de complexiteit te beheersen en reduceren. Een van de componenten van DEMO is het Generic System Development Process (GSDP) [Dietz, 2008] Volgens het NGI (Nederlands Genootschap van ICTprofessionals) behoort DEMO tot de meest complete raamwerken voor architectuur [Berg, M. v. et al., 2009]. Het L_PASO-model Om begrip te krijgen van de complexiteit en dynamiek van het werkveld van de architect gaan we nader in op het L-PASO-model. Het model ordent het ICTwerkterrein langs drie dimensies: systeemsoort, systeemoriëntatie, en activiteitsoort. Ze worden hieronder besproken. Systeemsoort geeft de indeling van een organisatie in drie aspectsystemen (organisaties), gebaseerd op de drie kwaliteiten van mensen met betrekking tot informatie en communicatie: forma, informa en performa [Dietz, 2006]:
B-systeem (Bedrijf; originele actoren). I-systeem (Informatie; rationele actoren). D-systeem (Data-infrastructuur; formele actoren).
Figuur 1 De systeemsoorten (Dietz, 2004) De actoren in het B-systeem creëren originele (nieuwe) feiten door met elkaar commitments aan te gaan over de levering van producten en diensten aan elkaar. De processoren in het I-systeem bewerken bestaande originele feiten tot informatieproducten zoals rapportages, jaarrekeningen, overzichten en dergelijke. Het I-systeem is ondersteunend aan het B-systeem, d.w.z. actoren in het bedrijfsproces (B-systeem) gebruiken het I-systeem ter ondersteuning van hun
11
Zie het Enterprise Engineering Manifesto (www.ciaonetwork.org)
onderlinge communicatieve acties (het aangaan en nakomen van commitments) en van hun besluitvorming. Een I-systeem is een conceptueel systeem, dat wordt gerealiseerd d.m.v. infrastructuursystemen (D-systeem), zoals e-mailsystemen, besturingssystemen, databasemanagementsystemen, maar ook alle elektronische formulieren waar mensen in organisaties dagelijks mee werken. De operatoren in het D-systeem dragen zorg voor opslag, transport, kopiëren en dergelijke. Organisaties zijn heterogene systemen en zijn samengesteld uit de drie aspectsystemen. Systeemoriëntatie. Binnen de drie aspectsystemen systeemoriëntaties: functie en constructie.
is
sprake
van
twee
Figuur 2 De twee systeemoriëntaties Vanuit de functieoriëntatie wordt gekeken door de bril van de gebruiker van het systeem. Het systeem wordt in beschouwing genomen als black box, dus alleen vanuit het perspectief ‘gedrag’ (zie Figuur 2). Kijkt men vanuit de constructieoriëntatie dan wordt gekeken door de bril van de bouwer. In dat geval wordt het systeem beschouwd als een white box, dus hoe het systeem inwendig werkt en is samengesteld (zie Figuur 2). Wanneer een bestuurder aan de bouwer of monteur van zijn auto zou vragen het verlichtingsysteem - een functie van de auto - te verwijderen, dan zal de constructeur antwoorden dat er geen één-op-één relatie bestaat tussen het functionele gedrag en de constructie van de auto. Dit is vergelijkbaar met de n-op-m-relatie tussen een black en white box bij een functioneel ontwerp en technisch ontwerp van bijvoorbeeld informatiesystemen. In Figuur 3 is zijn de systeemsoorten in relatie gebracht met de systeemoriëntaties. De functie (F) van een B-systeem wordt bepaald door de behoeften van omgeving van de organisatie. De functie van een I-systeem wordt bepaald door de constructie (C) van het B-systeem. De D-organisatie is vervolgens een doorvertaling van de Iorganisatie. De functie van een systeem is daarmee de ‘fit’ tussen het systeem en (de constructie van) het te ondersteunen systeem.
Figuur 3 Systeemsoorten en systeemoriëntaties (Dietz, 2004) Activiteitsoorten. Aan de hierboven beschreven concepten voegt Dietz (2001) met het L_PASO-model een dimensie toe: activiteitsoorten. Hij onderkent vier activiteitsoorten: ‘Architectureren’, ‘Ontwikkelen’, ‘Implementeren’ en ‘Beheren’. Met ‘Beheren’ wordt de ‘life cycle’ van een systeem gesloten. Architectureren moet leiden tot een set van functionele en constructionele principes die voorschrijvend zijn voor het ontwerpen van een klasse van systemen. Functionele principes worden toegepast tijdens het functieontwerp van een systeem. Constructionele principes worden toegepast tijdens het constructieontwerp van een systeem. In beide gevallen kan onder systeem worden verstaan een organisatie (business), een ondersteunend informatiesysteem of een ondersteunend data/infrastructuursysteem. Onder principes worden ook patronen en standaarden begrepen. Principes zijn ondubbelzinnig geformuleerd. Functiespecificaties en constructieontwerpen kunnen worden getoetst aan de geldende principes. Onder Ontwikkelen wordt verstaan het ontwerpen, bouwen en testen van systemen. Ontwerpen kan worden beschouwd als het bedenken en kiezen van een systeem als oplossing voor een probleem. Hierbij vormen de principes uit Architectureren het normatief kader. Bouwen wordt gezien als de realisatie van het ontwerp. Testen is de daaropvolgende verificatie van de constructie, werking en de capaciteit van het systeem, en de validatie van de functionaliteit van het systeem. Implementeren is het in werking stellen van een ontwikkeld systeem. Onder Implementeren vallen het installeren van het systeem en activiteiten als het voorbereiden van de organisatie op de verandering en de conversie van de oude naar de nieuwe situatie. In de voorbereiding zijn het opleiden van de gebruikers of het aanpassen van de bestaande organisatie activiteiten waarin moet worden voorzien om de implementatie succesvol te laten zijn. Beheren is het in bedrijf houden van het systeem. Dietz (2004) maakt hier onderscheid in twee subactiviteiten. De ene is het werkend houden van het systeem zoals het is geïmplementeerd: operational management. De andere subactiviteit is het systeem gedurende de levensduur optimaal te houden voor de gebruiker: changemanagement. Dit betekent dat veranderende wensen en eisen worden gesignaleerd, beoordeeld en doorgevoerd.
Figuur 4 Het L_PASO-model (Dietz, 2001; 2004)
In Figuur 4 is het resulterende L_PASO-model uitgebeeld. De dimensies systeemsoort en systeemoriëntatie vormen de kolommen van het model. Met de dimensie activiteitsoort worden aan de zes kolommen vier rijen toegevoegd: Architectureren, Ontwikkelen, Implementeren en Beheren. De vierentwintig cellen representeren de activiteiten die binnen het ICT-werkterrein plaatsvinden. Dietz (2001; 2004) geeft aan dat voor elk vlak specifieke competenties nodig zijn om de activiteit op de juiste wijze uit te voeren. Het GSDP In figuur 5 is het GSDP afgebeeld (Dietz, 2008). Links staat de constructie van het gebruikende systeem (using system). Rechts wordt de constructie weergegeven van het ondersteunende systeem (object system). Beide systemen zijn weergegeven als white box vanwege de systeemoriëntatie ‘constructie’. Tussen deze twee systemen, gebruikende en ondersteunende, is de functie weergegeven van het ondersteunende systeem (black box). Het GSDP is onafhankelijk van een systeemsoort. Van het gebruikende systeem (using system) wordt afgeleid welke functionele requirements van toepassing zijn op het ondersteunende systeem (object system). De functie-oriëntatie is daarbij leidend om het gewenste gedrag van het ondersteunende systeem vast te stellen. De functionele requirements worden aangevuld met de geldende functionele principes vanuit de architectuur. In het GSDP (Figuur 5) is architectuur een set normatieve regels (principes) waaraan een ontwerp moet voldoen. Het GSDP geeft alleen aan dat er principes vanuit de architectuur zijn, maar niet op welke wijze deze ontstaan. BEEM geeft hier wel antwoord op.
Figuur 5 Generic System Development Process (Dietz, 2008) Vanuit het gebruikende systeem worden ook de constructionele requirements afgeleid. Samen met het vastgestelde functioneel ontwerp en de geldende constructionele principes vormen ze de input voor het constructionele ontwerp. Op deze wijze wordt de constructie van het ondersteunende systeem (object system) vastgesteld, op het meest abstracte, en idealiter ontologische, niveau, waarna het systeem wordt ingericht (engineering) en geïmplementeerd. Het is ook mogelijk om uit een geïmplementeerd systeem het constructieontwerp af te leiden. Dit is weergegeven door de pijl ‘reverse engineering’ (bij het ‘using system’). Zowel de beschrijving van de ‘object system function’ als die van de ‘object system construction’ zijn vrij van implementatie. ‘Engineering’ levert de te implementeren vorm van de constructie op.
Met de kennis dat er drie aspectsystemen zijn, biedt dit de mogelijkheid om met drie GSDP’s een keten te vormen (bovenaan Figuur 6) en deze in relatie te brengen met de systeemsoorten (onderaan Figuur 6).
Figuur 6 Het GSDP als keten BEEM Het “GSDP als keten” (Figuur 6) is vervolgens verder uitgebreid door er de vier activiteitsoorten aan toe te voegen. Verticaal zijn in het model de activiteitsoorten gepositioneerd. Horizontaal staan de systeemsoorten met daarbinnen de systeemoriëntaties: functie en constructie. Architectureren en Beheren enerzijds en de toevoeging van strategievorming anderzijds vormen daarnaast de uitbreiding op het GSDP, waardoor de BEEM ontstaat (zie Figuur 7). Ontwikkelen en Implementeren maken feitelijk al deel uit van het GSDP. De meerwaarde t.o.v. GSDP is dat BEEM hiermee een landkaart biedt voor het gehele werkterrein.
Figuur 7 Basic Enterprise Engineering Map (BEEM12) BEEM wordt hierna in het kort uitgelegd aan de hand van het I-systeem van een organisatie (zie Figuur 8). Een soortgelijke uitleg kan worden gegeven voor het B- en het D-systeem van een organisatie. De constructie (1) van de B-organisatie (links) wordt (uiteindelijk) ondersteund door de constructie (1’) van de I-organisatie (rechts). Beide zijn daarom weergegeven als een white box (witte kader). Tussen deze twee constructies bevindt zich de functie (2) van de I-organisatie, voorgesteld als een black box. De specificatie van de functie is het resultaat van het ‘functional design’. Het functioneel ontwerp is gebaseerd op enerzijds de ‘functional requirements’ (3) en anderzijds de ‘functional principles’ (4). Het ontwerp van de constructie wordt gevoed door de vastgelegde functie van de Iorganisatie (2), de ‘constructional requirements’ (5) , en de ‘constructional principles’ (6). Binnen de activiteitsoort Architectureren (zie figuur 8) vindt de afweging plaats of bepaalde delen van de functiespecificaties (7) of constructieontwerpen (8) worden opgenomen in de architectuur voor toekomstige systemen. De architectuur wordt ook gevoed vanuit standaarden, weten regelgeving, e.d. (9). Architectuur legt dus beperkingen op aan de ontwerpvrijheid van de ontwerper, bovenop de requirements. Het verschil is dat requirements specifiek zijn voor één systeem en dat architectuur geldt voor een klasse van systemen. 12
http://www.ee-institute.com/
Op basis van het (idealiter: ontologische) ontwerp vindt de engineering van een systeem plaats. Na het testen wordt het systeem geïnstalleerd en de functie van het systeem binnen de organisatie geïmplementeerd (10). Tijdens Beheren is het mogelijk dat er behoefte is aan functionele of constructionele wijzigingen (11). Deze leiden tot aangepaste requirements, die op hun beurt leiden tot een gewijzigd ‘functional design’ (2) en ‘constructional design’ (1’). Kansen en beperkingen van BEEM Figuur 8 Werking van BEEM BEEM geeft de stakeholders in het ICTwerkterrein een gezamenlijk referentiekader waardoor zij in staat zijn om ieders positie in het terrein helder te bepalen. Van elk onderwerp kan direct worden aangeven tot welke systeem- en activiteitsoort het behoort en of het vanuit functie- of constructieperspectief moet worden benaderd. BEEM maakt ook een duidelijk verschil tussen architectuur enerzijds en het creëren van een oplossing, specificatie en ontwerp, anderzijds. Daarmee wordt het onderscheid tussen het hanteren van normen en het creëren van oplossingen ondubbelzinnig. Voor een enterprise maakt dit het toetsen van specificaties en ontwerpen aan gestelde normen ook eenduidiger. Architectuur geeft de ontwerper het kader waaraan hij zijn specificatie en ontwerp kan toetsen om te zien of hij binnen de norm blijft. Aan de Enterprise Architect biedt het de mogelijkheid om te beoordelen of een specificatie of ontwerp voldoet aan de geldende architectuur. Natuurlijk zijn er punten waarop BEEM kan worden uitgebreid. In de afgelopen jaren hebben bijvoorbeeld business rules management en testen zich ontwikkeld tot een verdergaand specialisme. Dit soort specialismen zijn een verdieping van de besproken activiteitsoorten. De uitdaging is echter wel om deze specialismen nog beter in kaart te brengen. De basis van BEEM ligt in de poging van Dietz (2001, 2004) heeft gedaan om inzicht te geven in de benodigde competenties voor het ICT-werkterrein. Recenter in 2008 zijn door het CIO-platform 36 competenties vastgesteld om het hoofd te bieden tegen de veelheid aan functiebenaming van de diverse specialismen. Deze 36 functies kunnen worden gematcht op de 24 activiteiten van BEEM. Het wordt dan ook duidelijk waar taken, verantwoordelijkheden en bevoegdheden liggen. Nader onderzoek wordt dan ook aanbevolen. Een voorstel tot wijziging betekent binnen BEEM het vaststellen op welke systeemsoort en op welke systeemoriëntatie de wijziging betrekking heeft. Voor een beheerste wijziging van een systeem (business, informatie of data/infra) en ook vanuit kostenoverweging moet duidelijk zijn waar de wijziging optreedt. BEEM maakt het mogelijk om de locatie aan te duiden. Als voorbeeld nemen we de invoering van de computer ter vervanging van het uitvoeren van handmatige berekeningen. Een dergelijk wijziging verandert de implementatie van het I-systeem en leidt tot wijzigingen in de constructie en de implementatie van het ondersteunende D-systeem. De wijziging is dus niet van invloed op het B-systeem. Er verandert immers niets aan de functie en de constructie daarvan.
Redenerend vanuit BEEM kan dan ook de veel besproken governance van Enterprises worden gediend zowel vanuit het perspectief van de business als vanuit het perspectief van de IT. Meerwaarde van BEEM Veel managers in de business hebben last van het jargon dat door ICT’ers wordt gebezigd. BEEM kan dienen als hulpmiddel bij de communicatie tussen business en IT. BEEM maakt het voor beide partijen in het veld van business en IT mogelijk om aan te geven waarop een architectuur, ontwerp, implementatie of wijzigingsvoorstel van toepassing is zonder direct in te gaan op de technische inhoud. BEEM spreekt zich niet uit over de te gebruiken technische oplossingen, tooling of conventies te gebruiken voor ontwerpen en modellen. Het benoemen van IT-functies en -bedrijfseenheden is vaak een groot probleem. Door de kerncompetenties van bedrijven in kaart te brengen - zoals dat gedaan wordt in BEEM -, worden de activiteiten overzichtelijker. Door deze plaatsbepaling kunnen specifieke markt- en technologieveranderingen worden onderkend die van invloed zijn op het functioneren en de kerncompetenties van de organisatie en de personen. Omdat BEEM het gehele terrein van de automatisering in kaart brengt, maakt dit duidelijk welke cellen (zie figuur 5) ingevuld moeten worden om een totale automatiseringsoplossing voor de klant te leveren. Het model helpt managers vooruit te kijken naar veranderingen en ondersteunt het bij strategievorming. Strategisch dient men zich af te vragen welke cel in eigen beheer wordt uitgevoerd en waar inkopen, inhuren, bedrijfsovername of samenwerking een beter alternatief is. In de praktijk zien we daarom samenwerking en overnames tussen bedrijven uit verschillende systeemcategorieën. Volgens de experts die hebben deelgenomen aan het onderzoek is BEEM een herkenbaar raamwerk voor het ICT-werkterrein. Tijdens het onderzoek bleek dit model door de deelnemers te worden herkend. Zij zagen de overeenkomsten tussen het model en hun dagelijkse praktijk. Het benoemen van IT-functies en -bedrijfseenheden is vaak een groot probleem. Door de kerncompetenties van bedrijven in kaart te brengen – zoals dat gedaan wordt in BEEM –worden de activiteiten van deze eenheden en functies overzichtelijker. Door plaatsbepaling kunnen specifieke markt- en technologieveranderingen worden onderkend die van invloed zijn op het functioneren en de kerncompetenties van de organisatie en de personen. De principes van BEEM hebben zich binnen Defensie bewezen tijdens de ontwikkeling van een nieuw systeemconcept doordat het onderscheid tussen functie en constructie en systeemsoort voor ieder teamlid duidelijk te maken was. Menig Babylonische spraakverwarring binnen het team is daarmee voorkomen. Ook voor de inrichting van de architectuurfunctie Defensie is BEEM leidend geweest om taken en verantwoordelijkheden te benoemen. BEEM geeft de betrokken partijen de mogelijkheid om hun rol binnen het grotere geheel te zien in het ICT-werkterrein en de communicatie te verbeteren door de principes en perspectieven die het biedt. Partijen kunnen concrete relaties leggen tussen de architectuurproducten en de ontwikkeling (specificatie en ontwerp), de
implementatie en het beheer van systemen. BEEM kan voor iedere organisatie fungeren als landkaart voor alle betrokkenen in en bij het ICT-werkterrein. Veel managers in de business hebben last van het jargon dat door ICT’ers wordt gebezigd. BEEM kan dienen als hulpmiddel bij de communicatie tussen business en IT, want BEEM maakt het voor beide partijen in het veld van business en IT mogelijk om aan te geven waarop een architectuur, ontwerp, implementatie of wijzigingsvoorstel van toepassing is zonder direct in te gaan op de technische inhoud. Redenerend vanuit BEEM kan de governance van enterprises worden gediend vanuit het perspectief van zowel de business als de IT. De manager staat aan het roer, maar er zijn regels in het verkeer. Om te voorkomen dat BEEM geen wetenschap achteraf is, maar sturend en preventief kan worden ingezet, is het benoemen van de cellen niet voldoende. De waarde van het raamwerk neemt toe als ervaringscijfers en scenario's voor verandering gerelateerd worden aan de cellen, waardoor het landschap beter in kaart wordt gebracht. In de afgelopen twee jaar zijn de ideeën achter BEEM op diverse seminars en voor diverse fora gepresenteerd. Ook zijn de ideeën door een kernteam van architecten binnen Defensie toegepast . De reacties zijn overwegend positief. Met name het functie- en constructieperspectief maakt architecten bewust dat architectuur niet alleen vormgeving is, maar dat engineering een mogelijk nog belangrijkere factor is. Een factor die niet alleen moet worden beschouwd vanuit een technisch gezichtspunt, maar minstens zo belangrijk, ook vanuit een organisatorisch gezichtspunt. Een ander punt dat als positief wordt ervaren, is de positionering van principes, als normatief kader, ten opzichte van de ontwikkeling van specificaties en ontwerpen als basis voor de realisatie van oplossingen (implementatie). BEEM maakt in het bijzonder drie zaken extra duidelijk. Het eerste is dat architectureren gaat over het maken van ontwerpprincipes, en dat die voortkomen uit de organisatie zelf. Het tweede is dat veranderingen uit het operationele gebruik en beheer (managing) komen en via requirements zorgen voor systeemveranderingen (samen met veranderde architectuur). Het derde is dat je in één oogopslag ziet dat veranderingen in de D-organisatie de minste impact hebben, die in de I-organisatie wat meer (omdat die ook altijd veranderingen in de D-organisatie inhouden), en die in de B-organisatie het meest.
Literatuur Berg, M. v. et al. (2009). Wegwijzer voor methoden bij enterprise-architectuur. Zaltbommel: Van Haren Publishing. Dietz, J. (2008). Architecture: Building strategy into design. Den Haag: Sdu Uitgevers BV. Dietz, J. (2006). Enterprise Ontology Theory and Methodology. Berlin, Heidelberg: Springer-Verlag. Dietz, J. (2001). L_PASO the passage to professionalism.
Dietz, J. (2004). Matchen op Competenties, een ontologisch fundament. Nootdorp: Sapio B.V. Dipten, E.G. van, (2010) Via L_Paso met de DIVA op weg naar inzicht in complexiteit (master thesis), Utrecht, University of Applied Science, Mulder, J. (2006). Rapid Enterprise Design. Rijswijk: Viagroep nv.
De schrijvers Prof.Dr.ing. J.B.F. (Hans) Mulder, MscBA is werkzaam bij VIAgroep nv en verbonden aan de Universiteit van Antwerpen Management School en de Hogeschool NOVI. Luitenant-kolonel E.G. (Edward) van Dipten MI is werkzaam bij de Defensie Materieel Organisatie en verbonden aan de Universiteit van Antwerpen, Technische Universiteit Delft en de Hogeschool Utrecht.
Luitenant-kolonel Edward van Dipten is sinds 1981 werkzaam bij Defensie. Hij heeft in de eerste jaren van zijn carrière alle functiegebieden en alle resorts doorlopen binnen de Koninklijke Landmacht. Vanaf 1996 is hij werkzaam geweest binnen vakgebieden als bedrijfsprocesmanagement, informatiemanagement, projectmanagement, bedrijf- en informatiearchitectuur en Enterprise Architectuur. Vanaf 2012 heeft hij een nieuwe aanpak ontwikkeld voor de Enterprise Architectuur binnen Defensie. Edward heeft Bedrijfskundige Informatica en Master of Informatics (MI) gestudeerd. Naast deze studies is hij onder meer gecertificeerd in DEMO, TOGAF, ArchiMate en INK-auditing. Hij is docent Business Process Management (BPM) & Enterprise Engineering (EE) en is hij lector Business Innovation & Enterprise Engineering aan de Hogeschool Novi. Sinds mei 2014 is hij voorzitter van het Enterprise Engineering Institute, het voormalige DEMO Kenniscentrum, en is daarnaast lid van het wereldwijde CIAO-network.
NOVI Opleidingen/ Hogeschool NOVI
T: E: W:
030-7115615
[email protected] www.novi.nl
Bezoekadres: Kobaltweg 44 3542 CE Utrecht Postadres: Postbus 2068 3500 GB Utrecht
