U bevindt zich hier


Enterprise Architectuur wordt ingezet om grip te krijgen op de informatievoorziening. Solution Architecturen worden gemaakt om project specifieke oplossingen in te kaderen. In de loop der jaren zijn er vele honderden – zo niet duizenden – modellen en beleidskaders gemaakt. Voor een goed rendement moet de kennis die daarin is vastgelegd laagdrempelig worden ontsloten en van een hoog kwaliteitsniveau zijn. En daar mankeert het vaak aan. Architecten geven prioriteit aan de interactie met stakeholders (ook een goede ontwikkeling), maar dat gaat wel ten koste van de borging van het architectuurfundament. Hergebruik wordt lastig omdat stukken onvindbaar zijn, geen status hebben, steeds weer andere lay-out en inhoud hebben, en het onduidelijk is welke stukken er überhaupt zouden moeten zijn. Het gevolg is teveel architectuur met te weinig effect.

De uitdaging

Het gebrek aan een deugdelijke borging van architectuur is geen incident, maar heeft structurele oorzaken, zoals:

  • De eisen die we aan (enterprise) architecten stellen worden steeds hoger. Hij moet zich op Boardroom-niveau begeven en sturing geven aan een alsmaar complexere omgeving. Deze senior architect doet niet aan documentatie en beheer.
  • Er is geen silver bullet. Oplossingen van toolleveranciers voldoen niet. Het probleem heeft meer kanten: governance, cultuur, inzicht in hoe architectuur werkt.

Het gevolg is dat enterprise architectuur zijn betekenis verliest. Architectuur komt onder vuur te liggen.

Een oplossing

Veel organisaties zoeken naar mogelijkheden om hun architectuurfunctie meer lean en agile te maken. Dat komt echter niet zo maar uit de lucht vallen. Architectuur naar projecten brengen vraagt om een slimme inrichting van de architectuurfunctie en een solide basis waar iedereen snel uit kan putten. Die solide basis bestaat uit een beheerde en lean repository, met niet te veel, maar ook niet te weinig inhoud. Kernvragen zijn:

  • Welke producten wil ik telkens weer gebruiken (bijvoorbeeld bij elk project)?
  • Wat zijn de belangrijkste architectuurkeuzes waarvoor we ons gesteld zien?
  • Wat willen we onderhouden en wat willen we alleen maar onthouden?

Daarnaast moeten ook de implementatie (vullen, uniformeren, ontsluiten, support) geregeld zijn. De uitdaging is niet de techniek, maar de discipline van de uitvoering. Hoe groter de organisatie, hoe beter de business case om dit te organiseren. Wij noemen dit de Architectuur Management Back Office (AMBO), geïnspireerd door de advocatuur, waar de uitvoerende advocaat wordt bijgestaan door een back office van juristen die jurisprudentie, wetten, getuigenverklaringen e.d. doorakkeren.

Business case AMBO

De voordelen van een AMBO zijn:

  • Kennis verdampt niet langer, maar wordt gecodificeerd: er wordt een geheugen ingericht die randvoorwaardelijk is voor agile en lean werken.
  • Het expliciet maken van het back office deel maakt dat het herkend en gewaardeerd wordt. Er is iemand die er van is.
  • Al het werk dat is gaan zitten in referentiemateriaal wordt eindelijk gebruikt. Projecten kunnen een vliegende start maken. De architectuurbelofte wordt waargemaakt.

Uit benchmarks blijkt dat tussen de 25% en 40% van de IT-projectkosten zit in het in kaart brengen van de bestaande situatie. Met een geborgde architectuur kan minstens 10% van afgehaald worden.

Dat is dan 10% van uw IT budget voor projecten!

Waar komt die 10% vandaan? Projecten willen van alles weten over de relaties tussen processen, systemen, gegevens, infrastructuurcomponenten en nog veel meer. Dat is complex. Vragen als ...

  • Welke applicaties ondersteunen dit proces?
  • Wat gaat er mis er als deze applicatie uitvalt?
  • Waar worden deze gegevens beheerd?

... blijken elke keer weer een puzzel te zijn waarmee kostbare tijd verloren gaat. Het elke keer weer opnieuw uitzoeken is een van de grootste 'waste'-factoren van de moderne IT. Eigenlijk te gek voor woorden: een kwart van je budget uitgeven om te bepalen waar je bent!?

'Agile' zet architectuur op scherp

In veel van onze blogs gaan we in op het fenomeen 'Agile'. Agile architectuur is m.i. niet meer een vrijblijvende keuze. Agile development wordt steeds meer de norm en vraagt van de architectuur een grotere betrokkenheid en dus tijd. Die tijd moet ergens vandaan komen. Te weinig nadenken leidt tot een pattern dat ik 'stumble upon' architectuur noem. Een relevante vraag is: hoeveel moet je nadenken voor je met een sprint begint? De antwoorden op die vraag beginnen naar elkaar toe te bewegen. In het Scaled Agile Framework 3.0 is een aanzienlijke plaats voor architectuur ingeruimd en architectuurbenaderingen als DYA krijgen ook steeds meer een agile interpretatie.
"Responding to change over following a plan" is één ding, maar je wilt wel een richting hebben. Big Design UP Front werkt niet, maar wat dan wel? BDUF heeft 4 problemen:

(1) het duurt te lang,

(2) het is niet actueel,

(3) stakeholders zijn onvoldoende betrokken, en

(4) het is te abstract voor hapklare consumptie.

Daaruit volgen:

(5) Te duur, en

(6) Niet geaccepteerd

De inhoud van een Enterprise referentie-architectuur kan verdeeld worden in:

  • Documentatie van de bestaande situatie
  • Kaders, standaarden, richtlijnen, etc. die richting geven
  • Documenten die de gewenste situatie beschrijven; de doelarchitectuur.

Met een AMBO is het streven dat het eerste deel geen tijd meer kost waar projecten last van hebben. Kaders en richtlijnen kosten tijd, maar niet overdreven veel. En de doelarchitectuur? We denken dat een visie op hoofdlijnen, en het uitwerken volgens het principe 'Just-in-time Just-enough' in projecten voldoende is. Daarmee zijn (1) en (2) opgelost. Betrokkenheid van architecten bij projecten op een agile manier lost problemen (3) en (4) op: in projecten moet je wel pragmatisch blijven.

Conclusie

Enterprise architectuur kan en moet aansluiten bij de behoefte aan agile ontwikkelen. Daarvoor moet het richting geven zonder de pretentie te hebben een blauwdruk te leveren. En om projecten just-in-time te kunnen bedienen moet huidige architectuur op de plank liggen. Er is gewoon geen tijd meer om dat telkens opnieuw uit te zoeken. Het kan uit om de enterprise (architecten) te voorzien van een architectuur management back office!

DEEL DIT ARTIKEL
VOLG ONZE BLOGS

Gerelateerde blog artikelen

  • Good Ideas - Agile en architectuur

    Deze animatie geeft de essentie van agile weer en zet ook de relatie met architectuur op scherp. Maar de kijkers komen niet altijd tot dezelfde conclusies.

    Lees verder
  • Het stiefkind van de enterprise architectuur

    Ik stel me voor dat u bij het lezen van deze titel onbewust al heeft ingevuld waar ik het over heb. En ik stel me ook voor dat velen van u het goed geraden hebben. De Architectuur van de Technische Infrastructuur, verder afgekort met TIA.

    Lees verder
  • Niet met 'n Ferrari in de file

    Deze blog gaat over de agile enterprise, en wat er voor nodig is om agile te worden. (Dan komen we vanzelf weer uit bij architectuur, maar net even anders.)

    Lees verder
  • Waar blijft het applaus?

    Het overkomt ons allemaal wel eens. Je hebt je best gedaan op een mooi stuk werk, en je bent trots op het resultaat. De analyse is degelijk, de architectuur die je bedacht hebt is beter dan marktconform, helder gedocumenteerd en gepresenteerd.

    Lees verder
  • ‘Just enough’ architectuur

    In gesprek met collega’s en klanten over hoeveel architectuur een organisatie nodig heeft, lijken we elkaar te kunnen vinden in de formulering ‘Just-enough’. Maar hoeveel is dat dan?

    Lees verder

Cookies op de website van Inspearit

Wij plaatsen functionele cookies, om deze website naar behoren te laten functioneren, analytische cookies waarmee wij het gebruik van de website kunnen meten en cookies van derden voor het weergeven van emdeded media (YouTube en GoogleMaps) Hieronder kan je aangeven welke andere soorten cookies je wilt accepteren:

Meer informatie