Enterprise architectuur en business analyse

Door: G.J. (Gert) Zweedijk, CBAP

3 februari 2017

In deze blog kijken we hoe enterprise architectuur gebruikt kan worden om tot betere (business) analyses te komen. Ik begin met een definitie van enterprise architectuur en geef vervolgens de raakvlakken aan met business analyse. Tot slot passeert een techniek de revue die analisten helpt om doeltreffender hun werk te kunnen doen.

‘Enterprise Architectuur (EA) is een geheel van uitspraken, processen, producten, mensen en middelen, dat richting geeft aan de ontwikkeling van een organisatie met de focus op samenhang’ (bron: Ordina). Enterprisearchitectuur bestaat uit verschillende lagen: business architectuur, informatie(systeem) architectuur en technologie architectuur. Business architectuur omvat een beschrijving van de doelstellingen van een bedrijf en de structuur die er voor moet zorgen dat deze doelstellingen bereikt zullen worden (waaronder bedrijfsstrategie en bedrijfsprocessen). Informatie(systeem) architectuur omvat enerzijds de inhoudelijke relaties en samenhang tussen gegevensverzamelingen en anderzijds de samenhang van informatiesystemen en applicaties binnen in een organisatie. Het is een modelmatige beschrijving van het applicatielandschap, de in productie zijnde systemen.

Analyse en Design

Uit het bovenstaande en mijn eerdere blogs kan worden opgemaakt dat er een flinke overlap bestaat tussen de vakgebieden (enterprise) architectuur en business analyse. Business analyse kan zich richten op slechts 1 architectuurlaag (bijvoorbeeld informatiesysteemarchitectuur) maar ook op meerdere lagen tegelijk.

Maar er zijn ook verschillen. Waar de aandacht van (enterprise) architectuur ligt in de vastlegging van (de samenhang tussen) verschillende lagen/perspectieven van een organisatie - het is een ontwerp op een hoog abstractieniveau - is business analyse meer geënt op het analyseren van een bestaande architectuur met als doel daarin verbeteringen aan te brengen. Die verbeteringen hebben uiteraard ook weer een samenhang (in een gewenste architectuur). Analisten hebben een bestaande (Ist-) architectuur als basis nodig om analyses uit te kunnen voeren en geven verbeteringen aan die worden vastgelegd in een gewenste (Soll-) architectuur. Je zou kunnen zeggen dat analyse en design met elkaar zijn verweven als het Yin-Yang-symbool; samen zorgen ze ervoor dat een organisatie kan groeien op talloze gebieden. Welke daarbij leidend is hangt af van de gekozen aanpak.

Van oudsher werd vaak een blauwdruk-aanpak gekozen voor architectuur hetgeen betekent dat er werd toegewerkt naar een vooraf gekozen ontwerpdoelstelling die werd vastgelegd in een Soll-architectuur. Nadeel hiervan was dat ontwerpdoelstellingen vaak werden ingehaald door de werkelijkheid, hetgeen wil zeggen dat er uiteindelijk anders werd gewerkt dan vooraf was bepaald. Steeds populairder werd dan ook de agile aanpak waarin je weliswaar een gewenste situatie schetst, maar waarbij je steeds kleine stapjes zet richting een gewenste situatie die er gaandeweg anders uit kan gaan zien. In plaats van een grote stap te zetten van een 1.0 versie naar een 2.0 versie geven steeds meer organisaties de voorkeur aan kleinere stapjes middels releases (via 1.1 en 1.2 naar 1.3 etc.). Zie onderstaande figuur.

Ook in agile aanpak verdient het de voorkeur een (project)startarchitectuur te hebben waarin de kaders en richtlijnen worden vastgelegd. Ik noem ze vaak architecturele requirements. Meer hierover in een volgende blog.

Frameworks

Er bestaan verschillende frameworks binnen het vakgebied enterprise architectuur waarbij TOGAF, Zachman en Archimate de meest populaire zijn. Frameworks ontstaan binnen een bepaald vakgebied omdat veel processen er op een hoog niveau allemaal hetzelfde uitzien. Het is natuurlijk zonde om zelf (steeds opnieuw) ‘het wiel uit te vinden’. Het verdient de voorkeur om dingen die zich in de praktijk hebben bewezen te hergebruiken. In het vakgebied systeemontwikkeling zijn SDM (beter bekend als de Waterval-methode), (R)UP (Unified Process) en Scrum de bekendste frameworks. In mijn toekomstige blogs zal ik nog vaak terugkomen op deze frameworks plus hun voor- en nadelen.

Omdat enterprise architectuur een zeer specialistisch vakgebied is en het dus afhangt van het gekozen framework welke perspectieven en/of lagen men onderscheidt, heb ik gekeken naar een soort grootst gemene deler waar de meeste frameworks ‘in passen’. De meeste frameworks maken namelijk onderscheid in de lagen Business, Bedrijfsproces, Informatie(voorziening), ICT-systemen en Infrastructuur.

Doel-Middelen Hiërarchie

In trainingen heb ik vaak gemerkt dat de Doel-Middelen Hiërarchie (in het vervolg afgekort met DMH) een zeer handige techniek is voor analisten. Het geeft namelijk een duidelijk overzicht van de verschillende niveaus van een organisatie en de verschillende perspectieven die stakeholders (van directie tot programmeur) kunnen hebben in een verandertraject. Door het vermogen te ontwikkelen om te kunnen schakelen tussen de verschillende niveaus, verbeter je als analist de communicatie met een groot aantal mensen met verschillende achtergronden. En dit is hard nodig om ervoor te zorgen dat de requirements van de verschillende niveaus op één lijn liggen (een van de belangrijkste taken van de analist).

Eerst zal ik de DMH nader beschrijven en vervolgens kom ik terug op de voordelen voor de (business) analist.

De DMH onderscheidt 5 (analyse)niveaus die als rijen in een tabel kunnen worden weergegeven (zie figuur).

Bedrijf
Bedrijfsproces
Informatievoorziening
ICT-systemen
Infrastructuur

1. Bedrijf

Het bedrijfsniveau is het hoogste niveau: hier worden de bedrijfsdoelen en –doelstellingen plus de strategie van de organisatie vastgelegd. Ook wordt hier gedefinieerd welke producten en/of diensten een organisatie levert. Strategieanalyse (zie vorige blogs) vindt plaats op dit niveau. Middels strategieanalyse worden alle huidige producten en diensten in kaart gebracht en geanalyseerd. Centrale vragen op dit niveau zijn: ‘wat leveren we?’ en vooral ‘waarom doen we dat?’. Eveneens vindt op dit niveau een analyse plaats van de bestaande klanten en markten: ‘wie zijn de afnemers van onze producten/diensten?’ (ofwel ‘voor wie doen we wat we doen?’) Hieraan gekoppeld zijn de doelstellingen en de daaruit voortvloeiende strategie van een organisatie.

2. Bedrijfsproces

Strategieanalyse (niveau 1) leidt tot een meerjarenplan, is richtinggevend en dus te beschouwen als een ‘punt op de horizon’. Maar een punt op de horizon is natuurlijk niet voldoende: er is ook een vertaalslag nodig van die strategie. Op het 2^e niveau worden de processen beschreven die ervoor moeten zorgen dat de bedrijfsdoelen kunnen worden behaald. Een product of dienst wordt niet uit het niets gecreëerd: hier ligt een verzameling van processen aan ten grondslag. Deze worden door de medewerkers en/of de informatiesystemen van de organisatie uitgevoerd.

Een boekhandel die bijvoorbeeld online boeken wil gaan verkopen, zal eerst zijn verkoop- en logistieke processen moeten digitaliseren. Als dit niet gebeurt dan ligt er een mooi plan maar zijn er geen resultaten! Helaas hebben veel boekhandels de afgelopen jaren hun deuren moeten sluiten omdat ze zich te laat realiseerden dat veel klanten zouden overstappen op online winkelen.

Dit niveau komt overeen met de deelgebieden Procesanalyse en People analyse uit de blog Business analyse en BPM.

3. Informatie(voorziening)

Het 3^e niveau brengt de informatiebehoeften in kaart die klanten of medewerkers hebben om de processen van laag 2 uit te kunnen voeren. Het geeft antwoorden op vragen als: ‘Welke gegevens moet ik als gebruiker invoeren om een inkooporder te registreren?’, ‘Wat is de status van mijn bestelling?’ en ‘Hoeveel klachten zijn er deze maand binnengekomen in mijn team?’. Het is het niveau waarop de meeste stakeholder requirements worden vastlegt.

4. ICT-systemen

De informatiebehoeften worden in de 4^e laag vertaald in systeemeisen en –wensen (system requirements). De eisen en wensen worden op hun beurt vertaald in informatiesystemen en applicaties. De grootste inspanning van een IT-project (bouw of aankoop) vindt op dit niveau plaats.

5. Infrastructuur

Tot slot is er het 5^e niveau: infrastructuur. Hier gaat het voornamelijk om de hardware die gebruikt wordt voor de operatie van de ICT-systemen van laag 4.

Niveaus 3, 4 en 5 komen overeen met het deelgebied Productanalyse uit eerdere blogs. Voor niveau 3 komt daar nog People analyse bij.

In toekomstige blogs zal ik uitgebreid terugkomen op bovenstaande analyseniveaus. Op dit moment is het voldoende om de niveaus te kennen en wil ik het belang van consistentie tussen de niveaus onderstrepen. Hiermee bedoel ik dat de hierboven genoemde lagen goed op elkaar aansluiten. Het is voor iedere analist belangrijk om te beseffen dat een informatiesysteem (niveaus 4 en 5) niet op zichzelf staat, maar dat het een instrument is om mensen te voorzien van op maat informatie (niveau 3) die gebruikt wordt om iets te doen (niveau 2) waardoor een organisatie zijn doelen kan behalen (niveau 1). Regelmatig heb ik meegemaakt dat een opdrachtgever een project start met de vraag: ‘ik wil een informatiesysteem dat ….’. Hoewel er een gerede kans is dat hij/zij gelijk heeft, wil dit niet zeggen dat je dat dan klakkeloos maar gaat uitvoeren. Door als analist de waarom-vraag te stellen kom je erachter wat de reden is om het informatiesysteem te bouwen of aan te schaffen. Het antwoord op de waarom-vraag leidt namelijk tot een hoger gelegen requirement uit de DMH. Deze traceability is net zo belangrijk als de requirements zelf!

Het is belangrijk dat je als analist kunt schakelen tussen de 5 DMH-niveaus en dat requirements niet uitsluitend betrekking hebben op een informatiesysteem maar op alle lagen van de DMH.

Naast de huidige situatie (weergeven in de linker kolom) kan in de DMH ook de gewenste situatie in kaart gebracht worden (in de rechter kolom) met betrekking tot producten/diensten, bedrijfsprocessen, informatiesystemen etc. Uit de verschillen tussen huidige en gewenste situatie worden de aandachtspunten voor de toekomst duidelijk in kaart gebracht. Veel requirements vloeien voort uit de delta tussen huidige en gewenste situatie.

Ook belangrijk: het deelgebied ‘requirements’ is een essentieel (doch niet het enige!) onderwerp voor de (business) analist.

Ik sluit deze blog af met een minicasus als voorbeeld waarin de DMH wordt gevuld.

Een minicasus: BCL

Beauty Cars Limited (BCL) is een fictief bedrijf dat al jaren actief is in de autobranche. Naast het produceren en verkopen van brandstofauto’s bieden ze hun klanten de mogelijkheid van een afbetaalregeling als service. Uit onderzoek is gebleken dat de markt voor elektrische auto’s groeiend is. In de nabije toekomst willen ze dan ook elektrische auto’s op de markt gaan brengen. Er wordt een nieuwe productielijn ontwikkeld waarin elektromotoren worden gebouwd (naast de productielijn voor brandstofmotoren die gaandeweg –afhankelijk van de marktvraag - zal worden afgebouwd). Daarnaast is het plan ontstaan om klanten de mogelijkheid te bieden een vervangende auto te huren voor vakanties. Deze zogenaamde Mobility as a Service (MaaS) wordt geboden omdat de range van veel elektrische auto’s nog te laag is voor (verre) vakanties.

Deze doelstellingen worden vertaald in een behoorlijk aantal nieuwe processen, naast de eerdergenoemde productielijn voor elektromotoren komt er een productielijn voor batterijen, een belangrijk onderdeel van de elektrische auto. Ook het proces dat vervangende vervoer mogelijk maakt moet worden uitgerold. Daarnaast worden diverse apps gemaakt die het elektrisch rijden voor klanten zo comfortabel mogelijk maken. Ook op het gebied van infrastructuur staan er een hoop zaken op de agenda: er zal nauw samengewerkt worden met partnerbedrijven die laadpalen installeren en software leveren om laden mogelijk te maken.

In de bovenstaande figuur is slechts een klein deel van alle plannen en wensen in kaart gebracht. Het gaat in deze casus niet om de volledigheid van de DMH, maar om te laten zien wat het nut ervan kan zijn. Hopelijk is dat gelukt. Ik zal er in toekomstige blogs regelmatig naar verwijzen.

vorige pagina