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!
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 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.
Reacties
Gijs,
1- De opleiding Bedrijfskunde bevat veel leuke modules waarmee je verschillende lacunes op je carrière pad kunt opvullen. Als voorbeeld de financiële management krijgt volledige aandacht waardoor je meer inzichten krijgt op de kosten in de hele keten.
Ik zie mensen (bijvoorbeeld cloud architecten) op LinkedIn iets over TCO en financiële kanten van Cloud Computing roepen terwijl ze maar bezig zijn met het berekenen van stoarage kosten en ook een aantal dingen op technische niveau. Ik zeg altijd geef je input als techneut aan een iemand die meer kennis heeft van deze zaken en blijf af van dit soort dingen.
2- Ik weet niet exact wat je met je artikel bedoelt (sorry ik ben een Libelle lezer :-))Normaal gesproken dit soort wijzigingen worden in een Business Case behandeld. De technische input komt vanuit architect en de zaken rondom business, financiële aspecten en nog andere dingen worden onderbouwd en beschreven door Projectmanager. De trigger kan afkomstig zijn van een business developer die ook wat mee kan geven voor de BC.
Klaar is Kees! Mis ik iets dan?
Het verhaal bevat een kern van waarheid, echter wat ik uit de praktijk geleerd heb is dat "architect" een rekbaar begrip is.
In de bouwsector is architect een beschermde titel, je moet hiervoor een bepaalde opleiding genoten hebben.
In de ICT is dit helaas niet het geval, waardoor het artikel in sommige gevallen dekkend is, maar in andere gevallen wellicht de plank mis slaat.
Libelle lezers die zich opeens voordoen als experts aangaande de cloud maar nog niet het verschil weten tussen de CapEx en de OpEx. Zeker missen ze iets als ze niet weten dat de discipline enterprise architectuur veelal om de governance gaat en daarin is een business case alleen maar een viewpoint. Boekhoudkundige verschuivingen zijn geen besparingen als ik overweeg dat ik 4 jaar geleden in paneldiscussie hierover al wat riep.
Nu ben ik dus over gecertificeerd en daarom misschien gehinderd door teveel kennis maar zou de vraag niet moeten gaan om winst verhogingen?
De cloud als Ecosysteem Oriented Architecture blijkt tot op heden nog een halte te ver als hybride oplossingen overheersend zijn. Betreffende de storage leg ik CIO/CTO's graag uit dat een situatie ontstaat van een supermarkt met niet gelabelde conservenblikken waardoor het moeilijk wordt om de goulash van het hondenvoer te onderscheiden,
Pavlov hondjes ontkennen deze problematiek omdat ze graag 'blikopeners' blijven leveren en er sprake is van een discussie met de kalkoen over het kerstdiner;-)
Arme Gijs, doet zo zijn best maar van Reza krijgt hij dan te horen dat hij als techneut van financiële zaken moet afblijven. En daarop van ons Pa dat zijn ict architectenvak zowiezo een beunhaas niche is.
En Ewout, nee de BC is niet winstmaximalisatie, maar korte termijn kostenbesparingen mbv project scoping. Dat leer je waarschijnlijk in die leuke modules waar Reza naar verwijst ;-)
Gijs,
2 dagen voor het verschijnen van je artikel las ik op andere site een artikel met hetzelfde thema (toevallig??)
Misschien wat betere uitleg vanuit dat artikel:
====================================================
Een business architect heeft de taak om een strategisch en steeds evoluerend plan te ontwikkelen voor het bedrijf om ervoor te zorgen dat de mensen, technologie en faciliteiten aanwezig zijn wanneer het bedrijf erom vraagt. Zij moeten aanpassingen maken als het bedrijf voortschrijdt en verandert. Ze moeten conflicten voorkomen en hierop anticiperen en synergieën zien zodat beslissingen minder kwaad dan goed doen en resources beter indelen zodat het bedrijf kosteneffectiever kan werken.
Deze rol kun je zien als een strategische versie van de operationeel directeur; een positie die kritiek is voor het succes van een organisatie en beschermend werkt tegen fouten die bestuurders vaak maken, zoals het doen van idiote overnames of het niet beschermen van een aangekochte technologie.
Het probleem met deze functie is dat het om een skillset vraagt die verder kijkt dan de grenzen van de business en IT en een diepe kennis van de markt, producten en operations vraagt, met de hierbij de nadruk op IT.
Om de baan goed uit te voeren, moet de business architect de autoriteit hebben om beslissingen te blokkeren die niet strategisch gemaakt zijn. Daarnaast moet hij besluiten kunnen maken over het aanschaffen van zaken lang voordat het anderen in het bedrijf duidelijk is dat deze resources al op zo'n relatief korte termijn noodzakelijk zijn.
De enige andere persoon met deze macht in het bedrijf is de CEO. Daarom vormt deze rol de ideale trainingsrol voor CEO. Maar de CEO vind het meestal niet prettig een positie in het leven te roepen met daarin iemand die hem of haar zou kunnen vervangen
======================================================
Maar.............deze uitleg was niet nodig! Gelukkig hebben we hier een Nachtburgemeester die alles beter denkt te weten en deze verder na een stevige borrel in de late uren met duidelijke taal weet te verwoorden :-)
Libelle lezer die ergens iets op een website leest......
Gezien het feit dat in die aangehaalde referentie sprake is van voortschrijdend strategische planningen en een skillset vraagt die verder kijkt dan de grenzen van de business en IT door een diepe kennis van de markt, producten en operations denk ik dat functie van business architect meer weg heeft van een loods dan een kapitein.
Betreffende de late uren zou de Libelle lezer er goed aan doen om eens te kijken naar de impact van de cloud, de 24/7 toegangsmethodiek vraagt veelal dus een organisatorische verandering als gevolg van paradigma verschuivingen. Dat beheerarchitecturen sommigen boven het theewater gaat blijkt wel uit het projectmatig werken van puntoplossingen die allemaal een eigen ecosysteem hebben, de oude schoenen waar de meeste organisaties nog op lopen zijn niet de zevenmijlslaarzen uit de sprookjes als we kijken naar enterprise lifecycle uitdagingen.
@Reza:
Ik heb zo mijn twijfels over de meerwaarde van een "business architect" als zo iemand de ruimte krijgt om weg te lopen voor de financiële aspecten van de door hem voorgestelde architectuur/technologie.
Hoe kan zo iemand dan "een trainingsrol" voor de CEO vervullen?
Die financiële vingeroefening hoeft dan misschien niet tot op de euro te kloppen. Maar mij lijkt dat zo iemand op zijn minst in staat moet zijn om een indicatie te geven in welke orde-grootte de resultaten komen te liggen.
Ook verwacht ik van zo iemand dat hij/zij kan aangeven welke parameters deze resultaten beïnvloeden - zeg maar de knoppen waar je aan kan draaien.
Mij lijkt dat alleen dan zo iemand inderdaad "een trainingsrol" voor de CEO kan zijn!
@Will,
De vraag is tot hoeverre moet een business architect de financiële aspecten uiteen zetten!
Wat ik vaak op LinkedIn voorbij zien gaan, meestal van "cloud-architecten" die zich uiten over de TCO van Cloud als een veranderingsmodel van je IT en business dan zie ik alleen een kortzichtige berekening van IOPS,TB en nog wat technische aspecten die in een sausje naar buiten gebracht worden als TCO van verandering van je ICT.
Wat mij betreft mag die TCO meer bevatten dan alleen deze berekening. Ik zei ook niet dat een business architect alles zelf moet berekenen maar wel met alles rekening houden en/of laten doorrekenen.
Dus mee eens met je reactie [...] zo iemand dat hij/zij kan aangeven welke parameters deze resultaten beïnvloeden - zeg maar de knoppen waar je aan kan draaien [...]
Maar is deze functie niet een wat "zwaardere versie" van bestaande business developer?
Interessant dat de ict-business kloof kennelijk nogal diep zit.
van werkvloer tot architect, libelle tot sprookjes.
Be business case bij klein duimpje was overigens ook kostenbesparing. De familie moest flink uitgedund en toegang voor de resources voor duimpjes rollbackplan werd uiteindelijk via IAM afgeschermd. Maar ik geloof dat het uiteindelijk toch weer goed afliep, gelukkig.
@Reza, inderdaad toevallig.
Verder ingaande op de discussie: het zou al erg helpen als de Business Architect (al of niet de CEO) overtuigd zou kunnen worden van de impact van de door hem ontstane technical debt. Wie zou dat kunnen en hoe zou dat gepresenteerd moeten worden?
@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.