Bedre offentlig IT

Mange steder i det offentlige system er man faktisk godt klar over, at anvendelsen af IT kunne være mere hensigtsmæssig, og i den seneste tid har hele 3 rapporter om digitalisering set dagens lys, alle initieret af det offentlige Danmark:

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.

Beslutningstomrum

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.

Strategisk IT anvendelse

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.

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.

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.

ESDH høring igen

ITST har igen sendt specifikationerne for sag og dokumentområdet til offentlig høring, nu i en slankere udgave, hvor bl.a. en del elementer har skiftet status fra obligatoriske krav til optioner. Den arkitekturmæssige tilgang er dog uændret, og ambitionsniveauet for standardiseringen er fortsat meget højt, idet man beskriver grænseflader for alle systemer i den offentlige forvaltning, der vil tilbyde eller benytte dokumenthåndteringsfunktioner i et andet system. Det er altså ikke kun ESDH systemerne, der er målet for den nye standardisering, men hele samspillet mellem den offentlige forvaltnings systemer.

Vi anbefaler alle leverandører af fagsystemer, portaler og infrastruktur til den offentlige forvaltning at holde et vågent øje med de nye dokumentstandarder, for hvis OIO udvalget får magt som de har agt, vil specifikationerne indgå i de fleste offentlige udbudskrav allerede fra næste år.

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.

EA for Innovation

Det er ofte hævdet, at begreber som strategisk planlægning og overordnet arkitektur står i direkte modsætning til innovativ udvikling. Påstanden bygger som regel på en misforstået opfattelse af, at strategisk tænkning altid er en topstyret proces, der skal resultere i et ensartet og forudsigeligt resultat. Men sådan behøver det slet ikke at være.

EA som innovationsmetode

Enterprise Architecture (EA) er en anerkendt metode til at organisere en virksomheds processer, informationer og teknologier, så alle dele af virksomheden fungerer optimalt sammen og skaber de projekterede resultater. Kernen i EA metoden er at udvikle processer og teknologiske løsninger, med udgangspunkt i de strategiske mål. Denne tilgang er ikke blot velegnet ved udvikling af virksomheder, men er også yderst værdifuld ved udvikling af innovative produkter og services. Her sætter vi anvendelsesprocesserne i centrum, og maksimerer den værdi, produktet kan skabe hos kunden. EA metoden relaterer produktets egenskaber til værdiskabelsen, i stedet for at tage udgangspunkt i teknologien. Dermed sikres, at vi tænker “out of the box” og skaber nye løsninger, der opfylder de overordnede behov bedre end de eksisterende produkter og services.

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.

Standardisering eller arkitektur? Begge dele, tak!

Efter sommerens høringskonference om de kommende ESDH standarder var deltagerne – og andre interessenter – inviteret til at indsende skriftlige kommentarer til de 5 specifikationer af forretningsservices, som skal supplere – og med tiden afløse – de eksisterende FESD standarder.

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.

En business case for EA

Når der skal opstilles en business case for EA, er omkostningssiden klart den nemmeste af konkretisere: Mandtimer, konsulenter, værktøjer. Men hvordan opgør vi plussiden? Hvilke fordele kan vi opnå, og hvilken værdi skal vi tillægge dem? Her har vi samlet lidt inspiration til enterprise arkitekten, der skal argumentere for at indføre et EA program i virksomheden.

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.

Supertanker eller optimistjoller?

I lyset af den skare af nyheder om offentlige it-projekter, der forsinkesfordyres eller på anden måde forringes, vi for tiden får nys om, så er det vel naturligt, at spørge sig selv om den måde vi planlægger og udfører vores store offentlige IT-projekter overhovedet er i tråd med hvordan man bedst udvikler løsninger? Og hvad med det samlede billede? – er der tænkt på hvordan man går fra strategi til specifikation af de byggeklodser der skal indgå i løsningskomplekset ?

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.

Topledelsen vil have EA-viden

Som omtalt i Computerworld, oplever vi i denne tid en tydelig stigning i interessen for enterprise arkitektur, ikke blot hos IT-specialister, men også hos virksomhedernes topledelse. Det tyder på, at både store og små organisationer satser på at få bygget bro mellem forretning og IT, mellem teori og praksis, mellem principper og processer.

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.

At være eller ikke være enterprise arkitekt

Både i den videnskabelige litteratur, hos analyse institutter, og på blogs “i den virkelige verden” er der en rimelig enighed om hvad betegnelsen enterprise arkitektur (EA) står for. Men samtidig er der en klar tendens til, at stadig flere IT professionelle får betegnelsen “arkitekt” føjet til deres visitkort.

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.

Nye arbejdsformer kræver ny arkitektur

Billedet af den traditionelle virksomhed, hvor alle medarbejderne arbejder synkront foran hver sin pc, hører en svunden tid til. Et stigende antal virksomheder tilbyder fleksible arbejdsformer som hjemmearbejdspladser og mobile opkoblinger for ansatte på farten.

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.