Time: 28-29 september

Place: Sørup Herregård

The seminar will address the issues of defining and implementing a coherent and optimized architecture in today’s public and private enterprises. It is NOT a beginner’s course – the event is designed to challenge and train seasoned professionals to become best-in-class enterprise developers. Read more here.

Finansministeriets IT udredning om statslige it-projekter

OECD rapporten:
Denmark – efficient e-government for smarter public service delivery

Teknologirådets rapport: Bedre styring af offentlig it

Mens Finansministeriets rapport sætter fokus på en professionalisering af arbejdet med IT projekter, har OECD rapporten et mere strategisk sigte, og anbefaler en samlende strategisk vision for digitaliseringen. Det sidste skud på stammen kommer fra en arbejdsgruppe under Teknologirådet, som anbefaler at se nøjere på de rammebetingelser og styringsmekanismer, der skal få strategi og gennemførelse til at hænge sammen.

Arbejdsgruppens efterlyser en holdningsændring på fire væsentlige punkter.

1. Et skift væk fra det ensidige fokus på kontrol, til mere vægt på dialog og innovation.
2. En central beslutningskompetence, som tager ansvar for en samlende strategisk vision.
3. En ny bevillingspraksis, som fremmer samarbejde på tværs.
4. Større satsning på forandring med kalkuleret risiko.

Teknologirådets rapport er resultatet af et projekt, som EA Fellows foreslog allerede i 2006: Vi pegede på, at styringsmodellerne for tværoffentlige teknologiprojekter må forbedres, hvis vi ønsker flere succesfulde digitaliseringsprojekter. Som deltager i arbejdsgruppen er vi helt enige i, at det er på tide at sætte fokus på den overordnede styring af Danmarks IT anvendelse.

Som led i projektet afholdt Teknologirådet en Workshop, hvor arbejdsgruppen drøftede både problemer og perspektiver med en række inviterede eksperter og en bred gruppe af interessenter. Dagen bød på mange gode indlæg og en livlig debat, som kan opleves som podcast på Teknologirådets hjemmeside.

Rapportens anbefalinger er delt op i tre temaer: Rammevilkår, strategi og styring. Under disse overskrifter sætter arbejdsgruppen fokus på de egentlige grunde til at så mange offentlige IT satsninger ryger i hegnet. Her er et uddrag af rapportens anbefalinger, som de fleste enterprise arkitekter vil nikke genkendende til:

Detaljerede kravspecifikationer hjælper ikke kunden til at reducere risikoen, men øger derimod omkostningerne, både til rådgivere og leverandør. Det ville være bedre, hvis kræfterne blev brugt til en mere omhyggelig analyse af behovet og planlægning af hvordan det bedst muligt kan opfyldes.

Manglende dialog mellem kunde og leverandør er et af de centrale problemer ved den nuværende udbudsform. Konkurrencestyrelsens fortolkning af EU’s udbudsregler har en klar negativ indflydelse på kvaliteten af offentlige IT-projekter. Arbejdsgruppen peger på alternative udbudsformer, hvor muligheden for en løbende dialog er til stede.

Strategisk fokus mangler i mange offentlige forandringsprojekter – planlæggerne glemmer at indregne de samfundsmæssige effekter, der skal opnås, og koncentrerer sig i stedet om de rene IT omkostninger. Vi bør lægge større vægt på projekternes forretningsmæssige værdi, og de offentlige bevillingssystemer skal justeres, så de understøtter dette.

Høste – så problematikken: Det er ofte anført som en barriere i IT-projekter, at gevinsten ligger et andet sted end hos dem, som leder og bekoster projektet. Den samme form for barriere optræder, når projektets fordele først indtræffer langt ude i fremtiden, så de nuværende beslutningstagere ikke kan få del i gevinsten.

Tværgående nytænkning har svære kår - vi oplever stadig, at mange offentlige problemer forsøges løst med et ”IT-system”, der skal kontrollere pengeforbruget. I stedet burde man beskæftige sig med at løse de underliggende problemstillinger og processer – især når de går på tværs af flere ressortområder.

Ambitionsniveauet er for lavt -  planlæggerne går med museskridt i digitaliseringen, og tænker for lidt i radikale forandringsprojekter, hvor man gennemfører grundlæggende ændringer i forretning og arbejdsprocesser. På denne måde kunne vi få store produktivitetsgevinster, specielt når det drejer sig om tværgående samarbejder. Men det kræver, at der bruges flere kræfter på planlægning og risikostyring.

En business case skal være et styringsgrundlag og ikke et bevillingsinstrument. Business casen skal gennem hele projektet bruges som et fleksibelt redskab med ajourføringer og justeringer, så fokus på mål og resultater fastholdes. Samtidig skal business casen også tage højde for og behandle ideer, som opstår i projektforløbet.

Kunden skal erkende og håndtere risici ved projektets start. Offentlige IT-projekter indeholder mange risikofaktorer. Arbejdsgruppen peger på to af de vigtigste: Projektets radikalitet og kundens modenhed. Desuden bør store, risikable IT-projekter først testes f.eks. i begrænsede lokationer eller brugergrupper.

Vi savner en overordnet arkitektur for digitaliseringen, som giver plads til en høj grad af decentralisering, det vil sige med fokus på interfaces og standarder, som gør det muligt for de forskellige domæner at udveksle data, og udvikle kompatible og sammenhængende løsninger. 

Brugen af standarder er en afgørende faktor. Det skal være et krav i forbindelse med investeringer i både løsninger og  infrastruktur, at der tages udgangspunkt i veletablerede standarder, som er bredt understøttet. Det er således ikke mængden af nye standarder, der er afgørende, men værdien som kan skabes i samfundet ved at opnå kompatibilitet mellem de offentlige IT-løsninger.

Beslutnings tomrum

Rapportens vigtigste konklusion er nok, at en række vigtige beslutninger om digitaliseringen stadig svæver i luften, og at vi savner embedsmænd og politikere, der tør tage dem. De offentlige IT-projekter lider under manglen på et strategisk bindeled mellem de overordnede politiske målsætninger og det taktiske niveau i regioner og kommuner. Tværgående og meget omfangsrige domæner som sundhed og erhverv er blandt de mest oplagte eksempler på de ”nye siloer” i digitaliseringen af den offentlige sektor. Manglen på overordnede beslutninger for hele den offentlige sektor får domænerne til at definere lokale principper, med følgelig suboptimering og etablering af nye barrierer for tværgående initiativer..

Et eksempel på en af de beslutninger, som mangler, er en plan for hvilke løsninger og it-services, der skal etableres i fællesoffentligt regi (som fx Navision Stat), og hvilke løsninger der skal bygges decentralt, i statslige, regionale og kommunale organisationer, eller servicefællesskaber. Uden en sådan plan er der overhængende risiko for, at de decentrale organisationer disponerer deres ressourcer uhensigtsmæssigt, og etablerer løsninger, der ikke fungerer ordentligt sammen.

En fælles digitaliseringsramme

Arbejdsgruppen peger på, at der er behov for et nyt strategisk niveau for styring af den offentlige IT anvendelse – placeret mellem den nationale strategi og de forskellige domæner i den offentlige forvaltning. Digitaliseringsrammen, som niveauet kaldes, skal samle alle de fælles beslutninger, som udstikker kursen med strategiske retningslinjer og dermed sikrer større ensartethed projekterne imellem og modvirker suboptimering. Digitaliseringsrammen kan f.eks. indeholde fælles arkitekturprincipper, governancemodel, udbudspraksis, standarder, metoder og business cases. Digitaliseringsrammen bør være forankret i en central beslutningskompetence, der kan tænke horisontalt i koordinering og konsolidering.

Udfordringen ved at etablere en overordnet arkitektur er at skabe interoperabilitet mellem de forskellige løsninger uden at hæmme eller begrænse de velfungerende, lokalt forankrede arkitekturer. Derfor er det afgørende at den fælles digitaliseringsramme indeholder netop de nødvendige og tilstrækkelige elementer til at sikre en koordineret digitalisering af den danske forvaltning.

Læs mere om rapporten i Teknologirådets nyhedsbrev Fra Rådet til Tinget.

Forretningsudvikling med IT

Hvis vi skal sikre et positivt afkast af IT investeringerne, har vi brug for en overordnet styring af IT-anvendelsen, som sammenkæder processerne for strategi, arkitektur og programledelse, og skaber værdi i forretningen. Det handler om forretningsudvikling med IT, ikke om IT-udvikling.

Når man leder og udvikler en moderne virksomhed, er man afhængig af IT hver dag. Men ofte giver IT anvendelsen ikke de ønskede resultater, fordi afgørende forudsætninger ikke holder, eller uforudsete komplikationer støder til.

Det kan være udfordrende at styre virksomhedens IT anvendelse, fordi sammenhængen mellem ny teknologi og forretningsmæssige fordele er svær at gennemskue og kontrollere.

Fokus på strategi

IT investeringerne skal optimeres – både med hensyn til rentabilitet og risiko. Vi ønsker at komme fra usikker satsning til forudsigeligt resultat gennem anvendelse af

• Strategisk planlægning
• Styring og kontrol

Begge disse elementer skal bidrage til succesen, men hidtil har man i de fleste virksomheder – ikke mindst i den offentlige sektor – lagt mere vægt på styring og kontrol end på planlægningen: I mange år har vi brugt kræfter på at blive bedre til at gennemføre IT-projekter, og sikre at forløbet og leverancerne fulgte den afstukne plan. Den strategiske planlægning har kun i mindre grad været genstand for en systematisk indsats, og sammenhængen mellem indsatser og resultater har derfor været svær at opnå.

Bedre metoder

Ligesom man har forbedret projektgennemførelsen med rammer og metoder som PRINCE2 og ITIL, kan man opnå langt bedre resultater i den strategiske planlægning ved at benytte systematiske metoder i arbejdet med strategi, arkitektur og programledelse.

Strategien skal være en konkret udmøntning af de politiske og forretningsmæssige mål, og en række beslutninger om, hvorledes man vil nå dem. For at sikre at strategien er realistisk og gennemførlig, er det nødvendigt at gennemføre en række analyser og beregninger, der kan understøtte strategiens beslutninger og anvise hvilke forholdsregler der skal tages, for at sikre strategiens  gennemførelse. Vi taler fx om risikoanalyse, konsekvensanalyse og cost-benefit vurdering.

Arkitekturen skal forklare, hvorledes strategien føres ud i livet. Vi beskriver, hvilke ændringer og nyskabelser der skal indføres i forretningsmodeller, arbejdsgange, informationer og IT-løsninger. Arkitekturens vigtigste formål er at beskrive sammenhængen mellem disse elementer, i form af en ubrudt kæde fra de overordnede mål til alle de beslutninger der skal tages omkring design og implementering. Kæden giver os sikkerhed for, at  alle beslutninger er koordineret i forhold til de overordnede mål, og at alle de nødvendige forudsætninger er opfyldt, for at målene bliver opfyldt. For at udarbejde en fyldestgørende arkitektur, er det nødvendigt at have adgang til både strategien og detaljerede informationer om udgangssituationen. Men derudover har vi også brug for en systematisk metode til at organisere arkitekturarbejdet.

Programledelsen omfatter den overordnede tilrettelæggelse af de ændringer og tiltag som arkitekturen har udpeget som nødvendige for at opnå de opstillede mål. Oftest vil programmet bestå af et antal projekter, som indbyrdes skal prioriteres og koordineres. Også her er det vigtigt at benytte rammer og metoder, som understøtter en løbende optimering af hele projektporteføljen. Det kan fx handle om overholdelsen af fælles arkitekturkrav eller samordning af flere projekter med henblik på at opnå den optimale effekt.

Sammenhæng

De fleste virksomheder anerkender behovet for at skabe sammenhæng mellem forretning og IT. Det betyder i praksis, at beslutningsprocesser og organisatoriske strukturer er gearet til at tage balancerede strategiske beslutninger på en hurtig og sikker måde. Men det betyder også, at forretning og IT råder over et fælles sprog , så de spiller godt sammen, når IT anvendelsen skal tilrettelægges og styres.

Vi anbefaler at etablere en strategi- og arkitekturpraksis, som sammenkæder IT investeringerne med de strategiske mål, og giver sikkerhed for, at IT anvendelsen kan levere de projekterede forretningsmæssige resultater. Det er oplagt at benytte anerkendte metoder og rammeværker i processen, for at få et effektivt samarbejde på tværs i organisationen, og hurtigt opnå operationelle fordele.

 Læs mere her: Management seminar om Strategisk IT anvendelse

Dels kommer Jan Staack, EA Senior Manager hos Carlsberg IT, og fortæller om hvordan Carlsberg arbejder med EA og om de styringsmæssige udfordringer. Og dels kommer tre unge forskere, som har arbejdet med Carlsberg det seneste halve år, og giver deres perspektiv på sammenhængsledelse i Carlsberg, og generelt.

Chris is challenging the traditional thinking: No more talk about aligning business and IT – the technology budget must be embedded in the total budget for developing the company and it’s products.

The participants of the EAlumni meeting, mostly enterprise architects, were thrilled to learn about the new game, where EA is moving out of the IT department, and the keywords are innovation, passion and power. Hear more from an inspired participant.

Later in the same week, Chris presented a ‘Scandinavian flavoured’ version of his award-winning 2-day seminar Corporate Strategy for IT , for a small VIP audience.

Based on The fruITion Strategy^® , the delegates were guided on a journey through four generations of Corporate Strategy for IT: Each generation of strategy involves a change in focus and the primary role of the CIO’s team.

During two intensive days, the participants adopted a corporate strategist’s view of IT investments, rather than the technologist’s viewpoint, and experienced new and practical perspectives on how best to turn yesterday’s efficiency based strategies into today’s exploitation led ones. Read the insights and perspectives by one of the delegates.

• Fundamentals of Enterprise Architecture, 25.-28. maj 2010
• Applied Enterprise Architecture Concepts, 16.-19. august 2010
• Advanced Enterprise Architecture Concepts21.-24. september, 2010

Hent brochure (PDF) eller kontakt John på 5124 5878 for yderligere info.

Chris Potts er anerkendt som en af verdens skarpeste, når det gælder forretningsudvikling med IT. Han giver internationale topledere et nyt perspektiv på IT anvendelsen i deres virksomhed, med sit prisvindende executive seminar

Corporate Strategy for IT

How to turn business leaders into experts at exploiting technology

Vores verden er forandret. Forbrugerne, kunderne og samarbejdspartnerne er bedre end nogensinde til at udnytte teknologierne til egen fordel. Men mange virksomhedsledere tænker på IT som en omkostning, i stedet for at bruge teknologien som et værktøj til at udnytte markedets muligheder.

Dette seminar giver deltagerne værktøjer til at udvikle forretningen med systematisk innovation, og demonstrerer hvordan strategiske IT investeringer giver forretningsmæssigt udbytte. Chris vil guide os til at tage det næste trin fremad mod forretningens optimale udnyttelse af teknologien.

Seminaret indeholder ingen tekniske anbefalinger – det handler udelukkende om management. Deltagerne får konkrete værktøjer til at håndtere forandring, mennesker, investeringer, omkostninger og forretningsmæssige beslutninger, så virksomhedens resultater optimeres.

Mange tidligere deltagere har oplevet, at dette seminar har givet dem en helt ny opfattelse af, hvad Strategi betyder. Når man ser verden med strategens briller, i stedet for den tekniske eksperts, er det nemmere at se hvilke praktiske tiltag der har størst effekt.

Chris Potts benytter sine personlige erfaringer fra førende virksomheder over hele verden til at forklare, hvilke metoder, der virker, og hvilke man bør undgå. Seminaret indeholder cases, baseret på konkrete virksomheder, og anbefalinger som direkte kan overføres til deltagernes hverdag.

Om Chris Potts

Chris er forfatteren til ‘FruITion: Creating the Ultimate Corporate Strategy for Information Technology‘. Han har mere end 20 års personlig erfaring med styring af strategi, investeringer og arkitektur i verdens førende virksomheder.

Tilmelding

Seminaret afholdes den 21 – 22 januar 2010 i den historiske Admiral Gjeddes Gaard.

Download brochuren for yderligere oplysninger om dette unikke arrangement.

Kontakt allan (Email address: allan #snabel-a# eafellows.com) eller ring 20 81 89 40 for information og tilmelding.

EA Fellows har tidligere sat fokus på dokument standarderne i et høringssvar. Det blev fulgt op med en omtale af alle indkomne kommentarer.

I dette indlæg uddyber vi det første af vore kommentarpunkter, og bringer en lille vejledning, som fx kan bruges til at prioritere standardiseringsprojektets aktiviteter.

Hvad er formålet?

Hvad er det overordnede formål med standardiseringsinitiativet, har vi tidligere spurgt. Det er ikke så let at blive klog på, for der er ikke formuleret et operationel strategi for standardiseringsprojektet. Men læser man referencearkitekturen, og de enkelte specifikationers formål, kan man fornemme, at OIO udvalget for sags- og dokumentområdet har en vision om en mangfoldighed af systemer i den offentlige forvaltning, hvor alle systemer kan bytte roller og tilbyde funktionalitet til hinanden på kryds og tværs. Nøglen hertil er, at alle systemer har fået “monteret” et OIO-standardiseret interface.

Når alle systemer er “plug-and-play”, vil markedskræfterne råde, og hver myndighed kan vælge frit på alle hylder, når det gælder esdh- og fagapplikationer. OIO udvalgets vision synes at være, at en omfattende standardisering kan eliminere behovet for en systemarkitektur, både hos myndigheder og leverandører. Men det er nok et spørgsmål, om den standardiseringsstrategi passer lige så godt på den offentlige sagsbehandling, som den passer på et usb-stik.

Det kan undre, at IT og Telestyrelsen med sit standardiseringsarbejde søger at fremme en strategi, hvor funktionerne kan fordeles ad libitum på mange små systemer, mens Finansministeriet med Statens IT arbejder i den modsatte retning, frem mod en konsolidering af de offentlige kernefunktioner, for at hente stordriftsfordele.

Hvis de to initiativer var koordinerede, ville man kunne hente betydelige gevinster til det offentlige, fx ved at Statens IT tilbyder fælles services til sags- og dokumenthåndtering, og ITST definerer for myndigheder og leverandører, hvordan de skal anvendes. Både Statens IT og Finansministeriet er repræsenterede i OIO udvalget, så man har da lov til at håbe, at de selv vil få denne ide. Og den må meget gerne komme, inden leverandørerne tvinges til at implementere en masse funktioner og grænseflader, som kun et fåtal har brug for.

Hvad er det værd?

Hvis vi skal beskrive, hvordan en standardisering af ESDH-grænsefladerne kan skabe værdi i samfundet, vil det være naturligt at bruge klassiske metoder fra EA værktøjskassen: Vi starter med at se på de forvaltningsprocesser, der kan optimeres, og følger derefter sporet til IT løsningerne. Undervejs kan vi optimere de strategiske beslutninger omkring standardiseringens omfang, forløb osv., og hente vigtige input til at opstille en business case for standardiseringsprojektet. Vi kan fx starte med 5 simple spørgsmål som disse:

1. I hvilke scenarier kan standardisering gøre en positiv forskel?

Lad os få sat fingeren på konkrete offentlige opgaver, hvor arbejdsgangen kan lettes, når de underliggende IT løsninger bringes til at spille bedre sammen. Og på de situationer, hvor kørende systemer skal konsolideres, fx i Staten eller i kommunerne.

2. Hvilken konkret værdi vil standardiserede grænseflader bidrage med?

For de valgte scenarier ser vi nu på, i hvilken grad en standardisering af grænsefladen kan skabe værdi. Det kunne være besparelser ved at undgå genindtastning af data, eller bedre muligheder for at finde og sammenstille oplysninger på tværs af flere systemer. Husk , at alle værdielementer skal opgøres i en fælles valuta, DKK.

3. Hvilke investeringer og indsatser skal ydes for at opnå fordelene?

For at standardiseringen kan få den ønskede effekt, skal den jo også implementeres, både teknisk og organisatorisk. Hvad koster det, for myndighederne, for leverandørerne, for borgerne? Og hvordan skal de forskellige parter motiveres til at investere.

4. Hvilke forudsætninger skal være opfyldt for at gevinsten kan høstes?

En række konkrete faktorer skal være på plads for at sikre standardernes effekt, fx bagud-kompatibilitet, certificering af løsninger, implementering i fællesoffentlige registre, finansieringsmodeller, markedsforhold og meget mere. Vurderingen af disse faktorer bør omfatte både omkostninger og risiko.

5. Findes der alternative initiativer, som kunne give en tilsvarende eller større værdi?

Før standardiseringsprojektet iværksættes, skal vi lige sikre os, at den valgte strategi også er den bedste. Det kunne jo tænkes, at en stor del af værdien hidrører fra en lille delmængde af projektet – så man med fordel kunne reducere scopet. Det kunne også være, at eksisterende standarder var bedre end de nye fra ITST? Eller måske kan fordelene bedre nås gennem konsolidering af systemer, i stedet for standardisering?

Disse grundlæggende spørgsmål bør stilles og vurderes omhyggeligt, før man formulerer en strategi for standardiseringen af sags- og dokumentområdet, som jo er en vigtig del af den offentlige administration. Vi kan kun anbefale, at IT- og Telestyrelsen giver de strategiske spørgsmål en høj prioritet.

Desuden bringer efteråret en ny udgave af næste-generations EA-kurset Coherency Management – Architecting the Enterprise, som udbydes sammen med Dansk IT. Dette kursus har et stærkt forretningsorienteret sigte. Kursusmaterialet er udviklet i samarbejde med eksperter i Canada, Singapore og USA. Målgruppen er erfarne arkitekter og CIOer.

Vil du udbygge din erfaring med den rigtige kombination af teori , cases, udfordringer, værktøj, eller søger du en certificering? Så kan du sammenligne alle vore kursustilbud på uddannelsesoversigten.

En god strategi kan indeholde et sæt rammebetingelser, som skaber en platform for udviklingen, i stedet for at foreskrive, hvordan alle opgaver skal løses.

Enterprise arkitektur er en strategisk disciplin, der organiserer løsningens elementer, og sikrer at de spiller sammen om at opfylde de ønskede mål. Og det er jo netop hvad vi har brug for, når nye produkter og tjenester skal udvikles.

Hvis strategi og arkitektur formuleres som overordnede principper, bliver de værdifulde redskaber for den kreative opfinder. Her skal vi se på, hvorledes enterprise arkitekturen kan bruges i innovationens tjeneste.

Hvordan får man en god ide?

De fleste forbinder innovation med nye ideer og opfindelser, som pludselig opstår, når man mindst venter det, fx under en spadseretur i naturen eller mens man tager brusebad. Hvad er den bedste måde at få gode ideer på? Mange mener at omgivelserne er vigtige: Hvis man bevæger sig væk fra dagens rutineopgaver, kan man åbne for inspirationen, og nye indtryk kan give konkrete ideer til nye produkter og tjenester. Men det er meget individuelt, hvad der skal til for at fremme de gode ideer: Mange opfindere er faktisk mest kreative, mens de er i gang med at lave noget helt andet.

De fleste opfindelser starter med opdagelsen af et nyt behov – eller en ny måde at opfylde et gammelkendt behov på. Kravet er, at opfindelsen skal skabe værdi: Man skal kunne se, hvad der kan gøres bedre – eller man skal finde nye forretningsmodeller, der kan skabe et økonomisk potentiale.

Her kan man med fordel benytte begreber og koncepter som findes i EA værktøjskassen: Vi anbefaler ikke at følge en bestemt arkitekturmetode slavisk, men at plukke de relevante elementer efter behov. Fx kan man tage udgangspunkt i den proces, som man ønsker at forbedre, og gennemgå dens deltagere og interessenter, se på deres motiver og spørge, hvorledes processen skaber værdi. Så vil man ofte finde alternative måder at gøre tingene på, eller kunne se et oplagt behov for en opfindelse, der kan hjælpe i processen.

Gode enterprise arkitekter stiller ofte spørgsmålet “hvorfor”, når de skal sikre sammenhængen mellem en løsning, og det behov, den skal dække. Denne nysgerrighed er et af de vigtigste redskaber for opfinderen (og forskeren) , der ønsker at udvikle sine ideer.

Hvordan fører man ideen ud i livet?

Innovation kræver en balance mellem spontanitet og systematik. De vilde ideer skal parres med erfaring og sund fornuft, herunder en afvejning af ideernes værdi og en analyse af hvorledes de kan realiseres på den mest optimale måde. Til disse vurderinger, som gennemføres i de første faser af opfindelsens tilblivelsesproces, er det relevant at inddrage erfaringer med produkter, som er sammenlignelige med den nye ide – eller som bliver dens konkurrenter i fremtiden. Vurderingen kan iscenesættes som en systematisk proces, hvor man bruger klassiske metoder fra EA værktøjskassen. Det betyder fx, at man beregner, hvorledes opfindelsen kan skabe værdi for kunderne, og optimerer dens opbygning herefter. På denne måde kan man sikre at opfindelsen vil stå så stærkt i konkurrencen, at den automatisk bliver det foretrukne produkt for kunder, der har de samme værdibegreber.

En systematisk vurdering på dette tidspunkt kan med stor nøjagtighed beskrive opfindelsens potentiale, og med stor sandsynlighed eliminere de betydelige risici, der ligger i et fejlskøn. Det er som bekendt de fejltagelser, der begås i projektets første faser, der ender med at blive de dyreste.

At realisere en opfindelse kræver dog meget mere end en god og holdbar ide. Her kommer vi til det, der traditionelt kaldes “transpirationsfasen”, som indeholder en masse hårdt arbejde. Der skal endeløse forsøg , vurderinger og sammenligninger af alternative modeller til, for at finde den bedste løsning til at opfylde et konstateret behov. For hver ny løsningskomponent, for hver ny funktion og for hver ny egenskab i løsningen er det vigtigt at relatere den – dels til de kommende kunders behov og præferencer , og dels til de tidsmæssige og økonomiske konsekvenser, det vil have for projektet. Det er en klassisk EA disciplin.

Et vigtigt aspekt i design af løsningen er at identificere de komponenter, koncepter, metoder etc, som gør løsningen unik, og som kan beskyttes mod kopiering gennem hemmeligholdelse, patentering eller andre former for rettighedsbeskyttelse. Den samlede løsningsarkitektur bør udformes sådan, at de overordnede fordele ikke kan opnås af en kunde eller konkurrent, der ikke har adgang til de centrale komponenter.

Især i denne fase er det vigtigt at stille spørgsmålet “hvorfor” gentagne gange. For hvis løsningen ikke er optimeret benhårdt mod det behov, den skal opfylde, er det helt sikkert at dens liv vil blive kort. Det skal den globale konkurrence nok sørge for.

Hvordan sikrer man det forretningsmæssige resultat?

Når en ny ide (eller en forbedret gammel ide) skal omsættes til fordele og økonomisk værdi, er det naturligt at gennemføre en interessentanalyse, hvor man kortlægger hvad opfindelsen kan gøre for alle, der er direkte berørt af opfindelsen, fx kunderne, der skal købe og bruge opfindelsen, producenterne, der skal omsætte ideen til fysiske eller logiske produkter og services, og ikke mindst for opfinderen og eventuelle andre rettighedshavere. Denne analyse bør være grundlaget for de forretningsmodeller, man vælger, og den tilhørende strategi for opfindelsens produktion og udbredelse.

Parallelt med udviklingen af én eller flere prototyper, skal vi i gang med at designe og producere det færdige, salgbare produkt. Afhængigt af opfindelsens art skal der gennemføres forskellige former for koncept- og produktudvikling, teknologiudvikling osv. I denne fase møder vi en stor risiko for, at det endelige produkt ikke vil kunne give de forventede resultater, på grund af forsinkelser, tekniske udfordringer -eller fordi produktet “rammer ved siden af” det markedsbehov, man søger at opfylde.

En referencearkitektur er det vigtigste redskab til at sikre en sammenhæng mellem ide, koncept og det færdige produkt. Ved at definere rammerne for produktudviklingen som arkitekturprincipper, kan en klassisk EA model sætte rammerne for udviklingen, uden at definere alle detaljer i forløb og design. Det betyder blandt andet, at vi har frihed til at vælge udviklingsmetode og -værktøjer efter opgaven (fx Agile) , og at vi har fleksibilitet til at vælge eksterne underleverancer (sourcing) for at optimere planlægningen. Arkitekturprincipperne vil gennem hele forløbet sikre en velbegrundet sammenhæng mellem de strategiske pejlemærker og den praktiske implementering. På denne måde reducerer vi risikoen for at produktet flopper, og samtidig finder vi den billigst mulige løsning, der kan levere den projekterede værdi til kunderne, producenterne – og til opfinderen selv.

Innovation overalt

Det er ikke kun i små, teknologiske opstartsvirksomheder, at der er behov for en målrettet udvikling af nye ideer og en transformation fra koncepter til produkter. Også store, veletablerede firmaer møder hele tiden nye konkurrenter og nye markedstrends, som tvinger dem til at skrue op for innovationstakten. I den offentlige sektor er der ligeledes brug for fornyelse – her bruges ordet “modernisering” om den stærkt efterspurgte udvikling af nye elektroniske servicetilbud.

I alle situationer er det vigtigt at huske, at ny teknologi sjældent giver fordele alene: Der skal arbejdes med processer, data og IT-funktioner under én hat – og ikke sjældent skal de overordnede mål og regler tages op til revision, for at man kan skabe konkret værdi. Det er her, enterprise arkitekten er en nyttig rådgiver og hjælper for den innovation, virksomheden skal leve af i fremtiden.

Denne artikel er først publiceret på www.zebranet.dk af Allan Bo Rasmussen.

De indkomne høringssvar er nu publiceret her. Der er grund til at bemærke høringssvaret fra Region Midtjylland, som stiller spørgsmålstegn ved både Referencearkitekturen for sags- og dokumentområdet og ved selve standardiseringsprojektet. I høringssvaret underbygges kritikken med erfaringer fra en lang række offentlige myndigheders IT-implementering. Tankevækkende læsning!

En anden kættersk tanke er for nylig blevet luftet af Ole Bech på version2. Her debatteres, om vi overhovedet har brug for de store forkromede ESDH systemer i den offentlige forvaltning, eller vi ville være bedre tjent med at rive siloerne ned og lade informationen følge opgaverne.

Måske er det tid at genoverveje standardiseringsprojektets scope, retning og ambitionsniveau i forhold til de overordnede succeskriterier. Erfaringerne viser, at vi kan skabe mere interoperabilitet og effektivitet i de offentlige IT-løsninger, hvis vi lægger vægt på en fælles enterprise arkitektur, end hvis vi standardiserer alle de tekniske detaljer.

Som nogen vil vide, var erfaringerne med FESD projektet noget blandede – et hovedformål var at skabe konvergens mellem markedets dokumenthåndteringssystemer, så de forskellige dele af forvaltningen kunne arbejde bedre sammen. Med IT- og Telestyrelsen i spidsen blev der standardiseret på livet løs -en lang række af systemernes funktioner og grænsesnit blev beskrevet i finurlige detaljer. Men i praksis var det så som så med kompatibiliteten – og med leverancernes kvalitet.

Nu spiller IT- og Telestyrelsen ud med et nyt sæt standarder. Denne gang er vi ikke begrænset til ESDH systemer, for standarderne skal også dække de mange fagsystemer der indeholder (eller benytter) ESDH funktionalitet. De nye standarder vil altså beskrive, hvorledes en meget stor del af systemerne i den offentlige forvaltning skal spille sammen.

På høringskonferencen var der flere deltagere, der var imponerede over dette meget høje ambitionsniveau. Vi var også nogle stykker, der var lidt bekymrede. For at hjælpe arbejdet lidt på vej, har EA Fellows skrevet en høringskommentar fra enterprise arkitektens synsvinkel.

Fra høringssvaret kan vi referere disse punkter:

1.      Forretningsmæssige begrundelser

En god arkitekturpraksis har til opgave at levere et velunderbygget beslutningsgrundlag for IT-investeringerne. Det betyder, at alle valg af løsningsmønstre og principper er begrundet i de opstillede mål, og at konsekvenserne er beskrevet, så det fx er muligt at opstille en business case for implementeringen af arkitekturen. Referencearkitekturen, som skal udgøre grundlaget for standardiseringen, har efter vor opfattelse ikke formidlet dette budskab klart nok. Dokumentet indeholder – i overensstemmelse med god praksis – afsnit om mål og visioner, forretningsservices og integrationsmønstre. Men disse afsnit er ikke systematisk kædet sammen, så man kan se begrundelsen for de trufne valg – og dokumentet indeholder i øvrigt ikke mange konkrete krav til arkitekturen. Således er de udmeldte principper henvist til et bilag, og er ikke relateret til hverken Referencearkitekturen eller Strategien for digital forvaltning. Vi anbefaler, at den næste version af referencearkitekturen udvikles til et mere komplet grundlag for ESDH udviklingen.

2.      Komplicerede grænseflader

Når målet er at opnå en bedre interoperabilitet, er det afgørende at der standardiseres på grænseflader i stedet for de indre strukturer, og de fremlagte specifikationer sigter da også i denne retning. Det er leverandørernes valg, i hvilken grad den indre struktur i databaser, programkode, etc. skal svare til det begrebsbillede, som de foreliggende specifikationer præsenterer. En gylden regel for standardisering af interfaces er imidlertid, at man kun skal medtage de parametre, der er nødvendige for at give forretningsmæssig værdi. Det er bekymrende, at specifikationerne ikke følger denne praksis, men i stedet lægger op til at eksponere en lang række interne parametre på grænsefladen. Erfaringerne fra en lang række cases viser, at den tilsigtede tætte integration ikke opnås ad denne vej, fx pga. manglende integritet i de udvekslede data. Desuden repræsenterer den tætte integration et brud på princippet om løs kobling, som det er udtrykt i referencearkitekturen. Vor anbefaling er at benytte de erfaringer, man fx har gjort i Norge, hvor overgangen fra NOARK-4 til NOARK-5 viser en tydelig flytning af fokus fra indre til ydre strukturer, og en simplificering af grænsefladerne, efter at man måtte konstatere at de komplicerede udvekslingsformater ikke gav de ønskede sammenhænge.

3.      Ambitionsniveauet

Både omfanget og antallet af de foreliggende specifikationer synes at være unødigt højt. Erfaringerne fra FESD1 viser tydeligt, at leverandørernes evne og vilje til levere et robust og kundetilpasset produkt vurderes højere af brugerne end muligheden for at få implementeret alle de fællesoffentlige standarder. Risikoen for at skabe et betydeligt gab mellem standarden og de konkrete implementeringer, bliver større jo mere der standardiseres. Vi kan derfor kun anbefale, at den obligatoriske standardisering holdes på et minimum, som kan give sammenhæng på udvalgte, centrale områder, og at de øvrige standarder bliver optioner, der kan tilvælges, hvis myndigheden har et forretningsmæssigt behov for en interoperabilitet, der går ud over der basale niveau. Hvis det høje ambitionsniveau fastholdes, er der risiko for, at myndighederne får en række specialudviklede (men stort set identiske) løsninger at vælge imellem, med dertil hørende negative virkninger for markedssituationen.

4.      Innovation

Flere steder i Referencearkitekturen understreges det, at IT udviklingen skal understøtte forandring i den offentlige forvaltning, og vi kunne ikke være mere enige. Men vi er samtidig bekymrede for, at den udbredte standardisering af arbejdsgange og løsninger på ESDH området vil begrænse moderniseringen af den offentlige sektor. Innovation handler primært om, at man tænker nye sammenhænge og nye processer, i stedet for at sætte strøm til de gammelkendte forvaltningsrutiner. En referencearkitektur der i vidt omfang bygger på eksisterende praksis, kan let komme til at modvirke nytænkningen. Vi kunne ønske os et større fokus på nytænkning og forenkling, og mindre vægt på automatisering af arbejdsgange, der allerede er komplicerede nok. En fremtidsorienteret arkitektur skal være udformet, så den kan understøtte nye og ændrede opgaver uden en større “ombygning”. Det betyder som regel, at arkitekturen skal være simpel og klart kommunikeret. Som et aktuelt eksempel kan nævnes, at en række forvaltningsmæssige opgaver i fremtiden forventes løst i et offentlig-privat partnerskab (OPP). Det ville derfor være hensigtsmæssigt hvis det offentliges ESDH systemer var gearet til at spille sammen typiske systemer i den private sektor, fx Customer Relation Management (CRM), Service Management etc.  En sådan fremsynethed kan opnås, hvis enterprise arkitekten spørger ind til begrundelsen for de udførte opgaver, og måden de udføres på. Det er her, innovationen starter og nye løsninger opstår. Modne organisationer har ofte succes med at orkestrere innovationen, fx ved at udskrive en konkurrence blandt medarbejdere eller belønne ledere der forenkler gammelkendte arbejdsgange eller udvikler nye services.

Læs de øvrige punkter om Privacy, Fællesoffentlig reference, Standardiseret infrastruktur, Scope, Roadmap og Governance her.

Enterprise arkitekturen giver virksomheden en række fordele, som alle rammer bundlinien – på kortere eller længere sigt. Hvis vi vil opstille en business case for EA programmet, som harmonerer med den traditionelle budgetstruktur, kan det være hensigtsmæssigt at opdele fordelene i to overordnede kategorier:

 Forretningsfordele

• Bedre opfyldelse af strategiske mål
• Forbedret forretningsmæssig performance

 IT-fordele

• Bedre IT understøttelse af forretningen
• Reducerede IT omkostninger

I de næste afsnit ser vi på, hvorledes en god EA praksis kan resultere i direkte besparelse, ekstra fortjeneste eller andre forretningsmæssige fordele som kan bogføres under disse overskrifter.

Bedre opfyldelse af strategiske mål

Især når virksomheden står over for betydelige forandringer, vil en velkørende arkitekturproces have stor værdi: Når den overordnede styring af virksomhedens projektportefølje baseres på vedtagne arkitekturprincipper, får vi sammenhæng mellem strategiske mål og de konkrete initiativer. I praksis bidrager EA til 

• at foretage en hurtig justering – på et sikkert grundlag – af projekter i forhold til ændrede succeskriterier eller nye begrænsninger, fx ved skiftende markedsforhold
• at opnå synergier mellem projekterne, fordi de bygger på fælles platforme, mønstre og kompetencer
• at udnytte eksisterende erfaring med kendte komponenter og processer i stedet for at eksperimentere med ukendte løsninger
• at standse eller afvise de projekter, som ikke understøtter de strategiske mål eller ikke er en god investering 

Forbedringer som disse kan som regel mærkes som besparelser på udviklingsbudgettet, men den største værdi kommer helt sikkert fra virksomhedens forbedrede evne til at kunne navigere sikkert gennem skiftende udfordringer og realisere det forretningsmæssige potentiale som strategien indeholder.

Forbedret forretningsmæssig performance

I den daglige drift er der brug for en systematisk visualisering og analyse af virksomhedens forretningsinitiativer, så man løbende kan følge op på resultaterne. En god arkitektur sikrer, at det forretningsmæssige udbytte af virksomhedens produkter og services kan sættes i relation til deres underliggende komponenter. Med denne indsigt kan man træffe hurtige og sikre beslutninger om hvilke ændringer der skal til i systemer og processer for at optimere de forretningsmæssige resultater. En god arkitektur giver fx mulighed for: 

• Eliminering af dublerede funktioner og løsninger, fx fakturering, CRM, mm
• Identifikation af flaskehalse og afhængigheder mellem systemer og processer
• Håndtering af forretningsmæssige muligheder og problemer tidligere i forløbet
• Nemmere projektstart ved brug af overordnede EA principper i projektbeskrivelsen
• Optimering af virksomhedens produktportefølje med konsoliderede erfaringer fra alle komponenter 

Når kravet er at skabe resultater på bundlinien, er det vigtigere end nogen sinde at resultaterne direkte kan henføres til de beslutninger der tages i den daglige drift, og at udbyttet løbende optimeres ved at anvende  de bedste løsninger, metoder og værktøjer.

Bedre IT understøttelse af forretningen

Effektiviteten af IT anvendelsen skal måles gennem de forretningsmæssige resultater. En af de vigtigste faktorer er her, hvor godt IT komponenterne leverer værdi i de forretningsmæssige arbejdsgange, og det er er netop dette forhold, enterprise arkitekturen står for at optimere. Med en god alignment (tilpasning) mellem forretning og IT opnår vi det største udbytte af IT-investeringerne. I virksomheder der har en god praksis for IT understøttelse, finder man disse positive virkninger: 

• Færre ændringer i de kørende systemer som følge af oversete eller ændrede behov
• Sikkert valg af komponenter der matcher veldefinerede operationelle krav
• Systemer med standardiserede grænseflader reducerer behovet for special udvikling af integrationer
• Hurtigere designcyklus for nye løsninger til forretningen ved genbrug af IT-komponenter
• Reduceret risiko for fejl og nedbrud ved brug af velkendte services og komponenter 

Den samlede effekt er ikke blot positiv i IT afdelingen, hvor man opnår hurtigere udviklingstid og færre rettelser. Forretningen oplever, at gevinsterne ved IT understøttelsen kan høstes tidligere, fordi IT-komponenter og arbejdsgange passer sammen fra starten. I tilgift får vi en større omstillingsevne (agilitet) for forretningsudviklingen, fordi udvikling og udbygning af modulære systemer er en langt hurtigere vej end “at starte fra bunden”, når et nyt forretningsprodukt skal understøttes med IT.

Reducerede IT omkostninger

En vigtig faktor i omkostningerne til udvikling og drift af IT løsninger er kompleksitetsgraden. Det er en velkendt sandhed, at organisationer som driver en portefølje af komplicerede IT løsninger, belastes af ekstra omkostninger, både til udvikling, drift og vedligehold, og har samtidig en forøget risiko for ustabilitet og nedbrud. Hvis man derimod satser på konsolidering af IT-infrastrukturen og udvikling af fælles standardiserede IT services, kan man opnå fordele på følgende punkter: 

• Reducerede udviklings- og test omkostninger ved at implementere fælles IT- komponenter
• Højere driftsstabilitet, og nemmere fejlretning med færre forskellige platforme
• Reducerede omkostninger til systemforvaltning, pga. af lavere kompleksitet
• Eliminerer behovet for vedligehold af dublerede data, systemer og services 

Når vi ser på de fordele, der kan hentes i IT driften, har en god arkitekturpraksis et stort potentiale. Men også i forbindelse med udvikling og opgradering, er der penge at hente, fordi en standardiseret infrastruktur, og faste principper for brug af standardsystemer og egenudviklede systemer, giver hurtigere implementering og mindre risiko. Her er de punkter, hvor en fælles arkitektur kan give fordele: 

• Konsolidering af platforme og værktøjer sparer omkostninger til drift og overvågning
• Standard mønstre giver hurtigere og nemmere opbygning af nye driftmiljøer
• Velstrukturerede platformskrav giver mulighed for selektiv outsourcing 

Både ved intern drift og ved outsourcing, bør en løbende forbedring af price/performance være en del af driftsaftalen. Det kan realiseres, hvis IT miljøet opbygges efter moderne arkitekturprincipper, hvor en stigende automatisering af driftsrutinerne er et af de overordnede principper for samarbejdet.

Sådan sikres gevinsten

Ved opstilling af business casen, skal potentialet for hvert punkt vurderes individuelt i den enkelte virksomhed. Som bekendt skal forbedringen altid måles ud fra det aktuelle niveau, og her kan en uvildig vurdering være til stor nytte. 

Ved realiseringen af de potentielle gevinster spiller det en stor rolle, at virksomheden tager hensigtsmæssige beslutninger gennem hele processen. EA er jo kun en metode til at tage gode strategiske valg – EA kan ikke garantere at virksomhedens ledelse omsætter anbefalingerne til action. Det er jo det, der skal til for at høste gevinsten. 

For at virksomheden kan styre hurtigt og sikkert, på et solidt, strategisk grundlag, skal beslutningsmekanismerne være velfungerende. God governance er karakteriseret ved, at de rigtige personer (interessenter) er involveret i beslutningsprocessen, og at de har et fælles værdisæt at arbejde ud fra. Når de får et solidt beslutningsgrundlag, som EA programmet kan levere, er det faktisk ikke så svært at tage rigtige og sikre beslutninger.

Workshoppen præsenterede Sammenhængsledelse som disciplin, og satte Enterprise Arkitektur i relation til ITIL, CobiT, CMMI og andre kendte rammeværker.

Med fokus på praktiske eksempler og afprøvede metoder kom vi hele kompasset rundt omkring brugen af EA som redskab til at skabe sammenhæng i organisationen.

Udover undervisere fra EA Fellows havde vi inviteret udvalgte ‘gæster i studiet’, som bidrog med deres konkrete erfaringer fra aktuelle cases. Fra England var det EA-eksperten Sally Bean, og her fra Danmark kom Diego Børresen Lladó fra Proces360, Hans Jayatissa fra CSC og Peter Helmer Sørensen fra NorthHouse Partners.

Nu er den gal igen

Finansminister Lars Løkke er netop citeret i Computerworld for at han “vil have styr på løbske it-projekter”. Udtalelsen er bl.a. foranlediget af Rigsrevisionens seneste rapport om styringen af 5 statslige digitaliseringsprojekter med udviklingsbudgetter på mellem 20 og 131 mio. kr. Denne rapport var knapt nok udkommet, da Computerworld præsenterede en anden undersøgelse af fire store statslige it-projekter, som viste endnu større budgetoverskridelser og forsinkelser.

Det kunne lyde som om historien gentager sig, men en nærlæsning af de seneste skandalerapporter viser faktisk at det offentlige er blevet bedre til at gennemføre projekterne. Det er i højere grad forudsætningerne og planlægningen, det kniber med. I beretningen fra Rigsrevisionen hedder det således, ”at beslutningsgrundlaget for de fem digitaliseringsprojekter, som revisionen har undersøgt, i flere tilfælde ikke var fyldestgørende”. Også Computerworlds gennemgang indeholder eksempler på projekter, hvor budgettet er eksploderet pga. af ”uforudsete ændringer i eksisterende systemer”.

Planlægningen mangler

De ustyrlige projektforløb er faktisk en naturlig konsekvens af mangelfuld planlægning. Som Rigsrevisionen påpeger, er mange af projekterne igangsat uden en fyldestgørende business case, som viser hvorledes projektets målsætninger konkretiseres og måles. Uden en sådan ”målepind” er både projektleder og styregruppe på herrens mark, når der skal tages store beslutninger i projektforløbet. Og der er en overhængende risiko for, at resultaterne ikke står mål med investeringerne i projektet.

For at skabe sammenhæng mellem det forretningsmæssige behov og løsningens egenskaber, benyttes i de fleste projekter en traditionel kravspecifikation. Som regel opstilles kravene dog længe efter, at budget og tidsplan er fastlagt, og det sker ofte, at specifikke, funktionelle krav nødvendiggør større strukturelle ændringer – eller valg af en ny teknologi. Sådanne overraskelser kan nemt få budgettet til at skride – eller gøre det nødvendigt at skære i de leverede resultater.

En bedre praksis

Vil man undgå skandaleramte digitaliseringsprojekter, må man sikre et solidt styringsgrundlag for det enkelte projekt. Finansministeriet tog i 2008 et vigtigt skridt i denne retning ved at gøre udarbejdelsen af en business case obligatorisk for projekter over 10 mio. kr. Men det er ikke nok at have de økonomiske rammer på plads. Man må også sikre sig, at de leverede resultater lever op til forventningerne. Hertil skal vi bruge en model der sammenkobler de overordnede målsætninger med løsningens konkrete egenskaber. Det hedder en enterprise arkitektur. Her opstilles rammerne for løsningen i principform, lige fra forretningsmodeller og arbejdsgange, til de tekniske systemer og platforme.

Arkitekturen er ikke en detaljeret specifikation, men en overordnet ramme for den løsning, der skal bygges. Den gør det muligt at definere projektet præcist mht. struktur og leverancer, og sikrer mod uforudsete vanskeligheder i løsningens samspil med eksisterende systemer.

Opfølgningen

For år tilbage havde det offentlige England problemer med at gennemføre moderniseringsprojekter, derfor udviklede den engelske Office of Government Commerce projektstyringsmetoden PRINCE2. Der var også problemer med IT drift og support, her blev resultatet ITIL. Begge disse metoder er i dag udbredt i hele verden, også i den danske offentlige sektor.

Danmarks Statistik udgiver hvert år en undersøgelse af den offentlige sektors brug af IT. Rapporten for 2008 er netop udkommet, og viser at 57 pct. af myndighederne nu bruger en projektmodel til styring og gennemførelse af digitaliseringsprojekter. De fleste af de myndigheder som har en projektmodel, bruger også en business case. Kun 23 % foretager dog en systematisk opfølgning på projektmålene.

Rigsrevisionen har nu sat fokus på omkostningerne ved de danske digitaliseringsprojekter, og finansministeren har udmeldt, at regeringen vil nedsætte en arbejdsgruppe, der skal se på, hvordan vi kan få bedre styr på de statslige IT-projekter. Vi er spændt på at se, hvilke tiltag ministeren vil iværksætte for at optimere de offentlige IT investeringer.

Vi er også rigtigt spændt på hvad Dorte Toft bringer på banen, nu hvor hun ovenpå IT Factory sagen har kastet sig over offentlige IT-indkøb.

Når den offentlige sektor skal arbejde bedre sammen, spiller teknologien en væsentlig rolle. Det gælder om at dele informationer og at samordne brugen af IT. I arkitektursammenhæng betyder det at rive siloerne ned og skabe en fælles infrastruktur, som fundament for forvaltningens fagsystemer.

Staten har taget et væsentligt initiativ i denne retning med dannelsen af den nye organisation Statens IT. Der er defineret et scope for Statens ITs opgaver men vi har endnu ikke et klart billede af, hvilken grad af harmonisering og konsolidering af systemer og infrastruktur, der er på tegnebrættet.

I mellemtiden har virksomheden Informi GIS givet et bud på, hvad den fælles infrastruktur bør indeholde. Geografisk information udgør en værdifuld fællesnævner i mange offentlige og private forretningsprocesser. Virksomheden illustrerer i et whitepaper Geografisk information i en enterprise arkitektur, hvorledes en geografisk tilgang kan fungere som løftestang for effektivisering, kvalitetsforbedring og styrket samarbejde i den offentlige sektor.

GIS systemer har traditionelt været betragtet som et fagsystem, som mest anvendes i tekniske forvaltninger til administration af veje, kloakker og byggetilladelser. Men ved at gøre de geografiske informationer tilgængelige som en infrastrukturservice, kan de bruges i mange andre sammenhænge, fx ved dynamisk styring af energi og offentlig transport. Det giver store perspektiver for tilrettelæggelsen af den offentlige service, og ikke mindst for samarbejdet mellem offentlige og private organisationer.

Vi venter spændt på at se, hvilke værdiskabende services der i fremtiden skal indgå i den fælles offentlige IT infrastruktur. GIS er et godt bud – hvem kommer med det næste?

Disclaimer: EA Fellows har bidraget med inspiration til publikationen fra Informi GIS.

Efter at have kørt programmet i over et år i Belgien og Holland sammen med Telelogic, har vi i EA Fellows ladet os akkreditere hos CMU til selv at kunne udbyde programmet. Ikke at vi har noget imod Telelogic – som nu er en del af IBM – men vi mener godt, at vi “kan selv”, og desuden vil vi – og CMU – gerne understrege, at programmet er leverandøruafhængigt.

Vi kører det første kursusforløb i november-januar, og der er stadig enkelte ledige pladser. Blandt allerede tilmeldte deltagere er en finansiel koncern, en statslig myndighed og et teleselskab.

Der er tale om tre intensive kurser à 4 dage. To eksamener undervejs. En lærebog, som forventes læst under forløbet. Kursusdokumentationen er omfattende. Fast underviser er John Gøtze, som trækker relevante gæsteforelæsere ind i forløbet.

Læs mere om CMU-kurserne her, samt ovre på enterprisearchitecture.dk. Eller hent vores nye brochure!

Billedet: Den ene af grupperne var så opslugt af den faglige diskussion (walk and talk), at de hverken ænsede den udendørs spa eller den fine udsigt

Kurset var også denne gang fuldt booket, men kommer helt sikkert igen. Se programmet her: SOAthon 24 hours og kontakt os for at høre om kommende arrangementer.

I vores andet blogindlæg om supertankere og optimistjoller langer vi lidt ud efter det offentlige arkitekturarbejde. Der er dog samtidig nogle rigtigt spændende initiativer på banen.

Arkitektur i FORM!

Årets bedste nyhed på arkitekturfronten i det offentlige Danmark mener vi er den fællesoffentlige forretningsreferencemodel FORM, der netop er blevet offentliggjort.

FORM er et redskab til at finde, analysere og udnytte moderniseringsmuligheder i den offentlige sektor, herunder specielt muligheder for fælles offentlig opgaveløsning og digitalisering.

FORM’s opgavekatalog er bygget op om de tre grundlæggende begreber: tjenester, opgaveområder og serviceområder. Et eksempel på et opgaveområde er ”Servicering af lovforberedelse”, der består af tjenester som administration af lovforslag og beslutningsforslag, gennemførelse af høring om lovforslag, udarbejdelse af betænkning, m.v.

FORM er udarbejdet af en ekspertgruppe med folk fra KL, IT- og Telestyrelsen, Økonomistyrelsen og Den Digitale Taskforce. Konsulenter på opgaven har været IBM, hvilket forklarer at FORM trækker heftigt på nogle af IBMs best practices. Den officielle forklaring er vist at man har ladet sig inspirere af nordamerikanske erfaringer fra bl.a. det føderale USA’s FEA-arbejde, men her har IBM også været konsulent, så hvordan man end vender den, så er der malet med blåt henover tingene.

Det med blåt består i, at man læner sig op af et af IBMs favoritakronymer, CBM, Component Business Model, som i al sin enkelthed blot handler om at ”udstille” hele forretningen på en side. Den offentlige forretning Danmark, der udtrykkes i FORM, fylder en A3-side (hvis den skal være læsbar). Andre forretninger passer nok ind på en A5-side, må man antage.

Det gode ved FORM er, at vi med den har et vigtigt redskab for udfoldelsen af en fællesoffentlig arkitektur. FORM giver overblikket over forretningen, og tilgangen kan bruges til at koble politik, strategi, forretning og teknologi – altså, skabe den altid-vigtige alignment.

Da Lars Frelle og Kristian Hjort-Madsen fremlagde FORM på aEAs gå-hjem-møde, talte de om at en af anvendelserne af FORM vil være at identificere områder, hvor der med fordel kan sættes ind med arbejdskraftbesparende teknologi. Altså skal FORM ultimativt bruges til at skrue på varme/kolde hænder-ratioen.

FORM kan og skal selvfølgelig ikke stå alene. I FEA-termer er en ”komplet EA referencemodel” foruden en forretningsreferencemodel (BRM) også fire andre referencemodeller for hhv. performance (PRM), servicekomponenter (SRM), data (DRM) og teknologi (TRM). Den danske ”oversættelse” vil svare til at FORM er BRMen, FOKUS er PRM, OIOXML/ISB er DRMen og OIO-kataloget er TRMen. Vi mangler således blot en SRM, servicekomponentreferencemodel, kunne man fristes til at sige. Men der mangler i den grad også sporbarhed mellem de forskellige referencemodeller.

Tillykke, Taskforce! Nu ser vi frem til at se de offentlige parter komme i FORM.

PS: OIO-kataloget er forresten under revidering, og indtil jul er 20 tekniske standarder i høring. Vi har med interesse gennemlæst høringsmaterialet, men ser ingen grund til at indsende et høringssvar, da der er tale om en rutinemæssig og ustrategisk ajourføring, som vi trygt overlader til bureaukraterne i Holsteinsgade. ”Nothing here, move on”.

Disclaimer: En del af de heromtalte organisationer er/var kunder hos EA Fellows.

For at starte i omvendt rækkefølge, så er der desværre noget der tyder på at vi endnu ikke har lært af Amanda og alle de andre dødssejlere der er blevet søsat i tidens løb.

Nye udbud dukker hele tiden op, hvor digitale supertankere ladet med et utal af komplekse teknologier skitseres og kastes i hovedet på de forsvarsløse leverandører, der føler sig forpligtede til at byde uanset hvor ækel den digitale mutant ser ud.

Løsningerne har ændret form over de seneste år fra de let forsimplede “strøm på blanketterne” udbud til de mere gennemgribende ændringer i arbejdsgangene ved indførelse af digitalisering, med en øget grad af automatisering via straksafgørelser mv. som følge.

Dette koblet med input fra mange fantasifulde konsulentfirmaer, der frit fortolker begreber som “åbne standarder” og OIOs hvidbog på hver deres kreative måde. Dette resulterer ofte i et væld af erklæringer om, at den intetanende leverandør skal leve op til snart sagt alle gældende standarder indenfor sikkerhed, Web Services og workflow.

Læg hertil et forhåndskrav fra kunden/konsulenten om, at leverandøren SKAL benytte en given proprietær infrastruktur til at implementere en fleksibel og åben løsning, og resultatet bliver den største selvmodsigelse man kan forestille sig.

Deadlines og økonomi er ofte også stramme, men man kan sige at det ligger i projektformens natur at man skal blive enige om disse ting ved starten, i stedet for at arbejde iterativt frem mod at løse det faktiske behov . Vi ser mange kontrakter, der indgås på et urealistisk grundlag. Hellere søge tilgivelse for forsinkelser end fortabe sig i forhandlinger, virker være logikken.

Nytænkning tak

Der er behov for nytænkning af den måde vi beslutter hvilke både vi vil have sat i søen i det offentlige digitale rum. Det nytter ikke noget at bygge en supertanker, hvis man blot skal krydse Gudenåen! Man skal måske tænke mere i brug af optimistjoller, hvis vi nu skal fortsætte på (dybt) vand – og så løse problemerne i små isolerede klumper i stedet for udfra en veltilrettelagt sejlrute og letfattelige samspilsregler.

Det kræver betydelige arkitektur-skills hos opgavestilleren, når man skal “hjemtage ansvaret for arkitekturen”. Og den kompetence findes sjældent hos kunden eller hans konsulenter i vore dage. Når de alligevel prøver, bliver det ofte en svær opgave for leverandøren – og en dårlig løsning.

Der er brug for en opsang. To gange endda: Først og fremmest til kunden for at stille krav om noget han ikke har forstand på. Men dernæst også til leverandøren for at byde på noget han ikke kan/bør levere, hvis han skal stå inde for løsningen med sin faglighed.

Men det er jo ikke blot fordi begge parter er dumme. Problemet opstår tit når de ikke kan finde deres plads i arkitekturprocessen, og at partnerne ikke kan finde ud af at fokusere på det de er bedst til: Dybest set at kunden kan sin forretning, og leverandøren kan sine løsninger og teknologi. Vi plejer at kalde det for “Danske Bank-modellen”: Hver part gør, hvad de er bedst til.

Det er ikke kundens opgave at stille detaljerede tekniske krav, for det er ikke her, han har sin styrke. Og det bør tilsvarende ikke være leverandøren rolle at definere kundens vision og målsætninger. På hvert niveau skal der være en arbejdsdeling, der svarer til parternes forudsætninger (og interesser), og en tilsvarende ansvarsfordeling.

Hvis kompetencerne som udgangspunkt er anderledes fordelt blandt parterne, så er det det der skal rettes op på – fx med styrkelse af kundens proces-udviklingsevne. Men det ville da også være forfriskende med en leverandør, der afslog at afgive bud med henvisning til at den ønskede tekniske arkitektur er uegnet, men at man gerne vil hjælpe med at udvikle et bedre alternativ …

Udfordringen er at få sigtelinierne fra strategien til at ramme rigtigt på de konkrete implementeringer i virkelighedens verden. Der er desværre ofte en tydelig “missing link” mellem strategien og projekterne. Kunden stiller nemlig ikke krav (især til sig selv) om, at projekterne reviewes med fokus på alignment, hverken før, under eller efter implementeringen.

Og hvad kan vi så gøre ved det? Tja, man har jo længe forsøgt sig med trylleformularen “business case”. Men det opfattes vist af de fleste myndigheder som en teoretisk tvangsøvelse, man skal igennem for at kvalificere et projekt til at få en bevilling, ikke som et aktivt styreredskab. Vi har i hvert fald endnu ikke mødt et offentligt projekt, hvor strategi, business case, udbudsmateriale og kontrakt hænger logisk og økonomisk sammen.

Et bedre udbud

Det er på tide at gøre op med de traditionelle fejltagelser, som silotænkning, proprietær infrastruktur, specialudviklede standardløsninger, osv. Vi har brug for et rammeværk for udbudsprocessen, der følger god EA praksis, og lægger vægt på randbetingelser, sigtelinier, risikostyring og økonomi. Det skal selvfølgelig passe sammen med K1 og K2, ITSTs arkitekturkrav, B103 standarderne og den digitale strategi. Idéen er at hjælpe opgavestilleren til at besvare en række spørgsmål som afgrænser opgaven, definerer forudsætningerne og beskriver de succeskriterier, som samarbejdet med leverandøren skal opfylde.

Hvis en sådan model blev obligatorisk for udbud over en vis størrelse (og for systemer med en central placering i digitaliseringen), kan der skabes overblik over de mange projekter, enten gennem tvungen rapportering opad, eller bare ved gennem åbenhed at synliggøre, om de lokale projekter er alignet med strategien.

Kurset løb over meget intensive 24 timer, tæt pakket med master class undervisning, workshops og rollespil. Ved at arbejde med en gennemgående case fik deltagerne praktisk erfaring med anvendelse af serviceorienteret arkitektur, og realistiske udfordringer med at omsætte forretningens krav til et konsistent design af services og løsninger.

Deltagerkredsen var præget af mange erfarne enterprise arkitekter – og enkelte nye ansigter. Antallet var begrænset til 24 deltagere for at sikre et maksimalt udbytte for alle. Læs mere i kursusbeskrivelsen om kursets emner og forløb. Og læs en deltagers beretning fra de 24 timer.

Vi har hos flere kunder oplevet, at der allerede er udarbejdet en stor, dyr og flot indbunden IT-vision og -strategi, men den har ikke forladt reolen efter den er blevet vedtaget at ledelsen. I den samme reol står er ofte en virksomhedsstrategi, en produktstrategi og flere andre overordnede planer. Men disse dokumenter er ofte udtænkt forskellige steder i organisationen, og det kan være svært – måske endda umuligt – at føre dem alle ud i livet på én gang.

Enterprise Arkitektur

Der er behov for samordning, og det er her, enterprise arkitekturen (EA) kommer ind i billedet. Ved at brede fokus ud til mere end blot IT-strategi, opnår organisationerne som arbejder med EA en større sammenhæng mellem de forskellige forretningsområder, mere gennemsigtighed, og dermed større mulighed for genbrug af processer og IT løsninger på tværs af hele forretningen.

Danske Bank er et godt eksempel på en virksomhed, der benytter enterprise arkitektur som et redskab til at opnå konkurrencemæssige fordele. Som Claus Torp Jensen er citeret for i artiklen opnår Danske Bank, at de i stedet for at udvikle fra bunden kan gøre brug af IT-komponenter, de allerede har på “hylderne” , og ved at kombinere dem på en ny måde kan de understøtte en ny forretningsproces og levere et nyt produkt til kunderne med kort varsel.

Kompetencerne mødes

Det er ikke trivielt at skabe en sammenhængende enterprise arkitektur for en virksomhed – det kræver betydelig indsigt både i forretningen, processerne og IT løsningerne. Det er vigtigt at arkitekturteamet repræsenterer et bredt udsnit af virksomhedens kompetencer – både de tekniske og de ledelsesmæssige. Men det er lige så afgørende, at arkitekturarbejdet følger en veldefineret metode, som alle deltagere forstår at anvende, selvom de kommer med forskellig baggrund.

Hos EA Fellows har vi i denne tid meget fokus på facilitering og undervisning. Vi mærker, at de forretningsansvarlige i stigende grad deltager i kurser og workshops om EA, for at kunne spille optimalt sammen med IT-folkene i deres hjemlige arkitekturproces. Og ikke overraskende, så kommer IT-arkitekterne til de samme kurser for bedre at forstå forretningens tankegang.

Mindre bøvl

Ved at råde over de rigtige kompetencer, og få dem til at spille sammen i en god proces, bliver virksomhederne i stand til at tage bedre strategiske beslutninger om anvendelsen af IT. Beslutningerne bliver langt mere “implementerbare” for kunden, fordi de er bygget på de samme forretningsprincipper, som styrer virksomhedens udvikling. Resultatet er sunde, langsigtede beslutninger – og langt mindre bøvl med IT.

EA Fellows er gået sammen med det amerikanske Carnegie Mellon University, et af superliga-universiteterne på it-området, og Telelogic, en af verdens førende EA-værktøjsleverandører, om at udbyde et EA-trænings- og certificeringsprogram i Europa.

I juli, september og november udbyder vi de første certificeringskurser i Amsterdam og Bruxelles. Vi planlægger endvidere kurser i de nordiske lande, og vil gerne høre fra folk, der eventuelt er interesserede i sådanne.

Der er tale om et tredelt forløb med et Fundamentals-kursus, et Applied-kursus og et Advanced-kursus. Det grundlæggende Fundamentals kursus henvender sig til arkitekter og ledere, der vil introduceres til EA. De to efterfølgende kurser går mere i dybden/stiller større krav, og henvender sig til praktiserende forretnings- eller it-arkitekter. Der er tale om nogle meget intensive kurser (3-5 dage), der hvert især afsluttes med en eksamen. Gennemføres alle tre kursus på tilfredsstillende vis tildeles titlen Certified Enterprise Architect med et dobbeltcertifikat fra Carnegie Mellon University og Telelogic.

Kurserne og certificeringen er baseret på et antal EA Knowledge and Skills Areas (KSAer), der angiver hvad en enterprisearkitekt skal vide og kunne (se CMU’s EA-KSA List), og programmet specificerer på den baggrund konkrete læringsmål. Disse er baserede på de 350 ‘learning points’, der er opstillet af det amerikanske CIO Council i en EA competency matrix, der afspejler de 42 EA læringsmål i dokumentet 2006 Clinger-Cohen Core Competencies and Learning Objectives. Selvom disse er udviklede med henblik for den amerikanske centraladministration er der tale om tilpas generiske krav til, at de også passer fint ind i en europæisk kontekst, og er relevante for både offentlige og private virksomheder.

At der er et samarbejde med Telelogic i dette certificeringsforløb betyder ikke, at kurserne orienterer sig mod specifikke leverandørers EA-værktøjer. Kursernes curriculum er udviklet af Dr Scott Bernard og efteruddannelses- og certificeringseksperter fra Carnegie Mellon universitetet. Bernard er en erfaren enterprise arkitekt (og forhenværende jagerpilot), der bl.a. har skrevet EA-lærebogen. Sammen med Telelogic har han startet programmet op for godt et år siden i USA, og samarbejder nu med EA Fellows om opstarten i Europa, hvor det er EA Fellows’ John Gøtze, der er ansvarlig for kurserne, og som har tilpasset dem til europæiske forhold.

For EA Fellows er dette partnerskab med akademisk og EA-professionel tyngde helt ideelt. Ikke blot er det en bro ud i Europa, det er også en god måde for os at fokusere vores indsats. Vi vil gerne bruge flere ressourcer på direkte dialog med vores kunder, og ser derfor certificeringsprogrammet som en integreret ydelse i et kompetenceskabende samarbejde med vore kunder. Vi sammensætter gerne et specialtilpasset forløb, der kombinerer kurserne, med individuel coaching og review for den enkelte organisation.

Tag gerne kontakt med John Gøtze på 5124 5878 eller john (Email address: john #snabel-a# eafellows.com), hvis du vil høre mere om mulighederne.

Det kan være en udfordring at få øje på enterprise arkitekten blandt alle de andre typer af arkitekter som vi møder: infrastruktur-, sikkerheds-, applikations-, løsnings-, informations-, database arkitekter – og der kommer stadig flere til!

Alle disse gode mennesker er utvivlsomt kompetente og effektive til at planlægge, designe og implementere IT-løsninger, men det kan nok diskuteres, om de alle beskæftiger sig med arkitektur. For arkitektur handler om at organisere på et overordnet niveau, i modsætning til at udforme løsningens detaljer.

I forbindelse med de konkrete opgaver, som EA Fellows løser for større kunder, er vi stødt på flere af de ovennævnte arkitekter, og mange tankevækkende beskrivelser af arkitektur. Derfor vil vi her give vores bud på, hvad arkitektur er, og – måske lige så vigtigt – hvad det ikke er.

Arkitektur er ikke tomme ord

“Arkitektur” er ikke en ny og opgraderet version af “bullshit-bingo” hvor det gælder om at kunne benytte flest akronymer og frameworks, på en måde så al tale bliver sort for dem som lytter. Hvis det er oplevelsen, så er det en sælger der taler – og ikke en arkitekt.

Arkitektur er ikke en konsulentydelse

“Arkitekter” er ikke en titel der er forbeholdt konsulenter, der er også en stor andel arkitekter i forskningsmiljøet og blandt de ansatte i offentlige og private virksomheder.

Arkitektur er ikke programmering

“Arkitektur” er mere end udvikling af ny software. Programmører og projektledere er ikke arkitekter, det er personer der har til opgave at skrive kildetekst, lave applikationer og styre implementeringen. Arkitektur handler om at organisere løsningens elementer på et overordnet niveau, og tage de principielle beslutninger for løsningens udformning.

Arkitektur indeholder mange discipliner

Der er mange discipliner indenfor arkitektur, og de har hver til sin tid en berettigelse. Hvis discipliner udelades, det være sig tekniske, organisatoriske eller procesmæssige, så bliver resultatet ensidigt og ukomplet. Alle discipliner må balanceres efter opgave, organisation og modenhed, for et skævt fokus vil føre til bristede illusioner og gode spildte kræfter for alle involverede.

Arkitektur kræver samarbejde og governance

En “stærk ledelsesforankring” eller anden form for “stærkt lederskab” bliver ofte nævnt som et element i arkitekturen, men det vil i sig selv aldrig løse opgaven for forretningen. Arkitekturen er en “opskrift”, som forretningsorganisationen sammen med ledelsen kan bruge til at løse de konkrete problemer og udfordringer, men det kræver at organisationen er i stand til at tage beslutninger og handle, for at realisere opskriften.

Arkitektur starter i forretningen

“Arkitektur” der ikke tager udgangspunkt i service til forretningen, krav eller ønsker fra forretningen, er ikke arkitektur, men elementer i en løsning. En “rigtig” arkitektur er en udmøntning af forretningsstrategien, og indeholder elementer som forretningsmodel (business case), nøgleprocesser og forbedringspotentiale (benefit realization), som definerer løsningens succesparametre.

Arkitektur er ikke en akademisk øvelse

Arkitekturarbejde som ikke er operationaliseret eller kan operationaliseres af andre, kan ikke betegnes som arkitektur. Det er akademiske øvelser, henstillinger, visioner eller dokumenter, som med stor sandsynlighed har størst værdi for forretningen i anden sammenhæng. “Rigtig” arkitektur giver grundlag for en praktisk implementering.

Arkitektur skal ikke være smuk – den skal være rigtig

Når vi taler om god arkitektur, er det altså ikke et spørgsmål om smag, men om løsningerne er hensigtsmæssigt struktureret i forhold til de opgaver de skal understøtte, og opfylder de overordnede målsætninger for den forretning, der skal bruge løsningerne.

Arkitektur giver ingen gevinster i sig selv

“Arkitektur” er ingen “silver bullet” eller frelsende Yourdon projektmodel, som giver løfte om umiddelbart målbare gevinster. Til gengæld er arkitekturarbejdet en god metode til at binde forretning og IT sammen på en måde, der sætter det positive samspil i fokus og giver mulighed for at høste nye fordele.

Disciplinen “arkitektur” er inde i en udvikling, hvor der er utrolig stor efterspørgsel, men få klare og entydige definitioner, endnu færre målepunkter for kvalitet og succes. I samarbejdet med vores kunder sætter vi fokus på at få defineret arkitektur i kundens kontekst og i forhold til organisationens modenhed. Vi bidrager også med konkretisering af arkitektur funktionens mandat og rolle, så arkitekturprocessen placeres rigtigt i forhold til de eksisterende forretnings og IT-funktioner i kundens organisation.

Nine-to-Five bliver til Always-On

De nye mobile og decentrale arbejdsformer betyder, at der stilles stigende krav fra forretningen overfor virksomhedernes it-afdeling. Når medarbejderne skal arbejde hjemmefra, eller fra hoteller, lufthavne og fremmede lokaler, stilles der krav til udstyr, båndbredde og sikkerhed, som går langt ud over den standard, der hersker på virksomhedens adresse.

Nye klienter

Den mest iøjnefaldende ændring i IT anvendelsen er nok brugen af nye klienter som PDA’er, smartphones, og andre devices, hvor brugergrænsefladen er markant anderledes end på en standard pc. Her bliver der brug for at håndtere flere parallelle kanaler fra den samme bruger til de samme data. For at møde denne udfordring vælger mange virksomheder at udskifte de traditionelle windows programmer med web-applikationer, som kan afvikles på tynde klienter, og ofte ser vi dette understøttet af en web-service infrastruktur. Men valget af denne form for applikationer giver også et øget pres på infrastrukturen, som kan forventes at blive en vigtig udgiftspost i de kommende år.

Slanke applikationer

Når arbejdsformerne ændres, må applikationerne følge med. For decentrale og mobile arbejdspladser benytter forretningsorienterede virksomheder enkle design principper som disse:

• Simpelhed, dette vil reducere omkostningerne til oplæring og support
• Tynde klienter, så det er ligetil at distribuere software og foretage opgraderinger
• Begrænset funktionalitet, implementer alene funktioner der er absolut nødvendige
• Brugervenligt design, det er lettere at yde support – og behovet er mindre
• Dimensioneret båndbredde: design med henblik på langsomme og ustabile net forbindelser
• Stabil konfiguration: undgå mange varianter og “lås” brugerens konfigurationsmuligheder så meget det er relevant

Serviceorienteret infrastruktur

Også infrastrukturen spiller en vigtig rolle, når målet er at gøre arbejdet uafhængigt af tid og sted. For enterprise arkitekten er opgaven at vælge og designe en infrastruktur, der kan bringe virksomhedens behov for funktionalitet, kommunikation og datalager på en fællesnævner, så stordriftsfordelene kan udnyttes.

En vigtig disciplin er kapacitetsplanlægningen, dvs styring af den indkøbte båndbredde, cpu-kraft og lagerplads i forhold til de forretningsmæssige behov. Når skiftende forretningsbehov giver store variationer i den ønskede kapacitet – og dens fordeling på systemer og brugere -  kan det være aktuelt at overveje en virtualisering af ressourcerne. På denne måde kan forretningens ønske om fleksibilitet honoreres, samtidig med at rutinefunktioner som fx backup og overvågning kan effektiviseres.

Ny arkitektur

De nye måder at arbejde på giver arkitekten nye udfordringer: Applikationerne skal vælges og sammensættes udfra nye principper, og infrastrukturen skal optimeres i forhold til det ændrede forbrugsmønster. Men målet er uændret, at understøtte forandring i virksomheden.

Single sign-on

Fælles brugerstyringsmodeller koncentrerer sig ofte om hvordan autentificering skal foregå, således at man har et solidt grundlag for at tildele autorisationer i de forskellige systemer, som indgår i processen. Den fælles autentificering kan fx være baseret på en brugeridentitet, som “bevises” een gang for alle, fx ved hjælp af et certifikat, en biometrisk genkendelse eller et indtastet password. Den fælles identitet giver altså mulighed for at opnå single sign-on mellem systemerne.

Autorisationer er derimod ofte knyttet tæt til det enkelte system, da adgangsstrukturen er formet efter de specifikke funktioner i et system, f.eks. regler om hvem der må se hvilke data, hvem der må opdatere bestemte data etc. Det betyder som regel, at der i det enkelte system må oprettes en autorisations-profil for hver bruger. Vedligeholdelsen af brugerprofilerne bliver dermed en væsentlig udgiftspost i forbindelse med systemets drift.

I en serviceorienteret arkitektur, hvor samarbejdende systemer skal understøtte den samme arbejdsproces, er det en stor hjælp at benytte en fælles brugeridentitet. Men det er ikke nok til at skabe en sikker og fleksibel løsning. Det kræver nemlig at vi kan styre sikkerheden i relation til den samlede forretningsproces, som de involverede systemer kollektivt understøtter. De forskellige personer, som deltager i forretningsprocessen, har som regel forskellige roller, og skal derfor have forskellige autorisationer i de enkelte systemer. Systemerne må have en fælles forståelse af disse roller, så sikkerheden bevares gennem hele forretningsprocessen.

Procesorienteret sikkerhed

Her er vi fremme ved sagens kerne: En fælles brugerstyringsmodel skal ikke blot omfatte en tværgående identitet, som alle systemerne kan referere til (og stole på). Den skal også definere et sæt roller for processens aktører, som de enkelte systemer kan oversætte til specifikke rettigheder (autorisationer).

På denne måde kan man opnå en ubrudt og konsistent sikkerhed gennem hele processen, selvom den er understøttet af en række samarbejdende systemer. Og som en ekstra bonus kan man spare væsentlige ressourcer til vedligeholdelse af brugerprofiler, fordi der nu kun er een profil per rolle i processen.

Det siger sig selv, at jo flere systemer i virksomhedens applikationsportefølje, der bruger et fælles rollesæt, jo større er potentialet for integration og besparelser. Udfordringen er imidlertid, at sådanne tværgående roller ikke er en hyldevare, men skal defineres i forhold til den aktuelle forretningsproces. Dertil kommer, at de gængse applikationsplatforme kun har en meget begrænset support for at benytte eksterne brugeridentiteter og profiler fra andre platforme og leverandører. Derfor er der ingen vej uden om at gennemføre et solidt stykke analyse- og planlægningsarbejde, når sikkerhedsarkitekturen skal på plads i den serviceorienterede arkitektur.

Mashups

Mashups er en betegnelse for web applikationer der blander indhold fra forskellige andre web sites og skaber nye anvendelsesmuligheder ved at kombinere funktionalitet fra uafhængige sites.

Et mashup udvikles ofte i en blanding af Javascript og kode på serveren, mens informationerne på de involverede sites hentes ved hjælp af et API eller via syndikerings protokoller som RSS og Atom.

Et simpelt mashup eksempel kan ses her. Dette eksempel benytter informationer fra Google maps til at vise selve kortet, og placerer myndigheder, der har valgt ODF som dokumentformat i en geografisk kontekst.

Portaler har længe været et vigtigt redskab til at sikre en samlet adgang til det offentlige sektors ydelser for såvel virksomheder som borgere. Begrebet portaler har mange fortolkninger, men generelt er der tale om, at stille funktionalitet fra forskellige systemer til rådighed på et samlet sted, samt at muliggøre personalisering af ydelsen, således at forskellige målgrupper kan benytte informationerne i portalerne på forskellig vis.I de seneste år har syndikering og integration af data fra andre systemer været i fokus i forskellige portal initiativer. Her har man på forskellig måde forsøgt at indlejre informationer fra andre systemer i en fælles portal.

En ofte anvendt metode er inline framing af elementer fra andre web applikationer, eller med andre ord at lade et andet websted optræde i sin egen frame på portalen. Denne metode kan dog ikke skabe en optimal integration mellem de involverede sites, og der er derfor opstået et behov for, at kunne forbedre integrationen mellem systemer der indgår i en portal. Hertil kunne man bruge protokollen Web Services for Remote Portlets (WSRP), der muliggør at data fra et websted kan rekvireres fra en ekstern portal og præsenteres på den form den eksterne portal benytter. Dette kræver dog at begge websteder implementerer WSRP services og da der er ikke pt. er udbredt support for WSRP i portalsoftware fra de kendte leverandører, er dette ikke en oplagt mulighed på kort sigt. På den anden side er selvsamme leverandører alle med i WSRP-standardiseringen, og OASIS, som står bag WSRP, har netop haft WSRP 2.0 i høring, og forventer lancering af WSRP 2.0 senere på året. De fleste nye portalplatforme understøtter WSRP.

Mashups – discount portaler

Mashups er en ny generation af web-applikationer, der kombinerer modne teknologier som f.eks. Javascript, XML og RSS til at bygge sites der integrerer indhold fra forskellige systemer på en intelligent måde, som giver brugeren mulighed for en stor interaktivitet med de involverede sites.

Sites som fx Google Maps, Amazon og Ebay stiller idag API’er til rådighed, der gør det meget enkelt at producere indhold der benytter information fra disse sites til at opbygge nye tjenester ved at kombinere vidt forskellige data og funktioner med hinanden.

Mashups viser vejen for fremtidens portaler: De grundlæggende teknologier er allerede tilgængelige, og udviklingen af et API til et site der skal indgå i et mashup er ikke specielt kompliceret set i forhold til at etablere en almindelig portal. Mange hundrede sites har allerede demonstreret potentialet ved at bygge applikationer ovenpå eksisterende services. Der er dog endnu ikke udbredt værktøjsunderstøttelse for udviklingen af mashups og en række aspekter som transaktionsstyring, sikkerhed og pålidelighed er endnu ikke en selvfølge indenfor området.

Men det er kun et spørgsmål om tid, før mashup-applikationer kan konkurrere med de dyre og ambitiøse enterprise portaler. EA Fellows anbefaler, at alle portal-byggere kigger sig over skulderen!

Forslag til Teknologirådet

Uhensigtsmæssige rammebetingelser har mange steder været den væsentligste barriere for at høste gevinsterne ved moderniseringen af den offentlige sektor. EA Fellows har i et projektforslag til Teknologirådet peget på, at styringsmodellerne for tværoffentlige teknologiprojekter må optimeres for at matche den omfattende udvikling af både arbejdsgange, IT-systemer og lovgrundlag, som digitaliseringen medfører.

Digitaliseringen af den offentlige administration har medført en omfattende udvikling af både arbejdsgange, IT-systemer og lovgrundlag. I de seneste år er der samtidig sket en stor omorganisering indenfor den offentlige forvaltning. Vi mener, at tidspunktet nu er det rigtige for en kortlægning af hvordan styringsmodellerne for tværoffentlige teknologiprojekter fungerer – og en debat om hvordan de kunne optimeres.

I digitaliseringens barndom var der skarpt fokus på leverandører og produkter. Der var en almindelig opfattelse, at teknologisvigt var den største fare for et IT-projekt. Nu er både produkter og leverandører mere modne, og det er sjældent, at et IT projekt kuldsejler pga. tekniske svigt. Til gengæld er der ofte problemer med de bløde sider i gennemførelsen, fx hvad angår planlægning og organisatorisk implementering. Her kommer de strategiske valg i fokus, fx omkring forretningsstrategi og valg af tekniske standarder.

I forbindelse med kommunalreformen og etablering af de nye regioner, er der sket store ændringer i rollefordelingen mellem stat, region og kommune. De nye enheder har fået ansvar for levering af mange ydelser til borgere og virksomheder, og der er i forandringsprocessen blevet udvist stor kreativitet og beslutsomhed for at etablere nye organisationer, der kan løfte ansvaret. Den nye fordeling af opgaverne stiller nye krav til samarbejdet mellem enhederne, ikke blot hvad angår den tekniske integration, men også hvad angår effektiviteten og kvaliteten i de leverede ydelser. Her er der brug for optimering på et overordnet plan.

Der er allerede gennemført en bemærkelsesværdig innovation indenfor levering af kerneprodukterne efter etablering af nye regioner og kommuner, og udviklingen af nye tværoffentlige systemer som fx ESDH og EPJ er i fuld gang. Det kan imidlertid være en udfordring at etablere et effektivt og velfungerende tværoffentligt samarbejde, hvis der mangler styringsmodeller, som kan fremme samarbejdet mellem økonomisk selvstyrende enheder som fx ministerområder, regioner og kommuner.

Vi har mange steder i den offentlige sektor (ligesom i den private) fundet gode eksempler på beslutningsmodeller og incitamentsstrukturer, der har været afgørende for et succesfuldt tværgående samarbejde. Men der findes desværre også mange eksempler på, at uhensigtsmæssige rammebetingelser har været den væsentligste barriere for moderniseringen af den offentlige sektor. Det har været svært at omsætte IT investeringerne til administrative gevinster, fordi styringsmekanismerne ikke er blevet ajourført i takt med den teknologiske udvikling.

Derfor mener vi, at det er på tide at sætte fokus på den overordnede styring af Danmarks IT anvendelse.

Virksomhederne har valgt en SOA strategi på baggrund af løfterne om en større fleksibilitet i IT arkitekturen, lettere integration mellem heterogene systemer og lavere vedligeholdelsesudgifter såfremt man fulgte den gyldne SOA sti. Men SOA er jo mange ting.

Den spæde start

For et par år siden var SOA projekterne på kravlestadiet og der blev ofte sat lighedstegn mellem SOA og Web Services. Mange systemer blev “service-enabled” ved at man etablerede en række read-only Web Services, så andre systemer kunne hente data på denne måde uanset teknologisk platform.

Denne enabling gav i sig selv ikke mere udbytte end hvad en traditionel dataoverførsel af andre kanaler kunne bringe, og oveni dette blev de pågældende services kun sjældent konstrueret med henblik på genbrugelighed i andre sammenhænge end i den aktuelle forretningsproces. Resultatet var, at SOA-gevinsterne i denne fase var temmelig svære at få øje på.

Modenheden vokser

Næste trin på modenhedsskalaen var udarbejdelse af en begrebsmodel, således at arkitekterne kunne råde over byggestenene til at konstruere services med og derfor kunne dyrke genbrug i større stil. Her var OIOXML projektet i Videnskabsministeriet en vigtig inspirationskilde, idet man her kunne lære hvordan et standardiseringsprojekt kan gennemføres og hvorledes man kan opbygge sin begrebsmodel på specifikationsniveauet. Med begrebsmodellen i hånden kunne man så gå i gang med at beskrive sine forretningsområder og dokumentere sine forretningsprocesser.

Det sidste skridt var at holde processerne op mod virksomhedens systemer, så man kunne finde frem til, hvilke services der var nødvendige for at understøtte de forretningsprocesser, man ønskede service-enable. Dette var et vigtigt trin på vej mod en rigtig SOA, da man nu havde et top-down fokus på forretningen frem for et snævert og kortsigtet bottom-up fokus.

Nu skal gevinsterne høstes

I 2006 afspejler SOA projekterne en erkendelse af, at gevinsterne ikke kan høstes ved blot at indføre én enkelt proces eller ved at købe en SOA suite fra sin favorit leverandør. Nu er der større fokus på de tværgående elementer i SOA implementeringen, heriblandt:

• Sammenstilling af services på tværs af flere systemer i workflows
• Sikkerhed mellem de involverede systemer og i forretningsprocesserne
• Portal integration implementeres internt såvel som eksternt
• Management af services ved hjælp af policies

Samtidig er der gjort en del bitre erfaringer med at forankre SOA strategien i virksomhederne, som der nu skal rettes op på. SOA har haft god ledelsesforankring, men der har været tendens til, at man ikke har gjort nok for at skabe rammerne og værktøjerne, der skal gøre virksomhedernes medarbejdere i stand til at bidrage fornuftigt til at sikre en fornuftig SOA implementering.

Indførelse af SOA kræver betydelige forandringer i virksomhedens “sociale arkitektur” – dvs. kombinationen af adfærd, struktur og kultur. Derfor er virksomhedens forandringsevne afgørende for SOA processens langsigtede succes.

På mange måder kan man sige, at Folketinget har vedtaget at 1. januar 2008 er den næste eDag. Men spørgsmålet er, om de offentlige parter og politikerne vil lade sig nøje med eDagenes kampagnepræg og generelle uforpligtethed. 

Der har været ført en længerevarende debat om hvilke konsekvenser det har at indføre åbne standarder i det offentlige, og mange synspunkter er fremført. Alle er enige om, at åbne standarder er vejen frem, men ikke om hvilke midler de skal indføres med. Regeringen henviser til et embedsmandsudvalg, det såkaldte Interoperabilitetsudvalg, som senest 15. august skal præsentere en betænkning med forslag til det videre arbejde.

Videnskabsministeriet har i et forstudie anbefalet, at åbne standarder gøres obligatoriske hvor det er nødvendigt for at skabe interoperabilitet og dermed en integreret forretningsproces, og hvor de opnåede gevinster er større end omkostningerne i den konkrete forretningsproces.

Argumentet fremført af Videnskabsministeren er, at de økonomiske gevinster ved indførelsen af standarder ikke alene følger af, at standarderne er åbne, men derimod skyldes at de er både fælles og åbne. Den store værdi kommer af at tale samme sprog, ikke at stille en ordbog til rådighed for alle, som Helge Sander udtrykte det for nylig i Folketinget. Således har IT-arkitekturkomitéen da også allerede lagt op til en vis stramning af OIO-kataloget, bl.a. ved at påpege at alle standardområder bør have en (og kun en) anbefalet standard. Men er det så nemt?

De fleste er enige i, at brugen af fælles standarder er et vigtigt værktøj til etablering af interoperabilitet mellem de offentlige it-løsninger, og at åbne standarder naturligvis bør foretrækkes. Men at gå så vidt som til at omdanne OIO-kataloget til en snæver positivliste, som alle offentlige myndigheder skal følge, vil næppe finde bred accept. Dertil er myndighedernes forudsætninger og opgaver nok for forskellige.

For generelle applikationer vil det være naturligt at vælge een fælles standard for hele den offentlige sektor, men når det kommer til fagspecifikke opgaver og systemer, er situationen mere kompleks. Vi tror, at standardvalget bør kædes sammen med det forretningsmæssige behov for samspil mellem de offentlige myndigheder, og det er en opgave for enterprise arkitekterne.

På IT området kan der på samme måde gå lang tid med at diskutere konkrete løsninger, produkter og leverandører i hver enkelt anskaffelsessag, hvis man ikke på forhånd har taget stilling til, hvilke generelle krav og standarder, de nye systemer skal leve op til. Naturligvis kan man bare uddelegere beslutningen til en fagmand, som fx IT chefen. Men kan man nu være sikker på, at han vælger, som ledelsen ville have gjort? Eller vil han lade sine egne præferencer spille ind?

Så er det måske bedre at sætte sagen i udvalg, og bede om en indstilling fra en gruppe af interessenter? På den måde vil det helt sikkert koste endnu flere ressourcer, før beslutningen er truffet.

Hvis man vil økonomisere med ledelsesressourcerne, og sikre at beslutningerne bliver taget til tiden, er det nyttigt at være “på forkant”. Det betyder, at man i ledelsesgruppen formulerer (og godkender) principper, som definerer den “normale” afgørelse af ofte forekommende sager.

På den måde reduceres behovet for sagsbehandling i ledelsesgruppen, fordi mange spørgsmål kan afgøres administrativt udfra principperne. Men det udelukker jo ikke muligheden for, at den enkelte sag kan forelægges ledelsesgruppen, hvis der er grund til at fravige princippet – eller hvis princippet skulle trænge til en justering.

Mange principper kan defineres på baggrund af vigtige beslutninger, man tidligere har taget (og investeret mange kræfter i). Det er en udbredt praksis i den offentlige administration. Så hvorfor ikke bruge den samme metode, når vi taler om IT ?

Fordelen ved at benytte principper, er at man undgår at diskutere de samme problemstillinger igen og igen. Det betyder, at ledelseskræfterne kan frigives til ledelse.

Der er en stigende erkendelse af, at virksomhedens evne til forandring er tæt knyttet til IT systemernes fleksibilitet og evne til at understøtte de optimerede arbejdsgange på en effektiv måde. Derfor er ikke blot arkitekturen, men også styringsmodellerne for IT beslutningerne kommet i fokus.

IT-governance handler om at etablere en klar styringsmodel for IT beslutningerne, så de er koordineret med de forretningsmæssige beslutninger. IT-governance er en integreret del af virksomhedens corporate governance, og det er den øverste ledelses ansvar.

En velfungerende governance er en forudsætning for, at de gode intentioner i virksomhedens strategiske planlægning vil blive efterlevet i praksis. Virksomheder med en stærk governance er karakteriseret ved:

• Topledelsen forstår, hvorledes IT skal bruges som strategisk værktøj i virksomhedens udvikling.
• IT strategien er integreret med forretningsstrategien og afspejler de forretningsmæssige mål.
• De overordnede principper for IT styring (fx arkitektur, sikkerhed og projektstyring) er vedtaget af firmaets direktion og kommunikeret til alle relevante ledere.
• Virksomheden har lagt den overordnede styring af IT i hænderne på en styregruppe, hvor både forretningsledelsen og IT ledelsen er repræsenteret.
• Der er etableret klare og effektive procedurer for planlægning, gennemførelse og opfølgning på resultaterne af alle større IT investeringer.

En stærk governance er en forudsætning for at opnå de forretningsmæssige fordele, som en god arkitektur giver. Mindre bøvl – mere bundlinie!

Håndteringen af elektroniske arkivalier er moderniseret betydeligt de seneste år, men det kan undre, at der ikke er sket en tilsvarende udvikling af standarderne for, hvorledes afleveringen skal foregå.

I Danmark har Statens Arkiver valgt selv at udvikle hjælpeprogrammer til at generere en arkivversion af offentlige dokumenter, og publicere værktøjerne på institutionens hjemmeside. Programmerne er udarbejdet af Statens Arkiver, som har copyright på dem, men i øvrigt ikke er forpligtet til at yde support på programmerne. Det oplyses, at programmerne ikke er testet på alle platforme, og hjælpeværktøjerne benyttes på eget ansvar. Hvis man vil selv vil teste eller videreudvikle, er der ikke umiddelbart adgang til kildeteksten.

I Australien har man stort set de samme udfordringer med håndtering af arkivalier som i Danmark, men man har valgt en lidt anden fremgangsmåde. National Archives har også udviklet et hjælpeværktøj, men den australske myndighed tilbyder værktøjet som OSS, og opfordrer andre institutioner til at deltage i arbejdet med udviklingen af hjælpeværktøjer og standarder for arkivering.

National Archives overvejer ifølge Computerworld Australien, at arbejde videre med hjælpeværktøjerne således, at det fremtidige opbevaringsformat for National Archives vil være ODF. Det kan tolkes som et tegn på, at levende formater som ODF er på vej til at finde fodfæste indenfor arkivverdenen, til fordel for døde formater som fx TIFF.

Se det ville være nytænkning blandt arkivarer – hvem siger at de arkiverede dokumenters format skal bevares lige så længe som dokumentets indhold?

Sun Microsystems’ Chief Open Source Officer, Simon Phipps, sætter situationen lidt på spidsen, og advarer mod at det han kalder for digital Alzheimer. Hvis formaterne vi bruger til vores arkiver ikke er åbne, så udsættes kulturarven for en ikke-reversibel forvitring.

Teknologien er egentlig ikke ny: Siden 1940′erne har man brugt den til identifikation af militært udstyr, og mange af os bruger allerede RFID tags, fx i bilens startspærre eller til identifikation af vores kæledyr. Det nye er, at prisen på RFID tags nu er kommet så langt ned, at det åbner mulighed for at bruge dem til dagligvarer, som en moderne stregkode i forsyningskæden fra producent til butik. Denne anvendelse forventes at eksplodere i de kommende år, fordi butikkerne med RFID kan styre deres varer bedre, og tilbyde nye services til forbrugerne.

I modsætning til de kendte stregkoder, indeholder hver RFID tag en unik adresse, så “taggede” varer kan spores individuelt. Det giver industrien et værdifuldt værktøj til effektivisering af logistikken og bekæmpelse af svind. Men samtidig åbnes muligheden for, at RFID tags på varer i indkøbsposen eller i tøj og sko kan misbruges til overvågning og profilering af personer.

Der er flere tekniske bud på, hvorledes misbrug kan undgås, uden at sætte fordelene over styr. Men teknikken kan ikke stå alene, når det gælder sikkerhed og privatliv. Her må vi også tale om principper for anvendelsen. Derfor beskæftiger fx Teknologirådet sig med emnet, og har for nylig skrevet dette inspirationsmateriale.

OASIS standarden for sikre Web Services (WS-Security) har faktisk længe været en bredt accepteret og moden standard for anvendelse af autentifikation, signering og kryptering i Web Services. Men den er ikke nær så udbredt som den fortjener. De fleste af tidens Web services integrationer baseret på sikkerhed i transportlaget, implementeret som lukkede netværk eller SSL krypterede forbindelser på Internettet. Denne arkitektur kan nemt være en barriere for tværgående integration, fordi den forudsætter at parterne allerede er koblet sammen med et sikkert netværk.

WS-Security, som indgår i profilerne for OIO Serviceorienteret Infrastruktur, giver mulighed for at udveksle informationer med sikre webservices over det åbne Internet. Dermed er barrieren brudt for tusindvis af små og mellemstore virksomheder, der gerne vil drive en sikker forretning over internettet, uden at være tvunget til at bruge en VANS-leverandør.

Pålidelighed bliver i de kommende år en afgørende faktor for udbredelsen af Web Services, da det er noget kunder og leverandører har brug for i deres Web Services integrationer. Hidtil har pålidelighed været løst ved hjælp af omkostningstunge infrastrukturer, men med WS-Reliable Messaging er der åbnet op for at benytte en valgfri kommunikationsform og derved opnå en mere kost effektiv, fleksibel løsning. Her har vi et klart eksempel på, hvordan brugen af åbne standarder kan ses direkte på bundlinien.

KMD skal i fremtiden have rollen som leverandør på linie med sine konkurrenter, og skal iøvrigt bidrage til standardiseringsprocessen ved at stille standardiserede grunddata til rådighed for kommunerne. De første data, der indgår i standardiseringsarbejdet, er løn-, økonomi, og p-data, men på sigt skal initiativet omfatte alle KMD’s fagsystemer.

Kommunernes egen forening sætter sig hermed for bordenden, når kommunernes data skal standardiseres. Vi vil opfordre til, at man tager udgangspunkt i at definere de fælles processer i kommunernes forvaltning så klart, at vi undgår mange lokale varianter af arbejdsgange, som tjener samme formål. På den måde får vi et solidt fundament under standardiseringen af datastrukturerne og undgår de mange lokale tilpasninger af standardsystemerne, som er kilden til unødige omkostninger.

Noget tyder dog på, at vi må vente til efter kommunalreformen, med at se EA slå igennem i kommunernes it-planlægning. De fleste kommuner har lige nu nok at gøre,  som KLs it-konsulent Michael Hald udtrykker det i denne video.

For et stykke tid siden lancerede Microsoft en beta-udgave af deres søgemaskine, den hedder Start og kan findes på Start.com. Og i sidste uge svarede Google så igen, da de købte Writely og dermed for alvor viste at de er på vej ind på Microsofts domæne, kontorprogrammerne. Snart ser vi vel Google Office, men kender man Google må det forventes være en online, web-baseret applikation.
På søgemaskineområdet ser vi også innovation. For eksempel Clusty, som opdeler søgeresultatet i grupper (“clusters”). Når man søger på EA får man vist grupper som Zachman, SOA og Open Group. Ganske smart. Gad vide hvornår Google, Yahoo eller Microsoft køber dem?

Det er bekosteligt at udarbejde strategiske planer, og det kræver et betydeligt ledelsesengagement at føre dem ud i livet. Mange virksomheder (både offentlige og private!) har derfor fundet det tilstrækkeligt at udarbejde en ny arkitektur (eller en IT strategi) hvert femte år. Resultatet er desværre ofte, at planerne får en begrænset værdi, fordi virksomheden over en femårsperiode har udviklet sig betydeligt, mens nye IT standarder og produkter er kommet til.

Hvis arkitekturdokumenterne skal undgå at samle støv, skal de opdateres løbende i takt med de nye forretningsmæssige og tekniske trends.Det kan man opnå ved at koble dem til Standardkataloget, som giver online adgang til de seneste anbefalinger om åbne standarder. Og til  Principkataloget, som hele tiden er opdateret med Best Practice Principper for arkitektur og strategi.

Når nye løsninger udformes, vælger man ofte at satse på en web løsning, fordi disse traditionelt set lettest når ud til den størst mulige målgruppe med det mindst mulige besvær.

Løsningen udformes så den passer til en eller flere browsere og implementering af løsningen indebærer alene deployment til en webserver, hvorefter alle kan tilgå systemet, så længe de har en browser installeret. Men browseren har sine begrænsninger – det jo i bund og grund kun en tekst terminal som er udvidet til at vise billeder og “objekter” i form af fx animationer og film.

Flash vinder frem
Flash teknologien har aldrig rigtig rodfæstet sig i større løsninger, idet man har vurderet at det vil være en hæmsko for udbredelsen, da ikke alle har Flash på deres systemer. Nu peger flere kilder på, at Flash har omkring 90% penetration på alle verdens pc’ere og der er derfor seriøst grundlag for at inddrage Flash teknologien i langt højere grad end tidligere i design af nye og mere avancerede grænseflader.

Macromedia satser stort på at Flash får en mere fremtrædende position som “rigtig” applikationsfrontend, fremfor kun at tjene som banner- og spil-motor. Og Flash får i fremtiden også lov til at brede sig ud over browserens rammer, idet Macromedia satser på at levere tools der kan lette udvikling og deployment af desktop applikationer i form af Flex produktet.

Samme område har også stort fokus hos Microsoft som sætter ind med alle sejl på WPF (Avalon) projektet, som er en pendant til Flash til Microsofts browsere og .Net frameworket. WPF platformen vil give udviklerne mulighed for at definere grænseflader i XML dialekten XAML, som kan bruges til at generere browser grænseflade komponentet a la Flash eller desktop applikationer.

Også IBM har kig på mulighederne og tilbyder fremover en komplet programsuite, der kan bruges til at udvikle desktop applikationer der let og enkelt kan deployes til mange brugere og automatisk bliver opdateret fra serveren.

De afgørende faktorer
Slaget om de bedste værktøjer kommer helt klart til at stå på følgende områder:

• ease of development - kvaliteten af udviklingsværktøjerne
• ease of deployment – hvor let er det at rulle programmerne ud til en stor og ukendt brugerskare
• ease of maintenance – opdatering af programmer skal ske automatisk
• runtime platform penetration – runtime programellet skal enten være meget let at installere eller findes på brugerens pc i forvejen

Den høje kvalitet af udviklingsværktøjer har længe været Microsofts force, men IBM og Macromedia er ved at hale ind på dem, med deres fælles satsning på Eclipse platformen, som er meget udbredt blandt udviklere og konstant udvides med nye funktionalitet, der gør det lettere at udvikle applikationer.

• At få koblet forretning og IT sammen i én strategi
• At vælge de rigtige standarder og teknologier
• At styre udviklingen med simple regler/principper

Enterprise Architecture (EA) er altså meget mere end end blot IT-arkitektur. Det er en planlægningsproces, som skaber sammenhæng mellem forretningsprocesserne og it løsningerne, og optimerer begge sider i forhold til hinanden. EA er for mange en vanskelig disciplin, fordi der kræves en bred vifte af kompetencer i processen, og fordi der skal tages mange vidtrækkende beslutninger undervejs. 

Enterprise architecture er en ledelsesdisciplin, der kræver indsigt i både de forretningsmæssiske og de tekniske forhold. De forskellige deltagere i EA-processen skal ikke blot være eksperter på deres eget felt, de skal også  forstå hvorledes beslutningerne i de forskellige domæner indvirker på hinanden, og hvilke konsekvenser deres beslutninger vil have på lang sigt. Kort sagt, EA er ikke for begyndere.

Der skal investeres mange ledelsesressourcer i arkitekturprocessen, for at de trufne beslutninger bliver rigtige for den enkelte virksomhed. Og det er afgørende at benytte de bedste metoder og værktøjer i processen, så den investerede tid giver det optimale udbytte. Derfor vælger stadig flere virksomheder at alliere sig med erfarne rådgivere, når arkitekturprocessen skal tilrettelægges  og gennemføres i praksis.