C4 Teknologiarkitektur

Formål
Denne aktivitet beskriver den nuværende og den fremtidige teknologiarkitektur.

Input
Til nuværende applikationsarkitektur:

• Eksisterende dokumentation.
• Interview med it nøglepersoner.

Til fremtidig applikationsarkitektur:
Nuværende arkitekturer indgår. Specielt den nuværende teknologiarkitektur (C4) skal være dokumenteret, for at man meningsfyldt kan definere en fremtidig teknologiarkitektur og senere en migreringsplan fra nuværende til fremtidig (E2). Desuden indgår It-principper (A4), Lokationer/organisation (B2), samt i den udstrækning de forefindes Informationsarkitektur (C1), Applikationsarkitektur (c2), og Servicearkitektur (C3).

Output
Dette trin producerer to sæt OIO EA-produkter: Ét der beskriver den nuværende informationsarkitektur, og et 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:

• Teknologi referencemodel (C4.1), der helt generelt præsenterer de teknologier organisationen for nuværende bruger, og hvad man fremover ønsker at standardisere omkring.
• LøsningsByggeBlokke (C4.2), der beskriver foretrukne tekniske byggeblokke som organistionen anvender – nu og fremover. En konfiguration kan være en database server, en filserver, en administrativ arbejdsstation (pc), kontorklient, mv.
• Systemtopologier (C4.3), der generelt beskriver infrastrukturlandskabet for organisationen – hvordan de enkelte ABBer kædes sammen i netværk. Igen vil der være nuværende og fremtidige systemtopologier – eventuelt flere fremtidige, en om 2 år, en om 4 år, osv.
• Udvidede systemtopologier (C4.4 ), hvor også udvalgte applikationer er påførte, og flow af udvalgte informationsobjekter ligeledes vist. Disse bruges til at fokusere på tværgående funktioner, såsom sikkerhed eller system management, der kræver et samspil mellem applikationer, databasesystemer, netværksprotokoller, systemsoftware og hardware såsom servere, klienter og firewalls for at kunne virke.
• Teknologikatalog (C4.5), der er oversigten over de helt konkrete teknologier der anvendes – servere med deres konfigurationer af processorer, RAM, ROM, IP-adresser; software med præcise versionsnumre og licensaftaler, osv. Denne leverance vil typisk kun være relevant for det nuværende miljø, men skal selvfølgelig opdateres løbende.

Samlet set bør aktiviteten give en beskrivelse af organisationens plan for brug af teknologier og standarder indenfor hardware, operativsystemer, database management systemer, netværksteknologi, messaging, middleware, sikkerhed, privacy, drifts- og system management værktøjer, udviklingsmiljøer, mv. Dette kan både laves på EA niveau og tilsvarende beskrives specifikt for et løsningsprojekt.

Metode
Udover teknologiarkitekten og enterprisearkitekten er nøglepersoner i denne aktivitet organisationens netværks-, system- og øvrige teknologifolk.

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 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.

Teknologiarkitekturen skal naturligvis understøtte applikationerne, så det er vigtigt at se, hvilke krav den fremtidige applikations- og informationsarkitektur stiller til den underliggende infrastruktur. Applikationer med særlige krav til eksempelvis svartider og sikkerhed kan indskrænke teknologivalget. De it-principper der blev defineret i aktiviteten Principper (A3) vil også være nyttigt input.

I valg af teknologier bør man også skelne til en række andre forhold, såsom:

• Hvilke kompetencer der findes i organisationens it-afdeling(er), og hvilke man ønsker at udvikle.
• Eksisterende licensaftaler og andre forhold der påvirker prisen på teknologier, jf aktiviviteten Kontrakter og aftaler (Y5) . Herunder selvfølgelig ikke mindst om man ønsker at anvende open source-teknologier.
• Hvilke fremtidige teknologier man ser komme – eksempelvis større brug af mobile løsninger.
• Hvordan lokationsmodellen, jf aktiviteten Organisation (B2), influerer på systemtopologien.
• Hvorvidt man ønsker at lave en central integrationsplatform (en middleware integrationsbrooker / serviceplatform).

Teknologiarkitekturen giver ikke mindst værdi ved at sørge for at ensrette brugen af tværgående teknologier. Ofte ser man en organisation bruge eksempelvis database management systemer fra 3-4 forskellige leverandør – her vil en konsolidering ofte spare både i udvikling/vedligehold og i licenser. Teknologier der er specifikke for kun et enkelt, afgrænset forretningsområde er det måske næppe så vigtigt at få ind i arkitekturen.

Teknologiarkitekturen bør række 3-5 år frem, og der bør derfor planlægges en udfasning af gamle teknologier og introduktion af nye. Nogle teknologier er ”taktiske” – nyttige nu, men ikke om flere år. Andre er strategiske også fremover. Andre igen bliver strategiske, men vil først nå et modenhedsniveau om nogle år.
Teknologiarkitekturen bør omfatte gængse generelle teknologier, men også sektor-specifikke (såsom måleinstrumenter, køretøjer med it-udstyr, specialiseret kommunikation, osv.).

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.

Fremtidig arkitektur:
Som nævnt giver det god mening at lave en ”teknologi køreplan” for teknologiernes forventede levetid og strategiske betydning. Denne bør revideres mindst én gang årligt.

Cloud computing er en megatrend i disse år og har stor betydning for de strategetiske teknologibeslutninger. Læs mere om cloud computing i gruppen om cloud computing i Danmark på digitaliser.dk.

Se overblikket over de fællesoffentlige infrastrukturløsninger, hvor du kan se hvilke komponenter, services og standarder, der anvendes.