Koblingen mellem Enterprise Arkitektur og Business Intelligence

Transkript

1 Koblingen mellem Enterprise Arkitektur og Business Intelligence IT-Universitetet, E-business, forår 2007 Teknisk 4-ugersprojekt Udarbejdet af Anders Kann, Claus Borum Poulsen, Martin Albertsen

2 Tak til: Vi vil gerne takke en række personer, som har bidraget med input og ideer til opgaven. Først og fremmest vores vejleder John Gøtze, der er ekstern lektor ved IT-Universitet i København. Han har gennem sin undervisning i faget Enterprise Arkitektur givet os de første idéer til projektet og gennem sin vejledning været med til at pejle os ind på den endelige opgaveformulering. Stig Torngaard Hammeken og Kjell Wittmaak fra virksomheden Platon, som gav os god sparing og inspiration til Business Intelligence og Information Management-delen af opgaven. Christian Frank der har skrevet speciale inden for samme område og som har bidraget med gode råd og konstruktiv kritik.

3 Indholdsfortegnelse 1. Indledning Problemformulering Afgrænsning Metode Kildekritik Enterprise Arkitektur-modenhed Generelt om Enterprise-arkitektur EA modenhed Herzums modenhedsmodel Ross s modenhedsmodel Hvad er EA-modenhed? Delkonklusion Information Management-modenhed Business Intelligence Data management Information Management IM-modenhed Kimball readiness SAS White Paper om IM-modenhed Hvad er IM-modenhed? Delkonklusion Fælles referenceramme for EA og IM Delkonklusion Synergieffekter mellem EA og IM

4 6.1 Service orienteret arkitektur Master Data Management SOA møder MDM EA/IM modning og SOA-distribuerede masterdata Delkonklusion Konklusion Perspektivering Litteraturliste Bilag 1: Den oprindelige problemformulering:

5 1. Indledning Vi har gennem undervisningen på kurserne Enterprise Arkitektur (EA) og Business Intelligence (BI) bemærket, at der eksisterer en række overlap mellem disse to discipliner. Det står os dog ikke klart hvordan man placerer disciplinerne i forhold til hinanden, og hvad det er der eventuelt kan koble dem sammen. En simpel søgning på termerne i diverse artikeldatabaser såvel som på søgemaskinen Google afslører heller intet om hvordan og hvorvidt disciplinerne kan sammenkædes. Til grund for vores interesse for dette område ligger derfor en undren over, at vi ikke har kunnet finde videnskabelig litteratur om denne kobling. Forestil dig en hule forbundet til en verden udenfor via en lang gang, som er så lang, at dagslyset ikke kan trænge ind. Verdenen udenfor hedder Idéverdenen. Med ansigtet mod hulens bagerste væg, og med ryggen til indgangen, sidder en række fanger. Fangernes kroppe er lænket fast og de kan ikke bevæge hovedet. Derfor kan de hverken se på hinanden eller ned på sig selv. Kun væggen foran dem. Sådan har det været hele deres liv og de kender ikke til andet. I hulen bag fangerne er der tændt et stort bål og de ved ikke, at mellem dem selv og ilden er en mandshøj mur. Mennesker på den anden side af muren bærer ting frem og tilbage på deres hoved. Skyggerne heraf kastes på den væg som fangerne kigger på, mens stemmerne kastes tilbage. Dette er fænomenernes verden. Forestil dig, at de eneste ting fangerne overhovedet sanser og erkender i deres tilværelse, er disse skygger og ekkoer (fænomener) fra væggen. Derfor antager fangerne selvfølgelig, at disse skygger og ekkoer er virkelige, og deres tale om erkendelse referer til skyggerne og deres stemmer. Hvis nu en af fangerne kunne gøre sig fri af lænkerne, ville han være så forkrampet af fangenskabet, at blot det at vende sig ville være smertefuldt. Lyset fra bålet ville blænde hans øjne og han ville være så forvirret, at hans første ønske ville være at vende tilbage til væggen med skyggerne og sin egen forståelige virkelighed. Men efter en tid ville hans øjne se klart. Fangen ville nu se virkeligheden og forstå, at det han før så som virkelighed, kun var skygger af den egentlige virkelighed, altså fænomener. Her ville nogle mennesker stoppe og ikke gå videre af angst for hvad det der gør så ondt er, mens andre ville hige efter det ukendte, for at udforske det. Forestil dig at fangen blev trukket ud af hulen til dagslyset til Idéverdenen. Han ville være så blændet af lyset og forvildet, at der ville gå lang tid før han kunne se og forstå noget af den virkelighed han blev præsenteret for. Hvis han så senere vendte tilbage til hulen, ville han igen blændes. Denne 3

6 gang på grund af mørket. Og alt, hvad han her ville fortælle de andre fanger, ville være uforståeligt, fordi fangernes sprog kun referer til skyggerne og ekkoerne fra væggen. Fangen ville derfor sikkert helst blive i lyset og aldrig vende tilbage til mørket. Platons hulelignelse, beskrevet herover, er en måde at skitsere problemstillingen der ligger til grund for denne opgave. Den manglende litterære afdækning af koblingen mellem EA og BI kunne være udtryk for at folk der arbejder med henholdsvis EA og BI erkender ud fra forestillinger om hvordan omverdenen ser ud. Derfor mangler de indsigt i hvad der i virkeligheden befinder sig uden for deres huler. Enkelte, som kortvarigt har opholdt sig i idéernes verden, har måske forsøgt at videregive deres oplevelser og erkendelser, dog uden at blive forstået. Med udgangspunkt i disse metaforer kan man sige at vi med opgaven zoomer ud, så det nu er synligt at EA-hulen og BI-hulen ligger i samme dal, hvor der også er mange andre huler. Det er dog nødvendigt at studere dette nye billede nærmere for rigtigt at se sammenhængen. 1.1 Problemformulering 1 Både EA og BI er omfangsrige områder med mange grene og underdiscipliner. Derfor har vi med denne opgave valgt kun at fokusere på koblingen mellem EA og BI set i forhold til modenhed. Modenhed er et begreb der benyttes inden for begge discipliner, da man både i forhold til EA og BI taler om, at der er forskellige modenhedsfaser man skal igennem. På baggrund af disciplinernes omfang, har vi valgt at tilgå denne opgave som en forundersøgelse til videre analyse og diskussion af sammenhængen mellem EA og BI. Denne opgaves formål er således at undersøge om der eksisterer en fælles referenceramme for Enterprise Arkitektur og Business Intelligence i forhold til modenhed. Vi ønsker derfor at besvare følgende spørgsmål: 1. Hvilke ligheder er der i forhold til modenhed indenfor EA og BI? Herunder: 1.1 Hvad karakteriserer EA-modenhed? 1.2 Hvad karakteriserer BI-modenhed? 2. Er det hensigtsmæssigt at kombinere EA og BI i forhold til at øge graden af modenhed? 1 Problemformuleringen er en skærpelse af den oprindelige problemformulering godkendt i projektbasen. Se bilag 1 for den oprindelige problemformulering. 4

7 1.2 Afgrænsning Opgavens omfang tillader ikke at vi foretager en dybdegående undersøgelse af sammenhængen mellem EA og BI. Derfor har vi valgt at afgrænse os til modenhed, som vi synes er særlig interessant. Igen har vi her været nødt til at begrænse os til kun at kigge på udvalgte teorier om modenhed og modenhedsfaser, hvorfor vi kun har valgt teorier, som vi mener, er relevante for netop vores problemstilling. Vi er bevidste om, at en sammenligning mellem EA og BI måske bedre lader sig gøre inden for andre område end modenhed. Men vi ønsker med opgaven at lave en forundersøgelse og i denne sammenhæng fremstår modenhed for os som et fornuftigt udgangspunkt. 5

8 2. Metode Vores metodiske tilgang til opgavebesvarelsen er udelukkende af teoretisk art. Samtidig illustrerer opgavens tilblivelse og struktur en erkendelsesproces, hvor vi undervejs har opnået indsigt som har ændret vores syn på forskellige problemstillinger og afledt heraf ændret analyseobjektets kontur. Derfor har det også undervejs i processen været nødvendigt at inddrage ny litteratur og nye begreber, for at kunne anskue analyseobjekterne. Dette afspejles i den rækkefølgende afsnittene er placeret i opgaven. Opgaven er struktureret således at vi først foretager en analyse af hvad der er karakteristisk ved EAmodenhed. Hertil bruges litteratur fra Peter Herzum og Jeanne Ross samt deres modeller for EAmodenhed. Ud fra disse modeller, vil vi analysere os frem til hvad der kendetegner modenhed inden for EA. Dette besvarer problemformuleringens spørgsmål 1.1. Vi vil kun give en kort beskrivelse af hvad EA er, da vi tidligere har beskrevet dette emne i miniprojektet Enterprise Arkitektur i gymnasie-regi fra amts- til selveje. Derfor betragter vi EA og generel teori herom som kendt stof i forhold til forståelse af opgaven. Derefter foretager vi en beskrivelse og analyse af hvad Business Intelligence er og inddrager i denne forbindelse også begrebet Information Management (IM). Efterfølgende undersøges hvordan modenhed omtales i forbindelse hermed. Til dette bruger vi bogen The Data Warehouse Lifecycle Toolkit samt et white paper fra SAS omhandlende modenhed inden for Information Management. Dette munder ud i analyse af hvad der kendetegner modenhed inden for BI og IM, hvilket besvarer problemformuleringens spørgsmål 1.2. Herefter er vi i stand til at undersøge hvorvidt der eksisterer en fælles referenceramme for EA og IM med hensyn til modenhed. Her sammenstilles svarene på spørgsmål 1.1 og 1.2 hvorved vi er i stand til at besvare problemformuleringens spørgsmål 1. Problemformuleringens spørgsmål 2 besvares ved blandt andet at inddrage begreberne Service Orienteret Arkitektur (SOA) og Master Data Management (MDM), hvormed vi ønsker at analysere os frem til om det er hensigtsmæssigt at kombinere EA og BI i forhold til at øge graden af modenhed. 2.1 Kildekritik Vores søgninger efter litteratur til opgaven har vist at der i forhold til koblingen mellem EA- og BImodenhed ikke i udpræget grad eksisterer videnskabelig, objektiv og kritisk litteratur eller forsk- 6

9 ning. Der findes litteratur på området, men der er tale om properitære kilder og modeller, som er udarbejdet af virksomheder eller organisationer i salgsøjemed. Generelt gælder der også at den videnskabelige litteratur, hvis den overhovedet findes, er meget langt bagefter den praktisk funderede litteratur, da udviklingen inden for både EA og BI går stærkt. Derfor indrager vi i denne opgave både litteratur fra forsknings- og universitetsverdenen og litteratur der er skrevet af virksomheder eller organisationer og litteraturen inddrages på lige fod. Dette gør vi for at få et så tidsvarende billede af hvordan tingene ser ud som muligt. Vi anerkender dog, at den videnskabelige litteratur er mere uafhængig og kritisk, og at der kan være en tendens til at den praktisk funderede litteratur fremstiller problemstillingerne meget ensidigt og samtidig negligerer ulemper og risici. Det er derfor vores opfattelse at der generelt er mangel på akademisk forskning på området, som kan føre til en ufhængig og kritisk vudering af begreber, modeller og metoder. 7

10 3. Enterprise Arkitektur-modenhed I dette afsnit vil vi først kort beskrive EA. Derefter undersøger vi hvad der karakteriserer EAmodenhed. 3.1 Generelt om Enterprise-arkitektur Som vi tidligere har beskrevet i miniprojektet, Enterprise Arkitektur i gymnasie-regi fra amts til selveje 2, er formålet med Enterprise Arkitektur overordnet set at sørge for at IT-infrastrukturen i en given virksomhed eller organisation er sidestillet med forretningsstrategien på en sådan måde, at virksomhedens målsætninger tilgodeses og fremmes bedst muligt, samt at de økonomiske ressourcer der bruges på dette, udnyttes på den bedste måde. I denne forbindelse er EA en metode til at skabe harmoni mellem forretning og IT. Arbejdet med EA er en iterativ proces, hvor den typiske fremgangsmåde er først at indsamle oplysninger om og dokumentere den nuværende situation for virksomheden med hensyn til strategi, forretning og teknik/it. Dette skal give et billede af as-is. As-is er virksomhedens nuværende forretnings- og arkitekturmæssige situation. Dernæst udtænkes og beskrives den ønskede fremtidige situation som virksomheden ønsker at opnå, to-be. Herefter kan der laves en gap-analyse, som skal kortlægge hvor, hvad og hvordan der skal optimeres for at virksomheden kan opnå to-be-situationen, den ønskede arkitektur. Forandringen fra as-is til to-be skal blandt andet understøttes af principper og styring, som skal holde virksomheden på rette kurs i arkitekturprocessen. 3.2 EA modenhed I forhold til opgavens problemstilling, er det at tale om EA-modenhed relateret til, i hvilken grad en given virksomhed er i stand til at arbejde med EA. Modenhed er hyppigt omtalt af forfattere og teoretikere inden for EA og i mindre grad inden for BI. Til at undersøge hvad der karakteriserer EAmodenhed, har vi valgt at anskue to modenhedsmodeller, udarbejdet af forfatterne Peter Herzum og Jeanne Ross. I det følgende vil vi beskrive de valgte modeller med henblik på at kunne definere hvad der kendetegner EA-modenhed. 2 Kann,

11 3.2.1 Herzums modenhedsmodel Formålet med at arbejde med EA er ifølge Herzum ikke at have en veldokumenteret arkitektur i sig selv, men derimod at opnå IT- eller forretningsstrategiske mål. EA er desuden en uendelig proces, som kan skabe harmoni og ensretning mellem forretningsstrategi og IT-strategi 3. I artiklen Applying Enterprise Architecture, præsenterer Peter Herzum sin model for det han kalder typiske EAmodenhedsfaser. Figur 1 - Herzums modenhedsfaser (Kilde: Herzum, 2003) Som det fremgår af Figur 1, er Herzums modenhedsmodel inddelt i fem faser spændende fra Inception til Optimization. Faserne er yderpunkter i forhold til hvor moden en virksomhed er i sin anvendelse af IT så den understøtter forretningsstrategien. Ifølge Herzum svarer modenhedsfaserne direkte til en given virksomheds evne og formåen i forhold til at arbejde med forskellige aspekter af EA. Desuden fremhæver Herzum at modningsprocessen er sekventiel, idet det ikke er muligt at avancere mere end ét niveau ad gangen. Dog mener han det er muligt at fremskynde den proces det kræver at avancere fra én fase til den næste, dog uden at konkretisere hvordan dette lader sig gøre. I det følgende vil vi kort beskrive hvad de enkelte faser i Herzums modenhedsmodel indeholder. 3 Herzum, 2003, s. 30 9

12 Inception I denne fase er behovet for arbejde med EA ikke udtalt eller anerkendt. Virksomheden har en adhoc IT-strategi som kommer til udtryk ved at man i virksomheden har fokus på teknologi, som primært bruges til at løse helt specifikke problemer. Derfor er der heller ikke sammensat et egentligt team til at tænke i EA på tværs af hele virksomheden. Interoperabilitet adresseres via teknologi og Herzum nævner her eksempler på Enterprise Applikation Integration blandt andet hub-and-spoke arkitektur og enterprise bus 4, som ifølge Herzum ofte ikke lever op til virksomhedens forventning om at få løst problemer med interoperabilitet. Endelig budgetteres der i virksomheden ikke ud fra en samlet IT-strategi, men i forhold til mindre projekter. Arkitekturmæssigt mangler der derfor styring og støtte til at iværksætte større og tværgående EA-projekter. Classification I denne fase har man i virksomheden oprettet en egentligt EA-arbejdsgruppe som begynder at indsamle og dokumentere erfaringer og eksisterende processer i virksomheden. Arbejdet er af løs og tilfældig karakter, men man kan alligevel sige at behovet for EA er erkendt i denne fase. Arbejdsgruppens opgave er også at skabe synlige og kortsigtede resultater, som kan overbevise virksomheden om værdien der ligger i at tænke i EA. I denne fase begynder man oftest at udvikle en systemportefølje, som oftest er en simpel liste over tilgængelige systemer. Selvom koordineringen mellem IT og forretning er meget begrænset, er arbejdsgruppens arbejde i denne fase yderst vigtige skridt i retning mod at forene IT med forretningsstrategien. I Classification-fasen er virksomheden også på udkig efter arkitektur-rammeværker, som kan være styrende for dokumentationen af virksomhedens situation. De mest konkrete initiativer i forhold til arkitektur i denne fase er relateret til data warehousing og data mangagement, men disse initiativer har oftest ingen relation til det øvrige indledende arkitekturarbejde i virksomheden. I tråd med at EA-arbejdsgruppen skal levere kortsigtede resultater, har man i fasen også stadig fokus på at løse EA-opgaver med specifikke redskaber. Blueprinting I tredje fase udvikles reference-arkitektur, også kaldet blueprints. Blueprints dokumenterer såvel asis som to-be og er dermed et udtryk for hvad og hvordan der skal ændres/optimeres for at virksom- 4 Kommunikation og transformation af data og protokoller udskilles fra forretningsapplikationerne og varetages typisk af en ESB (Enterprise Services Bus) funktion. 10

13 heden opnår sin ønskede struktur og portfolio af IT-systemer. Blueprints kan således anvendes til at træffe strategiske beslutninger og fungerer i øvrigt som styrende for individuelle projekter. Det er typisk i denne fase at virksomheden begynder at udvikle fælles services og komponenter, men en bred anvendelse i hele virksomheden er endnu ikke opnået. I denne fase betragtes EA-arbejdet som et strategisk værktøj for virksomheden og EA-arbejdet er forankret højere i virksomheden. Desuden har man fastlagt sig på ét rammeværk som i stigende grad forankres i flere afdelinger af virksomheden. Der udvikles/besluttes standarder som efterfølgende understøtter individuelle projekter med ressource og økonomiske besparelser til følge. I denne fase modnes også arkitekturen i forhold til datahåndteringen, idet datas tilgængelighed ikke længere kun betragtes som et spørgsmål om teknologi, men som en vigtig faktor for interoperabilitet og udvikling. Der er desuden etableret styringsprocesser i virksomheden, som definerer hvordan og hvornår individuelle projekter kan bidrage til at udvikle målene med at tænke i EA. Integration I Integration-fasen har virksomheden opnået en velstruktureret EA, hvor afhængigheder mellem de enkelte IT-systemer i IT-porteføljen ud over at være dokumenteret, også forenkles og overskueliggøres. Styringsprocesserne for EA er i denne fase veludviklede og nye indkøb af IT og outsourcing af opgaver er tilpasset virksomhedens IT-strategi og ønskede fremtidige situation, to-be, beskrevet i rammeværket. I denne fase er der et skiftende fokus fra interoperabilitet til integration, det vil sige fra udveksling af data mellem systemer til informationsflow og udveksling af information. Dette skal minimere redundans i data og applikations-funktionalitet. Endelig bliver virksomhedens strategi for data warehousing og data management forenet med en egentlig strategi for service orienteret arkitektur 5. Optimization Optimization-fasen er den ideelle situation for en virksomhed at opnå. Herzum kalder den også for Nirvana. I denne fase er hele virksomhedens portefølje af IT-systemer indarbejdet i diverse ITstrategier. IT-porteføljen er selve enterprise arkitekturen, som virksomheden ønskede at opnå. Der er desuden udarbejdet planer for arkitekturen og de opstillede forretningsmål kan spores tilbage til de enkelte systemer. Der findes konkrete værktøjer til at understøtte og styre processerne som forener IT med forretningen. 5 Herzum, 2003, s

14 Om EA-arbejdet i forhold til modenhedsfaserne påpeger Herzum at en virksomhed som minimum må befinde sig i Blueprint-fasen, før den er i stand til på fordelagtig vis at forene forretningsstrategi med IT-strategi. Desuden er det først i Integration-fasen at virksomheden kan definere hvad den samlede strategi for forretning og IT er Ross s modenhedsmodel I artiklen Creating a Strategic IT Architecture Competency: Learning in Stages præsenterer Jeanne Ross sin model for arkitekturmodenhed. Figur 2 Ross modenhedsfaser (Kilde: Ross, 2003) Modellen består af fire faser som går fra Application Silo (Applikationssiloer) til Modular (moduler). Modellen viser både hvad der karakteriserer de enkelte faser samt ressourcefordelingen. I det følgende beskrives hvad de enkelte faser indeholder. Application silo architecture Virksomheder der befinder sig i den første modenhedsfase karakteriseres ved at anvende IT og indkøbe IT til at varetage specifikke og enkeltstående forretningsbehov. Der er ligeledes fokus på at besidde den nyeste teknologi og software, ligesom der ofte bruges mange ressourcer på at udvikle og vedligeholde egne applikationer. Desuden har hvert af de mange systemer sine egne data, hvilket afspejler at der aldrig eller sjældent er blevet tænkt i EA. Virksomheden opnår derfor en struktur 6 Herzum, 2003, s

15 karakteriseret ved applikationssiloer som er enkeltstående, dyre at vedligeholde og ikke interoperable. Denne lokale optimering er ressourcekrævende, besværlig og afspejler at der ikke tænkes i en fælles arkitektur. Standardized technology architecture I denne fase har virksomheden skiftet fokus fra at tænke i enkelte applikationer til i stedet at tænke i fælles infrastruktur. Som det vigtigste, har man i denne fase lagt sig fast på nogle standarder som skal begrænse omfanget af platforme/systemer som kræver drift og vedligeholdelse. Antallet af applikationer og redundans i data reduceres dog ikke blot ved teknologi-standardisering. Derfor har mange virksomheder i denne fase også introduceret en form for data warehouse til at dele data, men dataene er stadig forankret i hvert enkelt system/applikation. Ud over data warehouse er man i virksomheden generelt begyndt at arbejde med EA. Et typisk udgangspunkt for dette er et ønske om at opnå besparelser på drift og indkøb af IT. Rationalized data architecture Rationalisering af data refererer til at virksomheden i denne fase har fokus på de data som er vigtige og hvis kvalitet er kritisk for at virksomheden kan tjene sit formål og opfylde kundernes forventninger. Dette tilgodeser samtidig virksomhedens kernekompetencer og skaber stabilitet samtidig med at virksomhedens kerneprocesser optimeres. Værktøjet til at rationalisere er data management, som skal samle og forbedre kvaliteten af virksomhedens kernedata. I standardiseringsfasen var vigtige data forankret i hver enkel applikation. Med data management er målet at de enkelte applikationer skal tilgå dataene fra et centralt sted. Herfra sikres og optimeres dataenes kvalitet hvilket har stor indflydelse på kvaliteten af virksomhedens kerneprocesser. Desuden er virksomheden blevet i stand til at se hvilke strategiske fordele der kan drages af disse optimeringer og det at tænke i arkitektur. Modular architecture I den sidste fase er virksomhedens kerneprocesser blevet en del af infrastrukturen. Virksomhedens kerneprocesser tilgås via moduler. Kontrol med data og kerneprocesser er forankret højt oppe i virksomheden, hvilket gør virksomheden i stand til at agere hurtigt i forhold til nye krav, processer eller omverden. For eksempel kan en virksomhed på baggrund af sin arkitektur og datastruktur i denne fase, udvikle, genbruge eller blot vælge moduler som understøtter specifikke forretningsprocesser. En modulær struktur giver derfor mulighed for strategisk smidighed og handlekraftighed, samtidig med at denne arkitektur åbner op for lokal tilpasning ikke at forveksle med lokal optime- 13

16 ring, som kendetegner første fase. Den agile virksomhed er dermed det øverste modenhedstrin i Ross s modenhedsmodel Hvad er EA-modenhed? Den umiddelbare og synlige forskel på de to modenhedsmodeller er, at hvor Herzums modenhedsmodel er inddelt i fem faser, har Ross s kun fire faser. Derudover tager Ross i højere grad udgangspunkt i at skitsere ressourcefordelingen på tværs af arkitekturmodenheden, hvor Herzums model i adresserer specifikke processer i modningsprocessen. Ud fra beskrivelsen af de to modeller, mener vi at kunne sammenfatte en karakteristik af EAmodenhed med nedenstående figur. Figur 3 EA-modenhed (Egen fremstilling) Vi har valgt at betragte EA-modenhed som en trinvis proces med fire faser. Det er ikke muligt at springe faser over i modningsprocessen. Navnet på Herzums første fase, Inception, tyder på, at han betragter modenhed som en proces der begynder allerede ved en virksomheds opstartstidspunkt. Ross derimod, har valgt application silo architecture, som navn til den første fase. Dette antyder at hun mener det kræver en vis størrelse og udvikling før det er relevant at tale om modenhed i forhold til arkitektur inden for såvel applikationer, infrastruktur og data. EA-modenhed anskues altså i forhold til såvel en nystartet virksomhed som en virksomhed med år på bagen. 14

17 I den første fase har virksomheden fokus på teknologi og lokal optimering af mange forskellige applikationer. Man har en ad-hoc strategi i forhold til anskaffelse af ny IT og teknologi, hvilket giver dårlig eller slet ingen interoperabilitet mellem systemer og applikationer. For at virksomheden kan øge sin modenhed i denne fase, er det nødvendigt at man internt erkender behovet for at tænke i infrastruktur og arkitektur. I anden fase har man i virksomheden etableret en egentlig EA-arbejdsgruppe, som samler indledende tanker og initiativer til EA-arbejde. Arbejdsgruppen begynder typisk at dokumentere processer og porteføljen af IT-systemer i virksomheden, med henblik på efterfølgende at vedtage standarder for såvel indkøb som anvendelse af IT. Vi har her valgt at betragte Herzums Classification og Blueprinting-faser under ét, da disse to faser primært dækker over hvad EA-arbejdsgruppen foretager sig. Der tænkes her især på dokumentation af as-is og to-be (blueprints), samt at skabe overblik over IT-porteføljen og sammenhænge og afhængigheder mellem systemer og applikationer. Et konkret initiativ i denne fase er starten på at opbygge et data warehouse til at dele data på tværs af virksomheden. Virksomhedens modenhed øges i denne fase i takt med at standardisering skaber fundamentet for en bedre infrastruktur. For det andet øges modenheden i takt med at EA i stigende grad betragtes som et strategisk værktøj blandt ledende personer i virksomheden. For det tredje kan virksomheden øge sin modenhed ved at tænke i udveksling af information frem for data. Med andre ord må virksomheden begynde at tænke i interoperabilitet mellem systemer. I tredje fase har virksomheden fokus på at rationalisere sine kerneprocesser samt den information der er kritisk for at understøtte disse processer. I denne fase er der et skiftende fokus fra udveksling af data (interoperabilitet) mellem systemer til informationsflow og standardisering af services. Kerneprocesserne standardiseres og tilpasses så de bedst understøtter virksomhedens IT-strategi. Desuden anvendes data management til at forbedre datastrukturer for de data som understøtter virksomhedens kerneprocesser. I denne fase begynder virksomhedens strategi for data warehousing og data management at smelte sammen med en egentlig strategi for modulær arkitektur. Modenheden øges i takt med at datastrukturen optimeres så den på enkel vis kan struktureres til information. Desuden tilpasses IT-porteføljen, så den svarer til virksomhedens IT-strategi. I den fjerde og sidste fase gennemgår arkitekturen en udvikling fra at være centraliseret og interoperabel, til at være integreret. I den integrerede arkitektur er IT-systemerne integreret med hinanden og bruger fælles funktionalitet. Information, frem for rå data, er målet og det kræver at systemer kan tilgå hinandens data igennem standardiserede moduler eller services. I denne arkitektur er syste- 15

18 merne rationaliserede således at funktionalitet udgår fra én og kun én proces. Jo længere en virksomhed kommer i denne modningsfase, jo mere agil bliver den. Agilitet skal i denne sammenhæng forstås som det at IT i højere grad understøtter virksomhedens evne til at omstille sig i takt med forretningen. Agilitet foranlediges blandt andet af at virksomheden kan genbruge, udvikle og udskifte services og moduler hurtigt og ubesværet uden at det påvirker andre processer eller moduler. Med andre ord har virksomheden nu opnået en høj tilpasningsevne hvilket tillader hurtig reaktion på ændrede forretningsstrategier eller krav fra omverdenen. 3.3 Delkonklusion Modenhed er ikke en forudsætning for at arbejde med arkitektur, men arkitekturarbejdet vil have forskelligt fokus alt efter hvilken grad af modenhed der karakteriserer virksomhedens ITanvendelse. Modenhedsfaser inden for EA er udtryk for i hvilken grad en given virksomhed er i stand til at arbejde med de forskellige aspekter af EA. Derfor kan arkitekturarbejdet være værdifuldt selv for en virksomhed som har en lav grad af modenhed, ligesom arkitekturarbejdet kan øge modenhedsgraden, hvis virksomheder er opmærksomme på hvad der kræves for at avancere. Modningsprocessen er sekventiel, så det er ikke muligt at avancere mere end ét niveau ad gangen. Arkitekturmodenhed og IT s strategiske indflydelse øges i takt med at virksomheden har større fokus på data og infrastruktur og samtidig mindre fokus på specifikke applikationer. Målet med modenhed er at skabe sammenhæng mellem IT- og forretningsstrategi, ved at integrere IT-systemer gennem moduler og services. Dette er grundlaget for at virksomheden kan blive agil og omstillingsparat i forhold til såvel interne som eksterne faktorer. Vi har nu ved hjælp af figur 3 skabt overblik over hvad der karakteriserer modenhed inden for EA. Med andre ord har vi kortvarigt været nede i hulen, hvor man erkender ud fra forestillinger om hvad der er EA. 16

19 4. Information Management-modenhed I dette afsnit vil vi først undersøge hvad BI er og hvordan det fungerer i praksis. Derefter inddrager vi begrebet Information Management, for til sidst at undersøge hvad der karakteriserer modenhed inden for IM. 4.1 Business Intelligence BI er en samlet betegnelse for applikationer og teknologier som tilsammen skal foranledige indsamling af data, samt give mulighed for at lave analyser og rapportering af data og information om virksomhedens performance såvel som mange andre områder. Ved hjælp af BI kan der udtrækkes data fra mange forskellige kilder som for eksempel CRMsystemer. Det bliver herved muligt at centralisere, organisere og standardisere sine data i et såkaldt Data Warehouse. I denne proces er der også mulighed for at rense sammenkøre og tilføje yderligere data. BI giver derudover ved hjælp af analytiske værktøjer adgang til at foretage forretnings eller tekniske forespørgsler på data, så eventuelle mønstre kan findes eller problemområder kan diagnosticeres. BI skal derfor ses som løsninger, der bringer den opnåede gennemsigtighed i information ud til beslutningstagerne. Figuren herunder illustrerer en typisk data warehouse-arkitektur, som beskrives nærmere i det følgende. Figur 4 Data Warehouse Arkitektur (Kilde: Platon, 2007b) 17

20 Operationelle systemer Yderst til venstre finders de operationelle systemer (CRM, SCM, ERP mv.), som indeholder for eksempel salgsoplysninger, kundedata mv. De operationelle systemer er typisk designet til at betjene mange og forskellige brugere samtidigt. Men de er ikke konstrueret til at rumme mange års indtastede (historiske) data. Det fjerner ydelse og øger svartiden fra systemet, hvor det i mange tilfælde i driftmæssig sammenhæng ville have været tilstrækkeligt med blot at gemme historikken for én enkelt dag, en uge eller en måned. De operationelle systemer er desuden kendetegnet ved, at de typisk er tilpasset til den daglige forretningsgang. Derfor kan det være vanskeligt at søge efter data i de operationelle systemer, fordi de med tiden er blevet tilpasset ændrede forhold. Udgåede varenumre er måske ikke længere repræsenterede i de operationelle systemer, hvorimod data med de oprindelige varenumre stadig ligger gemt i systemet. Data Warehouse og Data Marts I midten findes selve data warehouse et (DW). Med etableringen af et DW integreres datakilderne og data konsolideres. Samtidig har DW et en række værktøjer indbygget til sortering og udtræk. Disse kaldes ETL-processer 7, hvormed data kan udtrækkes (extract) fra de operationelle systemer eller det sted de opbevares. Herefter kan de ændres og opdateres (transform). Datastrukturen og arkitekturen for DW et lægger op til fælles standarder for dataene. Disse fælles retningslinjer medfører at man ikke alene får samlet al data på et og samme sted, men også i et fælles format med relationer og nøgler der kæder dataene fra de forskellige systemer sammen. Til sidst kan dataene indlæses (load) i DW et. I et DW eller i de enkelte datamarter opbevares taktisk eller historisk data i en relationel database. Herved får brugerne mulighed for at udtrække og sammensætte specifikke dataelementer fra et komplet datasæt, som der efterfølgende kan analyseres på. I datamarterne foretages ved hjælp af ETL-processer en yderligere segmentering af de data der findes i et DW er, så de tilpasses specifikke applikationer og forespørgsler. Forespørgsler, rapportering og analyse Yderst til højre på figuren herover findes rapporterings- og analyseværktøjerne. For at lave forespørgsler, rapportering og analyse på de data der opbevares i DW et og de forskellige Data Marter, benyttes forskellige værktøjer. 7 Extract, Transform, Load. Processerne gennemføres oftest med SQL. 18

21 Forespørgsel - og rapporteringsværktøjer giver brugerne mulighed for at foretage slice-and-dice - analyser på data fra DW et. Denne type analyse besvarer typisk spørgsmål af hvad og hvornårtypen. Multidimensional On-line Analytical Processing (MOLAP) og Data Mining 8 giver brugerne mulighed for at foretage blandt andet multi-dimensionelle analyser. OLAP-delen vil sige at man arbejder online med data fra DW et, i stedet for at kigge på en statisk rapport. Med online menes altså, at man har mulighed for dynamisk at vælge kriterier for filtrering, opsummering og præsentation. MOLAP og Data Mining kan som analysemetoder også bruges til at lave forudsigelser, kundeprofiler, indikere trends og lignende. Her besvares oftest spørgsmål af typen hvad hvis og hvorfor. Tilgang til information Resultatet af forespørgsler, rapportering og analyser kan for eksempel tilgås gennem dedikerede desktop-applikationer, dashboards eller intranet/extranet. Ud over at bruge informationen som envejs-information, for eksempel som en indikator på hvordan virksomheden har performet, kan informationen også aktivt indgå i de operationelle systemer. Data fra DW et eller datamarterne kan føde tilbage til for eksempel CRM-systemer, og give brugbar information til de medarbejdere der anvender disse systemer. Vi har nu beskrevet hvordan den tekniske arkitektur typisk ser ud for et DW. Men anvendelse og implementering af en sådan arkitektur kan ikke løses alene gennem teknologi. Virksomheder står i dag i en situation hvor adgang til pålidelig nær-realtime information er af stor betydning. Derfor er det nødvendig også at anskue DM i forbindelse med udvikling af et BI-projekt. 4.2 Data management Hvor BI omhandler strukturering af data og metadata til information, beskæftiger DM sig med selve dataarkitekturen og organisationens stillingtagen til data som et strategisk aktiv. Dermed ikke sagt at DM og BI er to vidt forskellige ting. Elementer fra BI er en del af DM og omvendt. DM opererer på et højere abstraktionsniveau, og ikke udelukkende inden for det tekniske område. DM omhandler blandt andet fælles definitioner af dataobjekter og formater for denne information, kaldet meta-data. DM bruges altså til at adressere den overordnede dataarkitektur for organisationen, herunder DW- 8 Kimball, 1998, s

22 arkitektur. DM er også vedligeholdelse af data, Data Quality Assurance 9 (DQA), Master Data Management (MDM) og konformitet. Med DM kan en virksomhed altså træffe organisatoriske beslutninger omkring data der indgår som et strategisk aktiv. Som det ses i afsnittet omkring DW, foregår der nogle helt grundlæggende processer omkring ETL og filtrering af data i DW et. Disse processer bygger i høj grad på det forarbejde der er gjort i forbindelse med MDM. MDM er en generel betegnelse for hvordan virksomheden forholder sig til kildedata i for eksempel de opperationelle systemer. MDM kommer vi ind på senere. DM og BI har derfor primært overlap når det kommer til DW et og i forhold til MDM. Dette fremgår af figur 5 herunder, hvormed vi ønsker at vise sammenhængen mellem BI og DM. Information Management Business Intelligence Performance Management ETL Reporting and Analysis Data Warehousing Master Data Management Meta Data Management Data Management Master Data Management Data Quality Assurance Data Architecture Figur 5 Information Management (Kilde: Platon, 2007a + egen tilvirkning) 4.3 Information Management Information Management (IM) er den overordnede betegnelse for det at behandle information som et aktiv. Dette kræver, som vi tidligere har nævnt, god dataarkitektur og at relevant og konsistent information er tilgængelig i alle forretningsprocesser. Herved bliver det muligt at optimere udnyttelsen af information til at tage beslutninger ud fra. IM består således både af BI og DM som igen har en fællesmængde hvor MDM og datakvalitet indgår. Det som IM og herunder BI og DM tilby- 9 Kimball, 1998, s

23 der, er således at forholde sig strategisk til data som et aktiv, strukturere den til information og derefter udtrække viden af denne information. Denne værdikæde kan illustreres på følgende måde: Data => Information => Viden Data giver mulighed for at gemme oplysninger om hændelser, information giver mulighed for at reagere på hændelser og viden giver mulighed for at påvirke hændelser 10. IM skal være drevet af forrretningen, og initiativer inden for BI og DM bør afspejle dette. Når tekniske projekter skal søsættes i en organisation, og opbakning skal sikres, er det altså vigtigt at der ses åbenlyse fordele for forretningen. I takt med at opmærksomheden på at agere intelligent på de stigende mængder data der indsamles i virksomheden, vinder BI og IM i det hele taget større og større indhug. I vores undersøgelse af hvad BI er, har vi nu fundet ud af at BI ikke kan stå alene når vi i det følgende vil undersøge modenhed. Dette skyldes at informationshåndtering spiller en større og større rolle i takt med at datamængderne øges. Derfor må vi udvide vores undersøgelse af hvad der kendetegner BI-modenhed til at omfatte IM, som indeholder både BI og DM. Derfor anvender vi i det følgende begrebet IM-modenhed til at kigge på hvad der kendetegner modenhed inden for såvel BI som DM. Hvis vi her refererer til hulelignelsen, har det vist sig at det vi troede var en BIhule i virkeligheden en IM-hule indeholdende både BI og DM. 4.4 IM-modenhed Udvikling og implementering af IM, som vi har beskrevet i forrige afsnit, er en iterativ proces. Ligesom med EA må en IM-løsning udvikles og implementeres trinvist, evalueres og tilpasses, så det tilfredsstiller og understøtter de ønskede processer og forretningsbehov. Om data warehousing siger Ralph Kimball desuden at: Data warehousing is all about providing improved access to better information to support decision making. 11 Forbedret adgang til bedre information er netop hvad IM omhandler ifølge de kilder vi har anvendt. Peter Herzum nævner BI i sin artikel, Applying Enterprise Architecture, og anfægter at data management og datakvalitet generelt ikke længere kan betragtes som selvstændige discipliner. Dataarkitektur er stærkt forbundet til andre funktionelle aspekter ved virksomheden, hvorfor det er nødven- 10 Platon, 2007a, s Kimball, s

24 digt at adressere dataarkitektur mere overordnet 12. Herzum bruger begrebet The realtime enterprise karakteriseret ved at linjerne mellem operationelle data og data warehouses viskes ud. Hermed mener han, at BI-værktøjer og andre værktøjer nu også udvinder historiske data i real-time. Mange virksomheder tilgår datakvalitet som et data management-problem 13. Men datakvalitet går på tværs af forretningsprocesser, funktionelle processer og applikationer. Dette er yderligere en begrundelse for at betragte IM-modenhed frem for BI-modenhed. Det er vigtigt for virksomheder at adressere hvad det kræver at starte og gennemføre et IM-projekt, herunder om den nødvendige modenhed er til stede. Til at undersøge hvad modenhed betyder i forhold til IM, har vi anvendt The Data Warehouse Lifecycle Toolkit, hvori begrebet readiness optræder samt Five Steps to evolving into an intelligent high-performance enterprise, som er et white paper fra SAS. I det følgende beskrives begrebet readiness samt modenhedsmodellen fra SAS med henblik på at kunne definere hvad der kendetegner IM-modenhed Kimball readiness I bogen The Data Warehouse Lifecycle Tolkit, omtaler Ralph Kimball nødvendigheden af at definere sit data warehouse-projekt før man går i gang med udvikling og imlementering 14. Dette omfatter dels at undersøge og lokalisere behovet for et data warehouse dels en vurdering af virksomhedens readiness til at gå i gang med selve udviklingen af DW et. Readiness inden for data warehousing mener vi har mange ligheder med modenhed inden for IM-projekter. Derfor vil vi nu kigge nærmere på hvad readiness betyder. Kimball opstiller tre scenarier som kan være beskrivende for hvor og hvordan behovet for et DW opstår. 1. Demand from a lone zealot Efterspørgslen på et DW kommer i dette scenarie fra en enkeltstående og ledende person i virksomheden. Vedkommende efterspørger ivrigt bedre information og adgang til information som kan hjælpe med og understøtte vigtige beslutninger. 12 Herzum s Ibid. 14 Kimball, s

25 2. Too much demand Efterspørgslen kommer fra flere forskellige CIO er som generelt udtrykker behov for bedre information. 3. In search of demand Efterspørgslen på et DW kommer i dette tredje scenarie fra en enkeltstående CIO, som ikke vil være den eneste i branchen, der ikke har et DW. Behovet er derfor ikke reelt til stede eller ikke tydeligt, men den pågældende søger efter problemer eller fordele som kan begrunde et behov. Det er altså ifølge Kimball vigtigt at lokalisere og vurdere behovet for et DW før man går videre i processen med at udvikle et sådan. I forlængelse heraf kan man også sige at ligesom inden for EAmodenhed må behovet for et DW generelt erkendes i virksomheden. En god og ledende person kræves til at styre og støtte udviklingen af DW et under hele processen. Kimball taler desuden om fem faktorer, som må adresseres før man i detaljer kan begynde sit arbejde med DW. Faktorerne skal afdække grundlaget for at en virksomhed er i stand til arbejde med DW. Derfor ser vi en række ligheder i forhold til de modenhedsfaser vi har præsenteret tidligere i opgaven. Om disse faser siger Herzum blandt andet at de er direkte overførbare til i hvilken grad en virksomhed er i stand til at arbejde med forskellige aspekter af EA. Readiness, som kimball omtaler det, er ikke en lineær proces som for eksempel Ross s modenhedsmodel. Men faktorerne, som vi omtaler herunder, må alle være til stede i en sådan grad, at opbakning, motivation, samarbejde, virksomhedskultur og forretningssituationen danner grundlag for arbejdet med at udvikle og implementere DW et 15. Sponsor Den vigtigste faktor, som ifølge Kimball udgør 60 % af de følgende faktorers samlede betydning er en business management sponsorer 16. Der tænkes her ikke på økonomiske sponsorer, men derimod på højt respekterede nøglepersoner i virksomheden som er visionære og realistiske på samme tid. En god sponsor har evne til at tage kontante beslutninger og efterfølgende tage konsekvensen heraf. Motivation DW er et værktøj som kan opfylde specifikke og vigtige forretningsbehov. Der kan dog være flere 15 Kimball, 1998, s Kimball, 1998, s

26 forskellige motiver for at implementere et DW. Heriblandt øget konkurrence på et marked eller ønsket om at trænge ind på nye markedsområder, men også nye interne eller eksterne processer og krav kan være en overbevisende motivation for at udvikle et DW. Denne faktor adresserer altså i hvilken grad ønsket om at udvikle et DW er integreret med virksomhedens forretningsstrategi, og målet er naturligvis at opnå synergi med denne relation. Samarbejde Vejen til et succesfuldt DW bliver ifølge Kimball til gennem samarbejde og partnerskab på tværs af afdelinger og teams i en virksomhed. Hermed er ansvar og ansvarsfølelse fordelt på flere individer i virksomheden. Et DW-projekt er en åbenlys mulighed for at reparere et dårligt forhold mellem forskellige afdelinger, såfremt begge parter er villige til at samarbejde. Derfor er villighed og ønske om partnerskab en vigtig faktor for arbejdet med DW og IM-projekter. Analytisk kultur Endnu en faktor for en virksomheds readiness er den nuværende analytiske kultur som kendetegner virksomheden. Hvis virksomheden ikke i udpræget grad anser information og analyse heraf som værdifuld, er virksomheden ikke umiddelbart parat eller egnet til at implementere et DW. Man kan hér skelne mellem virksomheder der træffer beslutninger ud fra data og facts og virksomheder der træffer beslutninger på baggrund af fornemmelse og antagelse. Kan denne faktor kun tilskrives lav værdi, står virksomheden over for at skulle ændre den kulturelle mentalitet. Datakvalitet Sidst men ikke mindst, er en væsentlig faktor for en virksomheds readiness til at udvikle og implementere et DW, hvilken datakvalitet virksomheden har. Dette omfatter både konsistens, placering og kompleksitet. Desuden vil udvikling af et DW besværliggøres hvis der i virksomheden ikke er vedtaget standarder inden for processer og procedurer. Kimball har ikke behandlet modenhed som et specifikt område, men ovenstående viser at udvikling og implementering af IM og DW kræver en vis grad af modenhed idet interne og eksterne faktorer må evalueres og eventuelt optimeres før et IM/DW-projekt er realiserbart SAS White Paper om IM-modenhed Five steps to evolving into an intellingent high-performance enterprise er et white paper fra SAS som beskriver fem forskellige niveauer for information capabilities. De fem niveauer er skitseret i 24

27 figur 6, The Information Evolution Model (EIM). Modellen giver mulighed for at evaluere anvendelse og håndtering af information i forhold til informationens strategiske betydning. Således kan det ud fra modellen vurderes på hvilket niveau man befinder sig og hvordan man kan avancere til det næste niveau. Før en virksomhed kan opnå succes med hensyn til håndtering af information er der, ifølge SAS, fire dimensioner den skal være opmærksom på. De fire dimensioner er infrastruktur, håndtering af viden, humankapital og virksomhedskultur 17. Dimensionerne påvirker hver især og tilsammen hvorledes information håndteres bedst muligt. En virksomheds modenhed kan ud fra disse dimensioner beskrives på fem niveauer: Operate, Consolidate, Integrate, Optimize og Innovate. Figur 6 The Information Evolution Model (Kilde: SAS White Paper, 2005) Hvert niveau i modellen er en nødvendig forløber for det næste og hvert højere niveau omfatter og udvider alle tidligere niveauer. I det følgende vil vi beskrive hvad de enkelte niveauer i modellen indeholder. iveau 1 - The Operational Enterprise Dette niveau er karakteriseret ved at der er individuelt ejerskab af data og kontrol. De enkelte ansatte i virksomheden sørger selv for at udnytte den information der er tilgængelig, for at takle de daglige problemstillinger. Infrastrukturen er opbygget af enkeltstående systemer, der ikke er sammenkoblet og de analyseværktøjer der eventuelt benyttes er klientbaseret og ikke serverbaseret. Håndteringen af viden er 100 pct. individuel og medarbejderne sætter pris på at være autonome. Kulturen fremmer karismatiske ledere og individualister og der er et indbyrdes konkurrenceforhold mellem medarbejderne i de enkelte afdelinger i virksomheden. 17 SAS 2005, s

28 For at bevæge sig fra niveau 1 til niveau 2, skal overflødige processer reduceres. Der skal bruges mindre tid på at indsamle data og mere på at analysere den. Dette fører til en større grad af konsistens og kontinuitet med forretningsfunktionerne i virksomheden, samt en øget motivation af medarbejderne og en større tillid til resultater og analyser. iveau 2 The Consolidated Enterprise Dette niveau er karakteriseret ved at individuelle perspektiver erstattes af funktionelle standarder i de forskellige afdelinger i virksomheden. Infrastrukturmæssigt anvendes der fælles hardware og softwareløsninger på afdelingsniveau, men ikke i hele virksomheden. Videnshåndtering bliver ligeledes konsolideret på afdelingsniveau, og medarbejderne arbejder som en gruppe og ikke individuelt. Der er en tendens til en dem mod os -mentalitet mellem de forskellige afdelinger i virksomheden. For at bevæge sig fra niveau 2 til niveau 3 skal virksomhedens strategi for håndtering af information sidestilles med virksomhedens overordnede strategiske målsætninger, uden at gå på kompromis med de behov der findes i de enkelte afdelinger. Herved opnås bedre mulighed for at tilpasse sig ændringer i markedet, bedre erhvervelse og fastholdelse af kunder og lavere omkostninger ved håndteringen af information. iveau 3 The Integrated Enterprise Dette niveau er karakteriseret ved at den konsolidering der skete på niveau 2 bliver udvidet til at dække hele virksomheden. Der sker en formalisering af informationshåndteringen fra centralt hold og der skabes en strømlinet virksomhedsinfrastruktur der dækker både hardware, software, databaser og netværk. Herved elimineres redundans og der opnås én version af sandheden. Håndteringen af viden skifter fra at have fokus på det operationelle til det analytiske, og dermed bliver det muligt at lave analyser af hvad-nu-hvis -situationer. Medarbejderne arbejder stadig i teams, men tænker også ud over deres funktionelle områder til gavn for hele virksomheden. På niveau 3 er information accepteret som et essentielt værktøj til at skabe værdi for virksomheden og dens kultur. For at bevæge sig fra niveau 3 til niveau 4, skal virksomhedens forretningsmodel udvides til et extended network. Der skal opbygges systemer og en kultur der indfanger tavs og eksperimentel viden såvel som explicit og kvalitativ information. Dette medfører en markant forbedring af effektiviteten, produktudviklingen og kvaliteten af services samt en nedbringelse af virksomhedens omkostninger i forbindelse hermed. 26

29 iveau 4 The Optimized Enterprise Dette niveau er karakteriseret ved at virksomheden fokuserer sin indsats på at opnå yderligere optimering af alle dimensioner, for derved mere præcist at kunne forudsige hvad fremtiden bringer. Herved skabes et extended network med både kunder, leverandører og forretningspartnere. Infrastrukturen giver på dette niveau en komplet sammenhæng mellem alle systemer, og udnyttelsen af den tilgængelige information bliver derved en naturlig del af forretningsprocessen. I forhold til håndtering af viden, er der fokus på at maksimere effektiviteten og forbedre kvaliteten, timingen og tilgængeligheden af information. Medarbejderne er højt motiverede og tilpasningsvillige og foretrækker kreative udfordringer i stedet for ensformige opgaver. Virksomhedskulturen ansporer de individuelle medarbejdere til kontinuerligt at foretage forbedringer på baggrund af den tilgængelige information. De interne konkurrenceforhold er erstattet af samarbejde og indbyrdes afhængighed. I praksis er niveau 5 en udvidelse af niveau 4 på en sådan måde, at de nye idéer der opstår, hurtigt bliver optimeret og brugt hvor de udnyttes bedst muligt. Herved bliver forskellighed og variation nøglen til succes. Der opnås en højere profit af nye produkter og markeder. iveau 5 The Adoptive, Innovating Enterprise Dette niveau er karakteriseret ved at det opnåede vækst- og overskudspotentiale tilføres yderligere brændstof i form af kreativitet og fornyelse. Infrastrukturen er en intelligent arkitektur der er fleksibel og forandringsklar, og giver mulighed for at gennemføre enhver integration eller udvidelse virksomheden måtte stå overfor. Der er mulighed for at analysere og teste alle tænkelige scenarier i et virtuelt miljø og infrastrukturen giver mulighed for netværkskreativitet, herunder systemer der kan organisere og pleje nye idéer. Ved håndtering af viden, benyttes data mining og analytiske modeller, som kan beskrive fremtiden og minimere risici, alt imens der foretages konstant innovation. Medarbejderne er proaktive, kreativt tænkende og giver vital viden til virksomheden med fokus på at virksomheden skal vokse. Samtidig tager virksomheden højde for nye områder hvor der kan skabes værdi. Virksomhedskulturen lægger op til, at der skal tænkes kreativt og alternativt, det vil sige outside the box og de eneste dårlige idéer er dem der ikke bliver drøftet. En proaktiv, revolutionerede ændring af virksomhedskulturen er ikke noget der frygtes, det er normen. En virksomhed der har nået niveau 5, vil oftest se på andre industrier, teknologier eller markeder efter forretningskoncepter der kan indarbejdes, så der skabes ny værdi i virksomheden. Derudover er innovation en del af alle dimensionerne af modenhedsmodellen, således at succeser opretholdes og gentages. Modenhed ifølge EIM-modellen kan således beskrives som en proces, hvor en virk- 27

30 somhed bevæger sig fra at have en eller flere fragmenterede BI-løsninger, til at have èn integreret IM-løsning Hvad er IM-modenhed? IM handler om at skabe kompromisløs adgang til information. Data skal struktureres i for eksempel et DW og skal efterfølgende kunne behandles og analyseres så det ikke længere blot er data, men information, som kan udveksles på tværs af systemer og være grundlag for vigtige strategiske og forretningsmæssige beslutninger. Vi har i de forrige afsnit undersøgt forskellige kilder for at afdække hvad der karakteriserer modenhed inden for IM. Vi har med nedenstående figur sammenfattet hvad der karakteriserer modenhed inden for IM: Figur 7 IM-modenhed (Egen fremstilling) Vi betragter IM-modenhed som en proces bestående af fem faser. I den første fase har man i virksomheden ikke erkendt behov for strukturering af data. Derimod præges arbejdsgange og processer af individuel datahåndtering. Medarbejderne arbejder autonomt i enkeltstående og klientbaserede systemer. Det ville typisk være i denne fase at scenariet om Demand from a lone zealot kunne optræde idet behovet for strukturering af data ikke er udtalt, men måske snarere forsagt blandt en eller få personer. Derfor er der også i denne fase behov for en sponsor, som kan bakke op om det forsagte og tage de nødvendige beslutninger. 28

31 I anden fase har virksomheden fokus på standardisering af såvel hardware som software. Det indledende arbejde med strukturering af virksomhedens videnshåndtering er begyndt. I denne fase er det vigtig at kommunikere og formulere motivationen for at arbejde med datastruktur og organisering. Et eksempel herpå kunne være samarbejde som motivation. I tredje fase tænkes der i udvidet grad på infrastruktur og optimering af virksomhedens videnshåndtering. Forskellige systemer begynder at kunne tale sammen hvorfor data kan behandles som information. En vigtig faktor i denne fase er derfor virksomhedens evne til at foretage analytiske processer ud fra struktureret information. Struktureret information skaber i stigende grad værdi for virksomheden. Integrering af virksomhedens systemer foranlediger desuden samarbejde på tværs af forskellige afdelinger. Evne til partnerskab og samarbejde på tværs af virksomhedens afdelinger er desuden en vigtig faktor for at videre avancering i modenhedsprocessen er realiserbar. I fjerde fase har virksomheden fokus på at optimere sin datakvalitet. I takt med at flere og flere systemer bliver interoperable bliver det i stigende grad nødvendigt at sikre høj datakvalitet. Datakvaliteten er vigtig idet informationen, som bygger på disse data, i stigende grad anvendes i forbindelse med beslutningsprocesser. Valide og konsistente data er derfor kritisk for den videre avancering i modningsprocessen. Modenhed i femte fase er udtryk for at virksomheden har en intelligent arkitektur med hensyn til såvel IT som data. Information danner i høj grad grundlag for vigtigt forretningsmæssige beslutninger. Arkitekturen er fleksibel og omstillingsparat, så den løbende kan tilpasses nye strategier og påvirkninger fra en foranderlig omverden. 4.5 Delkonklusion IM handler om at skabe bedre adgang til bedre information. Her er et af områderne der har betydning for modenhed videns- og informationshåndtering. Et andet område adresseres med begrebet readiness, som samlet vurderes ud fra en række faktorer for organisatoriske og virksomhedskulturelle egenskaber. IM-modenhed har derfor stærke rødder i optimering af informationshåndtering og infrastruktur. Høj datakvalitet skal øge en virksomheds evne til dels at skabe interoperabilitet mellem systemer, dels at gennemføre analytiske processer ud fra pålidelig information. Graden af modenhed der tilstræbes af virksomheder, med hensyn til IM, er en situation, hvor virksomheden er fleksibel og omstillingsparat i forhold til strategi og påvirkninger fra omverdenen. 29

32 Vi har nu ved hjælp af Figur 7 skabt overblik over hvad der karakteriserer modenhed inden for IM. Vi har således, udover at have været i EA-hulen, også besøgt IM-hulen, hvor man erkender ud fra forestillinger om hvad der er IM. En signifikant oplevelse ved besøget var, at hulen ikke kun indeholdte BI men også DM og dermed var det er IM-hule. 30

33 5. Fælles referenceramme for EA og IM Nu hvor vi har opholdt os i både EA og IM-hulerne, har vi fået indsigt i, hvordan man sanser og erkender i hver af disse fænomen-verdener. Derfor kan vi nu undersøge om de erkendelser og forestillinger vi har fået indsigt i har ligheder. I dette afsnit vil vi således, på baggrund af afsnittene om EA-modenhed og IM-modenhed, undersøge om der eksisterer en fælles referenceramme for EA og IM med hensyn til modenhed. IM - Modning EA - Modning Figur 8 Fælles referenceramme 1.0 (Egen fremstilling) Figuren herover illustrerer hvad vi har undersøgt indtil nu. Kassen, som pilene (modenhedsfaserne) peger mod, skal illustrere hvad en eventuel fælles referenceramme indeholder af begreber. Med andre ord er indholdet i kassen den referenceramme hvorom EA og IM erkender ens i forhold til modenhed. På figuren ser det ud som om EA-modenhed og IM-modenhed er helt parallelle processer. Modningsprocesserne har samme naturlige udgangspunkt, hvor man i virksomheden ikke har erkendt behovet for at forbedre infrastrukturen, samtidig med at der er fokus på lokal/individuel optimering af mange forskellige applikationer og systemer. Herefter er der ikke direkte sammenhæng mellem faserne, men der eksisterer overlap mellem modenhedsprocessernes indhold. Det er kendetegnende for begge modenhedsprocessers udspring, at usammenhængende struktur og ringe grad af interoperabilitet mellem systemer, applikationer og afdelinger efterhånden åbenbarer et behov for forandring. i forlængelse heraf, er det også fælles for de to modenhedsprocesser, at 31

34 behovet for forandring og forbedring af infrastrukturen må erkendes, før der kan avanceres fra den første modenhedsfase. Desuden er der behov for personer til at varetage styring og motivering af arbejdet under hele modenhedsprocessen. Ved undersøgelsen af både EA- og IM-modenhed, er vi stødt på at datakvalitet og det at strukturere udveksling af data og information, er en vigtig faktor for at kunne avancere i modenhedsprocessen. De tidlige modenhedsfaser er præget af ønsker og initiativer om at skabe standardiserede og konsistente data, og DW indføres som hjælpemiddel hertil. Man kan her sige at det er naturligt at data warehousing introduceres tidligt i modenhedsprocesserne, da et DW her kan opfylde specifikke behov for virksomheden. I de tidlige modenhedsfaser, kendetegnes virksomhederne ved ikke at have en forankret forretnings- og IT-stategi, og virksomhederne mangler arkitekturmæssige standarder for at arbejde lokalt med globale data, informationer og applikationer. Desuden er et område af høj relevans i begge modenhedsprocesser standardisering af hardware og software, så integrering af systemer kan bane vejen for anvendelse af fælles funktionalitet og standarder. Denne konformitet adresseres for begge modenhedsprocessers vedkommende i anden fase i forbindelse med standardisering og data warehousing. Fordelene ved standardisering og genbrug begynder at motivere virksomheden. Hermed øges opbakningen til at forandre sig og tage nye teknologier og fælles standarder til sig, i takt med at udbyttet synliggøres. Et andet område er optimering af processer, så de løbende kan tilpasses virksomhedens forretningsstrategi. I begge modenhedsprocesser er et at målene at kunne gennemføre analytiske processer hvis resultater kan danne grundlag for beslutningsprocesser og strategiske valg. I forlængelse heraf er vi nået frem til det som er målet med begge modenhedsprocesser. Vi ser en overskyggende lighed mellem de to modenhedsprocesser når vi nærmer os den sidste fase. Her har en virksomhed opnået den ønskede fleksible arkitektur og infrastruktur som gør den til en agil og omstillingsparat virksomhed. Man kan således sige at målet med modenhed inden for både EA og IM er at opnå en høj tilpasningsevne gennem strukturerede data og analytisk informationshåndtering. 32

35 Vi kan derfor fuldende figur 8 vi præsenterede i starten af dette afsnit. Figuren ser herefter således ud: IM - Modning EA - Modning Figur 9 Fælles referenceramme 2.0 (Egen fremstilling) 5.1 Delkonklusion Vi har med dette afsnit fundet frem til at der eksisterer en fælles referenceramme for EA- og IMmodenhed. IM og EA griber modning an fra to forskellige vinkler, men arbejder i høj grad mod fælles mål. Overlappet bliver klarere og klarere jo højere oppe i modenhedsfaserne virksomhederne befinder sig, hvilket også viser at det ikke er muligt at nå det højeste modenhedsniveau inden for EA uafhængigt af IM, og omvendt. Hvis det er fordelagtigt at kombinere EA og IM i forhold til at øge graden af modenhed, bør man kunne påpege områder hvor der eventuelt kan opstå synergi gennem denne kombination. Som vi tidligere har omtalt, nævner Herzum at det er muligt at fremskynde den proces det kræver at avancere fra én fase til den næste. Han nævner dog ikke hvad det i givet fald er der foranlediger dette. I det nye perspektiv vil vi derfor inddrage nye begreber, hvormed vi har til hensigt at undersøge om der kan opstå synergi ved at kombinere EA og IM gennem modenhedsprocesserne. 33

36 6. Synergieffekter mellem EA og IM Vi vil i dette afsnit argumentere for hvorfor det er muligt og hensigtsmæssigt at arbejde med EA og IM samtidig i forhold til at avancere hurtigere i modenhedsprocesserne. Er der oplagte teknologier og metoder hvormed der allerede eksisterer et overlap, og findes der områder hvor der decideret kan tales om at opnå en synergieffekt? Gennem vores undersøgelse af EA og IM-modenhed, har vi dannet os et overblik over hvad disse områder indeholder selvstændigt og samtidig har vi fået en fornemmelse af hvor der eksisterer kontaktflader mellem dem. Vi må nu udvide vores figur til også at omfatte en sky, symboliserende teknologi som kan forstærke kontaktfladerne mellem EA- og IM-modenhed. Figur 10 Fælles referenceramme 3.0 (Egen fremstilling) Vi vil i det følgende undersøge hvad skyen kan indeholde, og beskrive effekten af initiativer inden for disse områder. Skyen kan indeholde mange begreber, hvorfor vi netop har valgt at illustrere det med en sky. Der findes således ikke en skarpt optrukket linje for hvad der er med til at øge modenhed for IM og EA og det er også vigtigt at pointere, at vi ikke forsøger at kortlægge alt hvad der findes mellem EA og IM, men derimod fokuserer vi på hvad der har relation til opgavens problemstilling. Skyen er derfor et udtryk for hvad vi mener, kan skabe synergieffekt i modningsprocessen, når man arbejder med EA og IM samtidigt. Skyen skal således ses som vores bud på fremskyndelse af modningsprocessen, som Herzum lægger op til men ikke forklarer. 34

37 Som tidligere nævnt, ser vi stor overensstemmelse mellem EA og IM om organisationens indstilling til data. Ross s højeste modehednsniveau er A modular architecture 18, med den uddybende forklaring: The architecture builds onto enterprise-wide global standards with loosely coupled applications, data and technology components to preserve the global standards while enabling local differences. Vi mener Ross hér udtrykker at det ypperste og målet med EA-modning er at opnå en Service orienteret arkitektur (SOA). SOA er et mere IT-implementeringsnært koncept, der er tæt knyttet til og understøttet af data og datas troværdighed. Vi mener derfor at SOA går hånd i hånd med Master Data Management (MDM), og dermed kædes områder fra henholdsvis EA-verdenen og IM-verdenen sammen, hvilket vi vil argumentere for i det de følgende afsnit. Først vil vi gennemgå nogle karakteristika ved SOA og MDM, og sammenhængen mellem disse, hvorefter vi vil knytte det til vores figur for sammenhængen mellem EA og IM. 6.1 Service orienteret arkitektur For at beskrive SOA, skal der først skabes en fælles forståelse af hvad ordet service indeholder i SOA-kontekst. Nogen arbejder med SOA som en teknisk infrastruktur til opbygning af IT-systemer. I dette tilfælde er en service et program der kører på en form for server, og stiller funktionalitet og data til rådighed til applikationer eller IT-systemer. Andre ser SOA fra en mere forretningsmæssig vinkel, hvor det er en måde virksomheden håndterer sin organisation, sine processer og i det hele taget sin måde at lave forretning på. Her kunne en service for eksempel bestå af en ydelse mellem forretningsenheder. Der argumenteres for at SOA bør deles op i to separate discipliner, nemlig SOBA og SOTA, som står for henholdsvis Service Orienteret Business Arkitektur og Service Orienteret Teknisk Arkitektur 19. Vi mener at dette er en fornuftig opdeling, når man skal beskrive SOA, men vi mener også det er vigtigt at man ikke adskiller dem helt, da det fulde udbytte af SOA opnås når både den forretningsmæssige og den tekniske del mødes. Netop i relation hertil, har SOA store ligheder med såvel EA som IM. Som vi skrev i afsnit 3, er hovedformålet med EA at lukke gabet mellem forretning og IT. På samme måde mener vi også at SOA adresserer begge dele, og forsøger at udviske grænserne for hvornår forretningen starter og IT en slutter. SOA som en arkitekturmodel for IT-løsninger (SOTA), går kort sagt ud på at udvikle og opdele funktionalitet og tilgang til data i moduler. Disse moduler, eller services, står til rådighed for andre 18 Ross, 2003, s Gøtze, 2007a 35

38 moduler, applikationer og systemer. SOA er således mere implementationsnær end for eksempel EA, da denne arkitektur giver mere direkte anbefalinger til hvorledes arkitekturen i IT-systemer skal se ud. SOA er altså ikke en teknologi eller et produkt, men et koncept for hvordan man kan realisere IT-arkitektur. Gennem SOA kan IT-relaterede forretningsbehov adresseres direkte, på en struktureret og vedligeholdelsesvenlig måde 20. Uden SOA Med SOA Figur 11 SOA (Kilde: SOA etwork, egen tilvirkning) I en organisation hvor der ikke er tænkt i SOA, er systemerne isolerede i forhold til hinanden. Mange steder bygger de enkelte systemer på forskellige og måske proprietære softwareløsninger. Noget data går igen i forskellige systemer, og vedligeholdelse og synkronisering af data bliver et ressourcekrævende stykke arbejde. Information fra de enkelte systemer, kan udelukkende tilgås gennem brugergrænsefladen på de enkelte systemer, og der er altså en meget lav grad af integration mellem systemer og data. Dette svarer ganske godt til de laveste modenhedsfaser inden for såvel IM som EA. Når organisationen begynder at tænke i SOA, åbnes grænsefladerne på de forskellige systemer med såkaldte services. Disse services adresserer forskellige behov og områder. De indgår som en vigtig del af den interne IT-arkitektur til opbygning, deling og tilgængelighed af funktionalitet og data. Som det kan ses på højre side af figur 11 ovenfor, er systemerne knyttet sammen med services. De forskellige systemer er bibeholdt, men de er blevet koblet til organisationens fælles IT-arkitektur, i 20 Schmelzer (2006) 36

39 langt højere grad end før. De enkelte services skaber altså tilgængelighed og funktionalitet i hele organisationen, men er stadig under administration af de lokale systemers ansvarlige. Det tilgodeses altså at ansvar og IT-governance udføres inden for de forskellige områder af virksomheden. Kendskabet til de forskellige systemer, der meget vel kan være baseret på lukkede standarder, udnyttes til at stille funktionalitet og data til rådighed i et åbent miljø med åbne standarder. Og endnu vigtigere, efter fælles arkitekturstandarder. Som det også ses på figur 11, er det ikke meningen at SOAservices erstatter systemer, men at disse services øger kommunikation og gennemsigtigheden mellem systemer, hvilket medfører lettere og bedre data-flow samt øget tilgængelighed af data i virksomheden. En anden vigtig pointe omkring SOA er den decentrale natur. Der stilles ikke krav til hvor services udvikles og drives, men derimod fokuseres der på at services overholder den fælles arkitekturs standarder. Den mere forretningsmæssige del af SOA (SOBA), dækker ikke over hvordan IT skal implementeres i organisationen, men nærmere hvordan organisationen skal indrettes for at imødekomme forskellige forespørgsler. I stedet for at indrette sig i fastlåste faglige og organisatoriske enheder, forsøger SOBA at indrette organisationen således at opgaver løses inden for organisatoriske services. Der lægges i høj grad op til at opgaver løses hvor kompetencerne findes, uden at lade sig hindre af organisatoriske grænser. SOA som en paraplybetegnelse for både den tekniske og forretningsmæssige del, foranlediger således at opgaver løses af services, både når det kommer til teknik og forretning. 6.2 Master Data Management Master Data Management omhandler håndtering af masterdata. Hvor DM tager stilling til en række overordnede problemstillinger omkring data, er MDM tættere på den fysiske håndtering. MDM s fornemste formål er at sikre at kildedata (fra for eksempel operationelle systemer) kun ligger et sted og at alle systemer, der skal tilgå disse data, benytter dette sted 21. Formålet med MDM er altså også at opnå centraliserede og konsistente data. En ting der er vigtig at forstå er, hvorvidt denne centralisering rækker. Der menes ikke nødvendigvis at al data i virksomheden skal centraliseres et sted, men alle forekomster inden for en kategori skal samles ét og samme sted. Som eksempel skal kundedata, såvel det historiske som det opperationelle, lagres og vedligeholdes ét sted. Dette giver en form for hub-and-spoke-arkitektur. 21 Kalogirou (2007) 37

40 Ringe MDM God MDM IM- Modning Figur 12 MDM (Kilde: Agosta, egen tilvirkning) Som det ses af Figur 12, resulterer god MDM i færre relationer mellem systemer, og der findes kun ét sted hvor masterdataene skal vedligeholdes. I forhold til vores afsnit omkring IM-modning, ser vi også at en del af det at få bedre kontrol, standardisering og konformitet i sin håndtering af data, direkte afhænger af god MDM. Derfor representerer pilen IM-modning. En ting er at have planen og retningslinjerne for hvad dataarkitekturen skal understøtte, noget andet er at føre det ud i livet. Et koncept inden for IT-arkitektur, det tidligere omtalte SOA, lægger i høj grad også op til en hub-and-spoke-arkitektur, selvom det ikke er et krav. I det følgende vil vi kigge på de synergieffekter og begrænsninger der opstår når SOA og MDM mødes, samt hvordan dette kan være med til at fremskynde modningsprocesserne for EA og IM. 6.3 SOA møder MDM I takt med at databehovene i en virksomhed ændrer sig, stilles der højere krav til de bagvedliggende arkitekturmæssige, organisatoriske og strategiske beslutninger. Hverken SOA eller MDM kan adressere dette alene, men ved at lade de to mødes, mener vi at modningsprocessen kan fremskyndes i kombination med EA og IM. Øget modenhed og den generelle trend går mod at flere og flere enheder i virksomheden skal have så nær realtime adgang som muligt til data, på tværs af virksomhedens organisatoriske grænser. En organisation der arbejder med data og information som et strategisk aktiv, bør have øje for denne trend. Det giver et innovativt miljø, med høj produktivitet og 38

41 lav time-to-market for nye forretningsrelaterede IT-projekter. For at virksomheder kan imødekomme denne trend, må der tænkes i brede perspektiver når det kommer til DM og arkitektur. Netop her ser vi et potentiale for at opnå en synergieffekt ved at lade SOA og MDM mødes. Jo tættere på masterdataene man knytter de enkelte services, jo mere realtime-adgang opnås. Når services ønskes koblet så tæt på masterdata, ser vi en fordel i at der benyttes DW s som et formidlende og konformitetsskabende lag mellem masterdata og SOA-services. Det betyder imidlertid at DW s ikke udelukkende benyttes som et forstadie til analyse og rapportering i BI-øjemed, men også som dataformidling. Med et DW mellem masterdata og services, er dataene ikke længere realtime. Her er det mere korrekt at tale om nær-realtime i et ofte opdateret DW. DW et bruges altså i en anderledes kontekst end inden for BI, men med samme formål. Figur 13. SOA møder MDM. (Egen fremstilling) 39

42 Den tidligere omtalte hub-and-spoke-arkitektur, hvor masterdata samles et sted, kan gnidningsfrit kombineres med SOA som det formidlende lag over masterdataene. Det er dog urealistisk at samle alt masterdata et sted, da det er tæt knyttet til forskellige mere eller mindre proprietære softwareløsninger. Der er altså behov for at sprede services ud hvor dataene ligger, hvilket også går fint i spænd med SOA, der netop lægger op til at være spredt over flere platforme og organisatoriske enheder. Vi mener altså at MDM mødes med SOA i lidt opstrammede tøjler, og udmønter sig i en arkitektur som vi kalder SOA-distribueret masterdata. SOA har således ansvar for distribution, standardisering og tilpasning til virksomhedens øvrige arkitektur, og MDM har ansvar for datakvalitet og konformitet. Dette realiserer en hub-and-spoke-arkitektur, med flere SOA-distribuerede masterdatahubs. Figur 13 herover illustrerer et eksempel herpå. 6.4 EA/IM modning og SOA-distribuerede masterdata Vi er nu kommet med et eksempel på hvordan SOA-distribuerede masterdata i en hub-and-spokearkitektur kan foranledige distribution, standardisering og konformitet i en arkitektur der bygger på datakvalitet. Herzum taler i relation til sin modenhedsmodel om, at hver modenhedsfase bygger oven på tidligere faser, og at virksomheder derfor ikke kan springe faser over. Han nævner samtidig at det er muligt at avancere hurtigere mellem faserne, uden at specificere hvordan. Vi mener at netop SOA-distribuerede masterdata er et middel til at avancere hurtigere fra fase til fase i modningsprocessen når EA og IM kombineres. Vi er klar over at modenhedsprocesserne for EA og IM er naturlige udviklingsforløb og at det derfor er urealistisk at foretage drastiske ændringer fra dag til dag. Derfor må implementeringen af en arkitektur for SOA-distribuerede masterdata også ses som en proces. Forskellen er hér at denne arkitektur langt tidligere i processen adresserer hvad der oprindeligt var målet med både EA- og IMmodning (jf. figur 9) Har man lagt sig fast på at implementere en arkitektur for SOA-distribuerede masterdata, er behovet for arkitektur for det første erkendt. Betragtes modningsprocesserne for EA og IM, befinder man sig således i anden fase. Efter vores opfattelse er det allerede fra denne fase muligt at lægge sig fast på at opnå en specifik arkitektur. Vores eksempel på en arkitektur for SOA-distribuerede masterdata (figur 13) indeholder elementerne fra alle modenhedsfaserne for såvel EA- som IM-modning. Anskues arkitekturen som en proces, er det i lighed med EA- og IM-modning nødvendigt at behovet for arkitektur og forbedret infrastruktur er erkendt. Dette har vi tidligere fastlagt til at ske i anden 40

43 fase (se figur 3 og figur 7). Herefter lægger arkitekturen for SOA-distribuerede masterdata op til at standardisere virksomhedens IT-systemer ved at lade dem tilgå data gennem services. Som nævnt er det altså ikke hér et krav at erstatte alle systemer, som virksomheden har tilegnet sig gennem første fase. Det er netop her en fordel at virksomheden har systemer det er tilpasset specifikke forretningsbehov. Det vigtige som arkitekturen for SOA-distribuerede masterdata bibringer, er i denne sammenhæng MDM, som sikrer konformitet i virksomhedens kildedata. Da implementering af arkitekturen er en proces, kunne man her forestille sig at der primært fokuseredes på virksomhedens kernedata. Konformitet i kildedataene foranlediger således en fremskyndelse i forhold til at kunne strukturere data til information. Derfor fremskyndes også processen for at kunne håndtere analytisk informationshåndtering. Information kan også distribueres gennem mange forskellige services i nær-realtime. Arkitekturen for SOA-distribuerede masterdata foregriber således behovet for at foretage rationalisering og optimering af datakvaliteten, idet masterdataene under hele processen kan vedligeholdes centralt. Samtidig har en virksomhed med fokus på denne arkitektur fra start tilegnet sig retningslinjer for at arbejde lokalt med globale data, hvad end dette foregår gennem et DW eller for eksempel et CRM-system. Med ovenstående mener vi således at der kan opnås synergieffekter mellem EA og IM ved at lade en arkitektur for SOA-distribuerede masterdata være bestemmende for hvorledes virksomheden modnes. Et konkret eksempel på en synergi er at SOA-distribuerede masterdata i takt med EA og IM-modning foregriber datakvalitet og informationshåndtering, samtidig med at arkitekturen foranlediger retningslinjer for at arbejde lokalt med globale data. Dermed kan virksomheder ved at tænke EA og IM-modning samtidig, drage stor nytte af at anvende denne arkitektur og målet med at blive en agil og omstillingsparat virksomhed ligger dermed ikke i en så fjern fremtid. 41

44 Vores endelige figur, kan derfor udvides med en stiplet pil under skyen. Pilen symboliserer synergieffekten der kan opnås ved for eksempel at lade arkitekturen for SOA-distribuerede masterdata være styrende for EA og IM-modningsprocesserne. Figuren ser herefter ud som følger: Figur 14 Fælles referenceramme 4.0 (Egen fremstilling) Kritik og begrænsninger. Vi er klar over at vores endelige figur ikke løser alle problematikker når områderne EA og IM mødes. Vi mener dog at vi, ved at studere den mere implementeringsnære del, har fundet nogle brugbare koblinger. Som vi tidligere har nævnt, kan man, ligesom inden for EA og IM, ikke gennemføre drastiske ændringer over kort tid. Virksomheden skal følge med og såvel ledelsesmæssige og organisatoriske forandringer kan være besværlige at gennemføre. Samtidig er der utvivlsomt områder inden for både EA og IM vi ikke har adresseret og derfor ikke har taget højde for i vores analytiske tilgang til problemstillingen. Derfor er det ikke utænkeligt at vi med Platons ord befinder os i en fænomen-verden, hvor vi sanser og erkender ud fra en forestilling om hvordan tingene ser ud. Vi har dog med denne opgave forsøgt at se tingene i perspektiv og samtidig distancere os fra vore egen hule. 6.5 Delkonklusion Vi har i dette afsnit undersøgt hvordan kontaktfladerne mellem EA og IM kan forstærkes. I denne forbindelse måtte vi tilføje en sky til vores figur. Skyen symboliserer netop hvad der kan forstærke kontaktfladerne mellem EA og IM. Denne sky valgte vi at udfylde med SOA og MDM. Efterfølgende påviste vi at kombinationen af SOA og MDM kan skabe en synergieffekt i forhold til infor- 42

45 mationshåndtering, standardisering, datakvalitet og konformitet. Herefter præsenterede vi begrebet SOA-distribuerede masterdata, samt en arkitektur herfor, skitserende hvordan kombinationen af SOA og MDM kan foranledige hurtigere avancering i modenhedsprocesserne, når man tænker EA og IM samtidigt. 43

46 7. Konklusion Vi har gennem denne opgave trin for trin udviklet en figur i takt med at vi for hvert afsnit har fået dybere og dybere indsigt i den problemstilling der ligger til grund for opgaven. Først fandt vi frem til at modningsprocessen inden for EA er en sekventiel proces og vi valgte at betragte den som en pil indeholdende fire faser. Det er således ikke muligt at avancere mere end ét niveau ad gangen. Arkitekturmodenhed og IT s strategiske indflydelse øges i takt med at virksomheden har større fokus på data og infrastruktur og samtidig mindre fokus på specifikke applikationer. Målet med modenhed er at skabe sammenhæng mellem IT- og forretningsstrategi, ved at integrere IT-systemer gennem moduler og services. Dette er grundlaget for at virksomheden på højeste modenhedsniveau kan blive agil og omstillingsparat i forhold til såvel interne som eksterne faktorer. Herefter fandt vi, gennem undersøgelsen af hvad der karakteriserer BI, ud af at det i forhold til modenhed ikke var nok kun at betragte BI men også DM. I en nærmere undersøgelse heraf fandt vi frem til at BI og DM under ét kunne betegnes som IM. Derfor ændrede vi undersøgelsen af hvad der karakteriserer BI-modenhed til at omfatte IM-modenhed. Vi fandt frem til at IM-modenhed kan betragtes som en proces bestående af fem faser. Dette illustrerede vi, ligesom for EA-modenhed, med en pil. Modenhedsfaserne har generelt fokus på optimering af informationshåndtering og infrastruktur, høj datakvalitet og pålidelig information. Målet med IM-modenhed er at blive en fleksibel og omstillingsparat virksomhed i forhold til strategi og påvirkninger fra omverdenen. Endelig kunne vi påpege en fælles referenceramme for EA og IM, indeholdende agilitet, omstillingsparathed, datakvalitet og informationshåndtering, som betegnelser for det modenhedsprocesserne arbejder hen mod. Denne referenceramme valgte vi at illustrere med en kasse indeholdende de nævnte begreber og områder. Herefter fandt vi det nødvendigt at udvide figuren med en sky, indeholdende teknologi og begreber som kan forstærke kontaktfladerne mellem EA og IM i modenhedsprocesserne. Vi undersøgte i denne forbindelse hvad SOA og MDM er og hvad der kan opnås ved at kombinere disse to områder. Vi fandt frem til at kombinationen kan udmøntes i en arkitektur for hvad vi kalder SOAdistribuerede masterdata. Med SOA-distribuerede masterdata mener vi det er muligt at opnå synergieffekt ved at tænke EA- og IM-modenhed samtidigt, da denne arkitektur foregriber det som op- 44

47 rindelig var målet med modenhedsprocesserne hver for sig. Dette illustrerede vi med en stiplet pil i den endelige figur, som illustrerer muligheden for at avancere hurtigere i modenhedsprocessen. Den endelige figur er udtryk for den erkendelsesmæssige proces vi har været igennem med denne opgave. Hulelignelsen har givet os en indgangsvinkel til at anskue og arbejde med problemstillingen. Vi betragtede derfor henholdsvis EA og BI som huler der repræsenterer hver sin fænomenverden. Da vi fandt frem til at BI-hulen i virkeligheden var en IM-hule og at fænomen-verdenerne tilsammen har en fælles referenceramme, blev vi opmærksomme på at vi, ved at påpege dette, muligvis selv befandt os i en fænomen-verden. Derfor fandt vi det nødvendigt at sætte tingene i perspektiv ved at inddrage nye begreber og områder med relation til både EA og IM. Hermed blev det klart for os at EA og IM i det nye perspektiv kunne kombineres, endda med fordele i forhold til at øge graden af modenhed. Erkendelsesprocessen ender foreløbigt hér og vi har med denne opgave forsøgt at distancere os fra vores egen hule. Vi mener derfor at vi med denne opgave er trådt et skridt nærmere idéernes verden. 45

48 8. Perspektivering Vi har med denne opgave lavet en forundersøgelse af sammenhængen mellem EA og BI ved at fokusere på modenhedsmodeller inden for begge discipliner. Vi har valgt at lade strukturen i opgaven følge vores egen erkendelsesproces, hvorfor analyseobjektets kontur undervejs har skiftet udeende. Det har været vigtig for os at kunne tilgå denne opgave netop som en erkendelsesproces, da problemstillingen tilsyneladende ikke er blevet behandlet før. Med denne tilgang til problemstillingen, har vi derfor undervejs opdaget nye områder, problemstillinger og emner, som kunne tages op i et videre studie af sammenhængen mellem EA og BI. Vi kommer i opgaven ikke med konkrete forslag til hvordan man skal implementere sine MDM- og SOA-løsninger for at øge sin modenhed. Vi kommer med et konkret forslag til en arkitektur der kan realisere SOA-distribuerede masterdata. Dog kommer vi ikke ind på hvordan og hvorvidt denne arkitektur i praksis er realiserbar. Det kunne således være interessant at lave en case-undersøgelse hvor man i praksis kigger på implementering af MDM og SOA og sammenspillet i mellem disse. Eventuelt med udgangspunkt i den figur vi allerede har præsenteret i opgaven. I forbindelse med implemeteringen, er der også en del åbne problemstillinger mht. hvorledes organisationen tilpasser sig den service-orienterede tankegang. Der er i det hele taget, i forbindelse med mange af de forslag og idéer vi tager op i opgaven, mange omstillingssituationer der skal adresseres. Disse omstillingssituationer kunne for eksempel imødekommes med change-management og nye organisationsformer, hvilket det også kunne være spændende at udforske. Derudover er videnshåndtering og vidensdeling en vigtig del af høj modenhed i forhold til IM. Her kunne det være relevant at undersøge nærmere om der ved hjælp at SOA og MDM kan udvikles nye metoder til at gøre viden og ikke bare data og information tilgængelig i sine systemer. Der findes blandt andet inden for Knowledge Management teorier for hvordan man kan indsamle viden og gøre viden tilgængelig. Det kunne i denne forbindelse være interessant at undersøge om håndteringen af viden kan tænkes med ind i processerne når man arbejder med EA- og IM-modenhed. 46

49 9. Litteraturliste Agosta, Lou (2006, 17. august). Mastering Master Data Management. DM Direct Special Report 2006 Issue, DMReview. Gøtze, John (2007a, 16. Marts). SOA s missing link: Forretningen. Version2. Gøtze, John (2007b). SOA. Undervisningsnoter uge 7. Enterprise Arkitektur. IT-Universitet. Herzum, Peter (2003). Applying Enterprise Architecture. Enterprise Architecture Vol. 6, No. 3, Cutter Consortium. Kalogirou, John (2007, 29. april). Master Data Management Meets SOA a symbiotic relationship. SOA World Magazines. Kann, Anders, Borum Poulsen, Claus & Albertsen, Martin (2007). Enterprise Arkitektur i gymnasieregi fra amts- til selveje. IT-Universitetet. Kimball, Ralph, et. al. (1998). The Data Warehouse Lifecycle Toolkit. John Wiley & Sons Inc. Platon (2007a). Introduction to Business Intelligence. Undervisningsslides fra kurset, Business Intelligence, IT-Universitetet. Platon (2007b). Data Warehouse architecture. Undervisningsslides fra kurset, Business Intelligence, IT-Universitetet. Ross, Jeanne W (2003). Creating a Strategic IT Architecture Competency: Learning in Stages. MIT Sloan School of Management. 47

50 SAS White Paper (2005). Five steps to Evolving into an Intelligent, High-Performance Enterprise. SAS9, SAS Institute Inc. Schmelzer, Ronald & Bloomberg, Jason (2006). Service orient or Be Doomed!. John Wiley & Sons Inc. 48

51 Bilag 1: Den oprindelige problemformulering: Overordnet er det vi vil se på hvordan koblingen er mellem Business Intelligence (BI) og Enterprise Architecture (EA), og konkret vil vi besvare følgende spørgsmål: 1. Kan man implementere en komplet EA uden at have god BI? Hvad med omvendt? 2. Hvor skal man starte - med at opbygge en god BI og så EA? Eller omvendt? 49