Enterprise application integration vid Aftonbladet

Transkript

1 Enterprise application integration vid Aftonbladet Ian Vännman TRITA-NA-E03140

2 NADA Numerisk analys och datalogi Department of Numerical Analysis KTH and Computer Science Stockholm Royal Institute of Technology SE Stockholm, Sweden Enterprise application integration vid Aftonbladet Ian Vännman TRITA-NA-E03140 Examensarbete i medieteknik om 20 poäng vid Programmet för medieteknik, Kungliga Tekniska Högskolan år 2003 Handledare på Nada var Alex Jonsson Examinator var Nils Enlund

3 Sammanfattning Detta examensarbete utfört vid Aftonbladet under 2003 behandlar enterprise application integration (EAI) och applicerar EAI-teorier och verktyg för att integrera användarhanteringen av de redaktionella produktionssystemen vid Aftonbladet. Det är utfört i nära samarbete med Marcus Olofsson och hans examensarbete Arbetsflödesstyrsystem vid Aftonbladet och uppsatserna delar inledning, metod, en sammanfogande del av det praktiska arbetet, slutsatser och rekommendationer. Det finns ingen allmän term för enterprise application integration på svenska. En möjlig översättning är organisationssystem integration. Då branschförkortningen är EAI används den i hela uppsatsen. Vid Aftonbladet finns den redaktionella helpdesken. Deras huvudsakliga uppgift är att utveckla system och utbilda användare. Men en stor del av arbetstiden läggs på att utföra användaradministrativa uppgifter i tio olika grafiska användargränssnitt. Denna situation har uppstått på grund av att organisationens system har utvecklats i en förhållandevis hög takt där den användaradministrativa funktionaliteten ej varit prioriterad. Omständigheterna för helpdesk har förvärrats av att personalomsättningen vid Aftonbladet är mycket hög. Denna situation är inte ovanlig vid IT-baserade företag som har genomgått samma snabba utveckling och är i ett hårt ekonomiskt klimat. Syftet med examensarbetet är att undersöka hur man kan integrera organisationens system i varandra så att de kan dela användardata och om detta ej är möjligt, undersöka vilka andra möjligheter finns det för att integrera systemen. I förlängning ska detta arbete leda till tids- och kostnadseffektivisering för helpdesken vid Aftonbladet. För att uppnå syftet granskas EAI, inklusive integrationsmodeller och middleware. Med denna information presenteras, Linthicums tolv steg, ett verktyg för implementering av EAI. Detta verktyg används sedan för att utveckla en EAI-lösning inom problemområdet vid Aftonbladet. EAI-lösningen vid Aftonbladet sammanbinder användaradministrationen av alla, med ett undantag, produktionssystem. I EAI-lösningen ingår ett gränssnitt som används av Marcus Olofsson för att bygga ett arbetsflödesstyrssystem. I lösningen används olika integrationsmodeller, middleware och standarder. Standarder som används är LDAP, RADIUS, NetInfo, HTTP och SQL. Programmeringsspråk som används är PHP, Perl, Applescript och JSP. Serverprogramvara som används är Mac OS X Server, Apache, MySQL, OpenLDAP och OpenRADIUS. Middleware som används är pam_ldap, nss_ldap, MySQL och PHP. Arbetet visade att det finns många olika sätt att lösa integreringen. Det viktiga är att identifiera och utnyttja gränssnitt som systemen tillhandahåller. System som kan kommunicera via öppna standarder är lättare att integrera. Från arbetet, diskussionen och slutsatserna ges rekommendationer till Aftonbladet för framtida utveckling.

4 Abstract This Master s thesis was carried out at Aftonbladet in The subject area is enterprise application integration (EAI) and applies EAI theories and tools to integrate the user administration of the production systems at Aftonbladet. The master s thesis is completed in close cooperation with Marcus Olofsson and his Master s thesis Workflow management systems at Aftonbladet and shares the introduction, method, unification of the practical work, conclusions and recommendations. Aftonbladet is Scandinavia s largest newspaper and daily news web site. At Aftonbladet there is a computer helpdesk. Their primary responsibility is to develop systems and educate users. However, a large part of their time is spent on user administrative tasks in up to ten different graphical user interfaces. This situation has grown out of the explosive development of the enterprise systems in which the user administrative functionality has been a low priority. The circumstances have worsened due to the high staff turnover at Aftonbladet. This situation is not unusual at IT based enterprises that have experienced the same rate of development and are now facing a harsh economic climate. The purpose of this Master s thesis is to investigate how one can integrate the enterprise s systems with each other in order to share user data and if that is not possible, investigate what other possibilities there are for system integration. In the long run this investigation is going to lead to time and cost improvements for the helpdesk at Aftonbladet. In order to fulfill the purpose EAI is examined, including integration models and middleware. With this information at hand, a tool for the implementation of EAI, Linthicum s twelve steps, is introduced. This tool is then applied within the problem area at Aftonbladet. The EAI solution at Aftonbladet integrates the user administration of all, with one exception, production systems. The EAI solution includes an interface that is used by Marcus Olofsson in his workflow management system. The solution employs different integrations models, middleware and standards. Standards that are used are LDAP, RADIUS, NetInfo, HTTP and SQL. Programming languages that are utilized are PHP, Perl, Applescript and JSP. Server applications that are used are Mac OS X Server, MySQL, Apache, OpenLDAP and OpenRADIUS. Middleware that is used is pam_ldap, nss_ldap, MySQL and PHP. The project s results showed that there are many different ways to work out the integration. It is most important to identify and take advantage of the interfaces that the systems make available. Systems that can communicate using open standards are simpler to integrate. From the work performed, the discussions and conclusions recommendations are given to Aftonbladet for future development.

5 Innehållsförteckning 1 Inledning Bakgrund och problembeskrivning Syfte Frågeställningar Avgränsning Metod Tillvägagångssätt Enterprise Application Integration Bakgrund Definition av EAI Integrationsmodeller Middleware Fördelar med EAI Nackdelar med EAI Verktyg Linthicums tolv steg till implementering av EAI Admin 2.0 ett EAI projekt Steg Steg Steg 3 & Steg Steg 6 & Steg Steg Steg Steg Steg Sammanfogande Helhetslösningen Konfiguration av dator Värdesättning Diskussion Slutsatser EAI Arbetsflödesstyrsystem Rekommendationer Framtida utveckling Kravspecifikation Referensförteckning Böcker Artiklar Internet Övriga källor...60 Bilaga 1: Definitioner av teknologier

6 1 Inledning 1.1 Bakgrund och problembeskrivning När vi kontaktade Mattias Nyman, IT-Chef vid Aftonbladet, för att fråga om det möjligtvis fanns ett examensarbete vi kunde genomföra visade han oss en rapport han precis skrivit. Den skrevs tillsammans med Susanne Wahlström som ett arbete för den MBA-utbildning han följer på Handelshögskolan i Stockholm. Rapporten, Processanalys av Aftonbladets helpdesk som en grund för en ABCkalkyl, hade som syfte att göra en förberedande processanalys för att upprätta en Activity Based Costs kalkyl. Arbetet identifierade aktiviteter och kostnadsdrivare för de användaradministrativa uppgifterna som utförs av Aftonbladets redaktionella helpdesk. På Aftonbladets tekniska avdelning finns den redaktionella helpdesken. Den består av sju personer och arbetet sker mest på vanlig kontorstid, men också på natten. En stor del av arbetstiden används till att administrera information om användare, rättigheter och behörigheter till de system som används. Denna situation är vanlig vid stora organisationer, speciellt inom media då de nyttjar så många olika produktionssystem Desktop publishing revolutionen I och med desktop publishing revolutionen på mitten av 1980-talet uppstod den här situationen inom media. Medieteknikbranschen utvecklade fler och fler datorbaserade lösningar för tidningsproduktion. Till slut var hela produktionsledet digitaliserat. Från reporterns artikel i texthanteringssystemet och fotografens digitala bild i bildarkivet, via redigerarens uppslag i layoutprogrammet, till tryckförberedande processer och överföringen till tryckeriet. När tidningarna efter mitten av 1990-talet började publicera på internet ökade mängden produktionssystem återigen. Alla dessa system byggdes parallellt i hög takt. De ekonomiska vinningarna var uppenbara och ingen tanke lades på vad det ökade administrativa arbetet innebar i form av tid och kostnader. Av funktionsmässiga skäl och av säkerhetsskäl kräver dessa system att användarna har behörigheter och rättigheter i systemen. Utvecklarna av systemen fokuserade inte på de administrativa användargränssnitten, eftersom det inte var prioriterade funktioner. Ur marknadsföringsperspektiv är det intressanta med ett system vad det kan åstadkomma, inte hur man lägger till en användare i det. Detta ledde till en situation där organisationerna har mängder med system som alla har olika sätt att hantera användare på. Dessa administrativa användargränssnitt är ofta ej användarvänliga och därför omöjliga för den personaladministrativa avdelningen att nyttja. De enda med kompetens att hantera systemen är den tekniska avdelningen, som därmed får ta hand om dessa administrativa uppgifter Hög personalomsättning Aftonbladet har en hög personalomsättning vilket orsakas av det vikariesystem som tillämpas. Vikarierna arbetar mellan tre och elva månader. Även en hel del projektanställda medarbetare strömmar igenom. Årligen börjar och slutar ca 170 personer på redaktionen. 1

7 Denna situation, med mycket hög personalomsättning, är utbredd inom mediabranschen och sprider sig även till andra branscher. I det hårda ekonomiska klimat som råder undviker företag att tillsvidare anställa personal. Företagen strävar efter att ha hög flexibilitet i personalhanteringen. Genom att ha en hög andel av arbetskraften anställda som vikarier och som projektanställda ökar denna flexibilitet. Även kostnader associerade med nedskärningar minskar då Uppdraget Mattias och Susannes rapport tar upp hur den tekniska ledningen misstänker att för mycket tid läggs på att manuellt administrera användare. Ledningen vill därför inleda ett projekt för att rationalisera och automatisera administreringen av användare. Målet med projektet är att mer av helpdesks tid ska läggas på utbildning av användare och utveckling av system som stödjer produktionen genom att få bort onödigt rutinarbete. Mattias Nyman föreslår därför att vi inom ramen för våra examensarbeten ska applicera våra kunskaper inom IT-management för att åstadkomma tids- och kostnadsbesparingar för helpdesks administrering av användare vid Aftonbladet. Med vetskapen om att detta problem är utbrett inom hela mediebranschen och i många andra IT-baserade branscher åtog vi oss uppdraget Mätbarhet För ledningen är det viktigt att kunna utvärdera effekterna av ett projekt och då krävs det någon form av mätbarhet. Mattias och Susannes rapport redovisar kostnaderna för att administrera en användare som börjar, slutar, byter avdelning eller byter arbetsuppgifter och utgör därmed ett bra underlag för att kunna utvärdera effekterna av projektet. Den innehåller många diagram och tabeller med olika detaljnivåer, men här återges de två som är mest talande. Tabell 1.1: Summering av tidsåtgång i minuter per uppgift. Fotograf Reporter Arbetsledare Redigerare En medarbetare börjar En medarbetare slutar En medarbetare byter arbete och datortyp En medarbetare byter arbete Tabell 1.2 Kostnader för varje typ av uppgift. Aktivitet Medarbetare med bärbar dator börjar Medarbetare med stationär dator börjar Medarbetare med bärbar dator slutar Medarbetare med stationär dator slutar Medarbetare byter avdelning Medarbetare byter från stationär till bärbar dator Medarbetare byter från bärbar till stationär dator Kostnad 440 kr 130 kr 220 kr 90 kr 25 kr 370 kr 240 kr 2

8 Att administrera de medarbetare som börjar och slutar under ett år tar omkring 225 timmar. Att administrera de som slutar tar ca 125 timmar i anspråk. Detta utgör ca 4 % av årsarbetstiden för helpdesk. Men att användaradministration tar endast 4 % av årsarbetstiden stämmer inte överens med den uppfattning som helpdesk och ledningen har. Det kan troligen delvis förklaras med att antalet uppdrag underskattas något. Det är svårt att mäta eftersom alla inte noteras. En annan förklaring på det låga värdet är att de aktiviteter som undersökts är normalaktiviteter utan att problem har tillstött. Alltså är inte eventuella aktiviteter med omgörningar inkluderade i analysen. 1.2 Syfte Syftet med rapporten är att undersöka hur man kan integrera system i varandra så att de kan dela användardata och om detta ej är möjligt, undersöka vilka andra möjligheter finns det för att integrera systemen. Syftet med rapporten Arbetsflödesstyrssystem är att undersöka hur ett grafiskt användargränssnitt för det administrativa arbetet skall vara utformat och vilka funktioner det skall erbjuda. Vidare skall det undersökas hur man kan optimera de användaradministrativa rutinerna förknippade med systemen. De två rapporterna har ett gemensamt syfte på Aftonbladet och det är att applicera teorierna på Aftonbladets helpdesk, deras administrativa verktyg och deras användaradministrativa rutiner. Detta skall leda till ett nytt och dramatiskt effektivare sätt för helpdesk att sköta de användaradministrativa uppgifterna. 1.3 Frågeställningar Från uppdraget Aftonbladet erbjöd oss kan man se en frågeställning: Hur rationaliserar och automatiserar man det användaradministrativa arbetet vid en IT-baserad organisation? Även om den frågeställningen är intressant och relevant är den inte specifik nog för vårt arbete. Med vår bakgrund inom IT-management är det två problem som är intressanta för oss. Dessa är även av intresse för organisationer som möter samma problem som Aftonbladet. Ena problemet, som behandlas i uppsatsen Enterprise application integration vid Aftonbladet, är hur man handskas med de olika användaradministrativa funktionerna av systemen inom en IT-baserad organisation. I Aftonbladets fall rör det sig om ungefär tio vitt skilda system. Dessa system lagrar ungefär samma användardata med samma information. Det är huvudsakligen användarnamn, lösenord och behörigheter. Hur kan man integrera dessa system i varandra så att de kan till större utsträckning dela användardata? Om ovanstående ej är möjligt, hur kan man göra dessa data tillgänglig för läsning och uppdatering av andra system så att integration ändå kan ske? Det andra problemet, som behandlas i uppsatsen Arbetsflödesstyrssystem vid Aftonbladet, är mer inriktat på dem som genomför det användaradministrativa arbetet. Inom det arbetet använder de en mängd olika grafiska användargränssnitt, i Aftonbladets fall drygt tio olika gränssnitt. Detta är mycket ineffektivt och leder till 3

9 integritetsproblem med användarinformation. Följaktligen vill Aftonbladet ha ett enat grafiskt användargränssnitt för det användaradministrativa arbetet. Hur kan detta grafiska användargränssnitt vara utformat och vilka funktioner ska det innehålla? När man integrerar systemen så uppstår möjligheter för effektivisering av användaradministrativa rutinerna förknippade med systemen. Hur kan de användaradministrativa rutinerna förknippade med systemen effektiviseras? 1.4 Avgränsning Vi avgränsar våra examensarbeten och arbetet vid Aftonbladet till att effektivisera problemområdet. Med problemområdet menar vi samarbetet mellan helpdesk och personaladministrationen kring hanteringen av personal i Aftonbladets redaktionella produktionssystem. 4

10 2 Metod 2.1 Tillvägagångssätt Bakgrund Detta examensarbete är slutpunkten i vår civilingenjörsutbildning i Medieteknik vid KTH. Marcus Olofsson och jag har båda läst inriktning IT-management vid IT- Universitetet i Kista. Vi bestämde där att vi ville göra examensarbete tillsammans inom IT-management. Samtidigt som vi fick erbjudande att utföra arbetet vid Aftonbladet kontaktade vi professor Nils Enlund för att fråga om det var möjligt att göra examensarbetet under honom vid Medieteknik och Grafisk produktion. Vi var välkomna och tekn. dr. Alex Jonsson blev vår handledare vid KTH och Mattias Nyman, IT-chef, vår handledare vid Aftonbladet Inläsning Inläsningen pågick under en mycket lång och utdragen tid. Sammanlagt rör det sig om sex veckors heltidsarbete, men ägde rum under halvfart nästan hela våren Inläsningen påbörjades med mycket stor bredd. Områden som täcktes var Business Process Management och Business Process Reengineering, med verktyg som Idealized Design och Business to Business (B2B). Efter en längre tid infann sig insikten att vi behövde gå på djupet med mer specifika teorier och verktyg. Inom området Business Process Management fann vi arbetsflödesstyrsystem och arbetsflödesmetodiken intressant och applicerbart. Samtidigt fann vi Enterprise Application Integration (EAI) i litteraturen till Business Process Reengineering. Dessa ämnen är relaterade på så sätt att EAI är en förutsättning för utveckling av avancerade arbetsflödesstyrssystem. Samtidigt kräver en investering i EAI väl fungerande arbetsflödesstyrssystem för att nå den maximala potentiella avkastningen. Det finns ingen allmän term för enterprise application integration på svenska. En möjlig översättning är organisationssystem integration. Då branschförkortningen är EAI används den i hela uppsatsen. Vi nådde därmed en naturlig delning av både rapporten och uppdraget vid Aftonbladet. Marcus Olofsson behandlar arbetsflödesstyrssystem och arbetsflödesmetodiken och jag behandlar EAI. Mycket av arbetet skedde dock i nära samarbete, detta gäller framförallt inläsningen och utvecklingen vid Aftonbladet. Vi hänvisar till referensförtäckningen för en exakt lista över vad vi har funnit vår information. Men vi har huvudsakligen använt oss av böcker och artiklar för teoriinläsningen. För det praktiska arbetet vid Aftonbladet och de tekniska lösningarna har webbsajter, forum och e-postlistor varit mycket värdefullt. Även förlaget O Reillys böcker inom områden som PHP, Perl, LDAP, MySQL har varit mycket användbara Problemformulering När inläsningen var klar formulerade vi gemensamt frågeställningarna kring problemet. Dessa reflekterar delningen i uppsatserna och uppdraget. 5

11 2.1.4 Arbetsplanering För att planera vårt arbete efter inläsningen skrev vi en startrapport som vi överlämnade till examinator och de två handledarna. Den försökte vi sedan följa, även om tidsplaneringen ändrades under tidens gång, vilket ledde till att rapporten försenades en månad. Vi underskattade tiden det tog att formulera frågeställningar kring problemet och att hitta relevanta teorier. Vi hade inte heller inkluderat våra semestrar i planerna som sträckte sig över sommaren Informationsinsamling vid Aftonbladet Vi försökte tillbringa så mycket tid som möjligt på Aftonbladet för att kunna ta del av hur arbetet går till inom problemområdet för vårt uppdrag. Efter inläsningen var färdig blev detta arbete mer målinriktad med en fullständig kartläggning, både av tekniken och av arbetsflödet. Vi insåg att det fanns områden inom tekniken som vi behövde fördjupa oss i för att kunna utföra uppdraget vid Aftonbladet. Återigen genomförde vi en inläsningsperiod, denna kortare och mer fokuserad på källor på internet och litteratur från förlaget O Reilly Praktiskt arbete vid Aftonbladet Genom separat arbete, men med tätt samarbete, arbetade jag med EAI-lösningen och Marcus Olofsson med arbetsflödesstyrsystemet. Vi arbetade inom våra egna uppsatsers ämnesområden, men konsulterade varandra vid behov. Vi började med att applicera verktyg som vi studerat under inläsningen, arbetsflödesmetodiken och Linthicums tolv steg till EAI, på problemområdet vid Aftonbladet (Linthicum, 2000). Detta ledde till två planer och en gemensam målsättning för hur uppdraget vid Aftonbladet skulle genomföras. Planerna var relaterade så att ena planen, den för arbetsflödesstyrsystemet, inkluderade en kravspecifikation för ett gränssnitt. I planen för EAI lösningen inkluderades denna kravspecifikation då det ingick i EAI lösningen att utveckla ovannämnda gränssnitt. Planerna genomgick tre faser. Under utvecklingsfasen utvecklades lösningarna. I testfasen testades lösningarna och eventuella buggar slätades ut. Under sista fasen, implementeringsfasen, installerades lösningarna för att därefter lanseras i Aftonbladets IT-miljö. De två första faserna genomfördes parallellt. Planen styckades ner i många mindre delar, med distinkta problem. Dessa problem behandlades parallellt, en lösning utvecklades och lösningen testades därefter. Alltså skedde inte utvecklingen i ett enda svep, följt av tester. Tanken med denna strategi var att även om vi inte skulle uppnå våran målsättning skulle Aftonbladet fortfarande kunna ta del av de lösningar som hunnit bli färdiga. Om vi utvecklat med den andra strategin skulle en försening innebära att ingen lansering av de nya lösningarna skulle vara möjlig inom tidsramen för examensarbetet Disposition 6

12 EAI vid Aftonbladet Inledning Metod Arbets ödesstyrsystem vid Aftonbladet Sista uppgiften var att sammanställa examensarbetena i två uppsatser. Dessa uppsatser, varav ena du just nu läser, har en sammanvävd disposition. Vissa avsnitt, som detta, är gemensamma för uppsatserna. Teori Teori I figur 2.1 illustreras hur dispositionerna ser ut och är relaterade. Uppsatserna delar inledning, metod, en sammanfogande del av redovisningen av det praktiska arbetet, slutsatser och rekommendationer. Verktyg: Admin ett EAI projekt Verktyg: Arbetsflödesmetodik vid Aftonbladet Aftonbladet specifikt De horisontella pilarna i figur 2.1 representerar hänvisningar mellan rapporterna. Admin ett arbetsflödesstyrsystem Sammanfogande Diskussion Diskussion Slutsats Rekommen dationer Figur 2.1: Disposition av de två uppsatserna. 7

13 3 Enterprise Application Integration 3.1 Bakgrund Inom IT-baserade organisationer är ofta många system och lösningar så kallade skorstenssystem. Skorstenssystem är program som utvecklades för att stödja specifika affärsfunktioner. Exempel på dessa kan vara säljstödssystem, redovisningssystem och telefonväxelssystem. I en kartläggning av en organisations tekniska lösningar ser dessa system ut som isolerade vertikala strukturer, därför namnet skorstenssystem. Eftersom de inte var utvecklade för att kommunicera med andra system är de svåra att integrera. Men många av dessa skorstenssystem har blivit mycket värdefulla för organisationen. De kan innehålla hela den data och kunskap som organisationen lever på. Många affärsregler och lösningar kan vara lagrade i koden. Att då ersätta dessa system är mycket svårt och kostsamt. En bättre lösning är att integrera dem i de andra systemen. Integrationen skapar underlag för synergier som tidigare inte var möjliga. Detta leder till en rad konkurrens- och kostnadsfördelar för organisationen. Integration av system har skett tidigare, men har generellt bara varit mellan ett system och ett annat. Det har varit ad hoc lösningar som är specifika för problemet det löser och har ej varit applicerbara mellan andra system. Man slår ihop två skorstenssystem och skapar en ny större skorsten. Situationen blir ohållbar när sedan fler system skall integreras i lösningen. Med enterprise application integration inser man detta faktum (Ruh, 2001). 3.2 Definition av EAI Enterprise Application Integration (EAI) är en relativt ny term i informations teknologivärlden. Termen finns ej på svenska, men om den skulle översättas skulle den kanske kallas organisationssystem integrering. Den skapades av industrianalytiker som ville uppmärksamma IT-baserade organisationer på utveckling av programvara som hjälper och förenklar integration. Två definitioner för vad EAI är: EAI är integration av olika applikationer så att de fritt kan dela med sig av information och processer (Linthicum, 2000). EAI är skapandet av affärslösningar genom att med hjälp av gemensam middleware kombinera programvara (Ruh, 2001). Gamla system Paketerade program Internet EAI Klient-server program Objekt Figur 3.1: EAI är integration av olika applikationer så att de fritt kan dela med sig av information och processer (Linthicum, 2000). 8

14 Tekniken som gör EAI möjlig är middleware. Inom dataindustrin är middleware en generell beskrivning av all slags oberoende teknik som tillåter att man kan kommunicera mellan flera separata och ofta vitt skilda system eller program. 3.3 Integrationsmodeller En integrationsmodell är en metod för hur man integrerar mjukvara. Det finns tre stycken olika modeller och de har olika svårighetsgrader, begränsningar, återanvändbarhet, fördelar och nackdelar. Det tre är: Presentationsintegrationsmodellen (Presentation integration model) Dataintegrationsmodellen (Data integration model) Funktionsintegrationsmodellen (Functional integration model) Presentationsintegrationsmodellen En lösning byggd efter presentationsintegrationsmodellen integrerar ny mjukvara genom befintliga presentationer av gammal mjukvara. Med presentationer menas användargränssnitt som en människa arbetat mot, alltså ett grafiskt användargränssnitt eller ett textinmatningsbaserat användargränssnitt. Denna metod används vanligtvis för att bygga nya grafiska användargränssnitt, men kan även användas för att integrera med annan mjukvara. Genom att göra detta nyttjar man den gamla mjukvarans programlogik och slipper därmed utveckla egen ny. Grafiskt användargränsnitt Presentationen Presentationen Gammal programvara Packeterad programvara Data Data Figur 3.2: Presentationsintegrationsmodellen integrerar via användargränssnittet av gammal eller packeterad programvara. Man kan använda den här modellen om man vill (Ruh, 2001): Sätta ett grafiskt användargränssnitt på ett existerande textinmatningsbaserat program. Bygga ett grafiskt användargränssnitt till en uppsättning program, men man vill att användaren ska uppleva det som ett enda program. Integrera ett program vars enda möjliga integreringspunkt är genom dess presentation. Fördelar med den här modellen är att den är mycket snabb och enkel att utveckla. Det är lätt att kartlägga ett användargränssnitt och man slipper att utveckla en logik åt 9

15 programmet. Å andra sidan är man helt begränsad till vad det ursprungliga användargränssnittet erbjuder i form av funktioner och tillgång till data. Det är även svårt att återanvända lösningen Dataintegrationsmodellen Dataintegrationsmodellens integrerar mjukvara på datanivå genom att tillåta åtkomsten av data som är skapad, uppdaterad och lagrad av mjukvaran. Man undviker därmed användargränssnittet och programlogiken. Grafiskt användargränsnitt Programvarulogik Middleware Gammal programvara Packeterad programvara Data Data Figur 3.3: Dataintegrationsmodellen integrerar direkt mot data, och undviker användargränssnittet. Detta kan ske på många olika sätt, från relativt enkla som genom ett database management system (DBMS) som programmet också använder, eller med mer sofistikerade integreringar med unika databaser eller filer använda av programmet. Olika verktyg kan användas för att integrera informationen från databaser. Exempel på dessa verktyg är följande (Ruh, 2000): Open Database Connectivity (ODBC) ODBC är ett standardiserat programmeringsgränssnitt som abstraherar åtkomsten till olika typer av databaser, framförallt relationsdatabaser. Databasen måste erbjuda ett ODBC gränssnitt för att kunna stödja det. På samma sätt kan man även nyttja andra datakällor än databaser som har ODBC gränssnitt. Database access middleware (DAM) En form av middleware som tillhandahåller åtkomst till databaser. Fungerar på liknande sätt som ODBC, men är ofta centraliserat för flera olika databaser och har dessutom en plattform för att sköta kommunikation mellan databaserna. Det tillhandahåller även andra avancerade funktioner relaterade till skötsel och handhavande av databaser. Datatransformering Ett verktyg som komplementerar middleware och används för att konvertera data mellan olika format. Ett exempel kan vara att konvertera datum mellan databaser då de har olika format för datum. 10

16 Man kan använda den här modellen om man vill: Kombinera data från flera källor för analys och beslutsunderlag. Erbjuda flera system åtkomst till samma data. Tillåta att data extraheras från en källa, förändras och sedan uppdateras i en annan källa. Därmed kan man bibehålla dataintegritet mellan källorna. Fördelarna är många med den här lösningen jämfört med presentationsintegrationsmodellen. Data blir fullständigt tillgängliga och kan manipuleras på valfritt sätt, man är alltså inte begränsad av programlogiken. Det är enkelt att kombinera flera datakällor eller förflytta information mellan dem. Det går att återanvända lösningen, när en databas väl har ett ODBC-gränssnitt eller är anslutet till ett middleware så kan valfri mängd program integreras med databasen. En av nackdelarna är att man måste skriva om programlogiken. Vissa uppslagningar och manipuleringar av data skall kanske inte tillåtas och integriteten mellan olika källor får inte glida isär. Detta kan vara besvärligt att hantera, speciellt om felhantering är nödvändigt. Om programlogiken inte är inkluderad i ett middleware måste varje program som arbetar mot källorna ha en egen programlogik. Till sist om strukturen som data är lagrad i förändras, kan integrationen spricka och gör därför dataintegrationsmodellen känslig för förändringar Funktionsintegrationsmodellen Med funktionsintegrationsmodellen integrerar man mjukvara för att dela funktionalitet mellan flera program. Denna integration sker på kodnivå genom gränssnitt till mjukvaran. Man nyttjar därmed den existerande programvarans kod och får tillgång till all funktionalitet och data. Därmed erbjuder den alla fördelar av de två föregående modellerna. Man kan därmed bygga en egen programlogik som är bättre anpassad till organisationen. Grafiskt användargränsnitt Programvarulogik Middleware Gammal programvara Packeterad programvara Data Data Figur 3.4: Funktionsintegrationsmodellen integrerar direkt med koden av programvaran. 11

17 För att integrera enligt funktionsintegrationsmodellen använder man sig av en typ av middleware som kallas distributed processing middleware (DPM). DPM är en typ av mjukvara som tillåter kommunikation mellan mjukvarukomponenter med hjälp av definierade gränssnitt eller meddelanden. Vidare så tillhandahåller det en plattform för att styra kommunikationen mellan de olika programvarukomponenterna. Det finns två typer av distributed processing middleware: Message oriented middleware (MOM) Skapar integration mellan program genom att skicka meddelanden mellan dem. Kräver att programmen har meddelandemottagande och meddelandesändande funktionalitet. Distributed object technology (DOT) DOT applicerar objektorienterade koncept på middleware. Gränssnitt ser ut som mjukvaruobjekt. Mjukvaran kan nås av andra program över ett nätverk via mjukvaruobjektet. Dessa typer beskrivs närmare i avsnitt 3.4 nedan. Man kan använda den här modellen om man vill: Ersätta ett textinmatningsbaserat gränssnitt med ett grafiskt användargränssnitt. Detta sker genom att det nya gränssnittet direkt arbetar mot koden i programmet. Bygga ett grafiskt användargränssnitt till en uppsättning program, genom att arbeta direkt mot koden i programmen. Kombinera data från flera källor för analys och beslutsunderlag eller erbjuda flera system åtkomst till samma data. Man nyttjar då koden som programmen använder för att arbeta med källorna. Tillåta att data extraheras från en källa, förändras och sedan uppdateras i en annan källa. Detta kan man göra genom att låta gränssnitten meddela andra gränssnitt om att en förändring skett i koden. Därmed kan man bibehålla dataintegritet mellan källorna. Fördelar med funktionsintegrationsmodellen är att den är mest flexibel i sitt användningsområde. Den kan lösa både presentations- och dataintegrations problem. Dessutom erbjuder den mycket hög återanvändning då gränssnitten är tillgängliga direkt i programkoden. Nackdel är att komplexiteten i lösningarna är större. Det är ofta svårt att integrera på kodnivå. I bästa fall erbjuder programmet ett programmeringsgränssnitt, men ibland finns varken källkod eller gränssnitt och då får man vända sig till någon av de andra modellerna. 3.4 Middleware Från föregående avsnitt är det uppenbart att EAI arkitekturer bygger på middleware. Man kan säga att det är limmet mellan de olika integrerade systemen, samtidigt skall det erbjuda icke utnyttjade kladdiga ytor där andra system kan anslutas. Det finns fyra olika typer av middleware på marknaden idag. Dessa är: Remote procedure calls (Fjärranrop av procedurer) Database access middleware (Databasaccess middleware) 12

18 Message oriented middleware (Meddelandeorienterad middleware) Distributed object technology (Distribuerad objektteknik) Remote procedure calls (RPC) RPC är en typ av middleware som tillåter att procedurer anropas över nätverk utan att nätverket är känt för varken avsändare och mottagare. På det viset skapas ett program som är spritt över flera datorer. Det är en teknik som var populär på 1970-talet, men som sedan har sjunkit i popularitet sen andra middleware teknologier introducerats Database access middleware (DAM) DAM är en typ av middleware som är byggd för att kunna nå data som är spridd i filer och databaser. Den integrerar på datanivån och tillåter dataförfrågningar och dataförflyttningar över ett nätverk. Denna typ av middleware blev populär under slutet av 1980-talet. Structured Query Language (SQL) är en standard med lång historia för att ställa frågor till databaser. Men det fanns det ingen standard för att ansluta till databaser. Varje databasleverantör erbjöd sina egna lösningar för att tillåta programvara att kommunicera med databasen. Middlewaret samlar dessa lösningar så att programvaran ställer SQL-frågor till ett gränssnitt som middlewaret tillhandahåller. Middlewaret sköter sedan kommunikationen med databaserna och filerna. På senare tid har Open Database Connectivity (ODBC) blivit en populär standard för att nå databaser, men ändå envisas vissa leverantörer, som Oracle, med egna gränssnitt. Därför finns det fortfarande DAM lösningar på marknaden. OBDC har förövrigt utvecklats till att erbjuda Java kompatibilitet med gränssnittet JDBC Message oriented middleware (MOM) MOM tillåter vitt skilda system att integreras med hjälp av meddelanden. Ett meddelande är en kombination av styrinformation och data, där styrinformationen innehåller information som avsändare, mottagare och en beställning och data är den information som krävs för att utföra beställningen. MOM erbjuder en plattform för att skapa, förändra, köa, lagra och skicka dessa meddelanden. Eftersom det är så pass enkelt är det populärt. Plattformen kan i viss utsträckning abstrahera programmen från varandra genom att nyttja ett datatransformeringsverktyg. Det är däremot lite abstrakt för en programmerare att se meddelanden som ett gränssnitt till ett program, om man jämför med de objektorienterade programmeringsgränssnitten i distributed object technology Distributed object technology (DOT) DOT påminner om RPC middleware, men är byggt på det objektorienterade konceptet. Med DOT skapar man objektorienterade programmeringsgränssnitt till program. Med dessa kan man sedan nå all funktionalitet i koden som programmet innehåller, samt all data som programmet handhaver. När man anropar objekten i ens kod är det ointressant var objekten finns och hur objektet är kodat. Därmed uppstår en stor flexibilitet. Om man ser till att objektet är bakåtkompatibelt kan man uppgradera programmet som objektet representerar och erbjuda ny funktionalitet, utan att störa befintliga lösningar. 13

19 3.5 Fördelar med EAI Enligt Linthicum (2000) kan applikationsintegration spara mycket pengar åt företag, men det är de konkurrenskraftiga fördelarna som oftast driver företag att genomföra en integration. Andra fördelar med EAI är att: EAI ökar integriteten vid transaktioner och automatisering av komplexa processer och arbetsflöden. EAI ger en möjligheten att välja den applikation som bäst passar tillämpning och användare och slippa det tunga beroendet till en affärssystemsleverantör. EAI möjliggör att man förlänger livslängden på de befintliga och väl fungerande systemen. EAI kan eliminera manuellt arbete. Man kan minimera dubbel inmatning av information. EAI ger en flexibilitet som gör att man snabbt kan svara på förändringar på marknaden genom att kunna byta ut eller lägga till vissa applikationer. Man kan dra slutsatser ur den statistik som uppstår av meddelandehanteringen, till exempel att kunna följa upp hur många orderavbokningsmeddelanden som skickas. På sikt få fram en samlad databasstruktur som underlättar vid uppköp och sammanslagning av företag. 3.6 Nackdelar med EAI Hoppet om att flytta information mellan olika applikationer och databaser står till middleware. Men tyvärr finns det idag ej något tillgängligt middleware som tillhandahåller alla förutsättningar som krävs för total integration tillsammans med en oöverträffad prestanda. Innan integration kan ske gäller det för verksamheten att utforska alla middlewareteknologier och jämföra deras fördelar och nackdelar i just sin egen verksamhets specifika situation. Vidare finns det en risk att när EAI lösningen växer så växer komplexiteten ur kontroll. Det är därför viktigt att lösningen byggs på ett enhetligt och dokumenterat sätt (Linthicum, 2000). 14

20 4 Verktyg 4.1 Linthicums tolv steg till implementering av EAI Att implementera EAI vid en organisation är en lång och svår procedur. EAI är sällan repeterbart då varje organisation är unik med alla dess processer och affärstransaktioner. Därmed är det sagt att EAI är ingen exakt vetenskap. Det finns ingen allsmäktig lösning som kan implementeras på alla problemområden. Däremot finns det metodbeskrivningar som man kan följa. Målsättningen med metoderna är att man ska vara säker på att man har belyst alla delar av problemområdet, identifierat och kartlagt all data, alla processer och affärstransaktioner. När informations-insamlingen är klar är man redo för att framställa den bästa möjliga lösningen för problemområdet. Nedan följer en sådan metodbeskrivning utformad av David Linthicum (2000). 1) Förstå organisationen och problemområdet Detta är en största och mest tidskrävande steget av de tolv stegen och även det viktigaste. Här sätter man sig in i organisationen och identifierar dess problemområde. Det är viktigt att man avgränsar problemområdet på rätt sätt så att man kan göra en riktig analys av situationen. Kvaliteten på informationen framtagen genom detta arbete har stor betydelse vid de följande stegen. 2) Kartlägg problemområdets data Man kan implementera EAI med hjälp av de tre tidigare nämnda integrationsmodellerna. Oavsett vilken modell man väljer skall man alltid börja undersökningarna på datanivå. Att kartlägga data och därmed göra den tillgänglig och förståelig handlar helt och hållet om att förstå var data existerar, samla information om den och ta reda på vilka dataflöden som finns samt var de flödar och varför. Enligt Linthicum (2000) finns tre grundläggande punkter man måste följa innan man implementerar EAI på datanivån. Dessa tre punkter är: Identifiera data Att identifiera data innebär att man tar reda på vilka databaser finns och var dessa fysiskt befinner sig. Här inkluderar man även vilka maskiner, modeller och operativsystem som används. Katalogisering av data Katalogisering av data är processen som sammanfogar metadata och annan data. Metadata är data som beskriver annan data. Till exempel är Ålder metadata för datavärdet 26, som är min ålder. Bygga en metadatamodell Metamodellen används som ett underlag för att kunna integrera alla olika data som existerar inom organisationen. 3) Kartlägg problemområdets processer När man har gjort det två ovannämnda stegen är det dags att kartlägga de olika processerna inom problemområdet. Processer är de grundläggande uppgifter som olika individer eller system i problemområdet utför. 4) Identifiera alla affärstransaktioner 15

21 Nästa steg är att identifiera alla affärstransaktioner i organisationen. Med detta menar Linthicum att alla transaktioner inom en organisation leder till att en eller flera processer utförs. Det är viktigt vid kartläggning av organisationen att ta reda på vem som beordrade transaktionen, vad som hände och om det var några andra transaktioner som uppstod när den ursprungliga transaktionen beordrades. 5) Identifiera grafiska användaregränssnitten Det är viktigt att ta vara på de grafiska användaregränssnitt som fungerar och tillgodoser kundens behov. Genom att göra det minskar man obehaget hos användaren av att allt nytt känns svårt och därmed frustrerande. Målsättningen är alltid att användarna inte ska märka att stora förändringar har genomförts i de bakomliggande systemen. 6) Kartlägga hur innehållet förändras i flytt mellan system I denna punkt kartlägger man hur data måste förändras för att kunna flyttas mellan de olika systemen inom problemområdet. Detta sker för att möjliggöra informationsutbyte mellan systemen. 7) Kartlägga alla informationsförflyttningar Innebär att man kartlägger alla informationsförflyttningar mellan systemen inom problemområdet. Man vill ta reda på vilken information som flyttar från vilka system och till vilka system informationen flyttas. 8) Implementera tekniken Ett uttryck inom EAI är att det finns många sätt att slakta en ko på. Vad det betyder är att det finns många sätt att rent tekniskt genomföra EAI. Valet av teknologi beror helt och hållet på problemområdet, dess struktur och vilka som genomför förändringen. Det är därför ofta en svår och tidskrävande procedur där man först värderar alla möjliga lösningar och sedan väljer den som bäst uppfyller den av kunden uppsatta målsättningen. 9) Testa, testa och testa Att testa de valda lösningarna är både kostsamt och tidskrävande. Detta är en viktig punkt och om den inte görs rätt kan det uppstå stora problem, så som integritetsproblem i data. För att testning ska gå till på rätt sätt kan det vara bra att utforma och följa ett testprotokoll. 10) Granska prestanda på EAI-lösningen Ofta ignoreras vikten av att ha god prestanda på sin lösning och detta kan vara förödande för EAI-lösningen. När man implementerar en ny applikation är det viktigt att prestanda är bättre än före genomförandet. 11) Värdesättning av implementeringen Vid det här laget har man gjort den svåra delen av EAI. I detta steg gäller det att värdesätta vinsterna med EAI lösningen. Man måste betrakta både hårda och mjuka värden. De hårda värdena är direkt mätbara i de kostnader man eliminerar med hjälp av EAI, oftast i form av tids- och bemanningsbesparingar. De mjuka värdena är de icke kvantifierbara värden som uppstår med hjälp av EAI. Dessa är ofta humana aspekter så som mindre stress, mer nöjda användare och mindre irritation på grund av tråkiga rutinuppdrag. 16

22 12) Skapa rutiner för övervakning och drift När man nu nästan är klar med framtagandet av EAI-lösningen måste man skapa rutiner för hur det fortsatta arbetet ska fortgå inom organisation. Vem ska övervaka det nya systemet och se till att utvecklarna får reda på buggar och prestanda problem, samt behov för ny funktionalitet. 17

23 5 Admin 2.0 ett EAI projekt 5.1 Steg Problemområdet: Helpdesks och personaladministrations samarbete I steg ett av Linthicums tolv steg till implementering av EAI är målet att förstå organisationen och dess problemområde. Problemområdet i vårt projekt på Aftonbladet utgörs av samarbetet mellan helpdesk och personaladministrationen kring hanteringen av personal i Aftonbladets produktionssystem. Personaladministrationen administrerar all personal under deras tid vid mediahuset Aftonbladet. Aftonbladet har, som alla stora aktörer inom mediebranschen, väldigt många vikarier och projektanställda. I Aftonbladets fall är de sammanlagt cirka 170 varje år. Då personalomsättningen på redaktionen är mycket högre än inom andra avdelningar arbetar personaladministrationen primärt med redaktionens personal som består mest av redigerare, reportrar, fotografer och arbetsledare. När personaladministrationen skall anställa en individ eller en i personalen byter tjänst eller slutar så rapporterar de detta i webbtjänsten Personal Adm. De skickar dessutom ett e-postmeddelande till helpdesk om förändringen. Helpdesk i sin tur bevakar Personal Adm för förändringar. Detta sker huvudsakligen av helpdesks nattarbetare. När en förändring sker så genomför helpdesk de nödvändiga förändringarna i systemen individen använder. Till exempel, om en reporter börjar vid Aftonbladet så skall han få tillgång till vissa tjänster i intranätet Galento, texthanteringssystemet Scoop, bildhanteringssystemet Store, filservern Sidorx1. Dessutom skall han ha ett e-postkonto och en bärbar dator för att kunna arbeta. Helpdesk skapar då användaren i alla ovanstående system. För att göra detta får de arbeta i en mängd olika gränssnitt, ibland så många som tio stycken. 18

24 Helpdesk Personal administration Grafiskt användaregränssnitt Mjukvara: Mjukvara: Webbsida: Webbsida: Webbsida: Webbsida: Mjukvara: Mjukvara: Mjukvara: Mjukvara: Admintool Workgroup Manager Datorregistret Admin Communigate Pro Scoop DBmanager Openstore Mac- Radius Mac- Radius Personal Adm Middleware mail CGI: Mail System CLI Opierna aaa Galento & Dbgalento Mail Scoop Store Mac- Radius1 Mac- Radius2 Gamla Galento & Dbgalento NetInfo NetInfo RADIUS RADIUS RADIUS Sidservrarna Teknikservern VPN Airport RAS Figur 5.1: Kartläggning av system, middleware och grafiskt användaregränssnitt som helpdesk och personaladministrationen använde våren 2003 vid Aftonbladet. Figur 5.1 visar en karta över de grafiska användaregränssnitt, middleware och system som helpdesk och personaladministrationen använde våren 2003 vid Aftonbladet. Användaregränssnitten är de program och webbtjänster som används för att genomföra förändringar i systemen. Middleware är verktyg som tillhandahåller enkla mjukvarugränssnitt till de underliggande systemen. System är själva applikationerna som lagrar den data och erbjuder de tjänster användaregränssnitten nyttjar för att använda tjänsterna och för att presentera den lagrade data. Stora datorhallen Lilla datorhallen Opi1 Opi2 MacRadius1 MacRadius2 aaa 30 meter Helpdesk Figur 5.2: Översiktlig karta som visar var gränssnitten fysiskt är tillgängliga för helpdesk. 19

25 En besvärande omständighet för helpdesk är att de inte kan nå alla grafiska användaregränssnitt från sin dator. Opi1, Opi2, MacRadius1, MacRadius2 kräver att medarbetaren lämnar sin plats för att nå dem. Antingen går de till den närliggande datorhallen för att nå Opi1 eller Opi2 eller så får de vandra bort till den stora datorhallen för de andra gränssnitten. De kan visserligen nå aaa via Workgroup Manager på sin dator, men det har visat sig att några nyttjar Workgroup Manager direkt på servern istället. Utifrån de olika systemen beskrivs i följande avsnitt på en detaljerad nivå deras arkitektur Admin, datorregistret och mail.aftonbladet.se Grafiskt användaregränssnitt: Webbgränssnittet Admin används för att administrera användare och deras Middleware Webbsida: Webbsida: Datorregistret Admin Grafiskt användaregränssnitt Webbsida: Communigate Pro CGI: Mail mail rättigheter i Galento, Aftonbladets intranätplattform, samt på mail.aftonbladet.se, Aftonbladets e- postserver. Alla anställda vid Aftonbladet existerar i dessa system. Galento innehåller i dagsläget mer än hundra olika tjänster och är under ständig utveckling. Somliga är bara länkar till externa databaser och tjänster, men de flesta är internutvecklade tjänster som är till för att hjälpa personalen och avdelningarna i det dagliga arbetet. En av dessa tjänster är Datorregistret. Datorregistret används av helpdesk för att registrera alla datorer och vilka som använder dem. System Galento & Dbgalento CLI Mail E-postserver serverns webbgränssnitt, CommuniGate Pro, används främst för att skapa e-postlistor och se vilka mottagare som finns på listorna, men även för avancerade kontoinställningar. Figur 5.3: Karta över Admin, Datorregistret och mail.aftonbladet.se. System och middleware: Admin, Datorregistret och stora delar av Aftonbladets plattform är byggt med Apache, PHP och MySQL på operativsystemet Mac OS X. Galento är en OS X installation med Apache som webbserver. Apache, som är ett öppet källkodprojekt, är den vanligaste webbservern på internet idag och är tillgänglig på de flesta plattformar. PHP är ett HTML-inbäddat skriptspråk som exekveras på webbservern Galento. Det är dynamiskt då det kan arbeta med data från en SQL-databas, så som den MySQLdatabas som finns på servern Dbgalento. Dbgalento är också en OS X installation. Även PHP och MySQL har öppen källkod och finns på de flesta plattformar. MySQL är lite speciellt då även om källkoden är öppen och användare kan utveckla den vidare så styrs dess utveckling av ett svenskt företag vid namn MySQL AB. 20

26 E-postservern är utvecklad av Stalker och heter CommuniGate Pro. Den är installerad på Mac OS X. En del av e-postserverns funktionalitet kan styras i webbgränssnittet Admin. Detta sker via ett middleware som utvecklat med Perl i form av en uppsättning CGI som ligger på e-postservern. Perlskripten utför kommandon via ett terminal gränssnitt som CommuniGate Pro inkluderar. Till exempel, om man skapar en användare i Admin så skapas även användarens e-postkonto. Detta sker genom att PHP-koden i Admin kallar på ett Perl-CGI som ligger på e-postservern. Perlskriptet tar emot parametrar så som vad kontot skall heta, vad användaren heter och vilket lösenord det ska. Perlskriptet ansluter till terminal gränssnittet på CommuniGate Pro och utför de kommandon som krävs för att ett konto skall skapas med rätt namn och lösenord. Se bilaga 1 för mer information om PHP, MySQL, Perl och CGI Scoop Middleware Helpdesk Grafiskt användaregränssnitt Mjukvara: Scoop DBmanager Grafiskt användaregränssnitt Scoop DB Manager är en programvara med grafiskt användaregränssnitt på Mac OS X. Den används för att hantera användare till det texthanteringssystem, Scoop, som används av redigerare, reportrar och fotografer. Texthanteringssystemet Scoop är utvecklat av ett svenskt företag vid namn Wilkenson. All text och användardata lagras i en Oracle 8.0 databas som är installerad på en Sun Solaris maskin. Scoop DB Manager ansluter till denna databas. System Scoop Figur 5.4: Karta över systemet Scoop. 21