Menu

Business Architect is ook een vak

Onder druk van de business ontstaan vaak gedrochten van IT oplossingen. Nu de CMO of Marketing Manager meer IT budget heeft dan de CIO lijkt het einde helemaal zoek. Hoe kunnen we het tij keren?
Er wordt vaak gezegd dat hoe eerder in een softwareontwikkelingstraject een fout wordt vermeden, hoe goedkoper het is om op te lossen. Vaak denkt men hier impliciet aan fouten in informatie- of technische architectuur. In de praktijk blijkt echter dat fouten in business architectuur een nog veel grotere impact kunnen hebben.

Een concreet voorbeeld liep ik laatst tegenaan. Ik moet het wat abstract houden, anders maak ik meer kapot dan me lief is: Vanuit de business werd gekozen om een nieuwe partner aan te haken om een logistiek probleem goedkoper op te lossen. De drijfveer was kostenbesparing. Echter, de bijbehorende IT oplossing paste niet in de standaard architectuur en bleek uiteindelijk zeer moeilijk te realiseren en onderhouden. Het is nu, na een aantal jaren, bij deze organisatie zelfs zo ver dat deze maatwerkcomponent een upgrade naar een nieuwere versie van het platform zwaar bemoeilijkt en daardoor ook de beschikbaarheid en de schaalbaarheid van de oplossing in de weg staat. Ondertussen is er heel veel geld gestoken in het onderzoek naar de problematiek en de uitkomst zal nog veel meer geld gaan kosten: herontwikkelen!

Een informatie- of technisch architect heeft een vakgerichte opleiding gevolgd en houdt zijn kennis op peil door nieuwe trainingen te volgen en bijbehorende certificaten te behalen. Een business architect heeft ooit een economie of bedrijfsadministratie studie gedaan en daar is het waarschijnlijk bij gebleven. En na deze studie is men in rap tempo vergeten om de kosten van het implementeren van een nieuwe oplossing compleet te calculeren en deze tegenover de potentiële besparingen te zetten. Debet en credit. Niet alleen in initiële ontwikkelkosten uitgedrukt, maar ook in de run and maitain kosten. Daarnaast zien we in de praktijk ook dat de meeste IT-ers wel iets van business en dus commercie begrijpen, maar andersom is dit vaak een stuk dunner gezaaid.

Kortom, de mogelijke IT consequenties van in de business gemaakte keuzes worden vaak niet of nauwelijks onderzocht of bespreekbaar gemaakt. Het probleem is dat IT architecten vaak als “moeilijke” mensen worden beschouwd die overal beren op de weg zien. Terwijl de IT architect juist nadenkt over het creëren en behouden van een flexibele architectuur die zo goed mogelijk op de toekomst voorbereid blijft. Waar het vaak wel aan schort, is dat de IT architect problemen uitdrukt in termen als “niet onder architectuur” of “geen mooie oplossing”. Als vanuit de IT architectuur nu ook meer kwantificeerbare argumenten kunnen worden aangedragen om bepaalde oplossingen niet te kiezen of misschien op een iets andere manier te implementeren zodat het wel onderhoudbaar, beschikbaar en schaalbaar is, kunnen de twee partijen elkaar misschien beter leren begrijpen en dus gezamenlijk tot de beste oplossingen komen.

De verantwoordelijkheid om vanuit business architectuur tot implementeerbare IT architectuur te komen ligt echter wel primair bij de business architect. Als er afwijkingen in de IT architectuur nodig zijn om toch de gewenste oplossing te implementeren moeten de consequenties duidelijk zijn. Als deze consequenties kwantificeerbaar zijn (en dat zijn ze mijns inziens altijd) kan er door de business een gewogen beslissing worden genomen. Tòch niet kiezen voor de nieuwe business opportunity, òf in gesprek gaan met de betreffende logistieke partner uit het voorbeeld om tot een compromis te komen waarbij wel aanzienlijke kostenbesparingen kunnen worden behaald en tegelijkertijd een acceptabele IT architectuur gerealiseerd kan worden is natuurlijk het hoogst haalbare.

'