Denne artikel stammer fra det trykte Computerworlds arkiv. Artiklen blev publiceret den Computerworld d. 25. februar 2005.
... eller hvorfor en arkitektur ikke er det værste, man kan have
Færre fejlinvesteringer, overblik over konsolideringsmuligheder, fleksible og fremtidssikrede systemer. Ifølge tre danske it-chefer er det bare nogle af de fordele, der kan høstes ved at arbejde med plantegningen for it-installationernes
fremtid.
Hos handelsvirksomheden Procudan er it-chef Michael Iversen ansvarlig for et større egenudviklet ERP-system, der med hans ord gennem tiden er blevet tilrettet "ind i Hel.... et rigtig varmt sted". Han plejer en urskov af undersystemer og et CRM-system, som det aldrig rigtig er lykkedes at integrere med det gamle ERP-system.
Nu vil ledelsen gerne kunne bruge selskabets website mere aktivt over for kunder og partnere ved brug af webservices, en investering i et nyt ERP-system ligger og lurer som en mulighed i en ikke så fjern fremtid, og Michael Iversen ville ønske, at han havde en plan for systemernes fremtid.
Derfor overvejer han at gå til ledelsen. Han vil gerne have opbakning til at få lavet en arkitektur for selskabets systemer.
- Vi er godt klar over, at denne situation ikke går i længden. På overfladen kan vores systemer præcis det, de skal kunne, men under overfladen er vores it kun et lille skridt fra at være en reel forhindring for de ting, vi gerne vil i forretningen. Vi er knapt nok på første trin, hvad angår at have en plan for vores systemer, men der er ikke tvivl om, hverken hos mig eller ledelsen, at det ville være godt at have en, før vi går ud og investerer i blinde, siger han.
Den erkendelse er Michael Iversen ikke alene med. I det offentlige såvel som i det private får arkitekturarbejde stadig stigende anerkendelse som redskab til at skabe synergi mellem it-installationer og forretningsstrategier.
Ifølge Rambøll-rapporten, IT i praksis 2004, steg antallet af private virksomheder, der planlægger it-arkitekturen ud fra ledelsens forretningsmål, fra 69 til 75 procent mellem 2003 og 2004. I rapporten går Rambøll-konsulenterne så langt som til at sige, at enhver leder, der ikke er opmærksom på arkitektur som et centralt styringsinstrument, vil tabe terræn.
Hvad forretningen vil
Enterprise Architecture eller virksomhedsarkitektur er en tanke, der har eksisteret i de seneste ti år. Målet er en model for, hvordan arkitekturen for både forretning og systemer skal smeltes sammen.
Når arkitekturarbejdet de seneste tre år er blevet genstand for fornyet interesse, er det ifølge senioranalytiker hos IDC, Frank Gens, drevet af en kombination af nettets muligheder for ny forretning og en række nye krav fra ledelsen til it-afdelingen. Applikationerne skal understøtte forretningsprocesserne bedre. Med ønsket om at være fleksibel i et omskifteligt forretningsmiljø kræver ledelsen, at nye forretningsideer kan implementeres hurtigere, uden endeløs venten på it-afdelingen. Og frem for alt skal it fortsat være så billigt i drift som muligt.
For it-afdelingerne er det nemmere sagt end gjort, men ifølge Gens er arbejdet med arkitektur et rigtigt skridt på vejen.
- I mange virksomheder er applikationerne svære at integrere. Informationerne ligger fragmenteret i mange systemer, der gør det svært at få de rigtige informationer på rigtig tid og sted. Den tekniske infrastruktur er langsom, tager tid at ændre, og mange års knopskydning i applikationsporteføljen gør det hele dyrt at vedligeholde. Arkitekturarbejdet kan give dig et overblik over, hvor der er mulighed for besparelser, hvor de største problemer i installationerne ligger i forhold til virksomhedens ønsker samt en pragmatisk tilgang til, hvordan du bedst løser problemerne - et projekt af gangen. Arkitektur behøver ikke, at være en storslået masterplan for alting, siger han.
Han peger på, at specielt konsolidering af den tekniske infrastruktur og applikationsporteføljen er blandt de lavt hængende økonomiske frugter, som kan høstes i forbindelse med, at man konstruerer en arkitektur.
- Når du har overblikket over systemparken, er det et godt sted at starte. Det er en måde at skære i udgifterne til drift, siger Frank Gens.
Opdagede ekstra it-afdeling
Den har man fanget hos spiseolieproducenten Aarhus United. Her er målet at have en "lean-arkitektur".
Få it-medarbejdere skal kunne understøtte alle dele af forretningen, og installationernes TCO (Total Cost of Ownership) skal holdes så langt nede, som muligt. Midlet for at opnå den "slanke" arkitektur er konsolidering og atter konsolidering.
For den del af arkitekturen, der understøtter administrationen, er projektet lykkedes. Virksomheden har, ifølge it-direktør Henrik Amsinck, konsolideret med hård hånd, når det gælder Notes og SAP, og har høstet de økonomiske fordele ved at skulle vedligeholde færre systemer. Selv den bedst beskrevne og implementerede arkitektur kan imidlertid have mangler.
I starten af 2004 var Henrik Amsinck beskæftiget med at indføre samme SAP-konfiguration, som var en succes i Danmark, i datterselskaberne i England og USA, for også at høste konsolideringsgevinsterne dér. Midt i projektet blev Aarhus United dog sat til salg.
- Salgsplanerne betød, at vi i stedet rettede blikket indad i virksomheden, ikke mindst mod vores produktionsafdeling.
Der fandt han og systemchef, Esben Viskum, i realiteten en it-afdeling, som havde fået lov at leve adskilt fra den teknologiske udvikling, som var sket i administrationen, og hvis it-installationer ikke levede op til "lean-arkitektur"-planen.
Afdelingens titel er Automatik og står for den teknologi, der styrer produktionsanlæggene hos Aarhus United. Teknologi, som historisk har været mekanik, men som så meget andet har bevæget sig over i it-verdenen.
- Hver gang, der er blevet købt et nyt produktionsanlæg, har man også fået et processtyringssystem med. Nu er der fem forskellige. Det har fået lov at køre uden tanke på opdateringer, platformkonsolideringer eller integration. Det kan godt være, at det er billigt ud fra en øjeblikkelig betragtning, men det er dyrt i forhold til drift og vedligehold. De fordele, vi kunne have ved at køre et uafbrudt workflow med minimal menneskelig indblanding - fra ordren ruller ind i vores SAP-system til ventilerne i produktionsanlægget åbner - går tabt på grund af manglende integration og standardisering, siger Esben Viskum.
Og to it-afdelinger i samme selskab? Den går virkelig ikke.
Så med arkitekturplanen som ledestjerne er et nyt konsolideringsprojekt nu i gang hos Aarhus United.
- Vi har startet et samarbejde med vores produktionsafdeling, så vi får en samlende arkitektur og en it-afdeling for hele virksomheden, siger Henrik Amsinck.
Serviceorienteret fornuft og fleksibilitet
Mens konsolidering hører til de lavt hængende frugter, der kan høstes i forbindelse med arkitekturarbejdet, er integration og genbrug placeret noget højere på træet.
De to begreber hænger tæt sammen med de seneste års største buzzword inden for arkitekturarbejdet - serviceorienteret arkitektur (SOA). Serviceorienteret arkitektur knytter sig til den måde, man integrerer, udvikler og generelt opbygger virksomhedens systemlag. (se også "Genvejstasten til SOA" på side 14).
For fire år siden lancerede ledelsen fra Europæiske Rejseforsikring en ny strategi. Forsikringsselskabet skulle gøres til en selvbetjeningsforretning for erhvervskunder og partnere.
It-direktør Arne Svejgaard stod med en håndfuld gamle systemer på mainframe, der absolut ikke var gearet til forretningens selvbetjeningsstrategi. Der var to valg. Enten skulle de gamle systemer over på en ny platform i en en til en-migrering, som ville kræve nyudvilkling fra bunden, eller også skulle man forsøge at give dem et længere liv. En levetidsforlængelse der samtidig inkluderede udvikling af webservices til kunderne. Valget faldt på det sidste, og det blev startskuddet til Europæiske Rejseforsikrings serviceorienterede arkitekturarbejde.
- Spørgsmålet er, hvorfor det er vigtigt at have en arkitektur. Egentligt er det meget enkelt. Jo bedre du kender dine systemer, desto bedre kan du træffe de rigtige valg og ikke mindst overskue de fremtidige konsekvenser af dem. Et en til en-migreringsprojekt af det omfang, vi stod overfor, ville have været økonomisk fatalt. I den periode var it-budgettet fastfrosset. Der var ikke penge til både at udvikle nye tjenester og samtidig erstatte de gamle systemer, og havde vi forsøgt, tror jeg ikke, jeg ville være it-chef i dag. Og jeg ved, at virksomheden ikke ville have haft de salgs- og servicekanaler, vi nu tilbyder vores samarbejdspartnere, og som ledelsen stillede krav om, siger Arne Svejgaard.
I stedet for at migrere systemet, valgte Europæiske at stille funktioner fra de interne systemer til rådighed for kunder og partnere ved hjælp af webservices.
Rapportering af rejsedage, indsigt i skader og status på rejsedage, policer og dækning, stilles eksempelvis nu til rådighed som services for alle erhvervskunder. De kan søge egne informationer via nettet i stedet for at belaste selskabets Call Center.
De samme services kan bruges af Europæiske Rejseforsikrings assistancecentre rundt om i verden, og på den måde genbruges det arbejde, der allerede er udført af flere eksterne parter i et væld af selvbetjeningsprojekter.
- Det har gjort os og virksomheden mere fleksibel. Vores "time to market", altså den tid, der går fra virksomheden kommer med en ide, til den er implementeret, er blevet meget kortere. Hvis du ikke har overblikket i form af en arkitekturplan, skal du til at skabe dig overblik fra projekt til projekt. Med arkitekturplanen, har du overblikket og kan langt hurtigere se, hvilke processer du skal pille ved fra gang til gang. Det gør det nemmere at estimere over for forretningen, hvad et nyt projekt kommer til at koste, og hvor lang tid det tager, siger han.
Mens den serviceorienterede arkitektur er det brandvarme emne inden for arkitektur, er det samtidig et kompliceret stykke planlægnings- og udviklingsarbejde, der venter de virksomheder, som vil implementere det i større skala. Hos PFA brugte 40 mand fra et eksternt konsulenthus for nylig 11 måneder på en portalløsning med serviceorienterede tjenester.
For mindre virksomheder kan den type investeringer virke uoverskuelige. Men ifølge arkitekturanalytiker, Phil Allega, Meta Group, er det en misforståelse at tro, at en arkitekturplan pr. definition fører tunge projekter med sig.
- Det er vigtigt at forstå, at det at lave en arkitektur ikke betyder, at du død og pine skal gå væk fra dine gamle dos-systemer, og kaste dig ud i et avanceret serviceorienteret arkitekturprojekt. Det er meget muligt, at dine gamle systemer gør lige præcis det, de skal - nemlig understøtte din forretning, forretningens processer, mål og strategi. Pointen med en arkitektur er i høj grad at få overblik nok til at vide, om systemerne gør det eller ej, siger han.
Undgå fejlinvesteringer
Overblik var også målet for it-chef hos Q8, Henrik Trepka. Han begyndte arkitekturarbejdet for fire år siden. Det var et europæisk projekt, som dels skulle skabe bedre overblik over it-installationerne i Q8's ti europæiske datterselskaber og dels forbedre sammenhængen mellem dem. Hos Q8 var man plaget af ustabil infrastruktur og en voksende applikationsportefølje. En oplagt løsning var konsolidering. Mens det på infrastruktursiden var relativt problemfrit, så billedet anderledes ud for applikationsporteføljen.
- Man bør aldrig slippe konsolidering som mål, men vi havde kig på en løsning, hvor alle vores datterselskaber skulle samles på en SAP-konfiguration. Det forudgående arbejde med vores arkitektur viste imidlertid, at det ville have været en fejlinvestering.
Problemet hos Q8 var, at forretningsmodellerne i de enkelte lande adskilte sig markant. Der var med andre ord en grund til, at de blev understøttet af en række forskellige systemer.
- På overfladen er det nemt at sige: I sælger benzin, hvor svært kan det være at få det til at køre på samme platform? Men mens man i Italien udelukkende sælger benzin videre til en forhandler, sælger man i Danmark kanelsnegle på hver eneste tankstation. At få alle vores forretningsmodeller over på samme konfiguration ville resultere i så mange tilretninger, at vi reelt ville drive fire forskellige SAP-installationer, og at økonomien ville gå fløjten. Der er i de situationer, det er rart at have en plantegning at se på, inden man trykker på aftrækkeren til en ide, der på overfladen lyder rigtig god, siger han
Hvad er hagen?
Blandt it-cheferne er der ikke er tvivl om fordelene ved at have en arkitektur. Spørgsmålet er så, hvad hagen er ved at kaste sig ud i projektet.
Den primære er, at det ikke er gratis. Det tager tid at at lave et aftryk af forretningen og af it-installationerne, samt at definere fremtidige projekter og at udarbejde regler for systemerne. Skal planerne implementeres i form af konkrete projekter, koster det også penge. Så ledelsen skal være med på ideen. Richard Haagensen er it-arkitekt hos ATP. Her skal 18 mand bruge fem år på opbygning og implementering af en ny arkitektur.
- Arkitekturarbejde kan godt starte fra it-afdelingen, men hvis du har en eksisterende systempark, der egentlig kører godt nok, er det svært over for ledelsen at argumentere for de investeringer, det kræver. Det er en investering i fremtiden, og der vil altid være nogen, der spørger om den konkrete business-case, siger han. Han understreger dog, at det ikke er nogen undskyldning for at undlade at lave det basale stykke arbejde med at identificere, hvad man har, og hvor man er på vej hen, set fra et systemmæssigt synspunkt.
Hos Europæiske Rejseforsikring peger Arne Svejgaard på, at teknologiens konstante udvikling gør det svært at lave en fast arkitektur.
- Man beskriver en arkitektur ud fra de elementer, der kan fås lige nu eller lige om lidt og laver så en plan for, hvornår man vil indføre dem. Problemet er, at der hele tiden kommer nye, bedre muligheder, der helt kan - og ofte bør - ændre planen, siger han.
Administrerende direktør for analyse- og konsulenthuset Gartner, Henrik Zangenberg, anbefaler derfor en pragmatisk tilgang til projektet:
• At skabe en ny arkitektur fra bunden kan tage ti år for en større virksomhed, så for de fleste er det bedste råd, at man skal begynde med "godt nok".
• Sæt to måneder af til at lave den første version. Hvordan er vores it forbundet med det forretningsmæssige økosystem, og hvordan skal det se ud?
• Lav en version 1.0 - en kontur af bjerget. Find så ud af, hvilket projekt skal være den første basecamp og gå efter at få det implementeret.
Billedtekst:
- Arkitekturen er et brugbart forandringsværktøj, og som it-afdeling er du med en god arkitektur også langt mere forandringsparat, siger it-direktør, Arne Svejgaard, Europæiske Rejseforsikring.
Foto: Torben Klint
Billedtekst:
- Vi har startet de indledende forhandlinger med vores produktionsafdeling, så vi får en samlende arkitektur og en it-afdeling for hele virksomheden, siger Henrik Amsinck, Aarhus United.
Foto: Niels Aage Skovbo
Billedtekst:
- Arkitekturarbejdet kan give dig et overblik over, hvor der er mulighed for besparelser, hvor de største problemer i installationerne ligger i forhold til virksomhedens ønsker samt en pragmatisk tilgang til, hvordan du bedst løser problemerne, siger senioranalytiker Frank Gens, IDC.
Boks:
Arkitektur 101
Der er flere måder at forstå begrebet arkitektur på. En af dem siger, at hvis du har systemer kørende, har du pr. definition en arkitektur. Den er givet af den måde, systemerne spiller sammen på, og kan være mere eller mindre sammenhængende og forretningsunderstøttende.
Den gængse forståelse er imidlertid, at en arkitektur forudsætter noget planlagt. Her er arkitekturen din plan for, hvordan din systempark bedst kan understøtte forretningens mål. Det lugter lidt af it-strategi, men det stikker et teknisk spadestik dybere.
En arkitektur er en plantegning af, hvad it-afdelingen har. Det er en køreplan for, hvad it skal have af systemer og projekter, for at kunne understøtte virksomheden nu og i fremtiden, og det er regler for, hvordan de enkelte komponenter i arkitekturen skal se ud.
En arkitekturplan kræver derfor overblik over følgende.
• Virksomhedens strategi og forretningsprocesser. Hvordan tjener virksomheden penge i dag, hvilke forretningsprocesser er involveret. Vigtigst af alt, hvordan har virksomheden tænkt sig at tjene penge i fremtiden.
• Informationsarkitekturen i virksomheden. Hvilke informationer bliver brugt i hvilke forretningsprocesser og af hvem. Hvilke regler gælder for informationerne, hvem har adgang til dem, hvilke applikationer "ejer" data.
• Applikationsporteføljen. Hvilke applikationer eksisterer i virksomheden, hvilke forretningsprocesser understøtter de, hvordan er de integreret.
• Den tekniske infrastruktur. Netværket og hardwaren. Hvor mange servere havde du egentlig, sidst du talte?
Med en perfekt implementeret arkitektur i en perfekt verden understøtter informationer, applikationer og den tekniske infrastruktur forretningsstrategi og forretningsprocesser nu og i fremtiden. I en mindre perfekt verden kan du se på plantegningen, finde ud af hvor der er afvigelser i forhold til dine systemer og hvad forretningen ønsker at gøre, og så tage den derfra.
Boks:
Genvejstasten til SOA
For dem, der ikke voksede op i maskinstuen, kan forsøget på at forstå tidens største buzzword inden for it-arkitektur, "den serviceorienterede arkitektur (SOA)", være lidt af en udfordring. Virksomhedens udviklere vil med største selvfølgelighed sige ord som "løse koblinger" og "indkapslede softwarekomponenter", og de fleste vil - hånden på hjertet - kun være blevet marginalt klogere efter den forklaring.
Så hvad går SOA egentlig ud på?
Serviceorienteret arkitektur er en model, der knytter sig til, hvordan man kan konstruere systemlaget i virksomhedens samlede arkitektur.
Nøgleordet er selvfølgelig service.
En service er en funktion. Det kunne være den funktion i et lagersystem, der angiver, hvor meget der er på lager af vare X. Det kunne også være den funktion i et økonomisystem, der udregner kreditværdigheden for distributører. Eller en service udviklet fra bunden, der foretager kreditkorttransaktioner.
Traditionelt er applikationer udviklet som store monolitter, hvor alle systemets funktioner har været tæt integreret i hinanden. Det har gjort det svært for virksomhederne dels selv at bruge funktionerne fra andre systemer end monolitten og at udskifte eller rette i funktionen, dels at lade partnere og kunder bruge funktionen på en enkel måde via nettet.
Grundideen i den serviceorienterede arkitektur er at bryde de store systemer ned i funktioner og tilbyde de funktioner som services. Tænk legoklodser.
Servicen er en selvstændig lille applikation. Den er ikke koblet til noget bestemt system, og den er ligeglad med, hvilken type system, den skal tale med, og den kan "klikkes sammen" med andre legoklodser på kryds og på tværs. Det er her, betegnelsen løs kobling kommer ind. En service er en funktion, der ikke koblet til noget bestemt system. Og det vinder indpas i mange virksomheder, fordi det letter integrationen.
Der er forskellige måder at tilbyde services på. Man kan udvikle dem fra bunden, eller man kan tage allerede eksisterende funktioner fra eksempelvis et større gammelt system og groft sagt pakke dem ind i kode, der indadtil taler det gamle systemsprog og udadtil kan tale med andre applikationer.
Det kaldes indkapsling eller wrapping, og det er grundlaget for en af de helt store fordele ved SOA.
Du kan genbruge funktioner i de gamle systemer og tilbyde dem til intern og ekstern brug. Uden at skulle skifte skifte platform.
I en gennemført serviceorienteret arkitektur er der ingen store systemer. Hele systemlaget er bygget op af services, der ligger som selvstændige funktioner på virksomhedens netværk, hos samarbejdspartnere som måske har funktioner, du kan bruge, eller hos selvstændige udbydere, der laver en forretning ud af at udvikle avancerede services og tilbyde dem til virksomheder, som ikke selv har dem og ikke vil bruge tid på at udvikle dem fra bunden.
Boks:
Træd varsomt
I arbejdet med arkitektur er der ting, som er vigtige og ting, der er mindre vigtige. Hvis du laver din arkitektur ud fra et teoretisk synspunkt, bør du være ansat på universitet. Tag ideerne, og se om de passer virksomheden, put derefter en sjat pragmatisme oven på. Der er mange fremadskuende arkitekturelementer, som ser godt ud på papiret, men hvor teknologien ikke er klar. Din arkitektur skal død og pine virke i den virkelige verden. Richard Haagensen, It-arkitekt ATP
Lad være med at gå til topledelsen og begynd at diskutere de elementer, hvor det lynhurtigt kan gå hen og blive tung teknisk snak. Hold det til powerpoints og pile. Selv om vi gerne vil sige, at vi er forretningsdrevne og arbejder tæt sammen med resten af virksomheden, så er der altså nogle ting, som bedst holdes i it-afdelingen. Grib i stedet casen, når du ser den, og vis, hvordan det kan virke. Jo mindre case, jo bedre.
Arne Svejgaard, It-direktør Europæiske rejseforsikring
Husk at skære igennem. It-folk er ofte højtuddannede, og der er mange discipliner inden for faget. Der er mange meninger om arkitektur i en it-afdeling. Man skal lytte, men man skal også være parat til at sige, ok.. så er det den her vej, vi vælger.
Ricard Haagensen, it-arkitekt ATP
Den klassiske fejl er, at du oversælger projektet og præsenterer ledelsen for en arkitektur, der giver maksimum fleksibilitet og uden nogen begrænsninger. Det eksisterer ikke. Arkitekturarbejde handler i høj grad om fravalg, fordi et af målene er at mindske kompleksiteten i dine systemer.
Henrik Zangenberg, administrerende direktør Gartner
