EA Fellows

I sidste uge var der høringskonference om ESDH standarderne. På bordet lå Referencearkitektur for sags- og dokumentområdet -en diger sag på næsten 100 sider, der bl.a. indeholder en nyudviklet begrebsmodel for den offentlige sagsbehandling. På konferencen fremlagde OIO udvalget for Sag og Dokument de (5) specifikationer af forretningsservices, som skal supplere - og med tiden afløse - de eksisterende FESD standarder.

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

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

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

Fra høringssvaret kan vi referere disse punkter:

1.      Forretningsmæssige begrundelser

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

2.      Komplicerede grænseflader

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

 3.      Ambitionsniveauet

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

4.      Innovation

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

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

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.

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.

En gang i 90’erne hørte det til dagens orden at offentlige IT projekter udviklede sig til “IT skandaler”. Definitionen på en skandale var ganske simpelt at tidsplanen og budgettet blev overskredet i væsentligt omfang. Men så fik vi DANSK IT’s Dogmer for offentlige IT projekter og Bonnerup rapporten, som gav gode råd om hvordan man gennemfører store IT projekter. Snakken om skandaler stilnede af, og vi begyndte at tale om ”fine” ting som modenhed og standarder …

Nu er den gal igen

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

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

Planlægningen mangler

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

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

En bedre praksis

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

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

Opfølgningen

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

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

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

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

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

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

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

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

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

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

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!

Et nyt arrangement for erfarne enterprise arkitekter og strategiske planlæggere, blev i maj gennemført af EA Fellows i samarbejde med CSC Sverige, på det fine Rånäs Slott oppe i Uppland. 

Vi udfordrede deltagerne til at udvikle deres erfaring med serviceorienteret arkitektur i et intensivt forløb med master class undervisning, workshops og rollespil. Den gennemgående case handlede om en virksomhed i opbrud, og deltagerne var opdelt i 3 grupper, som skulle sørge for at serviceorientere de nye enheder i koncernen.

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

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

Hvad er årets bedste nyhed på arkitekturfronten i det offentlige Danmark? EA Fellows kommer med et bud. Men først skal vi ønske bloglæsere, kunder, venner og partnere en glædelig jul og et fremgangsrigt nytår.

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

Arkitektur i FORM!

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

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

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

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

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

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

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

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

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

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

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

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.

EA Fellows afholdt i samarbejde med CSC et superintensivt kursus for SOA-ansvarlige på Sørup Herregård den 18. til 19. september. Hovedkræfterne bag kurset var John Gøtze og Allan Bo Rasmussen.

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

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