CASE: Forretningsmodellen i Enterprise Arkitektur (4)

 I casestudiet ville det give god mening, hvis en eller flere af interessenter inden for EA funktionen havde fået vist, hvordan værdi skabes ved hjælp af enterprise arkitektur. Artefaktet ville kunne bruges til at overbevise de forskellige interessenter om, hvorfor behovet egentlig eksisterede for, at en EA funktion var implementeret i organisationen, set ud fra en værdiskabelses optik.

I forhold til at kunne kommunikere værdien af enterprise arkitektur programmet og funktionen kan interessenterne i organisationen vælge at anvende en tilpasset udgave af en forretningsmodel som fx i ”The Business Model Canvas” .

Set i forhold til caseorganisationens situation, så var der mange ideer der kan tages i betragtning. Caseorganisationen er på det niveau som Doucet et al (2009) ville kalde for fundament arkitekturen. Fundament arkitekturen er rettet mod, at EA-funktionen og EA-gruppen primært arbejder med at levere resultater til beslutningstagerne der findes i it-afdelingen med henblik på, at få styr på, hvilke it-projekter der skal sættes i gang for at kunne understøtte organisationens forretningsstrategi.

Dermed sagt så er fokus ofte på at identificere, hvor mange applikationer der findes i arkitekturen, og hvordan de anvendes samt hvem der anvender dem.

Caseorganisationen er ikke særlig moden set i forhold til, hvordan beslutningstagerne anvender EA-funktionen.

I udgangspunktet antages det, at den specifikke caseorganisation ikke sælger sine konsulenter som en ydelse til andre (i hvert fald ikke til andre uden for organisationen) så må der være tale om at enterprise arkitektur funktionen servicere interne kunder. Dermed sagt så findes der en række forskellige typer interessenter der påvirkes af enterprise arkitektur programmet, hvis enterprise arkitektur programmet vel at mærke bliver implementeret korrekt.

I kraft af at der ikke er nogen decideret indkomst igennem salg af konsulenterne eller EA-features, så må det antages at caseorganisationen anvender et budget og som sådan opfattes som et omkostningscenter (jf. opfattelsen af Kaplan & Norton 1998). EA-funktionen anvender ressourcer fra andre teams og afdelinger ved at enterprise arkitekterne og løsningsarkitekterne i deres søgen for at finde ud af, hvordan it-arkitekturen hænger sammen, og hvordan virkeligheden meningsfyldt kan simplificeres.

Caseorganisationen havde derudover en lille forretningsarkitektur afdeling, hvor det primære fokus var at identificere, hvordan koncerncentret kunne optimere sine aktiviteter og processer således it og forretning kunne understøtte hinanden på en mere effektiv måde.

Dermed kommer de forskellige afdelinger og teams med input til forretningsmodellen. Blandt ressourcerne der anvendes i den specifikke caseorganisation må der primært være tale om mennesker og menneskernes egenskaber.

Egenskaberne og den måde de enkelte arkitekter anvender dem på er fundamentet for de ressourcer der anvendes i produktionen. Caseorganisationen anvender ikke et konkret enterprise arkitektur værktøj fx MEGA Suite, QualiWare eller MooD (AE), i stedet bruges Microsofts kontorpakke og tillægspakken Microsoft Visio.

I udgangspunktet deles dokumenter typisk over caseorganisationens intranet og netværksdrev. På visse tidspunkter anvendes også organisationens ESDH-system. På sin vis må det tolkes som værende ressourcer, men i udgangspunktet er det kun de primære ressourcer der bør illustreres i forretningsmodellen. Det er ikke alle data der bør eksponeres i forretningsmodellen, da det kun vil gøre det svært at skabe et overblik over, hvordan enterprise arkitektur programmet skaber værdi, og derfor vælger jeg kun at anskue arkitekterne som værende nøgleressourcer.

Ydermere mere genoptræder arkitekterne som en del af nøgleaktiviteterne. Det er nødvendigt for at få afbillede artefakter og udarbejde modeller og planer, som ledelsen kan tage i brug for at få organisationen til at påbegynde en rejse.

Efter de to førnævnte faser findes fasen ”Value Proposition” der omhandler, hvad det egentlig er som enterprise arkitektur funktionen leverer af services eller produkter til sine kunder. Hvordan skaber det værdi for de forskellige teams?

Dernæst kommer ”Team Relations” som omhandler de relationer som enterprise arkitekterne og chefarkitekten har til de forskellige teams eller grupperinger der står for behandling af de forskellige problemstillinger.

Dernæst kommer ”Channels” som omhandler leverance af de services og produkter som enterprise arkitektur funktionen som helhed levere til organisationen.

Dernæst kommer ”Segments” som omhandler forskellige segmenter i it-afdelingen. Det er som regel en evaluering af de forskellige områder eller teams der kan anvendes.

Der findes tre yderligere faser. Disse faser omhandler de økonomiske strømme der er i organisationen, eller det som jeg har valgt at kalde for it-investering. Først og fremmest har de forskellige arkitekttyper (forretningsarkitekt, informationsarkitekt og enterprise arkitekterne) til opgave at identificere, hvordan de nuværende it-investeringer er opbygget. Den efterfølgende fase omhandler planlægning set i forhold til, hvordan en strategi kan hjælpe beslutningstagerne med at skabe et større afkast, og dermed antager jeg, at større afkast betyder en bedre styring af it-arkitekturen. Den sidste fase omhandler den optimerede it-investering, hvilket betyder at investeringerne skal forankres i organisationen.

Caseorganisationen var i en situation, hvori der var formuleret nogle SLA (Service Level Agreements) for, hvordan eller hvor godt it-arkitekturen skal fungere for at kunne stabile services. Stabile services er nødvendig for udvikling. SLA’erne har en betydning for, hvor godt organisationens it-afdeling skal være til at levere resultater i forhold til organisationen og i længden til kunderne. Disse SLA’er fastlagde det som kunderne internt i organisationen.

Værdiskabelsen i caseorganisationens situation var ved at anvende et enterprise arkitektur program til at skabebro mellem de forskellige teknologiske siloer. Siloerne bidrager hver især med forskellige specialiserede systemer men de data der er til rådighed i hver silo er ikke nødvendigvis tilgængelige for de andre systemer. Men i udgangspunket så virker specialiserede systemer ikke særlig godt, hvis data på tværs af applikationerne ikke står til rådighed for koncernen og de borgere som de servicere. Den anden del af fasen ”value proposition” går ud på få de forskellige forretningsrelaterede processer ville kunne udføres mere, bedre og billigere, hvilket ville understøtte de målsætninger som ministeriet for det pågældende område og finansministeriet overleverede omkring behov for opgave og omkostningshåndtering.

Men for at kunne levere resultaterne krævede det at enterprise arkitekterne og chefarkitekten var i stand til at kunne kommunikere meningsfyldt med de forskellige teams der findes på koncernniveau og på de enkelte afdelinger der findes andre steder i landet end i København, hvor koncerncentret er lokaliseret.

Teamrelationerne er essentielle og her fejlede enterprise arkitektur gruppen og chefarkitekten meget stort. Teamrelationen kunne i caseorganisationens tilfælde kunne på sin vis også være mellemlederne og topledelsen.

Kanalerne der er til rådighed kommer igennem projekter og ”project management office” eller i visse tilfælde være ”portfolio management office”. En anden del af fasen som kunne være gældende i caseorganisationens tilfælde ville være de ledelsesinformationer som enterprise arkitektur gruppen kunne levere, hvis enterprise arkitektur programmet var implementeret korrekt. Planlægning og assistance på ledelsesniveauet i it-afdelingen ville understøtte udviklingen og modne fundament-arkitekturen.

Set i forhold til modtagerne eller det som kaldes for ”organizational segments” så er både niveauet på koncernniveauet og de forskellige domæner som ville kunne kategoriseres her.

Set i forhold til de tre faser omhandlende værdiskabelsen. Enterprise arkitekterne og chefarkitekterne er i stand til at kunne identificere applikationer og den mængde ressourcer der er investeret i dem på koncernniveau, men også forhold til de enkelte domæner. Dernæst er bliver det en nødvendighed at sikre at udvikle planer for optimering af enterprisens it-investering bliver en nødvendighed. Normalt vil der være tale om udvikling af roadmaps og kritikalitetsanalyser for hver af it-løsningerne. I caseorganisationens tilfælde ville det være tale om at udvikle planer for, hvordan de enkelte processer, applikationer og projekter kan kobles til hinanden med det formål at skabe mere værdi set i forhold til at kunne anvende de tilgængelige ressourcer bedre end på nuværende tidspunkt. Typisk vil det nok være at fokusere på at understøtte en service-orientering og sikre at de forskellige applikationer understøtter kontakt til service-bussen.

I forhold til fasen ”Improved Enterprise IT Investment Structure” vil enterprise arkitekterne være en del af de processer der skal forankres i caseorganisationen for at der vil være muligt for understøtte en bedre bedre it-arkitektur og samlet set en bedre enterprise arkitektur for caseorganisationen.

Viden om forholdene bliver alt sammen arkiveret i det EA værktøj og rammeværk som caseorganisationen anvender, og den specifikke viden ville kunne genbruges.