Applikationer kræver forvaltning for at udviklingen af applikationen kan foregå dynamisk og at vedligeholdelse af applikationen også foregår på en hensigtsmæssig måde. For at applikationen kan afvikles på en fornuftig måde skal der udtænkes en overordnet reference arkitektur  og heriblandt skal fremgangsmåde for applikationsarkitektur opstilles.

Forvaltning af applikationer afhænger den fremgangsmåde som organisationens it-afdeling har valgt til enterprisearkitektur. Det kræver også at organisationens beslutningstagere er villige til at “committe” sig selv til allokering af ressourcer til udarbejdelse af:

• Afholdelse af workshops.
• Udarbejdelse af roadmaps.
• Formulering af strategi for applikationen.
• Formulering af standarder.
• Dokumentation af eksisterende applikationsarkitektur.
• Scenarie og planlægning af hvordan applikationen udvikles til at leve op til den næste udgave.
• Et samlet bibliotek hvor det er muligt for de forskellige interessenter at tilgå informationer om applikationerne og løsninger.

Kirk Knoernschild arbejder med en tanke om at udvikling af applikationer kræver, at organisationens it-afdeling aktivt arbejder aktivt med at dokumenterer applikationens arkitektur. I den kontekst anvender Kirk Knonernschild en fremgangsmåde og en antagelse om at applikationens arkitektur skal dokumenteres på alle niveauer af “stakken”. Der er selv sagt problemstillinger ved en sådan fremgangsmåde til udarbejde af arkitektur artefakt frembringelse. Nedenfor kan du finde nogle af problemstillinger som jeg har identificeret.

Den første problemstilling omhandler at der skal allokeres ressourcer til at en eller flere applikations – og enterprisearkitekter skal dokumentere. Desto flere som dokumentere og sammensætter desto mere sandsynligt vil det blive at udviklingen af artefakterne skal koordineres mellem flere forskellige profiler og dermed vil tiden for at  udvikle artefakterne ofte forlænges.

Den anden problemstilling er at desto flere artefakter som frembringes desto flere ressourcer skal der bruges på at holde dem i live. Artefakter holdes i live ved at holde dem opdateret og ved at forankre dem i organisationen, hvilket kun gøres ved at kommunikere og interagere med en række interessenter.

Den sidste problemstilling som taler imod den fremgangsmåde som Kirk Knoernschild omtaler er at kun meget modne IT-organisationer reelt er indstillet på at investere ressourcer nok til at dokumentere arkitekturen.

Dynamisk udvikling kræver en dynamisk arkitektur

Organisationens omverden påvirker organisationen. Organisationen vil oftest få stillet krav til, hvordan organisationen skal være i stand til at kunne udveksle data med omverdenen, hvilket kræver at de rette integrationer udarbejdes. Der vil også opstå situationer, hvor omverdenen stiller krav til at udviklingen skal foregår hurtigst muligt, og typisk vil disse situationer kræve en “arkitektur light” eller slet ingen arkitektur anvendes.

Fokus for udviklingen af applikationsarkitekturen vil typisk foregå igennem projekter, hvortil det er nødvendigt at applikationsarkitekterne og enterprisearkitekterne arbejder sammen om at udarbejde løsningsdesigns for applikationen.

De udvalgte løsningsdesign skal fremadrettet også kunne bruges i den kontekst som organisationen operere, hvilket kræver en del arbejde fra både enterprisearkitekterne og applikationsarkitekterne i den forstand at de skal håndhæve en overordnet ramme for løsningsdesign som består af principper, løsninger og standarder samt integrationer.

Arkitekturen er central for forvaltning af applikationen, og dermed skal forvaltningen af applikationen også være dynamisk. Det stiller krav til de interessenter som indgår i organisationens anvendelse af applikationerne.

Dynamisk udvikling kræver en dynamisk forvaltning

For at forvalte applikationen så kræver det at der tages højde for at der udarbejdes planer og scenarier for applikationens udvikling. Den dynamiske forvaltning består af følgende aktiviteter ofte skal udarbejdes. Derudover skal viden deles og viden skal formidles til de forskellige beslutningstagere. Det vil sige at beslutningstagerne langt hen ad vejen bliver nød til at deltage aktivt møder og workshops omhandlende applikationerne og deres struktur samt de integrationer som applikationerne har til hinanden. Forvaltning kræver også at de beslutningstagere som findes  i forretningsenhederne aktivt indgår i beslutningsprocessen og tager ejerskab for de kravspecifikationer som udarbejdes.

Forvaltning kræver at der i samarbejde med enterprisearkitekterne formuleres en vision for, hvordan de forskellige interessenter skal gøre brug af applikationen og hvordan den på sigt kommer til at skabe værdi for interessenterne. Derfor skal der udarbejdes et roadmap for applikationen der kan identificere de planlagte projekter som skal til for at det nødvendige stadie opnås.

Forvaltning kræver også at der findes en styremekanisme for udvikling af applikationer og en styregruppe for udvikling af den specifikke applikation. Styregruppen skal i den forbindelse være bekendt med de arkitekturprincipper som applikationen skal overholde for at applikationen på sigt mindsker kompleksitet i applikationslandskabet og understøtter at ressourcerne som skal bruges fejlrettelse, vedligeholdelse, udvikling på applikationen i fremtiden ikke stiger. Styrgruppen skal også være i stand til at nedsætte et udvalg som gennemgår projektleverancerne for applikationen for at finde frem til om arkitekturprincipperne overholdes og sammen med udvalget for håndtering af projekter og enterprisearkitektur funktionen være med til at kunne forkaste leverancer som ikke lever op til arkitekturprincipperne og projekterne vel at mærke er klassificeret som værende underlagt arkitektur af udvalget for håndtering af projekter.

Arkitekturprincipperne, roadmaps, behovsafklaring hos interessenterne og strategier for applikationerne er i sig selv ikke nok til at defineres som en forvaltningsplan, men alle indgår i forvaltningsplanen. Forvaltningsplanen er det lag som binder arkitekturprincipperne, roadmaps, behovsafklaring og strategier for forvaltning af applikationen samt opgørelsen af den IT-gæld som oparbejdes for applikationen fra leverancerne som er underlagt arkitektur og de leverancer som ikke er. Forvaltningsplanen indeholder også klare referencer til en rammearkitektur for at designe og dokumenterer applikationen og den teknologiske platform som den afvikles på.

Konklusion

Applikationer kan forvaltes effektivt, hvis der er enighed mellem de forskellige interessenter og der arbejdsaktivt med at skabe et overblik over applikationerne. Værktøjer som skal anvendes er diagrammer, dokumenter og standarder. Opfølgning og evaluering på de leverancer som bliver udarbejdet og de artefakter som udarbejdes som led af projekterne.

Dokumentation af applikationerne kan kun finde sted i projekt-regi og når der er tid i forhold til ressourcer i organisationen. Der skal opstilles en reference-arkitektur for hvordan applikationerne skal struktureres og et udvalg for håndtering af projekter skal tage stilling til, hvilke projekter som skal underligges arkitektur, og hvilke projekter som kan betragtes som behov for udvikling uden arkitektur, altså det som ofte anskues som værende straks leverancer.