Trin C4. Teknologiarkitektur
Formål
Trinet beskriver den nuværende og den fremtidige teknologiarkitektur.
Trinet fastlægger organisationens plan for brug af (strategiske) teknologier, på en måde der effektivt koordinerer udviklings-/vedligeholds-ressourcer og konsoliderer på nøgleteknologier.
Aktører
- Organisationens netværks-, system- og øvrige teknologifolk
Input
Til nuværende applikationsarkitektur:
Eksisterende dokumentation.
Interview med it nøglepersoner.
Til fremtidig applikationsarkitektur:
Nuværende arkitekturer indgår. Specielt C4. Teknologiarkitektur (nuværende) – skal være dokumenteret for at man meningsfyldt kan definere en fremtidig teknologiarkitektur og senere en migreringsplan fra nuværende til fremtidig (trin E2).
A6. It-principper
B2. Lokationer/organisation
C1. Informationsarkitektur, C2. Applikationsarkitektur, og C3. Servicearkitektur.
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:
- C4.1 Teknologi referencemodel, der helt generelt præsenterer de teknologier organisationen for nuværende bruger, og hvad man fremover ønsker at standardisere omkring.
- C4.2 ArkitekturByggeBlokke (ABB), der beskriver foretrukne konfigurationer – nu og fremover. En konfiguration kan være en database server, en filserver, en administrativ arbejdsstation (pc), kontorklient, mv.
- C4.3 Systemtopologier, 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.
- C4.4 Udvidede systemtopologier, 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.
- C4.5 Teknologikatalog, 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 selvfølgelig opdateres løbende.
Samlet set bør aktiviteten give en beskrivelse af organisations 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.
Metode
Nuværende arkitektur: at afdække den nuværende arkitektur er i høj grad et ”arkæologi-arbejde”. En EA arkitekt kan med fordel udvikle skabeloner til de dele af den nuværende arkitektur man vil afdække (jfr. Output-leverancerne). Disse udfyldes så af de af organisationens it-personer der har ansvar for de enkelte områder, ofte bistået af en leverandør. Det er vigtigt at bemærke følgende:
- Der er fire arkitekturområder: informations-, applikations-, service- og teknologiarkitektur, og dermed fire nuværende og fire fremtidige arkitekturer. Man dokumenterer dog ikke nødvendigvis alle, det er en del af tilpasningen af OIO EA metoden (trin A3) at definere hvilke der dokumenteres. Generelt:
- Hvis man designer den fremtidige arkitektur indenfor et af de fire område, skal man dokumentere den nuværende indenfor dette område.
- Hvis ikke man designer den fremtidige arkitektur indenfor et område, vil man ofte kunne spare at dokumentere den nuværende indenfor dette område, eller kun dokumentere den ret kortfattet. - Dokumentation af nuværende arkitektur kræver ikke meget erfarne arkitekter – udover en senior enterprise arkitekt til at skabe dokumentationsrammen og at overvåge og guide arbejdet, kan hovedparten af dataindsamlingen foretages af folk med noget mindre erfaring.
- Man kan med fordel dokumentere de nuværende arkitekturer i parallel. Ligeledes kan man indenfor en nuværende arkitektur definere de valgte output i parallel (én/flere dokumenterer applikationer, én dokumenterer integrationer, osv.). Høj grad af parallelitet fremmer at man hurtigere har grundlaget for at gå videre til designet af de fremtidige arkitekturer.
- EA arkitektens rolle i dokumentationen af den nuværende arkitektur er i høj grad at sikre konsistens og komplethed på tværs af områderne, og at rådgive om den ønskelige grad af detaljering der er krævet, for at sikre et godt fundament for den fremtidige arkitektur. De fleste organisationer har beskrevet dele af deres nuværende arkitektur, men i varierende grad af detaljering, komplethed og konsistens. Samtidig har mange organisationer svært ved at holde informationerne opdaterede. Der ligger en stor opgave for EA arkitekten i at sikre den indsamlede informations kvalitet, korrekthed og komplethed.
- Herudover har EA arkitekten opgaven med at sikre at organisationens medarbejde hjælper med at indsamle den information der indgår i dokumentationen af den nuværende. Dette er dog normalt ikke så vanskeligt, da området jo ikke er videre kontroversielt.
- Det kan være en relativt stor opgave at få dokumenteret den nuværende arkitektur. Til gengæld har en sådan oversigt en stor værdi, ikke blot for et EA projekt, men også for de teknologiprojekter der pågår i organisationen. Det er derfor en god ide allerede ved arbejdets begyndelse at have en plan for hvordan informationen vedligeholdes – af hvem, under brug af hvilke værktøjer, hvordan vedligeholdelsespligten forankres, osv. En del af dette hører under Y3. EA governance.
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 A6 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. 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 i B2 influerer på systemtopologien.
- Hvorvidt man ønsker at lave en central integrationsplatform (en middleware integrationsbrooker).
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.
Eksempler
C4.3 Systemtopologi
(Eksempel fra SKAT, ikke OIO EA kommunen)
Skabelon
Der er på nuværende tidspunkt ingen skabelon.
Relation til andre metoder
Links
Har du forslag til links - send dem via kontaktfunktionen.