Begræns buzz-words som SOA, EDA eller mash-ups i din it-arkitektur.
"Buzz-words driven architecture og architecture by magazine bliver et problem, fordi man ikke tager udgangspunkt i, hvor man er i dag, og hvad man reelt har brug for," siger senior manager Michael Strand hos Deloitte Business Consulting
Michael Strand er også kursusansvarlig for 'IT Arkitektur og Sikkerhed' på IT-Universitetets linje for IT-ledelse og strategi.
Han understreger, at man sagtens kan benytte sig af moderne arkitekturkoncepter som SOA, EDA og mash-ups, men det kan være, at det er vigtigere at renovere det kundesystem, der er lappet på i de sidste 10 år, frem for at kaste sig ud i implementering af SOA som det første.
Derudover nævner han en anden fare ved at bruge buzz-ordene.
"Man ender med ikke at være realistisk om egen organisations modenhed og kapacitet. Der bliver igangsat nogle meget omfattende SOA-moderniserings-projekter derude, og i nogle tilfælde kan man diskutere, om de pågældende virksomheder er klar til projekterne," siger Michael Strand.
Tænk målarkitektur
Michael Strand forklarer, at han ofte oplever, at når talen falder på en virksomheds it-arkitektur, forstås det som en fælles betegnelse for alle virksomhedens it-systemer.
Nogle firmaer udtrykker bekymring over, at omkostningerne stiger uforholdsmæssigt meget, som tiden går på grund af tilvækst af nye it-systemer med overlappende funktioner og det samtidig med, at de gamle it-systemer ikke forsvinder, forklarer Michael Strand.
"Men er det et problem med ens it-arkitektur? Eller er det i virkeligheden et problem, fordi man har det, der bliver kaldt, en 'tilfældig' it-arkitektur, eller en urskov?" spørger Michael Strand.
Han peger på, at it-arkitektur drejer sig om at have et mål, en 'målarkitektur'.
"Målarkitekturen er et grundrids for, hvordan man gerne vil have sin ideelle it-arkitektur til at se ud. Målarkitekturen kan understøtte, at virksomheden bliver forandringsparat, at it-omkostningerne kan styres, eller se hvad der nu er vigtigt for virksomheden" siger han.
Samtidig peger han på, at en målarkitektur ikke skal være statisk.
"Det kan være nødvendigt på et senere tidspunkt at skulle tilbage og opdatere den på grund af ændrede omstændigheder for virksomheden. Men det skal gøres med den største varsomhed, da det er ligesom at vende en supertanker med ofte store konsekvenser for de berørte it systemer," siger han.
Michael Strand advarer mod færdige løsninger udefra.
"Mange it-konsulenter vil gerne sælge færdigkogte målarkitekturer - men man kan spørge sig selv, hvem der ejer målarkitekturen, og i hvilket omfang den overhovedet passer til virksomheden," siger han.
Michael Strand forklarer, at det ofte ses, at virksomheder tager en færdigkogt it-arkitektur fra it-konsulenter og ændrer den lidt, men uden forståelse for konsekvenserne for dens fuldstændighed.
Svær implementering
Michael Strand mener, at det, der bestemmer om ens it-arkitektur bliver en succes eller en 'tilfældig' it-arkitektur er, i hvor høj grad man i dagligdagen i it-afdelingen og i de projekter, man sætter i gang, altid træffer valg, der leder mod målarkitekturen.
"For at sikre at dette sker, bør man indføre struktureret it-arkitektur-styring, det vil sige, at man skal sørge for at have it-arkitekter, der kan assistere og kontrollere, at alle arbejder hen mod målarkitekturen," siger han
I praksis betyder det typisk, at man skal:
1. Udarbejde it-arkitekturretningslinjer og guidelines til brug i projekter.
2. Sørge for at undervise alle i målarkitekturen.
3. Sørge for at it-arkitekterne har mulighed for at kontrollere, at målarkitekturen bliver fulgt i projekter og i det daglige arbejde. Det betyder ideelt, at it-arkitekterne har mulighed for at stoppe projekter, hvis de bryder målarkitekturen.
Michael Strand forklarer, at den største faldgrube er, hvis it-arkitekterne bliver set som en forhindring for succesfuld gennemførelse af projekter i virksomheden, fordi de er 'besværlige'.
Derfor skal it-arkitekterne vlre af den rigtige støbning. De skal kunne skabe gejst og være gode til at kommunikere med kollegaer i mange forskellige funktioner i virksomheden.
"Her er det vigtigt, at de forstår, at it-arkitekterne skal kunne sælge målarkitekturen, og at de reelt skal ville forsøge at hjælpe projekterne. Og i sidste ende kræver det, at it-ledelsen giver dem den nødvendige opbakning," siger han.
For at bakke målarkitekturen op skal ledelsen agere på en bestemt facon.
"Den kan sikre, at prioriteringen i virksomhedens projektportefølje tilgodeser projekter, der tager større skridt hen mod målarkitekturen frem for projekter, der tager mindre skridt," siger Michael Strand.
Han forklarer, at ledelsen også kan arbejde for at man med de projekter man prioriterer, sikrer, at gamle systemer reelt kan blive udfaset.
