Planlægning og styring
Forretningsarkitekten er en af mine nøgleroller. Først som medvirkende i planlægningen af projekter samme med projektledere og efterfølgende som deltager i diverse kontrolfora og styregrupper. Denne rolle er vigtig for at sikre faglig indsigt og forretningsmæssig forståelse.
Arkitekter og projektledere arbejder med fokus i forskellige dimensioner og derfor med forskellige mål. Men kan man få disse roller til at arbejde godt sammen, kan der opstå en stor synergi for projektet.
Coaching
Supervision og opgavedeling er yderligere et par aspekter af forretningsarkitektrollen: At være tilstede og dermed få sat fokus de rigtige steder, at få afstemt forventninger i hele projektgruppen, så alle er klædt godt på til at løse de opgaver der ligger, og at få skabt et forum for erfaringsopsamling.
Det kan let ske, projektdeltagere ikke er klædt godt nok på til at løse deres opgaver. Det er selvfølgelig vigtigt at undgå, og derfor skal opgaverne snakkes godt igennem, man skal være enige om hvem der laver hvad, og hvad man kan forvente af hinanden og af andre spor i projektet.
I løbet af et projekt vil der opstå mange problemer, der ikke umiddelbart løses af projektdeltagerne eller som løses af andre spor i projektet. Det er vigtigt at have forretningsmæssigt fokus på disse opgaver, og det er typisk en forretningsarkitekt der skal ind over for at få dem ordentlig adresseret, så projektlederne efterfølgende kan skabe et større og bedre overblik.
Arbejde med nye produkter
Arbejde på det strategiske niveau med design af nye produkter og videreførelse af dette arbejde til det operationelle niveau med planer for implementering af disse på eksisterende eller nye platforme.
Modeller, analyse og løsning
Det er ikke alting der er skrevet fra starten af større IT projekter. Forretningen vil typisk gerne have alle de gamle dyder med, men understøttet på en ny, fix og fremadrettet måde. Dette kræver ofte at man tager et skridt tilbage og får styr på de grundlæggende modeller, hvorefter løsninger på nye opgaver kan udarbejdes i holdbare rammer.
Kravspecificering
Kravspecificering, både på overordnet og detaljeret niveau. Dette kan være både til udbudsmaterialer og til deciderede IT oplæg.
Test...
... kommer man ikke uden om. En fornuftig udviklingsmodel kan selvfølgelig lette dette område betragteligt for forretningen, men det er stadig et monster. Use case baseret test er selvfølgelig godt, men det er vigtigt ikke at glemme de tekniske elementer, der gemmer sig i processerne. Dette kan løses ved også at huske funktionstest og unit test.
Konvertering
Konvertering er en svær øvelse. Først skal man vælge en overordnet strategi - Big Bang, større eller mindre gruppet. Hvis der er tale om en homogen portefølje er Big Bang tiltalende, da man slipper for at have flere forsikringssystemer kørende samtidig. Men det er ofte svært at få udviklet al funktionalitet samtidig, hvilket kan tvinge en til at forkaste denne løsning.
Efter fastlæggelse af den overordnede strategi skal man så til at arbejde med de meget lange garantier vi har i dansk livsforsikring. Nye systemer betyder nye måder at regne på, og der vil givet opså afvigelser mellem det gamle og det nye system. Dette skal selvfølgelig analyseres, og der skal findes løsninger der er acceptable for de forsikrede.
Der ud over er det essentielt at have håndtering af bogføring og Fall Back planer på plads, og der skal tages stilling til hvordan historik håndteres.
Generelt må det siges, at konvertering er et område man kun kan komme for sent i gang med. Ud over de store nævnte opgaver er det ofte her, man kommer i tanke om en del af de minoritetsfunktionaliteter, som man har glemt i de stillede krav.
