Det mere komplekst en opgave bliver desto sværere er det at finde en retning som leder til resultater. Blogindlægget omhandler de tanker som jeg har gjort mig om sammenhænge mellem kompleksitet og enterprisearkitektur.

I en it-kontekst vil der typisk være tale om at skulle leverer resultater inden for et givent tidspunkt for at opretholde tillid mellem beslutningstagerne i forretningsenhederne og i it-afdelingen. Hvis der ikke er tillid mellem de forskellige parter så vil det med stor sandsynlighed medføre at den rette beslutning ikke træffes. Tillid er en nødvendighed eller vil beslutninger træffes på grund af de forskellige interessenter hellere vil prioritere deres egne områder frem for fælles løsninger.

Kulturen omkring håndtering af beslutningsprocesser spiller en stor rolle set i forhold til evnen til at kunne håndtere en række forskellige problemstillinger som påvirker med kompleksitet og i forhold til om de rette beslutninger træffes på de rette tidspunkter.

Hvad er kompleksitet?

I en it-kontekst vil der være tale om at kompleksitet er at for mange faktorer så som integration, målsætninger og processer blandes sammen i en kontekst, hvor it-udvikling finder sted.

Kompleksitet kan ikke reduceres, men beslutningstagerne i it-afdelingen kan være med til at påvirke dem, men det kræver samtidigt at der findes de rette forudsætninger i organisationen.

Kompleksitet kan anskues på mange måder. Både Roger Sessions og David Snowden har skrevet værker om kompleksitet, hvortil den første har skrevet et værk som omhandler enterprisearkitektur og især softwareudvikling. Snowden arbejder med et rammeværk der oprindeligt blev brugt til videnledelse som kaldes for Cynefin. Efter min mening er rammeværket også brugbart set i forhold til at analysere forhold for beslutningstagere.

Sessions fremgangsmåde varierer fra Snowdens fremgangsmåde ved at den primært fokusere på at undersøge mulighede for at nedbryde store problemstillinger til mindre og derigennem sikrer fremgang for projekter med specielt fokus på it-projekter og den kompleksitet som typisk findes ved at udvikle it-projekter i en dataarkitektur – og teknologisk arkitektur som er kendetegnet ved lav modenhed og en række aldrende løsninger som er integreret med hinanden. Jeg mener, at Sessions fremgangsmåde er relevant fordi han demonstrativt viser at nedbryde store opgaver til mindre komplicerede problemstillinger vil kunne understøtte hurtigere udvikling af en bedre kvalitet.

Niveauer for kompleksitet

Der findes fire niveauer for kompleksitet (Snowden 2007-2010):

1)    Simpelt som er kendetegnet ved at der findes en direkte forbindelse mellem det som sættes i gang af beslutningstagerne og resultaterne.

2)    Kompliceret er kendetegnet ved at der ikke nødvendigvis er en direkte forbindelse mellem de initiativer som sættes i gang af beslutningstagerne og de resultater som opnås.

3)    Komplekst er kendetegnet ved at der ikke findes direkte kendskab til hvordan problemstillingerne skal håndteres og hvordan der måles på om problemstillingerne bliver løst.

4)    Kaos, hvor beslutningstagerne vil sætte initiativer i gang som vil påvirke den overordnede struktur for organisationen, og hvor det ganske enkelt ikke vil være muligt at kunne måle på om problemstillingerne blev løst med de problemstillinger der blev foretaget. Det er på dette niveau, hvor organisationerne kan bidrage til at skabe fundamental ny viden.

Imellem disse niveauer for kompleksitet findes der et specifikt område der kaldes for “disorder”.

 

Det er muligt at navigere mellem de forskellige niveauer for kompleksitet, men det kræver at der findes en samlet enhed i organisationen som arbejder aktivt med at navigere mellem de forskellige niveauer af kompleksitet som henholdsvis forretningsprocesserne og applikationerne operere med.

En faktorer som kan anvendes til at navigere mellem flere forskellige niveauer for kompleksitet er simplificering af faktorer der indregnes i den kontekst som en problemstilling skal løses igennem it-projektet. Det kan vise sig at være en strategisk egenskab at kunne gå fra de forskellige niveauer for kompleksitet set i forhold til at kunne sætte projekterne i gang og sikrer fremgang.

Hvad kompleksitet påvirker?

It-udvikling kan finde sted både i miljøer som er meget komplekse og miljøer som er afgrænset og nemme at gå til. Kompleksitet har indflydelse på tre faktorer der i sidste ende vil påvirke it-projekternes egenskaber set i forhold til leverance inden for det aftalte tidsrum, inden for de aftalte omkostninger og inden for den aftalte kvalitet.

De tre faktorer er som følgende:

• Tid
• Scope
• Ressourcer.

Hvordan kan it-strategien tage højde for kompleksitet?

Kompleksitet kan ikke reduceres, men beslutningstagerne i it-afdelingen kan være med til at påvirke dem. Beslutningstagerne kan være med til at påvirke graden af kompleksitet ved at der træffes en række beslutninger som omhandler hvilke projekter der udvælges samt hvilke standarder og regler projekterne skal overholde. It-strategien er i udgangspunktet en opstilling af de forretningsmæssige målsætninger og egenskaber, hvortil it-strategien udleder hvilke it-projekter som antages vil leverer de tekniske komponenter som skal til for at organisationen opnår de ønskede forretnings egenskaber og målsætninger.

It-strategien har ligeledes til formål at udlede, hvordan organisationen kan udnytte de muligheder som findes ved den specifikke teknologi ved at tilpasse processer og informationsteknologierne.

Enterprisearkitektur programmet har typisk haft til opgave at finde frem til, hvordan de forskellige applikationer hænger sammen, og hvordan de forskellige forretningsprocesser gør brug af applikationerne.

Det er enterprisearkitekterne der i samråd med løsningsarkitekterne arbejder med at finde frem til, hvordan udviklingen på de enkelte applikationer kan finde sted på den mest hensigtsmæssige måde.

De er med andre ord vant til at navigere i kompleksitet, og det vil typisk være hos enterprisearkitekterne at beslutningstagerne vil kunne finde information om kompleksitet. Kompleksitet som vil påvirke organisationens mulighed for at arbejde videre med sin operating platform har som regel også indflydelse på, hvor god organisationen er i forhold til at omstille sig de behov som organisationen har.

Enterprisearkitekterne vil derfor være i stand til at validere it-strategien og arbejde for at de rette projekter bliver prioriteret således de projekter der bør udarbejdes under de retter kompleksitetsniveauer således de bliver implementeret rettidigt så den størst mulige værdi skabes.

Konklusion

Igennem teknologistrategien kan beslutningstagerne i it-afdelingen påvirke nogle af de faktorer som på sigt vil påvirke it-afdelingens evne til at udvikle og implementere løsninger.

Der findes en række interessante problemstillinger ved at navigere i kompleksitet herunder at der findes de rette mennesker i fx it-afdelingen der kan understøtte udviklingen.

Enterprisearkitektur programmet bør aktivt arbejde med at identificere de muligheder for kompleksitet som findes og de bør igennem af rapportering til projektkontoret og dem der udvælger de forskellige it-projekter.

Kilder

Ross, Jeanne W., Peter Weill, and David C. Robertson. Enterprise Architecture as Strategy: Creating a Foundation for Business Execution. illustrated ed. Harvard Business School Press, 2006.

Sessions, Roger. Simple Architectures For Complex Enterprises: Best Practices. 1st ed. MICROSOFT PRESS, 2008.
Snowden, D., The Origins of Cynefin, 2007 – 2010, Cognitive Edge.