IT-arkitektur kræver forretning før teknik

Jeg havde en interessant diskussion i et møde forleden med en kunde og dennes leverandør. Det var en klassiker. Hvad skal der tages mest hensyn til: forretningen eller teknikken? Det enkle synspunkt, som er understøttet af enterprise arkitektur og alt muligt andet, er jo, at selvfølgelig kommer hensynet til forretningen i første række. Men så enkelt er det jo ikke.

I dette konkrete tilfælde foregår diskussionen i en workshop, som handlede om procesmodelleringen af en fremtidig vision i et område, som allerede er it-understøttet. Og så er der jo basis for en interessant diskussion. For her er teknikken – det eksisterende system – afgørende for omkostningen og mulighederne for at drømme ny forretning op. I hvert fald hvis man skal anvende dele af det gamle system til den nye proces.

Kunden har i dette tilfælde behov for at understøtte nye regler og muligheder i forretningsområdet, og vil gerne gøre arbejdet så fremsynet som muligt. Derfor har kunden taget udgangspunkt i at arbejde med de nye processer, som jo er den rigtigt gavnlige fremgangsmåde, når verden ændrer sig. Nye arbejdsgange til nye tider og regler, så man kan arbejde med at imødekomme udfordringer og høste gevinster. Men hvordan griber man arbejdet an, når det gamle system lurer i ens bevistheden med dets gamle måder at gøre tingene på og den åbentlyse omkostning ved at blive ændret på?

Diskussionen i mødet gik så på, om man kunne tillade sig at give frit løb i procesmodelleringen af et to-be scenarium, eller man skulle arbejde udfra den eksisterende proces. Det er jo meget reelt, at implementationen af en ny proces ovenpå et ældre system nødvendiggør, at man evaluerer de realistiske muligheder for at ændre på tingene – på et eller andet tidspunkt i processen.

Som fascilitatorer i processen talte jeg og min kollega Søren Philipsen for at tage et frisk syn på sagen, og ikke lade sig knægte af fortiden. Risikoen for ikke at definere en proces, som er fremsynet nok, er simpelthen for høj. Det nytter ikke noget – har man behov for nye arbejdsgange virker det simpelthen ikke at tage udgangspunkt i det eksisterende. Man skal først tillade sig selv at være kreativ og tænke nyt, for så derefter at have en proces, hvor ambitionerne bliver tilpasset virkeligheden.

Forretningshændelser kan bane vejen

Men det er også nemmere sagt end gjort. For arbejdgangene er jo meget kendte og dominerende i de involveredes hoveder. Så hvordan slipper man de gamle processers tag i opmærksomheden? I vores metodik anvender vi forretningshændelser som et middel til at træde et skridt tilbage og tænke nyt. Forretningshændelser er begivenheder eksternt til forretningen, som medfører en planlagt reaktion i forretningen. De er årsagen til, at man overhovedet laver meningsfuldt arbejde, f.eks. “en kunde bestiller en vare”, eller “en virksomhed melder tilbage”. Når de sker, kræves der noget af forretningen, nu skal vi handle: sende varen, behandle meldingen etc. Selvfølgelig kan det også være “tid til at gøre noget” i forretningen – altså en tidsmæssig hændelse, som for eksempel et spørgsmål der også kræver en planlagt reaktion – det kunne f.eks. være en tidsfrist, der bliver overskredet.

Det er dejligt overskueligt med en liste af hændelser også i forbindelse med en ny proces. Denne nye proces opstår som følge af en eller flere nye eller gamle hændelser, og man kan ikke undgå dem – de vil altid være der. Og de er der, uanset hvilken intern proces man definere for at klare jobbet. De omkranser processen og gør den overskuelig – sætter fokus på det, som processen skal klare. Så nu kan vi være kreative – nu kan vi drømme om den ideelle proces – fastholdt til virkelighedens hændelser. Når så den nye proces er defineret, kommer det modificerende arbejde – den tekniske workshop med afklaringerne af, hvor langt vi kan gå mod den ideelle proces.

Så svaret på, om det skal være teknik eller forretning der bestemmer, er faktisk en faseinddeling. Først det kreative forløb med forretningsmodellering, og så en tilretning til eventuelle tekniske begrænsninger – ikke begge dele på én gang! For så går der kludder i den menneskelige hjernes kreative evner – og vi begrænser os selv unødigt.

Finn Uldum is working as a combined chief technology and knowledge officer in Visma Consulting A/S. With a broad background from years of work in almost all roles within software development, he is also advising customers on architectural issues. Typically he is working very closely with our projects and customers, both setting a technological direction and capitalizing on the high knowledge levels of his colleagues.