Ik ben Lidwine van As, sinds 1994 werkzaam in de IT, en actief als 
“Als je alleen een hamer hebt, ziet alles eruit als een spijker” - Abraham Maslow
Is het de onvolwassenheid van het vakgebied, of toch een soort beroepsdeformatie? Hoe dan ook: het behoort tot de folklore van BI-land dat inhoudelijke discussies gemakkelijk uitdraaien op een jacht op de technisch-inhoudelijke “single version of the truth”. Voor- en tegenstanders voeren strijd over zaken als de juiste datamodelleertechniek, het aantal lagen dat je in een datawarehouse-architectuur kan, mag of moet onderkennen, de vraag of operationele systemen wel of geen BI-capabilities mogen bevatten (en of dat dan BI mag of moet heten), en ga zo maar door – vaak vanuit een impliciete gedachtengang dat er maar één goed antwoord is op iedere architectuurvraag.
Architectuurproces
Zolang het om wat vrijblijvend gediscussieer gaat, is dat niet zo erg. Maar het architectuurproces in concrete projecten ziet er helaas vaak niet veel anders uit. In mijn ervaring worden architectuurkeuzes eerder bepaald door de voorkeur en stijl van de architect in charge, dan door de specifieke eisen die de organisatie stelt aan zijn BI-omgeving. En het komt al helemaal zelden voor dat architectuurkeuzes gedurende de life cycle van het systeem gereviewd en bijgesteld worden om eventuele gewijzigde eisen te kunnen bedienen.
Goed beschouwd is dat een nogal contraproductieve manier van architectuur bedrijven. Vrijwel iedere aanpak, methode of techniek die ooit bedacht is, heeft wel ergens zijn nut en toepasbaarheid; de kunst is om te begrijpen welke aanpak je in welke omstandigheden het beste kunt volgen.
Niet-functionele eisen
Om de juiste aanpak te bepalen, moet de architect vraag en aanbod tegen elkaar afwegen: enerzijds moet hij weten welke alternatieven er voorhanden zijn en wat hun sterke en zwakke punten zijn, anderzijds moet hij weten welke eisen de omgeving stelt aan de oplossing. We hebben het dan niet alleen over functionele eisen: juist voor architectuurkeuzes zijn de niet-functionele eisen de belangrijkste driver.
Deze afweging zie ik in BI-projecten maar zelden gemaakt worden. Mindset speelt daarbij een grote rol: wie zich niet realiseert dat niet-functionele eisen voor iedere BI-omgeving verschillend kunnen zijn, zal daar geen ook energie in steken. En een one trick pony-architect zal uit zichzelf geen vraagtekens zetten bij de toepasbaarheid van dat ene truukje (ook al moet hij zich af en toe in de raarste bochten wringen om dat truukje toch maar tegen heug en meug te kunnen blijven gebruiken).
Voor architecten met een breder repertoire kan het ontbreken van inzicht in de toepassingskarakteristieken van relevante alternatieven een probleem vormen. Over de sterke kanten van een oplossing is meestal genoeg te vinden, maar de zwakke kanten blijven nog weleens onderbelicht. (Dat is overigens niet altijd een kwestie van onwil of verkooptactiek: vaak worden de nadelen pas duidelijk nadat een oplossing eerst een paar keer in verschillende omstandigheden is toegepast).
Professionalisering
Er vallen dus nog wel een paar slagen te maken in de verdere professionalisering van het BI-architectuurproces.
Om te beginnen moeten we ons de terminologie en het gedachtegoed van niet-functionele eisen eigen maken. We hoeven dat wiel niet zelf uit te vinden, maar kunnen de kunst afkijken bij aanpalende IT-disciplines: een kwaliteitsmodel als ISO 9126, of het daarop gebaseerde Quint zou (wellicht met enige aanpassing) prima onderdeel kunnen gaan uitmaken van de BI body of knowledge.
Verder moet het boven tafel krijgen van de niet-functionele eisen een vast onderdeel van het BI-architectuurproces worden.
(Het zou evident moeten zijn dat je die – net als de functionele eisen – ophaalt bij de opdrachtgever. Dat dat kennelijk niet voor iedereen voor de hand ligt, blijkt uit een recente uitspraak van een collega-architect: “ja hoor eens, de business snapt niet eens wat een niet-functionele eis is. Dus daar moet je ze helemaal niet naar vragen. Volgens mij moet je dat gewoon zelf een beetje proberen in te schatten.” Nou… volgens mij niet.)
En natuurlijk hebben we ook meer inzicht nodig in de impact van niet-functionele eisen op BI-architecturen, en in de manier waarop de verschillende alternatieven de gestelde eisen al dan niet kunnen adresseren. Eigenlijk wil je dus bij iedere oplossing (concept, architectuurstijl, methode, techniek) een bijsluiter hebben die aangeeft wat zijn doel is, wat de bijwerkingen zijn, en wat de contra-indicaties zijn. Aan de bedenkers en toepassers van nieuwe oplossingen de uitdaging om hun ervaringen te delen met de BI-community.
Tussen de oren
Maar uiteindelijk begint het allemaal bij de mindset: bij het inzicht dat niet alles een spijker is. Hopelijk gaan steeds meer BI-architecten de voordelen inzien van een gereedschapskist die meer bevat dan alleen een hamer.
Back to home page
« System of facts - maar wat zijn...
