De synergie door samenhang met bestaande methoden en

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

Download Report