I Lakeside oplever vi i stigende grad at offentlige digitaliseringsprojekter efterspørger en målarkitektur. Behovet er specielt udbredt for digitaliseringsprojekter, der går på tværs af flere parter. Ofte lyder opgaven ”Projektet skal have udarbejdet en målarkitektur i henhold til den ”Fællesoffentlig Digital Arkitektur (FDA)”.
En målarkitektur beskriver de overordnede mål og principper for en IT-arkitektur. Når der refereres til FDA, så efterspørges en arkitektur, der i høj grad kommer omkring de forretningsorienterede emner (styring, strategi, jura og opgaver) og binder dette sammen med den traditionelle IT-vinkel på arkitektur (Information, applikation og infrastruktur).
Hvad skal min målarkitektur kunne?
I komplekse projekter, med mange integrationer og involverede parter, kan målarkitekturen, og ikke mindst processen, der fører til målarkitekturen, være en afgørende faktor for projektets succes. Målarkitekturen bliver et konsensusdokument blandt interessenterne, der validerer om der er enighed om målet og vejen dertil, samt om løsningen er realiserbar og dermed ikke strider mod eksisterende rammer. Eksempelvis i rammer udstukket af strategier, jura og eksisterende infrastruktur.
Offentlige organisationer er underlagt forskellige rammer i form af strategier, lovgivning, arkitektur-principper, reference-arkitekturer, domænemodeller og standarder. Projekter som går på tværs af to eller flere offentlige parter (fx på tværs af stat, region, kommune og private virksomheder), skal desuden tage hensyn til forskellige lokale rammer, da organisationerne arbejder under forskellig lovgivning og styring.
Hvor passer målarkitekturen ind?
På figuren nedenfor ses målarkitekturens placering og relation til andre dokumenter, der udarbejdes i forbindelse med et it-projekt.
Målarkitekturen placerer sig imellem projektgrundlaget- og løsningsarkitekturen. Den har fokus på de overordnede mål og principper for den løsning, der skal udarbejdes, og lægger rammerne for fastlæggelsen af løsningsarkitekturen. Løsningsarkitekturen beskriver det detaljerede design af den løsning, der skal udvikles.
Sådan gør du
Hos Lakeside har vi igennem en lang række projekter med afsæt hos den offentlige kunde høstet en del erfaringer omkring udarbejdelse af målbilleder. Der findes gode vejledninger til indholdet i en målarkitektur. I regi af ”Fællesoffentlig Digital Arkitektur (FDA)” er der udarbejdet vejledninger og kataloger over de arkitekturartefakter, som en målarkitektur kan indeholde. Dem bør du orientere dig i, men vores erfaring er, at du kommer længst med dem, hvis du har de her seks gode råd for øje:
- Læg snittet. Fastlæg afhængighederne mellem de øvrige arkitektur- og projektdokumenter (primært enterprice arkitektur, projektgrundlag og løsningsarkitektur).
- Hvilke ansvar har de øvrige dokumenter, som målarkitekturen derfor ikke skal gentage, men blot referere til.
- Hvilke hængsler eller overgange skal der være mellem dokumenterne. Eksempelvis er en vellykket opgave- og begrebsliste i målarkitekturen et rigtigt godt udgangspunkt for løsningsarkitekturen.
- Ha’ en plan. Design en proces, som involverer alle de vigtigste interessenter. Processen kan med fordel planlægges hen over en møderække, hvor deltagerne kan bidrage til arbejdet og herunder koordinere med og hente input fra den organisation de repræsenterer.
- Få mandatet. Få interessenternes godkendelse af den udarbejdede målarkitektur således, at der er et fast grundlag når løsningsarkitektur, krav og implementering gennemføres.
- Udfyld hele FDA-regnbue-spillepladen. kom omkring alle lag i modellen: Styring, strategi, jura, sikkerhed, opgaver, information, applikation og infrastruktur.
- Tegn og skriv så de forstår det. Når der skal vælges arkitekturartefakter til de enkelte lag, så vælg artefakter som projektdeltagerne har erfaringer med og forstår. Teknikker må ikke stå i vejen for, at alle kan være med og den gode dialog.
- Hold det konceptuelt. Udarbejd målarkitekturen på et konceptuelt niveau. Dyk kun ned på logisk niveau, hvor det er vigtigt for løsningen, eller hvis det er en mærkesag for en eller flere af de deltagende parter. For mange detaljer (på logisk og fysisk niveau) kan dræbe processen og resultere i en målarkitektur, som er uegnet til beslutningstagerne.