Gezond eten, zo wordt ons geleerd, is lange termijn denken. Je lichaam is een tempel en moet met respect behandeld worden. Helaas verandert de officiële mening over wat gezond is nogal eens. Wat vandaag gezond is, is morgen ongezond en een absolute ´no no´. Een paralellel met IT architectuur is snel gemaakt. Goed vandaag, slecht morgen en weer goed overmorgen. Wanneer doe je het goed waar het lange termijn architectuur en strategie betreft? In de wereld van beleidmakers slaat steeds vaker de wanhoop toe. Beleidmakers houden namelijk van stabiliteit en ze zouden het liefst alles voor 5 jaar vast zetten. Een mooi voorbeeld: meer dan twintig jaar geleden vroeg een verwarde CIO mij ”Maar waarom moeten we nu opeens SOA gaan doen? Vorig jaar was onze strategie toch ERP, en nu is opeens alles anders?”
 

“Nu opeens”

Laten we dit eens ontleden te beginnen bij het einde: “Vorig jaar was onze strategie ERP en nu is opeens alles anders?” Tja, diegene die eerdere blogs van mij gelezen hebben, voelen aan hun water wat  nu gaat komen. Daar gaan we: natuurlijk is nu alles anders, want we zijn een jaar verder. En als alles anders is, of als je meer of andere informatie hebt, is het toch logisch om je mening bij te stellen? Sterker nog, sinds wanneer is een mening zoiets als een contract voor een bepaalde tijd? In dit geval is de mening gebaseerd op vakmanschap in een snel ontwikkelend vak. Dezelfde mening, jaar na jaar, zou op zijn minst gefronste wenkbrauwen moeten opleveren.

De opmerking: “waarom moeten we nu opeens …” was gekoppeld aan een tijdsverloop van ruim een jaar. Het woordje “opeens” komt dan ook van een langetermijn-planner, die van strategen en architecten verwacht dat ze de toekomst kunnen voorspellen. Terwijl vijf jaar vooruit kijken hetzelfde is als schieten op een bewegend doel. Voor de langetermijn-planners en Excel fetisjisten bestaat een bewegend doel niet. Zij hebben houvast nodig om te kunnen budgetteren en plannen. Een strategisch plan betekent voor beide uitersten dus iets heel anders. Voor de visionairs en “Luchtkastelenbouwers”  is het zoiets als “het zou best eens kunnen dat …” oftewel een voorlopige richting, terwijl het voor de “Excel fetisjist” een dartbord is met in het midden een duidelijke bullseye, het doel.

Keuzes maken

Hoe brengen we deze twee uitersten bij elkaar? Zijn er generieke waarden of principes die voor beide kanten goed verteerbaar zijn en die zowel op korte als lange termijn een gezond dieet voor een organisatie zijn? Waarden en principes zijn subjectief tot je afspreekt wat je bedoelt. Een gemeenschappelijke taal is pas gemeenschappelijk als de woorden objectief voor alle betrokkenen hetzelfde betekenen. Bijvoorbeeld: de afspraak over wat een centimeter is ligt ergens vast en als er misverstanden over zijn dan pakken we samen een meetlat en zien we objectief wat een centimeter is. Ook over groepen van woorden, die een samenhangend geheel vormen of een concept duidelijk maken, zijn afspraken nodig. Als het (IT-)systemen betreft, probeer ik, voordat we het over de inhoud hebben, afspraken te maken over de belangrijkste principes én over wat we minder belangrijk vinden. Focus is noodzaak en dat betekent  keuzes maken, want als alles belangrijk is, is niets belangrijk. Daarom heb ik een eigen schijf van vijf opgesteld als hulpmiddel. Deze bevat de vijf belangrijkste zaken om te objectiveren en om de karakteristieken van een systeem vast te leggen. De afgelopen jaren heeft het me geholpen om partijen bij elkaar te brengen en focus aan te brengen in hun samenwerking.

Flexibiliteit

Een containerbegrip, dus wat bedoelen we nou eigenlijk met flexibiliteit? Hoe beweeglijk een IT architectuur is, bepaalt in belangrijke mate hoe beweeglijk de business kan zijn. De mate van benodigde verandering en vernieuwing van de business  – en haar aansluiting op de markt – zijn dus bepalend voor de mate van flexibiliteit in IT. Echter, de afdeling marketing heeft een andere lifecycle van haar producten dan de afdeling logistiek of productie. Principes die in alle omstandigheden voor alle afdelingen werken, bestaan dus niet. Ergo, dogmatische principes voor de hele IT architectuur gaan niet werken. Diegenen die het geheel moeten overzien, moeten dus bij uitstek flexibel zijn en de mate van verandering leidend laten zijn voor de benodigde flexibiliteit per bedrijfsfunctie. Leg dus vast wat flexibel betekent in de vorm van:

  • Hoeveel veranderingen verwachten we in een bepaald tijdsframe?
  • Hoe snel verandert een product of een dienst?
  • Hoe vaak veranderen processen?
  • Hoeveel mag een bepaald type verandering in tijd en geld kosten?

Exit strategie

Lock-in met leveranciers of producten lijkt de grootste angst van de afdeling procurement. Maar om te weten hoe schadelijk lock-in echt is, dient in eerste instantie, wederom, vanuit de business gekeken te worden. Leg vast:

  • Hoe waarschijnlijk is het dat producten of delen van de business- en IT-architectuur vervangen moeten worden bij een exit?
  • Hoeveel moeite mag dat kosten (in tijd, geld en afbreukrisico)?

In tweede instantie kijken we naar product en leveranciersafhankelijkheid met een IT-technische bril.

  • Wat is de impact van een exit op het IT-landschap?
  • Wat is de impact op de interne integraties?
  • Wat is de impact op de externe integraties?
  • Wat gebeurt er met de data, als we van een product of leverancier af willen?

Ook hier geldt weer dat dogma’s niet het gewenste resultaat gaan leveren. Er is niet één goede exit strategie, maar een exit per product/leverancier en/of businessfunctie. Wat helpt is om regelmatig een risicoanalyse op de bestaande architectuur te doen met de veranderportfolio in de hand en met een zo multifunctioneel mogelijk publiek.

Kwaliteit

Laten we beginnen met wat kwaliteit niet is, namelijk, het beste. Een valkuil waar we met regelmaat in trappen en die vaak leidt tot ongewenste complexiteit, kosten en onrealistische verwachtingen. Kwaliteit is ’in the eye of the beholder‘. Wat de gebruiker/klant nodig heeft en wat hij gezien de missie en de marketing mag verwachten, is de kwaliteit waar we aan moeten voldoen. De beste manier om daar achter te komen is het de eindgebruiker/klant vragen en vast te leggen. Vragen over kwaliteit betreffen o.a. betrouwbaarheid, beschikbaarheid, duurzaamheid, functionele WYSIWYG. Wat we ook willen weten is hoe snel en hoe goed oplossingen worden geboden bij vragen of onverwachte gebeurtenissen en wat hierover de verwachting van de eindgebruiker/klant is. Om te weten hoe het met de kwaliteit gesteld is moet er dus gemeten worden. Zowel geautomatiseerd als via interactieve feedbackloops met gebruikers van de diensten en producten. En als we dan gemeten hebben wat de kwaliteit is, moet de architectuur ook toestaan dat kwaliteit schaalbaar is. Want na meten en analyseren, komt reageren en daarmee scherpen we dus ook de hierboven beschreven benodigde flexibiliteit aan.

Veiligheid

Misschien hadden we met deze taartpunt moeten beginnen. In de Mazlov pyramide begint het met het hebben van de basisvoorzieningen en de volgende laag is veiligheid. Waar het voor ons begint is dat de license to operate (LTO) van de organisatie nooit in gevaar mag komen. Kort door de bocht betekent dat, dat je aan wet en regelgeving moet voldoen. Niet alleen dien je geen criminele activiteiten te ontplooien of ondersteunen, maar er zijn ook ethische grenzen, als gevolg van de visie, de missie en maatschappelijke context, die je niet overschrijdt. Ook hier is meten weten. Een architectuur zou veilig (op gebied van security, privacy, integrity) ‘by design‘ moeten zijn, zonder dat werken of veranderen onmogelijk wordt. Er is een balans tussen risico’s en de waarschijnlijkheid dat iets gebeurt, versus het gevaar van een bedreigde LTO. Door te meten hoe goed je maatregelen zijn, versus de beperkingen op de speed-to-market, ontstaat een idee over wat redelijk is en wat de bottom line is die niet overschreden mag worden. Niet in de laatste plaats moeten we hier ook imagoschade meenemen. Iets dat strikt gezien niet bij de LTO hoort, maar wat zeker je markt en klanten en per ultimo de levensvatbaarheid van de organisatie beïnvloedt.

Snelheid

Timing en speed-to-market zijn in veel markten het verschil tussen succes en falen. Goede timing is wat van iemand een excellerende ondernemer maakt. Maar omdat de wereld niet stil staat moet er vervolgens geschaald en voortdurend veranderd en geïnnoveerd worden. De snelheid waarmee dat gebeurt (speed-to-market) is cruciaal om relevant en concurrerend te blijven. Strategieën en architecturen dienen snelheid en ability-to-execute te ondersteunen. Snelheid is niet synoniem met efficiëntie of controle (zie verderop in deze blog), maar heeft een soort omgekeerde Lean-strategie. Op het eerste gezicht inefficiënte dubbelingen zouden zomaar heel efficiënt kunnen zijn als je gezichtspunt time-to-market is. Net als een sportwagen telt hier niet liters brandstof per kilometer, maar tijd tot 110 kilometer per uur. Sneller is altijd beter. Mocht dat duurder zijn dan langzaam, bedenk dan dat duurder maar verkoopbaar, goedkoper is dan goedkoop maar te laat en onverkoopbaar. Ook snelheid moet gemeten worden en onderhevig zijn aan voortdurende assessments. De business/IT strategie en architectuur dienen dus zo opgezet te zijn dat bevindingen uit de assessments verwerkt kunnen worden.  Als je je timing kent, dan ken je ook de benodigde snelheid. En dat betekent vaak keuzes maken, want als de timing en veiligheid vast liggen, moeten kwaliteit en functionaliteit vloeibaar zijn. Of zoals Reid Hoffman (co-founder en executive chairman van LinkedIn) gezegd heeft: “If you’re not embarrassed by the first version of your product, you’ve launched too late.”

 

 

Tussendoortjes

Is dit alles? Nee, net zoals bij de voedingsschijf van vijf is er meer. Daar worden het tussendoortjes genoemd en ze kunnen er wel bij, maar niet te veel en niet te vaak. De invloed van zaken zoals efficiency, kosten en complexiteit moet niet te groot zijn. Efficiency is een gevolg van de schijf, niet een oorzaak. Het mag niet het uitgangspunt zijn voor speed-to-market, kwaliteit of flexibiliteit. Hetzelfde geldt voor kosten. Een organisatie die door de boekhouder wordt gerund lijkt vaak op een bedrijf dat onder curatele staat. Kostenbeperking lijkt een soort laatste redmiddel om de zaak in leven te houden, of erger nog, stervensbegeleiding, zodat de aandeelhouders het laatste restje waarde uit de organisatie kunnen persen. Kosten zijn belangrijk en horen te passen binnen de schijf van vijf, alleen zijn ze niet het uitgangspunt, maar een gevolg ervan. Tenslotte: wees niet bang voor complexiteit. De maatstaf voor complexiteit is niet of een manager de ‘dirty details’ snapt. De vraag is vooral, past het en kunnen we het beheersen? En als dat volgens de vakmensen het geval is, zou ik zeggen, leve de noodzakelijke complexiteit.

Gezond verstand

Toch staat er iets heel belangrijks niet in de schijf van vijf. GEZOND VERSTAND! Gezond verstand is een superpower en voorkomt vaak foute beslissingen veroorzaakt door religieus geloof in dogma’s en heilige huisjes. Als er genoeg vakmanschap, en dus gezond verstand, in een organisatie is, kunnen we wellicht de hele schijf van vijf vergeten. Want aan het einde van de dag blijft het werken met mensen die we zouden moeten vertrouwen op hun wil om het beste voor het bedrijf te doen. Zeker voor vakmensen geldt dat er niemand ’s morgens op de fiets naar het werk stapt en denkt: kom, laat ik er vandaag eens een puinhoop van maken. En als we er vanuit gaan dat zowel de wolkenridders als de Excel fetisjisten vakmensen zijn en het beste met elkaar en het bedrijf voor hebben, is het hebben van een gemeenschappelijke taal, begrip van de uitdagingen en samenwerking het belangrijkste dat we kunnen faciliteren.