Strategy-til-arkitektur loops: hvorfor temaer kræver initiativer kræver apps

Spørg en CIO, om virksomheden har en IT-strategi. Svaret er ja.

Spørg om strategien er koblet til IT-porteføljen. Svaret er som regel: "Vi arbejder på det."

Det er ikke en teknisk fejl eller en politisk undladelse. Det er et strukturelt problem. De fleste EA-værktøjer og strategiprocesser modellerer enten arkitektur eller strategi — men ikke loopet imellem dem. Og loopet er præcis det, der afgør, om en strategi omsættes til handling, eller om den forbliver et aspiration-dokument i en skuffe.

Denne artikel beskriver loopet: temaer, initiativer og applikationer som tre forbundne lag, og hvad der sker, når koblingerne mangler.

Hvad er et strategi-til-arkitektur loop

Loopet er ikke en ny idé. Det er formaliseret i Roger Martins og A.G. Lafleys "Playing to Win" (2013) som strategikaskaden: en vindende ambition, der brydes ned til valg af slagmark, valg af vej til sejr, de nødvendige capabilities og de managementsystemer, der driver capability-opbygningen.

Richard Rumelt tilføjer i "Good Strategy / Bad Strategy" (2011) en central indsigt: en god strategi er ikke en liste af ambitioner. Det er en diagnose af problemet, et vejledende princip og en sammenhængende sæt af handlinger. Handlingerne er afgørende — ikke som uafhængige tiltag, men som et system, der forstærker hinanden.

I EA-praksis oversættes dette til tre lag:

Strategiske temaer — de to til fire overordnede prioritetsområder, der definerer, hvad organisationen er villig til at ofre noget for. Ikke "vi vil vokse" (det siger alle). Men "vi vælger at differentiere på kundeoplevelse frem for produktbredde — og det kræver, at vi investerer i vores kundedata-platform frem for i yderligere produktlinjer."

Initiativer — de konkrete projekter, der omsætter temaerne til handlinger. Initiativer er tidsbundne, har ejere og koster noget. De er broen mellem intention og eksekvering.

Applikationer og capabilities — den teknologiske realitet. De applikationer, der faktisk leverer de capabilities, initiativerne forudsætter. Og den tekniske gæld, der bremser det.

Loopet er ikke lineært. Det er en feed-back-cyklus: temaer informerer initiativer, initiativer driver applikationsvalg og -investeringer, og applikationernes faktiske tilstand (TIME-klassificering, teknisk gæld, integration med andre systemer) informerer realismen i de strategiske temaer.

Strategiske temaer uden initiativer er aspirationer. Initiativer uden applikationer er teater. Applikationer uden strategisk kontekst er vedligeholdelse af status quo. Loopet er det, der giver alle tre meningsfyldt.

Temaer som retning, ikke som mål

Et strategisk tema er ikke en KPI. Det er en retning.

Forskellen er afgørende. En KPI siger: "Øg kundetilfredsheden med 15% i indeværende regnskabsår." Et strategisk tema siger: "Vi vælger at vinde på kundeoplevelse — det er det, vi er villige til at investere i og ofre andre ting for."

Temaet definerer en prioritering, ikke et resultat. Det gør det muligt at svare på spørgsmålet: "Skal vi investere i dette initiative?" med andet end mavefornemmelse. Svarer initiativet til et tema, vi har forpligtet os på? Eller er det et nice-to-have?

I praksis bør et virksomheds strategiske temaer:

Være få — to til fire. Hvis alt er prioriteret, er intet prioriteret.

Være eksklusive — valget af temaer betyder fravalg af andre områder. En strategi, der ikke udelukker noget, er ikke en strategi.

Være tilstrækkelig specifikke til at guide beslutninger. "Vi vil være digitalt fremragende" er ikke tilstrækkeligt specifikt. "Vi investerer i vores digitale kundekanal frem for vores distributionsnetværk" er det.

Eksistere på et tidsniveau, der er realistisk for IT-portef øljens investeringscyklus — typisk 18-36 måneder, ikke et kvartal og ikke ti år.

Initiativer som oversættelseslag

Initiativet er det sværeste led i kæden. Det er her, strategi og teknologi mødes — og oftest går galt.

Et initiativ er et strategisk tema gjort operationelt: det har et klart formål (hvad forbedres?), en ejer (hvem er ansvarlig?), en tidsramme (hvornår er det done?), et ressourcekrav (hvad koster det?) og en IT-forbindelseskabel (hvilke applikationer og capabilities er det afhængigt af?).

Det sidste punkt — IT-forbindelseskabelet — er det, de fleste initiativer mangler. Et initiativ til at forbedre kundeportalen definerer sjældent eksplicit: "Vi forudsætter, at vores CRM-system kan eksponere realtime-kundedata via API, og at vores identitetssystem understøtter SSO på tværs af mobile og web." Når disse forudsætninger er usande (og de er det oftere end man tror), overraskede implementeringen, forsinkelserne starter, og initiativet leverer delvist eller for sent.

Et godt initiativregister kobler hvert initiativ til:

De specifikke capabilities, der kræves. Ikke bare "vi har brug for et godt CRM" — men "vi kræver, at CRM'et kan levere kundeinteraktionshistorik opdateret med under 5 minutters forsinkelse til vores salgsassistent-AI."

De applikationer, der leverer eller blokerer de capabilities. Her krydses til TIME-klassificeringen: er de relevante applikationer i "Invest", "Migrate", "Tolerate" eller "Eliminate"? Et initiativ, der forudsætter en applikation i "Eliminate"-kategorien, er allerede i vanskeligheder.

De afhængigheder til andre initiativer. Initiativer er sjældent uafhængige. Et initiativ til at migrere til en ny datahub blokerer for tre andre initiativer, der er afhængige af den eksisterende datastruktur.

Applikationer og capabilities som faktum

Arkitekturen er ikke hvad vi ønsker, den var. Den er hvad den er.

Det er den indsigt, som gør EA til andet end PowerPoint-slides. En ærlig porteføljeoversigt viser applikationernes faktiske tilstand: teknisk gæld, integration-mønster, leverandøraftaler, support-status. Og den tilstand er ikke formbar på kort sigt.

Det har to implikationer for loopet:

Nedadgående: Arkitekturen definerer råderummet. Initiativer, der forudsætter capabilities, den eksisterende applikationsportefølje ikke kan levere, er ikke strategisk mulige uden yderligere investeringer. Denne realitet bør informere, hvilke initiativer der er realistiske at forpligte sig på indenfor den strategiske tidshorisont.

Opadgående: Arkitekturen informerer temadefinitionen. Hvis porteføljens tilstand viser, at den fundamentale datakvalitet er for lav til at understøtte AI-drevne kundeoplevelser, kan et tema om "Vinde på AI-personalisering" ikke realiseres uden en forudgående investering i datakvalitet. Det er en strategisk realitet — og den bør afspejles i temadefinitionen.

De fleste strategiprocesser starter med ambition og slutter med roadmap. Loopet kræver, at du starter med realitet: hvad kan vi faktisk levere med den applikationsportefølje, vi har — og hvad kræver det at ændre det?

Loopet som feedback-mekanisme

Det, der gør loopet til et loop (og ikke en lineær kaskade), er feedback.

Et strategisk tema formuleres baseret på en bestemt forståelse af, hvad der er muligt. Når initiativerne implementeres og applikationsporteføljens faktiske tilstand viser sig anderledes end antaget, skal dette føres tilbage til temaet. Skal temaet justeres? Skal det suppleres med et forudgående initiativ til at forbedre den teknologiske fundament? Skal investeringsprofilen ændres?

Feedback-mekanismen kræver to ting:

En struktureret kobling mellem initiativstatus og strategisk status. Ikke bare "initiativet er forsinket" — men "initiativet er forsinket, fordi vores CRM-integration er mere kompleks end antaget, og det forsinkelse påvirker temaet 'Vinde på kundeoplevelse' med 6 måneder."

Et forum, der behandler disse feed-backs. Typisk en kombineret arkitektur- og strategiproces, der mødes kvartalsvist og ser på begge lag. Ikke en IT-styregruppe (der kun ser IT) og ikke en ledelsesworkshop (der kun ser strategi), men en integreret proces.

Hvad der går galt uden loopet

Tre mønstre er hyppigere end andre, når loopet mangler:

Phantom-initiativer: Initiativer, der godkendes strategisk uden at checke, om den underliggende applikationsportefølje kan understøtte dem. De leverer delvist, for sent eller på ikke-brugbare funktioner — fordi grundlaget mangler.

Orphan-applikationer: Applikationer, der ikke er koblet til noget strategisk initiativ og derfor hverken investeres i eller udfases. De akkumulerer teknisk gæld og maintenance-omkostninger uden at bidrage til strategisk retning.

Strategi-drift: Temaer, der ikke opdateres, når arkitekturrealiteten ændrer sig. Over tid divergerer den strategiske plan og den teknologiske virkelighed, og det bliver uklart, hvad der faktisk prioriteres.

Alle tre mønstre kan identificeres og adresseres, hvis loopet er synligt. De er usynlige, hvis det ikke er.

Hvad gøres i morgen

Strategy-til-arkitektur loopet er ikke et projekt. Det er en praksis. Tre skridt til at starte:

Uge 1: Identificér de to til fire strategiske temaer, organisationen faktisk er forpligtet på — ikke hvad der er skrevet i strategien, men hvad der faktisk prioriteres i investeringsbeslutninger. Skriv dem ned i ét dokument.

Uge 2: Map de aktive initiativer til temaerne. For hvert initiativ: identificér de top-3 capability-krav og de applikationer, der leverer (eller blokerer) dem. Identificér de initiativer, der mangler en kobling.

Uge 3: Gennemgå TIME-klassificeringen for de applikationer, der er kritiske for de vigtigste initiativer. Identificér de discrepancer, der udgør en strategisk risiko.

Loopet er aldrig perfekt. Det er heller ikke formålet. Formålet er at gøre koblingerne synlige nok til at tage bedre beslutninger.

Referencer

[1] Roger L. Martin og A.G. Lafley, "Playing to Win: How Strategy Really Works", Harvard Business Review Press, 2013.

[2] Richard Rumelt, "Good Strategy / Bad Strategy: The Difference and Why It Matters", Crown Business, 2011.

[3] TOGAF Standard, version 10, "Architecture Development Method (ADM)", The Open Group, 2022.