Denne aktivitet beskriver den nuværende og den fremtidige applikationsarkitektur. På EA niveau omfatter at optegne applikations- og integrationslandskaberne. På løsningsniveau omfatter det tilsvarende en modellering af de komponenter, der indgår i løsningen, herunder deres relation til processer, data og andre komponenter (integrationer). Dette er dette aktivitetsområde der foretages egentlig udvikling og tilpasning af software i løsningsprojekter.
Til nuværende applikationsarkitektur:
- Eksisterende dokumentation.
- Interview med it nøglepersoner.
Til fremtidig applikationsarkitektur:
Nuværende arkitekturer indgår. Specielt (nuværende) applikationsarkitektur skal være dokumenteret, for at man meningsfyldt kan definere en fremtidig applikationsarkitektur og senere en migreringsplan fra nuværende til fremtidig arkitektur. Dokumentation fra aktiviteterne Forretningsprocesser, Forretningsservices og Forretningsobjekter er meget centrale som input til denne aktivitet. Også It-principper, Lokationer/organisation, Forretningsregler og Use cases giver godt input. Dokumentation fra Informationsarkitektur og Servicearkitektur samt Teknologiarkitektur giver ligeledes god støtte, i det omfang den er udviklet. Specielt teknologiarkitektur vil ofte først foreligge senere, men kan give anledning til modifikation af navnlig applikationsarkitektur og servicearkitektur.
Desuden er applikationsudviklere vigtige bidragesydere til både den nuværende og især den fremtidige applikationsarkitetur, ikkemindst på designniveau.
Dette trin producerer to sæt OIO EA-produkter: ét der beskriver den nuværende applikationsarkitektur, og et der beskriver den fremtidige applikationsarkitektur (”as-is” og ”to-be”). For både den nuværende og fremtidige arkitektur kan OIO EA output produkterne omfatte:
- Applikationskatalog (C2.1), der giver en oversigt over funktionalitet, teknologi-platform, brugere, integrationer, mv. for de enkelte applikationer.
- Applikation-Information map (C2.2, der mapper C1.1-C2.1), der beskriver hvilke applikationer der bruger hvilke informationsobjekter fra C1 – gerne i en matrix, og gerne med angivelse af hvorvidt applikationen opretter, læser, skriver eller sletter informationen).
- Applikationsinfrastruktur mønstre (C2.3 ), der beskriver hvordan den enkelte applikations data-, funktions- og præsentationskomponenter fordeler sig.
- Applikation-Proces map (C2.4, der mapper B4.1-C2.1), hvor man prøver at få et overblik over hvilke applikationer der understøtter hvilke forretningsprocesser (fra B4), og eventuelt også hvor god denne understøttelse er.
- Integrationskatalog (C2.5), der giver en oversigt over funktionalitet, teknologi-platform, data flow, mv. for de enkelte integrationer.
- Integrationsstrategi og integration patterns (C2.6) beskriver tilgangen til integrationer. Dette omfatter den generelle strategi (for eksempel brug af integrationsbus) samt de konkrete patterns (mønstre) man har valgt til integrationerne (publish-subscribe, request-provide, osv.).
- Applikation-Integration views (C2.7, der kombinerer C2.1-C2.5-C1.1) beskriver applikationers integrationer, typisk som diagrammer med pile der viser data flow mellem applikationerne. Disse views kan med fordel gøres domænespecifikke, så der er ét per funktionelt område. Bemærk at et domæneview vil ofte være lig med et ”system” (hvor et ”system” er en samling applikationer der tilsammen hjælper brugerne med at løse sæt sammenhængende opgaver – sagsbehandling, personaleadministration, osv.).
- Applikationsdesign (C2.8) – design af en konkret applikation på et detailniveau, der specificerer funktionalitet og brugergrænseflade. Kan være en modellering eller egentlig eksekverbar kode.
Nuværende arkitektur:
At afdække den nuværende arkitektur er i høj grad et ”arkæologi-arbejde”. Det anbefales at læse den generelle artikel om dokumentation af den nuværende tekniske arkitektur.
Fremtidige arkitektur: Hvor kortlægning af den nuværende arkitektur er en dokumentationsopgave, er udvikling af den fremtidige en designopgave. Denne kræver en hel anden grad af detaljeret fagdybde, og involverer en lang række specialister indenfor de enkelte arkitekturområder, der hver især behersker metoder og teknikker indenfor området. Samtidig er området ofte meget følsomt, der kan være forskellige ”fløje” i organisationen der advokerer forskellige teknologier.
Formålet er at give et overblik over applikationslandskabet, og for de enkelte applikationer at beskrive deres funktioner, tekniske platform. Samtidig skal integrationerne imellem applikationerne identificeres, og de enkelte integrationers tekniske platform beskrives. Fra ”B4 Forretningsprocesser” har vi en indikation af de enkelte processers vigtighed, hvor meget it understøttelse man giver dem, og hvor godt det virker. Ved at mappe applikationer til processer får man nu et endnu bedre udgangspunkt for at vurdere hvilke applikationer der bør modificeres eller udskiftes.
Der kan være flere grunde til at modificere eller udskifte applikationer, herunder:
- Der er nye forretningsbehov der kræver ændret it-understøttelse.
- Standard-software pakker findes til erstatning for egenudviklede applikationer.
- Nogle applikationer kører på forældede platforme der ikke længere kan opgraderes.
- Fusioner, organisationsændringer og andet kræver applikationskonsolidering.
- Ændrede love og markedsvilkår kræver nye rapporteringsformer og nye tjenester, som skal implementeres af nye applikationer.
Ved at optegne de nye applikationer og også fra data distribution/data flow diagrammerne i C1 får man en god ide om integrationsstrukturen. Herefter må man – med udgangspunkt i kravene til den enkelte integration mht. datamængder, hyppighed, krav til sikkerhed, osv. – vælge den integrationsteknologi der giver bedst mening. Man kan overveje om man helt generelt ønsker at implementere en integrationsplatform, der reducerer antallet af integrationer og forhindrer ”N:N integrationer”. En integrationsstrategi kunne eksempelvis være ”publish-subscribe”, hvor en applikation der håndterer en forretningsbegivenhed (såsom at en patient er blevet indlagt, en borger har ansøgt om et eller andet) publicerer denne forretningsbegivenhed på en generel integrationsplatform. Andre applikationer der tager sig af denne type begivenheder, kan så abonnere på begivenheden.
Endelig bør man i arkitekturen tage højde for krav til interoperabilitet – mange applikationer passer i dag ikke ind i en integrationsplatform, og har i stedet behov for en løsere kobling til protokoller og dataformater. Det er hensigtsmæssigt at applikationsarkitekturen tager højde for at der i fremtiden (uvægerligt) vil komme nye protokoller og formater, som smidigt kan adopteres uden gennemgribende af kernen af applikationen.
Med hensyn til applikationsdesing og udvikling og programmering af eksekverbar kode henvises til de mange specialiserede kilder om dette. En indgang kan være wikipedias artikel om software programming.
Det giver værdi at have mange bidragsydere til at dokumentere den nuværende arkitektur, og komme relativt hurtigt i mål med oversigten over den nuværende arkitektur. Man bør også bestemme sig for hvem af de deltagende, der fortsætter med at udarbejde den fremtidige arkitektur.
Dokumentation af den nuværende applikationsarkitektur skal ikke være mere detaljeret end at det giver værdi. Det betyder fx at dokumentation af applikationsdesign kun skal laves, hvis det reelt skal anvendes fremadrettet. Ellers er det overordnede overblik typisk rigeligt.
Med hensyn til projekter der pågår er krav til dokumentation af applikationsdesign til gengæld relevant specielt i udviklingsprojekter, hvor kunden betaler for udvikling af koden. Og her er det en god idé, at tænke i retning af open souce og at stille krav til dokumentation af applikationsdesign og rettigheder til kildekoden.
Bliv enig om terminologien omkring ”applikation” og ”system” – hvad er hvad? Ofte vil man bruge termen ”system” om et kompleks af ”applikationer” indenfor et sammenhængende område. For eksempel en håndfuld applikationer der tilsammen håndterer tilskudsadministration og samlet benævnes ”tilskudsadministrationssystemet”.
Vær opmærksom på mulighederne for genbrug. Det kan være at der allerede er komponenter i organisationens it-porteføljem, der kan genbruges. Undersøg om der findes eller open source eller cloudbaserede løsninger, som kan anvendes fremadrettet. Det gælder ikke mindst fællesoffentlige it-services og komponenter.
Overvejer i en service, der fungerer på mobile enheder som smartphones og tabletter – så tjek Digitaliseringsstyrelsens guide til udvikling af mobile services.