Det er lederne (mellemlederne) står for at eksekvere de initiativer og projekter som kommer fra it-styregrupperne. Dermed sagt så har it-styring ikke noget med eksekvering af gøre. Rob England (med alias IT Skeptic) pointerer i videoen nedenfor at guvernører (deltagerne i it-styregrupperne hvis man omsætter det til it-styring) omhandler at udstikke politikker og retninger for, hvordan organisationen skal udvikles.

Rob England kommer ind på forholdet mellem it-styring, succeser og fejl i citatet nedenfor og der findes problemstillinger set i forhold hvor de egentlige fejl findes.

”IT gets all the blame, as an organizational unit, for not aligning with the business, not understanding the business, not talking the right language, and a lot of that is remises we have as parents with teenagers. I can see an analogy there and you can’t put all the blame on the teenagers, just like the organization can put all the blame on the IT-department, it is a two-way thing, right. If the organization has failed to provide the proper guidance for IT over the years and has allowed IT to be ignorant of the broader strategies of the organization are and hasn’t imposed any discipline on IT, and slap them around a bit when they went of spending five million dollars on technology that nobody needed and so there is some blame on both sides for that.”

Rob England kommer ind på at der findes visse overordnede standarder, lovgivning og rammeværker nu pointere at det ikke kun er hos it-ledelsen at ansvaret for god it-ledelse kan placeres. Det er et ansvar som bestyrelsen i sidste ende har et medansvar for, hvormed det ikke kun kan være it-afdelingen som kan bebrejdes for de fejl som begås i organisationen.

“ISO 38500, Sarbon-Oxley Act [SOX], and COBIT 5 now are putting the message out that the ultimate accountability for IT is not in the IT-department. We can’t fire the CIO, we can, but I mean the accountability doesn’t stop with the CIO, the accountability rests with the board, and so if the IT-department is dysfunctional the ultimate blame for that is the overall organization, so the overall organization has to step up to its responsibilities, provide proper guidance to the IT-department to keep it a part of the organization, so that is what I mean about business failing IT as a bad parent.”

Der findes to forskellige tilgangsvinkler til it-service management ifølge Rob England. Den ene er den procesorienterede, hvor der findes en række standardiserede problemstillinger som kan løses med standardiserede løsninger. Den anden fremgangsmåde som Rob England omtaler og som han mener at mange organisationer kan lære noget af er det som kaldes for ”case-management”, hvor fokus er på problemstillinger som ikke er standardiserede og som kan ændre sig over tid. Rob England kommer ind på at det kan være en fremgangsmåde som it-afdelingen kan lære noget af set i forhold til at kunne håndtere de forespørgsler som brugerne kommer med.

“What I talked about is that a lot about thinking in service management is all based on predefined processes, so standardized models for how we do stuff, so if we get a request from a user and we go on looking on the library on how to do things we and sees it is a standard and we know how to do that, then there is a lot of guidance on how to do that stuff, align that stuff and measure and improve that stuff in the current service management thinking, but the reality is that half the stuff we get when it pops up we go ‘I don’t know how to do that, there is no standard process for me’. So, you know people talks about 40 or 60 per cent of their requests are being nonstandard requests where there is no immediately resolution for the incident. Our current body of knowledge, which is ITIL, is simply just a box saying ‘resolve it’.”

“In case-management each case is unique. You don’t know where you are going to end up. The goal can change and the goal can change through series of states. […] What options are we able to assemble like LEGO-blocks to execute on this action and try to get to another state and external stuff come in and you learn about something new […]”

Analyse

Set i lyset af at flere og flere organisationer har behov for at få styr på it-udviklingen for at understøtte en sammenhængende forretningsudvikling så viser det sig at it-styring (som også kaldes it-governance) bliver vigtigt at prioritere. Enterprisearkitektur funktionen vil typisk være til at finde i it-afdelingen (Doucet et al 2009), hvis organisationen vel at mærke investerer i sin enterprisearkitektur så vil det være muligt at kunne understøtte en bedre form for it-styring og som vil understøtte konkurrencefordele.

It-styringen kan ifølge Richard L. Routh opnå 20% højere profit. En ting som er vigtig i denne kontekst er at beslutningstagerne som indgår i it-styregruppen træffer de rette beslutninger.

Enterprisearkitektur funktionen kan i udgangspunktet understøtte udvikling som er forventelig (Wagter et al 2005) og i udgangspunktet kan den viden som enterprisearkitektur funktionen understøtte hurtigere forretningsudvikling.

De rette beslutninger opnås kun ved at beslutningstagerne har mulighed for at få fat i de rette typer informationer. De rette informationer kan skaffes igennem enterprisearkitektur funktionen, hvis den da vel at mærke er etableret, som organisationen råder over. Enterprisearkitektur funktionen kan betragtes som en leverandør af information til it-styregrupperne og på den facon kan it-styregruppen træffe beslutninger baseret på et informeret grundlag. Beslutninger truffet på et informeret grundlag kan lede til at organisationen opnår konkurrencefordele.

Konklusion

Chefarkitekten bør så vidt det er muligt arbejde på at få understøtte en it-styregruppe med det formål at kunne levere informeret ledelse til beslutningstagerne som indgår i den.

Enterprisearkitektur kan udvide mulighederne for at forudsige i enterprisearkitektur programmet, da det vil være muligt for enterprisearkitektur funktionen at få direkte relationer til beslutningstagerne som egentlig også er dem som vil træffe beslutninger om it-udvikling som skal finde sted i organisationen, hvilket kan understøtte færre situationer som er defensive eller offensive som kan sætte enterprisearkitektur programmet ude af kraft.