Et centralt emne i arbejdet med enterprisearkitektur er behandlingen af organisationens individuelle applikationsarkitekturer. Der findes et hav af store programmeringssprog som kan vise sig at blive anvendt i store organisationer. I dette blogindlæg bliver begrebet applikationsarkitektur behandlet med i udgangspunkt i bogen ”Java Application Architecture” af Kirk Knoernschild.

For at få en overordnet strategisk forvaltning af applikationer kan du læse blogindlægget her.

Begrebet arkitektur

Kirk Knoernschild ræsonnerer sig frem til at fordelene ved at anvende applikationsarkitektur i forhold til styring, forvaltning og udvikling af applikationer vil være at kunne håndtere kompleksiteten ved udvikling og sikre applikationen fremadrettet  i forhold til at kunne understøtte en dynamisk udvikling.

Dynamisk udvikling er en problemstilling set i forhold til arkitektur og it-projektledelse på grund af at der findes en række problemstillinger med at afsætte ressourcer i forhold til at håndtere behovet for planlægning og dokumentation set i forhold til behovet for udvikling og især ”quick fixes” som skal vægtes. Problemstillingen med arbejdet med applikationsarkitektur er at der altid vil være situationer som kræver at der skal ændres et eller andet ved applikationen. Fænomenet beskrives af van den Berg og van Steenbergen som værende offensiv og defensiv udvikling. De to fænomener vil ofte kræve at der arbejdes mindre med enterprisearkitektur og i den forbindelse mindre med applikationsarkitektur. Derfor handler det om at finde det rette leje for anvendelsen af enterprisearkitektur og dermed også det helt rette leje for applikationsarkitektur.

Kirk Knoernschild har en pointe ved at antage at de artefakter som produceres ved at applikationen dokumenteres. Kirk Knoernschild arbejder med en antagelse om at det er nødvendigt at dokumentere hele vejen igennem teknologistakken for at få mest ud den kommunikationsværdi som applikationsarkitekturens artefakter kan bringe med sig. Den fremgangsmåde kan vise sig at blive en problemstilling for dem som arbejder med applikationsarkitekturen og enterprisearkitektur programmet fordi forandringer vil kræve at ressourcer allokeres til udvikling frem for dokumentation af artefakter. Derfor vil en DYA fremgangsmåde i forhold til applikationsarkitektur.

Begrebet applikation

Applikationer består af en række klasser og ofte af en række forskellige eksekverbare filer som skal til for at applikationen virker rigtigt. En applikation er i denne kontekst typisk kompleks fordi den ikke alene består af klasser, eksekverbare filer og moduler, men også forskellige integrationer til andre applikationer og ikke mindst til databaser for at kunne håndtere data.

Objekt-orienterede sprog som Java og C# er begge bygget op om en tilgang, hvor de forskellige klasser opbygges så de understøtter udvikling som tager sit udgangspunkt at identificere objekter fra den virkelige verden og specificerer dem som mulige objekter fx igennem specialiserede klasser.

De mange klasser og integrationer kan gøre det uoverskueligt at arbejde med forvaltningen af applikationer, hvortil Kirk Knoernschild arbejder anbefaler at udviklingen centrerer sig omkring moduler.

Modul

Det er for kompliceret at holde styr på alle de klasser som udarbejdes og dokumenteres fx igennem UML-diagrammer. I stedet anbefaler Kirk Knoernschild at der anvendes en fremgangsmåde som tager sit udgangspunkt i moduler. Ifølge Knoernschild kan et modul bedst defineres som værende en JAR-fil.

Der findes herudover forskellige mønstrer (patterns) som udviklerne kan gøre brug af til udvikling af JAVA applikationer. Ifølge Knoernschild vil der være tale om de fleste udviklere automatisk arbejder med mønstre uden helt at tage aktivt stilling til det.

OSGi er et af de mønstrer som Kirk Knoernschild arbejder aktivt i bogen som værende et mønster som kan vise sig relevant at arbejde videre med for applikationer som er baseret på programmeringssproget Java.

N-lagsarkitektur

Applikationsarkitektur drejer sig om at planlægge udviklingen af udviklingen af applikationen på sigt. De fleste applikationer som findes i organisationernes applikationslandskaber er integreret enten igennem punkt til punkt integrationer eller en service-bus (ESB).

Herudover bør en applikation være struktureret omkring et præsentationslag (et modul for sig), et lag hvor de forskellige niveauer af forretningslogik er struktureret (et eller flere moduler) og i sidste ende et lag som består af håndtering af adgang til en eller flere databaser. Trods ovenstående er god skik og mange applikationer er bygget op omkring denne fremgangsmåde så er det typisk tale om at manglende applikationsarkitektur forvansker applikationens struktur og muligheden for, at få tilpasset applikationen til de behov som slutbrugerne har.

Konklusion

Der findes mange gode grunde til at arbejde aktivt med applikationsarkitektur. Den første grund er for at understøtte dynamik under kontrollerbare forhold. Den anden grund er at understøtte at videreudvikling og vedligeholdelse hurtigere kan gennemføres fordi applikationen er logisk struktureret. Hurtigere fejlfinding på grund af en velstruktureret applikation og hurtigere tilpasning til slutbrugernes behov er to gevinster ved at investerer i applikationsarkitektur og enterprisearkitektur generelt.

Kilder

Knoernschild, Kirk. Java Application Architecture Modularity Patterns with Examples Using OSGi. Upper Saddle River, NJ: Prentice Hall, 2012.