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.

 Download denne artikel som pdf.

Hvordan styrkes virksomhedens økonomiske modstandskraft?

I gode tider er det naturligt at der samler sig lidt “fedt” i organisationen: Ikke alle investeringer bliver vejet og vurderet i dybden, når midlerne er til rådighed, og fordelen er åbenbar. Derfor vil det altid være muligt at finde “lommer” i virksomheden, hvor unødvendige omkostninger kan elimineres.

På IT området har de fleste virksomheder opnået væsentlige effektivitetsforbedringer gennem de seneste 8-10 år, gennem styring af applikationsporteføljen, optimering af infrastrukturen, konsolidering af systemer og ved outsourcing af opgaver, der bedre og billigere kan varetages af specialiserede organisationer. Der er med andre ord ikke mange besparelser at komme efter, hvis ellers IT direktøren har løst sine opgaver professionelt.

Samtidig er der sket det, at integrationsgraden er blevet markant større. Gennem mange år har man stræbt efter at få virksomhedens IT systemer til at hænge bedre sammen, og efter at støtte stadig flere forretningsprocesser med IT-løsninger. Det har givet større effektivitet, men det betyder også, at det kan være farligt at tage bestemte IT funktioner ud af drift, fordi en række andre systemer og funktioner er afhængige af dem.

Derfor er det i en moderne virksomhed ikke hensigtsmæssigt at skære ned efter grønthøster-metoden – der skal smartere metoder til.

Skal vi spare eller hvad?

Når virksomheden skal bringes sikkert gennem en markedsmæssig krise, er den oplagte reaktion at skære ned på de faste omkostninger – og herunder at tilpasse arbejdsstyrken. IT omkostningerne regnes traditionelt for administrative omkostninger, og står ofte i skudlinien, når der skal spares.

Men lad os lige se på, hvad IT omkostningerne består af. Overordnet kan man dele IT-budgettet op i 3 dele: 

• Den første del er rene driftsomkostninger, som er forbundet med de systemer som støtter virksomhedens forretningsprocesser
• Den andel del er forvaltningsomkostningerne, som bl.a. indeholder fejlretning og løbende forbedring af de kørende IT løsninger
• Den tredje del omfatter etablering af nye løsninger, ofte organiseret som projekter

Driftsomkostningerne består overvejende af faste omkostninger og allerede foretagne investeringer. En nedskæring her vil som regel medføre ringere serviceniveau og højere risiko for nedbrud. Forvaltningsomkostningerne kan i højere grad justeres efter situationen, idet man kan afveje behovet for “bessermachen” i forhold til omkostningerne. Projekterne, som skaber nye løsninger bør naturligvis prioriteres efter den værdi, de skaber.

Det er langtfra sikkert, at nedskæringer alene er redningen. Måske skal der både spares og investeres på samme tid. Formålet er jo at forbedre bundlinien, og her kan målrettede investeringer give bedre resultater end nedskæringer. Analyser fra anerkendte rådgivere som McKinsey og Gartner, viser at de fleste virksomheder har et stort potentiale for at forbedre effektivitet og indtjening med små, strategiske IT forbedringer.

Når forretningen og IT sammen ser på firmaets processer, vil de finde tiltag med 10 gange større potentiale (virkning på toplinie og bundlinie) end simple nedskæringer. Fx kan man optimere udbyttet af virksomhedens data (om kunder, konkurrenter, markedspriser etc.) ved at sammenkoble eksisterende informationer, så de giver grundlag for bedre indtjening. Eller man kan eliminere flaskehalse og manuelle procedurer i produktion og logistik, så effektiviteten får et hak opad.

Initiativer, hvor begrænsede IT investeringer hurtigt kan forbedre indtjening og effektivitet, findes ofte på disse områder:

• Dynamisk styring af salg og prissætning
• Optimering af produktion, indkøb og sourcing
• Forbedring af supportprocesserne for at få mere loyale kunder
• Erstatning af langsigtet styring med mere direkte opfølgning på resultater

Ikke mindst beslutningsprocesserne er vigtige: Hvis virksomheden har en velfungerende governance struktur for styring af forvaltningsaktiviteter og projekter, er der ingen grund til at sætte den ud af kraft i krisetider. Her er det yderst relevant at kunne tage hurtige og sikre beslutninger, og at benytte opdaterede kriterier for prioritering af de enkelte investeringer. Og hvis man ikke allerede har en god beslutningsmekanisme for IT investeringer, så er det på høje tid at få den etableret! 

Hvad skal ledelsen gøre?

Se på virksomhedens processer og vurder hvor IT kan skabe større værdi ved at

• finde og eliminere kostbare flaskehalse i produktion og logistik
• finde manuelle rutiner som kan let kan automatiseres
• finde fejlkilder som kan elimineres gennem it-kontroller
• stille bedre informationer til rådighed for processens deltagere
• reducere kompleksiteten af procesforløbet og de behandlede data
• etablere nye processer til at systematisere “tilfældige” opgaver

 Analyser virksomhedens data for at finde muligheder for

• at forøge indtjeningen uden at hæve priserne
• at skabe større kundetilfredshed og loyalitet
• at styrke salget med værdibaserede bonus-modeller
• at få et bedre grundlag for strategiske og taktiske beslutninger
• at optimere forretningsmodeller og policies til den nye situation
• at sammenkoble datasiloerne for at skabe ny viden
• at finde dublerede og unødvendige informationer

Finanskrisen varer helt sikkert ikke evigt – men det er afgørende for virksomheden at komme godt igennem denne periode, hvor de gamle markedsmekanismer er erstattet af et nyt sæt spilleregler, hvor tilpasningsevnen er sat i højsædet. De virksomheder, som kan justere forretningen til de nye tider, vil komme styrket ud af krisen.

 Download denne artikel som pdf.

I Zebranet har vi en mangeårig tradition for at netværke med institutioner, virksomheder og enkeltpersoner. Det giver os mulighed for at levere balancerede og ajourførte anbefalinger til vore kunder. Vores aktive netværk omfatter bl.a. følgende organisationer:

• RISKnet – et netværk af nordiske eksperter i IT sikkerhed
• PEP-NET – et stort europæisk netværk for udvikling af e-demokrati
• EA Fellows – en tænketank for Enterprise Arkitektur
• Privacyforum.dk – et websted med holdninger og fakta om privacy
• Rådet for Organisation og IT – en uafhængig tænketank for god IT praksis

Læs mere under Netværk i menuen til højre…

I 2001 mødtes skaberne af mange forskellige agile udviklingsmetoder, og definerede et fælles grundlag for agil udvikling i Manifesto for Agile Software Development. Her fremhæves værdien af den personlige interaktion i teamet, demonstration af konkrete funktioner, samarbejde med kunden, og evnen til at håndtere forandring i udviklingsforløbet. Manifestet suppleres af en række principper for agil softwareudvikling, som primært adresserer værdier, processer og roller i samarbejdet.

De agile udviklingsmetoder blev opfundet i erkendelse af, at den traditionelle vandfaldsmodel let kommer til kort, når opgavestilleren ikke er i stand til at specificere løsningen ved projektets start, eller når forudsætningerne ændrer sig, så de stillede krav – og løsningen- må justeres. Vi bliver jo alle klogere i projektets forløb, og de agile metoder tager hensyn til dette ved at sætte tilpasningsevnen i højsædet, en lille smule ligesom Darwin gjorde det.

Når et projekt følger en agil udviklingsmodel, er den væsentligste fordel, at man kommer hurtigere i gang med at programmere, og dermed på et tidligt tidspunkt får indhøstet nogle af de erfaringer, der manglede ved projektets start. Dermed tackler man risikoen for at spilde ressourcer på at lave noget der ikke er holdbart – eller som der slet ikke er brug for.

Men til gengæld har den agile udvikling andre indbyggede risici: Når man fx vælger standarder og teknologier, inden den samlede løsning er beskrevet, kan man nemt komme ud for, at det bliver svært at opfylde de stillede krav på den valgte platform. Og når løsningen kun i meget begrænset omfang dokumenteres, kan det blive besværligt at drifte og vedligeholde softwaren, efter at udviklingsteamet  er draget videre til nye, spændende projekter.

Derfor kan det være hensigtsmæssigt at kombinere en agil udviklingsmetode med en række principper, som definerer rammerne for udviklingsprojektet. Her tænker vi først og fremmest på de overordnede arkitekturprincipper, som beskriver de forretningsmæssige og tekniske rammer, man har valgt at arbejde inden for. Det kunne fx handle om:

1. Forretningsmæssige forudsætninger og mål, herunder målbare succeskriterier
2. Hvordan løsningen indgår i forretningsprocesserne, og hvilke fordele den skal give
3. Hvilke data der skal behandles i løsningen og hvordan de skal være organiseret
4. Løsningens funktionelle afgrænsning i forhold til andre systemer i virksomheden
5. Hvilke teknologiske platforme skal løsningen køre på og hvorledes skal den indpasses i infrastrukturen

Ved at fastlægge rammerne i principform, giver man frihed til den kreative iteration, som bærer udviklingsprocessen. Men samtidig sparer man også en masse tid til fx afprøvning af alternative teknologier eller til at diskutere scope og integration i forhold til omgivelserne. Arkitekturen er en fælles referenceramme, der understøtter hurtig udvikling, netop fordi den definerer frihedsgraderne i hittepåsomheden, og hjælper til at opfylde nye krav med allerede eksisterende praksis og komponenter.

Foruden arkitekturprincipperne kan det være nyttigt at fastlægge andre rammebetingelser for udviklingsprocessen, fx budgetmæssige krav, og krav til den dokumentation der skal følge med løsningen ved aflevering og idriftsættelse. Der kan også være behov for at koordinere projektets forløb i forhold til dets omgivelser – her kan man med fordel se i retning af PRINCE2 for at hente inspiration.

Men til syvende og sidst er valget af projektmodel et spørgsmål om at afveje virksomhedens behov for agilitet mod behovet for styring og kontrol. Og at indregne både virksomhedens og projektets forudsætninger i overvejelserne.

Hvad taler for valget af agile metoder/elementer

• Projektet er ikke kritisk for virksomheden
• Udviklere med høj erfaring
• Kravene til løsningen skifter ofte
• Antallet af udviklere er lavt
• Virksomhedskulturen trives med kaos

Hvad taler for valget af planlagt/styret metode

• Projektet er kritisk for virksomheden
• Udviklerne er nye eller uerfarne
• Kravene er velkendte og faste
• Projektet involverer mange udviklere
• Virksomhedens kultur er baseret på orden

For mange virksomheder vil det være relevant at inddrage elementer fra både de agile modeller og fra de traditionelle, kontrollerede forløb, som scorer højt på Carnegie Mellon Universitetets CMMI model. For en virksomhed med flere (mange) projekter er det oplagt at følge en projektmodel, som er fleksibel. Det kan fx realiseres med tilvalg/fravalg af de enkelte elementer, baseret på de konkrete behov i det enkelte projekt.

 Download denne artikel som pdf.

Læs mere her:

Kelly Waters blog: All About Agile.

Software Engineering Institute: CMMI or Agile: Why Not Embrace Both.

Craig Larman & Victor R Basili: Iterative and Incremental Development: A brief History.

Formålet med projektformen er at gennemføre aktiviteterne i det enkelte projekt i en hensigtsmæssig orden, og med styr på tid, kvalitet og risiko. Det kan opnås ved at bruge en anerkendt projektmodel som fx PRINCE2 til at definere rammerne for projektets gennemførelse, og ved at engagere en projektleder, der forstår at benytte modellen i praksis.

Men sammenhængen mellem strategi og projekter kommer ikke af sig selv. Vi ser desværre mange eksempler på organisationer, der har en fin og pompøs strategi for virksomhedens udvikling (og IT anvendelse), men alligevel søsætter projekter på stribe, uden at demonstrere hvorledes de understøtter strategien.

The Missing Link

I sådanne tilfælde er der en missing link mellem strategiens højtflyvende målsætninger og succeskriterierne for det enkelte projekt. Det kunne være fordi strategien ikke indeholder en konkret vision for virksomhedens udvikling. Men i de fleste tilfælde er det faktisk fordi styringen af de mange projekter ikke er koordineret i forhold til de overordnede prioriteter.

Det er organisering, der skal til – på flere fronter: 

• For det første skal vi sørge for at strategien er forbundet til virkeligheden, ved at virksomhedens budget og økonomistyring afspejler de strategiske mål. Hvis der skal investeres i ny udvikling, skal der være penge til det. Og når projekternes resultater skal gøres op, fx som effektivisering eller mersalg, skal det indgå i den økonomiske opfølgning.
• For det andet skal den overordnede styring af projektporteføljen, også kaldet programstyringen, være lagt i hænderne på en ledergruppe på topniveau, som har kompetence til at prioritere indsatsen og tager ansvar for at styre porteføljen af projekter frem mod de fælles strategiske mål.
• Programstyringens opgave er at omsætte strategiens mål til konkret handling, herunder at iværksætte korrigerende handlinger, hvis forløbet af et enkelt projekt ikke er alignet med de strategiske mål. Styregruppen skal derfor have adgang til et retvisende billede af den aktuelle situation, med hensyn til ressourcer, fremdrift, kvalitet og risiko i det enkelte projekt. Det kræver at virksomheden har en fælles metrik for disse nøgleparametre – og en proces for rapporteringen.

Mange virksomheder har allerede valgt at oprette et Program Management Office (PMO), som har til opgave at understøtte de 3 nøgleopgaver ovenfor. Det betyder at PMO konsoliderer projekternes rapportering, fungerer som sekretariat for styregruppen, og ser til, at beslutningerne føres ud i livet.

Hvis organisationen har behov for at udvikle sin modenhed i projektudførelsen, kan PMO desuden have som opgave at bistå projekterne med metoder, værktøjer og review af projektforløbet. På den måde kan man opnå både et strategisk løft og en bedre praksis i udviklingen.

 Download denne artikel som pdf.

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.

Udgangspunktet

Det starter med at stille de rigtige krav: Behovsopgørelsen skal naturligvis omfatte traditionelle telefonifunktioner som fx omstilling, gennemvalg, søgegrupper. Den skal også beskrive funktionaliteten af de mere komplekse telefoni-applikationer, som virksomheden har brug for, til fx et omstillingsbord, en voicemail funktion eller et call center. Noget af det sværeste er nok at definere, hvilken integration der er behov for i forhold til virksomhedens IT systemer: Der findes masser af muligheder for at sammenkoble telefonien med fx email, kalender og personaleadministrative systemer. Men hver integration har sin pris – her er det vigtigt at se på hvorledes den kan skabe værdi i den tilhørende forretningsproces. Eller med andre ord, at vurdere dens bidrag til business casen for indførelse af IP telefoni.

Planlægningen

IP telefoni kan indføres på mange måder, afhængigt af de valgte produkter. De forskellige leverandørers systemarkitekturer giver varierende muligheder for at opfylde de funktionelle behov. Og hvad angår de operationelle krav , er der også store forskelle: Man skal være opmærksom på, at mange af de tilbudte serverplatforme har ringere stabilitet end traditionelle telefoncentraler – på grund af deres større kompleksitet. Kun de færreste IP telefoni leverandører tilbyder redundante løsninger, som kan kompensere for dette – så brugerne må ofte acceptere en lavere oppetid for IP telefonien end for deres gamle telefoncentral. Her er det vigtigt at se på, om leverandørens garanterede tilgængelighed, herunder den tilbudte serviceaftale kan opfylde virksomhedens behov.

Løsningsvalget

Når man har overbevist sig selv (og sin ledelse) om, at IP telefoni er en god investering for virksomheden, er det måske tid til at se lidt på den infrastruktur, som det skal installeres på: Med IP telefoni bliver telefontrafikken uafhængig af de gamle telefonkabler i bygningerne, og de lejede telefonkredsløb mellem firmaets adresser. Her er der helt sikkert penge at spare. Men til gengæld skal telefontrafikken nu køre på de eksisterende datakredsløb og lokalnet i virksomheden, og det stiller nye krav. Når talen skal transmitteres på en datalinie, skal den have god plads, for at undgå hak i gengivelsen. Og datalinien skal have en høj kvalitet, for at undgå “dåselyd” og udfald.

For de fleste virksomheder betyder dette, at datanettet skal opgraderes, for at bære den nye trafik. Og at nettets sikkerhedsindstillinger skal justeres, for at IP telefonien ikke bliver en ny risiko for virksomheden.

Implementeringen

Nu kommer vi til en ny forhindring: Ved overgangen fra en eksisterende analog telefoniløsning ønsker de fleste kunder, at alle eksisterende telefonifunktioner bevares uændret, fx lokalnumre, eksterne telefonnumre, automatiske viderestillinger, mm.

Det kan imidlertid være svært at opnå dette, hvis den eksisterende konfiguration ikke er fuldstændigt dokumenteret – og det er den sjældent. Med mindre virksomheden råder over sin egen “ekspert” i telefoni, vil det være nødvendigt at lade leverandøren analysere den gamle konfiguration, som udgangspunkt for implementeringen af et nyt system.

Derefter skal den gamle telefoncentrals konfiguration overføres til IP-telefoni løsningen, og som regel skal denne konfigurering udføres manuelt, da administrationsfunktionerne på de to systemer er forskellige. Selvom overførslen foretages omhyggeligt og samvittighedsfuldt, er det næsten utænkeligt, at den vil være fejlfri, især for større telefonsystemer med flere tusinde lokalnumre. Det er derfor yderst relevant at gennemføre en test, der kontrollerer – eller i det mindste sandsynliggør – at konfigurationen af telefonanlægget er udført korrekt.

Også for installationen af IP-telefoner og servere på virksomhedens netværk og for integrationen til de eksisterende IT systemer er der god grund til at gennemføre en omhyggelig test af funktionerne, før løsningen sættes i drift.

De fleste brugere anser telefonsystemet i en virksomhed som en selvfølgelig funktion, der bare altid fungerer korrekt. En opgradering til IP-teknologi vil næppe blive opfattet som et stort teknologisk fremskridt for den enkelte medarbejder. Men vi kan være helt sikre på, at enhver fejl i funktionen vil blive bemærket, og enhver forringelse af lydkvaliteten vil blive kritiseret. Derfor er det afgørende, at telefoniprojektet har høj opmærksomhed på kvaliteten i både planlægning og gennemførelse.

10 gode råd om IP telefoni

1. Etabler virksomhedens egne kompetencer til specifikation, konfiguration og test af telefonfunktionerne
2. Sørg for at dokumentere den eksisterende konfiguration af telefoninstallationen
3. Vurder virksomhedens behov for at telefonisystemet integreres med andre IT-systemer (fx email, CRM system, servicedesk, HR-system)
4. Vurder i hvilken grad telefonisystemet skal integreres med den eksisterende IT-infrastruktur (netværk, serverplatforme, databaser, etc)
5. Vurder behovet for opgradering af interne og eksterne datanetværk for at IP telefonien kan benytte disse
6. Vurder hvorledes de eksisterende investeringer i apparater, netværk og telefoniapplikationer kan beskyttes ved migrering til IP telefoni
7. Kontroller om IP telefonien og telefoniapplikationerne overholder de sikkerhedskrav og -principper, som gælder for virksomhedens øvrige IT systemer
8. Gennemfør en formel test af telefonisystemet ved idriftsættelsen og ved alle fremtidige ændringer
9. Sørg for at få en garanti for den samlede løsnings stabilitet (tilgængelighed) -og for en acceptabel talekvalitet i forhold til den benyttede båndbredde
10. Etabler en løbende overvågning af systemet for at styre kapacitet og kvalitet

 Download denne artikel som pdf.

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.

Det er temaet for konferencen Forretnings- og It-arkitektur hånd i hånd som præsenterer de nationale chefarkitekter fra både USA og Canada, som står i spidsen for de respektive landes arkitekturudvikling, og en række danske Cases, som illustrerer hvordan man har draget nytte af de udenlandske erfaringer i nogle af vores mest succesfulde projekter i private og offentlige organisationer.

Konferencen afholdes den 25. oktober 2007 i Pyramiden, Dansk Industri, København, og programmet præsenteres af John Gøtze, som er formand for Association of Enterprise Architects og medstifter af tænketanken EA Fellows. Læs programmet for konferencen her.

Erfaringen viser, at det går rigtig godt for virksomheder, der arbejder professionelt med it-planlægningen, uanset om de kalder det enterprise arkitektur, SOA eller business alignment. Omvendt findes der talrige eksempler på virksomheder, som har oplevet forretningsmæssige vanskeligheder, som kan tilskrives it-problemer.

Det har hidtil været svært at sætte tal på disse sammenhænge, men nu har det anerkendte BTM Institute afsluttet en omfattende undersøgelse blandt Global 2000 virksomheder, som viser markante forskelle mellem de organisationer, som har integreret forretnings- og it-planlægningen – og de som ikke har. For eksempel:

• de it-integrerede virksomheder havde en gennemsnitlig årlig vækst i omsætningen på 12%, sammenlignet med 4% af branchegruppen som helhed
• indtjeningen pr aktie steg med 36% om året i de it-integrerede virksomheder, sammenlignet med branchegruppens gennemsnit på 7%

Undersøgelsen omfattede ca 100 private og offentlige virksomheder, hvis modenhed blev evalueret i forhold til en model, udviklet af BTM. Den økonomiske analyse af firmaernes udvikling dækker perioden 2002-2006.

Den anvendte modenhedsmodel forudsætter ikke en bestemt arkitekturproces eller udviklingsmetode, men vurderer bl.a. virksomhederne på følgende punkter:

• Governance: En konsistent proces for forretningens involvering i teknologibeslutninger, og udmelding af regler og standarder.
• Enterprise architecture: Dokumenteret sammenhæng mellem forretnings- og IT-arkitektur, som beskriver organisationen og hvorledes den vil nå sine mål.
• Strategic technology investments: Standardiserede rammer for projekter, som sikrer at de følger virksomhedens strategiske valg.

For den erfarne enterprise arkitekt er det let at oversætte disse egenskaber til EA, SOA og business alignment begreber.

Rapporten “Business Technology Convergence Index” indeholder en lang række spændende observationer, og demonstrerer med med kolde facts hvordan verdens mest succesrige virksomheder har benyttet IT til at løbe fra konkurrenterne.

I denne artikel vil vi se på de grundlæggende rammer for enterprise arkitekternes arbejde. Den kan bruges som inspiration for ledelsen – eller som checkliste for den, der søger job som arkitekt!

Rollerne

Hvis enterprise arkitekterne skal påtage sig et ansvar for den overordnede koordinering af IT systemernes udvikling, må de være i tæt samarbejde med forretningen. De skal forstå forretningsmodellen, og hvorledes den er implementeret i virksomhedens processer. Og de skal kunne foreslå forbedringer, hvor både proces og teknik er involveret.

EA teamets rolle kan være forskellig i den enkelte virksomhed: Hvis der fx allerede findes en afdeling for forretningsudvikling, vil det være naturligt at EA teamet samarbejder med denne enhed. I andre organisationer forventes det, at innovationen skal komme fra IT-siden, og her må arkitekterne have en mere proaktiv rolle.

I alle tilfælde bør mandatet for arkitekterne være forankret i et forum eller person på ledelsesniveau, og være kommunikeret ud til hele virksomheden. Det skal være klart for alle, der er involveret i forretningsudvikling og IT-anvendelse, om arkitekterne skal være lovgivende, rådgivende eller kontrollerende i forhold til virksomhedens IT-projekter, og hvorledes de skal involveres, når det gælder vedligeholdelse, udvikling eller indkøb af IT-løsninger.

Opgaverne

Når rollerne er på plads, er det tid at definere hvilke leverancer, arkitekterne skal producere. Skal de dokumentere den eksisterende arkitektur, skal de skrive principper  for udviklingen, eller skal de designe næste generation af løsninger?

Det kan isæt være nyttigt at beskrive, hvad arkitekturafdelingen skal levere i forhold til de igangværende projekter, skal de fx opstille en business case, skal de deltage i udviklingen af arbejdsgange og IT funktioner, skal de bidrage til kravspecifikationer eller bare rådgive i teknikvalget? Jo tidligere i planlægningsprocessen arkitekturteamet involveres, jo mere værdi kan de typisk tilføre. Men arkitekturleverancerne skal være veldefinerede – det er ikke nok at kommentere ad hoc gennem hele forløbet.

En naturlig opgave for arkitekturafdelingen er at vælge og udvikle en generel arkitekturproces for virksomheden, og at benytte den som referencepunkt  for alle de opgaver, der løses i den strategiske IT planlægning.

Kompetencerne

Videndeling er alfa og omega for arkitekterne. Teamet skal tilsammen dække et bredt spektrum af kompetencer, både i forretningsdomænet og i teknikken. Derfor kommer man ikke uden om at benytte både formelle og uformelle metoder til at dele erfaringer og viden. Der skal bruges kræfter på systematisk research, dokumentation og masser af interne diskussioner foran tavlen.

Når EA teamet sammensættes, bør man naturligvis lægge vægt på de enkelte personers spidskompetencer. Men det er også af stor betydning, at den enkelte arkitekt har et godt overblik over sine kollegers kompetencer, så man kan supplere hinanden.

Med gode procedurer og værktøjer til videndeling får arkitekturteamet flere fordele: Først og fremmest sparer man dobbeltarbejde, fordi ny viden kun skal tilvejebringes én gang. Men nok så vigtigt er det, at EA teamets vurderinger og anbefalinger er konsistente – for troværdighedens skyld, og for at maksimere rådgivningens værdi.

Værktøjerne

Mange organisationer ser dokumentstrukturen som det bærende element i arkitekturarbejdet. Men selvom gode værktøjer kan lette både det kreative og det administrative arbejde, kan vi ikke undvære det menneskelige aspekt. Vi anbefaler derfor at definere værktøjsbehovet på baggrund af arkitekturteamets roller, opgaver og kompetencer, som nævnt ovenfor. Eller med andre ord: Vil man følge god arkitekturpraksis, skal man starte med at afklare de organisatoriske og forretningsmæssige behov, før man griber i teknik-kassen.

 Download denne artikel som pdf.

Men en standardiseret konfiguration af brugerens pc spiller faktisk en væsentlig rolle for IT systemernes forretningsmæssige værdi. Der er nemlig her, at tiden går til spilde, og data går tabt, når teknikken svigter, eller brugeren mister overblikket.

Standardisering

Først og fremmest  bør alle pc’er være konfigureret ens – eventuelt opdelt i 2-3 arkitekturtyper. Den ene type kan fx være en traditionel Windows pc med alle kontorapplikationer installeret lokalt, mens en anden kunne være en tynd klient, fx baseret på Citrix. Mange organisationer har desuden brug for en tredje type for mobile brugere. For hver standardtype er det vigtigt at følge fælles konfigureringsregler, fx for hvilke versioner og opdateringer der skal installeres af operativsystemet og de fælles applikationer.

Forretningsapplikationer

En del virksomheder benytter forretningsorienterede applikationer, fx fagsystemer som afvikles på centrale servere, men kræver en særlig klient på brugernes pc. Det stiller som regel meget specifikke krav til pc konfigurationen, ikke blot hvad angår installationen af speciel klient-software, men også når det gælder tilhørende lokale sw komponenter som fx Java, .NET eller lokale database systemer. Selv når forretningsapplikationerne er web-baserede, vil der være mange lokale browser indstillinger, der skal standardiseres.

Managed Client

Hvis man vil undgå at IT-support medarbejderne bruger masser af tid på at betjene de brugere, der har problemer, skal den standardiserede pc konfiguration indeholde en række værktøjer, som understøtter fjernstyring og opgradering af pc’en fra et centralt helpdesk. Her kan man spare rigtig mange supportkroner, men betingelsen er altså, at installationen er standardiseret, og at brugerens muligheder for al lave lokale ændringer i forhold til standarden begrænses.

Innovation og effektivitet

Der tales meget om, at innovationen i fremtidens virksomheder skal komme fra brugerne, som selv udvikler nye måder at løse deres opgaver på. Men det behøver ikke at stå i modsætning til standardisering af pc-arkitekturen. Opgaven er at give brugeren adgang til en samling robuste og velfungerende værktøjer på pc’en, uden at styre hvorledes brugeren skal arbejde.

 Download denne artikel som pdf.

Sammenhængen mellem den overordnede planlægning af produktion og logistik, og den detaljerede styring af maskiner og processer er afgørende for effektiviteten i den moderne industri. Men IT systemerne er ofte præget af leverandørspecifikke arkitekturer, og mange integrationsløsninger er udviklet specielt til den enkelte virksomhed. Det betyder, at omstillinger og udvidelser i produktionen bliver komplekse og kostbare, og at det kniber med at skabe overblik over kapacitet og kvalitet.

Stadig flere produktionsvirksomheder vælger derfor at satse på en serviceorienteret arkitektur, der overordnet organiserer IT funktionerne i 3 niveauer:

1. Data Warehouse (DW) for den overordnede planlægning og rapportering, som understøtter den strategiske virksomhedsledelse og udgør grundlaget for den finansielle rapportering.
2. Enterprise Resource Planning (ERP), som økonomisk styringsredskab for indkøb, løn, omkostninger, salg m.m. 
3. Manufacturing Execution System (MES), som varetager den tekniske styring af produktionsapparatet (på fabriksniveau) og interfacer direkte med processtyringssystemerne.

Funktionalitet

Ved en nærmere gennemgang viser det sig ofte, at meget af systemernes funktionalitet er opbygget for at kompensere for svagheder i andre systemer. Fx er et af de vigtigste formål med fabriksstyringen (MES) at undgå afhængighed af den overordnede planlægning, så produktionen kan fortsætte selvom de overordnede systemer er utilgængelige. Tilsvarende indeholder mange ERP systemer planlægningsfunktioner, som dublerer DW faciliteterne, for at muliggøre en mere detaljeret planlægning.

Den løse kobling er i princippet et sundhedstegn, men man kan spørge, i hvilket omfang det er rationelt at dublere data og funktionalitet for at hæve oppetiden -  måske ville det være mere optimalt at investere i foranstaltninger i infrastrukturen, som hæver robustheden i de kritiske systemer – fx ved at indføre redundans i hardware og netværksforbindelser.

Datagrundlaget

Når flere forskellige systemer beskæftiger sig med de samme informationer, er der risiko for, at de bliver tolket på forskellig måde. Et ofte forekommende problem er, at grunddata i de forskellige systemer ikke er harmoniseret – således at de forskellige systemer opererer med forskellige definitioner på vigtige nøgletal, som fx  driftseffektivitet, spildprocent, energiforbrug, osv.

Hvis man sørger for, at alle beslutningstagere har det samme billede af udgangssituationen, kan man undgå langvarige diskussioner om hvorledes produktionen skal optimeres, og reducere risikoen for at tage ikke-optimale beslutninger på ledelsesplan, fordi datagrundlaget er usikkert.

En serviceorienteret arkitektur

IT-optimering i produktionsvirksomheder handler om  arkitektur: Systemer og data skal organiseres, så de optimerer effektivitet og kvalitet på en sikker platform.

• Et første skridt på vejen til at etablere en service orienteret arkitektur kan være at opbygge en central data dictionary for alle udvekslede data, således at alle nøgletal har en entydig definition, uanset i hvilket system de benyttes.
• Det andet skridt er at etablere en arkitektur, som organiserer alle beregninger – dvs.  at den definerer i hvilket (del)system en bestemt funktionalitet skal implementeres – så vi undgår overlap i funktionaliteten mellem forskellige systemer og eminimerer den usikkerhed, som altid følger af at have dobbelte data for den samme information.
• Det tredie skridt vil være at definere standarder for alle vigtige grænseflader mellem interne og eksterne systemer. Standarden bør være udgangspunktet, både når nye systemer skal anskaffes og når de eksisterende skal ombygges og videreudvikles

Med disse 3 skridt kan produktionsvirksomhederne bruge den serviceorienterede arkitektur til at skabe en bedre sammenhæng mellem de forretningsprocesser, data og IT-systemer, der understøtter planlægning og styring af produktionen.

 Download denne artikel som pdf.

Bedre IT Governance

Topledelsen taler om SOA, fordi det skaber bedre image omkring virksomheden. Til gengæld forventer man konkrete fordele ved at investere i en ny arkitektur. IT chefen bliver IT-direktør, og får ofte ansvaret for langsigtede investeringer og udvikling af nye arbejdsprocesser.

SOA bliver til EA

Den serviceorienterede arkitektur bliver den fremherskende arkitekturstil for serviceorienterede virksomheder. Og hvem er ikke det i dag? SOA bliver moden og veldefineret og vokser ind i forretningsdomænet, men vi må alle være forberedt på, at SOA bliver afløst af nye buzzwords…

Serviceorienteret forretningsudvikling

Mange virksomheder har fået øjnene op for de nye måder at bygge applikationer på nettet, kendt som web 2.0. Syndikering af indhold fra andre (eller egne) sites spiller en væsentlig rolle, ligesom Mashups viser nye veje for den traditionelle portal udvikling.

Netbaserede applikationer

Nye teknologier som fx Ruby on Rails viser vejen for letvægts-udvikling af applikationer på nettet. I de kommende år forventes netbaserede applikationer (også kaldet Rich Internet Applications) at tage væsentlige markedsandele fra traditionelle software produkter.

Porteføljestyring af IT investeringer

Der er et stigende fokus på forretningens udbytte af IT-anvendelsen, og tidligere tiders slogan “one size fits all” vil blive afløst af et balanceret valg af teknologier og produkter, som passer til virksomhedens risikoprofil og effektivitetskrav.

Fra integration til interoperabilitet

Der er stigende krav om sammenhæng mellem systemerne, men metoderne skifter: Den traditionelle, specialudviklede integration mellem applikationer afløses af åbne grænseflader, som giver adgang til en standardiseret service.

Virtualisering af infrastrukturen

Som det allerede er almindeligt ved web-hosting, vil infrastruktur i stigende grad blive tilgængelig “on demand”: Virtuelle platforme giver store fordele ved konfiguration og administration, og gør det muligt at levere maskinkraft i meget små mængder til lave priser.

Trusselsbilledet har mange aspekter: Usikre Internettransaktioner er efterhånden kendt som en væsentlig trussel mod privatlivets fred. Men også mange andre moderne teknologier kan benyttes til overvågning af personer og afluring af personlige informationer. Vi behøver blot at tænke på mobiltjenester, GPS og videokameraer.  Selv dagligdags funktioner, som fx trafikkontrol og kreditkortkøb vil som regel omfatte personhenførbare informationer, og derfor udgøre en risiko for den personlige privacy.

For at beskytte sit privatliv kan den enkelte person benytte såkaldte Privacy Enhancing teknologier, som skjuler de personlige informationer, eller gør det umuligt for andre at forbinde informationerne med en bestemt person. Beskyttelsen af de private informationer kan også opnås ved at indbygge funktioner i de anvendte netværk og systemer, som slører persondata, eller gør dem utilgængelige for misbrug. I praksis vil mange beskyttelsesforanstaltninger imidlertid kunne omgås, så valget af privacy beskyttelse vil afhænge af individets tillid til systemejeren eller producenten af den teknologi, der benyttes.

I februar 2006 offentliggjorde Videnskabsministeriet rapporten “Privacy Enhancing Technologies”, som beskriver resultaterne af en international analyse, gennemført af META Group for Ministeriet. Allan Bo Rasmussen var projektleder og hovedforfatter på rapporten, som giver en systematisk introduktion til de privatlivsfremmende teknologier, og beskriver deres funktioner og anvendelser. Her ser vi en oversigt over rapportens systematik:

Oversigten illustreres i rapporten med en række scenarier og beskrivelser af konkrete produkter, og rapporten afsluttes med en beskrivelse af følgende trends og issues:

TRENDS

• Demonstration Projects
• Acceptance Surveys
• Privacy Considerations in E-Governmant
• Review of Public E-services includes Privacy
• Corporate Privacy Solutions are Advancing

ISSUES

• Lack of a Trust Model
• Specific Provisions are Limiting Design Changes
• New Technologies are Challenging Old Legislation
• Lack of Standards
• Privacy Requires an Architecture

Hele rapporten kan hentes her: Privacy Enhancing Technologies.

 Download denne artikel som pdf.

Strategiske standarder

Valget af standarder er forbundet med mange centrale beslutninger i udviklingen af arkitektur og strategi, fx hvad angår behovet for interoperabilitet mellem systemer, og ønsket om konsolidering af IT-infrastrukturen.

De fleste er enige om, at åbne standarder er grundstenen for en tidssvarende IT udvikling. Men for den enkelte virksomhed kan det være en stor udfordring at vælge de rigtige standarder, både når man selv planlægger at udvikle løsninger, og når man skal opstille kravene ved anskaffelse af standardsystemer.

Der er mange ting at tage hensyn til: Først og fremmest er det vigtigt at vælge standarder for teknik, data og processer, som både er modne, bredt understøttet af markedets produkter, og som kan forventes holde denne position i lang tid fremover. Der findes mange eksempler på standarder, som fik et kort liv, fordi markedets store spillere valgte dem fra: Se fx X.400 protokollen for email, som i 1996 blev valgt som standard for Statens E-post. Den har ikke mange tilhængere idag.

Ved standardvalget er det også vigtigt at se på, hvilket samspil, der er behov for mellem virksomhedens systemer og i forhold til eksterne samarbejdspartnere. Sådanne beslutninger er tæt koblet til virksomhedens enterprise arkitektur, altså den overordnede organisering af processer, informationer og it-løsninger. Standarderne skal ikke vælges fordi de er “rigtige”, men fordi de medvirker til at opfylde virksomhedens forretningsmæssige mål. Begrundelsen kan fx være, at en teknisk standard medvirker til at gøre infrastrukturen simplere og mere robust, eller at den logiske sammenhæng mellem systemer reducerer behovet for genindtastning af data og andre besværlige arbejdsgange.

Business Case

De fleste beslutninger om anvendelse af standarder, er kompliceret af, at der er så mange at vælge imellem, og at de økonomiske konsekvenser er svære at overskue. Her kan det være en hjælp at opstille en business case, hvor fordele og ulemper (omkostninger) belyses med et eller flere scenarier, så standardiseringen og det konkrete valg af teknologier og løsninger kan begrundes med tørre tal.

Arkitektens katalog

Som en hjælp til at koble principper og standarder i IT planlægningen har vi i EA Fellows Kataloget samlet og kommenteret en række af de mest anvendte IT standarder, og eksempler på konkrete arkitekturprincipper.

Business casen behøver ikke at komme ud af den blå luft. Den kan opstilles på grundlag af virksomhedens arkitekturprincipper, der fortæller, hvor en standardisering er hensigtsmæssig, og peger på de standarder, det er bedst at følge i den konkrete situation. Arkitekturprincipperne skal naturligvis være velbegrundede, hvilket betyder at de kan henføres til virksomhedens overordnede mål, og at konsekvensen af at efterleve principperne er beskrevet i praksis.

Når vi på denne måde kobler principper og standarder, får vi en IT-planlægning med de to egenskaber, som virksomhedens ledelse sætter allerhøjest: For det første er udviklingen forudsigelig og giver ingen ubehagelige overraskelser, og for det andet er den optimeret i forhold til virksomhedens behov.

 Download denne artikel som pdf.

I mange af de tidlige SOA projekter var der fokus på teknologien, snarere end på princippet. Der blev ofte sat lighedstegn mellem SOA og Web Services. Gamle systemer blev moderniseret ved at man åbnede adgang til deres interne data via en række read-only Web Services, så systemer på andre platforme kunne hente data gennem det nye interface.

Denne form for SOA, som endnu praktiseres af virksomheder med mainframe baserede systemer, giver i sig selv ikke større udbytte end traditionel dataoverførsel via andre kanaler, men den er et vigtigt skridt i retning af at bygge sammenhængende systemer i stedet for de traditionelle monolitter. Det er altså primært på virksomhedens modenhedsskala, vi skal se virkningen af SOA princippet.

Et vigtigt trin i SOA udviklingen er at udarbejde en begrebsmodel for hele virksomheden, således at arkitekterne råder over byggestenene til at konstruere services, der kan genbruges. Her kan vi pege på OIOXML projektet i Videnskabsministeriet som en vigtig inspirationskilde, idet man her kan lære hvordan hvorledes man kan opbygge en begrebsmodel på specifikationsniveauet. Med begrebsmodellen i hånden kan man så gå i gang med at modellere både sine forretningsprocesser og de IT services, der skal understøtte dem. Når begrebsmodellen er udviklet til at dække en hel virksomhed, får man et stort genbrugspotentiale for de udviklede services.

Det brede scope er afgørende for at opnå forretningsmæssige fordele med den serviceorienterede arkitektur. Der er en stigende erkendelse af, at gevinsterne ikke kan høstes ved blot at optimere én enkelt proces og understøtte den med passende IT funktioner. Det er sammenkoblingen af processer og services i workflows, der giver forretningen værdi.

Med en serviceorienteret arkitektur kan integrationen realiseres uden løse ender, som fx manglende sikkerhed og sammenhæng. Forudsætningen er imidlertid, at disse egenskaber designes ind i de udviklede services, og at den samlede løsning specificeres i forhold til forretningsprocessens krav. Det kræver mere end blot at købe en SOA suite fra sin favorit leverandør. De udviklede services skal både være langtidsholdbare og lette at tilpasse til nye behov. Derfor er valget af en SOA strategi tæt forbundet med en proaktiv brug af standarder i IT-udviklingen.

 Download denne artikel som pdf.

Service Orienteret Arkitektur

Mere end 80 deltagere havde fundet vej til DANSK ITs konference om SOA , som blev afholdt den 31. oktober 2006 på Park Inn Copenhagen Airport.

Udvikling og understøttelse af forretningen

Konferencen satte fokus på koblingen mellem arkitektur og forretningsstrategi og belyste med konkrete cases, hvorfor fremtrædende virksomheder har valgt SOA som princip for deres arkitektur. Vi fik indlæg fra Arla, Danske Bank og Danmarks Radio, som fortalte om integration, sikkerhed og organisatorisk forankring af arkitekturprocessen.

Konferencen havde tillige flere visionære indlæg om SOA udviklingen, og sammenhængen mellem SOA og Enterprise Architecture. Dagen blev afsluttet med Allan Bo Rasmussens indlæg Et kig i Krystalkuglen, som gav eksempler på de nyeste trends og tips til arkitekturarbejdet.

Et uddrag af denne præsentation kan læses her: Arkitektur Trends

Kommunale servicefællesskaber

Deltagerne i kommunale service-fællesskaber skal ikke blot være enige om de tekniske valg på IT-området, men også være parate til at harmonisere deres forvaltningsprocesser så vidt, at en fælles drift kan realiseres med fordele for alle parter.

Servicefællesskab betyder at flere organisationer løser en intern (eller ekstern) opgave i fællesskab – og på en måde, som man er blevet enige om. Det kan fx handle om et IT-samarbejde mellem flere kommuner, som omfatter fælles planlægning, anskaffelse og drift af IT-løsninger, der understøtter kommunernes forvaltningsopgaver.

IT-samarbejdets primære formål er typisk at reducere omkostningerne gennem stordriftsfordele, samtidig med at IT-ydelsernes kvalitet kan højnes gennem en professionalisering af IT-organisationens leverancer. Til gengæld må den enkelte kommune, forvaltning og bruger ofte give afkald på specielle ydelser, som er tilpasset individuelle behov, fordi tilvejebringelsen af sådanne ydelser reducerer IT-organisationens samlede effektivitet.

De samarbejdende kommuner skal ikke blot være enige om de tekniske valg på IT-området, men også være parate til at harmonisere deres forvaltningsprocesser så vidt, at en fælles drift kan realiseres med fordele for alle parter. Denne strategiske udvikling bør være formuleret i en fælles IT strategi, som ledelsen i de deltagende kommuner er enige om.

Kernen i et IT-fællesskab er at formulere et sæt arkitekturprincipper, som kan bruges til en målrettet styring af IT-anvendelsen i de deltagende kommuner, herunder ikke blot de tekniske løsninger, men også forvaltningsopgavernes tilrettelæggelse, informationernes organisering og driftsopgavernes tilrettelæggelse.

Servicefællesskabet bør ikke blot have en fælles strategi og arkitektur for IT-udviklingen, men også en SLA aftale, som regulerer det løbende samarbejde. Det betyder, at der etableres et formelt leverandør-kunde forhold mellem fællesskabets deltagere og den fælles IT-enhed, med aftaler mellem parterne, hvor IT-ydelserne defineres og de gensidige forventninger afstemmes mht. omkostninger, service, kvalitet m.m.

En vigtig del af etableringen af et servicefællesskab er at beskrive og vedtage de rammebetingelser, som de deltagende kommuner og den fælles enhed skal agere inden for. Det er fx vigtigt at have klare betingelser for indtræden og udtræden af fællesskabet, og for evt. justeringer af samarbejdets omfang. Det giver fællesskabets ledelse et klart kommissorium, og definerer den økonomiske tyngdekraft, der sikrer et godt forretningsmæssigt udbytte for alle fællesskabets deltagere.

 Download denne artikel som pdf.

Principper for privacy

Dansk Industris Privacy Taskforce, som omfatter repræsentanter for Forbrugerrådet, Finansrådet, Institut for Menneskerettigheder, Digital Rights og en række af industriens specialister har netop udgivet notatet Principper for privacy, som sætter scenen for den vigtige debat om Privacy i Danmark.

IT-sikkerhed, fx som formuleret i DS484 eller ISO 17799 / ISO 27001, varetager først og fremmest dataejerens interesse. Ved privacy varetages derimod interessen for det enkelte individ, som informationen vedrører. Privatlivets fred udgør en af samfundets grundlæggende værdier, men der er mange forskellige meninger om, hvor grænsen går, når privatlivet skal beskyttes. Forskellige personer har forskellig opfattelse af begrebet privatliv, og ofte afvejes beskyttelsen af private informationer i forhold til andre behov, som fx sikring af transaktioner eller bekæmpelse af kriminalitet.

Privacy som forretningsparameter

Behovet for privacy beskyttelse i forbindelse med brug af elektroniske tjenester har i en årrække haft en begrænset opmærksomhed hos den almindelige forbruger, men nu er udviklingen vendt: Stigningen i it-baseret kriminalitet som fx identitetstyveri og spam har gjort det tydeligt, at beskyttelse af private informationer spiller en væsentlig rolle for individets sikkerhed og integritet, og forbrugerne ser i større grad på, om deres personlige informationer er i fare.

Forbrugernes ønske om en nem og sikker privacy beskyttelse skaber et stærkt behov for tjenester, hvor privacy-hensynet kan varetages, uden at sætte funktionalitet eller sikkerhed over styr.

Ved markedsføring af nye digitale servicetilbud er der således kommet fokus på løsningernes evne til at give kunderne en personlig service uden at kompromittere deres integritet. Kunderne forventer, at en seriøs serviceleverandør medvirker til at beskytte kundens privacy. Det betyder i praksis, at leverandøren ved enhver transaktion skal minimere sit behov for personlige oplysninger om kunden, og behandle de afgivne informationer på en sådan måde, at kunden er beskyttet mod krænkelser og kriminalitet.

Et grundlæggende brugerkrav til alle privacy-relaterede løsninger er, at de foruden at give sikkerhed og tryghed, samtidig skal være nemme at anvende, både konceptuelt og praktisk. Det betyder fx, at fordelene ved at anvende privacy løsningen skal være attraktive, og at anvendelsen ikke må være forbundet med ulemper eller udgifter, som får brugeren til at fravælge beskyttelsen.

Privacy-aware design

Der lanceres i disse år en lang række teknologier, som åbner mulighed for nye innovative tjenester, men som også kan true brugerens privacy, hvis ikke anvendelsesscenariet og de bagved liggende systemer og registre designes med privacy for øje. Vi behøver blot at tænke på biometri, RFID og positionsbestemmelse med GSM og GPS.

Samtidig oplever vi et stigende udbud af teknologiske produkter, der kan tilføje privacy-beskyttelse til eksisterende it-løsninger, eller hjælpe forbrugeren til at “forsvare” sig mod systemer, der ikke formodes at opfylde hans forventninger til privacy-beskyttelse.

Når disse byggesten skal sammensættes til produkter og tjenester, som kan vinde bred accept blandt forbrugerne, møder designerne ofte de klassiske barrierer i et umodent marked: Privacy begreberne er endnu ikke afklaret hos den almindelige forbruger – og slet ikke rodfæstet i den gængse it-praksis. En vigtig forudsætning for design af gode privacy-løsninger er fx at have en accepteret  referenceramme for beskrivelsen af privacy behov i forskellige situationer og kulturelle sammenhænge.

Arkitektur for privacy

Privacy-området har hidtil været et fragmenteret marked, præget af inkompatible løsninger med ringe brugervenlighed. Gennem samarbejde mellem industri og forskningsmiljøer kan der etableres et fælles grundlag for udviklingen, som skaber konvergens i løsningerne, og gør det nemmere for systemejerne at opfylde kravet om privatlivsbeskyttelse.

Der er brug for en overordnet arkitektur for privacy, som tager udgangspunkt i samfundets og individets behov, og organiserer begreber, teknologier og komponenter, som baggrund for udvikling af privacy relaterede produkter og tjenester. Arkitekturen skal fx definere rammer for anvendelsen af nye teknologier som fx anonymisering, sletning og biometri, så de kan understøtte opfyldelsen af komplekse markedskrav til fremtidens IKT-løsninger.

 Download denne artikel som pdf.

Enterprise Architecture

DANSK ITs konference om IT-arkitektur blev afholdt den 1. juni 2006 på Park Inn Copenhagen Airport.

Igen i år afholdt DANSK IT konferencen Enterprise Architecture med Allan Bo Rasmussen fra Zebranet som programkomité og foredragsholder.

Forretningsudvikling med IT arkitektur

Den velbesøgte konference satte fokus på koblingen mellem arkitektur og forretningsstrategi og viste hvorledes arkitekturprocessen benyttes som et fælles mindset for udvikling af forretning og IT. Repræsentanter fra markante virksomheder  som COOP Danmark, Danske Bank og ATP fortalte, hvordan de har organiseret deres arkitekturarbejde og hvilke resultater det har givet. Konferencen blev afsluttet med Allan Bo Rasmussens indlæg om de nyeste trends og tips til arkitekturarbejdet – se præsentationen her.

Strategi,  arkitektur og programledelse

Virksomhedsstrategien er den vigtigste forudsætning for at udvikle en sammenhængende arkitektur for forretningens processer og it-systemer. Men en overordnet programledelse er også nødvendig for at implementere arkitekturens principper i de konkrete projekter.

Professionel it-planlægning handler om at skabe sammenhæng mellem virksomhedens udvikling og de it-løsninger, der skal støtte den. Men det er ofte lettere sagt end gjort. Selv i situationer, hvor det enkelte projekt styres professionelt mod sine konkrete forretningsmål, kan det ske at virksomheden løber ind i problemer med it-anvendelsen:

I implementeringsfasen kan der fx opstå flaskehalse, fordi flere projekter har brug for de samme ressourcer på samme tid. I driftsfasen kan man savne en sammenhæng mellem systemernes data, fordi de ikke blev opbygget med en fælles arkitektur. Og i nogen tilfælde udebliver de forventede gevinster af it-projekterne, fordi de nye it-værktøjer ikke passer til virksomhedens arbejdsgange.

Symptomer som disse kan opstå, når der mangler samspil mellem it-planlægningens 3 dimensioner: Strategi, arkitektur og programledelse. Set fra arkitektens synspunkt er virksomhedsstrategien den vigtigste forudsætning for at kunne udvikle og beskrive en sammenhængende arkitektur for forretningens processer og it-systemer. Men en overordnet programledelse er også nødvendig for at sikre implementeringen af arkitekturens principper i de konkrete projekter.

Strategien er virksomhedens formulerede mål og pejlemærker, og bør lægge særlig vægt på at beskrive den udvikling, som virksomheden ønsker – eller er nødt til – at gennemføre. Forandringen kan fx handle om at levere nye produkter eller løse nye opgaver, eller om strukturelle ændringer i forbindelse med virksomhedsfusion eller flytning. Strategien skal være så konkret, at den kan bruges ved organiseringen af virksomhedens opgaver, og de it-løsninger, der skal støtte arbejdsprocesserne. Hvis strategien ikke er præcist formuleret, eller hvis den indeholder modstridende mål, kan det være svært – eller umuligt – for it-arkitekterne at organisere it anvendelsen, så den understøtter forretningen.

Arkitekturen beskriver ikke blot it-løsningernes struktur, men også sammenhængen mellem forretning og it. Her er det engelske begreb Enterprise Architecture mere dækkende end blot it-arkitektur. For arkitekturen handler om at organisere arbejdsprocesser, informationer og it-løsninger, således at de samlet set giver det optimale udbytte for virksomheden. Arkitekturarbejdets resultater er et grundlæggende sæt principper, som virksomheden vælger at følge ved anskaffelse, udvikling og anvendelse af it. Principperne bliver fx brugt som krav til projekter og eksterne ydelser, og som rettesnor for virksomhedens egne it-beslutninger.

Programledelsens opgave er at koordinere de konkrete forandringsprojekter, som udspringer af planlægningen. Programledelsen skal sikre kontinuiteten i it-udviklingen og styre projektporteføljen, så den samlet set understøtter virksomhedens strategiske mål. Det betyder fx, at alle projekter følger de aftalte arkitekturprincipper, og at de givne ressourcer udnyttes optimalt.

Ofte hører man, at det er et specialistjob at være it-arkitekt. Ja måske, men ikke et teknikerjob. Det er et speciale i kommunikation, i at formidle budskaber og facilitere en proces. Opgaven er at motivere både ledelsen og den enkelte projektmedarbejder til at benytte helikopterperspektivet, når der skal planlægges og optimeres.

 Download denne artikel som pdf.