Formål
Denne aktivitet beskriver den nuværende og den fremtidige servicearkitektur.
Input
Til nuværende servicearkitektur:
- Eksisterende dokumentation.
- Interview med it nøglepersoner.
Til fremtidig servicearkitektur:
Nuværende arkitekturer indgår. Specielt nuværende servicearkitektur (C3.) bør være dokumenteret, for at man meningsfyldt kan definere en fremtidig servicearkitektur (C3) og senere en migreringsplan fra nuværende til fremtidig (E2).
Desuden indgår dokumentation fra aktiviterne It-principper (A3), Forretningsservices (B3) samt Informationsarkitektur (C1), Applikationsarkitektur (C2) og Teknologiarkitektur (C4), i det omfang denne foreligger. Specielt C4 vil ofte først foreligge senere, men kan give anledning til modifikation af navnlig C2-C3.
Output
På EA niveau producerer denne aktivitet to sæt EA-produkter: Ét der beskriver den nuværende informationsarkitektur, og ét der beskriver den fremtidige informationsarkitektur (”as-is” og ”to-be”). For både den nuværende og fremtidige arkitektur kan OIO EA output produkterne omfatte:
- Serviceoversigt (C3.1), der giver en oversigt over hvilke services der udbydes for nuværende, og skal udbydes fremover (typisk som webservices). Denne kan med fordel have to dele: 1) En teknologi-afhængig del, hvor der findes detaljer om hvordan servicen er/bør blive implementeret. Dette kan omfatte integrationsmønstre, samt de teknologi-afhængige dele af en SLA (service level agreement). 2) En teknologi-uafhængig del, hvor servicen beskrives ud fra hvad den gør. Dette kan også omfatte teknologi-uafhængige dele af en SLA (service level agreement).
- Komponentopdelt applikationslandskab (C3.2 ), hvor services der er implementeret flere steder, er trukket ud og planlagt så de kun implementeres ét sted. Igen kan der være en nuværende komponentopdeling, og en planlagt fremtidig. Komponentopdeling svarer i virkeligheden til kerneservices på samme måde som kernekomponenter i OIOXML verdenen – dvs. de services/komponenter der er mest centrale og genbrugelige. Dette landskab viser altså hvordan de services, der er identificeret i serviceoversigten bruges, og kan samtidig hjælpe til at identificere nye komponenter, der kan gøres til services.
- (Web)service-forretningsservice map (C3.3, der mapper B3.1-C3.1), der er en mapning af de ovenfor identificerede (web)services (nuværende og fremtidige) ind i de forretningsservices som B3 identificer. Herved får man beskrevet hvordan de forretningsmæssige services realiseres af tekniske services, og dermed et værktøj til at styre, hvordan man ændrer de forretningsmæssige services og hvilke forretningsmæssige services, der kan påvirkes af at skifte teknisk service-leverandør.
I et løsningsprojekt er opgaven for det første at orientere sig i de interne og relevante serviceoversigter for at sikre at relevante services bringes i anvendelse dels med henblik på at sikre relevant funktionalitet og data dels med henblik på effektiviswrende genbrug.
For det andet skal et løsningsprojekt selv overveje hvilke services der kan, bør eller skal stilles til rådighed for omverdenen internt og eksternt. Såfremt der er services der skal stilles til rådgighed skal disse beskrives og registreres i det/de relevante servicekatalog(er).
Alle myndigheder opfordres til at registrere services, der udstiller data til rådighed for offentligeheden, i Digitaliser.dk’s datakatalog.
Metode
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.
Brug gerne FORM til opmærkning når du skal skabe overblik over hvilke forvaltningsopgaver dine services dækker.
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 arkitektur-områ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.
Det er målet at “serviceorientere” de dele af arkitekturen, det er hensigtsmæssigt at serviceorientere (SOA). Med udgangspunkt i den applikationsstruktur der er beskrevet i aktiviteten Applikationsarkitektur (C2), går man nu så at sige ”ind i maven” på de enkelte applikationer. Man kigger på de services og komponenter, der benyttes og tilbydes, med udgangspunkt i en funktionel beskrivelse og med fokus på snitflader og beskrivelse af udvekslede data.
Leverancen bør identificere komponenter, der måske er implementeret flere gange, men med fordel kan trækkes ud som fælleskomponenter. Dette gøres ved at analysere hele applikationsporteføljen under ét. Dette er altså en komponentopdeling internt, af de enkelte applikationer. Det kan endda tænkes, at der allerede er defineret fællesoffentlige services. Hvor det er et krav skal disse selvfølgelig anvendes – f.eks. nemID, men i andre situationer bør man overveje mulighederne for at anvende setvices eller ompnenter udviklet i fælles regi. Klik her for at få et samlet overblik over de fællesoffentlige services og komponenenter – hver løsnng er dokumenteret i tekst og grafisk overblik.
Eksternt ser bør man overveje hvilke applikationer, som man med fordel kan ”service-enable” – altså hvilke services, som den enkelte myndighed eller institution bør stille til rådighed for resten af verden, typisk som web services. Her bør man læne sig op af kriterier og retningsliner fra OIO arbejdet.
Mere om SOA (introduktion) og integration med web services (mønstre og standarder).
Gode råd
Nuværende arkitektur: Det giver værdi at have mange bidragsydere til at dokumentere denne, 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.
Det bemærkes, at projekter, der pågår, også skal regnes ind under den nuværende EA.
Hvis organisationen ikke har ret meget service-orientering i dag giver det måske ikke mening at beskrive den nuværende arkitekturs service-orientering.
Fremtidig arkitektur: Serviceorientering – SOA mv. – handler i bund og grund om at gøre relevante services fælles, og implementere dem på en åben måde, under brug af internetteknologier som er tilgængelige for alle.
Når man vil stille services til rådighed eksternt bør man gøre det via et servicekatalog.
Man bør skelne mellem forretningslogik og services – hvor forretningslogik er lidt mere primitivt (atomart). Eksempelvis kan forretningslogik være at slå en faktura op, mens servicen er at godkende fakturaen.
Man bør også skelne mellem en service, sådan som den er implementeret, og så den web service, som man har aftalt med dem, der skal bruge servicen. Det sidste kan være gennem en SLA (Service Level Agreement), hvor man har et fast interface, der ikke ændres selvom man ændrer i selve servicen (altså at ny funktionalitet i en service ikke påvirker dem, der har baseret sig på aftalt funktionalitet; en versioneringspolitik).