Verrichtingen in Enterprise Architectuur
Enkele maanden geleden vergeleek ik, in deze pagina’s, de ‘Enterprise Architecture’ met de komst van de bioscoop in een wereld die alleen maar de foto kende. Ik blijf mij vandaag verbazen over de manier waarop IT-afdelingen een enterprise architecture puur projectmatig aanpakken.
Een EA ontwikkeld zich rond vijf assen, met als doel het IT-beleid te integreren in elk onderdeel, elke dienst van de onderneming. Die assen zijn strategische analyse, architectuur, governance, het in de praktijk brengen van de strategie en communicatie. Er zijn maar weinig IT-organisaties waar deze assen op een operationele manier worden aangepakt, in een continue cyclus.
De grote aandacht die momenteel ontstaat voor governance, zou dit moeten helpen realiseren. Maar wij stellen bij heel wat klanten vast, dat hun inspanningen in deze richting zijn gericht op een ‘Sarbanes-Oxley’-project, dat van korte duur is en slechts beperkte middelen krijgt.
Weinigen beseffen dat al de documentatie die hieruit voort komt, volgend jaar opnieuw moet worden bijgewerkt. Het zou interessant zijn om er een cyclus van te maken, met een organisatie erachter. Die documentatie is een onderdeel van de EA-repository. Als je ze regelmatig bijwerkt, creeer je de noodzakelijke basis om een strategie te ontwikkelen binnen de onderneming, en om IT af te stemmen op de business.
Gelukkig begint er hier en daar wat te veranderen. Een aantal van onze klanten zijn begonnen met het creëren van permanente structuren en organisaties. Die nieuwe diensten houden zich bezig met de functionele, technische en informatie-architectuur, met het beheer van de bedrijfsprocessen of de processen op het vlak van governance of communicatie. Om dat met succes door te voeren in alle diensten die IT aanbiedt, moet de vraag worden gesteld wat de toegevoegde waarde van de EA is. Het gaat hier om marketing. Wij hebben verschillende methodes geprobeerd om waarde te creëren met de architectuur, en om dat in te voeren in de verschillende departementen van een onderneming.
De oplossing ligt in de analyse van de business processen. De vraag moet worden gesteld aan het hoofd van een afdeling, hij ontvangt de resultaten en onderneemt de noodzakelijke actie. Zodat de manager het resultaat kan begrijpen, mag een goede Business Process Modelling (BPM) niet meer dan vijf of zes grafische conventies bevatten. Beschikt men eenmaal over schema’s van alle processen, dan ziet men al snel de eerste verrassingen over het verloop van de stromen. De verantwoordelijken, die ‘op het terrein’ zitten, stellen onmiddellijk alternatieven voor. De analist kan zorgen voor geoptimaliseerde voorstellen, en kan een pad uitstippelen om er te geraken. Er kunnen ‘Quick wins’ worden geïdentificeerd, die waarde zullen toevoegen aan de dienst die geanalyseerd wordt.
Op basis van de stappen in het proces die worden geïdentificeerd, worden vervolgens prestatie-indicatoren geleverd. Het onderhouden van al deze informatie wordt eerst en vooral gerechtvaardigd door het onderhoud van de indicatoren, en in de tweede plaats door de voortdurende verbetering van de operationele prestaties.
En op die manier hebben we dus een ‘as-is’ plan, een ’to-be’ plan en een roadmap. Deze procesarchitectuur kan zeer goed de basis vormen voor de functionele architectuur, de applicatie-architectuur, de informatie-architectuur en de technische architectuur. Het mechanisme dat ons zal leiden naar de strategische analyse en het realizeren van die strategie is op gang gebracht.
‘IT doesn’ t matter’ schreef Nicholas G. Carr in Harvard Business Review. Misschien had hij gelijk als de analist de IT gewoon in de steek laat, en zich nog enkel gaat bezighouden met het beheren van alle informatie van en binnen de onderneming, met als enig doel het toevoegen van waarde. Maar zo ver zijn we nog lang niet…
Dominique Scheuren (dominique.scheuren@bizliner.com) is eigenaar van Bizliner en consultant in ‘Enterprise Architecture’.
