Artikler om Arkitektur

Bedre offentlig IT

Wednesday, 7. July 2010

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.

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.

Strategisk IT anvendelse

Friday, 18. June 2010

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

Sammenhæng, arkitektur og øl

Wednesday, 3. March 2010

Den 24. – 26. marts holder vi næste-generations EA-kurset Coherency Management – Architecting the enterprise (hent kursusbeskrivelsen) sammen med Dansk IT. Vi har holdt dette kursus før, og har noget godt materiale, men som noget nyt vil vi denne gang trække en konkret case direkte ind i forløbet. Casen er Carlsberg.

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.

ESDH høring igen

Tuesday, 27. October 2009

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.

(more…)

EA for Innovation

Tuesday, 18. August 2009

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.

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

Standardisering eller arkitektur? Begge dele, tak!

Friday, 7. August 2009

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

Tuesday, 14. April 2009

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.

Practicing EA

Saturday, 28. March 2009

EA Fellows har netop afholdt en EA-workshop i samarbejde med Dansk It, der har markedsført arrangementet som et kursus i arkitekturstyring og sammenhængsledelse.

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.

Certificering som enterprisearkitekt – i Danmark

Friday, 3. October 2008

Carnegie Mellon University’s EA-trænings- og certificeringsprogram starter nu op i Danmark, leveret af EA Fellows.

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!

Supertanker eller optimistjoller?

Sunday, 16. December 2007

I lyset af den skare af nyheder om offentlige it-projekter, der forsinkes, fordyres 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.