Gå til indhold
Spekir

EAInsights

Beslutningen ingen kan forklare et år efter

Beslutningen overlever i systemet. Begrundelsen lever i et chatvindue eller ét menneskes hukommelse. Sådan holder en begrundelse, uden et helt arkitekturrepository bag sig.

Rasmus Sloth Nielsen
Rasmus Sloth NielsenFounderLinkedIn

6 min læsetidBeslutninger / Enterprise Architecture / Governance

Hop til afsnit...

En beslutning overlever. Systemet den ændrede kører stadig, leverandøren er stadig under kontrakt, processen fungerer stadig, som den blev sat op til. Det, der ikke overlever, er begrundelsen. Spørg hvorfor beslutningen blev truffet, og svaret lever i en chattråd, ingen kan søge i, et slide fra et møde tre omorganiseringer tilbage, eller hukommelsen hos den ene person, der sad i lokalet. Hvis den person er skiftet til en anden rolle, er begrundelsen væk. Beslutningen er det ikke.

Det er ikke en historie om dårlige dokumentationsvaner. Det er en historie om, hvor organisationer vælger at bruge kræfter. At skrive en beslutning ned i det øjeblik, den træffes, koster nogle minutter. At rekonstruere den atten måneder senere, når en ny CIO vil vide, hvorfor landskabet ser ud, som det gør, koster dage med at spørge sig frem og gætte. De fleste organisationer betaler den anden pris uden at bemærke, at de havde et valg.

Hvorfor begrundelsen forsvinder hurtigere end beslutningen

Beslutningen selv er holdbar, fordi den er indlejret i noget, der bliver ved med at køre: et system forbliver installeret, en kontrakt forbliver underskrevet, en proces forbliver på plads, indtil nogen aktivt ændrer den. Begrundelsen bag beslutningen har intet tilsvarende anker. Den levede i en samtale, og samtaler slutter. Den levede i nogens vurdering af de muligheder, der var til rådighed dengang, og den vurdering blev aldrig skrevet ned, fordi det føltes som overhead i selve øjeblikket, beslutningen blev truffet.

Så asymmetrien vokser. Beslutningen består som standard. Begrundelsen forfalder som standard. Et år efter har organisationen hvad'et og har mistet hvorfor'et, og de to er ikke lige nemme at genskabe: hvad'et er synligt i systemet, hvorfor'et skal rekonstrueres fra mennesker, og mennesker glemmer, skifter job eller husker det forskelligt fra hinanden.

Hvad en begrundelse faktisk skal indeholde for at holde

En begrundelse, der overlever, kræver ikke et helt arkitekturrepository bag sig. Den kræver fire ting, og alle fire er små nok til at skrive ned i minutterne lige efter en beslutning er truffet, ikke måneder senere.

Hvad beslutningen var. Ikke det tekniske detaljeniveau, men selve valget: hvilket system, hvilken leverandør, hvilken fremgangsmåde, formuleret klart nok til, at nogen, der ikke kender projektet, kan læse det og forstå, hvad der ændrede sig.

Hvad man vidste på det tidspunkt. Den kontekst, beslutningen blev truffet i: hvilket problem den løste, hvilke begrænsninger der gjaldt, hvilken information der var tilgængelig. Det er den del, der forsvinder hurtigst, fordi den holder op med at være indlysende, i det øjeblik omstændighederne ændrer sig. Det, der lignede den eneste fornuftige mulighed i et givet kvartal, kan se vilkårligt ud et år senere, hvis ingen noterede de begrænsninger, der gjorde det fornuftigt.

Hvad der ellers var på bordet. De muligheder, der blev overvejet og fravalgt, og nogenlunde hvorfor. En beslutning, der navngiver sine alternativer, er langt lettere at forsvare senere end en, der kun navngiver sit resultat, for "vi valgte X" inviterer spørgsmålet "hvorfor ikke Y", og hvis Y aldrig blev overvejet på skrift, kan ingen svare med sikkerhed.

Hvem der besluttede, og hvad de forventede skulle ske. En navngiven ejer og den konsekvens, beslutningen var tænkt til at give. Uden en ejer bliver en beslutning et forældreløst barn, som alle kan pege på, og som ingen kan tale for. Uden en angivet forventning er der intet at sammenligne resultatet med senere.

Intet af dette er arkitekturdokumentation i traditionel forstand. Det ligner mere en kvittering: kompakt, knyttet til selve beslutningsøjeblikket, og nyttig netop fordi den er let nok til, at nogen rent faktisk gemmer den.

Sådan ser det ud, når det bliver holdt fast

En beslutningslog, der indeholder disse fire ting, gør noget, et slide ikke kan: den forbliver søgbar, efter mødet er glemt. I Atlas bærer en beslutningspost en angivet kontekst, de alternativer der blev overvejet, en ejer, en status og den konsekvens, der var forventet. Hver beslutning kan også kobles til de applikationer og kapabiliteter, den berører, så nogen, der spørger "hvad påvirker denne beslutning faktisk", får et svar i stedet for et gæt. Intet af det erstatter dømmekraft. Det betyder bare, at den dømmekraft, nogen udøvede for et år siden, stadig er synlig for den, der skal bygge videre på den i dag.

De organisationer, der taber mest tid, er ikke dem med dårlig arkitektur. Det er dem, hvor arkitekturen er fin nok, men hvor ingen kan forklare, hvordan den blev sådan. Et landskab uden sporbare beslutninger er ikke forkert, men ethvert spørgsmål om det bliver til en efterforskning. Et landskab med sporbare beslutninger gør det samme spørgsmål til et opslag.

En test, du kan køre i denne uge

Vælg en beslutning, din organisation traf for et år siden. Hvilken som helst: et leverandørskifte, en systemudfasning, en procesændring der holdt. Bed nu en kollega, der ikke var i lokalet, om at finde ud af, hvorfor den blev truffet, uden at spørge den, der traf den.

Kan de finde begrundelsen i et dokument, i en post, i noget der ikke afhænger af, at én bestemt persons hukommelse er intakt og tilgængelig, så holder beslutningen. Er den eneste vej til et svar gennem nogens erindring om et møde, står beslutningen stadig, men begrundelsen bag den begyndte allerede at forsvinde den dag, den blev truffet. Forskellen mellem de to udfald er ikke en dokumentationspræference. Det er forskellen på en organisation, der kan forklare sig selv, og en, der kun kan gætte.

DelLinkedInX

Spekir bygger det lag, der forbinder strategi med IT-porteføljen. Se Atlas

Relaterede artikler