Onder druk van de business ontstaan vaak gedrochten van it-oplossingen. Nu de cmo of marketingmanager 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 businessarchitectuur 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!
Commercie begrijpen
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.
Aanzienlijke kostenbesparingen
De verantwoordelijkheid om vanuit businessarchitectuur 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 van 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.
@Gijs Een van de opvallende zinnen in je stuk was: “de mogelijke it-consequenties van in de business gemaakte keuzes worden vaak niet of nauwelijks onderzocht of bespreekbaar gemaakt”. Treurig, kenmerkend en een oorzaak van falende ICT projecten.
Want laat dat net de crux zijn van goede of minder goede ICT projecten, je hebt te maken met bestaande ICT oplossingen en het is handig als wat je kiest daar wel op aansluit en uitgaat van de mogelijkheden en onmogelijkheden en gebasseerd op kennis van zaken. Ook al ken ik de voorkeur voor de ‘niets deugt, alles moet anders’ oplossingen. Uiteindelijk komt alles uit op de techniek.
In je laatste reactie, hoe zou in dit geval de business architect overtuigd kunnen worden? Het zou al helpen als de man of vrouw zou beseffen niet genoeg verstand van zaken te hebben daarover te kunnen oordelen. Bescheidenheid en nederigheid.
Helaas, iedereen heeft uiteraard verstand van zaken en het is het probleem bij veel ICT projecten, beslissers die beslissen over zaken waar men geen verstand van heeft.
@Louis, helemaal eens. Het probleem is dat er geen bescheiden en nederige CEO’s bestaan volgens mij 😉
@Gijs Even de hand in eigen boezem. Misschien geldt het wel voor ons allemaal in meer of mindere mate, gebrek aan becheidenheid en nederigheid, weten we eigenlijk meer niet dan wel en worden we geplaagd door blinde vlekken. Twee weten meer dan één. Alleen gaat het vaak om die man of vrouw die beslist en bepaalt…
@Louis, dat klopt en dat zeg ik ook al in het stuk; “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.”
Het is nog maar de vraag of de aanloop die de auteur neemt om “vanuit businessarchitectuur tot implementeerbare it-architectuur te komen” groot genoeg is om de beruchte kloof tussen ICT en de business te overbruggen. Mijns inziens is niet een langere aanloop nodig maar een ontbrekende schakel.
De ontbrekende schakel tussen de bedrijfsarchitect en de IT-architect is mijns inziens af te leiden uit de 3 hoofdviews waartoe Enterprise Architectuur tegenwoordig wordt beperkt, namelijk:
– Business View: bedrijfsarchitectuur
– Functional View: informatie- of applicatiearchitectuur
– Technology View: technologie/infrastructuurarchitectuur.
Niet toevallig corresponderen deze views precies met de toepassingsgebieden van de bekende frameworks BiSL, ASL en ITIL, maar dat nu even terzijde.
Wat betreft de functional view prefereer ik overigens de aanduiding applicatie-architectuur boven de aanduiding informatie-architectuur. Zo spreek je bijvoorbeeld wel van functioneel testers of applicatietesters (naast bedrijfstesters en technische testers), maar niet van informatietesters.
En zo is de ontbrekende schakel tussen de bedrijfsarchitect en de IT-architect dus de functioneel architect.
Zomaar enkele gedachten voor wie er wat mee kan 🙂
@Jack, dat klopt inderdaad allemaal. De “Functioneel Architect” zit dus tussen twee haantjes in en is de pisang.
Is een business architect wel de juiste benaming. De business is meestal, als het goed is wel, het primaire proces van een onderneming en waar een organisatie/onderneming zijn toegevoegde waarde ten gelde maakt. IT is faciliterend aan het primaire proces en dient dit zo optimaal mogelijk te doen, uiteraard onder druk van budget, tijd en technologie vernieuwing.
Voor het primaire proces zijn soms hele afdelingen bezig voor ondersteuning, optimalisatie, etc. etc.
Business architect lijkt mij niet iets om binnen de de IT te introduceren.