Mange store organisationer oplever at det kan vise sig problematisk at placere ansvar for drift og udvikling af applikationer. I de fleste tilfælde vil it-afdelingen være den forretningsenhed som får ansvaret for at holde styr på organisationens it-drift og understøtte udviklingen som finder sted på de applikationer, som organisationen råder over. Jeg kan fristes til at tænke at det i bund og grund er en af årsagerne til at en organisation har en it-afdeling til at begynde med. Problemstillingen bliver at det for mange organisationers vedkommende kan vise sig problematisk at arbejde med forretningsudvikling uden at involverer ny udvikling eller tilpasning af eksisterende løsninger som oftest skal kunne integrere med de eksisterende applikationer og it-infrastruktur.

Blogindlægget behandler to former for arkitektur. Samtidsarkitekturen (As-Is) og fremtidsarkitekturen (to-be), og især hvad samtidsarkitekturen kan bruges i forhold til at kunne påvirke organisationen (især it-afdelingen) til at kunne udvikle sig i den i en retning som er gavnlig for forretningsudvikling i organisationen.

I store organisationer kan det tilmed vise sig at det er uklart hvad de enkelte applikationer bliver brugt til og i givet fald hvem som egentlig har ansvaret for at kunne godkende nyudvikling og tilpasninger i drift.

Eksempel 1

Et eksempel kan være at en applikation som anvendes i en proces som anvendes i forhold til organisationens evne til at yde kundeservice. Applikationen bruges i forhold til kommunikation mellem organisationens databaser og et front-end system som viser kundeservice medarbejderne en oversigt over, hvem kunden er og hvilke produkter som kunden har købt, om der er betalt for varerne. Brugerne har ligeledes mulighed for at indtaste kommentarer om det som de har aftalt med kunden.

Det har været et ønske lederen af kundeservice afdelingen at få applikationen integreret med organisationens eksisterende ERP-system så det vil være muligt at have så mange data som muligt samlet omkring nogle få applikationer som muligt. It-afdelingen ved at opgraderingen af applikationen vil have betydning for den proces som applikationen indgår i, og det vil have betydning for kundeserviceafdelingen, hvis det viser sig at det nyeste byg af applikationen ikke vil virker efter hensigten, da kundeserviceafdelingen i givet fald ikke vil være i stand til at kunne få oversigt over de transaktioner som kunderne har foretaget med virksomheden.

Eksempel 2

Et eksempel på it-infrastrukturen kunne være at marketingsafdelingen oplever lange svartider, når medarbejderne arbejder med en bestemt applikation eller i en bestemt proces. Til trods for at marketingsafdelingen er udstyret med relativt moderne bærbare computere (standard modellen som bruges i organisationen) virker de applikationer som anvendes langsomme, og det gælder især de applikationer som anvender de ressourcer som findes på organisationens servere. Det kunne vise sig at være tale om at it-infrastrukturen så som gamle servere, forældet netværk og middleware som har indflydelse på, hvordan slutbrugerne oplever applikationen.

Problemstillingerne fra de to eksempler

Eksemplet giver anledning til granskning af en række problemstillinger. Problemstillingerne drejer sig primært om at it-afdelingen som helhed kan risikerer at få tildelt skyld for at fejl der kan påvirke organisationens evne til kundeservice, hvilket kan medføre tab for organisationen i form af økonomi, tab af omdømme og tab af kunder.

Ansvar bør placeres

Det er nødvendigt at få placeret ansvar for hvem der har retten til at godkende ændringer som skal udarbejdes og implementeres i organisationen. Det er ligeledes vigtigt at arbejde for at de personer som har muligheden for at placere ansvaret forstår, hvad det er de skal træffe beslutninger om.

Ansvaret skal placeres for at undgå at de forskellige interessenter som indgår i beslutningsprocessen ikke er klar over, hvilket omfang forandringer reelt kan have for at organisationen kan gennemfører de processer og aktiviteter som den har designet. Samtidsarkitekturen kan bidrage til en it-styringsproces, hvor ansvar for styring af applikationerne og it-infrastrukturen.

Enterprisearkitektur

Begrebet enterprisearkitektur består af forskellige komponenter så som et rammeværk der henviser til hvilke typer informationer som kan vise sig at være relevante at have styr på for at kunne skabe ledelsesrapportering, metoder for at indsamle de rette informationer og en overordnet fremgangsmåde for, hvordan enterprisearkitektur funktionen kan bruges i forhold til at understøtte forretningsudvikling og dermed hjælpe organisationen med at anvende sine ressourcer til at skabe værdi på en mere intelligent måde som i sidste ende vil kunne understøtte, at organisationen kan opnå de målsætninger som beslutningstagerne har formuleret. Enterprisearkitekturen kan segmenteres i tre som omhandler forretningsarkitekturen, data – og informationsarkitekturen og den tekniske arkitektur. De tre arkitekturer bør i så vid en udstrækning det er muligt være afstemt med hinanden. Bernard (2005) arbejdermed en definition af enterprisearkitektur som kan opstilles på en formel EA = S + B + T. S står for strategy, B står for business og T står for technology. Wagter et al (2005) definerer enterprisearkitektur programmet som værende et værktøj som kan bruges til at understøtte udvikling i organisationen som vel at mærke er forudsigelig, hvortil offensiv og defensiv udvikling som vil påvirke organisationen på baggrund af hændelser som påvirker organisationen igennem sine omgivelser.

Samtidsarkitekturen

Det er vigtigt at få skabt et overblik over organisationens forretningsprocesser, applikationer og anvendelse af data og it-infrastruktur. Der er grænser for, hvad organisationens enterprisearkitektur program kan nå at dokumenterer og i hvilken detaljeringsgrad som vil vise sig nødvendig at anvende. Desto højere detaljeringsgrad desto mere vil det vise sig at enterprisearkitektur funktionen over en tidsperiode bliver ansvarlige for at holde opdateret og desto flere informationer kan vise sig at være forkerte.

Fremtidsarkitekturen

Det er vigtigt at få skabt et overblik for hvordan retningen for organisationens enterprisearkitektur bør være. Typisk vil der være tale om at enterprisearkitekterne engagerer beslutningstagerne i it-afdelingen sammen med chefarkitekten for at finde ud af, hvordan den foretrukne fremtid bør se ud for organisationen.

Fremtidsarkitekturen tager sit primære udgangspunkt i at identificere forretningsegenskaber (capabilities) som organisationen bør råde over inden for en tidsperiode. Dernæst bliver de forskellige forretningsegenskaber kombineret med mulige applikationer som understøtter dem. Dernæst bør det konceptuelle applikationslandskab udarbejdes og det konceptuelle it-infrastrukturlandskab samt det konceptuelle forretningsproceslandkort.

Fremtidsarkitekturen vil dog med stor sandsynlighed blive ændret over flere gange, da organisationen over tid vil opleve både defensiv og offensiv udvikling, hvortil enterprisearkitektur funktionen bør udvikle en reel proces for planlægning og engagering af de forskellige beslutningstagere for at holde fremtidsarkitekturen opdateret. Fremtidsarkitekturen bør lige som samtidsarkitekturen være tilgængelig for alle interesserede i organisationen.

Konklusion

Overblikket over samtidsarkitekturen vil typisk være katalysatoren for at sætte en forandringsproces i gang, hvis enterprisearkitekterne er i stand til at sætte gang i en proces med at delegere ansvar for tilpasning, udvikling og drift på applikationerne. Fremtidsarkitekturen er også vigtig, men på grund af forandringer i organisationens omverden (defensiv og offensiv udvikling) så vil fremtidsarkitekturen forandres og derfor bør enterprisearkitekterne og især chefarkitekten arbejde med få skabt en proces som kan være med til at holde samtidsarkitekturen vedlige.

Kilder

Bernard, Scott, A. An Introduction To Enterprise Architecture: Second Edition. 2nd ed. AuthorHouse, 2005.

Wagter, Roel, Martin van den Berg, Joost Luijpers, and Marlies van Steenbergen. Dynamic Enterprise Architecture: How to Make It Work. 1st ed. Wiley, 2005.