A6 Metodegrundlag

Formål
Formålet med denne aktivitet er at sikre, at den generelle OIO EA metode tillempes de behov, som den enkelte organisation / programmet / projektet har.
Det vil sige,

  • at der udvælges hvilke aktiviteter, der skal gennemføres og hvilken dokumentation, der skal tilvejebringes
  • at der udelades aktiviteter og dokumentation, der enten ikke er nødvendige, eller hvor der allerede findes arbejde, og
  • at valgte aktiviteter og dokumentationstyper modificeres eller suppleres, hvis det giver mere mening.

Input
Fokuser på dokumentationsinput fra tidligere iterationer af denne aktivitet og fra aktiviterne Udfordringer, Governance, Programmer og projekter og It-arkitekturgovernance.

Udover den tværoffentlige metoderamme OIO EA kan der være metoderelaterede krav og input fra subdomæner som staten (f.eks. Statens It-projektmodel), sektorområder, fx sundhedsdomænet eller fælleskommuale rammer.

Output
Outputtet er en beskrivelse af organisationens / projektets metodetilgang Dette omfatter:

  • En tilpasset OIO EA metode, der indpasser behovene til den enkelte organisations behov.
  • Valg af modelleringssprog og værktøjer der anvendes i projektets enkelte trin.

Dette beskrives kort og indarbejdes i projektgrundlaget.

Metode
Det er vigtigt at være opmærksom på at OIO EA metoden er en ramme, der altid tillempes det konkrete behov – ikke en opskrift der slavisk skal følges fra ende til anden. Det er vanskeligt at forklare hvordan tillempningen af OIO EA gøres; der kræves meget erfaring for at lave en tillempning, der optimerer udbyttet på minimal tid.

Man kan dog sige at nogle fornuftige trin at gennemgå vil være:

  • At få fastlagt omfang af EA arkitekturen på to leder:
    • horisontalt (skal hele OIO EA metodegennemløbet gennemløbes, eller kun udvalgte trin?).
    • vertikalt (skal EA udvikles for hele organisationen, eller kun for udvalgte forretningsenheder/forretningsprocesser?).
  • Konklusion på omfang: hvilket OIO EA aktiviteter er relevante i forløbet; hvilke ikke? Skal der andre aktiviteter med, der ikke er en del af OIO EA rammen?
  • For de relevante aktiviteter der vælges udført: hvilket beslægtet input eksisterer allerede, og i hvilket omfang kan dette genbruges?
  • Herudfra: For de enkelte aktiviteter der skal udføres: hvilke leverancer (dokumentationstyper) skal laves, udelades eller tilføjes?

Læs mere i introduktionen til OIO EA metoden, hvor du bl.a. kan få et crash couse i OIO EA trinene og vejledning i tilpasning eller tjek vores quickstarter.

Aktiviteten foregår i parallel med Programmer og projekter, hvor man laver projektgrundlag.

De anbefalede værktøjer anvendes ikke i denne aktivitet, men det er denne aktivitet, der skal udvælge dem. Typisk er det værktøjer til modellering og notation, til klassifikation og opmærkning samt til governance (tjeklister o.l).

Gode råd
Det er let at komme til at vælge for mange aktiviteter og for omfattende og dyb dokumentation. “Det nødvendige og det tilstrækkelige” og “det muliges kunst” er to gode mundheld, at tage i brug her.

Det er vigtigt at sætte et rimeligt ambitionsniveau – det giver ikke mening at gøre arkitekturen så detaljeret, at den nærmest er uaktuel, når man er færdig. Lav hellere en hurtig første iteration, og tilføj enten løbende nye elementer, når behovet viser sig, eller ved næste iteration.

En virkelig erfaren EA arkitekt er essentiel for at sikre, at man kun udfører de trin, der virkelig hjælper organisationen / programmet / projektet videre. Der er ofte store besparelser i mand-timer og kalendertid at hente ved at skræddersy metoden til de egentlige behov.

Leave a Comment