Komponentbaserade standardsystem

Det finns en trend mot att leverantörer börjar bygga upp sina system med hjälp av applikationsdelar i miniatyrformat som kallas för standardkomponenter eller verk-samhetsobjekt¹.

1 Flera andra undersökningar påtalar även en framtida trend mot komponentbaserad sys-temutveckling. Se Wennnersten, B.G. & Sandén, W. (1996). Så kan Sverige utveckla en framgångsrik programvaruindustri inför 2000-talet, Rapport 1/96, IT-kommissionen, Stockholm. Se även Sundgren, B. (1996). Vi vill ha ett användarvänligt och flexibelt sys-tem!, i Lundeberg, M. & Sundgren, B. (Red.). Att Föra Verksamheten Framåt – Män-niskor och informationssystem i samverkan, Studentlitteratur, Lund som behandlar beho-vet av standardkomponenter inom framtida systemutveckling.

Flertalet befintliga standardsystemprodukter delar samma karaktäristik. De är byggda för att fungera som en helhet, men integrerar dåligt med andra produkter.

De undantag som har börjat synas på marknaden bygger på nya system- och utvecklingstekniker. Som exempel kan objektorienterade verktyg och standarder nämnas. Dessa skulle i sin tur kunna utnyttjas för att utforma tillämpningar inom det administrativa området uppbyggda av komponenter (”byggklossar”).

Konceptet med komponenter som sådant är känt från andra områden. I de flesta industrier används och återanvänds komponenter för att bringa ned kostnader och ledtider för framtagande av nya produkter. Komponenter karaktäriseras av att de har ett precist definierat ”gränssnitt” mot omvärlden (som exempelvis kan jämföras med dimensionen på en skruv) och ett tillika väldefinierat ”beteende” (som kan jämföras med ett lås som kan stängas och öppnas)¹. Gränssnittet i vårt fall avgör hur omgivningen kan kommunicera (utbyta information) med komponenten. Bete-endet kan beskrivas som hur komponenten reagerar på data som den tar emot.

Utmaningen i att bygga en komponent som skall kunna användas i ett större sam-manhang tillsammans med andra komponenter ligger i att tillse att gränssnitt och beteende följer den specifikation som anges för komponenten. I annat fall kommer användningen av komponenten potentiellt inte att resultera i avsett resultat.

Att bygga komponenter kan jämföras med moduluppbyggnad som har använts under lång tid för att underlätta konstruktion, tillverkning och testning. Benäm-ningen modul är av intern karaktär (inom företag, affärsenhet eller liknande) medan komponent är mer av produkt som kan tillverkas och säljas (för olika ända-mål).

Inom standardsystembranschen har begreppet ”modul” använts för att beskriva olika funktionella delar (delprodukter) inom ett och samma system (totalprodukt).

Härvid har modulernas beteende beskrivits, men deras gränssnitt har varit mindre intressanta eftersom samma leverantör har kunnat hantera detta som en intern kon-struktionsdetalj. Även om systemet kan sägas använda komponenter så förutsätts den resulterande produkten i huvudsak användas för sig och i sin helhet.

I den mån det är möjligt att utbyta information mellan olika produkter, så är det ett resultat av den underliggande plattform som produkterna är byggda på. Det finns sällan funktioner i produkten som gör att den effektivt kan samverka med andra produkter.

1 Det finns många olika definitioner av begreppet ”komponent” i litteraturen. Se t.ex. Steel J. (1996). Component Technology, Part I, IDC White Paper, International Data Corpora-tion, London. Rapporten beskriver bl.a. IDCs definition av en komponent och ger en beskrivning av konkurrerande standarder inom komponentområdet.

Som exempel kan nämnas möjligheten att extrahera information ur ett standardsys-tems datalager. Flera av dagens standardsystemprodukter använder en databashan-terare som har verktyg för att söka och sammanställa information. Den information som tillämpningen lagrar är dock sällan organiserad eller dokumenterad så att det går att komma åt informationen på ett smidigt sätt.

Utnyttjande av en kommersiell databashanterare i ett standardsystem kan i och för sig sägas utgöra komponentanvändning. Databashanteraren säljs vanligen som en fristående produkt och har ett väldefinierat gränssnitt som standardsystemprodu-centen följer för att utnyttja databashanterarens beteende. Ett sätt att beskriva till-lämpningar är att göra följande indelning¹:

•

Presentation. Denna del av tillämpningen tar emot indata och presenterar resul-tat av bearbetningar på olika sätt (grafisk, i tabellform, som rapporter).

•

^Logik. Denna del av tillämpningen bearbetar inmatad information. Logikdelen är kärnan i tillämpningen. Presentation och datalager kan ses som stödfunktio-ner till logiken.

•

^Datalager. Denna del av tillämpningen lagrar bearbetad information för senare bearbetning och presentation.

Moduler kan sägas vara vertikala komponenter som innehåller alla delar (presenta-tion, logik och datalager). Exempel på moduler i standardsystem kan vara lönebe-räkning, fakturering och kundreskontra. Som tidigare nämnts har man i befintliga standardsystem lagt mindre vikt vid gränssnittens utformning, En databashanterare kan beskrivas som en horisontell komponent, som löser en del av datalagrets upp-gift. Presentationsverktyg är på motsvarande sätt horisontella komponenter som löser en del av presentationsskiktets uppgifter. Se figur 2 på nästa sida.

Framtidens komponenter kommer att ha väldefinierade gränssnitt både horisontellt och vertikalt och kommer därmed att medge en finkornigare indelning av tillämp-ningar. Pilarna i figuren avser flöden av data mellan en komponent och dess omgiv-ning (andra komponenter).

”Vilka fördelar kan komponentbasering medföra?”

Det finns stora skalfördelar inom standardsystembranschen idag. Dagens standard-systemprodukter har utvecklats i sin helhet och vidareutvecklingen av produkterna utgår från ett komplett av leverantören egenutvecklat system. Detta medför att för-säljningsvolym är mycket viktig. Genom att ersätta egenutvecklade delar med

1 Sundgren, B. (1996). Vi vill ha ett användarvänligt och flexibelt system!, i Lundeberg, M.

& Sundgren, B. (Red.). Att Föra Verksamheten Framåt – Människor och informations-system i samverkan, Studentlitteratur, Lund, beskriver en liknande indelning med delsys-tem för användarinteraktion, verksamhetslogik och datahantering.

komponenter som har utvecklats av andra företag kan skalfördelarna minska. Det kan i sin tur innebära att kunder kan få se ett ökat utbud och därmed få större val-möjligheter. Samtidigt kan en leverantör uppnå ”kritisk massa” vid en betydligt lägre installerad bas. Riskerna för att en leverantör råkar i svårigheter på grund av att han har för få kunder minskar. Komponentbasering kan också vara en väg att uppnå högre volym för den enskilde leverantören om han i sin tur kan leverera sina (komponentbaserade) produkter som komponenter i andra produkter.

”Vilka nackdelar kan komponentbasering medföra?”

Komponentbasering bygger på delvis nya teknologier. Det är mycket viktigt att dessa teknologier tillåts mogna och att användningen av dem utvecklas så att de resulterande produkterna uppnår den kostnadseffektivitet, driftsäkerhet och flexibi-litet som förväntas av dem. Det är inte osannolikt att de första produkter som dyker upp på marknaden kommer att ha barnsjukdomar och att det kommer att ta ett tag för komponentbaserade system att mogna. Under vår leverantörsstudie 1994 fick vi flera beskrivningar av pilotprojekt som pågick för att utröna för- och nackdelar med olika nya teknologier.

Vi beskrev ovan hur skalfördelar kan komma att minska som ett resultat av kompo-nentanvändning. Detta kan naturligtvis ses som en nackdel för de allra största leve-rantörerna i branschen eftersom det kommer att vara möjligt för fler företag att eta-blera sig och utnyttja inköpta produkter istället för att som tidigare göra allt själv.

Det implicita etableringshinder som finns idag kommer delvis att rivas. Detta upp-fattar vi som en stor fördel under förutsättning att försvagningen av de stora leve-rantörerna uppvägs av att kunderna får en ökad valfrihet.

Datalager Logik Presentation Vertikal komponent (modul)

Framtidens komponenter

Figur 2. Komponenttyper

Horisontell komponent

Ett tänkbart alternativ är att kunder som idag sitter med kombinationer av standard-system och egenutvecklade standard-system väljer att komplettera eller ersätta delar av sina nuvarande system med olika former av komponentbaserade system. Dessa företag tvingas redan idag hantera problem med samverkan mellan olika system. Införande av komponentbaserade system kan komma att minska dessa problem, men på kort sikt kommer samverkan mellan nya och gamla system att vara ett problem.

8.5 Framtiden för

In document Välja och Förvalta Standardsystem (Page 195-199)