Koblingen mellem Enterprise Arkitektur og Business Intelligence

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

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.

Indholdsfortegnelse 1. Indledning... 3 1.1 Problemformulering... 4 1.2 Afgrænsning... 5 2. Metode... 6 2.1 Kildekritik... 6 3. Enterprise Arkitektur-modenhed... 8 3.1 Generelt om Enterprise-arkitektur... 8 3.2 EA modenhed... 8 3.2.1 Herzums modenhedsmodel... 9 3.2.2 Ross s modenhedsmodel... 12 3.2.3 Hvad er EA-modenhed?... 14 3.3 Delkonklusion... 16 4. Information Management-modenhed... 17 4.1 Business Intelligence... 17 4.2 Data management... 19 4.3 Information Management... 20 4.4 IM-modenhed... 21 4.4.1 Kimball readiness... 22 4.4.2 SAS White Paper om IM-modenhed... 24 4.4.3 Hvad er IM-modenhed?... 28 4.5 Delkonklusion... 29 5. Fælles referenceramme for EA og IM... 31 5.1 Delkonklusion... 33 6. Synergieffekter mellem EA og IM... 34 1

6.1 Service orienteret arkitektur... 35 6.2 Master Data Management... 37 6.3 SOA møder MDM... 38 6.4 EA/IM modning og SOA-distribuerede masterdata... 40 6.5 Delkonklusion... 42 7. Konklusion... 44 8. Perspektivering... 46 9. Litteraturliste... 47 Bilag 1: Den oprindelige problemformulering:... 49 2

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

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

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

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

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

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, 2007 8

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

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

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. 13 11

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 6. 3.2.2 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. 25 12

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

ring, som kendetegner første fase. Den agile virksomhed er dermed det øverste modenhedstrin i Ross s modenhedsmodel. 3.2.3 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

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

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

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

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