EA Fellows

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.

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.

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.

Brugerstyring kan være et meget komplekst emne at tage hul på, når nye IT systemer skal designes, eller når eksisterende systemer skal bindes sammen for at indgå i en fælles proces. Adgangskontrollen har to trin: Først skal det konstateres med sikkerhed hvem brugeren er (autentificering), derefter skal det styres hvad hun skal have adgang til (autorisation).

Single sign-on

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

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

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

Procesorienteret sikkerhed

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

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

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

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

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

Mashups – discount portaler

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

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

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

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

SOA har nu været et pejlemærke for mange virksomheders IT strategi i en rum tid, men hvordan er det egentlig gået med at realisere den Service Orienterede Arkitektur og høste frugterne heraf ?

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

Den spæde start

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

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

Modenheden vokser

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

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

Nu skal gevinsterne høstes

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

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

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

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