Veel vragen, weinig krijgen

Banken, verzekeraars, ministeries en productiebedrijven, bijna allemaal maken ze tegenwoordig gebruik van enterprise architectuur om risico’s bij strategische verandering te beheersen. Er wordt bijvoorbeeld een procesblauwdruk, applicatielandschap of technologie-roadmap gemaakt, drie veel gemaakte enterprise architectuur-producten, waarop de standaarden en richtlijnen staan waar mensen zich aan moeten houden als ze processen, applicaties en technologie wijzigen.

Deze enterprise architectuur-producten worden vervolgens weer gebruikt in projecten als gemeenschappelijk kader en beeld van een toekomstige situatie om daar stapsgewijs via milestones en architectuurplateaus naar toe te werken. Op de producten staat bijvoorbeeld een procesmodellering-standaard zoals BPMN, een applicatiegegevens-uitwisselstandaard van zoals WSDL en een technologiestandaard zoals SSL, voor versleutelde internetcommunicatie.

Helaas is de enterprise architectuur, of beter gezegd de enterprise architectuur-producten, lang niet altijd even bruikbaar of beschikbaar in projecten en op afdelingen. In organisaties zijn het vooral de ict-managers die de vraag neerleggen bij enterprise architecten om meer bruikbare (begrijpelijke) producten en dan met name visuele architectuurproducten. Het gaat dan om een begrijpelijk overzicht, of überhaupt een overzicht in welke vorm dan ook, van bijvoorbeeld alle bedrijfsprocessen in de organisatie en door welke software applicaties ze worden ondersteund. Menig ict-manager vraagt wekelijks om zo’n overzicht, maar krijgt het vaak niet en steeds weer om een andere reden.

Ict-managers stellen enterprise architecten steevast dezelfde vragen zodat zij de risico’s beter beheersen bij veranderingen die plaatsvinden met gebruikmaking van enterprise architectuur. Zij krijgen helaas lang niet altijd een adequaat antwoord. De ‘vragen’ zijn een oproep aan enterprise architecten om te voorzien in meer en betere visuele architectuur producten.

1. Van welke softwareapplicaties zijn de primaire bedrijfsprocessen afhankelijk?
Bij een overheidsinstantie wilde een ict-manager weten van welke softwareapplicaties de primaire bedrijfsprocessen afhankelijk zijn en vroeg dit aan de enterprise architect aldaar. Als je namelijk overzicht hebt, kun je beter prioriteren in het onderhouden en eventueel vervangen van de softwareapplicaties. En dat wilde de ict-manager gaan doen. Het is bij managers een bekend principe, maar lang niet bij elke architect.

De enterprise architect overigens antwoordde dat het in beeld brengen van de processen pas over drie maanden gepland was en dat het niet zijn verantwoordelijkheid was, maar die van de business architect. Het gevolg: de ict-manager ging maar zelf workshops beleggen om zijn eigen beeld en oordeel te kunnen vormen over de bedrijfsprocessen. Maar dit ging wel ten koste van de tijd die hij voor andere dingen had ingepland en het overzicht van processen was allesbehalve compleet.

2. Wat gebeurt er als ik een bepaald applicatieplatform vervang?
Een correcte impactanalyse van mogelijke veranderingen om zo de continuïteit van bedrijfsprocessen niet te verstoren is van groot belang voor ict-managers. Zij willen naar hun interne klanten toe (de business) een kwalitatief goede dienstverlening kunnen aanbieden. De ict-manager bij deze organisatie, een verzekeraar, vroeg aan de enterprise architect om een impactanalyse te doen betreffende het vervangen van een verouderd applicatieplatform. De enterprise architect gaf echter aan dat hij op dit moment geen bijgewerkt overzicht had van de samenhang en afhankelijkheden van applicaties en platformen en dat de ict-manager dat beter eerder had kunnen vragen, zodat het werk bij de budgetronde ingepland had kunnen worden. Het gevolg was dat het applicatieplatform werd vervangen waarbij gedurende twee dagen de productie in een bepaald proces werd verstoord.

In hetzelfde geval werd bij een andere organisatie besloten om het platform maar niet te vervangen en een persoon extra in te huren van de leverancier van het platform om het nog maar een jaar uit te zingen. Het gevolg: extra onnodige leveranciersafhankelijkheid en kosten.

3. Zou ik een technologie-roadmap mogen hebben?
Om de impact van wijzigingen zo laag mogelijk te houden en inzicht te geven aan de buitenwereld wanneer bepaalde veranderingen op stapel staan, maken organisaties gebruik van roadmaps. Het is echter enorm kennisintensief om een roadmap te maken, dus de vraag werd al snel aan de enterprise architect gesteld. De enterprise architect, gevraagd om een technologie-roadmap te maken voor de ict-omgeving van de organisatie, gaf aan de ict-manager aan dat hij te weinig informatie krijgt van de leveranciers om een roadmap te kunnen maken en dat de i-Visie ook nog niet klaar is. De ict-manager heeft de maanden daarna met veel ontevredenheid van zijn collega-managers te maken gehad, dat gedeeltelijk te voorkomen was geweest als er een visualisatie van een roadmap was gemaakt.

4. Wanneer krijg ik nu eindelijk eens mijn applicatielandschap?
In dit geval is er een organisatie waar een architect door omstandigheden steeds wordt gedwongen brandjes te blussen en hij niet de tijd neemt of krijgt om elke week, stap voor stap, een overzicht van alle applicaties te maken. De ict-manager vraagt er elke drie maanden om en de enterprise architect belooft het ook te leveren, elke drie maanden opnieuw. De ict-manager heeft nu maar iemand extern ingehuurd om het applicatielandschap in beeld te laten brengen.

Dit artikel is eerder verschenen in Computable magazine jaargang 48, nummer 5 van mei 2015.